【数仓分层构建】新能源自动驾驶/车联网行业的数仓分层

一、数仓分层描述

这里是常规的数仓分层，接下来我将结合具体业务讲述数仓开发。

二、业务驱动构建总线矩阵

1.DWD层维度建模

我结合Kimball的维度建模理论以业务过程为驱动制作了下面表格：

这个结果怎么来的呢，我通过下面步骤说明：
（1）选择业务过程
在业务系统中，我们要选择我们需要的有意义的业务，比如在车联网领域我们选择驾驶里程业务，车辆能耗业务等，这里的业务就是事实对应事实表。
（2）声明粒度
声明粒度意味着精确定义事实表中的一行数据表示什么，应该尽可能选择最小粒度，比如驾驶里程表中一行数据表示的是一辆车在在这个时序时间的里程值（这里的里程值不一定是累计里程，要根据传感器的种类确认）。
（3）确定维度
维度的主要作用是描述业务是事实，确定维度的原则是：后续需求中是否要分析相关维度的指标，例如出勤的情况肯定要看车辆的出勤时长（评估车辆作业情况）和驾驶员的出勤时长（驾驶员计算绩效），因此车辆维度和驾驶员维度是需要的。
（4）确定事实
确定事实就是最后一步，我们要细化到哪些度量值，比如上表中的能耗事实，我们要细化看耗水、耗电、耗油等。
至此，数据仓库的维度建模已经完毕，DWD层是以业务过程为驱动。
DWS层、ADS层都是以需求为驱动，和维度建模已经没有关系了。
DWS层和DWT（部分企业会有）都是按照主题去建表。主题相当于观察问题的角度，站在角度去看事实。

2.DIM层抽取维度

在经历了上述的维度建模以后，我们需要进一步的抽取出维度层，比如上面的车辆维度，需要单独做一张车辆维度表，为什么呢，比如车辆维度里我加了车型、车辆用途，那么在后续汇总层我可以有更多的角度去看事实，以此来完善的满足业务需求。
另一方面我们这一层要完成维度退化，例如车辆维度表，车辆每天在的项目地是不一样的，并且车辆的项目归属是单独的一个来源，因此这种情况我们可以将车辆配置表和此表关联作为车辆DIM维度表，实现维度退化，减少后续关联。

3.DWB层宽表

明细宽表在企业中也很重要，业务过程中存在相似性时，我们会采用宽表设计，这样可以提升数据整合性、提高数据查询效率，并降低维护成本。同时，宽表设计也便于跨系统和跨部门的数据整合与调用。但是宽表的设计从维度建模的思想来说适当破坏了规范，这一层要根据具体场景去平衡。
关于宽表我会在我账户的其他文章专题陈述。

4.DWS层轻度汇总

这一层设计思想一句话总结，“站在维度的角度去看汇总事实”，注意这里的用词是汇总，如果不是汇总那么容易和维度建模过程混淆，维度建模是明细数据，这里是汇总或者说累计数据，举个例子，大蚂蚁车型昨日总里程。
DWT层不单独陈述，DWS层存放的所有主题对象当天的汇总行为，例如每个自动驾驶版本的电耗、信号强度等，DWT层存放的是DWS基础上的的累积汇总，例如每个自动驾驶版本最近７天、30天、60天）的油耗汇总。

4.ADS层应用指标

这一层是和业务最近的指标层，在有了之前的DWS层轻度汇总的基础上，我们可以更方便的构建指标，比如车辆手动驾驶的作业的平均沿边距离的月度环比涨幅，再比如车辆流失等等。
这里要格外注意，如果ADS之前做的足够规范，我们是不需要关联DIM层的，同时也是基于数据治理的角度，ADS层制作只去DWS层获取，避免了跨层调用带来的后续问题，问题比如血缘关系混乱、业务杂乱。总之，按照这一整套规范流程可以把复杂问题简单化、减少重复开发、为业务高效完善提供指标。