大数据任务调度和数据同步组件初探

xiaoliizi

已于 2023-05-09 23:06:00 修改

阅读量1.2k

点赞数 1

分类专栏：大数据文章标签：大数据 emr

于 2023-05-08 23:43:09 首次发布

本文链接：https://blog.csdn.net/xiaoliizi/article/details/130569690

版权

大数据专栏收录该内容

7 篇文章 1 订阅

订阅专栏

本文个人博客地址
 本文公众号地址

背景

数据从最原始的状态，可能是一个 excel，一个文本，或者是来自业务数据库的数据，格式各种各样，落地到数据仓库、数据湖中，数据的同步过程是必不可少的

在这里插入图片描述

图片来源

传统的数据同步方式主要是基于定时任务的模式，通过任务调度服务，每天定时将原始数据提取（extract），进行清洗处理，比如过滤掉重复数据（transform），最后存入数仓（load），即 ETL 任务模式。这种模式对数据的实时性要求不高，常见的同步工具有 datax、sqoop

在这里插入图片描述

实时同步，则需要让同步任务一直处于运行状态，有新数据进来需要在秒级别内更新。这种情况下传统的调度模式就不能满足了，需要能时刻监测数据同步状态、管理和启停任务、甚至动态分配任务资源。一种常见的模式是任务通过 spark / flink 等流式任务引擎去执行，然后在上层通过 k8s 或其他任务管理平台进行调度

本质上实时同步数据的模式和 ETL 是一样的，对数据依然有抽取、清洗和写入的操作。只是时效性、任务管理复杂度、资源动态分配能力上，要求会更高

在这里插入图片描述

图片来源-DataFunTalk：阿里建设一站式实时数仓的经验分享

搭建可以在公司内通用的 EMR 平台，除了满足数据同步的功能，还需要提供任务调度的功能，因为用户的任务各种各样，可能是自定义的 spark / flink 任务，python 脚本对数据自行处理的任务等等，所以需要提供能让用户自行上传任务、执行任务的平台

在这里插入图片描述

图片来源-xxl-job工作原理解析

不过相比数据同步离线和实时同步架构相差较大，任务调度平台架构的发展则不离其宗，基本变化不大

本文将会对业界主流的任务调度服务和数据同步服务做一些介绍，大家可以参考，择优选择更适合自己业务需求的服务进行尝试

云原生背景下的任务调度组件

这里列举三个主流的任务调度服务: azkaban、airflow 和 dolphinscheduler。我们先分别看基于这三个组件数仓的架构可能是什么样的，然后系统对比，最后大致看下使用页面

传统离线数仓: azkaban

在这里插入图片描述

大数据开发之路-离线数仓

实时离线融合: airflow

在这里插入图片描述

Data Warehouse

实时离线融合: dolphinscheduler

在这里插入图片描述

基于DolphinScheduler的使用浅谈数仓分层及模型设计

对比

大数据调度平台分类大对比(Oozie/Azkaban/AirFlow/XXL-Job/DolphinScheduler)

【大数据】【调度】Airflow 和 Azkaban的选型

特性\组件	airflow	dolphinscheduler	azkaban
web界面	有，功能比较多	有，且支持中文	有，比较简单
工作流语法	python代码内定义，可通过界面查看但不能编辑	可视化编辑，对小白很友好，但不适合通过代码编排	配置文件
跨dag/project依赖	支持，可通过 ExternalTaskSensor 配置	不支持	不支持
易用程度	安装和维护上手难度高，组件包括 WebServer、Scheduler、Worker	安装维护上手难度高，组件包括 master、api、alert、worker 等，不过界面支持中文，可视化编辑任务比较友好	上手难度低，只有 webserver、executor 两个组件
变量定义	支持全局参数，和一些内置模板变量，如 {{ ds }}	不支持全局变量	不支持全局变量
调度中心HA	支持，对 db 版本有要求（mysql >= 8）	支持	不支持
执行器HA	支持	支持	支持
权限管控	支持用户、任务级别配置	用户角色支持管理员、普通用户两种，不支持项目层级配置	支持用户、任务级别配置
任务监控	可通过定义 on_failure_callback 在任务结束后触发提醒，示例，支持metrics	支持任务告警，支持通过企业微信、飞书等方式发送	可配置 job 的 failure.emails 让任务失败后发送邮件提醒

