大数据：离线数据开发

  • 从采集系统中收集了大量的原始数据后，数据只有被整合和计算，才能被用于洞察商业规律，挖掘潜在信息，从而实现大数据价值，达到赋能于商业和创造价值的目的；
  • 面对海量的数据和复杂的计算，阿里的数据计算层包括两大体系：数据存储及计算平台（离线计算凭他 MaxCompute、实时计算平台 StreamCompute）、数据整合及管理体系（OneData）；

 

一、数据开发平台

  • 阿里数据岗位工作：了解需求——模型设计—— ETL 开发——测试——发布上线——日常运维——任务下线；
  • 阿里数据研发特点（与传统的数据仓库开发（ETL）相比）：
  1. 业务变更频繁——业务发展非常快，业务需求多且变更频繁；
  2. 需要快速交付——业务驱动，需要快速给出结果；
  3. 频繁发布上线——在集团公共层平均每个开发人员负责 500 多个任务；
  4. 系统环境复杂——阿里平台系统多为自研，且为了保证业务的发展，平台系统的迭代速度较快，平台的稳定性压力较大；

 

1、统一计算平台

  •  MaxCompute：由阿里自主研发的海量数据处理平台，主要服务于海量数据的存储和计算，提供完善的数据导入方案，以及多种经典的分布式计算模型，提供海量数据仓库的解决方案，能够更快速地解决用户的海量数据计算问题，有效降低企业成本，并保障数据安全。
  • MaxCompute 工作方式：采用抽象的作业处理框架，将不同场景的各种计算任务统一在同一个平台上，共享安全、存储、数据管理、资源调度，为来自不同用户需求的各种数据处理任务提供统一的编程接口和界面。（提供数据上传/下载通道、SQL、MapReduce、机器学习算法、图编程模型和流失计算模型多种计算分析服务）

1）MaxCompute 的体系架构

 

  •  MaxCompute 由四部分组成：客户端（MaxCompute Client）、接入层（MaxCompute Front End）、逻辑层（MaxCompute Server）、计算层（Apsara Core）；
  • MaxCompute 客户端有一下几种形式：
  1. Web：以 RESTful API 的方式提供离线数据处理服务；
  2. SDK：对 RESTful API 的封装，目前有 Java 等版本的实现；
  3. CLT（Command Line Tool）：运行在 Windows/Linux 下的客户端工具，通过 CLT 可以提交命令完成 Project 管理、DDL、DML 等操作；
  4. IDE：上层可视化 ETL/BI 工具，即阿里内部名称是在云端（D2），用户可以基于在云端完成数据同步、任务调度、报表生成等常见操作；
  5. 接入层：提供 HTTP 服务、Cache、负责均衡，实现用户认证和服务层面的访问控制；
  6. 逻辑层：又称作控制层，是 MaxCompute 的核心部分，实现用户空间和对象的管理、命令的解析与执行逻辑、数据对象的访问控制与授权等功能。（在逻辑层有 Worker、Scheduler、Executor 三个角色）
  • Worker：处理所有的 RESTful 请求，包括用户空间（Project）管理操作、资源（Resource）管理操作、作业管理等，对于 SQL DML、MR等需要启动 MapReduce 的作业，会生成 MaxCompute Instance（类似于 Hive 中的 Job），提交给 Scheduler 进一步处理；
  • Scheduler：负责 MaxCompute Instance 的调度和拆解，并向计算层的计算集群询问资源战友情况以进行流控；
  • Executor：负责 MaxCompute Instance 的执行，向计算层的计算集群几条真正的计算任务；

 

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

 

 2）MaxCompute 的特点

  • 计算性能高且更加普惠；
  • 集群规模大且稳定性高；
  • 功能组件非常强大：
  1.  MaxCompute SQL：标准 SQL 的语法，提供各类操作和函数来处理数据；
  2. MaxCompute MapReduce：提供 Java MapReduce 编程模型，通过接口编写 MR 程序出了 MaxCompute 中的数据。还提供基于 MapReduce 的扩展模型 MR2，在该模型下，一个 Map 函数后可以鸡儿连续多个 Reduce 函数，执行效率比普通的 MapReduce 模型高；
  3. MaxCompute Graph：面向迭代的图计算出了框架，典型应用有 PageRank、但源最短距离算法、K-均值聚类算法；
  4.  RMaxCompute：使用 R 处理 MaxCompute 中的数据；
  5. Volume：MaxCompute 以 Volume 的形式支持文件，管理非二维表数据；
  • 安全性高

 

