大数据平台 - 整体建设思想

大数据平台 - 整体建设思想

大数据平台整体建设思想

• 目标
  • 为使用平台的用户解决了哪些问题，扫除了哪些障碍，提升了多少工作效率，附加了哪些增值收益
  • 内部组件的横向联通能力
  • 业务流程上纵向贯穿打通上下游链路的能力
• 建设指导方针
  • 组件工具化
  • 工具平台化
  • 平台服务化：平台提供的内容是不是用户最终想要的东西？重点是用户体验是否够好，用户满意才是衡量服务水平的唯一标准
  • 平台产品化：需要根据公司的业务发展阶段，对现实中的各种问题进行评估、妥协和取舍。
• 建设思路
  • 垂直业务领域一站到底的建设方式
    • 优点
      • 和具体业务结合紧密，产品逻辑可以高度定制，可以做到最大限度地匹配业务的需求
      • 产品的交互流程、架构复杂度相对可控，同时可以尽可能地屏蔽与具体业务无关的内容，确保易用性
      • 无须太考虑通用性问题，也不用太考虑业务之间的兼容性，整体产品架构成型快，演进负担小
    • 缺点
      • 系统专用性较强，可拓展性差
      • 放到多个部门，从业务的维度来看，系统之间可能缺乏考虑，存在大量重复建设的工作
  • 通用组件建设，组合支持业务的方式
    • 优点
      • 针对抽象的通用功能需求，可扩展性较好
      • 能够减少各业务系统之前的重复建设
      • 各系统设计和架构方案有机会做得更加深入、完善和稳定
    • 缺点
      • 需求考虑通用性，设计难度较大，系统架构成型较慢
      • 各系统之间依赖相对较多，迭代演进负担较大
      • 对具体业务场景定制成都较低，整体易用性相对较差，使用成本较高
      • 团队承受压力大，公司只关心最终的价值输出

服务意识和产品思想的培养

• 大数据平台服务能力的评估标准
  • 大数据平台团队的职能定位
    • 在有些公司，只负责基础组件的开发和运维，为业务方提供SDK、组件套餐或集群形式的服务
    • 在有些公司，基础组件之上的工具、平台等，都由专门的工具团队负责，层层分工，团队之间较差服务。
    • 在有些公司，不同事业部团队会自行在基础平台组件之上，各自垂直地构建独立的业务系统，平台基础组件开发者服务与上层业务系统开发人员
    • 在有些公司，大数据团队从下到上全链路通吃，从集群运维一直负责到最终具体终端业务数据的产出，对终端使用数据的用户负责
  • 打通上下游系统和业务流程的能力
    • 后端集群流量／负载的反馈控制能力 。
    • 和脚本集成开发环境的对接。
    • 和权限系统、数据订阅管理体系的连通。
    • 和元数据血缘分析系统的对接。
    • 和任务测试/发布环境的对接
    • 与报警、值班、监控系统的协同
    • 和其他非大数据类业务自身的工作流管理体系的联通能力
    • 和数据质量管理系统的系统能力

服务意识和产品思想的培养 — 满足用户真正的需求

• 用户需要的是稳定、可靠、高效地存储数据，只要满足性能指标，他们其实并不关心底层使用的是hdfs、HBASE，还是你自己研发的分布式存储系统
• 用户关心的是高效低成本的开发业务，钻研和学习各类计算框架并不是他们的初衷
• 用户在意的是方便、快速地查询到想要的数据，结果便于理解和沟通，能够有效地支持业务决策。

服务意识和产品思想的培养 — 认清服务的代价，做好心理建设

• 由俭入奢易，由奢入俭难
  • 首先，你要明确你所提供的服务的范围定义和质量约 定 。
  • 然后，要尽早和用户达成一致 。 如果可以，对用户使用对应服务时应该承 担的责任，也需要提前明确进行沟通。 作为乙方，这有时候可能很难做到，但 必须要往这个方向去做 。 这么做，不是单纯地为了降低用户的期望值，而是为 了统一认知一一凡事不怕标准高，就怕标准不一致 。
  • 作为服务提供方，需要明确地告知用户，你所提供的服务能做 什么、不能做什么、将来的计划是什么、用户在使用过程中需要注意什么，甚至可以包括用户对我们的承诺和应尽的责任 。 如果用户在使用你的服务之前或 过程中明确知道这些信息，那么与用户的沟通过程或许就会顺畅很多。
