论“跪舔式”构建“服务化”数据平台的崇高理想

云器科技

于 2023-03-30 14:50:17 发布

阅读量146

点赞数

文章标签：大数据

原文链接：https://blog.csdn.net/colorant/article/details/73168122

版权

前文中（链接👉为建设四个现代化的大数据平台奋斗终身）我们谈到，在构建数据平台的过程中，我们要坚持四个现代化，其中平台服务化是关键指导思想之一，而用户满意是衡量服务水平的唯一标准。

那么这篇，让我来具体谈谈如何为人民服务。

什么是服务？

首先，什么是服务？我们辛辛苦苦提供了稳定的Hadoop集群给业务方用，是服务么？我们开发了高性能的ETL工具，是服务么？我们把元数据血缘关系都收集，分析，展现出来了，是服务么？我们提供了任务调度的方式手段，是服务么？

其实，这个问题，没有标准答案，是不是服务，取决于你所服务的对象。你所提供的内容，是不是对方最终想要的东西？好比我想享受一顿美食，你给我一条活蹦乱跳的澳洲龙虾，一个设备齐全的厨房，甚至还有一本澳龙烹饪指南。不是不可以，但可能并不是大多数人所期望的服务。但如果我是想学习烹饪，那这种服务就再理想不过了。

所以，要谈服务，首先得谈你怎么定位大数据平台的职能范围和服务对象。很不幸，这也不是一个有标准答案的问题。

有些公司，大数据团队只负责基础组件的开发和运维，业务方裸用系统。有些公司，基础组件之上的工具，平台等等，都由专门的工具团队负责。有些公司，不同的事业部团队会自行在基础组件之上，各自构建自己的系统。还有些公司，大数据团队从下到上，链路通吃，从集群运维一直负责到最终具体终端业务数据的产出。

但不管怎么划分，我想，相关系统所依赖的人力、资源和技能的内聚应该都是最重要的划分考量因素。对于多数公司来说，相关系统和具体的特定业务知识是否有强关联，会是一个比较合理的划分参考依据。

凡是没有业务强关联的，而对大数据相关基础知识或生态依赖又较大的系统，可能由大数据平台相关团队统一来构建会比较合适。反之，往具体终端业务产品拓展衍生的程度，就要看各公司大数据团队自己的实际情况和业务团队的能力了。

而评估数据平台的服务能力，除了客户满意这个主观标准，另一个偏客观一点的标准可以是：贯穿打通上下游和周边业务的能力，打通的越彻底，平台的服务能力基本上就越强。

比如你开发一个调度系统，系统自身的能力，大家都知道：时间／依赖触发，任务计划，执行流水，出错重试，支持的任务类型等等。

那么上下游和周边业务关系包括什么呢？比如：

后端集群流量／负载的反馈控制能力
和脚本开发环境的集成对接
和权限系统，任务，脚本订阅管理体系的连通
和元数据血缘分析管理系统的对接
和任务测试／发布环境的对接
与报警，值班，监控系统的协同
和其它非大数据类业务自己的工作流体系串联
与数据质量监控系统的协同

类似的能力，还可以列举很多，很明显，上述能力越完备，调度系统的服务水平很可能就越高。但值得注意的是，能力并不等同于服务，还要看它对用户的价值，这点我们后面再详述。

下面，基于这样的定位来讨论大数据平台团队所提供的服务。

数据平台的用户需要什么服务？

所以，用户需要的是什么服务？按照我们服务的用户定位，用户需要的不是一个个具体的组件，用户需要的服务往简单来归纳，很明显，就是三类：

存储
计算
查询（展示）

至于为了更好的支持这三类服务，不论是存储计算的具体组件hdfs／hbase／hive／spark／storm／flink，还是你所需要工作流调度，权限管控，元数据血缘分析，质量监控等等各类支撑和监管系统，都是手段而已。并不是说他们不重要，或者用户不需要关心，而是说从用户的角度来说，并不是他们诉求的出发点。

用户需要的是稳定可靠高效的存储数据，只要满足性能指标，他们其实并不想关心底层使用的具体组件。

用户关心的是高效低成本的开发业务，钻研和学习各类计算框架，并不是他们的初衷。

用户在意的是方便快速的查询到想要的数据，结果便于理解和沟通，能够有效的支持业务决策。数据存储在哪里，用什么工具查询，需要做什么预处理，是否需要缓存优化，这些能不考虑最好不过。

当然，从业务开发的角度来说，可能对底层系统理解得越多，开发使用起来就会越顺手，但从数据平台服务构建的目标来说，服务的价值，就在于能在多大程度上减少使用方对底层系统了解的必要性，降低业务开发的门槛。而不是仅仅提供组件或者孤立的系统，把组件选型评估，流程串接，方案构建的工作交给业务方去考虑。

