天险之路（下）

 有时候迈出一步，需要勇气。

---

维度设计

维度设计基础

        维度使用主键标识其唯一性，主键也是确保与之相连的任何事实表之间存在引用完整性的基础。主键有两种：代理键和自然键，它们都是用于标识某维度的具体值。

维度设计方法

1. 选择维度或新建维度。作为维度建模的核心，在企业级数据仓库中必须保证维度的唯一性。
2. 确定主维表。
3. 确定相关维表。
4. 确定维度属性。
   1. 尽可能生成丰富的维度属性。
   2. 尽可能多地给出包括一些富有意义的文字描述。
   3. 区分数值型属性和事实
   4. 尽量沉淀出通用的维度属性

维度的层次结构

        维度中的一些描述属性以层次方式或一对多的方式相互关联，可以被理解为包含连续主从关系的属性层次。层次的最底层代表维度中描述最低级别的详细信息，最高层代表最高级别的概要信息。

规范化和反规范化

        采用雪花模式，除了可以节约一部分存储外，对于 OLAP 系统来说没有其他效用 。而现阶段存储的成本非常低。出于易用性和性能的考虑，维表一般是很不规范化的 。 在实际应用中，几乎总是使用维表的空间来换取简明性和查询性能。

一致性维度和交叉探查

1. 共享维表。 比如在阿里巴巴的数据仓库中，商品、卖家、买家、类目等维度有且只有一个。所以基于这些公共维度进行的交叉探查不会存在任何问题。
2. 一致性上卷，其中一个维度的维度属性是另一个维度的维度属性的子集，且两个维度的公共维度属性结构和内容相同。比如在阿里巴巴的商品体系中，有商品维度和类目维度，其中类目维度的维度属性是商品维度的维度属性的子集，且有相同的维度属性和维度属性值。这样基于类目维度进行不同业务过程的交叉探查也不会存在任何问题。
3. 交叉属性，两个维度具有部分相同的维度属性。比如在商品维度中具有类目属性，在卖家维度中具有主营类目属性，两个维度具有相同的类目属性，则可以在相同的类目属性上进行不同业务过程的交叉探查。

维度设计高级主题

维度整合

• 命名规范的统一。表名 、 字段名等统一。
• 字段类型的统一。 相同和相似字段的字段类型统一。
• 公共代码及代码值的统一。公共代码及标志性宇段的数据类型、命名方式等统一。·
• 业务含义相同的表的统一。主要依据高内聚、低稠合的理念，在物理实现中，将业务关系大、源系统影响差异小的表进行整合：将业务关系小、游、系统影响差异大的表进行分而置之。通常有如下几种集成方式：
  • 采用主从表的设计方式，将两个表或多个表都有的字段放在主表中（主要基本信息），从属信息分别放在各自的从表中。对于主表中的主键，要么采用复合主键、源主键和系统或表区别标志：要么采用唯一主键、“游、主键和系统或表区别标志”生成新的主键。通常建议采用复合主键的方式。
  • 直接合并，共有信息和个性信息都放在同一个表中。如果表字段的重合度较低，则会出现大量空值，对于存储和易用性会有影响，需谨慎选择。
  • 不合并，因为源表的表结构及主键等差异很大，无法合并，使用数据仓库里的多个表存放各自的数。

表整合

1. 垂直整合，即不同的来源表包含相同的数据集，只是存储的信息不同。比如淘宝会员在源系统中有多个表，如会员基础信息表、会员扩展信息表、淘宝会员等级信息表、天猫会员等级信息表，这些表都属于会员相关信息表，依据维度设计方法，尽量整合至会员维度模型中，丰富其维度属性。
2. 水平整合，即不同的来源表包含不同的数据集，不同子集之间无交叉，也可以存在部分交叉。如果进行整合，首先需要考虑各个会员体系是否有交叉，如果存在交叉，则需要去重；如果不存在交叉，则需要考虑不同子集的自然键是否存在冲突，如果不冲突，则可以考虑将各子集的自然键作为整合后的表的自然键；另一种方式是设置超自然键，将来源表各子集的自然键加工成一个字段作为超自然键。

水平拆分

方法一：将维度的不同分类实例化为不同的维度，同时在主维度中保存公共属性。

方法二：是维护单一维度，包含所有可能的属性。

考虑原则：

• 扩展性：当源系统、业务逻辑变化时，能通过较少的成本快速扩展模型，保持核心模型的相对稳定性。软件工程中的高内聚、低稠合的思想是重要的指导方针之一 。·
• 效能： 在性能和成本方面取得平衡。通过牺牲一定的存储成本，达到性能和逻辑的优化。
• 易用性：模型可理解性高、访问复杂度低。用户能够方便地从模型中找到对应的数据表，并能够方便地查询和

依据：

依据1：维度的不同分类的属性差异情况。当维度属性随类型变化较大时，将不能将所有可能的属性建立在一个表中。

依据2：是业务的关联程度。两个相关性较低的业务，稠合在一起弊大于利，对模型的稳定性和易用性影响较大。

垂直拆分

在进行维度设计时，依据维度设计的原则，尽可能丰富维度属性，同时进行反规范化处理。

历史归档

在数据仓库中，可以借用前台数据库的归档策略 ， 定期将历史数据归档至历史维表。

策略

归档策略1：同前台归档策略，在数据仓库中实现前台归档算法，定期对历史数据进行归档。但存在一些问题，一是前台归档策略复杂，实现成本较高 ； 二是前台归档策略可能会经常变化 ， 导致数据仓库归档算法也要随之变化，维护和沟通成本较高。此方式适用于前台归档策略逻辑较为简单，且变更不频繁的情况。

归档策略2：用的数据抽取策略一般是通过数据库binlog 日志解析获取每日增量，通过增量 merge 全量的方式获取最新的全量数据。可以使用增量日志的删除标志， 作为前台数据归档的标志。通过此标志对数据仓库的数据进行归档。

