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

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

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

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

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

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

模式1：常见的实际场景

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

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

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

拿来数据是比较方便的，ODS