概要
笔者是某游戏平台领域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了解你在做什么,为什么要这样做,往往是做事成功的第一步。
重构势在必行
至于重构是怎么设计的,笔者还在开发中。再续…