正文

六、元数据管理

1、业务元数据

描述 ”数据”背后的业务含义

主题定义：每段 ETL、表背后的归属业务主题。

业务描述：每段代码实现的具体业务逻辑。

标准指标：类似于 BI 中的语义层、数仓中的一致性事实；将分析中的指标进行规范化。

标准维度：同标准指标，对分析的各维度定义实现规范化、标准化。

不断的进行维护且与业务方进行沟通确认。

2、技术元数据

数据源元数据

例如：数据源的 IP、端口、数据库类型；数据获取的方式；数据存储的结构；原数据各列的定义及 key 指对应的值。

ETL 元数据

根据 ETL 目的的不同，可以分为两类：数据清洗元数据；数据处理元数据。

数据清洗，主要目的是为了解决掉脏数据及规范数据格式；因此此处元数据主要为：各表各列的"正确"数据规则；默认数据类型的"正确"规则。

数据处理，例如常见的表输入表输出；非结构化数据结构化；特殊字段的拆分等。源数据到数仓、数据集市层的各类规则。比如内容、清理、数据刷新规则。

数据仓库元数据

数据仓库结构的描述，包括仓库模式、视图、维、层次结构及数据集市的位置和内容；业务系统、数据仓库和数据集市的体系结构和模式等。

BI 元数据

汇总用的算法、包括各类度量和维度定义算法。数据粒度、主题领域、聚集、汇总、预定义的查询与报告。

3、管理元数据

管理领域相关，包括管理流程、人员组织、角色职责等。

4、小编有话

在日常工作中，元数据的管理主要体现在元数据的采集、存储、查询、应用几个方面。原则上应从规范化，到脚本化，到工具化的方向进行建设。

采集：元数据采集时尽可能详细，真实，可通过工具生成或者勾选，避免手动录入带来不规范等问题

存储：存储元数据要做到不失真，元数据变更时及时同步

查询：通过网页或库表等方式，方便快捷的看到元数据，辅助进行开发

应用：数据血缘、优化调度依赖、数据治理等

七、维度表

1、什么是维度表

维度是维度建模的基础和灵魂。在维度建模中，将度量称为“事实” ， 将环境描述为“维度”。

维度表包含了事实表中指定属性的相关详细信息，最常用的维度表有日期维度、城市维度等。

日期维表：

2、维度表设计原则

维度的作用一般是查询约束、分类汇总以及排序等，我们在进行维度表设计时，应当提前考虑：

（1）维度属性尽量丰富，为数据使用打下基础

比如淘宝商品维度有近百个维度属性，为下游的数据统计、分析、探查提供了良好的基础。

（2）给出详实的、富有意义的文字描述

属性不应该是编码，而应该是真正的文字。在间里巴巴维度建模中， 一般是编码和文字同时存在，比如商品维度中的商品 ID 和商品标题、 类目 ID 和 类目名称等。ID 一 般用于不同表之间的关联，而名称一般用 于报表标签

（3）区分数值型属性和事实

数值型宇段是作为事实还是维度属性，可以参考字段的一般用途。如果通常用于查询约束条件或分组统计，则是作为维度属性;如果通常 用于参与度量的计算， 则是作为事实。比如商品价格，可以用于查询约 束条件或统计价格区间 的商品数量，此时是作为维度属性使用的;也可 以用于统计某类目 下商品的平均价格，此时是作为事实使用的。另外， 如果数值型字段是离散值，则作为维度属性存在的可能性较大;如果数 值型宇段是连续值 ，则作为度量存在的可能性较大，但并不绝对，需要 同时参考宇段的具体用途。

（4）沉淀出通用的维度属性，为建立一致性维度做好铺垫

有些维度属性获取需要进行比较复杂的逻辑处理，有些需要通过多表关联得到，或者通过单表 的不同宇段混合处理得到，或者通过对单表 的某个字段进行解析得到。此时，需要将尽可能多的通用的维度属性进 行沉淀。一方 面，可以提高下游使用的方便性，减少复杂度;另一方面，可以避免下游使用解析时由于各自逻辑不同而导致口径不 一致。

