谈数据治理感想：基于《如何避免数仓模型“烟囱式”建设》博文

原文链接：如何避免数仓模型“烟囱式”建设

如果把指标⽐喻成⼀棵树上的果实，那模型就是这棵⼤树的躯⼲，想让果实结得好，必须让树⼲变得粗壮。真实场景举例：

⼤多数公司的分析师会结合业务做⼀些数据分析（需要⽤到⼤量的数据），通过报表的⽅式服务于业务部⻔的运营。但是在数据中台构建之前，分析师经常发现⾃⼰没有可以复⽤的数据，不得不使⽤原始数据进⾏清洗、加⼯、计算指标。

由于他们⼤多是⾮技术专业出⾝，写的SQL质量⽐较差，甚⾄⻅过5层以上的嵌套。这种SQL对资源消耗⾮常⼤，会造成队列阻塞，影响其他数仓任务，会引起数据开发的不满。数据开发会要求收回分析师的原始数据读取权限，分析师⼜会抱怨数仓数据不完善，要啥没啥，⼀个需求经常要等⼀周甚⾄半个⽉。分析师与数据开发的⽭盾从此开始。

这个⽭盾的根源在于数据模型⽆法复⽤，数据开发是烟囱式的，每次遇到新的需求，都从原始数据重新计算，⾃然耗时。⽽要解决这个⽭盾，就要搞清楚我们的数据模型应该设计成什么样⼦。

引言部分与原博文一致。

---

数据的开发需要首先弄清自己的需求，即你要搞清楚，我将来拿到的数据是做什么用的？从自身经历出发，我认为可以分为以下两大部分。1.单纯存储；2.做分析。

1.从存储来说，其实建造什么样的模型，建多少模型都无所谓，因为从我的需求出发，我的目的是“存”，只需要保证了存储安全，备份容灾，版本控制等一系列考量，数据本身不丢失不损坏可追溯，存储的目的就达到了。相对于另一部分的需求。考虑的内容并不算多。

2.做分析的话，需要考量的内容激增。模型模型，这里指的都是数据模型，与我常些的挖掘模型算法模型数学模型这类称呼不是一类，注意区分，这里指的都是物理模型。物理模型即仓库内部的底层表，是先从业务模型中抽象出的概念，最后再落地的。要指出的是，现在有需求部署数据仓库，也确实有能力建设数据仓库的公司，已经很少有单生产、单系统的数据源的场景了。而出现了多数据源多生产系统的场景，就需要更多侧重于考虑到底层模型怎么建，或者说减少维护成本。要关注应用的业务范围，有多少部门，有多少业务条线要用数据去服务他们。

3.数据仓库的运维，往往需要的是时刻与业务契合，与监管要求契合。在资源和满足使用之间寻求一种微妙的平衡。正好够用就行了吗？当然不是，数据的建设从来与服务的业务场景息息相关，数据仓库是所有产品的数据中心，公司体系下的所有产品产生的所有数据最终都流向数据仓库，可以说数据仓库不产生数据，也不消费数据，只是数据的搬运工。数据仓库的数据，实时性要求不高，而准确性、清洁性必须较高，因此清洗的脚本繁多。如果每条数据都实时传送到数据仓库的话，那脚本执行的频率将非常高，所占用的系统资源也随之增加。