归档策略3：数据仓库自定义归档策略。可以将归档算法用简单、直接的方式实现，但原则是尽量比前台应用晚归档、少归档。避免出现数据仓库中已经归档的数据再次更新的情况。

维度变化

缓慢变化维

1. 重写维度值。
2. 插入新的维度行。
3. 添加维度列。

快照维表

数据仓库的计算周期一般是每天一次，基于此周期，处理维度变化的方式就是每天保留一份全量快照数据。

极限存储

1. 透明化

底层的数据还是历史拉链存储，但是上层做一个视图操作或者在Hive 里做一个 hook，通过分析语句的语法树，把对极限存储前的表的查询转换成对极限存储表的查询。

1. 分月做历史拉链表

 微型维度

通过将一部分不稳定的属性从主维度中移出，并将它们放置到拥有自己代理键的新表中来实现。

以淘宝为例：

 缺点：

• 微型维度的局限性。微型维度是事先用所有可能值的组合加载的，需要考虑每个属性的基数，且必须是枚举值。很多属性可能是非枚举型，比如数值类型，如 VIP 分数、信用分数等；时间类型，如上架时间、下架时间、变更时间等。
• ETL 逻辑复杂。对于分布式系统，生成代理键和使用代理键进行ETL 加工都非常复杂， ETL 开发和维护成本过高。
• 破坏了维度的可浏览性。买家维度和微型维度通过事实表建立联系，无法基于 VIP 等级、信用等级进行浏览和统计。可以通过在买家维度中添加引用微型维度的外键部分来解决此问题，但带来的问题是微型维度未维护历史信息。

特殊维度

递归层级

按照层级是否固定分为均衡层次结构和非均衡层次结构。

比如类目，有固定数量的级别，分别是叶子类目、五级类 目、四级类目、三级类目、二级类目、 一级类目。

层次结构扁平化

通过建立维度的固定数量级别的属性来实现，可以在一定程度上解决上钻和下钻的问题。对于均衡层次结构，采用扁平化最有效。

层次桥接表

行为维度

1. 另一个维度的过去行为，如买家最近一次访问淘宝的时间、 买家最近一次发生淘宝交易的时间等。
2. 快照事实行为维度，如买家从年初截至当前的淘宝交易金额、买家信用分值、卖家信用分值等。
3. 分组事实行为维度，将数值型事实转换为枚举值。如买家从年初截至当前的淘宝交易金额按照金额划分的等级 、 买家信用分值按照分数划分得到的信用等级等。
4. 复杂逻辑事实行为维度，通过复杂算法加工或多个事实综合加工得到。如前面提到的卖家主营类目，商品热度根据访问、收藏、加人购物车、交易等情况综合计算得。

原则：

1. 避免维度过快增长。比如对商品表进行了极限存储，如果将商品热度加入现有的商品维表中，则可能会使每日商品变更占比过高，从而导致极限存储效果较差。
2. 避免稠合度过高。 比如卖家主营类目，加工逻辑异常复杂，如果融合进现有的卖家维表中，那么过多的业务稠合会导致卖家维表刷新逻辑复杂、维护性差、产出延迟等。

多值维度

1. 降低事实表的粒度。
2. 采用多字段。
3. 桥接表。

多值属性

1. 保持维度主键不变，将多值属性放在维度的一个属性字段中。
2. 保持维度主键不变，但将多值属性放在维度的多个属性字段中

         3.维度主键发生变化， 一个维度值存放多条记录。

杂项维度

        将这些字段建立到一个维表中，在事实表中只需保存一个外键即可。多个字段的不同取值组成一条记录，生成代理键，存人维表中，并将该代理键保存到相应的事实表字段下。建议不要直接使用所有的组合生成完整的杂项维表，在抽取遇到新的组合时生成相应的记录即可。杂项维度的 ETL 过程比一般的维度略微复杂些。

事实表设计

粒度：一种是维度属性组合所表示的细节程度；一种是所表示的具体业务含义。

事实表设计

设计原则

1. 尽可能包含所有与业务相关的事实。
2. 只选择与业务过程相关的事实。
3. 分解不可加性事实为可加的组件。
4. 在选择维度和事实之前必须先声明粒度。
5. 在同一个事实表中不能有多种不同粒度的事实。
6. 事实的单位要保持一致。
7. 对事实的null值要处理。
8. 使用退化维度提高事实表的易用性。

事实表设计方法

        1.选择业务过程及确定事实表类型

        2.声明粒度（尽量选择最细级别的原子粒度，以确保事实表的应用具有最大的灵活性。）

        3.确定维度

        4.确定事实

        5.冗余维度

事务事实表

设计过程

        事务事实表， 即针对这些过程构建的一类事实表，用以跟踪定义业务过程的个体行为，提供丰富的分析能力，作为数据仓库原子的明细数据。

单事务事实表

        单事务事实表，顾名思义，即针对每个业务过程设计一个事实表。这样设计的优点不言而喻，可以方便地对每个业务过程进行独立的分析研究。

多事务事实表

        多事务事实表 ， 将不同的事实放到同一个事实表中，即同一个事实表包含不同的业务过程。多事务事实表在设计时有两种方法进行事实的处理： ①不同业务过程的事实使用不同的事实字段进行存放：①不同业务过程的事实使用同一个事实字段进行存放，但增加一个业务过程标签。

两种事实表对比

计算存储成本

        

1. 事实完整性

事实表包含与其描述的过程有关的所有事实，即尽可能多地获取所有的度量。

1. 事实一致性

在确定事务事实表的事实时，明确存储每一个事实以确保度量的一致性。

1. 事实可加性

        事实表确定事实时，往往会遇到非可加性度量，比如分摊比例、 利润率等，虽然它们也是下游分析的关键点，但往往在事务事实表中关注更多的是可加性事实，下游用户在聚合统计时更加方便。

