小熊科技|数据仓库的治理一塌糊涂,没有管理好数据,最后都会怎么样


“年年数据要治理 , 数据年年治不好” 。
【小熊科技|数据仓库的治理一塌糊涂,没有管理好数据,最后都会怎么样】数仓治理的老大难 , 通常是跟着业务需求快跑 , 要不是数据零散在各个团队 , 或者是大家的研发规范有不同 , 作为一项通过维度模型来约束规范的工种来讲 , “模型”的治理难度 , 大于“架构” 。
目前整个行业通常的模型治理方法 , 是规定一种建模规范 , 大家在编码的过程中各自遵守 。 当业务开始变得模糊不清的时候 , 再专门抽调时间 , 来做人工治理 。 就像黄河一样 , 流沙清理了一次又一次 , 但上游还是会冲下新的流沙 。
小熊科技|数据仓库的治理一塌糊涂,没有管理好数据,最后都会怎么样
本文插图

数仓的假设既然都是采用的维度建模 , 那么其设计思想必然是自下而上的进行建设 , 与架构进行类比 , 也就是先做好子模块 , 最后做顶层设计 。
但如果设计者不熟悉对应的领域模型 , 一旦业务上发生了变动 , 一张核心表动辄几百张的引用 , 会让重构的工作变得困难无比 。

强如阿里 , 会做一些更进一步的工作 , 比如模型的健康分 , 看看你的存储成本有多少、计算成本有多少、生命周期是不是合理、代码规范有没有避免全表扫描 , 等等 。 但这些工作只能发现一些常规的问题 , 也依然需要进行人工治理 , 不仅效率上没有得到提高 , 每天推送的邮件也会让你产生心烦 。
投入多少人 , 投入多少时间 , 终归是解决了一时的问题 , 而非长远 。
小熊科技|数据仓库的治理一塌糊涂,没有管理好数据,最后都会怎么样
本文插图

因此 , 换个思路考虑问题 , 当业务高速发展时 , 数仓势必要跟着跑 , 不然业务都跪了 , 数仓又有何用 。 但业务通常不会一直处于高速发展的阶段 , 就像长跑一样 , 总有跑跑停停的时候 , 因此如果我们遵循一定的做事方法 , 流程上多一点步骤 , 那么就会极大的延缓数仓治理的问题 。
即不追求长久的问题解决 , 而以一段时间内的稳定为目标 , 比如一年 。 当业务已经发展到比较稳定的阶段 , 再回过头来做治理 , 既能够避免因为业务变动而影响模型重构 , 也可以节省大家的精力和压力 , 就不失为一种解决思路了 。
完美的解决方案通常不存在 , 退而求其次是大多数人的选择 。 当技术无法解决问题时 , 不妨用另类思路去解决 。

数仓的指导思想是什么?如果一定有定义 , 那么就是:以维度建模为基础 , 根据业务域和数据域设计主题模型 , 构建一致性的维度和事实 。
以下简略叙述理论 , 维度模型已经有很多的讲解文章 , 这里只是起到思路讲解的作用 。
从宏观上讲 , 首先要了解数据的统计周期 , 是增量同步 , 还是全量同步 , 并根据预估的数据量设计ODS 。
其次 , 要大致了解业务域的划分情况 , 将一类不可拆分的行为作为一类 , 比如支付、比如搜索 。 当有了宏观的划分之后 , 就可以根据这些业务过程 , 构建最明细粒度的事实表 , 也就是DWD 。
再次 , 基于DWD便可以根据主题对象进行数据建模 , 构建公共粒度的汇总指标事实表 。 很多时候 , 由于需要加工一定的业务逻辑 , 可能带来DWD依赖DWS的情况 , 比如基于时间序列的业务过程 , 这里就需要避免统计类型或者业务类型的逻辑 , 加工到DWD中 , 这部分应该放到ADS层去做 。
小熊科技|数据仓库的治理一塌糊涂,没有管理好数据,最后都会怎么样
本文插图

最后 , 定义好一致性的维度 , 即DIM 。 通常是静态的信息 , 如果存在动态可变的属性 , 还是放到DWD比较合适 。

从这里开始 , 每位研发同学 , 都可以掌握维度建模的核心思想 , 通常公共层建设好之后 , 应该是变动极其小的 , 为了避免设计不好导致的后续维护问题 , 模型一定要有评审 , 即便是忙 , 也至少要找一个人帮忙进行CodeReview 。


推荐阅读