2、统一开发平台

 

  • 开发工作流图
  • 对应于开发工作流的产品和工具

1）在云端（D2）

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

 

2）SQLSCAN

  • SQLSCAN：总结开发中遇到的问题（如用户编写的 SQL 质量差、性能低、不准守规范等），形成规则，并通过系统及研发流程保障，事前解决故障隐患，避免事后处理。
  1.  用户在 D2 的IDE 中编写代码；
  2. 用户提交代码，D2 将代码、调度等信息传到 SQLSCAN；
  3. SQLSCAN 根据所配置的规则执行响应的规则检验；
  4. SQLSCAN 将检查成功或者失败的信息传回 D2；
  5. D2 的 IDE 显示 OK（成功）、WARNNING（警告）、FAILED（失败，禁止用户提交）等消息；
  • SQLSCAN 主要有三类规则校验：
  1. 代码规范类规则；（如表命名规范、生命周期设置、表注释等）
  2. 代码质量类规则；（如调度参数使用检查、分母为 0 提醒、NULL 值参与计算影响结果提醒、插入字段顺序错误等）
  3. 代码性能类规则；（如分区裁剪失效、扫描大表提醒、重复计算检测等）
  • SQLSCAN 规则有强规则和弱规则两类：
  1. 触发强规则：任务的提交被阻断，必须修复代码后才能再次提交；
  2. 触发弱规则：只会显示违反规则的提示，用户可以继续提交任务；

 

3）DQC（Data Quality Center，数据质量中心）

  • DQC：通过配置数据质量校验规则，自动在数据处理任务过程中进行数据质量方面的监控；
  • DQC 主要的两大功能：
  1. 数据监控：监控数据质量并报警，本身不对数据产出进行处理，需要报警接收人判断并决定如何处理；
  2. 数据清洗：将不符合既定规则的数据清洗掉，保障最终数据产出不含“脏数据”，数据清洗不会触发报警；
  • DQC 数据监控规则有强规则和弱规则之分，强规则会阻断任务的执行（将任务置于失败状态，其下游任务将不会被执行）；而弱规则智慧警告而不会阻断任务的执行。
  • 常见的 DQC 监控规则：主键监控、表数据量及波动监控、重要字段的费控监控、重要枚举子弹的离散值监控、指标值波动监控、业务规则监控等。
  •  

 

4）在彼岸

  • 在彼岸：自动化的大数据测试平台，将通用的、重复性的操作沉淀在测试平台中，避免被“人肉”，提高测试效率。
  • 数据测试的典型测试方法是功能测试，主要验证目标数据是否符合预期，主要场景：

 

  • 新增业务需求
  1. 测试原因及目的：新增产品经理、运营、BI等的报表、应用或产品需求，需要开发新的 ETL 任务，此时应对上线前的 ETL 任务进行测试，确保目标数据符合业务预期，避免业务方根据错误数据做出决策；
  2. 测试方法：对目标数据和源数据进行对比，包括数据量、主键、字段空值、字段枚举值、复杂逻辑（如 UDF、多路分支）等的测试；
  • 数据迁移、重构、修改
  1.  测试远程及目的：由于数据仓库系统迁移、源系统业务变化、业务需求变更或重构等，需要对现有的代码逻辑进行修改，为保证数据质量需要对修改前后的数据进行对比，包括数据量差异、字段值差异对比等，保证逻辑变更正确。
  2. 测试方法：对优先级大于某个阈值的任务，强制要求必须使用在彼岸进行回归测试，在回归测试通过后，才允许进入发布流程。
  • 在彼岸的测试组件：数据测试的数据对比组件、数据分布组件、数据脱敏组件；
  1. 数据对比组件：支持不同集群、异构数据库的表做数据对比。（表级对比规则主要包括数据量和全文对比；字段对比规则主要包括字段的统计值（如 SUM、AVG、MAX、MIN 等）、枚举值、空值、去重复、长度值等。）
  2. 数据分布组件：提取表和字段的一些特征值，并将这些特质值与预期值进行行比对。（表级数据特质提取主要包括数据量、主键等；字段级数据特质提取主要包括字段枚举值分布、空值分布、统计值（如 SUM、AVG、MAX、MIN 等）、枚举值、空值、去重复、长度值等。）
  3. 数据脱敏组件：将敏感数据模糊化。（在数据安全的大前提下，实现线上数据脱敏，在保证数据安全的同事又保证数据形态的分布，以便业务联调、数据调研和数据减缓。）

 

 

二、任务调度系统