总结: ds 对各种 ETL 任务类型的界面化配置支持更好，airflow 更适合 python 基础较好的团队使用，编排任务代码化笔者认为也是一种趋势。azkaban 较为传统，使用起来更简单，也更适合定义流程简单的 ETL 任务，但是相比前两个组件，更新不是特别活跃

airflow 架构和界面

在这里插入图片描述

Architecture Overview

dolphinscheduler 界面

在这里插入图片描述

azkaban 架构和界面

在这里插入图片描述

1. Azkaban 介绍

数据同步组件

对数据同步而言，支持更多的数据源是更重要的，传统数据同步工具，如 sqoop、datax ，都是对基于hadoop的传统数仓、基于关系型数据库支持更好，不过对更现代的 OLAP、甚至湖仓一体的架构支持并不够好

随着发展，功能更强大的同步组件如 seatunnel、chunjun 也逐渐占有了一席之地，在业务使用实际场景中可以优先选择它们

sqoop

在这里插入图片描述

Sqoop原理和架构

【知识】ETL大数据集成工具Sqoop、dataX、Kettle、Canal、StreamSets大比拼

特点：

离线全量同步，不支持增量导入
仅支持关系型数据库，比如从 mysql 同步到 hive
任务运行方式: mapreduce

datax

在这里插入图片描述

阿里云开源离线同步工具DataX3.0介绍

在这里插入图片描述

数据同步 DATAX 工作原理及源码解读

特点：

相比 sqoop 支持的数据源更丰富，支持非关系型数据库（如从 mysql 写到 hdfs、mongodb、es 等）
表字段的映射，必须提前写成json配置
同步任务在单节点运行（在执行 datax 的节点运行）

canal

在这里插入图片描述

Canal——原理架构及应用场景

特点：

只能同步增量数据（本质：模拟 mysql slave 进行数据同步）
支持数据源: kafka、rocketmq、hbase、elasticsearch
实时任务管理：需要单独部署管理服务，如 cloudin-datax、Canal Admin

datalink

在这里插入图片描述

git-ucarGroup/DataLink

特点：

支持增量数据同步任务的管理，基本任务启停、同步状态检查等
对 canal 、datax 等同步工具进行了封装，支持数据源: mysql、hbase、elasticsearch、kafka、kudu
神州租车开源，现在不再维护，不过基本功能比较完善

神州优车数据交换平台的架构、建设与痛点难点详解

seatunnel

在这里插入图片描述

【大数据】什么是数据集成？（SeaTunnel 集成工具介绍）

特点：

通过spark / flink 方式同步数据，支持更多现代数据源（clickhouse、doris、iceberg 等）
UI 还不是很完善
笔者后续会更详细地体验这个工具，补充和更多实时同步组件的使用对比

airbyte

在这里插入图片描述

Architecture overview

特点：

完全云原生化的数据同步服务，一个同步任务对应一个容器
适用ETL 场景（配置定时任务，最小周期5分钟，并不是完全实时）
上手难度高，学有余力可以尝试

展望

对于任务调度平台来说，本质上都是 定时 + 触发任务 + 管理任务 的使用机制，基本架构都离不开 scheduler + task worker，相差不大

但对于数据同步组件来说，现在有一种离线往实时迁移的趋势。所以诸如 sqoop、datax 这种传统离线数据同步方式应该会逐渐淡出，相比较，seatunnel 、 airbyte 这种后起之秀一定会越来越强大。不过，实时也意味着需要更灵活的资源分配方式，需要掌握更深的技术栈，对开发人员要求也会更高

Anyway，所有大数据架构的底层都是存储。数据如果是存放在 hdfs + hive 这种架构，对实时性要求不高，那么 sqoop + azkaban / airflow 模式就完全足够了。数据需要存放在 clickhouse / kudu 这种 OLAP 存储，业务需要获取实时数据进行分析，那么就需要 seatunnel 这种实时同步的服务。没有绝对的哪个更好，只有更合适