（5）退化维度（Degenerate Dimension）

在维度类型中，有一种重要的维度称作为退化维度。这种维度指的是直接把一些简单的维度放在事实表中。退化维度是维度建模领域中的一个非常重要的概念，它对理解维度建模有着非常重要的作用，退化维度一般在分析中可以用来做分组使用。

（6）缓慢变化维（Slowly Changing Dimensions）

维度的属性并不是始终不变的，它会随着时间的流逝发生缓慢的变化，这种随时间发生变化的维度我们一般称之为缓慢变化维（SCD），缓慢变化维一般使用代理健作为维度表的主健。

缓慢变化维的三种常用处理方式：

① TYPE1 直接覆盖原值

适用于：不看历史数据，简单粗暴

② TYPE2 拉链表

需要在维度行再增加三列：有效日期、截止日期、行标识（可选）。

在旧的一行数据增加关链时间（end_date），新的一行数据增加开链时间和关链时间，多条数据加起来是一个完整的时间周期。

③ TYPE3 增加属性列

3、维度表设计方法

第一步：选择维度或新建维度。作为维度建模的核心，在企业级数 据仓库中必须保证维度的唯一性。以淘宝商品维度为例，有且只允许有 一个维度定义。

第二步：确定主维表。此处的主维表一般是 ODS 表，直接与业务 系统同步。以淘宝商品维度为例， s_auction_auctions 是与前台商品中心 系统同步的商品表，此表即是主维表。

第三步：确定相关维表。数据仓库是业务源系统的数据整合，不同业务系统或者同 一业务系统中的表之间存在 关联性。根据对业务的梳 理，确定哪些表和主维表存在关联关系，并选择其中的某些表用于生成维度属性。

第四步 ：确定维度属性 。本步骤主要 包括两个阶段，其中第 一 个阶 段是从主维表 中选择维度属性或生成新的维度属性;第 二个阶段是从相 关维表中选择维度属性或生成新 的维度属性。以淘宝商品维度为例，从 主维表 (s_auction_auctions)和类目、 SPU、卖家、店铺等相关维表中 选择维度属性或生成新 的维度属性。

八、三范式与反范式

范式是符合某一种级别的关系模式的集合。构造数据库必须遵循一定的规则。在关系数据库中，这种规则就是范式。

      关系数据库中的关系必须满足一定的要求，即满足不同的范式。大数据生态中，各类强大的查询引擎层出不穷，相对廉价的磁盘和分布式技术，也让数据冗余变得可接受甚至更加方便。

      在创建一个数据库的过程中，范化是将其转化为一些表的过程，这种方法可以使从数据库得到的结果更加明确。这样可能使数据库产生重复数据，从而导致创建多余的表。范化是在识别数据库中的数据元素、关系以及定义所需的表和各表中的项目等这些初始工作之后的一个细化的过程。

1、第一范式

1NF要求属性具有原子性，即列不可再分解；

表：字段1、 字段2(字段2.1、字段2.2)、字段3 ......

如学生（学号，姓名，性别，出生年月日）

有些钢筋可能要问西红柿了，姓名可以拆成姓、名两列， “出生年月日” 也可以拆成年、月、日三个字段。所以就不满足第一范式了！！！这里再强调一下原子性，原子性是根据使用方便来自定义的最小单位。中国人一般姓名一起用，美国就习惯姓名分别存两字段。

2、第二范式

2NF要求记录有惟一标识，即不存在部分依赖；

简单来说就是拆表，以人为粒度做一张明细表，以课程号为粒度做一张维度表，两表关联使用，消除了数据冗余

表：学号、课程号、姓名、学分;

