全网最全大数据面试提升手册！

第1章 元数据1.1 元数据概述1.1.1 元数据定义

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

元数据按用途的不同分为两类：技术元数据（ Technical Metadata) 和业务元数据（Business Metadata ）

1.1.2 元数据价值

元数据有重要的应用价值，是数据管理、数据内容、数据应用的基础；

1.1.3 统一元数据体系建设

元数据的质量直接影响到数据管理的准确性，如何把元数据建设好将起到至关重要的作用。元数据建设的目标是打通数据接入到加工，再到数据消费整个链路，规范元数据体系与模型，提供统一的元数据服务出口，保障元数据产出的稳定性和质量。

1.2 元数据应用

价值：数据驱动决策，数字化运营

1.2.1 Data Profile

核心思路：为纷繁复杂的数据建立一个脉络清晰的血缘图谱。通过图计算、标签传播算法等技术，系统化、自动化地对计算与存储平台上的数 据进行打标、整理、归档，实际承担的是为元数据“画像”的任务，开发了四类标签：

1.2.2 元数据门户1.2.3 应用链路分析

通过应用链路分析，产出表级血缘、字段血缘和表的应用血缘。其中表级血缘主要有两种计算方式：

常见的应用链路分析应用主要有影响分析、重要性分析、下线分析、链路分析、寻根溯源、故障排查等

1.2.4 数据建模

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

星形模型设计中，使用元数据信息有：

1.2.5 驱动 ETL 开发

第2章 计算管理2.1 系统优化2.1.1 HBO

（History-Based Optimizer，基于历史的优化器）

在任务稳定的情况下，可以考虑基于任务的历史执行情况进行资源评估，即采用HBO

针对“大促”这类数据量暴涨的场景， HBO 也增加了根据数据量动态调整 Instance 数的功能，主要依据 Map 的数据量增长情况进行调整。

2.1.2 CBO

基于代价的优化器，根据收集的统 计信息来计算每种执行方式的代价，进而选择最优的执行方式。

引人了重新排序 Join（JoinReorder）和自动MapJoin（AutoMapJoin ）优化规则等，同时基于 Volcano 模型的优 化器会尽最大的搜索宽度来获取最优计划

可以设置规则白名单（使用哪些优化规则）、黑名单（关闭哪些优化规则）

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

2.2 任务优化2.2.1 Map 倾斜

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

上游表文件的大小特别不均匀，并且小文件特别多，导致当前表 Map 端读取的数据分布不均匀，引起长尾，手段有二：

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

2.2.2 Join 倾斜

因为数据倾斜导致长尾的现象比较普遍，严重影响任务的执行时 间，尤其是在“双 l l ”等大型活动期间，长尾程度比平时更严重。比 如某些大型店铺的 PV 远远超过一般店铺的PV，当用浏览日志数据和 卖家维表关联时，会按照卖家 ID 进行分发

2.2.3 Reduce 倾斜

Reduce端产生长尾的主要原因就是key 的数据分布不均匀

第3章 存储和成本管理3.1 数据压缩

针对3份副本的压缩方案：archive 压缩方法，存储比约为 1:3 提高到 1:1.5

3.2 数据重分布3.3 存储治理项优化

3.4 生命周期管理

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

3.4.1 生命周期管理策略

周期性删除策略

彻底删除策略

永久保留策略

极限存储策略

冷数据管理策略

增量表 merge 全量表策略：交易增量数据，使用 订单创建日期或者订单结束日期作为分区，同时将未完结订单放在最大 分区中，对于存储，一个订单在表里只保留一份；对于用户使用，通过 分区条件就能查询某一段时间的数据。

3.4.2 通用的生命周期管理矩阵

历史数据等级划分

3.5 数据成本计量

将数据成本定义为存储成本、计算成本和扫描成本三个部分，能够很好地体现出数据在加工链路中的 上下游依赖关系

3.6 数据使用计费第4章 数据质量4.1 数据质量保障原则

如何评估数据质量的好坏，业界有不同的标准，阿里主要从4个方面进行评估：完整性、准确性、一致性、及时性；

1. 完整性