• 服务口碑取决于服务最差的环节
  • 注意管理好用户期望和 引导用户，不要盲目地被用户牵着鼻子走。至于最终的口碑，由它去 吧 ，那不 属于你可以随意控制的范围。
• 服务越多支持的代价越高1. 一个系统服务难免会有 Bug， 也总会有不够灵活的地方 ，提供的服务越多 越全面， 日常维护的代价就越高 。
  • 用户在使用服务的过程中遇到的问题，很多时候未必是系统自身逻辑的问 题，也可能是使用姿势问题、业务逻辑问题等 。
  • 事实上，在多数情况下，不是用户懒，而是他们不具备解决问题的能力， 没有足够的知识储备。又或者即使他们具备相关的知识能力，也可能在出现问 题时，因缺乏明确的故障反馈、无法查看问题日志、没有性能数据、缺乏修复 的手段等各种原因，而不得不依赖服务开发者来帮忙定位和解决。
  • 我们需要考虑将运维手段工具化、 最佳实践文档化，降低用户自主定位和解决问题的难度：更理想的做法是可以通过构建一个专家系统来帮助 缺乏经验的用户发现和诊断问题。
• 需求响应要疾如闪电，功能服务要天长地久1. 需求快速响应，功能长久不变
  • 如果可能，制订班车式开发计划，按固定的周期和预订的计划更新系统和服务 ， 如非特别必要，不做计划外临时更新 。
  • 进行服务变更和系统更新迭代等时提前和用户沟通， 就可能造成的影 响明确告知，宁滥勿缺 。这本质 上还是一个用户预期管理的 问题。
  • 对用户可能造成较大影响的变更，确保你有灰度发布和回滚的方案。
• 既要马儿驼得多，还要马儿不摔倒1. 系统稳定和需求快速响应的矛盾
  • 这同样是一个预期管理的沟通问题，也叫向上管理，只不过面向 的对象是 老板。
  • 我个人还是倾向于要坚持特定的原则一－把团队的利益放在自身利益之 上。 如果有压力 ， 不要简单地做二传手向下传递压力，别把问题和责任抛给团 队， 而是面对问题，把目标和方案抛给团队。另外，遇到难题时，还要适当反 馈客观存在的困难，比如：“老板，招不到人啊，这活没法干”之类 的 。总之， 不求老板舒坦，但求问心无愧 。
• 用户的服务诉求各异，众口难调1. 不同的需求之间互相矛盾
  • 凡事可以坚持原则 ，但是没有必要苛求立场。
  • 需要多动脑筋，多沟通，多讲道理。没有必要追求大家对所 有工作真心赞同，而是要求同存异，解决核心矛盾，寻找一个双方都可以接受 的妥协点。这个妥协点一定存在，如果没找到，不是方案还不够好，还有改进 的空间，就是沟通不充分，道理没有讲明白。
  • 服务从来都不是一件单向承诺 的事情。选择什么样的路线，以什么样的方 式对待大数据平台的用户，遇到问题时如何解决，其实都是可以选择的。关 键是作为开发者，需要明确自己所做的每一个选择的理由，积极地面对问题， 关注解决方案，并与用户保持紧密联系，积极沟通，争取得到用户的理解和 支持。
• 提供服务那么难，为什么我们还要做

服务意识和产品思想的培养 — 寻找解决服务代价问题的方案

• 首先，系统组件设计，需要考虑通用性，设计难度相对较大，系统成型比较慢，业务价值产出的压力很大。
  • 在开发之初，也需要面向一个具 体的业务，最好上线之初就带上一个真实 的业务 。
  • 带着具体业务的痛点问题来做开发，在此基础上考虑如 何构建通用的解决方案来适配其他业务。采用“通用＋适度”定制的方式快速推 进平台的构建，不怕做得不够通用，就怕通用到过于抽象，没有业务可以快速 适配 。
