[大数据]hadoop数仓建设之离线数据开发

🌸最近在学python的基础数据结构，主要原因是面试的算法题都是数据结构，想努力打打基础，但是作为一个人工智能与大数据领域的博主，还是要继续学习大数据的，今天我们就来介绍一下数据仓库的离线数据开发的过程吧,往期数仓的介绍在下面👇：

• 第一篇: Hadoop之数据仓库概述.
• 第二篇: hadoop数仓建设之日志采集.
• 第三篇: Hadoop数仓建设之数据同步.

🍡大数据之路任重道远，借着公司有大数据的平台赶紧把大数据好好学习一下，今天要介绍的离线数据开发和我目前的工作简直如出一辙，我知道在平台上该怎么操作，但我也希望知道这个平台实现的原理是什么，以及与传统的数据仓库的开发有什么样的不同。

1. 离线数据开发

上一章节我们讲述了数据同步，从采集系统中收集了大量的原始数据后，数据只有被整合和计算，才能被用于洞察商业规律，挖掘潜在信息，从而实现大数据价值，达到赋能于商业和创造价值的目的。面对海量的数据和复杂的计算，数据计算层包括两大体系:数据存储及计算平台 (离线计算平台 MaxCompute 和 实时计算平台 StreamCompute) 、数据整合及管理体系 ( OneData ) 。

2. 数据计算平台

我们公司的数据研发岗位的工作大致可以概括为:了解需求→模型设计→ ETL 开发→测试→发布上线→日常运维→任务下线。与传统的数据仓库开发( ETL)相比，我们的数据研发有如下几个特点:

• 业务变更频繁一一业务发展非常快 ，业务需求多且变更频繁。
• 需要快速交付一一业务驱动 ，需要快速给出结果。
• 频繁发布上线一一迭代周期以天为单位，每天需要发布数次。
• 运维任务多 一一在集团公共层平均每个开发人员负责 500 多个任务
• 系统环境复杂一一平台系统多为自研，且为了保证业务的发展，平台系统的迭代速度较快，平台的稳定性压力较大。

通过统一的计算平台(MaxCompute)、统一的开发平台(D2 等相关平台和工具)、统一的数据模型规范和统一的数据研发规范，可以在一定程度上解决数据研发的痛点。

2.1 统一计算平台

离线数仓的存储和计算都是在MaxCompute上完成的。大数据计算服务 MaxCompute 是自主研发的海量数据处理平台，主要服务于海量数据的存储和计算 ，提供完善的数据导入方案， 以及多种经典的分布式计算模型，提供海量数据仓库 的解决方案，能够更快速地解决用户的海量数据计算问题，有效降低企业成本，并保障数据安全。

2.1.1 MaxCompute 的结构

MaxCompute 采用抽象的作业处理框架 ，将不同场景的各种计算任务统一在同一个平台之上，共享安全、存储 、数据管理和资源调度，为来自不同用户需求的各种数据处理任务提供统一的编程接口和界面。它提供数据上传/下载通道、 SQL、 MapReduce、机器学习算法 、 图编程模型和流式计算模型多种计算分析服务，并且提供完善的安全解决方案。

MaxCompute 由四部分组成，分别是客户端（ MaxCompute Client ）、 接人层（ Max Compute Front End）、逻辑层（ MaxCompt Server）及存储与计算层（ Apsara Core ）。

Max Compute 客户端有以下几种形式：

• Web ：以 RESTful API 的方式提供离线数据处理服务。
• SDK ：对 RESTful API 的封 装，目前有 Java 等版本的实现。
• CLT (Command Line Tool ）： 运行在 Windows /Linux 下的客户端工具，通过 CLT 可以提交命令完成 Project 管理、 DDL 、 DML 等操作。
• IDE ：上层可视化 ETL/BI 工具， 即阿里内部名称是在云端（ 02 ) ,用户可以基于在云端完成数据同步、任务调度、报表生成等常见操作。

接人层提供 HTTP 服务、 Cache、负载均衡，实现用户认证和服务
层面的访问控制。