周期快照事实表

        快照事实表的设计有一些区别于事务事实表设计的性质。事务事实表的粒度能以多种方式表达，但快照事实表的粒度通常以维度形式声明$事务事实表是稀疏的，但快照事实表是稠密的； 事务事实表中的事实是完全可加的，但快照模型将至少包含一个用来展示半可加性质的事实。

特性

        1.用快照采样状态

         2.快照粒度

        事务事实表的粒度可以通过业务过程中所涉及的细节程度来描述，但快照事实表的粒度通常总是被多维声明，可以简单地理解为快照需要采样的周期以及什么将被采样。

        3.密度与稀疏性

        快照事实表和事务事实表的一个关键区别在密度上。事务事实表是稀疏的，只有当天发生的业务过程，事实表才会记录该业务过程的事实，如下单、支付等；而快照事实表是稠密的，无论当天是否有业务过程发生，都会记录一行。

        4.半可加性

        在快照事实表中收集到的状态度量都是半可加的。

实例

        由于通过事务事实表聚集效率较低，而采用周期快照事实表则是可行的方案。

1. 单维度的每天快照事实表
   1. 确定粒度
   2. 确定状态度量

1. 混合维度的每天快照事实

        例：淘宝卖家信用分和 DSR快照事实表

        是直接采用操作型系统数据进行设计加工，采样周期是每天，针对卖家维度的统计，状态度量就是卖家信用分和 DSR评分。

1. 全量快照事实表
   1. 确定粒度
   2. 确定状态度量

注意事项

1. 事务与快照成对设计

数据仓库维度建模时，对于事务事实表和快照事实表往往都是成对设计的，互相补充，以满足更多的下游统计分析需求，特别是在事务事实表的基础上可以加工快照事实表。

1. 附加事实

快照事实表在确定状态度量时， 一般都是保存采样周期结束时的状态度量。

1. 周期到日期度量

因此在确定周期快照事实表的度量时，也要考虑类似的度量值，以满足更多的统计分析需求。数据仓库在设计周期快照事实表时，就需针对多种周期到日期的度量设计了不同的快照事实表。

累积快照事实表

        对于类似于研究事件之间时间间隔的需求，采用累积快照事实表可以很好地解决。

1. 选择业务过程
2. 确定粒度
3. 确定维度
4. 确定事实
5. 退化维度

特点

1. 数据不断更新
2. 多业务过程日期

特殊处理

1. 非线性过程（业务过程的统一、针对业务关键里程碑构建全面的流程、循环流程的处理）
2. 多源过程

        针对多业务过程建模时，业务过程可能来自于不同的系统或者来源于不同的表，其对于累积快照事实表的模型设计没有影响，但会影响ETL 开发的复杂程度。

1. 业务过程取舍

        当拥有大量的业务过程时，模型的实现复杂度会增加，特别是对于多源业务过程，模型的精合度过高，此时需要根据商业用户需求，选取关键的里程碑。

实现

1. 全量表的形式：每天的分区存储昨天的全量数据和当天的增量数据合并的结果，保证每条记录的状态最新。 此种方式适用于全量数据较少的情况。
2. 全量表的变化形式：主要针对事实表数据量很大的情况。较短生命周期的业务实体一般从产生到消亡都有一定的时间间隔，可以测算此时间间隔，或者根据商业用户的需求确定一个相对较大的时间间隔。
3. 以业务实体的结束时间区分：每天的分区存放当天结束的数据，设计一个时间非常大的分区，比如 3000-12-31 ，存放截至当前未结束的数据。可能存在业务系统无法标识业务实体的结束时间，可使用相关业务系统的业务实体的结束标志作为此业务系统的结束标志，或和前端业务系统确定口径或使用前端归档策略。

三种事实表的比较

        事务事实表记录的事务层面的事实，用于跟踪业务过程的行为，并支持几种描述行为的事实，保存的是最原子的数据，也称为“原子事实表”。事务事实表中的数据在事务事件发生后产生，数据的粒度通常是每个事务一条记录。 一旦事务被提交，事实表数据被插人，数据就不能更改，其更新方式为增量更新。

无事实的事实表

        在维度模型中，事实表用事实来度量业务过程，不包含事实或度的事实表称为“无事实的事实表”虽然没有明确的事实，但可以用来支持业务过程的度量。

        有两种情况：

        1.事件类的，记录事件的发生.

        2.是条件、范围或资格类.

聚集型事实表

        聚集主要是通过汇总明细粒度数据来获得改进查询性能的效果。通过访问聚集数据，可以减少数据库在响应查询时必须执行的工作量，能够快速响应用户的查询，同时有利于减少不同用户访问明细数据带来的结果不一致问题。尽管聚集能带来良好的收益，但需要事先对其进行加载和维护 ，这将会对给 ETL 带来更多的挑战。

聚集的基本原则

• 一致性：聚集表必须提供与查询明细粒度数据一致的查询结果。从设计角度来看，确保一致性，最简单的方法是确保聚集星形模型中的维度和度量与原始模型中的维度和度量保持一致。
• 避免单一设计：不要在同一个表中存储不同层次的聚集数据 ；否则将会导致双重计算或出现更糟糕的事情。在聚集表中有些行存放按天汇总的交易额，有些行存放按月汇总的交易额 ， 这将会让使用者产生误用导致重复计算。
• 聚集粒度可不同：聚集并不需要保持与原始明细粒度数据一样的粒度，聚集只关心所需要查询的维度。

聚集的基本步骤

1. 确定聚集维度
2. 确定一致性上钻
3. 确定聚集事实

公共汇总层

基本原则

1. 数据公用性
2. 不跨数据域
3. 区分退统计周期

交易汇总表设计