数据完整性是数据最基础的保障；

2. 准确性

3. 一致性

4. 及时性

4.2 数据质量方法概述

阿里的数据质量建设体系：

消费场景知晓

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

主要对两部分的数据卡点校验：在线系统和离线系统数据生产加工各个环节的卡点校验；

风险点监控

风险点监控：主要针对在数据运行过程中可能出现的数据质量和时效等问题进行监控；

主要对两个方面进行风险点监控：

质量衡量

质量配套工具

4.2.1 消费场景知晓

数据资产等级定义

背景：针对阿里庞大的数据仓库，数据的规模已经达到 EB 级，对于这么大的数据量，如果一概而论势必会造成精力无法集中、保障无法精确；

五个数据等级，不同性质的重要性一次降低：

即，数据一旦出错，将会引起重大资产损失，面临重大受益损失，造成重大公共风险；

即，数据直接或间接用于集团业务和效果的评估、重要平台的运维、对外数据产品的透露、影响用户在阿里系网站的行为等；

即，数据直接或间接用于内部一般数据产品或者运营 / 产品报告，如果出现问题会给事业部或业务线造成影响，或者造成工作效率损失；

即，数据主要用于小二的日常数据分析，出现问题几乎不会带来影响或者影响很小；

不能明确说出数据的应用场景，则标注为未知；

对于不同的数据资产等级，使用英文 Asset 进行标记：

毁灭性质：A1 等级；

全局性质：A2 等级；

局部性质：A3 等级；

一般性质：A4 等级；

未知性质：A5 等级；

重要程度：A1 > A2 > A3 > A4 > A5；

如果一份数据出现在多个应用场景中，遵循就高原则；

数据资产等级落地方法

需要解决的问题：对于如此庞大的数据量，如何给每一份数据都打上一个等级标签？

数据资产等级落地的方法 / 步骤：

数据流转过程

数据从业务系统到数据仓库再到数据产品，都是以表的形式体现的，流转过程如下图：

同步到数据仓库（对应到阿里就是 MaxCompute 平台）中的都是业务数据库的原始表，主要用于承载业务需求，往往不能直接用于数据产品；（一般是 ODS 层的全量数据）

在数据产品中使用的都是经过数据仓库加工后的产出表；（根据需求 / 报表进行加工）

1.划分数据资产等级

2.根据数据流转过程，建立元数据，记录数据表与数据产品或者应用的对应关系；

3.根据影响程度，给数据产品和应用划分数据资产等级；

4.打标：依托元数据的上下游血缘，将整个消费链路打上某一类数据资产标签（也就是对消费链路数据打标）；

链路：指数据从业务系统到数据产品的流转过程；

总结：

通过上述步骤，就完成了数据资产等级的确认，给不同的数据定义了不同的重要程度，需要用到元数据的支撑；

4.2.2 数据加工过程卡点校验

目的：保障数据准确性、保障与离线数据的一致性；

在线业务系统卡点校验（数据产出环节）

工具

发布平台：发送重大变更的通知；

通知内容：变更原因、变更逻辑、变更测试报告、变更时间等；

数据库平台：发送库表变更通知；

通知内容：变更原因、变更逻辑、变更测试报告、变更时间等；

发布平台

功能：在业务进行重大变更时，订阅发布过程，然后给到离线开发人员，使其知晓此次变更的内容；

注：业务系统繁忙，日常发布变更数不胜数，并不是每一次业务变更都要只会离线业务，那样会造成不必要的浪费，而且影响在线业务迭代的效率；

订阅内容：针对全集团重要的高等级数据资产，整理出哪些变化会影响数据的加工，则订阅这些内容；

如，财报，这个自然是 A1 等级的资产，如果业务系统的改造会影响财报的计算，如约定好的计算口径被业务系统发布变更修改了，那么务必要告知离线业务，作为离线开发人员也必须主动关注这类发布变更信息；

卡点：发布平台集成了通知功能，针对重要的场景发布会进行卡点，确认通知后才能完成发布；

数据库表的变化感知

无论是随着业务发展而做的数据库扩容还是表的 DDL 变化，都需要通知到离线开发人员；