这个表明显说明了两个事务:学生信息, 课程信息;由于非主键字段必须依赖主键，这里学分依赖课程号，姓名依赖与学号，所以不符合二范式。

可能会存在问题：

数据冗余：每条记录都含有相同信息；

删除异常：删除所有学生成绩，就把课程信息全删除了；

插入异常：学生未选课，无法记录进数据库；

更新异常：调整课程学分，所有行都调整。

正确做法:

学生：Student(学号, 姓名)；

课程：Course(课程号, 学分)；

选课关系：StudentCourse(学号, 课程号, 成绩)。

3、第三范式

3NF是对字段的冗余性，要求任何字段不能由其他字段派生出来，它要求字段没有冗余，即不存在传递依赖；

表: 学号, 姓名, 年龄, 学院名称, 学院电话

因为存在依赖传递: (学号) → (学生)→(所在学院) → (学院电话) 。

可能会存在问题：

数据冗余:有重复值；

更新异常：有重复的冗余信息，修改时需要同时修改多条记录，否则会出现数据不一致的情况 。

正确做法：

学生：(学号, 姓名, 年龄, 所在学院)；

学院：(学院, 电话)。

4、反范式化

一般说来，数据库只需满足第三范式（3NF）就行了。

   没有冗余的数据库设计可以做到。但是，没有冗余的数据库未必是最好的数据库，有时为了提高运行效率，就必须降低范式标准，适当保留冗余数据。具体做法是：在概念数据模型设计时遵守第三范式，降低范式标准的工作放到物理数据模型设计时考虑。降低范式就是增加字段，允许冗余，达到以空间换时间的目的。

 〖例〗：有一张存放商品的基本表，如表1所示。“金额”这个字段的存在，表明该表的设计不满足第三范式，因为“金额”可以由“单价”乘以“数量”得到，说明“金额”是冗余字段。但是，增加“金额”这个冗余字段，可以提高查询统计的速度，这就是以空间换时间的作法。

   在Rose 2002中，规定列有两种类型：数据列和计算列。“金额”这样的列被称为“计算列”，而“单价”和“数量”这样的列被称为“数据列”。

5、范式化设计和反范式化设计的优缺点

5.1 范式化 （时间换空间）

优点：

范式化的表减少了数据冗余，数据表更新操作快、占用存储空间少。

缺点：

查询时需要对多个表进行关联，查询性能降低。

更难进行索引优化

5.2 反范式化（空间换时间）

反范式的过程就是通过冗余数据来提高查询性能，但冗余数据会牺牲数据一致性

优点：

可以减少表关联

可以更好进行索引优化

缺点：

存在大量冗余数据

数据维护成本更高（删除异常，插入异常，更新异常）

6、OLAP和OLTP中范式设计

OLAP 一般冗余比较多，以查询分析为主，这种一般都是采用反范式设计，以提高查询效率。更新一般是定时大批量数据插入。

OLTP 则是尽可能消除冗余，以提高变更的效率。因为这种应用无时无刻不在频繁变化。

九、数据仓库架构-Lambda和Kappa

随着数据量的暴增和数据实时性要求越来越高，以及大数据技术的发展驱动企业不断升级迭代，数据仓库架构方面也在不断演进，分别经历了以下过程：早期经典数仓架构 > 离线大数据架构 > Lambda > Kappa > 混合架构。

1、Lambda架构原理

Lambda架构的核心思想是把大数据系统拆分成三层：Batch Layer，Speed Layer和Serving Layer。其中，Batch Layer负责数据集存储以及全量数据集的预查询。

Speed Layer主要负责对增量数据进行计算，生成Realtime Views。Serving Layer用于响应用户的查询请求，它将Batch Views和Realtime Views的结果进行合并，得到最后的结果，返回给用户，如下图：

2、Lambda架构的缺点

Lambda架构解决了大数据量下实时计算的问题，但架构本身也存在一定缺点。