1. 按商品粒度汇总

• 确定聚集维度一一商品。
• 确定一致性上钻一一按商品（商品 ID）最近l 天汇总。
• 确定聚集事实一一下单量、交易额。

1. 按卖家粒度汇总

• 确定聚集维度卖家。
• 确定一致性上钻一一按卖家（卖家 ID）最近 7 天和最近 30 天汇总。
• 确定聚集事实一一交易额。

1. 按卖家、买家、商品粒度汇总

• 确定聚集维度一一卖家、买家、商品。
• 确定一致性上钻一一按卖家（卖家 ID ）、买家（买家 ID ）、 商品（商品 ID）最近l 天汇总。
• 确定聚集事实一交易额。

1. 按二级类目汇总

• 确定聚集维度一一类目。
• 确定一致性上钻——按最近l 天类目维度的二级维度属性汇总。
• 确定聚集事实一一交易额。

聚集的其它事项

1. 聚集是不跨越事实的

聚集是针对原始星形模型进行的汇总，为了获取和查询与原始模型一致的结果，聚集的维度和度量必须与原始模型保持一致，因此聚集是不跨越事实的。

1. 聚集带来的问题

聚集会带来查询性能的提升，但聚集也会增加 ETL 维护的难度。当子类目对应的一级类目发生变更时，先前存在的、已经被汇总到聚集表中的数据需要被重新调整。

元数据

元数据概述

元数据定义

        元数据（ Metadata）是关于数据的数据。元数据打通了源数据、数据仓库、数据应用，记录了数据从产生到消费的全过程。元数据主要记录数据仓库中模型的定义、各层级间的映射关系、监控数据仓库的数据状态及 ETL 的任务运行状态。

        根据用途可分为两类：技术元数据（ TechnicalMetadata) 和业务元数据（ Business Metadata）

阿里巴巴中常见的的技术元数据：

• 分布式计算系统存储元数据
• 分布式计算系统运行元数据
• 数据开发平台中数据同步、计算任务、任务调度等信息
• 数据质量和运维相关元数据

阿里巴巴中常见的的业务元数据：

• OneData 元数据
• 数据应用元数据

元数据价值

是数据管理、数据内容、数据应用的基础，在数据管理方面为集团数据提供在计算、存储、成本、质量、安全、模型等治理领域上的数据支持。

统一元数据体系建设

元数据应用

        数据的真正价值在于数据驱动决策，通过数据指导运营。通过数据驱动的方法，我们能够判断趋势，从而展开有效行动，帮助自己发现问题，推动创新或解决方案的产生。

Data ProFile

        承担的是为元数据“画像”的任务。通过图计算、标签传播算法等技术，系统化、自动化地对计算与存储平台上的数据进行打标、整理、归档。

• 基础标签：针对数据的存储情况、访问情况、安全等级等进行打标。
• 数仓标签：针对数据是增量还是全量、是否可再生、数据的生命周期来进行标签化处理。
• 业务标签：根据数据归属的主题域、产品线、业务类型为数据打上不同的标签。
• 潜在标签：这类标签主要是为了说明数据潜在的应用场景， 比如社交、媒体、广告、电商、金融等

元数据门户

        元数据门户致力打造一站式的数据管理平台、高效的一体化数据市场。

        分为“前台”和“后台”。“前台”产品为数据地图，定位消费市场，实现检索数据 、 理解数据等“找数据”需求 E“后台”产品为数据管理，定位于一站式数据管理，实现成本管理、安全管理、质量管理等。

        数据地图围绕数据搜索，服务于数据分析、数据开发、数据挖掘、算法工程师、数据运营等数据表的使用者和拥有者，提供方便快捷的数据搜索服务，拥有功能强大的血缘信息及影响分析，利用表使用说明、评价反馈、表收藏及精品表机制，为用户浮现高质量、高保障的目标数据。

        数据管理平台围绕数据管理，服务于个人开发者 、 BU 管理者、系统管理员等用户，提供个人和 BU 全局资产管理、成本管理和质量管理等。针对个人开发者，主要包括计算费用和健康分管理、存储费用和健康分管理，并提供优化建议和优化接口：针对 BU 管理者和管理员，主要提供 BU、应用、集群等全局资产消耗概览、分析和预测。

应用链路分析

        通过应用链路分析，产出表级血缘、字段血缘和表的应用血缘。

        主要有两种计算方式：一种是通过 MaxCompute 任务日志进行解析；一种是根据任务依赖进行解析。

数据建模

        通过元数据驱动的数据仓库模型建设，可以在一定程度上解决此问题，提高数据仓库建模的数据化指导，提升建模效率。

• 表的基础元数据，包括下游情况、查询次数、关联次数、聚合次数、产出时间等。
• 表的关联关系元数据，包括关联表、关联类型、关联字段、关联次数等。
• 表的字段的基础元数据，包括字段名称、字段注释、查询次数、关联次数、聚合次数、过滤次数等。

在星形模型设计过程中，可能类似于如下使用元数据。

• 基于下游使用中关联次数大于某个阔值的表或查询次数大于某个阐值的表等元数据信息，筛选用于数据模型建设的表。
• 基于表的字段元数据，如字段中的时间字段、字段在下游使用中的过滤次数等，选择业务过程标识字段。
• 基于主从表的关联关系、关联次数，确定和主表关联的从表。
• 基于主从表的字段使用情况，如字段的查询次数、过滤次数、关联次数、聚合次数等，确定哪些字段进入目标模型。

驱动ETL开发

计算管理

        如何降低计算资源的消耗，提高任务执行的性能，提升任务产出的时间，是计算平台和 ETL 开发工程师孜孜追求的目标。

系统优化

        MaxCompute 采用各种抽样统计算法，通过较少的资源获得大量的统计信息，基于先进的优化模型，具备了完善的 CBO 能力，与传统的大数据计算系统相比，性能提升明显。

