赞
踩
数据从最原始的状态,可能是一个 excel,一个文本,或者是来自业务数据库的数据,格式各种各样,落地到数据仓库、数据湖中,数据的同步过程 是必不可少的
传统的数据同步方式主要是基于定时任务的模式,通过任务调度服务,每天定时将原始数据提取(extract),进行清洗处理,比如过滤掉重复数据(transform),最后存入数仓(load),即 ETL 任务模式。这种模式对数据的实时性要求不高,常见的同步工具有 datax、sqoop
实时同步,则需要让同步任务一直处于运行状态,有新数据进来需要在秒级别内更新。这种情况下传统的调度模式就不能满足了,需要能时刻监测数据同步状态、管理和启停任务、甚至动态分配任务资源。一种常见的模式是 任务通过 spark / flink 等流式任务引擎去执行,然后在上层通过 k8s 或其他任务管理平台 进行调度
本质上实时同步数据的模式和 ETL 是一样的,对数据依然有 抽取、清洗和写入的操作。只是时效性、任务管理复杂度、资源动态分配能力上,要求会更高
图片来源-DataFunTalk:阿里建设一站式实时数仓的经验分享
搭建可以在公司内通用的 EMR 平台,除了满足数据同步的功能,还需要提供任务调度的功能,因为用户的任务各种各样,可能是自定义的 spark / flink 任务,python 脚本 对数据自行处理的任务 等等,所以需要提供能让用户自行上传任务、执行任务的平台
不过相比数据同步 离线和实时同步架构相差较大,任务调度平台架构的发展则不离其宗,基本变化不大
本文将会对业界主流的任务调度服务 和 数据同步服务 做一些介绍,大家可以参考,择优选择更适合自己业务需求的服务 进行尝试
这里列举三个主流的任务调度服务: azkaban、airflow 和 dolphinscheduler。我们先分别看基于这三个组件 数仓的架构可能是什么样的,然后系统对比,最后大致看下使用页面
基于DolphinScheduler的使用浅谈数仓分层及模型设计
大数据调度平台分类大对比(Oozie/Azkaban/AirFlow/XXL-Job/DolphinScheduler)
特性\组件 | 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 任务,但是相比前两个组件,更新不是特别活跃
对数据同步而言,支持更多的数据源是更重要的,传统数据同步工具,如 sqoop、datax ,都是对基于hadoop的传统数仓、基于关系型数据库 支持更好,不过对更现代的 OLAP、甚至湖仓一体的架构支持并不够好
随着发展,功能更强大的同步组件 如 seatunnel、chunjun 也逐渐占有了一席之地,在业务使用实际场景中可以优先选择它们
【知识】ETL大数据集成工具Sqoop、dataX、Kettle、Canal、StreamSets大比拼
特点:
特点:
特点:
特点:
【大数据】什么是数据集成?(SeaTunnel 集成工具介绍)
特点:
特点:
对于任务调度平台来说,本质上都是 定时 + 触发任务 + 管理任务 的使用机制,基本架构都离不开 scheduler + task worker,相差不大
但对于数据同步组件来说,现在有一种离线往实时迁移的趋势。所以 诸如 sqoop、datax 这种传统离线数据同步方式应该会逐渐淡出,相比较,seatunnel 、 airbyte 这种后起之秀 一定会越来越强大。不过,实时也意味着需要更灵活的资源分配方式,需要掌握更深的技术栈,对开发人员要求也会更高
Anyway,所有大数据架构的底层都是存储。数据如果是存放在 hdfs + hive 这种架构,对实时性要求不高,那么 sqoop + azkaban / airflow 模式就完全足够了。数据需要存放在 clickhouse / kudu 这种 OLAP 存储,业务需要获取实时数据进行分析,那么就需要 seatunnel 这种实时同步的服务。没有绝对的哪个更好,只有更合适
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。