戴着枷锁跳舞：漫谈重构数据仓库的辛酸

Posted 2021-04-24 木东居士

0x00 前言

如果，让我回想一下有哪些幸福快乐的工作经历，怕是很难想到。

但是，如果让我回想，有哪些痛苦不堪的工作经历，我第一个能想到的就是数据仓库的重构。

所以，本文算是一个回忆文，记录一些居士在经历过的几个数据仓库重构项目遇到的痛苦记忆。

友情提示，最后会附上一些数仓建设的tips，避坑。

0x01 世界上最恐怖的事情，莫过于读懂队友的脚本！

和一些庞大后台系统的代码量相比，数仓的那些脚本可能只算是小儿科，论代码的复杂度和代码量都远远不及。

但是，这些脚本也有它们独特的让人讨厌的地方。

大部分数仓项目都会以Sql为主力编程语言，在非互联网行业，多是运行在 Oracel、PG 和mysql 上，在互联网行业，多是运行在Hive上。

那么，问题来了，一千行的 Sql 你有没有见过？！！！

这一千行的 Sql 还没有注释！！！

随便调试一下几个小时过去了，有木有？

几十个一千行以上的 Sql 脚本放在你面前的时候，请问，你是什么感觉？

有朋友给居士吐槽，队友给留下了超过 1w 行的Sql脚本。

？？？

只能说，居士的队友都比较仁慈，多谢队友不杀之恩。

0x02 神一般的任务依赖逻辑

一个 Sql 有一千多行就算了。

请告诉我，为什么有的数据，会依赖三十多张中间表？

能加个注释吗，哥哥？

不能再加一个层次吗？

这尼玛每个中间表的维度都不一样，理解起来简直xxxxxxxx。

然后，为什么我发现，有一个中间表，依赖了一个结果表的数据？？？

不对，有很多这种情况！！！

兄弟，不能有点设计文档参考吗？有没有数据仓库的建模图？

有没有数据仓库的分层设计？

这都尼玛什么设计逻辑？？？

0x03 新需求不能停，老的数据也不能停，重构也不能停！

嗯，最怕就是这种事情了。

想象一下，重构这样一个天坑摆在面前，梳理任务就是一个让人绝望的事情了。

新的需求源源不断？

老得数据也要继续跑，和重构的数据做对比！

这种场景，除了绝望还有什么可以形容？

关键是，老板能不能不要再挑战重构数仓的业务价值了。谢谢了。

我想来接你的坑吗？

0x04 每天莫名其妙的产生数据，看不到代码，看不到任务？？？

最让人无语的事情是：经常有一些莫名其妙被生产出来的数据！！！

没人知道生产它的代码在哪里，调度也不知道在哪里？？？

搞笑呢？

而且代码也不统一，为什么有的是用 Spark ，有的是用 Hive？

没有统一的规范吗？

0xFF 总结

值得吐槽的地方有点多，不过写一半感觉还是写点建议实在吧，负能量传播一部分就好了。

数仓重构的几个小建议

1. 事先评估好重构的成本，老板在支持你做重构时，他可能也没接收到太多的上层压力，当他有压力的时候，就会把压力传递给你，因此事先好好评估很重要。
2. 重构应该侧重于重构规范，尽量不要动以前的代码，新的需求用重构后的规范。一般一份数据计算任务，一年左右的时间就会迎接一次更新，因此新的规范推动一年后，大部分任务都会变成新的了，除非特别必要尽量不要动以前的代码，成本太高。
3. 获取业务方的支持，至少要把能带来的价值说清楚，让业务方支持一部分工作，不然自己做一半，还会被人后面捅刀子。

关于如何重构数据仓库，敬请期待～

热门文章