大数据平台的建设之路漫长、艰难，所以需要统一认知，达成一致的建设思想和目标；进行心理建设，让大家做好充分的心理准备；充分认识平台的特点，有正确的的产品和服务意识。
1. 初心、源动力
大家以前从事web开发或者学习web开发，使用的技术栈是servlet+jsp+tomcat，现在流行springboot+vue.js，为什么会这样？
由于软件工程的复用思想，大量重复的、通用的工作，我们都将其抽象出来，变成了通用开发组件、框架。
大数据技术在一个团队或者一个公司应用到一定阶段，必然进入到平台阶段。因为可以对一些组件进行封装、工具化，提高代码复用和开发效率等。对内可以给内部开发团队使用，对外可以给第三方组织开放大数据服务和能力。
2. 统一平台的整体建设思路和目标
平台建设需要培养跳出现象看本质的习惯和思维。要结合实际的业务场景和用户需求，不仅从技术架构，更要从代价、收益、业务价值、易用性和可维护性等众多角度进行综合评估和取舍。
2.1 what?
大数据相关业务开发平台，是给数据使用者提高方便的平台、工具。
数据使用者包括：数据分析人员、数据管理人员、数据开发人员、数据运维人员等，不同角色对于平台的需求是不一样的。
数据分析人员需要元数据管理、BI自助分析、可视化展示等功能。
数据管理人员需要进行数据资产管理、数据治理等。
数据开发人员在数据分析的基础手上，还需要数据集成开发环境、工作流调度等，很多公司内部的平台纯粹为了开发者使用。
数据运维人员要进行集群的搭建、运维等工作，由于有了Cloudera、Hortonworks的Hadoop套件，很少有公司强调这方面的平台组件管理工具。
2.2 target?
大数据平台的目标是方便使用者，提升工作效率，实际产出了多少价值，降低平台开发人员运维成本。
目前各家公司使用大数据技术的现状：组件与大公司相比一个都不少，但是平台的实际应用水平和所提供的服务时，这些平台往往是极度原始和简陋。
与大公司平台成熟度的差距在哪里？
产品和服务形态。
比如小米与苹果的差距？硬件差距相对没那么多，小米总是使用业界最先进的硬件，毛利率极低，更多的是软实力的差距。
如何扬长避短：组件的深度、新技术的探索确实无法跟大公司比，但本质的东西：平台的价值、投入产出效益，产品和服务形态，可以跟其他公司対飚。特别是阿里云，他为了做到通用性，就没办法照顾不同行业、不同层次用户的诉求。垂直领域的一些诉求，相对比较通用，相对可以从产品和服务形态与其竞争，特别是当市场规模没那么大时，往往是大公司忽略的地方。如抖音、快手，如拼多多、融360，并不是与BAT比拼技术能力，也是在比拼产品与服务能力。小公司在组件的使用上，并不会比大公司有那么大的差距，像阿里云专家对于多维分析，也没有更好的解决方案。
- 平台为用户
- 解决了哪些问题？
- 扫除了哪些障碍？
- 提升了多少工作效率？
- 产生了哪些附加价值？或者实际产出的价值？投入产出效益？
- 更深层次
- 平台内部组件的横向联通能力
- 业务流程上纵向贯穿打通上下游链路的能力
2.3 建设指导方针：四化建设
- 组件工具化：组件维护、用户应用开发
- SDK：权限控制、操作数据采集、流量监控、屏蔽一些高风险操作、简化一些用户的操作(kafka消费者中的偏移量)
- HBase SQL(Phoenix)
尽量给用户提供统一sql引擎
提供一些工具将这些组件、操作封装起来。不仅仅是为了降低用户的学习成本，也有助于屏蔽集群的拓扑布局、业务操作的命令细节、组件版本的兼容性问题等。
- 工具平台化：组件、工具、开发流程整合在一起，统一管理，提供成体系的开发运维管理途径。
通过规范开发流程，提高平台整体的稳定性和可控性，进而提升运维和业务开发的效率。
哪些是可以做、应该做也值得做的事情。
平台服务化：用户想要的东西，以用户体验为中心。用户满意是衡量服务水平的唯一标准。.
- 平台产品化
- 困境：
- 公司角度：团队资源的投入产出比，对公司业务价值的产出贡献。
- 团队角度：做得越多错得越多，服务越好负担越重。
- 如何破？良好的产品形态来换取可衡量的价值产出才能打破。
- 困境：
- 平台的适用性：产品定位、服务对象、聚焦核心问题。
- 阿里云的EMR，面向小白用户，功能简单。
- 企业内部业务开发团队，业务需求更复杂。
- 一站到底 vs 通用组件建设、组合支持业务
在各种取舍、抉择中度过，可能需要两种方式结合。
3. 开发者如何培养正确的产品和服务意识
3.1 平台服务能力的评估标准
对用户产生价值。
用户满意、易用、可用、简单、傻瓜。
- 职能定位？平台+数据处理、上下游全链路通吃。
- 划分依据：相关系统和特定业务知识是否强关联。
- 能力？打通上下游系统和业务流程。
- 以工作流调度系统为例，从触发作业运行的角度，调度系统自身的能力包括：各种任务类型的支持、时间/依赖触发能力的支持、任务计划的编排管理能力、对任务执行流水、历史记录的管理。
- 和上下游及周边业务流程的相关能力：
- 后端集群流量、负载的反馈控制能力
- 脚本集成开发环境的对接
- 与权限系统、数据订阅系统的连通
- 和元数据系统的对接
- 与任务测试、发布环境的对接
- 与报警、值班、监控系统的协同
- 和数据治理管理系统的协同
3.2 满足用户的真正需求
- 提供（大）数据处理能力，一站式解决方案，核心服务：
- 存储
- 计算
- 展示
用户并不关心具体的集群、组件。
- 用户在意：
- 高效、稳定、可靠的存储，满足性能指标。底层存储并不关心。
- 高效低成本的开发业务。不太想钻研各种计算框架
- 方便、快速的查询，结果便于理解和沟通，能够有效地支持业务决策。
在满足性能指标的前提下，尽可能简单、方便、易用，得到想要的数据。
对于中小企业来说，根据业务场景，提供简单、易行的解决方案，最起码是封装好的工具。
对于第三方用户，主要诉求是帮助挖掘数据价值。
3.3 认清服务的代价，做好心理建设
- 提供服务这么难，为什么我们还要做？
基于用户满意是评判服务水平的唯一标准。在提供服务时，要有卧薪尝胆的精神。- 由俭入奢易，由奢入俭难。用户对服务质量的要求只会越来越高。
- 服务口碑取决于服务最差的环节。木桶效应
- 服务越多，支持的代价越高
- 需求响应要疾如闪电，功能服务要天长地久。
- 既要马儿驼得多，又要马儿不摔倒
- 用户的服务诉求各异，众口难调。作为服务提供方，我们的时间在用户看来可能并不值钱，而用户的时间很值钱。
3.4 寻找解决服务代价问题的方案
产品简单、易用，用户不会犯错。
- 路线选择带来的服务代价问题？
- 通用型系统开发难点： 设计难度相对较大，系统成型慢，业务价值产出的压力很大。
- 前期妥善沟通方案，“通用+适度”定制，快速推进平台的构建。
- 组件服务式系统的挑战（相对于一站到底的垂直系统）：各个系统之间的依赖关系相对复杂，迭代演进的时候负担很大。
- 各个服务组件模块化、提供所依赖功能的插件封装机制
- 具备灰度发布能力
- 通用平台的痛点：对具体业务场景定制程度较低、整体易用性相对较差、使用成本较高。
- 便捷和通用是矛盾的。
- 基线+定制，带来的问题是需要维护多个版本，以前华为的一些软件业务线就是这么干的。
- 如何降低服务自身的代价？
- 由俭入奢易，由奢入俭难。用户对服务质量的要求只会越来越高。
- QOS约定，用户预期管理。统一认知
- 向用户提供：产品定义、路线计划、已知问题列表、最佳实践、FAQ等文档，可参考阿里云以及其他开源、商业软件。让用户提前知道服务的能力范围，沟通或许更顺畅。
- 服务口碑取决于服务最差的环节。木桶效应
- 管理好用户的预期和引导用户。
- 少纠结过去、多放眼未来。
- 服务越多，支持的代价越高
- 运维手段工具化、最佳实践文档化。
- 专家系统：帮助缺乏经验的用户发现和诊断问题。
- 需求响应要疾如闪电，功能服务要天长地久。快速迭代和稳定可靠是必然矛盾的。
- 定期更新
- 变更提前和用户沟通
- 灰度发布和回滚方案
- 既要马儿驼得多，又要马儿不摔倒
- 预期管理之向上管理
- 用户的服务诉求各异，众口难调。作为服务提供方，我们的时间在用户看来可能并不值钱，而用户的时间很值钱。
- 本质上一致：让用户更好的使用大数据平台。
- 实现过程如何兼顾，是挑战。寻找妥协点。
3.5 平台的产品化思想
功能和服务做得好，还要考虑代价和收益。
3.5.1 从用户体验角度谈产品设计
- 别让用户有挫败感。从小白角度去设计，比如数据采集。
- 提供差异化、阶梯化的产品服务。有这么多子系统，也可以设计一个简化的、包含各个子系统功能的定制产品，帮助快速入手。
- 构建反馈式的产品服务。但凡用户做了一个动作，或者一件事情状态发生了变化，要想办法让用户得到及时的信息反馈。
- 确保产品实现可持续改进。用户的使用情况不能是黑盒，否则无法改进产品。
- 性能监控
- 行为监控：通过埋点
- 日志分析：
3.5.2 从价值和利益的角度谈产品思维
To be or not to be, that is a question.
- 不同的层次
- 是什么、怎么做、能不能做
- 这么做是为什么
- 为什么一定要这么做、有没有别的解决方案
- 这么做值得吗、做点别的事是不是收益更高
小结
大数据平台的建设属于费力不讨好的事情，属于看不见摸不着的事情，需要从顶层来考虑平台的建设，需要平台的开发人员沉下心、耐住性子，脚踏实地、一点点完善平台的功能，利用当前的资源产生最大化的平台价值。
参考文献
- 《大数据平台基础架构指南》读书笔记