浅谈大数据平台的建设思想及产品服务意识

大数据平台的建设之路漫长、艰难，所以需要统一认知，达成一致的建设思想和目标；进行心理建设，让大家做好充分的心理准备；充分认识平台的特点，有正确的的产品和服务意识。

1. 初心、源动力

大家以前从事web开发或者学习web开发，使用的技术栈是servlet+jsp+tomcat，现在流行springboot+vue.js，为什么会这样？

由于软件工程的复用思想，大量重复的、通用的工作，我们都将其抽象出来，变成了通用开发组件、框架。

大数据技术在一个团队或者一个公司应用到一定阶段，必然进入到平台阶段。因为可以对一些组件进行封装、工具化，提高代码复用和开发效率等。对内可以给内部开发团队使用，对外可以给第三方组织开放大数据服务和能力。

2. 统一平台的整体建设思路和目标

平台建设需要培养跳出现象看本质的习惯和思维。要结合实际的业务场景和用户需求，不仅从技术架构，更要从代价、收益、业务价值、易用性和可维护性等众多角度进行综合评估和取舍。

2.1 what?

大数据相关业务开发平台，是给数据使用者提高方便的平台、工具。

数据使用者包括：数据分析人员、数据管理人员、数据开发人员、数据运维人员等，不同角色对于平台的需求是不一样的。

数据分析人员需要元数据管理、BI自助分析、可视化展示等功能。

数据管理人员需要进行数据资产管理、数据治理等。

数据开发人员在数据分析的基础手上，还需要数据集成开发环境、工作流调度等，很多公司内部的平台纯粹为了开发者使用。

数据运维人员要进行集群的搭建、运维等工作，由于有了Cloudera、Hortonworks的Hadoop套件，很少有公司强调这方面的平台组件管理工具。

2.2 target?

大数据平台的目标是方便使用者，提升工作效率，实际产出了多少价值，降低平台开发人员运维成本。

目前各家公司使用大数据技术的现状：组件与大公司相比一个都不少，但是平台的实际应用水平和所提供的服务时，这些平台往往是极度原始和简陋。

• 与大公司平台成熟度的差距在哪里？

产品和服务形态。

比如小米与苹果的差距？硬件差距相对没那么多，小米总是使用业界最先进的硬件，毛利率极低，更多的是软实力的差距。

如何扬长避短：组件的深度、新技术的探索确实无法跟大公司比，但本质的东西：平台的价值、投入产出效益，产品和服务形态，可以跟其他公司対飚。特别是阿里云，他为了做到通用性，就没办法照顾不同行业、不同层次用户的诉求。垂直领域的一些诉求，相对比较通用，相对可以从产品和服务形态与其竞争，特别是当市场规模没那么大时，往往是大公司忽略的地方。如抖音、快手，如拼多多、融360，并不是与BAT比拼技术能力，也是在比拼产品与服务能力。小公司在组件的使用上，并不会比大公司有那么大的差距，像阿里云专家对于多维分析，也没有更好的解决方案。

• 平台为用户
  1. 解决了哪些问题？
  2. 扫除了哪些障碍？
  3. 提升了多少工作效率？
  4. 产生了哪些附加价值？或者实际产出的价值？投入产出效益？
  • 更深层次
    • 平台内部组件的横向联通能力
    • 业务流程上纵向贯穿打通上下游链路的能力

2.3 建设指导方针：四化建设

1. 组件工具化：组件维护、用户应用开发

   1. SDK：权限控制、操作数据采集、流量监控、屏蔽一些高风险操作、简化一些用户的操作(kafka消费者中的偏移量)

   2. HBase SQL(Phoenix)

   3. 尽量给用户提供统一sql引擎

   4. 提供一些工具将这些组件、操作封装起来。不仅仅是为了降低用户的学习成本，也有助于屏蔽集群的拓扑布局、业务操作的命令细节、组件版本的兼容性问题等。

2. 工具平台化：组件、工具、开发流程整合在一起，统一管理，提供成体系的开发运维管理途径。

   1. 通过规范开发流程，提高平台整体的稳定性和可控性，进而提升运维和业务开发的效率。

   2. 哪些是可以做、应该做也值得做的事情。

3. 平台服务化：用户想要的东西，以用户体验为中心。用户满意是衡量服务水平的唯一标准。.

4. 平台产品化

   1. 困境：
      1. 公司角度：团队资源的投入产出比，对公司业务价值的产出贡献。
      2. 团队角度：做得越多错得越多，服务越好负担越重。
   2. 如何破？良好的产品形态来换取可衡量的价值产出才能打破。

5. 平台的适用性：产品定位、服务对象、聚焦核心问题。

   1. 阿里云的EMR，面向小白用户，功能简单。
   2. 企业内部业务开发团队，业务需求更复杂。

• 一站到底 vs 通用组件建设、组合支持业务

在各种取舍、抉择中度过，可能需要两种方式结合。

3. 开发者如何培养正确的产品和服务意识

3.1 平台服务能力的评估标准

对用户产生价值。

用户满意、易用、可用、简单、傻瓜。

• 职能定位？平台+数据处理、上下游全链路通吃。
  • 划分依据：相关系统和特定业务知识是否强关联。
