构建企业级数据仓库的底层逻辑

最近这些年，“底层逻辑”这个词很火，什么是底层逻辑呢？笔者认为可以将其理解为事物背后最本质的特征或原理。那么企业构建数据仓库的底层逻辑是什么？笔者认为主要是数据仓库能够反映出企业经营管理过程产生的数据洞见（insight），这些洞见有价值而且不靠数据仓库无法产生，这是数仓存在的根本逻辑。

具备条件的企业都要建立数据仓库，因为可以帮助企业基于数字驱动的决策、运营，这是数字化时代企业的生存手段和必备技能。一个致力于数字化转型的企业可以没有数据湖，但必须有数仓。那么如何构建一个企业级数仓？笔者结合工作实际谈一下思路。

需要提前说明的是，本文讨论范围仅限于数仓的构建思路，不涉及建模方法（如ER、雪花、星型等）、不涉及技术平台（如Oracle、TD、GaussDB、Hadoop、Hudi等）。因为笔者认为随着存储成本的持续走低，对建模方法的讨论意义不大。而且数据仓库与数据中台类似，更多的是一种理念，是无关技术平台的。如果数据量不大，哪怕用mysql构建数仓都可以。

1、确定主题域。

主题域就是企业经营管理所涉及的一个个相对独立的宏观分析领域。如何确定主题域？如果所在企业是金融行业的，直接可以拿来主义，比如IBM提出的FSDM、TD提出的FS-LDM都有很成熟的实施经验。如果是其他行业，简单的方法是可以考虑按照已建成的系统或业务部门来划分，但这两种方法都存在系统变化、部门变动的问题，对数仓架构可能有比较大的影响，笔者还是建议根据企业的业务进行一定的抽象，抽象成稳定的、可经历时间考验的主题域，这需要对企业的业务、企业建成系统有很深的理解。

2、尽可能完整反映每个主题域下的业务流程。

这里的关键词是“完整”，如果业务流程不完整，数仓反映的数据就是不健全的，缺少事实情况或维度情况，后续的分析就会有短板。笔者参加过一个数字化营销交流会议，一位在四大行里面负责数字营销的老师也分享到，支撑数字化营销的数据基础中，最重要的是数据能够反映真实业务的串联，数据不能有断点和片面性。

做到“完整”可能并不是一件容易的事，比如，有的企业和第三方合作，一些关键信息并未落入企业自己的系统；有的系统与其他系统的关联较为复杂，一些交互信息、流程等数据可能产生在别的系统；一项业务较为复杂，可能需要合并多个系统中的数据才能完整反映整个业务。因此，在这种情况下，数仓架构师需要做的是“尽可能”，应当做好做足充分的调研，调研对象要包含业务人员、系统开发建设人员、数据中心人员等等。

3、确定复合/高维指标。

做好前两步后，数仓的数据基础已经全了，能够满足一些报表统计、简单分析。但要使数仓的数据更有含金量，还需要更多的高维/复合指标，这是因为高维/复合指标可以支持机器学习模型，更好地产生数据洞见。做过机器学习的都知道，特征工程可以带来更好的模型效果，而特征工程最重要的就是构建高维/复合指标。如何构建高维/复合指标呢？通常的说法是需要一个“领域专家经验”，但笔者认为这夸大了业务专家的能力、增加了数仓的构建难度。

笔者认为，不失一般性地，可以参考营销领域的“RFM”模型来构建高维/复合指标。RFM模型的具体含义是：最近一次消费时间（Recency，最近一次消费记录到当前时间的间隔）、一定时间内消费频率（Frequency）、一定时间内累计消费金额（Monetary），围绕RFM可以做很多营销领域的特征，比如对于F，可以根据消费类目、消费时间衍生出大量高维/复合指标：最近1/3/6/12个月购买/浏览/搜索服装类/食品类/电子产品/书籍的次数；对于M，最近1/3/6/12个月购买服装类/食品类/电子产品/书籍的金额总和/平均金额/最大金额/环比；对于R，最近一次购买/浏览/搜索服装类/食品类/电子产品/书籍距今时间。

以上是营销领域的特征，如果换成其他领域呢？比如客户资产领域的特征，也可以参考RFM模型，只不过要将消费类指标变为资产类指标，比如：对于M类指标，最近1/3/6/12个月A类资产/B类资产/C类资产余额的总和/平均金额/环比/占比/标准差；比如客户偏好类的特征，要将消费类指标变为行为类指标，对于F类指标，最近1/3/6/12个月听摇滚乐/评书/小品/古典乐/民族乐/流行乐的次数。

需要说明的是，除了RFM类指标，还有一些基础类和个性化的指标也非常关键，比如客户基本信息、季节性因素、商品特征、促销活动、节假日事件等等都会影响到用户的行为，数据仓库设计师也需要考虑到这些因素，相关数据应反映在数仓中，此处不再赘述。

4、确定存储策略。

虽然存储已经白菜价了，但谁家也不是地主，不可能对所有表，每天都搞个全量快照。确定合适的存储策略不仅有利于成本的压降，也能减轻数据仓库维护的难度。一般而言，对于交易类数据，毫无疑问存储方式是流水表；对于变化不频繁的数据可以按月汇总存为全量快照表；非必要情况下，不推荐使用拉链表，因为拉链表的可理解性差、解释成本高、在追历史的时候容易出错，而且时间久了以后分区数量也会极度膨胀，对于一些变化频繁的数据，拉链表也并不能带来存储成本的降低。

5、确定架构和开发规范，交付开发实施。

数仓架构设计的一项重点内容是数仓分层，分层是业界的共识了，各层各司其职，一般底层是用于铺垫数据基础、一些转换和清洗，中间层合并、汇总，上层产生数据统计、复合/高维特征，就类似于我们的求学：义务教育阶段是打牢基础知识->高中阶段重点学科强化->大学选择一门学科方向->研究生选择更加细分的领域精进突破。具体而言，一般业界有“ODS-DWD-ADS-集市”这样的经典数仓分层架构，此处不再赘述。

开发规范方面，需要有开发实施人员一起参与制定，这个阶段涉及到开发语言和平台选择、命名规范、层次调用规范、一些开发习惯、共识约定等等。

6、数仓运营

数仓运营虽然写在最后，但是作用却是极为重要的，任务也非常繁重。这几年流行一个词叫“熵增”，数仓运营就是对抗熵增，保障熵减的过程。因为数仓连接了上下游，源系统变动、逻辑修改多、下游影响多，因此数据模型更新、变动历史、修数情况，都要记录在案，时常维护、更新发布。除此之外，数据质量监控、作业运行、日志检查、通知机制等等，都是需要每天关注、长期维护的。数仓运营的工作很枯燥，也很难是工作亮点、很难引起上级领导重视，可以说是一种“下水道”工作。笔者建议做数仓运营的人，在顺利调岗之前，千万不要体制化（institutionalized），不要适应和陷入那种忙忙碌碌的事务主义。