1、背景

  • 调度系统：整个大数据系统的智慧中枢。
  • 在大数据环境下，每天需要处理海量的任务，多的可以达到几十上百万。另外，任务的类型也很复杂，有 MapReduce、Hive、SQL、Spark、Java、Shell、Python、Perl、虚拟节点等，任务之间互相依赖且需要不同的运行环境，任务调度系统就是所有任务的指挥系统。
  • 传统的数据仓库系统中，很多是依靠 Crontab 定时任务功能进行任务调度处理的，此方式有很多弊端：
  1. 个任务的依赖基于执行时间实现，容易造成前面的任务未结束或失败而后面的任务已经运行；
  2. 任务难以并发执行，增加了整体的处理时间；
  3. 无法设置任务优先级；
  4. 任务的管理维护很不方便，无法进行执行效果分析。

 

2、介绍

1）数据开发流程与调度系统的关系

  • 用户通过 D2 平台提交、发布的任务节点，需要通过调度系统，按照任务的运行顺序调度运行。

 

2）调度系统的核心设计模型

  • 两个核心模块：调度引擎（Phoenix Engine）、和执行引擎（Alisa）。
  1. 调度引擎：根据任务节点属性以及依赖关系进行实例化，生成各类参数的实值，并生成调度树；
  2. 执行引擎：根据调度引擎生成的具体任务实例和配置信息，分配 CPU、内存、运行节点等资源，在任务对应的执行环境中运行节点代码。

 

 3）任务状态机模型

  • 任务状态机模型：是针对数据任务节点在整个运行生命周期的状态订阅，总共 6 种状态：

 

4）工作流状态机模型

  • 工作状态机模型：针对数据任务节点在调度树中生成的工作流运行的不同状态的定义，共有 5 找那个状态：

 

5）调度引擎工作原理

  • 原理：基于任务状态机模型和工作流状态机模型原理，以事件驱动的方式运行，为数据任务节点生成实例，并在调度树中生成具体执行的工作流。任务节点实例在工作流状态机、任务状态机和事件处理器之间转换，其中调度引擎只涉及任务状态机的未运行和等待运行两种状态：

 

 

  1.  Async Dispatcher：异步处理任务调度；
  2. Sync Dispatcher：同步处理任务调度；
  3. Task 事件处理器：任务事件处理器，与任务状态机交互；
  4. DAG 事件处理器：工作流事件处理器，与工作流状态机交互。（一个DAG 事件处理器包含若干个 Task 事件处理器。）

 

6）执行引擎工作原理

 

 

 

3、特点及应用

1）调度配置

  • 常见调度配置方式：对具体任务手工配置依赖的上游任务。
  • 　　　　# 此方式存在两个问题：一是配置上比较麻烦，需要知道上游依赖表的产出任务；二是上游任务修改不在产出依赖表或本身任务不再依赖某上游任务时，对调度依赖不做修改，导致依赖配置错误。

 

2）定时调度

  • 根据实际需要，设定任务的运行时间，共有 5 种时间类型：分钟、小时、日、周、月，具体可精确到秒。

 

3）周期调度

  • 按照小时、日等时间周期运行任务，与定时调度的区别是无需指定具体的开始运行时间。

 

4）手动运行

  • 当生产环境需要做一些数据修复或其他一次性的临时数据操作时，可以选择手动运行的任务类型，在开发环境（IDE）中写好脚本后发布到生产环境，再通过手动触发运行。

 

5）补数据

  • 在完成数据开发的发布以后，有些表需要进行数据初始化，比如有些日增量表要补齐最近三年的历史数据，这时就需要用到补数据任务。（可以设定需要补的时间区间，并圈定需要运行的任务节点，从而生成一个补数据的工作流，同时还能选择并行的运行方式以节约时间。）

 

6）基线管理

  • 基于充分利用计算资源，保证重点任务优先产出，合理安排各类优先级任务的运行，调度系统引入了按优先级分类管理的方法。
  • 优先级分类从 1~9，数字越大代表优先级越高，系统会先保障高优先级任务的运行资源。
  • 对于同一类优先级的任务，放到同一条基线中，可以实现按优先级不同进行分层的统一管理，并可对基线的运行时间进行预测估计，以监控是否在规定的时间内完成。

 

 

 

7）监控报警

  • 调度系统有一套完整的监控报警系统，包括针对出错的节点、运行超时未完成的节点，以及可能超时的基线等，设置电话、短信、邮件等不停的告警方式，实现了日常数据运维的自动化。

 

posted @ 2020-07-30 09:55  何永灿  阅读(2579)  评论(0)  编辑  收藏  举报