HBO

        HBO 是根据任务历史执行情况为任务分配更合理的资源，包括内存、 CPU 以及 Instance 个数。

        HBO 是对集群资源分配的一种优化，概括起来就是：任务执行历史＋集群状态信息＋优化规则→更优的执行配置。

        通过数据分析，发现在系统中存在大量的周期性调度的脚本（物理计划稳定），且这些脚本的输入一般比较稳定，如果能对这部分脚本进行优化，那么对整个集群的计算资源的使用率将会得到显著提升。HBO 一般通过自造应调整系统参数来达到控制计算资源。

1. 基础资源数量的逻辑

        对于MapTask，系统需要初始化不同的输入数据量，根据期望的每个Map能处理的数据量，再结合用户提交任务的输入数据量，就可以估算出用户提交的任务所需要的Map数量。

        对于ReduceTask，比较Hive使用Map输入数据量，MaxCompute使用最近7天Reduce对应Map的平均输出数据量作为Reduce的输入数据量，用于计算Instance的数量。对于Reduce个数的估算与Map估算基本相同，不再赘述。

1. 加权资源数量的逻辑

        对于MapTask，系统需要初始化期望的每个Map能处理的数据量。通过该Map在最近一段时间内的平均处理速度与系统设定的期望值做比较，如果平均处理速度小于期望值，则按照同等比例对基础资源数量进行加权，估算出该Map的加权资源数量。

        最终的Instance个数为：基础资源估算值＋加权资源估算值。

HBO好处：

1. 提高CPU利用率
2. 提高内存利用率
3. 提高Instance并发数
4. 降低执行时长

CBO

        MaxCompute 2.0 引人了基于代价的优化器（ CBO），根据收集的统计信息来计算每种执行方式的代价，进而选择最优的执行方式。