DDL（(Data Definition Language）：数据库模式定义语言；用于描述数据库中要存储的现实世界实体的语言。

DDL 数据库模式定义语言是 SQL 语言（结构化查询语言）的组成部分；

例：CREATE DATABASE（创建数据库）、CREATE TABLE（创建表）；

DML（Data Manipulation Language）：数据操纵语言命令；使用户能够查询数据库以及操作已有数据库中的数据。

例：insert、delete、update、select 等都是 DML ；

背景 / 问题：数据仓库在进行数据抽取时，采用的是 DataX 工具，可能限制了某个数据库表，如果发生数据库扩容或者迁移，DataX 工具是感知不到的，结果可能会导致数据抽取错漏，影响一系列的下游应用；

解决方法：通过数据库平台发送库表变更通知；

开发人员

数据资产等级的上下游打通，同样也要将这个过程给到在线开发人员，使其知晓哪些是重要的核心数据资产，哪些暂时还只是作为内部分析数据使用；

要提高在线开发人员的意识，通过培训，将离线数据的诉求、离线数据的加工过程、数据产品的应用方式，告诉在线业务开发人员，使其意识到数据的重要性，了解数据的价值，同时也告知出错后果，使在线开发人员在完成业务目标时，也要注重数据的目标，做到业务端和数据端一致；

离线系统卡点校验（数据离线加工环节）

背景 / 问题：数据从在线业务系统到数据仓库再到数据产品的过程中，需要在数据仓库这一层完成数据的清洗、加工；正是有了数据的加工，才有了数据仓库模型和数据仓库代码的建设；如何保障数据加工过程中的质量，是离线数据仓库保障数据质量的一个重要环节；

目的：保障数据加工过程中的质量（主要指数据的准确性）；

在两个环节进行卡点校验：

代码提交时的卡点校验

背景 / 原因：数据研发人员素质不同，代码能力也有差异，代码质量难以得到高效保障；

解决方法：开发代码扫描工具 SQLSCAN，针对每一次提交上线的代码进行扫描，将风险点提取出来；

卡点方式：使用代码扫描工具 SQLSCAN，扫描代码提取风险点；

任务发布上线时的卡点校验

为了保障线上数据的准确性，每一次变更都需要线下完成测试后在发布到线上环境中，线上测试通过后才算发布成功；

卡点方式：分别对任务（指变更的业务）发布上线前和上线后进行测试；

发布上线前的测试：主要包括 Code Review 和回归测试；

回归测试的目的：

保障新逻辑的正确；

保证不影响非此次变更的逻辑；

注：对于资产等级较高的任务变更发布，采用强阻塞的形式，必须通过在彼岸完成回归测试之后才允许发布；

发布上线后的测试：在线上做 Dry Run 测试或者真是环境运行测试；

不执行代码，仅运行执行计划，避免线上和线下环境不一致导致语法错误；

使用真实数据进行测试；

通知内容：变更原因、变更逻辑、变更测试报告、变更时间等；

过程：

使用通知中心，将变更原因、变更逻辑、变更测试报告、变更时间等自动通知下游，下游对此次变更没有异议后，再按照约定时间执行发布变更，将变更对下游的影响降低至最低；

4.2.3 风险点监控

风险点监控：主要指针对数据在日常运行过程中容易出现的风险进行监控，并设置报警机制；

主要包括在线数据和离线数据运行风险点监控；

目的：保障数据的准确性；

1、 在线数据风险点监控

配置告警：针对不同的规则配置不同的告警形式；

注：由于 BCP 的配置和运行成本较高，主要根据数据资产等级进行监控；

离线数据风险点监控主要包括对数据准确性和数据产出的及时性进行监控；

数据准确性是数据质量的关键，因此数据准确成为数据质量的重中之重，是所有离线系统加工时的第一保障要素；

方法：通过 DQC 进行数据准确性监控；

DQC（Data Quality Center，数据质量中心）：主要关注数据质量，通过配置数据质量校验规则，自动在数据处理任务过程中进行数据质量方面的监控；

注：监控数据质量并报警，其本身不对数据产出进行处理，需要报警接收人判断并决定如何处理；

监控方式：通过配置数据质量检验规则，自动在数据处理任务过程中进行监控；

监控规则：

强规则：会阻断任务的执行；

将任务置为失败状态，其下游任务将不会被执行；

弱规则：只告警而不会阻断任务的执行；

常见的 DQC 监控规则：主键监控、表数据量及波动监控、重要字段的非空监控、重要枚举字段的离散值监控、指标值波动监控、业务规则监控等；

规则配置：依赖数据资产等级确定监控规则；

DQC 检查其实也是运行 SQL 任务，只是这个任务是嵌套在主任务中的，一旦检查点太多自然就会影响整体的性能；因此还是依赖数据资产等级来确定规则的配置情况；

注：不同的业务会有业务规则的约束，这些规则来源于数据产品或者说消费的业务需求，有消费节点进行配置，然后上推到离线系统的起点进行监控，做到规则影响最小化；

在确保数据准确性的基础上，需要进一步让数据能够及时的提供服务；否则数据的价值将大幅度降低，甚至没有价值；

阿里的大部分离线任务：

一般以天为时间间隔，称为 “天任务”，对于天任务，数据产品或者数据决策报表一般都要求在每天 9:00 甚至更早的时间产出；

为了确保前一天的数据完整，天任务是从零点开始运行的，由于计算加工的任务都是在夜里运行的，而要确保每天的数据能够按时产出，需要进行一系列的报警和优先级设置，使得重要的任务优先且正确的产出；

重要的任务：资产等级较高的业务；

对于 Map 任务和 Reduce 任务，调度是一个树形结构（RelNode 树），当配置了叶子节点（RelNode 节点）的优先级后，这个优先级会传递到所有上游节点，所以优先级的设置都是给到叶子节点，而叶子节点往往就是服务业务的消费节点；

设置优先级：首先确定业务的资产等级，等级高的业务所对应的消费节点自然配置高优先级，一般业务则对应低优先级，确保高等级业务准时产出；

任务报警和优先级类似，也是通过叶子节点传递；

任务在运行过程中难免会出错，因此要确保任务能够高效、平稳的执行，需要有一个监控报警系统，对于高优先级的任务，一旦发现任务出错或者可能出现产出延迟，就要报警给到任务和业务 Owner；

摩萨德：阿里自主开发的监控报警系统；

摩萨德：离线任务的监控报警系统；是数据运维不可或缺的保障工具；

根据离线任务的运行情况实时决策是否告警、何时告警、告警方式、告警给谁等；

两个主要功能：强保障监控、自定义告警；

强保障监控

强保障监控是摩萨德的核心功能，是仅仅围绕运维目标即业务保障而设计的，只要在业务的预警时间受到威胁，摩萨德就一定会告警出来给到相关人员；

强保障监控主要包括：

监控范围：设置强保障业务的任务及其上游所有的任务都会被监控；

监控的异常：任务出错、任务变慢、预警业务延迟；

告警对象：默认是任务 Owner，也可以设置值班表到某一个人；

何时告警：根据业务设置的预警时间判断何时告警；

业务延迟预警和出错报警，都是根据 “产出预警时间“ 来判断的；

产出预警时间：摩萨德根据当前业务上所有任务最近 7 天运行的平均时间来推算当前业务所用的大概时间，来作为产出预警时间；

告警方式：根据业务的重要紧急程度，支持电话、短信、旺旺、邮件告警；

例：生意参谋业务（预警业务延迟）

资产等级及需求：定义的资产等级是 A2，要求早上 9:00 产出数据给到上架；

设置：给生意参谋业务定义一个强保障监控，业务产出时间是 9:00，业务预警时间是 7:00；

这里的预警时间是指，一旦摩萨德监控到当前业务的产出时间超出预警时间时，就会打电话给值班人员进行预警；

如，摩萨德推测生意参谋的产出时间要到 7:30，那么电话告警就出来了，由值班人员来判断如何加速产出；产出时间推算（预警判断，也就是产出延迟判断）：摩萨德是根据当前业务上所有任务最近 7 天运行的平均时间来推算的；虽然有误判的可能性，但是总体还是非常准确的，可以接受；

自定义监控是摩萨德比较轻量级的监控功能，用户可以根据自己的需求进行配置，主要包括：

出错告警：可根据应用、业务、任务三个监控对象进行出错告警配置，监控对象出错即告警给到人 / Owner / 值班表；

完成告警：可根据应用、业务、任务三个监控对象进行完成情况告警配置，监控对象完成即告警给到人 / Owner / 值班表；

未完成告警：可根据应用、业务、任务三个监控对象进行未完成情况告警配置，监控对象未完成即告警给到人 / Owner / 值班表；

周期性告警：针对某个周期的小时任务，如果在某个时间未完成，即告警给到人 / Owner / 值班表；

超时告警：根据任务运行时长进行超时告警配置，任务运行超过指定时间即告警给到人 / Owner / 值班表；

针对业务的运行情况，摩萨德会提供一天关键路径，即完成业务的最慢任务链路图；因为每个业务上游可能有成千上万个任务，所以这条关键路径对于业务链路优化来说非常重要；

4.2.4 质量衡量

保障数据仓库的数据质量，有很多方案，评价这些方案的优劣，需要一套度量指标：

一般数据仓库的作业任务都是在夜晚进行，一旦出现问题就需要值班人员起夜进行处理；

起夜率：用每个月的起夜次数，作为衡量数据质量建设完善度的一个指标；

数据质量事件：记录每一次数据质量的问题；

针对每一个数据质量问题，都记录一个数据质量事件：

功能：既用来衡量数据本身的质量，也用来衡量数据链路上下游的质量，是数据质量的一个重要度量指标；

用来跟进数据质量问题的处理过程；

用来归纳分析数据质量原因；

根据数据质量原因来查缺补漏，既要找到数据出现问题的原因，也要针对类似问题给出后续预防方案；

对于严重的数据质量事件，将升级为故障；

故障：指问题造成的影响比较严重，已经给公司带来资产损失或者公关风险；

背景：数据从采集到最后的消费，整个链路要经过几十个系统，任何一个环节出现问题，都会影响数据的产出，因此需要一种机制，能够将各团队绑在一起，目标一致，形成合力，故障体系在这个背景下应运而生；

故障体系中，一旦出现故障，就会通过故障体系，要求相关团队在第一时间跟进解决问题，消除影响；

故障定义

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

故障等级

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

故障处理

故障发生后，需要快速的识别故障原因，并迅速解决，消除影响；

在处理故障的过程中，会尽量将故障的处理进度通知到相关方，尽可能减少对业务的影响；

故障 Review

故障 Review：即分析故障的原因、处理过程的复盘、形成后续解决的 Action，并且都会以文字的形式详细记录，对故障的责任进行归属，一般会责任到人；

注：对故障责任的判定，不是为了惩罚个人，而是通过对故障的复盘形成解决方案，避免问题再次发生；

如果这个文章对你有帮助，不要忘记「在看」「点赞」「收藏」三连啊喂！

2022年全网首发|大数据专家级技能模型与学习指南(胜天半子篇)

互联网最坏的时代可能真的来了

我在B站读大学，大数据专业

我们在学习Flink的时候，到底在学习什么？

193篇文章暴揍Flink，这个合集你需要关注一下

Flink生产环境TOP难题与优化，阿里巴巴藏经阁YYDS

Flink CDC我吃定了耶稣也留不住他！| Flink CDC线上问题小盘点

我们在学习Spark的时候，到底在学习什么？

在所有Spark模块中，我愿称SparkSQL为最强！

硬刚Hive | 4万字基础调优面试小总结

数据治理方法论和实践小百科全书

标签体系下的用户画像建设小指南

4万字长文 | ClickHouse基础&实践&调优全视角解析

【面试&个人成长】2021年过半，社招和校招的经验之谈

大数据方向另一个十年开启 |《硬刚系列》第一版完结

我写过的关于成长/面试/职场进阶的文章

当我们在学习Hive的时候在学习什么？「硬刚Hive续集」