记一次数仓重构的前因后果，以及抉择的反思

概要

专有名次解释

笔者是某游戏平台领域xx公司的数据负责人，准确来说是刚接到boss需求紧急调配到这个项目组。刚接到需求的我立刻跟各个同事了解业务情况，当我了解到数仓的问题的时候，我裂开了，（本人曾担任过原数仓的负责人），原来的数据源是1个，以hadoop为中心展开，现在到好，变成了三个（oss + hadoop + dataworks）。

现数仓设计图

这里可以看到，我们从阿里的sls（日志中心）订阅实时流数据，然后经由ETL工具（nifi）处理，分别写入三个数据源(OSS, EMR(hadoop), Dataworks)。做过工程的同学都知道，同时维护三份相同的数据源，并且保证每个数据源的数据是一致的，这无疑增加了维护成本。简单的来说，如果一个mysql能搞定问题，为什么我要把一份数据分别存到三个mysql，并且维护这三个mysql呢。

现数仓接入/出方式

因为存在多个数据源，所以现数仓有多种接入/出方式，包括：

write:
(1) spark
(2) presto
(3) maxCompute
(4) dla

read:
(1) mysql
(2) dla
(3) presto
(4) spark
(5) maxCompute
(6) hologres
(7) dataworks内建工具包
…

有时候选择太多也不是一件好事，维护多数据源，多出入口方式，本身就是一个极大的负担，这是重构(迁移)势在必行的第一个主要原因。道理其实很简单，如果不拿石头砸自己的脚，往往我们就没法继续前行。如果要想好产品，基础设计是重要且致命的一环。乔布斯先生设计的iphone4，不仅仅是功能跨时代，连每个按钮，每个棱角的设计都是有过仔细考量，这才给我们带来了iphone如此惊艳的产品。日本人有个精神，工匠精神，we build it , we built it better, how could we build it best, 这三个层面的结果往往是很不一样的，对于一个熟练的工程师，做出一个功能不难，如果把这个功能做好，满足低耦，开放封闭原则，SRP 等等，结果就很不一样，再进一步，我怎么把这个产品设计好，结果就更不一样。如果公司的每个人都能自我要求，以力所能及的技术极限，产品极限为目标来设计每个业务。那么对整个公司来说，结果就会很不一样。量变引起质变。

其他接手项目+重构的原因

1.没有完整规划，多数据源同时存在，迁移无法完成。
2.数据的稳定性，错误数据，延迟等发生概率并没有达到生产级的水平。
3.所谓的中间表开发遥遥无期，各团队无法使用，都是从原始日志捞数据。
4.数仓迁移大半年任务仍然没有完成，不论是是数仓方还是业务方都有责任，数仓责任更大，没有主导项目的高效推进。
5.数仓同时存在多个数据源，数据的一致性存在很大的挑战，把原本迁移的问题复杂化。
6.dataworks选型存在技术上选型的问题，dataworks并不能很好的兼容现在所有的业务，并且增加迁移成本。（mysql同步的表无法查询）
7.新数仓较老数仓使用体验相比，并没有给各个业务方带来多大的便捷，各使用方都不满。
…

笔者不是一个高手，但是明显且已知问题暴露在那，就要去解决它。是的，回到前情提要，we build it , we built it better, how could we build it best。

「江湖」就是人情世故

技术并不是一切，人不是无感情的动物。优秀的工程师往往会陷入技术就是中心的漩涡，忽略了其他人的感受，技术得确很重要，但是沟通更重要，让你的搭档/boss了解你在做什么，为什么要这样做，往往是做事成功的第一步。

重构势在必行

至于重构是怎么设计的，笔者还在开发中。再续…