优化器原理

        优化器（ Optimizer）引人了 Volcano 模型（请参考论文： TheVolcano Optimizer Generαtor: Extensibility and ξfficient Search ），该模型是基于代价的优化器（ CBO），并且引人了重新排序 Join(Join Reorder）和 自动 MapJoin(Auto MapJoin）优化规则等，同时基于 Volcano 模型的优化器会尽最大的搜索宽度来获取最优计划。

Meta Manager

        Meta 模块主要提供元数据信息，包括表的元数据、统计信息元数据等。当优化器在选择计划时，需要根据元数据的一些信息进行优化。

Statistics

        Statistics 主要是帮助优化器选择计划时，提供准确的统计信息，的统计信息，如表的 Count 值、列的 Distinct 值、 TopN值等。

Rule Set

        优化规则是根据不同情况选择不同的优化点，然后由优化器根据代价模型（ CostModel ）来选择启用哪些优化规则。

Volcano Planner Core

        Volcano Planner 是整个优化器的灵魂，它会将所有信息（ Meta 信息、统计信息、规则）统一起来处理，然后根据代价模型的计算，获得一个最优计划。

        Planner 的创建主要是将 Planner 在优化过程中要用到的信息传递给执行计划器，比如规则集，用户指定要使用的规划：MetaProvider，每个Re IN ode 的 Meta计算，如 RowCount 值计算、 Distinct值计算等；代价模型，计算每个 RelNode 的代价等。这些都是为以后 Planner提供的必要信息。

优化器新特性

        优化器具有一些新特性，主要是重新排序 Join(Join Reorder）和自动 MapJoin(Auto MapJoin ）。

1.重新排序Join

        重新排序 Join可以认为是将 Join 的所有不同输入进行一个全排列，然后找到代价最小的一个排列。

2.自动 MapJoin

        Join 实现算法有多种，目前主要有 Merge Join 和 MapJoin。对于小数据量， MapJoin 比 Merge Join性能更优。之前是通过 Hint方式来指定是否使用MapJoin，这样对用户不是很友好，且使用不方便。自动MapJoin 充分利用优化器的代价模型进行估算，获得更优的MapJoin方式，而不是通过Hint方式来进行处理。

3.优化器使用

        优化器提供的 Flag 有：

        规则白名单一一odps.optimizer.cbo.rule.filter.white

        规则黑名单一－odps.optimizer.cbo.rule.filter.black

        如果用户需要使用哪些优化规则，只要将规则的缩写名称加人白名单即可；反之，需要关闭哪些优化规则，只要将名称加入黑名单即可。

4.注意事项

        Optimizer会提供谓词下推（ PredicatePush Down）优化，主要目的是尽量早地进行谓词过滤，以减少后续操作的数据量，提高性能。但需要注意的是：

        UDF

        如果用户需要下推 UDF，则要自己改动 SQL，这样做主要的好处是用户自己控制 UDF 执行的逻辑，最了解自己的 UDF 使用在 SQL的哪个部分，而不是优化器任意下推等。

不确定函数

        对于不确定函数，优化器也不会任意下推。

隐式类型转换

        书写 SQL 语句时 ， 应尽量避免 Jo in Key 存在隐式类型转换。

任务优化

        SQL/MR在MaxCompute中的细分步骤。

        在MaxCompute中会生成MaxCompute Instance，通过唯一ID进行标识。

• Fuxi Job：对于MaxCompute Instance，则会生成一个或多个由Fuxi Task组成的有向无环图，即Fuxi Job。
• Fuxi Task：主要包含三种类型，分别是Map、Reduce和Join，类似于Hive中Task的概念。
• Fuxi Instance：真正的计算单元，和Hive中的概念类似，一般和槽位（slot）对应。

Map倾斜

        Map 端是 MR 任务的起始阶段， Map 端的主要功能是从磁盘中将数据读人内存。

        在 Map 端读数据时，由于读入数据的文件大小分布不均匀，因此会导致有些 MapInstance 读取并且处理的数据特别多，而有些 MapInstance 处理的数据特别少，造成 Map 端长尾。

        Map 端长尾的根本原因是由于读人的文件块的数据分布不均匀，再加上 UDF 函数性能、Join、聚合操作等，导致读人数据量大的 Maplnstance 耗时较长。在开发过程中如果遇到 Map 端长尾的情况，首先考虑如何让 Map Instance 读取的数据量足够均匀，然后判断是哪些操作导致 MapInstance 比较慢，最后考虑这些操作是否必须在 Map 端完成 ，在其他阶段是否会做得更好。

Join倾斜

        Join 操作需要参与 Map 和 Reduce 的整个阶段。出， MaxCompute SQL 在 Join 执行阶段会将 Join Key 相同的数据分发到同一个执行 Instance上处理。如果某个Key 上的数据量比较大，则会导致该 Instance 执行时间较长。

        可根据相应原因给出对应的解决方案：

• Join 的某路输入比较小，可以采用 MapJoin，避免分发引起长尾。
• Join 的每路输入都较大，且长尾是空值导致的，可以将空值处理成随机值，避免聚集。
• Join 的每路输入都较大，且长尾是热点值导致的，可以对热点值和非热点值分别进行处理，再合并数据。

解决方法

1. MapJion方法

MapJoin 的原理是将 Join 操作提前到 Map 端执行， 将小表读人内存，顺序扫描大表完成 Join。这样可以避免因为分发 key 不均匀导致数据倾斜。

1. Join因为空值导致尾长

如果关联 key 为空值且数据量比较大，Join 时就会因为空值的聚集导致长尾，针对这种情况可以将空值处理成随机值。

1. Join因为热点值导致长尾

        如果是因为热点值导致的长尾，并且Join 的输入比较大无法使用MapJoin，则可以先将热点 key 取出，对于主表数据用热点 key 切分成热点数据和非热点数据两部分分别处理，最后合并。

Reduce倾斜

        Reduce端负责的是对 Map端梳理后的有．序 key-value键值对进行聚合，即进行 Count 、 Sum 、Avg 等聚合操作，得到最终聚合的结果。

        Distinct 是 MaxCompute SQL 中支持的语法，用于对字段去重。比如计算在某个时间段内支付买家数、访问 UV 等，都是需要用Distinct进行去重的。 MaxCompute 中 Distinct 的执行原理是将需要去重的宇段以及 Group By 宇段联合作为 key将数据分发到Reduce端。

        因为 Distinct操作，数据无法在 Map端的 Shuffle 阶段根据 GroupBy 先做一次聚合操作，以减少传输的数据量，而是将所有的数据都传输到Reduce 端，当 key 的数据分发不均匀时，就会导致 Reduce 端长尾。

        Reduce 端产生长尾的主要原因就是 key 的数据分布不均匀。比如有些 Reduce 任务 Instance 处理的数据记录多，有些处理的数据记录少，造成 Reduce 端长尾。如下几种情况会造成 Reduce端长尾：

• 对同一个表按照维度对不同的列进行 CountDistinct 操作，造成Map 端数据膨胀，从而使得下游的 Join 和 Reduce 出现链路上的长尾。
• Map 端直接做聚合时出现 key值分布不均匀，造成 Reduce端长尾。
• 动态分区数过多时可能造成小文件过多，从而引起 Reduce端长尾。
• 多个 Distinct同时出现在一段 SQL代码中时，数据会被分发多次，不仅会造成数据膨胀 N倍，还会把长尾现象放大N倍。

解决方案

        MaxCompute对动态分区的处理是引人额外一级的 Reduce Task，把相同的目标分区交由同一个（或少量几个）Reduce Instance 来写人，避免小文件过多，并且这个 Reduce肯定是最后一个 Reduce Task 操作。

对 Multi Distinct 的思考

• 上述方案中如果出现多个需要去重的指标，那么在把不同指标Join 在一起之前， 一定要确保指标的粒度是原始表的数据粒度。比如支付买家数和支付商品数，在子查询中指标粒度分别是： 原始表的数据粒度＋ buyer_id 和原始表的数据粒度 ＋ item_id，这时两个指标不是同一数据粒度，所以不能 Join，需要再套一层代码，分别把指标 Group By 到“原始表的数据粒度”，然后再进行 Join操作。
• 修改前的 Multi Distinct 代码的可读性比较强，代码简洁，便于维护；修改后的代码较为复杂。当出现的 Distinct个数不多、表的数据量也不是很大、表的数据分布较均匀时，不使用MultiDistinct 的计算效果也是可以接受的。所以，在性能和代码简洁、可维护之间需要根据具体情况进行权衡。另外，这种代码改动还是比较大的，需要投入一定的时间成本，因此可以考虑做成自动化，通过检测代码、优化代码自动生成将会更加方便。
• 当代码比较膝肿时，也可以将上述子查询落到中间表里，这样数据模型更合理、复用性更强、层次更清晰。当需要去除类似的多个 Distinct 时，也可以查一下是否有更细粒度的表可用，避免重复计算。

存储和成本管理

        如何有效地降低存储资源的消耗，节省存储成本，将是存储管理孜孜追求的目标。本章主要从数据压缩、数据重分布、存储治理项优化、生命周期管理等的角度介绍存储管理优化。

数据压缩

        目前 MaxCompute 中提供了 archive 压缩方法，它采用了具有更高压缩比的压缩算法，可以将数据保存为 RAIDfile 的形式，数据不再简单地保存为 3 份，而是使用盘古 RAID file 的默认值（ 6 ,3）格式的文件，即 6 份数据＋3 份校验块的方式，这样能够有效地将存储比约为1:3 提高到1: 1.5，大约能够省下一半的物理空间。但使用archive压缩方式也有一定的风险，如果某个数据块出现损坏或者某台机器宕机损坏，回复数据块的时间将要比原来的方式更长，读的性能会有一定的损失。

数据重分布

        在 MaxCompute 中主要采用基于列存储的方式，由于每个表的数据分布不同，插人数据的顺序不一样，会导致压缩效果有很大的差异， 因此通过修改表的数据重分布，避免列热点，将会节省一定的存储空间。

存储治理项优化

        通过对该优化项的数据诊断 ， 形成治理项，治理项通过流程的方式进行运转、管理，最终推动各个 ETL 开发人员进行操作，优化存储管理，并及时回收优化的存储效果。在这个体系下，形成现状分析、 问题诊断、管理优化、效果反馈的存储治理项优化的闭环。通过这个闭环，可以有效地推进数据存储的优化，降低存储管理的成本。

生命周期管理

        数据的生命周期管理是存储管理的一项重要手段。生命周期管理的根本目的就是用最少的存储成本来满足最大的业务需求，使数据价值最大化。

生命周期管理策略

周期性删除策略

        所存储的数据都有一定的有效期，从数据创建开始到过时，可以周期性删除 X天前的数据。

彻底删除策略

        无用表数据或者 ETL 过程产生的临时数据，以及不需要保留的数据，可以进行及时删除，包括删除元数据。

永久保留策略

        重要且不可恢复的底层数据和应用数据需要永久保存。

极限存储策略

        极限存储可以超高压缩重复镜像数据，通过平台化配置手段实现透明访问。

冷数据管理策略

        冷数据管理是永久保留策略的扩展。永久保留的数据需要迁移到冷数据中心进行永久保存，同时将 MaxCompute 中对应的数据删除。

增量表merge全量表策略

        对于某些特定的数据，极限存储在使用性与存储成本方面的优势不是很明显，需要改成增量同步与全量 merge 的方式，对于对应的delta增量表的保留策略，目前默认保留 93天。

通用的生命周期管理矩阵

        主要通过对历史数据的等级划分与对表类型的划分生成相应的生命周期管理矩阵。

历史数据等级划分

P0：非常重要的主题域数据和非常重要的应用数据。

P1：重要的业务数据和重要的应用数据，具有不可恢复性。

P2：重要的业务数据和重要的应用数据，具有不可恢复性。

P3：不重要的业务数据和不重复的应用数据，具有可恢复性。

表类型划分

• 事件型流水表（增量表）
• 事件型镜像表（增量表）
• 维表
• Merge全量表
• ETL临时表
• TT临时数据
• 普通全量表

 

数据成本计量

        在计量数据表的成本时，除考虑数据表本身的计算成本、存储成本外，还要考虑对上游数据表的扫描带来的扫描成本。我们将数据成本定义为存储成本、计算成本和扫描成本三个部分。

数据质量

        随着 IT 向 DT 时代的转变，数据的重要性不言而喻，数据的应用也日趋繁茂，数据正扮演着一个极其重要的角色。

数据质量保障原则

        从四个方面进行评估，完整性、准确性、一致性和及时性。

完整性

        完整性是指数据的记录和信息是否完整，是否存在缺失的情况。数据的缺失主要包括记录的缺失和记录中某个字段信息的缺失，两者都会造成统计结果不准确。

准确性

        准确性是指数据中记录的信息和数据是否准确，是否存在异常或者错误的信息。

一致性

        一致性一般体现在跨度很大的数据仓库体系中，比如数据仓库，内部有很多业务数据仓库分支，对于同一份数据，必须保证一致性。

及时性

        在确保数据的完整性、准确性和一致性后，接下来就要保障数据能够及时产出，这样才能体现数据的价值。

数据质量方法

数据质量建设方法

        根据应用的影响程度，确定资产等级 ；根据数据链路血缘，将资产等级上推至各数据生产加工的各个环节，确定链路上所涉及数据的资产等级和在各加工环节上根据资产等级的不同所采取的不同处理方式。

数据生产加工各个环节卡点校验

        数据生产加工各个环节卡点校验部分主要包括在线系统和离线系统数据生产加工各个环节的卡点校验。

        在线系统生产加工各环节卡点校验主要包括两个方面：根据资产等级的不同，当对应的业务系统变更时，决定是否将变更通知下游；对于高资产等级的业务， 当出现新业务数据时，是否纳入统计中，需要卡点审批。

        离线系统生产加工各环节卡点校验主要包括代码开发、测试、发布和历史或错误数据回刷等环节的卡点校验，针对数据资产等级的不同，对校验的要求有所不同。

风险点监控

        分主要是针对在数据日常运行过程中可能出现的数据质量和时效等问题进行监控，包括在线数据和离线数据的风险点监控两个方面。

质量衡量

        根据质量问题对不同等级资产的影响程度，确定其是属于低影响的事件还是具有较大影响的故障。质量分则是综合事前和事后的衡量数据进行打分。

质量配套工具

        针对数据质量的各个方面，都有相关的工具进行保证，以提高效能。接下来将对数据质量保障的各个方面进行介绍。

数据资产

数据资产等级定义

        通过五个等级来定义数据资产等级。即毁灭性质、全局性质、局部性质、 一般性质和未知性质，不同性质的重要性依次降低，具体定义如下。

• A1：毁灭性质，即数据一旦出错，将会引起重大资产损失，面临重大收益损失，造成重大公关风险。
• A2：全局性质，即数据直接或者间接用于集团级业务和效果的评估、重要平台的运维、对外数据产品的透露、影响用户在阿里系网站的行为等。
• A3：局部性质，即数据直接或间接用于内部一般数据产品或者运营／产品报告，如果出现问题会给事业部或业务线造成影响，或者造成工作效率损失。
• A4：一般性质，即数据主要用于小二的日常数据分析，出现问题几乎不会带来影响或者带来的影响极小。
• Ax：未知性质，不能明确说出数据的应用场景，则标注为未知。

数据资产等级落地方法

        数据是从业务系统中产生的，经过同步工具进入数据仓库系统中，在数据仓库中进行一般意义上的清洗、加工、整合、算法、模型等一系列运算后，再通过同步工具输出到数据产品中进行消费。

        产品每一个页面的每一个模块基本上都是通过数据表输出展现的，不同模块数据的重要等级也就决定了相关表的重要等级，决定了这个导出表的重要等级。

数据加工过程卡点校验

风险点监控

质量衡量

数据质量起夜率

        前文在介绍数据及时性时已经提到，数据产品或者管理层决策日报一般都要求在上午 9:00 之前提供，数据仓库的作业任务都是在凌晨运行的， 一旦数据出现问题就需要开发人员起夜进行处理。

数据质量事件

        数据质量事件，首先，用来眼进数据质量问题的处理过程；其次，用来归纳分析数据质量原因 z 第三，根据数据质量原因来查缺补漏，既要找到数据出现问题的原因，也要针对类似问题给出后续预防方案。

数据质量故障体系

        对于严重的数据质量事件，将升级为故障。故障，是指问题造成的影响比较严重，已经给公司带来资产损失或者公关风险。

(1) 故障定义首先识别出重要的业务数据，并注册到系统中，填写相关的业务情况，如技术负责人、业务负责人、数据应用场景、延迟或错误带来的影响、是否会发生资产损失等，完成后，会将这部分数据的任务挂到平台基线上，一旦延迟或错误即自动生成故障单，形成故障。

(2）故障等级故障发生后，会根据一定的标准判断故障等级，如故障时长、客户投诉量、资金损失等，将故障按 pl ～ p4 定级，各团队会有故障分的概念，到年底会根据故障分情况来判断本年度的运维效果。

(3）故障处理故障发生后，需要快速地识别故障原因，并迅速解决，消除影响。在处理故障的过程中， 会尽快将故障的处理进度通知到相关方，尽可能减少对业务的影响。

(4）故障 Review对于故障会进行 Review，即分析故障的原因、处理过程的复盘、形成后续解决的Action，并且都会以文字的形式详细记录，对故障的责任进行归属，一般会到具体的责任人。注意，对故障责任的判定，不是为了惩罚个人，而是通过对故障的复盘形成解决方案，避免问题再次发生。

数据应用

        全球知名咨询公司麦肯锡称：“数据，已经渗透到当今每一个行业和业务职能领域，成为重要的生产要素。人们对于海量数据的挖掘和运用，预示着新一波生产率增长和消费者盈余浪潮的到。”

生意参谋

        为了保证用户体验，从 2014 年起，依托阿里巴巴内部的 OneData体系建设的、在数据一致性方面更具优势的生意参谋陆续整合量子恒道、数据魔方等其他数据产品，并在 2015 年年底升级为官方统一的商家数据产品平台。由此，商家只要通过生意参谋一个平台，就能体验统一、稳定、准确的官方数据服务。

        当然，长达两年的整合升级并不是简单地对多个数据产品进行功能整合，而是在保留其核心功能的同时，对其进行优化，同时不断拓展新平台的服务能力和服务范围。

        在整合量子恒道时，同步推出大促活动看板、实时直播大屏、实时直播大屏、自助取数等重要功能。

功能架构与技术能力

        在生意参谋上，“我情”的数据主要基于店铺经营全链路的各个环节进行设计。以“经营分析”为例，这个板块依次为商家提供流量、商品、交易、服务、物流、营销等不同环节的数据服务，不同服务还能再往下细分，如在“流量分析”下，还会再提供流量地图、访客分析、 装修分析等更细粒度的数据。基本上， 一个访客从未进店到进店，再到店内流转，最终交易转化，转化后的评价和物流情况都可以通过“经营分析” 一站式获取。

        生意参谋通过市场行情，为商家提供了行业维度的大盘分析，包括行业洞察、搜索词分析、人群画像等。其中，行业洞察可以从品牌、产品、属性、商品、店铺等粒度对本行业数据进行分析：通过搜索词分析可以了解不同关键词的近日表现，从而反推消费者偏好；人群画像能从人群维度人手，直接提供买家人群、卖家人群 、 搜索人群三大人群的数据洞察信息。

        平台背后看不见的“数据中台”给生意参谋提供了大量技术保障。例如，在体验方面，生意参谋的数据来自阿里巴巴大数据公共层 OneData 。 OneData 可以对集团内外数量繁多的数据进行规范化和数据建模，从根本上避免数据指标定义不一致、重复建设的问题，从而确保生意参谋对外数据口径标准统一，计算全面、精确。

        OneData 体系、 OneID 技术等在其中为生意参谋等数据产品提供了稳定的技术支持。

 

对内数据产品平台

定位

        通过数据产品将数据转化为用户更优做决策和行动的依据。数据产品有多种形态，包括最简单常见的报表、多维分析、专题分析型数据产品、智能型数据应用产品。

解决的痛点是用户对业务发展中的数据监控、问题分析、机会洞察、决策支持等诉求，提供给用户高效率获取数据、合理分析框架、数据辅助业务决策的价值。

目的

        对于高管和决策者，既需要宏观的业务数据，又需要可下沉的数据 ，还需要丰富的趋势数据来辅助决策，需要通过数据了解业务进展、当前进展是否合理、接下来的业务方向等，针对此类需求提供定制化的数据产品供决策参考，为高管提供宏观决策分析支撑平台，分析历史数据规律，预测未来发展趋势，洞察全行业动态。

结语

        对于大数据的探索，在不断迭代中，探索更多、创造更新的数据价值，更高效地开发数据产品，服务世界。

        这条天险之路只有方向，没有终点。

---

本文旨在读《阿里巴巴大数据之路》时，对相关知识点进行摘录与总结，并与大家分享。