如何构建数据平台服务？

如果你有无限的时间和无敌的能力，那么这个问题不是问题，大无畏的去构建就是了。

但现实情况是你的时间是有限的，你的能力和经验也是有限的，而数据平台所需要的服务，几乎是无限的。

所以，大体看来，我觉得平台服务的构建，可以分为两种方式：

第一种方式，是针对具体的业务场景，针对性的开发，一站到底式的支持。

优点：

和业务结合紧密，产品逻辑可以高度定制，最大程度匹配业务需求。
流程复杂度相对可控，可以尽可能屏蔽与具体业务无关的内容，确保易用性。
无需太多考虑通用性问题，系统架构成型快，演进负担小。

缺点：

系统专用性较强，可拓展性差。
放到多个部门，业务的维度来看，系统之间可能缺乏统筹考虑，存在大量重复建设的工作。

比较典型的，如果是业务导向的部门来构建的系统，基本是这样的。比如广告部门要做数据分析业务，那他一定不会优先考虑数据模型的通用性，多租户权限管控之类的东西，高度定制化的流程及时产出正确的计费数据和投放策略才是最核心的内容。

还有一种情况，是各个集团部门间存在一些竞争关系，或者不满意基础架构团队提供的服务，所有的东西宁愿自己搞一套。

第二种方式：是针对抽象通用的功能需求，分别构建独立的系统，通过各个系统的叠加配合完成对业务场景的支持。

优点：

针对抽象通用的功能需求，可拓展性较好。
能够减少各业务系统的重复建设。
各系统设计和架构方案有机会能够做到更加深入，完善。

缺点：

需要考虑通用性，设计难度较大，系统架构成型较慢。
各系统之间依赖较多（相对），迭代演进负担较大。
对具体业务场景定制程度较低，整体易用性相对较差，使用成本较高。

比较典型的，如果是非业务导向的部门来构建的系统，往往是这样的。

还有一种情况是，基础部门没有自下而上的完整链路的掌控权，那么也可能是基于自己的业务范围，构建一些相对独立的功能模块和系统。又或者是系统的演进，是从工具向平台演变的一个过程，也很自然的是从局部向整体拓展。

两种方式没有绝对对错之分，取决于各公司，团队，部门具体的实际情况。

但无论使用哪种方式，都需要考虑，如何尽可能扬长避短，或者采取必要的手段去弥补缺点。

比如我司（老东家“蘑菇街”）之前的北京分舵，技术方案融合前，北京分舵的数据平台基本就是按照业务定制的原则来开发，在具体某类定制化的业务开发流程方面，客观的说，易用性就比我们杭州分舵的平台要好很多，用户口碑不错。但带来的问题就是，不同的业务和产品线实现类似的功能，各有一套体系，比如调度系统就有独立的三套。各类业务之间基本没有打通的可能性，维护成本也很高，技术迭代困难。

我司当时的数据平台服务，是采用第二种方式来演进的：

2014年左右

我们的基本情况是只有最基本的功能组件，包括：定时轮询的调度系统，hive集成开发平台，定制的报表系统，简单的权限系统，使用Storm开发基本的实时计算业务等。

2015年左右

我们开始添加更多的功能组件，Spark计算框架的引入，元数据管理系统的开发，自定义查询系统的开发，Storm代码开始模块化构建，全站用户页面行为跟踪埋点体系的构建，以及一些底层系统整理改造工作，包括公司内部底层多个集群的整合，改造，升级。数据平台各业务后台权限管理的统一，报警服务系统的拆分构建等等。

这里面有经验收获也有历史教训。

教训是，整个15年，做了大量的稳定性改进，模块拆分，组件完善，集群融合，升级等工作，在一定程度上完善了数据平台的体系架构，降低了维护代价，提升了稳定性。这固然给平台发展打下了基础，但是，从业务价值产出的角度来说，并不明显，相对零散，对业务方来说，没有从数据平台地改进工作中得到显著的收益。团队的压力较大（绩效方面）。

从领导和业务方的角度来说，不要跟我说你们做了什么，告诉我对公司有什么价值？

回过头来看，应该在业务导向方面，多做一些思考和工作，避免冰山下的工作不能给团队带来实际的价值回报，所以16年的工作在核心系统改造的基础上，开始加入更多的围绕终端服务价值产出的内容。

2016年

开始重构部分核心组件，和推进整体平台服务化的进程，包括权限系统的服务化，构建对象存储系统，完成了核心调度系统重构，完成了数据可视化平台核心功能的构建，实时计算平台构建，数据交换链路服务化，常态化业务数据大屏构建，数据质量系统的构建，开始集群配置管控平台的构建。

整体来说，一方面是内部系统的服务化，比如RBAC的权限系统，用来服务所有的业务和数据后台，比如通用对象存储服务，用来支持其它各类有通用存储需求的系统，比如简历招聘系统，小图片存储系统。

