数据中台的前世今生（一）：数据仓库——数据应用需求的涌现

利润是做生意永恒的话题，我们就用商品利润的例子展开今天的讲述。

用杜邦分析法展开利润指标，我们可以清晰地看到利润组成的结构化因素，诸如商品销量、商品单价以及核算的成本等。此时，我们需要获取并分析每个品类下对应商品的销售和库存信息，基于这些数据，为每个商品制定销售采购计划：有的商品滞销，应该降价促销；有的商品畅销，需要及时补充库存，这些都离不开商品各个维度的数据。

以上的数据来源于多个业务系统。例如，需要顾客交易系统的数据，仓储库存系统的数据，采购物流系统的数据等。这些系统在源源不断保存历史数据的同时，需要经常根据业务需求被提数，而每一次的提数都需要进行大数据量的扫描和查询。这种面向单一业务系统的事务型数据库，常常面对以下痛点：

开发人员：“我们收集了海量业务数据，但无法及时维护和响应取数需求！” ；数分人员：“我们需要以各种方式对数据进行切片和拼接！” ；业务人员：“我们无法方便获取数据，不能快速响应异常情况！“；管理人员：“请将最重要的事情展示给我！；所有人：“每次会议特别低效！自始至终争论谁的数字是正确的，而不是指定决策”。

综上，事务型数据库已经不能满足灵活主题式的数据分析（以下简称数分）场景，这促使数据仓库概念的出现。

数据仓库之父比尔·恩门（Bill Inmon）首次完整定义数据仓库：数据仓库（以下简称数仓，Data Warehouse）是企业在管理和决策的过程中，面向主题的、集成的、与时间相关的，不可修改的数据集合。

在电商场景中，有的数据库存放事实交易订单的数据，有的数据库存放会员行为的数据，每个数据库“各司其职”。在将其数据同步到统一介质的过程中，需要对源数据执行 ETL，且按照主题域进行组织。

主题域是业务过程的一个高层次的抽象，诸如商品、交易、用户、流量、库存等都可以作为一个主题域，正如每本书开头的目录，经过详细且清晰的层级编排。数仓中的数据按照时间线分区存储，一般会保留 3 年以上。每个时间分区内的数据都是追加录入方式，对于某条记录通常是不可更新的。

经典数仓模型采用的是维度建模，存在两种模式：星型模式和雪花型模式。

星型模型

其维度建模的基础是 Inmon 和 Kimball 共同开创的 DW 架构（如下）。

Kimball DW/BI 架构的核心元素

针对其架构 Kimball 有一个生动形象的解释。

想象一个餐厅场景。餐厅的运营自称体系，厨师获得原始食材，将他们做成各色的菜品。在这个过程中，后端（包括源事务）类似餐厅的后厨，业务数据库类似原始食材，ETL 类似厨师加工菜品的过程。

这期间的设计包含几个目标。首先，出菜要尽可能迅速，这依赖于高效地布置。当餐厅被塞满，客人都非饥饿时，不能将时间浪费在运转方面；其次，保证同一菜品的口味一致，因此厨师将餐厅的调味料放置在固定的位置，同时调拌沙拉和处理鸡的工作台的分离；最后，端出的菜品要保证其完整。

前端类似于餐厅就餐区。在评价餐厅优劣时，多数顾客最初主要是关注餐厅能否提供满足预期的食物，但装修风格、服务水平、就餐开销也逐渐成为是否选择就餐的主要因素。于是，就餐区的装修好不好看、餐桌布局合不合理、有没有针对不同顾客的定制化服务以及适当的消费支出，逐渐成为餐厅受欢迎的关键要素。

在具体的设计过程中，Inmon 提出的建模方法自顶向下（这里的顶指的是数据的来源）；Kimball 建模与 Inmon 正好相反，是一种自底向上的模型设计方法，从数分的需求出发，拆分维度和事实。

这两种方法各有优劣。Inmon 建模是从数据源开始构建，因此构建成本比较高，适用于应用场景比较固定的业务，诸如金融领域，冗余数据少、数据结构整齐是它的优势。Kimball 建模从分析场景出发，适用于快速变化的业务，诸如电商领域，快速响应业务的定制化需求。

基于 Kimball 架构的经典数仓，第一次明确了数分的应用场景应该用单独的解决方案（数据产品）去实现，不再依赖于业务的数据库，为后来数分的大规模应用奠定了基础。

进入移动互联网时代后，经典数仓逐渐被数据湖替代，但 Kimball 架构仍是其基础。一场由互联网巨头发起的技术革命催生了大数据存储和应用的到来。

从数据仓库到数据中台系列未完待续；如果你有快速创建数据 API、数据中台、数据治理等需求，那就试试麦聪 DaaS 平台吧，回复：DaaS 可以抢先体验。

数据中台架构策略(上)——元数据中心 &指标字典

数据中台架构策略(中)——数据模型 &数据质量与成本评估

数据中台架构策略(下)——数据服务

数据中台重要的协助流程——数据产品 &数据分析 &数据开发