关于数仓里画像层的构建的一些思考

最新推荐文章于 2024-07-20 16:56:36 发布

木东居士

最新推荐文章于 2024-07-20 16:56:36 发布

阅读量292

点赞数

0x00 前言

写一些关于数据仓库里面，数据集市（画像层）的东西吧

最近一直都没写文章，因为太忙了，公司很多事情，主要画像层的一些重构，搞得我死去活来，所以写一篇文章给大家分享一下，如何构建一个良好的数据集市。

情况呢是这样的，现在有很多的B端画像（交易，流量，什么的这种），但是呢，这些个画像，几年前就构建好了，而且SQL写的极其复杂，导致SLA已经很晚了，所以要优化重构。我这里主要说几点吧。

0x01 8点思考

中间表尽量少——为什么这么说呢，因为我在重构的过程中发现，之前的那些个SLA超级晚的画像，用了大量的中间表，一张画像甚至从事实表到最终画像表，中间表可以有20多张，太恐怖。导致起job的时间都要花不少，同时浪费大量存储资源（10TB左右）。所以有时候只要思路理顺了，写大SQL不见得是坏事。
少用union all——之前写那个画像层的哥们（现在已经离职了），非常喜欢用union all，然后再group by，这会导致数据量激增，同时会有数据倾斜风险。
少用子查询——我们要知道，只要SQL中有一个from或者一个join，那就是一个MapReduce任务。所以能够在一个查询里面进行判断计算出的结果，不要写子查询。
若非必要，不要在where条件，将判断条件写在select中的字段里，case when去做判断——其实这个思路和前面第三点是差不多的，还是减少MapReduce任务，省去不必要的开销。达到资源优化最大。
最后关联维度表——不管有几张中间表，最后写入结果表时，再去关联维度表（比如在此次重构过程中，最后再去关联商户维度表），从而不管是在优化上，还是后续迭代维护，都是方便很多。
合并小文件——这个不多说了吧，小文件一多，会对NameNode的压力激增，这种参数都要加上。
备注一定要写全——重要的事情说三遍，不要以为备注这个东西无所谓，这也是数据治理和数据质量的重要一环，否则字段命名不统一，备注不全，会导致后续case解答的时间会占用你一部分的工作时间，然后就不停的加班。
加强复用性——因为画像（数据集市），是对下游很多的应用和OLAP分析的出口，所以复用性是很重要的，所以没有特殊情况，务必保留全量的商户，不要去where里加限定条件，毕竟这不是APP层，不是定制化需求，务必保证复用性最大化。