【模型实施】
如何从具体的需求或项目转换为可实施的解决方案，
如何进行需求分析、架构设计、详细模型设计等，
则是模型实施过程中讨论的内容。
本节先简单介绍业界常用的模型实施过程，
然后重点讲解阿里巴巴Ondata 模型设计理论及实施过程。
9.4.1 业界常用的模型实施过程
1 . Kimball 模型实施过程
Kimball 维度建模主要探讨需求分析、
高层模型、详细模型和模型审查整个过程。
构建维度模型一般要经历四个阶段：
第一个阶段是高层设计时期定义业务过程维度模型的范围，
提供每种星形模式的技术和功能描述；
第二个阶段是详细模型设计时期，
对每个星形模型添加属性和度量信息；
第三个阶段是进行模型的审查、再设计和验证等工作；
第四个阶段是产生详细设计文档，提交 ETL 设计和开发。
（1）高层模型
高层模型设计阶段的直接产出目标是创建高层维度模型图，
它是对业务过程中的维表和事实表的图形描述。
确定维表创建初始属性列表，为每个事实表创建提议度量。
（2）详细模型
详细的维度建模过程是为高层模型填补缺失的信息，
解决设计问题，并不断测试模型能否满足业务需求，
确保模型的完备性。
确定每个维表的属性和每个事实表的度量，
并确定信息来源的位置、定义，
确定属性和度量如何填入模型的初步业务规则。
（3）模型审查、再设计和验证
本阶段主要召集相关人员进行模型的审查和验证，
根据审查结果对详细维度进行再设计。
（4）提交 ETL 设计和开发
最后，完成模型详细设计文档，
提交 ETL 开发人员，进入ETL 计和开发阶段，
由 ETL 人员完成物理模型的设计和开发。
上述内容主要引用自 Ra lph Kimball 等的
The Datahouse _Lifecycle _Toolkit ，
具体细节请参考原著作。
2. Inmon 模型实施过程
Inmon 对数据模型的定位是：
扮演着通往数据仓库其他部分的智能路线图的角色。
由于数据仓库的建设不是一蹦而就的，
为了协调不同人员的工作以及适应不同类型的用户，
非常有必要建立 个路线图——数据模型，
描述数据仓库各部分是如何结合在一起的。
Inmon 将模型划分为三个层次，
分别是
ERD (Entity Relationship Diagram ，实体关系图）层、
DIS (Data Item Set 数据项集）层和
物理层（ Physical Model ，物理模型）。
ERD 层是数据模型的最高层，
该层描述了公司业务中的实体或主题域以及它们之间的关系；
ERD 层是中间层，
该层描述了数据模型中的关键字、属性以及细节数据之间的关系；
物理层是数据建模的最底层，
该层描述了数据模型的物理特性。
Inmon 对于构建数据仓库模型建议采用螺旋式开发方法，
采用迭代方式完成多次需求。
但需要采用统一的 ERD 模型，
才能够将每次迭代的结果整合在一起。
RD 模型是高度抽象的数据模型，
描述了企业完整的数据。
而每次迭代则是完成 RD 模型的子集，
通过 DIS 和物理数据模型实现。
上述内容主要引用自 Inmo Building _the _Data rehouse
具体 细节请参考原著作。
3. 其他模型实施过程
在实践中经常会用到如下数据仓库模型层次的划分，
和 Kimball、Inmon 的模型实施理论有一定的相通性，
但不涉及具体的模型表达。
业务建模
生成业务模型，主要解决业务层面的分解和程序化。
领域建模
生成领域模型，主要是对业务模型进行抽象处理，成领域概念模型。
逻辑建模
生成逻辑模型，
主要是将领域模型的概念实体以及实体之间的关系进行数据库层次的逻辑化。
物理建模
生成物理模型，主要解决逻辑模型针对不同关系数据库的物理化以及性能等一些具体的技术问题。
9.4.2 OneData 实施过程
本节重点讲解怎么使用 OneData 这套体系和相配套的工具实施
数据系统的模型建设，在讲解中会以阿里巴巴的具体业务进行说明
1.指导方针
首先，在建设大数据数据仓库时，
要进行充分的业务调研和 求分析。
这是数据仓库建设的基石，
业务调研和需求分析做得是否充分直接决定了数据仓库建设是否成功。
其次，进行数据总体架构设计，主要根据数据域对数据进行划分；
按照维度建模理论，构建总线矩阵、抽象出业务过程和维度。
再次，对报表需求进行抽象整理出相关指标体系，
使用 OneData 工具完成指标规范定义和模型设计。
最后，就是代码研发和运维。
2. 实施工作流
（1）数据调研
业务调研
整个阿里集团涉及的业务涵盖电商、数字娱乐、
导航（高德）、移动互联网服务等领域。
各个领域又涵盖多个业务线，
如电商领域就涵盖了C类（淘宝、天猫、天猫国际）
与B类（阿里巴巴中文站、国际站、速卖通）业务。
数据仓库是要涵盖所有业务领域，
还是各个业务领域独自建设，
业务领域内的业务线也同样面临着这个问题。
所以要构建大数据数据仓库，
就需要了解各个业务领域、业务线的业务有什么共同点和不同点 ，
以及各个业务线可以细分为哪几个业务模块，
每个业务模块具体的业务流程又是怎样的。
业务调研是否充分，将会直接决定数据仓库建设是否成功。
在阿里巴巴一般各个业务领域独自建设数据仓库，
业务领域内的业务线由于业务相似、业务相关性较大，
进行统一集中建设。
如表 9.3 所示是粗粒度的C类电商业务调研，
不难发现几个功能模块／业务线除了淘宝无供应链管理外，
其他几乎一样。
需求调研
可以想象一下，
在没有考虑分析师、业务运营人员的数据需求的情况下，
根据业务调研建设的数据仓库无疑等于闭门造车。
了解了业务系统的业务后并不代表就可以进行实施了，
此刻要做的就是收集数据使用者的需求，
可以去找分析师、业务运营人员了解他们有什么数据诉求，
此时更多的就是报表需求。
需求调研的途径有两种：
一是根据与分析师、业务运营人员的沟通 （邮件、 IM ）获知需求；
二是对报表系统中现有的报表进行研究分析。
通过需求调研分析后，就清楚数据要做成什么样的。
很多时候，
都是由具体的数据需求驱动数据仓库团队去了解业务系统的业务数据，
这两者并没有严格的先后顺序。
举例：分析师需要了解大淘宝（淘宝、天猫、天猫国际）一级类目
的成交金额。
当获知这个需求后，
我们要分析根据什么（维度）汇总，
以及汇总什么（度量），
这里类目是维度，金额是度量；
明细数据和汇总数据应该怎样设计？
这是一个公用的报表吗？
是需要沉淀到汇总里面，
还是在报表工具中进行汇总？
（2）架构设计
数据域划分
数据域是指面向业务分析，
将业务过程或者维度进行抽象的集合。
业务过程可以概括为 个个不可拆分的行为事件，如下单、支付、退款。
为保障整个体系 的生命力，
数据域需要抽象提炼，
并且长期维护和更新，
但不轻易变动。
在划分数据域时，
既能涵盖当前所有的业务需求，
又能在新业务进入时无影响地被包含进已有的数据域中或者扩展新的数据域。
如表 9.4 所示是功能模块／业务线的业务动作（部分示例）。
如表 9.5 所示是根据业务过程进行归纳，抽象出的数据域（部分示例）。
构建总线矩阵
在进行充分的业务调研和需求调研后，就要构建总线矩阵了。
需要做两件事情 ：明确每个数据域下有哪些业务过程；
业务过程与哪些维度相关，并定义每个数据域下的业务过程和维度。
如表 9.6 所示是供应链管理业务过程示例
（3）规范定义
规范定义主要定义指标体系，
包括原子指标、修饰词、时间周期和派生指标。
（4）模型设计
模型设计主要包括维度及属性的规范定义，
维表、明细事实表和汇总事实表的模型设计。
相关实践详解请参考后续章节。
（5）总结
OneData 的实施过程是一个高度迭代和动态的过程，
一般采用螺旋式实施方法。
在总体架构设计完成之后，
开始根据数据域进行迭代式模型设计和评审。
在架构设计、规范定义和模型设计等模型实施过程中，
都会引人评审机制，以确保模型实施过程的正确性。
若有收获，就点个赞吧
0 人点赞
