原创|实时数仓实战项目-第三节（数仓治理）

马上就要到国庆节了，提前祝大家国庆快乐，最近比较忙，考虑到粉丝一直要求我更新文章，我今天就加班更新一下文章。

实时数仓如何做数据治理

在做技术分享之前，我就尽量画图，少写字，最好能让大家看一天图，就能懂最好。我不画大饼，搞一些高大上的东西，我就简单从我一个数据开发的角度来思考🤔我们应该如何去做数据治理。

1、表概览

有个地方可以维护你当前实时数仓维护了多少张表，这个好处就是，我们可以一目了然的发现我们当前有多少表，这些表目前的数量状况

2、表明细

有个地方记录你的每个表的创建信息、是否为临时表、近30天使用次数（判断表的热度，如果一个表长期没有人使用，我们就可以推动产品协调相关使用人员，是否可以把这个表下掉，节省计算和存储资源）、血缘关系（基于什么表加工，如果发现数据跟离线对不上，方便追踪上游，定位问题），依赖关系（能否下掉，下游都有哪些任务在用，下线是否影响其他团队）、数据的保留多少天（实时数据保留多少天，kafka一般默认3天，那doris实时落的数据你需要保留多久，需要提前维护好，有的kafka明细数据直接落doris方便排查线上问题，可能量级比较多，10几亿，存储几百g，存的天数多了，占用存储）等等，都需要一个精细化的平台来记录，小团队刚开始表少，两个人就可以维护聊，等团队多了， 每个人都维护100多个表，谁都不知道谁手里维护的什么表，很容出现烟囱式开发，也就是需要有一个平台去查询数据情况。

3、标规范化

不知道大家有没有经历过这种情况，你想查询某个业务相关的表，你发现找不全，原因就是每个同学的表命名规则都不一致，所以大家创建的表可能五花八门，等团队人多了，你会发现维护不动了。我举个例子：张百万，你们看到这个名字，你们知道这个兄弟姓张，叫百万，为啥你知道这些，是因为你有起名字的规范，你知道第一个是姓氏。

建议大家在小组内统一命名规范，方便后期维护，定期审阅小组成员创建的表，表的命名规范网上一大堆，我就不一一列举了。

4、指标口径

需求评审，离线和实时同学一起开发数据报表，实时同学开发业务投放使用报表，离线同学开发业务结算使用的报表，可能开评审的时候，双方都明白如何加工数据，但是由于公司基础数据无法实现流批统一，会出现离线和实时加工的数据存在gap。

做数据的同学，应该比较有共识的一点，就是排查问题，像我是做实时的，我发现了一个问题，业务和产品都觉着离线的数据往往比实时的加工的更准，出现问题，就会问我为啥跟离线数据有gap，赶紧查，拉了一大堆领导过来，让你查问题，那你们如何高效的应对呢？

常见问题（设备反作弊，设备多发码）：实时数据落doris明细表，离线数据也同步到doris表，出一个gap报表，让业务和投放同学自己去报表上看，数据为什么有gap，给他们吃一个定心丸，你们也不用每天都去查，常见的问题抽象画出来，节省人力。

不常见的问题（指标对不上）：建议大家实时数据存doris明细或者设备力度的聚合数据（具体看业务情况，如果数据量特别大，建议落hive），方便快速跟离线对数据，快速定位问题。

指标口径不统一，这个问题是每个程序员都无法逾越的鸿沟，家常饭。

4、总结

数据治理还有很多其他的方面，我不能一一例举完全，比如还有做数据安全的，数据质量的这些都跟觉业务场景去定制化。

个人理解，数据治理就是类似美容吧，如果你感觉单眼皮不好，你就割双眼皮，你感觉皮肤黑，你就弄点美白皮肤的护肤品，你感觉哪里不好治哪里。非常简单，不要以为这些都是什么高大尚的东西，你们想想，sqlboy还能高大上到哪里起（我认识一个十年做数仓的老哥，我专门请他吃饭请教他问题，我问他：“最近数据治理比较火，数据治理到底是干啥的？”，他的回答：“就是数据不好维护了，就治理一下”，从那开始我豁然开朗了）

想要交流实时数仓的同学可以加我微信

预告

下期讲啥还没有想好。

实时数仓常用的flink计算场景我也会给大家一一讲解，敬请关注千亿级的实时数仓架构方案！！！！

大家有问题可以留言，自己的想法都可以留言交流，想让我分享什么的内容也可以在文末留言。