实时与批量计算结果不一致引起的数据口径问题：因为批量和实时计算走的是两个计算框架和计算程序，算出的结果往往不同，经常看到一个数字当天看是一个数据，第二天看昨天的数据反而发生了变化。

批量计算在计算窗口内无法完成：在IOT时代，数据量级越来越大，经常发现夜间只有4、5个小时的时间窗口，已经无法完成白天20多个小时累计的数据，保证早上上班前准时出数据已成为每个大数据团队头疼的问题。

开发和维护的复杂性问题：Lambda 架构需要在两个不同的 API（application programming interface，应用程序编程接口）中对同样的业务逻辑进行两次编程：一次为批量计算的ETL系统，一次为流式计算的Streaming系统。针对同一个业务问题产生了两个代码库，各有不同的漏洞。这种系统实际上非常难维护

服务器存储大：数据仓库的典型设计，会产生大量的中间结果表，造成数据急速膨胀，加大服务器存储压力。

3、Kappa架构原理

Kappa架构的核心思想包括以下三点：

用Kafka或者类似的分布式队列系统保存数据，你需要几天的数据量就保存几天。

当需要全量重新计算时，重新起一个流计算实例，从头开始读取数据进行处理，并输出到一个新的结果存储中。

当新的实例做完后，停止老的流计算实例，并把老的一些结果删除。

在Kappa架构下，只有在有必要的时候才会对历史数据进行重复计算，并且实时计算和批处理过程使用的是同一份代码。

4、Lambda架构和Kappa架构优缺点对比

5、数据架构评价标准

响应速度：数据架构的主要场景包括：业务开发、数据产品、运营分析三大类，不论是那种场景，数据架构均应该在尽可能短的时间内响应需求；

可复用性：只有复用能力上来了，响应速度才能提上来，体现在下游依赖、调用次数、核心字段覆盖率等指标上；

稳定性：除了日常任务不出问题以外，一旦发现了问题，能在多短的时间内定位和恢复问题，就非常重要；

健壮性：除了电商等已经耕耘多年的领域外，绝大多数业务模型，都会快速的变化，如何适应这种变化，就非常考验架构功底。

6、小编有话

Lambda 将全量历史数据和实时增量数据合并输出。

Kappa 两个流协作输出，queries每次使用最新一个流处理结果

目前很多准实时增量批处理方案也能满足实时性需求，从稳定性和运维成本上也表现更佳。

比如kudu（存储）+impala（计算）准实时方案，可以实现千万级数据的增量更新和olap查询，性能优异。

十、数据治理（目的、方法、流程）

1、什么是数据治理

数据治理（Data Governance）是组织中涉及数据使用的一整套管理行为。由企业数据治理部门发起并推行，关于如何制定和实施针对整个企业内部数据的商业应用和技术管理的一系列政策和流程。

数据的质量直接影响着数据的价值，并且直接影响着数据分析的结果以及我们以此做出的决策的质量。

我们常说，用数据说话，用数据支撑决策管理，但低质量的数据、甚至存在错误的数据，必然会"说假话"！！！数据治理即提高数据的质量，发挥数据资产价值。

2、数据治理的目的

降低风险

建立数据使用内部规则

实施合规要求

改善内部和外部沟通

增加数据价值

方便数据管理

降低成本

通过风险管理和优化来帮助确保公司的持续生存

3、数据治理的方法

从技术实施角度看，数据治理包含“理”“采”“存”“管”“用”这五个步骤，即业务和数据资源梳理、数据采集清洗、数据库设计和存储、数据管理、数据使用。

数据资源梳理：数据治理的第一个步骤是从业务的视角厘清组织的数据资源环境和数据资源清单，包含组织机构、业务事项、信息系统，以及以数据库、网页、文件和 API 接口形式存在的数据项资源，本步骤的输出物为分门别类的数据资源清单。

