数仓理论结合自己的工作和思考总结

搭建数据仓库可以从多个方面切入，我接触到的工作中处理实际工作案例大致分为2中模式。一种是在需求不明确的情况下从底层搭建开始，主要工作重心在于先收集数据，并对数据分类保存，等到具体需求到位的时候再搭建上层的数据仓库表（如用户一体化）。另外一种模式就是在确定需求场景下，根据需求内容向下拆解任务反推需要的数据源支持（如用户在线）。两种模式各有利弊，我的总结如下：

模式1：属于通用型强的广泛收集数据，但是会造成很多冗余和不合理。后期可支持的需求种类会宽泛很多，但是整体项目工程的进度会慢，项目返工的几率很高。目前的主要的应用场景现在只有一种，或正在摸索式中。

模式2：根据需求设计数据针对性强很多，能够快速的梳理出依据需求得出数据支持关系。按照需求搭建数据产出速度很会很快，当然最终的数据结果可能仅适用case by case的解决问题。

两种模式其实无论好坏，不同职责的部门可能距离业务需求的远近不同，无权选择采用的哪种模式解决问题。但是最终成熟的数据仓库产品是符合两种模式的优点的，这就需要两种模式在不断优化迭代中逐步完成。

如何分别不同的两种模式，我们可以从实际的场景中看看两种模式的反应情况，以便于遇到的时候能注意到利弊。

模式1：常见的实际场景

我们都知道并认同abc数据很重要，但是怎么分析和使用没有具体的方案。

例如，我们要分析业务的订单数据，我们要将订单数据纳入到数据仓库中。至于支持哪些维度和指标，分析师们以后会怎么用数据。我们并不清楚。这个是典型的模式1。我很难判断数据的重要优先级，也很难合理设置出满足今后需求的数据表结果。因此，我们只能依赖偏技术性的数据仓库知识去做管理和维护。将业务库的订单数据全部拿过来，将订单的系统日志全部拿过来，将埋点的订单数据全部拿过来。有什么拿什么过来形成最底层的ODS层数据就好。几百几千的原始数据表数据被灌入到数据仓库。

这个过程中我们是对数据不加任何多余考虑的。既然不知道是否有不需要的数据，为了保障完整性全部拿来。也不会知道数据有什么缺失，反正具体的需求是什么我们也不知道。

拿来数据是比较方便的，ODS层数据的只要苦力加个班几天时间就可以将大量的数据灌入数据仓库。接下来的一步就会非常困难，怎么分类整理搭建轻度汇总层，将数据加工出汇总的明细数据。这个过程对于研发工程师最大的考验是熟悉业务（熟悉业务和数据的“映射”关系）。订单都包含什么信息，订单的创建到消费经历什么环节，有多少环节，对应的状态和参数是什么？数据之间的关联关系是一对一，一对多，多对多？订单对应几个用户信息，订单信息会被更改退吗？

当任何不熟悉业务的数据工程师想要在ODS层的基础上去搭建上层数据的时候，都会陷入复杂的业务知识和逻辑中。我所经历的类似工作内容中，能够一次性搞定这块数据仓库搭建的至今成功案例非常少，除非公司业务简单，老员工占多数，不然真是浩劫（当然解决办法也有很多，这个以后再聊更深入点）。所以，如果遇见类似的场景要做2个判断，a、业务的复杂度。b、有没有老员工扛大旗。如果不符合这两个条件，项目尽早认怂或者换思路解决问题。

模式2：常见的实际场景

我们现在有一个数据需求，想看A页面带来的订单转化数据效果。表头是日期、城市、模块（页面整体、页面子模块）、订单数，订单人数，支付订单数、支付异常订单数、支付金额，利润金额。

根据需求去搭建数据仓库就简单很多，因为需求明确，所以首要任务是以需求为导向设计方案，在上述提到的数据表头中我们很容易推断出数据仓库各层应该放什么样的内容。尤其是对于应用层、数据汇总层的设计，在为了仅满足一个需求的前提下是很容易给出方案的。那么接下来的重点主要在于搞清楚业务数据中是否有我们需要的字段，我们从哪里抽数据即可（轻度汇总层的数据明细层，主要是对拿过来的ODS层数据进行加工一轮，以便于符合数据仓库标准和规范，因此这层的设计可有可无也不难处理）。

以上两种模式在实际工作中，前者需要后期不断实际需求的提出才能逐步摸清数据给出更好而方案。后者会在新一轮又一轮的数据需求提出过程中发现前期的方案不足慢慢自我优化迭代。