分布式 dataX 详细 (落地) 设计

1.    背景

      分布式 DataX 基于 datax 打造的语义分分布式 ETL 平台。Datax 提供 reader-framework-writer 框架，方便开发两种异构数据源数据同步，但开源的 社区版datax 缺少分布式特性，本文介绍基于 elastic 平台和 elastic-scheduler 改造分布式 datax 详细(落地)设计

2.    参考和术语

ETL Extract-Transform-Load 的缩写，数据从来源端经过抽取（extract）、转换（transform）、加载（load）至目的端

《分布式 datax 架构设计》分布式架构设计文档，分布式 datax 概念和高层的时间

《elastic 平台设计》分布式支撑服务设计说明

《分布式时间槽架构设计》 介绍分布式时间槽详细设计

3.    概览

下图展示分布式 datax 概览

rbt 全量同步，接入分布式 datax

cdc 增量同步，接入云 datax

rb-transformer  基于规则的转换框架

setl-data 数据读写组件，包括 cdc，jdbc(jpa)，neo4j

config-center 配置中心，支持 zk，nacos 等，可扩展，datax 的配置文件，job.json，core.json，数据同步业务的文件放到配置中心无需依赖本地文件

scanner 数据库扫描工具包，生成 schema，辅助数据同步

分布式 datax   支持时间槽模式和调度作业模式

  cloud-datax

  elastic-datax

4.    datax 原理

*官方图，Transport 处是 Channel，本人觉得不太准确，应为 Transport

> 作业分解为任务，任务分组，最后调度器调度任务(组)

> 调度器负责分派资源执行任务(组)，TaskExecutor 执行任务

>  transport 包括数据交换(exchanger)，数据转换(transformer)，交换数据字节数/记录数的统计(channel)

5.    分布式 datax 设计原理

Datax原理介绍了社区版的 datax 原理，数据同步分两部分，任务分组和调度，其中调度与分布式有关，datax 抽象了调度接口，因此分布式 datax 主要是实现 datax 分布式调度器及其 Communication 组件

Ø  Datax 调度逻辑

分 3 步，

1）  注册和初始化 Communication 组件，其中的 configurations 即任务组

2）  开启任务(组)执行 startAllTaskGroup

3）  作业执行期间，周期性地计算作业/任务组的执行状态

Ø  Datax 调度器接口规范：

startAllTaskGroup 调度的主要实现接口

dealFailedStat/dealKillingStat 任务组失败/killing 处理

isJobKilling 作业 killing 事件处理

Ø  datax 任务组模式

分片是任务组，datax engine 的任务组模式正好对应分片执行，接收分布式作业传入的分片即可

Ø  communication 组件

社区版的 communication 模型

通讯器 Communicator 负责管理/收集报告/通讯 Communication

Collector 合并任务为任务组统计；合并任务组为作业统计

Reporter

分布式架构下，任务组在本地执行，统计与社区版的单机模式相同，但输出到 redis

作业统计从 redis 获取任务组统计，再累计为作业统计，从而做作业 summary,  支持快照和摘要输出到持久存储

Ø  PerTracer 组件和 VM 信息

两单机组件，不对该组件改造

6.    分布式组件

elastic 平台 分布式支撑服务，如，znode 读写，服务注册，选主服务，实例服务，分片，分片容错

elastic-timeslot/elastic-jobx 基于 elastic 平台的分布式调度，支持作业分片，分片容错

两者合并为 elastic-scheduler，支持时间槽模式和调度作业双模式

elastic 为分布式开发提供基础组件，通用组件，大大减轻分布式开发时间和难度

7.    分布式 datax 技术架构

client/watcher/worker

client 负责写入任务组分片，触发 worker 执行；client 可集成到管理台；作业监管，检测作业完成，清理作业环境

watcher 作业统计，输出统计；按作业分片观测和聚合计算; watcher 可集成到管理台

worker 分配分片；任务(组)执行，任务组执行统计

整体架构设计遵循不修改，只扩展的原则，兼容原有 standalone

8.    详细设计

8.1     分布式 Scheduler

分布式调度器是 client 的一部分，第7章 技术架构分布式调度原有的功能作业统计分离到 watcher，分布式调度功能简单了很多，只要写入分片(任务组)，写入作业统计分片，trigger worker

写入分片(任务组和作业统计)提供事务保证

调度器在 JobContainer 根据-m 参数初始化，standalone 单机的调度器 StandAloneScheduler，distribute 使用 ElasticScheduler

8.2     工作节点(worker)

工作节点是运行模式为 taskgroup 的 datax engine

engine 接入分布式作业，作业上下文(shardingContext)装载着分派的任务组(分片)，engine 从上下文获取分片

8.3     观测节点(watcher)

观测节点负责周期性地计算作业统计快照和汇总，输出到持久数据源

观测节点部署于分布式调度时间槽模式

8.4     Communication 组件

Communication 是任务/任务组/作业执行状态统计组件，分两个层级，任务组和作业，任务组本地执行，作业聚合任务组的统计

注册 注册任务/任务组统计，后续的报告根据注册更新；分布式场景下，注册任务与单机一直，注册任务组就是是写入分片

收集  增量合并或累计

1. counter 累计

2. state 合并

3. message 合并

分布式场景下，输出到 redis；单机场景下，默认写日志或 NOP(啥都不做)

报告 生成新的统计，报告给通讯器，通讯器 update 为最新统计

计算 计算衍生的统计指标，如速率

分布式场景下，操作与单机相同，任务组聚合任务统计，作业聚合任务组统计；不同的是读入来源，分布式任务组统计放到 redis

输出 保存作业统计，快照和汇总

Ø  统计输出组件

组件负责 Communication 输出作业状态快照和汇总

快照在作业执行期间，周期性地收集作业任务(组)并累计数据

汇总是作业执行速率报告，可以用于对账，检查作业执行完整性，平台的性能

分布式场景下任务组状态输出到 redis(HMSET 结构)，设置时效，下图 展示 snapshot 和 summary 结构

Ø  本着” 不修改，只扩展的原则”，输出组件扩展原因的 reporter 组件，分布式场景下，使用 redis 实现，单机使用 log 或 nop

Ø  输出库接口设计item 对应任务组统计；agg 聚合任务组的作业统计；metrics 作业设定时间间隔速率计算，即作业 summary，特别地，作业完成后的作业统计与初始作业统计的 metrics 计算是作业的最终 summary

模板 T 对应 snapshot，S 对应 Summary

NEXT

集成弹性资源

 随着弹性资源平台的完成，集成到弹性资源，提供高弹性伸缩

https://blog.csdn.net/szlhj/category_12446958.html