数据采集清洗：通过可视化的 ETL 工具（例如阿里的 DataX，Pentaho Data Integration）将数据从来源端经过抽取 (extract)、转换 (transform)、加载 (load) 至目的端的过程，目的是将散落和零乱的数据集中存储起来。

基础库主题库建设：一般情况下，可以将数据分为基础数据、业务主题数据和分析数据。基础数据一般指的是核心实体数据，或称主数据，例如智慧城市中的人口、法人、地理信息、信用、电子证照等数据。主题数据一般指的是某个业务主题数据，例如市场监督管理局的食品监管、质量监督检查、企业综合监管等数据。而分析数据指的是基于业务主题数据综合分析而得的分析结果数据，例如市场监督管理局的企业综合评价、产业区域分布、高危企业分布等。那么基础库和主题库的建设就是在对业务理解的基础上，基于易存储、易管理、易使用的原则抽像数据存储结构，说白了，就是基于一定的原则设计数据库表结构，然后再根据数据资源清单设计数据采集清洗流程，将整洁干净的数据存储到数据库或数据仓库中。

元数据管理：元数据管理是对基础库和主题库中的数据项属性的管理，同时，将数据项的业务含义与数据项进行了关联，便于业务人员也能够理解数据库中的数据字段含义，并且，元数据是后面提到的自动化数据共享、数据交换和商业智能（BI）的基础。需要注意的是，元数据管理一般是对基础库和主题库中（即核心数据资产）的数据项属性的管理，而数据资源清单是对各类数据来源的数据项的管理。

血缘追踪：数据被业务场景使用时，发现数据错误，数据治理团队需要快速定位数据来源，修复数据错误。那么数据治理团队需要知道业务团队的数据来自于哪个核心库，核心库的数据又来自于哪个数据源头。我们的实践是在元数据和数据资源清单之间建立关联关系，且业务团队使用的数据项由元数据组合配置而来，这样，就建立了数据使用场景与数据源头之间的血缘关系。数据资源目录：数据资源目录一般应用于数据共享的场景，例如政府部门之间的数据共享，数据资源目录是基于业务场景和行业规范而创建，同时依托于元数据和基础库主题而实现自动化的数据申请和使用。

质量管理：数据价值的成功发掘必须依托于高质量的数据，唯有准确、完整、一致的数据才有使用价值。因此，需要从多维度来分析数据的质量，例如：偏移量、非空检查、值域检查、规范性检查、重复性检查、关联关系检查、离群值检查、波动检查等等。需要注意的是，优秀的数据质量模型的设计必须依赖于对业务的深刻理解，在技术上也推荐使用大数据相关技术来保障检测性能和降低对业务系统的性能影响，例如 Hadoop，MapReduce，HBase 等。

商业智能（BI）：数据治理的目的是使用，对于一个大型的数据仓库来说，数据使用的场景和需求是多变的，那么可以使用 BI 类的产品快速获取需要的数据，并分析形成报表，比较知名的产品有 Microsoft Power BI，QlikView，Tableau，帆软等。

数据共享交换：数据共享包括组织内部和组织之间的数据共享，共享方式也分为库表、文件和 API 接口三种共享方式，库表共享比较直接粗暴，文件共享方式通过 ETL 工具做一个反向的数据交换也就可以实现。我们比较推荐的是 API 接口共享方式，在这种方式下，能够让中心数据仓库保留数据所有权，把数据使用权通过 API 接口的形式进行了转移。API 接口共享可以使用 API 网关实现，常见的功能是自动化的接口生成、申请审核、限流、限并发、多用户隔离、调用统计、调用审计、黑白名单、调用监控、质量监控等等。

4、数据质量8个衡量标准

数据的准确性

数据采集值或者观测值和真实值之间的接近程度，也叫做误差值，误差越大，准确度越低。

数据的精确性

指对同一对象的观测数据在重复测量时所得到不同数据间的接近程度。

数据的真实性

数据的及时性

数据能否在需要的时候得到保证，比如月初的财务对账，能不能在月初就完成

