如果,让我回想一下有哪些幸福快乐的工作经历,怕是很难想到。
但是,如果让我回想,有哪些痛苦不堪的工作经历,我第一个能想到的就是数据仓库的重构。
所以,本文算是一个回忆文,记录一些居士在经历过的几个数据仓库重构项目遇到的痛苦记忆。
友情提示,最后会附上一些数仓建设的tips,避坑。
和一些庞大后台系统的代码量相比,数仓的那些脚本可能只算是小儿科,论代码的复杂度和代码量都远远不及。
但是,这些脚本也有它们独特的让人讨厌的地方。
大部分数仓项目都会以Sql为主力编程语言,在非互联网行业,多是运行在 Oracel、PG 和Mysql 上,在互联网行业,多是运行在Hive上。
那么,问题来了,一千行的 Sql 你有没有见过?!!!
这一千行的 Sql 还没有注释!!!
随便调试一下几个小时过去了,有木有?
几十个一千行以上的 Sql 脚本放在你面前的时候,请问,你是什么感觉?
有朋友给居士吐槽,队友给留下了超过 1w 行的Sql脚本。
???
只能说,居士的队友都比较仁慈,多谢队友不杀之恩。
一个 Sql 有一千多行就算了。
请告诉我,为什么有的数据,会依赖三十多张中间表?
能加个注释吗,哥哥?
不能再加一个层次吗?
这尼玛每个中间表的维度都不一样,理解起来简直xxxxxxxx。
然后,为什么我发现,有一个中间表,依赖了一个结果表的数据???
不对,有很多这种情况!!!
兄弟,不能有点设计文档参考吗?有没有数据仓库的建模图?
有没有数据仓库的分层设计?
这都尼玛什么设计逻辑???
嗯,最怕就是这种事情了。
想象一下,重构这样一个天坑摆在面前,梳理任务就是一个让人绝望的事情了。
新的需求源源不断?
老得数据也要继续跑,和重构的数据做对比!
这种场景,除了绝望还有什么可以形容?
关键是,老板能不能不要再挑战重构数仓的业务价值了。谢谢了。
我想来接你的坑吗?
最让人无语的事情是:经常有一些莫名其妙被生产出来的数据!!!
没人知道生产它的代码在哪里,调度也不知道在哪里???
搞笑呢?
而且代码也不统一,为什么有的是用 Spark ,有的是用 Hive?
没有统一的规范吗?
值得吐槽的地方有点多,不过写一半感觉还是写点建议实在吧,负能量传播一部分就好了。
关于如何设计一套数据仓库请参考公众号的数据仓库系列文章。
关于如何重构数据仓库,敬请期待~