JOKER|数据仓库一堆数据的分类整理思路（20181025）

Posted 2021-04-24 姬远玄

昨天微信群和朋友聊起数据仓库，准备今天帮着他一起分析一下数据该怎么分类整理，搭建数据各层要注意什么，然而，仔细分析了一些数据内容之后，感觉隔行如隔山的懵逼，对于传统行业的数据在不熟悉业务场景的前提下，是无从下手的。看来，熟悉业务是搭建数据仓库的必备条件，这话一点不为过，那么实际工作中我们改如何搭建数据仓库呢？

以下，Enjoy：

01

—

业务知识

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

模式1：属于通用型强的广泛收集数据，但是会造成很多冗余和不合理。后期可支持的需求种类会宽泛很多，但是整体项目工程的进度会慢，项目返工的几率很高。

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

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

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

模式1：常见的实际场景

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

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

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

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

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

模式2：常见的实际场景

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

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

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

02

—

数据分层

随着业务的发展需求越来越多，项目总会越做越复杂。当达到一定的数据量级复杂度和历史包袱积攒负重不堪的时候，我们必须考虑数据仓库的长期搭建方案。为了解决以上数据仓库搭建问题，拆表、合表、重新数据分层是我们常用的解决办法，搭建离线数据仓库分层的架构如下：

• 应用层  \\服务数据产品，应用场景

• 数据汇总层 \\宽表明细，主题表明细，维度表

• 数据明细层 \\轻度汇总层的明细，维度数据

• ODS层  \\各种业务库同步数据，埋点数据 系统日志

我注意到很多公司对数据分层有不同的叫法和分法，但是大体可以对齐口径的是3-4层。其中ODS层和应用层的歧义很少，ODS层作为最基础的数据作用是保持数据源的提供，我们一般不对它直接进行加工和清洗。应用层的含义大致是交付数据结论的一层，主要是提供实际计算加工统计的数据，或者是满足实际产品工程查询、查看数据的数据仓库表。对于应用层的歧义也相对较小，一般主要歧义点在于应用层是否应该有明细数据，应用层的明细、维度表和中间2层的意义区别在哪里，这个歧义不太容易统一口径。

最后是对中间2层的理解差异非常大，搭建标准较为丰富多姿。数据仓库是否好用，是否健壮。我理解主要的核心在于中间两层，大部分的数据工程师的工作也处于中间两层。

由于时间的关系，数据仓库最重要的2层明天再写。

FLAG：JOKER|数据仓库数据明细层和汇总层搭建思路（20181026）

---

• 文章多有不足，需要长久的打磨才能产出优秀的内容，我对每篇文章设置了版本编号，以便于不断的发现问题和完善知识点，感谢大家支持。

  
  

• High Joker订阅号每天更新数据相关的文章，订阅号内的文章均为原创。欢迎大家的传播和转载，本人对于转载无任何限制条件和要求。

欢迎关注 交流数据