数据的即时性

指数据采集时间节点和数据传输的时间节点，一个数据在数据源头采集后立即存储，并立即加工呈现，就是即时数据，而经过一段时间之后再传输到信息系统中，则数据即时性就稍差。

数据的完整性

应采集和实际采集到数据之间的比例。

数据的全面性

完整性衡量的是应采集和实际采集的差异。而全面性指的是数据采集点的遗漏情况。

数据的关联性

指各个数据集之间的关联关系。比如员工工资数据和员工绩效考核数据是通过员工这个资源关联在一起来的。

信息技术智库关注领取技术资料、面试真题、简历模板和PPT模板；一起交流工作难题、面试套路、职场经验、内推直通车公众号

5、数据治理流程

基本流程：发现数据质量问题 > 定义数据质量规则 > 质量控制 > 质量评估 > 质量优化

十一、ETL

1、什么是ETL

ETL，是英文Extract-Transform-Load的缩写，用来描述将数据从来源端经过抽取（extract）、转换（transform）、加载（load）至目的端的过程，是数据仓库的生命线。

      抽取（Extract）主要是针对各个业务系统及不同服务器的分散数据，充分理解数据定义后，规划需要的数据源及数据定义，制定可操作的数据源，制定增量抽取和缓慢渐变的规则。

      转换（transform）主要是针对数据仓库建立的模型，通过一系列的转换来实现将数据从业务模型到分析模型，通过ETL工具可视化拖拽操作可以直接使用标准的内置代码片段功能、自定义脚本、函数、存储过程以及其他的扩展方式，实现了各种复杂的转换，并且支持自动分析日志，清楚的监控数据转换的状态并优化分析模型。

装载（Load）主要是将经过转换的数据装载到数据仓库里面，可以通过直连数据库的方式来进行数据装载，可以充分体现高效性。在应用的时候可以随时调整数据抽取工作的运行方式，可以灵活的集成到其他管理系统中。

2、ETL & ELT

伴随着数据仓库的发展（传送门：数据仓库的八个发展阶段），数据量从小到大，数据实时性从T+1到准实时、实时，ETL也在不断演进。

在传统数仓中，数据量小，计算逻辑相对简单，我们可以直接用ETL工具实现数据转换（T），转换之后再加载到目标库，即（Extract-Transform-Load）。

但在大数据场景下，数据量越大越大，计算逻辑愈发复杂，数据清洗需放在运算能力更强的分布式计算引擎中完成，ETL也就变成了ELT（Extract-Load-Transform）。

即：Extract-Transform-Load  >>  Extract-Load-Transform

通常我们所说的ETL，已经泛指数据同步、数据清洗全过程，而不仅限于数据的抽取-转换-加载。

3、常用的ETL工具

下面小编将介绍几类ETL工具（sqoop，DataX，Kettle，canal，StreamSets）。

3.1 sqoop

是Apache开源的一款在Hadoop和关系数据库服务器之间传输数据的工具。

可以将一个关系型数据库（MySQL ,Oracle等）中的数据导入到Hadoop的HDFS中，也可以将HDFS的数据导出到关系型数据库中。

sqoop命令的本质是转化为MapReduce程序。

sqoop分为导入（import）和导出（export），

策略分为table和query

模式分为增量和全量。

3.2 DataX

DataX 是阿里巴巴集团内被广泛使用的离线数据同步工具/平台

实现包括 MySQL、Oracle、SqlServer、Postgre、HDFS、Hive、ADS、HBase、TableStore(OTS)、MaxCompute(ODPS)、DRDS 等各种异构数据源之间高效的数据同步功能。

3.3 Kettle

一款国外免费开源的、可视化的、功能强大的ETL工具，纯java编写，可以在Windows、Linux、Unix上运行，数据抽取高效稳定。

3.4 canal

