datax和canal对比

datax和canal对比

文章目录

  • datax和canal对比
      • 前言
      • 功能简介
      • 对比
        • datax
        • canal

前言

datax和canal都是阿里巴巴开开源的数据同步组件/工具,但是二者在功能架构、使用场景上又有些区别。我刚接触到这两个组件的时候,经常混淆他们,不太能分清楚他们各自的使用场景。今天这篇文章就打算彻底对比下两者的共同点和差异。

功能简介

DataX 是阿里巴巴开源的离线数据同步工具/平台,内置实现了包括 MySQL、Oracle、SqlServer、Postgre、HDFS、Hive、ADS、HBase、TableStore(OTS)、MaxCompute(ODPS)、DRDS 等各种异构数据源之间高效的数据同步功能。

canal译意为水道/管道/沟渠,主要用途是基于 MySQL 数据库增量日志解析,提供增量数据订阅和消费。

从上面两段描述,我们可以了解到二者在使用场景上的区别,虽然都是数据传输工具,但datax主要是离线的场景,而canal是实时的场景。

对比

datax

datax的网络传输拓扑如下:

datax和canal对比_第1张图片

从上图可以看出,datax其实是起到了一个中间的传输桥梁的角色。多个数据源之间传输是个网状的拓扑结构,但是接入了datax后,可以变成一个星状的结构,简化了整个传输的模型。

datax和canal对比_第2张图片

这幅图是datax的总体架构图,可以看到,datax采用Framework + plugin架构构建。

其中Framework处理了缓冲,限流,并发,上下文加载等技术问题。

而plugin就牛逼了,它提供了超强的扩展能力。将数据源读取和写入抽象成为Reader/Writer接口,纳入到整个同步框架中。如果内置的plugin无法满足我们的场景,开发者可以自己编写plugin定制功能。

开发者实现自己的插件非常简单,仅需实现对数据处理系统的访问即可,因为核心技术部分framework已经帮我们做好了。

framework内部的核心架构如下所示:

datax和canal对比_第3张图片

我看到这幅图的第一反应就是,跟flink有点像,事实上他们确实有很多相似的地方。对于一个任务,datax采用的是单进程+多线程的模式。流程如下:

  1. DataX完成单个数据同步的作业,我们称之为Job,DataX接受到一个Job之后,将启动一个进程来完成整个作业同步过程。DataX Job模块是单个作业的中枢管理节点,承担了数据清理、子任务切分(将单一作业计算转化为多个子Task)、TaskGroup管理等功能。

  2. DataXJob启动后,会根据不同的源端切分策略,将Job切分成多个小的Task(子任务),以便于并发执行。Task便是DataX作业的最小单元,每一个Task都会负责一部分数据的同步工作。

  3. 切分多个Task之后,DataX Job会调用Scheduler模块,根据配置的并发数据量,将拆分成的Task重新组合,组装成TaskGroup(任务组)。每一个TaskGroup负责以一定的并发运行完毕分配好的所有Task,默认单个任务组的并发数量为5。

  4. 每一个Task都由TaskGroup负责启动,Task启动后,会固定启动Reader—>Channel—>Writer的线程来完成任务同步工作。

  5. DataX作业运行起来之后, Job监控并等待多个TaskGroup模块任务完成,等待所有TaskGroup任务完成后Job成功退出。否则,异常退出,进程退出值非0。

举例来说,用户提交了一个DataX作业,并且配置了20个并发,目的是将一个100张分表的mysql数据同步到odps里面。DataX的调度决策思路是:

  • DataXJob根据分库分表切分成了100个Task。
  • 根据20个并发,DataX计算共需要分配4个TaskGroup。(20/5=4,5是单个taskgroup默认使用的并发数量)
  • 4个TaskGroup平分切分好的100个Task,每一个TaskGroup负责以5个并发共计运行25个Task。

canal

canal的总体架构图如下:

datax和canal对比_第4张图片

canal的数据源只支持mysql,这点需要特别注意,这也限制了它的使用场景。

datax和canal对比_第5张图片

上图是mysql主从复制的原理图:

  • MySQL master 将数据变更写入二进制日志( binary log, 其中记录叫做二进制日志事件binary log events,可以通过 show binlog events 进行查看)
  • MySQL slave 将 master 的 binary log events 拷贝到它的中继日志(relay log)
  • MySQL slave 重放 relay log 中事件,将数据变更反映它自己的数据

Canal 伪装成 MySQL 从节点,mySQL master 会推送 binary log 给canal,canal读取 MySQL binlog的变更信息并生成消息,客户端订阅这些数据变更消息,处理并存储。只要开发一个 Canal客户端就可以解析出MySQL的操作,再将这些数据发送到大数据流计算处理引擎,即可以实现对 MySQL 实时处理。

我们一般使用canal时,只需要引入一个客户端,比如java类似这样:


    com.alibaba.otter
    canal.client
    1.1.0

然后就可以订阅binlog消息了。

另外canal也支持直接把binlog消息发送到mq,这样对多语言的支持更好一些。

canal自身帮我们做了很多事,这样我们自己写的客户端才能更简单,更专注于业务。下面就来看看canal内部的架构。

datax和canal对比_第6张图片

说明:
server代表一个canal运行实例,对应于一个jvm

instance对应于一个数据队列

核心是instance模块,它包含:

  • eventParser (数据源接入,模拟slave协议和master进行交互,协议解析)
  • eventSink (Parser和Store链接器,进行数据过滤,加工,分发的工作)
  • eventStore (数据存储)
  • metaManager (增量订阅&消费信息管理器)

参考:

  • https://github.com/alibaba/DataX/blob/master/introduction.md
  • https://github.com/alibaba/canal

你可能感兴趣的:(Canal源码解读,DataX源码分析,canal,datax,ETL,数据传输,对比)