关于三年大数据平台的工作
发布时间:在数据驱动企业发展的背景下，随着企业演化，不知不觉成为了一名不那么合格的数据开发。 数据开发是个尴尬的职位TITLE，不同的公司有着不同的负责内容。 随着公司发展，我有幸参与了数据全流程开发，工作内容繁杂多变，从数据采集到数据仓库技术维度，从数据分析到数据架构业务维度，数据各个方面算是都体验了一圈。
这篇文章不聊大的，场景就是一个从0到1的小公司发展过程中涉及的数据平台工作。 完全是个人向吐槽、思考。 阔谈大数据平台建设的文章太多了，我这个没人家的深度。 不过，十分恼火现在的风气，语不惊人死不休，好像人人都轰轰烈烈，工作内容牵扯到“大数据”，就必须来个人类级命题才能聊下去。 你真做这块，你手里数据多脏，你在岗位上有多焦头烂额，你心里没有个逼数吗？ 如果你没有，那必然没有深度参与数据相关工作。最逗的是学个SQL基本取数方法，现在管这个叫“数据自由”。
当我们在聊数据平台的时候我们在聊什么
2016年底，当数据架构师将一张花花绿绿写满大数据技术栈的架构图摆在我眼前时，着实震撼。 在这之前我只知道Hadoop的Logo是一只小象，Zookeeper似乎就是用来管理这群小象的。 架构图描述着公司数据服务的未来，而随着公司业务发展旧数据架构已经明显无法满足各方人员的取数需求。 有了大数据技术助力，似乎触碰到了时代前沿。 紧接着就陷入了一种莫名的焦虑，整个大数据技术栈牵扯的组件着实很多，而且大多是Java技术背景，初入职场刚刚能保证自己Node架构的应用能跑稳定的我，显得如此无知。
依稀记得2016~2017年期间整个互联网行业背景都对大数据有莫名的情结，各种数据吹文每日必登榜首。 无知的我将大数据视为银弹，惊讶于此技竟然如此高大上。 事实证明无知是有代价的。无知就需要跟着前人跑，我做梦都没想到，大数据集群竟然如此容易即可搭建起来。 彼时CDH、HDP这种打包的数据平台解决方案已经足够成熟，Lambda架构是时髦说辞。 一个大数据工程师只需要在集群上通过简单引导设置就可以在Web UI看板下跑起来一个数据平台。 但是即使是打包的数据平台方案也充满坑，组件关联相互影响，如果不借助手册或主动搜索提问，会被奇奇怪怪问题阻断搭建过程。
经过几个月摸索，我们在生产环境跑起来一整套HDP服务。 其中包括消息接收服务，Hadoop/Zookeeper/Spark基建，数仓Hive，调度系统Oozie，数据开发界面Hue，服务接口SparkThrift。 如今看起已略显简陋。跑起来这些服务简单，困难在用起来，更甚至于稳定高效的用起来。 举个例子，新旧数据服务技术栈不一致，NoSQL数据导入Hive环节除了技术问题外，更多是适配问题。数据本身也存在脏数据清洗，数据指标不明等信息本身问题。 以新替旧，当然也就存在对比问题，取数条件稍有不一，得出结果也就不一。
经历半年打磨，在公司内部推开数据平台服务后，紧接着就是要做数据可视化。取数自由的人肯定不能仅限于数据分析人员。有好肉得烤熟才有人吃。 Superset基本是当时唯一的开源且交互式看板最优解。 也有一些财大气粗公司选择FineBI一步到位。
回头看看，大数据平台服务的技术构建过程本质还是玩转开源组件的过程，你可能要很费力的才能稳定的跑好一系列服务。 在系列服务关联，经历生产检验后，最后再适配业务进行二次开发。 就大数据服务搭建这个事情，我们经历大大小小500多个任务的洗礼终于搭稳一个整体的数据平台服务。以为是结束，没想到才是开始。
当我们在聊数据中台的时候我们在聊什么
数据是信息，信息反映现实。如果现实一团糟糕，数据必然一团糟糕。
数据平台建设初期根本原因是业务量上涨，分析速度跟不上，引入大数据架构虽然速度快了，但是数据分析的最终目的不会改变。 数据分析的最大问题就是，如何又好又快的准确分析。 作为一个数据平台建设人员能给出的答案就是，有目的的分析，对应的业务场景有指标，结果导向。 这里牵扯到的技术项就是数仓建设。
数仓建设初期，主要存在两个问题：数据质量问题 和 核心指标问题。 不同于前后端类的信息建设服务，数仓是纯粹的基于演化建设。 依赖Kimball之流的数仓建模方法论，从ODS到AWS环环相扣建设。 前后端随着业务更迭可以推倒重来，但是数仓如果推倒重来，那简直是造孽。
现实是，这个孽，相信数仓开发人员都造过。
中小企业业务发展不明确，核心指标就无法沉淀，数仓分层就可能会不合理。 不合理？不合理就重构，再招俩来！ 我仔细看过数仓职能的招聘:
- 初创企业喜欢招资深数仓开发工程师，因为需要建模搭框架
- C轮企业长期在招数据仓库工程师，因为要么是在激进的数仓建设期，要么就是数仓建设出了各种问题长期招人来面试白嫖几个问题
- AB轮企业扩招分析人员，CD轮扩招ETL/数仓建设人员，很值得玩味
我觉得就像我们透过企业发布的招聘信息判断企业发展节奏一样，数仓建设过程其实应该重在看演化而不是结果。 在业务高速发展过程中更应该沉淀核心指标，将演化过程中遇到的问题沉淀并积累才是重点，才不至于让数仓建设陷入推倒重来的悲剧。 这里对应的技术项就是元数据管理系统。 既然已经发展到了中台阶段，中台很重要的职能就是交换数据，做好元数据管理就能摁住脖颈不至于让业务部门和数据部门脱开。 在做好管控的前提下，再去做数据中台服务，进一步实施数据质量管控，可以大幅降低重构可能。
随着业务发展数据链路只会越来越复杂，数据平台需要尽早的确立一条核心链路，核心链路配套完善的监控设置。 核心链路为核心指标服务，在数据问题发生的时候，工程师应该抢救的核心链路为主，所以核心链路要足够精简直白。 屡不清核心链路就必须要反思是不是更深层的问题。
此处我的反思是，数据平台是基建。
基建就应该有基建的样子，不要过度追求满足各个业务部门的数据需求。
整个行业如今被称为数据中台能力，终究还是因为发现数据建设工作重建可能太高。
其实数据重建不代表必须推倒之前的全部基于数据的决策。
诚然数据的最终目的是驱动决策，而完成一项决策并不是只有数据才能辅助。
分析人员在看数据之内的，也要看数据之外的。
当我们在聊数据开发的时候我们在聊什么
从事数据开发职能工作，我曾经一度以为最好的好处是可以熟悉数据从0到1的全链路工作。在建设数据平台过程中接触到了丰富的技术栈。 前端做报表和可视化服务，后端有数据API服务，类中台服务又接触消息中间件系统，大数据组件也得完好，尤其SQL分析能力更是可以贯穿职业生涯使用。 可缺陷就是，3年回头一看，实则没有精通的其中任何一项。 简短总结的话，五分运维，三分沟通，两分开发。
五分运维理由是数据平台建设工作基本都是基于开源项目，平台性质有HDP，批处理Hive，流处理Flink这些基建均是来自于开源社区。 中小企业数据平台研发人员应该大部分时间都花在调试调优上面。 一款大数据组件就像是一只需要花时间慢慢驯服的野兽，虽然各种项目日渐完善，但是问题发生都是在生产环境的实践过程当中。 开发人员不得不花大量的时间玩转一款工具。 管理者要有试错的预期。
三分沟通是来自数据技术之外还有协作压力，沟通成本。 沟通不当就是错误的数据需求。 我对数据问题的认知是小错必然蝴蝶效应酿成大错。 错误的数据必然是错误决策，错误的决策一定会有人埋单，如果要找个埋单的，数据平台团队难辞其咎。 如果数据平台团队难辞其咎，那就找个一线开发问责。 而这个一线开发为了不再犯错，只好牺牲了睡眠，牺牲了生活，年近三十还没好好恋爱，身体也终要被拖垮。 所以沟通真的很重要，每个数据需求方不一定真的懂自己要怎样的数据，一定要多问WHY。 我觉得数据产品有必要谨慎到做数据模拟环节，让需求方直接绘图说明需求，以终为始。
数据是客观的，是对真实世界的真实反映，不过解读数据是人性。 曾经合作过一个高级产品经理在产品上线后只看数据好的部分，对于数据差的部分充耳不闻。 这也是高级职场人士的惯用伎俩，偏听偏见。 此类高端人士善用OKR、结果导向、目标感等舶来管理说辞。 表面言之有理实则只够给自己职业生涯镀金。 我还合作过一个高级产品经理一顿操作搞得项目成粥军心大乱，结果很快跳槽然后在脉脉上写了漂漂亮亮的简历。
仔细反思这几年数据平台我做得失败之处。
其一是虽然切身参与，但是参与深度远不达标，实际上整个大数据技术栈已经比较成熟。但是对于“大数据”三个字我总是抱着过度解读和幻想。我甚至一度以为要学完全部大数据技术栈后才能设计出整个数据架构。 我目前十分缺憾的是没有对一项大数据技术有深深切切的认识，源码级别的学学。
其二是基建完备之上，更重要的看重数据服务，搭个平台谁都能，但是能产品化提供一个数据服务就需要美美哒包装了。而所谓的数据服务不是接下公司内部全部数据相关需求，应该在基建上给一个好的产品包装，做一个具备长久示范作用的项目。
其三是要埋头深耕，作为一个数据开发人员，你可能沉浸于数据平台这项工作中。 但是埋头深耕，开始是对的，在中后期就需要务虚了，整个产业是持续发展的，有更好的实践已经公开。 有别人走过的坑，有各种已经写好的忠告，不要再相信你领导的经验，他跟你一样也是第一次跟你在相同的公司相同的场景下工作，他能做到的，你也能做到。
其四是要敢于行动，职位职能相对宏观的领导人，在数据建设的决策上不一定完全正确，数据服务建设方面自下而上推出的系统往往存活更久且更有用。有想搞的事情，就可以搞。
我不知道你是否发现，唯独在招聘数据研发的JD里要写十几个关键字才显得像个数据研发的JD。 实际上要学这么多吗？实际上要用这么多吗？实际上一个公司如果搞这么多技术栈，有卵用吗？ 且就说止于此。
致敬每一位数据相关工作者！