MaxCompute数据仓库构建的整体流程。
数据明细层：DWD（Data Warehouse Detail）
数据服务层：DWS（Data WareHouse Service）
维表层：DIM（Dimension）
应用数据层(Application Data Store):ADS
基本概念
在正式学习本教程之前，您需要首先理解以下基本概念：
业务板块：比数据域更高维度的业务划分方法，适用于庞大的业务系统。
维度：维度建模由Ralph Kimball提出。维度模型主张从分析决策的需求出发构建模型，为分析需求服务。维度是度量的环境，是我们观察业务的角度，用来反映业务的一类属性 。属性的集合构成维度 ，也可以称为实体对象。例如， 在分析交易过程时，可以通过买家、卖家、商品和时间等维度描述交易发生的环境。（用数据库的表来描述好像并不准确，实际上是一种功能性的概念，数据域里的数据起到不同的作用来区分该数据是否属于一个维度）
属性（维度属性）：维度所包含的表示维度的列称为维度属性。维度属性是查询约束条件、分组和报表标签生成的基本来源，是数据易用性的关键。（可以理解为表的schema）
度量：在维度建模中，将度量称为事实 ，将环境描述为维度，维度是用于分析事实所需要的多样环境。度量通常为数值型数据，作为事实逻辑表的事实。（类似于一个真实数据的概念）
指标：指标分为原子指标和派生指标。原子指标是基于某一业务事件行为下的度量，是业务定义中不可再拆分的指标，是具有明确业务含义的名词 ，体现明确的业务统计口径和计算逻辑，例如支付金额。
原子指标=业务过程+度量。
派生指标=时间周期+修饰词+原子指标，派生指标可以理解为对原子指标业务统计范围的圈定。
业务限定：统计的业务范围，筛选出符合业务规则的记录（类似于SQL中where后的条件，不包括时间区间）。
统计周期：统计的时间范围，例如最近一天，最近30天等（类似于SQL中where后的时间条件）。
统计粒度：统计分析的对象或视角，定义数据需要汇总的程度，可理解为聚合运算时的分组条件（类似于SQL中的group by的对象）。粒度是维度的一个组合，指明您的统计范围。例如，某个指标是某个卖家在某个省份的成交额，则粒度就是卖家、地区这两个维度的组合。如果您需要统计全表的数据，则粒度为全表。在指定粒度时，您需要充分考虑到业务和维度的关系。统计粒度常作为派生指标的修饰词而存在。
业务调研
通过调查表和访谈等形式详细了解以下信息：
1.用户的组织架构和分工界面。
例如，用户可能分为数据分析、运营和维护部门人员，各个部门对数据仓库的需求不同，您需要对不同部门分别进行调研。
2.用户的整体业务架构，各个业务板块之间的联系和信息流动的流程。
您需要梳理出整体的业务数据框架。
3.各个已有的业务板块的主要功能及获取的数据。
进一步了解各业务板块中已有的数据功能模块。数据功能模块通常和业务板块紧耦合，对应一个或多个表，可以作为构建数据仓库的数据源。
需求分析的途径有两种：
根据与分析师和业务运营人员的沟通获知需求。
对报表系统中现有的报表进行研究分析。
在需求分析阶段，您需要沉淀出业务分析或报表中的指标，以及指标的定义和粒度。粒度可以作为维度的输入。建议您思考下列问题，对后续的数据建模将有巨大的帮助：
业务数据是根据什么（维度、粒度）汇总的，衡量标准是什么？
例如，成交量是维度，订单数是成交量的度量。明细数据层和汇总数据层应该如何设计？
公共维度层该如何设计？
是否有公共的指标？
数据是否需要冗余或沉淀到汇总数据层中？
分析业务过程
业务过程可以概括为一个个不可拆分的行为事件。用户的业务系统中，通过埋点或日常积累，通常已经获取了充足的业务数据。为理清数据之间的逻辑关系和流向，首先需要理解用户的业务过程，了解过程中涉及到的数据系统。
全面分析数据仓库涉及的源系统及业务管理系统：
每个业务会生成哪些数据，存在于什么数据库中。
对业务过程进行分解，了解过程中的每一个环节会产生哪些数据，数据的内容是什么。
数据在什么情况下会更新，更新的逻辑是什么。
划分数据域
数据域是指面向业务分析，将业务过程或者维度进行抽象的集合。为保障整个体系的生命力，数据域需要抽象提炼，并长期维护更新。在划分数据域时，既能涵盖当前所有的业务需求，又能让新业务在进入时可以被包含进已有的数据域或扩展新的数据域。数据域的划分工作可以在业务调研之后进行，需要分析各个业务模块中有哪些业务活动。
定义维度与构建总线矩阵
明确每个数据域下有哪些业务过程后，您需要开始定义维度，并基于维度构建总线矩阵。
在企业级数据仓库中必须保证维度的唯一性。
明确每个数据域下有哪些业务过程后，即可构建总线矩阵。您需要明确业务过程与哪些维度相关，并定义每个数据域下的业务过程和维度。
明确统计指标
需求调研输出的文档中，含有原子指标与派生指标，此时我们需要在设计汇总层表模型前完成指标的设计。
架构与模型设计
架构选型
在数据模型设计之前，您需要首先完成技术架构的选型。
使用阿里云大数据产品MaxCompute配合DataWorks，完成整体的数据建模和研发流程。
数仓分层
数据仓库分为三层，自下而上为：数据引入层（ODS，Operation Data Store）、数据公共层（CDM，Common Data Model）和数据应用层（ADS，Application Data Service）。
缓慢变化维度
MaxCompute不推荐使用代理键，推荐使用自然键作为维度主键，主要原因有两点：
MaxCompute是分布式计算引擎，生成全局唯一的代理键工作量非常大。当遇到大数据量情况下，这项工作就会更加复杂，且没有必要。
使用代理键会增加ETL的复杂性，从而增加ETL任务的开发和维护成本。
在不使用代理键的情况下，缓慢变化维度可以通过快照方式处理。
数据同步加载与处理
遵循以下规范：
一个系统的源表只允许同步到MaxCompute一次，保持表结构的一致性。
数据集成仅用于离线全量数据同步，实时增量数据同步需要您使用数据传输服务DTS实现，详情请参见数据传输服务DTS。
数据集成全量同步的数据直接进入全量表的当日分区。
ODS层的表建议以统计日期及时间分区表的方式存储，便于管理数据的存储成本和策略控制。
数据集成可以自适应处理源系统字段的变更：
如果源系统字段的目标表在MaxCompute上不存在，可以由数据集成自动添加不存在的表字段。
如果目标表的字段在源系统不存在，数据集成填充NULL
层次调用规范
完成数据仓库的分层后，您需要对各层次的数据之间的调用关系作出约定。
ADS应用层优先调用数据仓库公共层数据。如果已经存在CDM层数据，不允许ADS应用层跨过CDM中间层从ODS层重复加工数据。CDM中间层应该积极了解应用层数据的建设需求，将公用的数据沉淀到公共层，为其他数据层次提供数据服务。同时，ADS应用层也需积极配合CDM中间层进行持续的数据公共建设的改造。避免出现过度的ODS层引用、不合理的数据复制和子集合冗余。总体遵循的层次调用原则如下：
ODS层数据不能直接被应用层任务引用。如果中间层没有沉淀的ODS层数据，则通过CDM层的视图访问。CDM层视图必须使用调度程序进行封装，保持视图的可维护性与可管理性。
CDM层任务的深度不宜过大（建议不超过10层）。
一个计算刷新任务只允许一个输出表，特殊情况除外。
如果多个任务刷新输出一个表（不同任务插入不同的分区），DataWorks上需要建立一个虚拟任务，依赖多个任务的刷新和输出。通常，下游应该依赖此虚拟任务。
CDM汇总层优先调用CDM明细层，可累加指标计算。CDM汇总层尽量优先调用已经产出的粗粒度汇总层，避免大量汇总层数据直接从海量的明细数据层中计算得出。
CDM明细层累计快照事实表优先调用CDM事务型事实表，保持数据的一致性产出。
有针对性地建设CDM公共汇总层，避免应用层过度引用和依赖CDM层明细数据。
项目分配与安全
在为企业级大数据平台创建项目时，建议您对ODS层、DWD及DWS层的数据按照业务板块的粒度建立项目，对于ADS层的数据，按照应用的粒度建立项目。
建立性能基准
MaxCompute性能表现优劣，主要取决您的表设计是否符合规范。为方便您衡量MaxCompute表的性能表现，建议您在优化性能之前首先建立性能基准
数仓的优化
针对数仓的性能优化，主要是针对表和数据分布的优化。
表的其他优化技巧
建议您严格遵循表设计规范。此外，您还可以利用下列技巧完成表的优化：
中间表的利用：适用于数据量非常大，下游任务很多的表。
拆表：适用于个别字段产出极慢的情况，您可以将字段拆分为单独的表。
合表：随着数仓的发展，针对业务重叠或重复的表，您可以进行任务和数据合并。
拉链表：合理利用拉链表能减少您的存储消耗，关于拉链存储的详情请参见拉链存储。
结果验证
完成数仓的优化后，您需要对结果进行评估验证，确认优化的有效性。
如果您在优化过程中改变了表结构，您需要删除原有的表，并根据优化策略新建表和分区。本教程中提供的测试数据也需要进行对应的结构调整，方便您完成数据的导入。