canal是阿里巴巴旗下的一款开源项目，纯Java开发。基于数据库增量日志解析，提供增量数据实时订阅和消费，目前主要支持了MySQL，也支持mariaDB。

3.5 StreamSets

是大数据实时采集ETL工具，可以实现不写一行代码完成数据的采集和流转。通过拖拽式的可视化界面，实现数据管道(Pipelines)的设计和定时任务调度。

创建一个Pipelines管道需要配置数据源(Origins)、操作(Processors)、目的地(Destinations)三部分。

4、ETL加载策略

4.1 增量

有些表巨大，我们需要选择增量策略，新增delta数据需要和存量数据merge合并。

只有新增(full join。能拿更新表就拿更新表)

新增+删除

history-table Left join delet-table where delect-table.value is null == 表a

表a full join update-table (能拿update就拿update)

4.2 全量

每天一个全量表，也可一个hive天分区一个全量。

4.3 流式

使用kafka，消费mysql binlog日志到目标库，源表和目标库是1：1的镜像。

5、小编有话

无论是全量还是增量的方式，都会浪费多余的存储或通过计算去重，得到最新的全量数据。为解决这一问题，西红柿墙裂建议kafka的数据同步方案，源表变化一条，目标表消费一条，目标表数据始终是一份最新全量数据，且为实时同步的。

ps.极端情况下可能会丢数，需要写几个监控脚本（详见上文数据质量部分）和补数脚本即可~

十二、数据应用-OLAP

1、olap和oltp的区别

2、OLAP分类

MOLAP，基于多维数组的存储模型，也是OLAP最初的形态，特点是对数据进行预计算，以空间换效率，明细和聚合数据都保存在cube中。但生成cube需要大量时间和空间。

ROLAP，基于关系模型进行存储数据，不需要预计算，按需即时查询。明细和汇总数据都保存在关系型数据库事实表中。其特点是与事务实体对应，关系清晰；但一般需要较为复杂的数据准备。在响应前端需求时，一般较快，但取决于计算引擎能力。

HOLAP，混合模型，细节数据以ROLAP存放，聚合数据以MOLAP存放。这种方式相对灵活，且更加高效。可按企业业务场景和数据粒度进行取舍，没有最好，只有最适合。

3、OLAP基本操作

★钻取：维的层次变化，从粗粒度到细粒度，汇总数据下钻到明细数据。如通过季度销售数据钻取每个月的销售数据。

★上卷：钻取的逆，向上钻取。从细粒度到粗粒度，细粒度数据到不同维层级的汇总。eg. 通过每个月的销售数据汇总季度、年销售数据。

★切片：特定维数据（剩余维两个）。eg. 只选电子产品销售数据。

★切块：维区间数据（剩余维三个）。eg. 第一季度到第二季度销售数据。

★旋转：维位置互换（数据行列互换），通过旋转可以得到不同视角的数据。

4、OLAP选型

4.1 druid

实时查询和分析的高容错、高性能开源分布式系统，用于解决如何在大规模数据集下进行快速的、交互式的查询和分析。

实时的数据消费，真正做到数据摄入实时、查询结果实时。

扩展性强，支持 PB 级数据

极高的高可用保障，支持滚动升级。

druid属于时间存储，删除操作比较繁琐，且不支持查询条件删除数据，只能根据时间范围删除数据。Druid能接受的数据的格式相对简单，比如不能处理嵌套结构的数据。

4.2 kylin

可扩展超快olap引擎，Hadoop/Spark上百亿数据规模

提供 Hadoop ANSI SQL 接口

交互式查询能力，用户可以与Hadoop数据进行亚秒级交互

百亿以上数据集构建多维立方体（MOLAP CUBE）

与BI工具无缝整合，如Tableau，PowerBI/Excel，MSTR，QlikSense，Hue和SuperSet

十三、数据倾斜

1、数据倾斜表现

1.1 hadoop中的数据倾斜表现

有一个多几个Reduce卡住，卡在99.99%，一直不能结束。