Max Compute 逻辑层又称作控制层，是 MaxCompute. 的核心部分，实现用户空间和对象的管理、命令的解析与执行逻辑、数据对象的访问控制与授权等功能。在逻辑层有 Worker 、 Scheduler 和 Executor 三个角色 ：

• Worker 处理所有的阻 STful 请求，包括用户空间( Project )管
  理操作、资源(Resource )管理操作、作业管理等，对于SQL DML、MR等需要启动 MapReduce 的作业，会生成MaxCompute Instance（类似于 Hive 中的 Job ） ，提交给 Scheduler 进一步处理。
• Scheduler 负责 MaxCompute Instance 的调度和拆解，并向计算层的计算集群询问资源占用情况以进行流控。
• Executor 负责 MaxCompute Instance 的执行，向计算层的计算集群提交真正的计算任务。

计算层就是飞天内核（ Apsara Core），运行在和控制层相互独立的
计算集群上，它包括 Pangu （分布式文件系统）、 Fuxi （资源调度系统） 、 Nuwa/ZK U、James pace 服 务） 、 Shennong （监控模块）等。 Max Compute 中的元数据存储在阿里云计算的另一个开放服务 OTS (Open Table Service，开放结构化数据服务） 中，元数据内容主要包括用户空间元数据、 Table/Partition Schema 、 ACL 、 Job 元数据、安全体系等。

2.1.2 MaxCompute 的特点

• 1.计算能力高且更加普惠

• 2.集群规模大且稳定性高

• 3.功能组件强大

• 4.安全性高

3.数据开发平台

数据开发平台集成了多个子系统来解决实际生产中的各种痛点。围绕 MaxCompute 计算平台，从任务开发、调试、测试、发布、监 控、 报警到运维管理，形成了整套工具和产品，既提高了开发效率，又保证了数据质量，并且在确保数据产出时效的同时，能对数据进行有效管理。

数据研发人员完成需求了解和模型设计之后，进入开发环节，开发 工作流如图：

3.1 在云端(D2)

D2 是集成任务开发、调试及发布，生产任务调度及大数据运维，数据权限申请及管理等功能的一站式数据开发平台 ， 并能承担数据分析工作台的功能。

用户使用 D2 进行数据开发的基本流程如下：

• 用户使用 IDE 进行计算节点的创建，可以是 SQL/MR 任务，也可以是 Shell 任务或者数据同步任务等，用户需要编写节点代码、设置节点属性和通过输入输出关联节点间依赖。设置好这些后，可以通过试运行来测试计算逻辑是否正确、结果是否符合预期。
• 用户点击提交，节点进入开发环境中，并成为某个工作流的其中一个节点。整个工作流可以被触发调度，这种触发可以是人为的（称之为“临时工作流”），也可以是系统自动的（称之为“日常工作流”）。当某个节点满足所有触发条件后，会被下发到调度系统的执行引擎 Alisa 中， 完成资源分配和执行的整个过程 。
• 如果节点在开发环境中运行无误，用户可以点击发布，将该节点正式提交到生产环境中，成为线上生产链路的一个环节。

3.2 SQLSCAN

SQLSCAN 将在任务开发中遇到的各种问题，如用户编写的 SQL质量差、性能低、不遵守规范等，总结后形成规则，并通过系统及研发流程保障，事前解决故障隐患，避免事后处理。
SQLSCAN 与 D2 进行结合，嵌入到开发流程中，用户在提交代码时会触发 SQLSCAN 检查。 SQLSCAN 工作流程如图所示：

• 用户在 D2 的 IDE 中编写代码。
• 用户提交代码， D2 将代码、调度等信息传到 SQL SCAN 。
• SQLSCAN 根据所配置的规则执行相应的规则校验。
• SQLSCAN 将检查成功或者失败的信息传回 D2。
• D2 的 IDE 显示 OK （成功）、 WARNNING （警告）、 FAILED
  （失败，禁止用户提交）等消息。

SQLSCAN 主要有如下三类规则校验：

• 代码规范类规则，如表命名规范、生命周期设置、表注释等。
• 代码质量类规则，如调度参数使用检查、分母为 0 提醒、 NULL值参与计算影响结果提醒、插入字段顺序错误等。
• 代码性能类规则，如分区裁剪失效、扫描大表提醒、重复计算检
  测等。

SQLSCAN 规则有强规则和弱规则两类。触发强规则后，任务的提交会被阻断，必须修复代码后才能再次提交 ； 而触发弱规则，则只会显示违反规则的提示，用户可以继续提交任务。

3.3 DQC

DQC (Data Quality Center ，数据质量中心）主要关注数据质量，通过配置数据质量校验规则，自动在数据处理任务过程中进行数据质量方面的监控。
DQC 主要有数据监控和数据清洗两大功能。数据监控，顾名思义,能监控数据质量并报警，其本身不对数据产出进行处理，需要报警接收人判断并决定如何处理；而数据清洗则是将不符合既定规则的数据清洗掉，以保证最终数据产出不含“脏数据”，数据清洗不会触发报警。
DQC 数据监控规则有强规则和弱规则之分，强规则会阻断任务的执行（将任务置为失败状态，其下游任务将不会被执行）；而弱规则只 告警而不会阻断任务的执行。常见的 DQC 监控规则有：主键监控、表 数据量及波动监控、重要字段的非空监控、重要枚举宇段的离散值监控、 指标值波动监控、业务规则监控等。
数据仓库的数据清洗采用非侵人式的清洗策略，在数据同步过 程中不进行数据清洗，避免影响数据同步的效率，其过程在数据进入 ODS 层之后执行。对于需要清洗的表，首先在 DQC 配置清洗规则；对于离线任务，每隔固定的时间间隔，数据人仓之后，启动清洗任务，调用DQC 配置的清洗规则，将符合清洗规则的数据清洗掉，并保存至 DIRTY 表归档。如果清洗掉的数据量大于预设的阐值，则阻断任务的执行；否则不会阻断。

DQC的运行流程如下：

3.4 在彼案

数据测试的典型测试方法是功能测试，主要验证目标数据是否符合预期。其主要有如下场景 ：

• 新增业务需求

新增产品经理、运营、 BI 等的报表、应用或产品需求 ， 需要开发
新的 ETL 任务，此时应对上线前的 ETL 任务进行测试，确保目标数据 符合业务预期，避免业务方根据错误数据做出决策。其主要对目标数据 和源数据进行对比，包括数据量、主键、字段空值、字段枚举值、复杂 逻辑（如 UDF、多路分支）等的测试。

• 数据迁移、重构和修改

由于数据仓库系统迁移、源系统业务变化、业务需求变更或重构等，需要对现有的代码逻辑进行修改，为保证数据质量需要对修改前后的数据进行对比，包括数据量差异、宇段值差异对比等，保证逻辑变更正确。为了严格保证数据质量，对于优先级（优先级的定义见“数据质量”章节）大于某个阔值的任务，强制要求必须使用在彼岸进行回归测试，在彼岸回归测试通过之后，才允许进入发布流程。
在彼岸则是用于解决上述测试问题而开发的大数据系统的自动化测试平台，将通用的、重复性的操作沉淀在测试平台中，避免被“人肉”，提高测试效率。

在彼岸主要包含如下组件，除满足数据测试的数据对比组件之外，
还有数据分布和数据脱敏组件。

1. 数据对比 ： 支持不同集群、异构数据库的表做数据对比。表级对比规则主要包括数据量和全文对比；字段级对比规则主要包括字段的统计值（如 SUM 、 AVG 、 MAX 、 MIN 等）、枚举值、空值、去重数、长度值等。
2. 数据分布：提取表和字段的一些特征值，并将这些特征值与预期值进行比对。表级数据特征提取主要包括数据量、主键等；字段级数据特征提取主要包括字段枚举值分布、空值分布、统计值（如 SUM 、 AVG 、 MAX 、 MIN 等）、去重数、长度值等。
3. 数据脱敏：将敏感数据模糊化。在数据安全的大前提下，实现线上数据脱敏，在保证数据安全的同时又保持数据形态的分布,以便业务联调、数据调研和数据交换。

使用在彼岸进行回归测试的流程如图：

参考资料

《大数据之路 某某公司大数据平台建设》
《hadoop构建数据仓库》