• 其次，相对于一站到底的垂直系统，在组件服务式构建的系统中，各个系 统之间的依赖关系相对复杂，选代演进的时候负担较大。
  • 适度地拆分服务，做到松辑合强内聚， 一定是服务建设的首要 目标。
  • 要尽量考虑保障系统具备灰度发布的能力，组件依赖多 ，出问题难 以避免； 关联系统多 ， 系统更新可能也无法一蹦而就，那就需要尽可能降低变 更过程的风险，用灰度的方法去做局部验证，控制风险范围，知错就改，别做 一锤子买卖。
  • 敏捷开发的目标就是不做过度设计， 而是按需快速构建系统 。但要平衡好设计 、实现和重构的代价。
    • 我们能做的就 是做好各个服务组件的模块化工作，提供所依赖功能的插件封装机制，适当考 虑向后兼容的可能性，以及降低系统的祸合度。
    • 不只是代码 的精合，硬编码依赖系统的地址之类问题无疑应该避免，更难的是要避免业务逻辑流程上的过度搞合。
• 最后，对具体业务场景定制程度较低，整体易用性相对较差，使用成本 较高。
  • 对于一个 通用平台，或者不能满足业务方的定制需求，被业务方抱怨流程长、操作复杂、 交互不友好、开发效率低 ；
  • 或者把各种需求都集成进来 ，但是一堆旨在提供便 捷的功能反而很容易让系统变得更加复杂，最终的结果就是导致整个系统瞬肿 不堪 。
  • 这个问题更多时候无关服务，而是一个产品设计问题，不过从服务路线 的角度来说，一种可行的方式是针对具体业务的 场景需求，在通用服务的基础上二次垂直封装，适度定制和简化业务流程。从 通用服务衍生出 专用服务，来屏蔽和特定业务场景无关的系统复杂性。不过代 价当然也是有的，那就是你又多了一个系统，又多了 一层依赖关系需要维护。

服务意识和产品思想的培养 — 大数据平台的产品化思想

• 概述
  • 服务化的本质思想是帮用户解决问题 ， 是"为人民服务"的态度在你的平台中的具体化体现。
  • 产品化，关注的重点是大数据平台所提供的服务的具体内容是什么， 展现形式如何，能不能吸引用户 。 再说得直白一点 ： 有没有价值，或者说作为 商品，我们提供的服务能否卖得动，能否赚钱？
• 从用户体验的角度谈产品设计
  • 核心思想
    • 别让用户有挫败感
    • 提供差异化、阶梯式的产 品服务
    • 构建反馈式的产 品服务
    • 确保你的产品具备可持续改进的能力
  • 你爱用户， 用户却不爱你问题的重 点是 ： 别让新用户有挫败感 ！ 至少， 在他尝到甜头之前不要有挫败感。比如说文档对于小白来说，不具有可操作性
    • 不要认为用户和开发者一样具备所有的背景知识， 用户的环境设定和你的一致 ，想要更好地减少用户的挫败感，一个小白用户的角度，完整地去体验自 己的产 品和服务 ，发现和思考需要改进的地方。
  • 提供差异化、阶梯式的产品服务用户的需求是多样化的， 能吸引用户群体 A 的产品， 未必能满足用户群体 B 的 需求， 比如让熟练的专家级用户满意的产品设计， 对于刚入 门的小白用户来说， 学习门槛可能就会太高 。甚至 同样的用 户 ， 求也可能是不同的 。
    • 要么针对用户各自的诉求， 提供差异化的服务 ；
    • 要 么根据用户不同的知识背景， 提供抽象程度不同的服务， 不要企图用同一个产品覆盖所有需求。
    • 提供简易操作版和深度定制版
  • 构建反馈式服务
    • 比起响应迟钝的系统，更让人崩溃的是完全没有响应的系统。至于以什么样的形式反馈给用户 ， 是界面变化、弹窗提示、引 导查询、定时提醒，还是放在一个角落让用户自己发现，这就要因地制宣了 。
  • 确保产品实现可持续改进
    • 要确保产品可持续改进，收集用户意见固然重要，但这往往是不够的。你 需要主动收集产品使用过程中的相关数据和信息，除了 一些客观指标，比如运 行／加载／响应时间、服务负载、流量 QPS 、错误统计，还可以包括系统交互是否 流畅、哪里用户容易犯错、哪里容易导致用户流失，以及用户访问频率和复用 率之类的数据 。
• 从价值和利益的角 度谈产品思维