从0到1用阿里方法论搭建数仓 （一） 数仓规划

2015年1月，《数据仓库工具箱——维度建模权威指南》出版；2017年7月，《大数据之路——阿里巴巴大数据实践》出版，如今后者已停印，网上要买只能买到原价两倍起的二手书或质量参差不齐的影印版。按照互联网技术发展的速度，似乎书中这些技术和方法论应该已经落伍了，可现实是，除了那些起步早、成为各行业头部的几十家公司的数仓体系构建得科学合理，大部分有这方面需求的公司的数仓仍旧是烟囱式地按需建设。数仓，即DW/BI系统在管理层眼中，定位主要是分析决策系统（BI商业分析），他的缺位不会影响公司早期的扩张，如果业务线的数据集市建设得满足当前发展的需求，对数仓搭建的投资不受重视也是可以理解的。只有当公司发展得足够成功，以至到了规模化阶段，业务上公司的目标变成对运营模式优化，使规模化后运行更有效率，并创造更大的商业生态，这时对公司的数据就提出了更高的要求，如果数据分散于各个数据集市而不能打通，则必然不能满足管理层对各业务线横向对比经营指标的要求；API流量、渠道关系以及竞品信息，这些之前只是干扰信号的东西，规模化阶段都成了值得思考的问题。技术上，公司发展过程中收集了海量数据，数据的存储和计算成本已有攀上天文数字之势，但因为数仓建设不足导致无法对其有效访问（未转换成可用的资产以产生效益），必然也会推动管理层被迫开始解决这个问题。

据此可知，每年进入规模化后的公司，多会产生数仓规范建模的人才需求，除去被大厂招安的人才，每年跳出来找机会并熟悉数仓建模方法论、并有相关经验的人才，必然是稀缺也因此炙手可热的。需知道，好的项目（培）养人，但好的项目也少（体量大的公司就那么几十家，且公司数仓大厦建完后就主要剩数据治理的需求了），所以当你所在公司有数仓建模的需求时，把握机会去争取它，去实践数仓建模的方法论，把建模方法学到融会贯通，因为数仓开发在职业路线上对技术没有那么深的要求，但对数仓建模的要求却很高。毕竟技术上，大数据平台可以由高P后端为你实现和降低开发难度（SQL化的趋势），设计上，怎么把需求建模，即业务数据抽象成一系列高可用数据集的能力，将数仓建模成功经验复制到其他主题数仓的能力，将会是职业发展的关键。熟练且掌握方法论的人总能为公司省下时间和试错成本。

数仓模型可以被当做书就是数据的图书馆管理系统，建模就是数据组织和存储的方法。 数仓建模在国内有两个主流的方法论，一个是Kimball的维度建模方法论，一个是基于Kimball发展的阿里OneData方法论。Kimball维度建模理论的步骤分别是：

阿里的数据调研分两部分，业务调研和需求分析。 业务调研 —— 对业务系统的业务进行了解，并进行业务层面的分解和程序化。维度建模的星型模型基本都构建于关系数据库之上，而关系数据库多遵守E-R模型的3NF，这里的分解和程序化可理解为E-R模型的一个个实体和实体间关系。该步骤是自底向上建数仓。 需求分析 —— 收集商分/运营人员对数据或报表的需求，建立不同分析视角（这里的分析视角可以理解为为不同方向的商分建立ADS应用大宽表，是自顶向下建数仓）。 Kimball维度建模与之对应的步骤则是：收集业务需求与数据实现情况，可以分为两个步骤：

维度设计者对接业务代表（产品经理）——理解业务需求（目标），梳理关键性能指标

维度设计者对接源系统专家（研发、DBA）——摸清底层源数据实际情况，可行性 可以看到在这个步骤，阿里还是完全和Kimball的维度建模保持一致的。 这里我们重点讲一下流程2：需求分析。这个流程可以通过回答一份问题清单来抓住工作的关键（问题驱动式）：

我们的核心用户是谁？ 这个问题可以引导你做用户分层，建一个用户优先级金字塔，当研发人力不能满足需求量时，审慎地选择核心用户及其需求

他们想看什么指标？ 继承自上个用户金字塔，可以分别归纳不同用户关心的指标

如何评估指标的价值/收益？ 目前这个还没有看到什么官方资料，但我认为可供衡量的有： a.指标上线后是否直接被用做某些决策/运营依据？ b.指标上线后被各种报表等使用的pv/uv c.指标上线后ODS/DWD层使用率降低了多少

使用者用什么数分模型/商分模型？ 目前的主流应该是AAARR和OSM，因为已经足够普及本章不再复述

想从哪些商分视角看？这些视角下看的是什么指标？ 可以按照业务方向去归纳，并这里提供一个参考范例：

讲之前先声明一下阿里数仓体系的专业名词解释： 业务过程：企业的业务活动事件，如下单、支付、退款都是业务过程，不可拆分的业务行为事件 数据域：将业务过程或维度归纳和抽象后的集合，从业务归属角度来设计，对业务进行的一次抽象分组 这是阿里有而Kimball原版没有的步骤，因为阿里建模是要一站式建成OneData体系，所以力求把已有业务都归纳、定义和抽象提炼。且根据高内聚低耦合原则，把提炼出来的知识体系与迭代频繁的上层结构解耦，把不易变动的沉淀到基础结构里（当然仍需长期维护和更新），避免未来迭代中还需要动摇根基，以至上层模型也被迫跟着变动的情况。预期目标是划分数据域后，既能涵盖当前所有业务需求，又能在新业务进入时无影响地被包含进已有的数据域中和扩展新的数据域。

a. 明确业务过程所属数据域 b. 明确业务过程所属维度 c. 明确业务过程与维度的关系（矩阵） 维度——度量的环境，用来反映业务的一类属性，这类属性的集合构成一个维度，也可以称为实体对象（同E-R模型中的实体） 企业数据仓库总线架构 —— 一种架构性框架，通过关注业务过程，将DW/BI规划过程分解为可管理的模块，通过重用跨不同过程的标准化一致性维度实现集成。支持增量式建立DW/BI系统，也支持敏捷实现企业数据仓库总线矩阵 企业数据仓库总线矩阵 —— 用于设计并与总线架构交互的工具，矩阵的行表示业务过程，列表示维度，矩阵中的点表示维度与给定的业务过程是否存在关联关系。梳理总线矩阵时可以分析每一行以测试是否为业务过程定义好相关的候选维度，同时也能分析每个列，考虑某一维度需要跨多个业务过程并保持一致性。 可以按照上述步骤梳理数据域下的业务过程，再梳理业务过程对应的维度，已完成总线矩阵。在Kimball维度建模中本步骤对应着维度设计的1、2、3点，即选择业务过程，声明粒度，以及确认描述环境的维度。该步骤的预期产出是企业数据仓库总线矩阵图，如下：

明确每个业务过程下对应的：

阿里结合数仓建设经验和数据特点设计出的一套数据规范命名体系（数据标准在阿里Dataworks中又叫全局字段管理），应用于从数据域划分到模型设计的几个流程。包含步骤：

下图是整体流程图：

剩余的模型设计将会在第二章介绍，敬请期待。