• 能力？打通上下游系统和业务流程。
  • 以工作流调度系统为例，从触发作业运行的角度，调度系统自身的能力包括：各种任务类型的支持、时间/依赖触发能力的支持、任务计划的编排管理能力、对任务执行流水、历史记录的管理。
  • 和上下游及周边业务流程的相关能力：
    1. 后端集群流量、负载的反馈控制能力
    2. 脚本集成开发环境的对接
    3. 与权限系统、数据订阅系统的连通
    4. 和元数据系统的对接
    5. 与任务测试、发布环境的对接
    6. 与报警、值班、监控系统的协同
    7. 和数据治理管理系统的协同

3.2 满足用户的真正需求

• 提供（大）数据处理能力，一站式解决方案，核心服务：

1. 存储
2. 计算
3. 展示

用户并不关心具体的集群、组件。

• 用户在意：

1. 高效、稳定、可靠的存储，满足性能指标。底层存储并不关心。
2. 高效低成本的开发业务。不太想钻研各种计算框架
3. 方便、快速的查询，结果便于理解和沟通，能够有效地支持业务决策。

在满足性能指标的前提下，尽可能简单、方便、易用，得到想要的数据。

对于中小企业来说，根据业务场景，提供简单、易行的解决方案，最起码是封装好的工具。

对于第三方用户，主要诉求是帮助挖掘数据价值。

3.3 认清服务的代价，做好心理建设

• 提供服务这么难，为什么我们还要做？

基于用户满意是评判服务水平的唯一标准。在提供服务时，要有卧薪尝胆的精神。

1. 由俭入奢易，由奢入俭难。用户对服务质量的要求只会越来越高。
2. 服务口碑取决于服务最差的环节。木桶效应
3. 服务越多，支持的代价越高
4. 需求响应要疾如闪电，功能服务要天长地久。
5. 既要马儿驼得多，又要马儿不摔倒
6. 用户的服务诉求各异，众口难调。作为服务提供方，我们的时间在用户看来可能并不值钱，而用户的时间很值钱。

3.4 寻找解决服务代价问题的方案

产品简单、易用，用户不会犯错。

• 路线选择带来的服务代价问题？

1. 通用型系统开发难点： 设计难度相对较大，系统成型慢，业务价值产出的压力很大。
   • 前期妥善沟通方案，“通用+适度”定制，快速推进平台的构建。
2. 组件服务式系统的挑战（相对于一站到底的垂直系统）：各个系统之间的依赖关系相对复杂，迭代演进的时候负担很大。
   • 各个服务组件模块化、提供所依赖功能的插件封装机制
   • 具备灰度发布能力
3. 通用平台的痛点：对具体业务场景定制程度较低、整体易用性相对较差、使用成本较高。
   • 便捷和通用是矛盾的。
   • 基线+定制，带来的问题是需要维护多个版本，以前华为的一些软件业务线就是这么干的。

• 如何降低服务自身的代价？

1. 由俭入奢易，由奢入俭难。用户对服务质量的要求只会越来越高。

   • QOS约定，用户预期管理。统一认知
   • 向用户提供：产品定义、路线计划、已知问题列表、最佳实践、FAQ等文档，可参考阿里云以及其他开源、商业软件。让用户提前知道服务的能力范围，沟通或许更顺畅。

2. 服务口碑取决于服务最差的环节。木桶效应

   • 管理好用户的预期和引导用户。
   • 少纠结过去、多放眼未来。

3. 服务越多，支持的代价越高

   • 运维手段工具化、最佳实践文档化。
   • 专家系统：帮助缺乏经验的用户发现和诊断问题。

4. 需求响应要疾如闪电，功能服务要天长地久。快速迭代和稳定可靠是必然矛盾的。

   • 定期更新
   • 变更提前和用户沟通
   • 灰度发布和回滚方案

5. 既要马儿驼得多，又要马儿不摔倒

   • 预期管理之向上管理

6. 用户的服务诉求各异，众口难调。作为服务提供方，我们的时间在用户看来可能并不值钱，而用户的时间很值钱。

   • 本质上一致：让用户更好的使用大数据平台。
   • 实现过程如何兼顾，是挑战。寻找妥协点。

3.5 平台的产品化思想

功能和服务做得好，还要考虑代价和收益。

3.5.1 从用户体验角度谈产品设计

1. 别让用户有挫败感。从小白角度去设计，比如数据采集。
2. 提供差异化、阶梯化的产品服务。有这么多子系统，也可以设计一个简化的、包含各个子系统功能的定制产品，帮助快速入手。
3. 构建反馈式的产品服务。但凡用户做了一个动作，或者一件事情状态发生了变化，要想办法让用户得到及时的信息反馈。
4. 确保产品实现可持续改进。用户的使用情况不能是黑盒，否则无法改进产品。
   1. 性能监控
   2. 行为监控：通过埋点
   3. 日志分析：

3.5.2 从价值和利益的角度谈产品思维

To be or not to be, that is a question.

• 不同的层次

1. 是什么、怎么做、能不能做
2. 这么做是为什么
3. 为什么一定要这么做、有没有别的解决方案
4. 这么做值得吗、做点别的事是不是收益更高

小结

大数据平台的建设属于费力不讨好的事情，属于看不见摸不着的事情，需要从顶层来考虑平台的建设，需要平台的开发人员沉下心、耐住性子，脚踏实地、一点点完善平台的功能，利用当前的资源产生最大化的平台价值。

参考文献

• 《大数据平台基础架构指南》读书笔记