另一方面是针对数据开发用户或者终端数据使用用户的服务，整体的目标是降低各项业务开发的难度，让用户能够更加独立自主地进行自我服务，减少需要平台定向支持的需求，比如通过可视化平台让用户以配置的方式完成数据图表的自主开发。

2017年～

2017年目标是傻瓜化服务平台的构建，各种自助服务功能的完善，端到端整体链路服务的打通，专家系统的构建，进一步降低服务支持的代价，实现世界和平，人类大同。（淡定，只是愿景，愿景...）

回头小结

即使放在我司，回过头来看，也不能说第二种方式：通用组件->平台融合就是最合理的方案，事实上对一个特定的具体用户来说，第一种定制开发的方案可能才是他最欢迎的，毕竟，急他所急嘛，客观上来说，短期的收益也可能是最明显的。

所以，有时候，局部做一些妥协，可能也是你生存下去的合理举动。人生，不就是在各种利益抉择中度过的么？

凡事都有代价，不要太天真？

所以，这样去做就好了么？用户就会跪下来感谢你了么？你的工作生活从此就阳光快乐了么？Naive！

事实上，自打你心里打定主意，走上这条又红又专的服务化之路的那天起，你就走上了一条不归路......

很快，你就会发现：

由俭入奢易，由奢入俭！

用户对服务质量的要求，只会越来越高！
每每有其它公司数据团队告诉我，他们的用户运行任务遇到问题，都自行了断，他们都不值班，用户出问题，分析到原因才找他们时，我都会流下嫉妒而又悔恨的泪水......

你的服务口碑，取决于你服务最差的那个环节。

可恨的水桶效应，当你尽心尽力还是被人骂的时候，有没有六月飞雪的感觉呢？
不过，这也是人之常情了，就好比悲剧总是比喜剧隽永，痛苦永远比快乐来得持久。

服务越多，支持的代价越高。

以我们的开发能力，做个服务，总会有BUG，总会有不够灵活的地方，可是谁让你揽过这摊事呢？

用户：既要疾如闪电，还要天长地久！

用户的需求你一定要快速响应，这个界面交互不爽，那个API不够便利，只要用户发起变更需求，你就得赶紧搞定不是，否则不重视用户这个大棒子就砸脑门上了，赶紧赔不是去。
但是你发起的变更呢，那一定是私生子啊，待遇低下，注定招人白眼。我去，这个Button昨天还在这呢，今天怎么找不到了？什么？要改API，你丫之前咋不设计好呢？！操作流程变了，咋不提前通知呢？啥，通知过了？没看到，这么重要咋不直接找我沟通呢？
好吧，对于这两个标准的问题，不要抵抗，都是用户对，做好心理准备，陪个笑脸，想想怎么解决具体问题，更容易一些。

老板：既要马儿驼得多，还要马儿不摔倒！

老板语重心长的告诉你，要服务好客户啊！业务第一知道么？这个工作，你敢告诉我你不接，不想混了？对了，还有那个，别和他们争了，做掉就好了......
然后有一天，诶，怎么出了个故障？净给我找事，能梳理一下问题，保证一下稳定性么，稳定第一你不知道么？！
后来又有一天老板问你：最近没什么故障，不错，不过，今年你们好像没有什么产品成果啊，都在做什么呢，有没有一点价值导向的思想啊？你这样不行啊......361绩效？本来想给1+的，看你干得辛苦，给个6-部分不满足需求鼓励一下吧......

（以上情节，纯属虚构，请勿对号入座。但说实话，老板，都是对的！）

用户的诉求和你的诉求，经常是冲突的，哪怕你的出发点是：你好，我好，大家好。

你要数据安全，用户想要方便：我不就查个表么，申请权限还找不到owner审批，影响效率啊！我没分析出数据，明天GMV跌了你负得起这个责任么！（用户A：我去，谁drop了我的表？？你们平台太不靠谱了，权限也不控制？）
你想提高集群服务性能，敦促大家优化脚本，用户告诉你，没空！怎么滴吧？（用户B：我去，今天跑任务怎么这么慢？让不让我干活了？）
你的时间不值钱，哪怕它本来可以用来解决更多的问题。用户的时间最值钱，哪怕花一点时间可以克服的麻烦，也会来挑战你，为什么不能做得完善一点，再完善一点，更完善一点？（用户C：诶，搞啥呢，一个功能拖那么久？信不信我告你老板去！）

最后，上述问题，基于用户满意是唯一衡量标准这条公理，最后一定可以推导出都是你的问题，谁叫你是服务提供者呢？有本事你去做甲方去啊。没有被鞭的觉悟，就不要趟这个浑水了。挣，还是不挣，问题都在那里，还是多花点时间想想如何更好的解决吧。