各种container报错OOM

异常的Reducer读写的数据量极大，至少远远超过其它正常的Reducer

伴随着数据倾斜，会出现任务被kill等各种诡异的表现。

1.2 hive中数据倾斜

一般都发生在Sql中group by和join on上，而且和数据逻辑绑定比较深。

1.3 Spark中的数据倾斜

Spark中的数据倾斜，包括Spark Streaming和Spark Sql，表现主要有下面几种：

Executor lost，OOM，Shuffle过程出错；

Driver OOM；

单个Executor执行时间特别久，整体任务卡在某个阶段不能结束；

正常运行的任务突然失败；

2、数据倾斜产生原因

我们以Spark和Hive的使用场景为例。

在做数据运算的时候会涉及到，count distinct、group by、join on等操作，这些都会触发Shuffle动作。一旦触发Shuffle，所有相同key的值就会被拉到一个或几个Reducer节点上，容易发生单点计算问题，导致数据倾斜。

一般来说，数据倾斜原因有以下几方面：

1）key分布不均匀；

2）建表时考虑不周

举一个例子，就说数据默认值的设计吧，假设我们有两张表：

   user（用户信息表）：userid，register_ip

   ip（IP表）：ip，register_user_cnt

这可能是两个不同的人开发的数据表。如果我们的数据规范不太完善的话，会出现一种情况：

user表中的register_ip字段，如果获取不到这个信息，我们默认为null；

但是在ip表中，我们在统计这个值的时候，为了方便，我们把获取不到ip的用户，统一认为他们的ip为0。

两边其实都没有错的，但是一旦我们做关联了，这个任务会在做关联的阶段，也就是sql的on的阶段卡死。

3）业务数据激增

比如订单场景，我们在某一天在北京和上海两个城市多了强力的推广，结果可能是这两个城市的订单量增长了10000%，其余城市的数据量不变。

然后我们要统计不同城市的订单情况，这样，一做group操作，可能直接就数据倾斜了。

3、解决数据倾斜思路

很多数据倾斜的问题，都可以用和平台无关的方式解决，比如更好的数据预处理，异常值的过滤等。因此，解决数据倾斜的重点在于对数据设计和业务的理解，这两个搞清楚了，数据倾斜就解决了大部分了。

1）业务逻辑

我们从业务逻辑的层面上来优化数据倾斜，比如上面的两个城市做推广活动导致那两个城市数据量激增的例子，我们可以单独对这两个城市来做count，单独做时可用两次MR，第一次打散计算，第二次再最终聚合计算。完成后和其它城市做整合。

2）程序层面

比如说在Hive中，经常遇到count(distinct)操作，这样会导致最终只有一个Reduce任务。

我们可以先group by，再在外面包一层count，就可以了。比如计算按用户名去重后的总用户量：

（1）优化前

只有一个reduce，先去重再count负担比较大：

select name,count(distinct name)from user;

（2）优化后

// 设置该任务的每个job的reducer个数为3个。Hive默认-1，自动推断。

set mapred.reduce.tasks=3;

// 启动两个job，一个负责子查询(可以有多个reduce)，另一个负责count(1)：

select count(1) from (select name from user group by name) tmp;

3）调参方面

Hadoop和Spark都自带了很多的参数和机制来调节数据倾斜，合理利用它们就能解决大部分问题。

4）从业务和数据上解决数据倾斜

很多数据倾斜都是在数据的使用上造成的。我们举几个场景，并分别给出它们的解决方案。

一个原则：尽早过滤每个阶段的数据量。

数据有损的方法：找到异常数据，比如ip为0的数据，过滤掉。

数据无损的方法：对分布不均匀的数据，单独计算。

hash法：先对key做一层hash，先将数据随机打散让它的并行度变大，再汇聚。

数据预处理：就是先做一层数据质量处理，类似于数据仓库维度建模时，底层先处理数据质量。