十款开源数据集成工具，总有一款适合你
在大数据作业开发中，数据集成工具是非常重要的一个环节，一个好的数据集成系统从可用性、架构扩展性、底层引擎选型、数据源支持能力等方面都需要一定的考量，在本文中汇总了十款开源的数据集成系统，作者本人在过往的开发过程中，使用过其中的7款（DataX、Flume、Seatunnel、Canal、BitSail、InLong、Chunjun(Flinkx) ），其中三款（AiyByte、CloudCanal、Nifi），本文是对于每款数据集成软件的基础介绍说明，如果对于实践部分感兴趣的话，可以关注后续内容（如果你对于数据集成感兴趣的话，可以加入我们的小群（文末扫码），一起来交流&测试）
wx添加kubedata，加入云原生大数据交流群，或者关注公众号：云原生大数据技术荟，领取干货资料
本文分为两个部分，一部分是对于十款不同组件的介绍，包括基本信息、特性支持、架构介绍等等，可以当作对于每个组件的基本了解，当然了，如果你有兴趣想参与测试每个组件的话，也欢迎一起来进行实践操作。另一部分是关于开源组件的一些基础维度对比，包括开源社区、背后支持企业、活跃度等等。
Apache InLong: 一站式、全场景的海量数据集成框架
SeaTunnel: 下一代高性能、分布式、海量数据集成框架
Chunjun:基于Flink的批流统一的数据同步工具
BitSail : 高性能数据集成引擎
AirByte：开源的数据移动基础设施
CloudCanal : 数据同步、迁移工具
Flume ：开源分布式、高可靠的流式日志采集系统
Canal：数据库增量日志解析、采集工具
Nifi：一个易于使用、功能强大且可靠的系统，用于处理和分发数据
DataX：异构数据源离线同步工具
一：Apahce InLong ：一站式、全场景的海量数据集成框架
Apache InLong（应龙）是一站式、全场景的海量数据集成框架，同时支持数据接入、数据同步和数据订阅，提供自动、安全、可靠和高性能的数据传输能力，方便业务构建基于流式的数据分析、建模和应用。 InLong 项目原名 TubeMQ ，专注于高性能、低成本的消息队列服务。为了进一步释放 TubeMQ 周边的生态能力，我们将项目升级为 InLong，专注打造一站式、全场景海量数据集成框架。 Apache InLong 依托 10 万亿级别的数据接入和处理能力，整合了数据采集、汇聚、存储、分拣数据处理全流程，拥有简单易用、灵活扩展、稳定可靠等特性。 该项目最初于 2019 年 11 月由腾讯大数据团队捐献到 Apache 孵化器，2022 年 6 月正式毕业成为 Apache 顶级项目。
InLong 架构设计
InLong有两种架构模式，一种是标准架构，提供了更加丰富的能力，也支持Dashboard、CLI、API、SDK的能力，轻量化架构是将中间的数据集成层单独剥离了出来，更加的简单、灵活。
标准架构：包含 InLong Agent、Manager、MQ、Sort、Dashboard 等所有 InLong 组件，同时支持`数据接入`、`数据同步`和`数据订阅`。
轻量化架构：只包含 InLong Sort 一个组件，也可以搭配 Manager，Dashboard 一起使用。轻量化架构简单、灵活，支持`数据同步`。
InLong的特性支持
简单易用：基于 SaaS 模式对外服务，用户只需要按主题发布和订阅数据即可完成数据的上报，传输和分发工作
稳定可靠：系统源于实际的线上系统，服务上十万亿级的高性能及上千亿级的高可靠数据数据流量，系统稳定可靠
功能完善：支持各种类型的数据接入方式，多种不同类型的 MQ 集成，以及基于配置规则的实时数据 ETL 和数据分拣落地，并支持以可插拔方式扩展系统能力
服务集成：支持统一的系统监控、告警，以及细粒度的数据指标呈现，对于管道的运行情况，以数据主题为核心的数据运营情况，汇总在统一的数据指标平台，并支持通过业务设置的告警信息进行异常告警提醒
灵活扩展：全链条上的各个模块基于协议以可插拔方式组成服务，业务可根据自身需要进行组件替换和功能扩展
二、SeaTunnel：下一代高性能、分布式、海量数据集成框架
SeaTunnel是一个非常易于使用、超高性能的分布式数据集成平台，支持海量数据的实时同步。它每天可以稳定高效地同步数百亿数据，已被近100家企业应用于生产。
SeaTunnel专注于数据集成和数据同步，主要解决数据集成领域的常见问题：
各种数据源：有数百个版本不兼容的常用数据源。随着新技术的出现，出现了更多的数据源。用户很难找到一个工具，可以完全和快速地支持这些数据源。
复杂的同步方案：数据同步需要支持离线全同步、离线增量同步、CDC、实时同步、全库同步等多种同步场景。
高资源需求：现有的数据集成和数据同步工具往往需要庞大的计算资源或JDBC连接资源来完成海量小表的实时同步。这增加了企业的负担。
缺乏质量和监控：数据集成和同步过程经常会出现数据丢失或重复。同步过程缺乏监控，无法直观了解任务过程中数据的真实的情况。
复杂的技术堆栈：企业使用的技术组件不同，用户需要为不同的组件开发相应的同步程序来完成数据集成。
管理和维护困难：受限于不同的底层技术组件（Flink/Spark），离线同步和实时同步往往已经被分开开发和管理，这增加了管理和维护的难度。
SeaTunnel特性支持
丰富且可扩展的连接器：SeaTunnel提供了一个不依赖于特定执行引擎的连接器API。基于此API开发的连接器（Source、Transform、Sink）可以在目前支持的SeaTunnel Engine、Flink、Spark等多种不同引擎上运行。
连接器插件：插件设计允许用户轻松开发自己的连接器并将其集成到SeaTunnel项目中。目前，SeaTunnel支持100多个连接器，并且数量正在激增。以下是当前支持的连接器列表
批次流整合：基于SeaTunnel Connector API开发的连接器完美兼容离线同步、实时同步、全同步、增量同步等场景。它们大大降低了管理数据集成任务的难度。
支持分布式快照算法，保证数据一致性。
多引擎支持：默认情况下，SeaTunnel使用SeaTunnel引擎进行数据同步。SeaTunnel还支持使用Flink或Spark作为Connector的执行引擎，以适应企业现有的技术组件。SeaTunnel支持多个版本的Spark和Flink。
JDBC复用，数据库日志多表解析：SeaTunnel支持多表或全库同步，解决了跨JDBC连接的问题;支持多表或全库日志阅读和解析，解决了CDC多表同步场景需要处理日志重复阅读和解析的问题。
高吞吐量、低延迟：SeaTunnel支持并行阅读和写，提供稳定可靠的数据同步能力，具有高吞吐量、低延迟的特点。
完美的实时监控：SeaTunnel支持数据同步过程中每一步的详细监控信息，让用户轻松了解同步任务读写的数据数量、数据大小、QPS等信息。
支持两种工作开发方法：编码和画布设计。SeaTunnel网络项目https://github.com/apache/seatunnel-web提供作业、调度、运行和监控功能的可视化管理。
三：chunjun:基于Flink的批流统一的数据同步工具
纯钧（ChunJun，原名FlinkX），是一款稳定、易用、高效、批流一体的数据集成框架，目前基于实时计算引擎Flink实现多种异构数据源之间的数据同步与计算，已在上千家公司部署且稳定运行。
纯钧（ChunJun）将不同的数据库抽象成了reader/source 插件，writer/sink 插件和lookup 维表插件，其具有以下特点：
基于实时计算引擎Flink，支持JSON模版配置任务，兼容Flink SQL语法；
支持分布式运行，支持flink-standalone、yarn-session、yarn-per job等多种提交方式；
支持Docker一键部署，支持K8S 部署运行；
支持多种异构数据源，可支持MySQL、Oracle、SQLServer、Hive、Kudu等20多种数据源的同步与计算；
易拓展，高灵活性，新拓展的数据源插件可以与现有数据源插件即时互通，插件开发者不需要关心其他插件的代码逻辑；
不仅仅支持全量同步，还支持增量同步、间隔轮训；
批流一体，不仅仅支持离线同步及计算，还兼容实时场景；
支持脏数据存储，并提供指标监控等；
配合checkpoint实现断点续传；
不仅仅支持同步DML数据，还支持Schema变更同步；
不同的数据源头被抽象成不同的Reader插件，不同的数据目标被抽象成不同的Writer插件。理论上，FlinkX框架可以支持任意数据源类型的数据同步工作。作为一套生态系统，每接入一套新数据源该新加入的数据源即可实现和现有的数据源互通。
在底层实现上，FlinkX依赖Flink，数据同步任务会被翻译成StreamGraph在Flink上执行，基本原理如下图：
四、BitSail：高性能数据集成引擎
BitSail是字节跳动开源的基于分布式架构的高性能数据集成引擎, 支持多种异构数据源间的数据同步，并提供离线、实时、全量、增量场景下的全域数据集成解决方案，目前服务于字节内部几乎所有业务线，包括抖音、今日头条等，每天同步数百万亿数据
BitSail支持功能
全域数据集成解决方案, 覆盖离线、实时、增量场景
分布式以及云原生架构, 支持水平扩展
在准确性、稳定性、性能上，成熟度更好
丰富的基础功能，例如类型转换、脏数据处理、流控、数据湖集成、自动并发度推断等
完善的任务运行状态监控，例如流量、QPS、脏数据、延迟等
BitSail使用场景
异构数据源海量数据同步
流批一体数据处理能力
湖仓一体数据处理能力
高性能、高可靠的数据同步
分布式、云原生架构数据集成引擎
BitSail主要特点
简单易用，灵活配置
流批一体、湖仓一体架构，一套框架覆盖几乎所有数据同步场景
高性能、海量数据处理能力
DDL自动同步
类型系统，不同数据源类型之间的转换
独立于引擎的读写接口，开发成本低
任务进度实时展示，正在开发中
任务状态实时监控
五、AiyByte：开源的数据移动基础设施
Airbyte是一个开源的数据移动基础设施，用于构建提取和加载（EL）数据管道。它的设计具有多功能性、可扩展性和易用性。
在Airbyte中有三个主要组件需要了解：
连接器
350多种预建连接器：Airbyte的连接器目录“开箱即用”，提供超过350种预建连接器。这些连接器可用于在几分钟内开始将数据从源复制到目标。
无代码连接器生成器：您可以轻松地扩展Airbyte的功能，通过No-Code Connector Builder等工具来支持您的自定义用例。
平台：Airbyte的平台提供了配置和扩展数据移动操作所需的所有水平服务，可作为云管理或自我管理。
用户界面：Airbyte具有UI、PyAirbyte（Python库）、API和Terraform Provider，可与您首选的工具和基础设施管理方法集成。
Airbyte适用于广泛的数据集成用例，包括AI数据基础设施和EL（T）工作负载。Airbyte还可以嵌入到您自己的应用程序或平台中，为您的产品提供动力。
Airbyte协议有两个主要组成部分：源和目的地。这些组件被称为Actor。源是由一系列标准接口描述的应用程序。此应用程序从基础数据存储中提取数据。在此上下文中，数据存储是指实际存储数据的工具。一种数据存储器，包括：数据库、API、任何产生数据的东西等等。例如，Postgres Source是一个从Postgres（一个数据存储）拉取的Source。目的地是一个应用程序，它由一系列标准接口描述，用于将数据加载到数据存储区中。
协议用于描述数据的关键原语是Catalog、Configured Catalog、Stream、Configured Stream和Field：
流--流描述了资源的模式和关于用户如何与该资源交互的各种元数据。此上下文中的资源可能指数据库表、REST API中的资源或数据流。
字段-字段指的是流中的“列”。在数据库中，它是一个列;在JSON对象中，它是一个字段。
Catalog-catalog是一个流列表，用于描述数据存储中源所表示的数据。
一个Actor可以通过Actor Specification通告关于它自己的信息。规范共享的主要信息之一是配置Actor所需的信息。
六、CloudCanal ：数据同步、迁移 工具
CloudCanal 是一款 数据同步、迁移 工具，帮助企业构建高质量数据管道,具备实时高效、精确互联、稳定可拓展、一站式、混合部署、复杂数据转换等优点。
数据迁移
将指定数据源数据全量搬迁到目标数据源，支持多种数据源，具备断点续传、顺序分页扫描、并行扫描、元数据映射裁剪、自定义代码数据处理、批量写入、并行写入、数据条件过滤等特点，对源端数据源影响小且性能好，同时满足数据轻度处理需求。
可选搭配结构迁移、数据校验和订正，满足结构准备或数据质量的需求。
数据同步
通过消费源端数据源增量操作日志，准实时在对端数据源重放，以达到数据同步目的，具备断点续传、DDL 同步、元数据映射裁剪、自定义代码数据处理、操作过滤、数据条件过滤、高性能对端写入等特点。
可选搭配结构迁移、数据初始化(全量迁移)、单次或定时数据校验与订正，满足数据准备和业务长周期数据同步对于数据质量的要求。
结构迁移和同步
帮助用户快速将源端结构执行到对端的功能，具备类型转换、数据库方言转换、命名映射等特点，可独立使用，也可作为数据迁移或数据同步准备步骤。
数据校验和订正
将源端和对端数据分别取出，逐字段对比，可选择差异数据订正，功能可单独使用，也可配合数据迁移或数据同步使用，满足用户数据质量验证与修复的需求。
架构设计
Console
集中化的管控服务，以 web 服务集群存在。
承载产品化功能，包括数据源/机器/数据任务生命周期管理、容灾调度、监控告警、元数据管理等。
Sidecar
部署于具体数据迁移同步机器上。
承担包括获取需要运行的任务配置、启停数据任务进程、收集和上报任务状态、执行任务的健康检查等工作。
CloudCanal Core
部署于具体数据迁移同步机器上。
执行具体的数据迁移、同步、校验、订正任务。
内核架构
数据源插件
包含各个数据库、消息、数据仓库等数据源数据读写、元数据获取逻辑和对应驱动。
各个插件通过 Java 类加载机制隔离，任务运行时只加载对应数据源插件。
核心
包含内核代码骨架、操作过滤、元数据映射、DDL 转换、自定义数据处理等部分。
支撑
包含元数据、任务配置、位点、监控指标，以及和管控交互的逻辑
使用场景
七、Flume：分布式、可靠且可用的数据七、Flume：分布式、可靠且可用的数据
Apache Flume是一个开源的、分布式的数据采集系统，旨在可靠地、高效地从各种数据源采集、聚合和传输数据到目的地。Flume的设计目标是解决大规模数据采集的可靠性和扩展性问题。其基于可插拔的架构和配置驱动的方式，使得用户可以方便地定制和扩展数据采集的流程。
Flume的核心组件
2.1 Source（数据源）
Flume的数据源是指数据采集的起点，它负责从外部数据源读取数据并将其传递给Flume的通道。Flume提供了多种数据源类型，例如Avro Source、Thrift Source和Spooling Directory Source。Avro Source支持通过Avro协议接收数据，Thrift Source支持通过Thrift协议接收数据，而Spooling Directory Source则监控指定目录下的文件，并将文件内容作为数据源。
2.2 Channel（通道）
通道是Flume的核心组件之一，用于缓存和传递从数据源接收到的数据。Flume提供了多种通道类型，如Memory Channel、File Channel和Kafka Channel。Memory Channel将数据存储在内存中，适用于高吞吐量和低延迟的场景；File Channel将数据存储在本地文件系统中，适用于对数据持久化有要求的场景；Kafka Channel基于Apache Kafka实现，支持高可靠性和可扩展性。
2.3 Sink（数据目的地）
Sink是Flume的数据目的地，它负责将数据从通道中取出并发送到指定的目标系统。Flume提供了多种Sink类型，如HDFS Sink、Hive Sink和Elasticsearch Sink。HDFS Sink将数据写入Hadoop分布式文件系统，Hive Sink将数据写入Hive表，Elasticsearch Sink将数据写入Elasticsearch索引。
八、Canal：数据库增量日志解析、采集工具
译意为水道/管道/沟渠，主要用途是基于 MySQL 数据库增量日志解析，提供增量数据订阅和消费
早期阿里巴巴因为杭州和美国双机房部署，存在跨机房同步的业务需求，实现方式主要是基于业务 trigger 获取增量变更。从 2010 年开始，业务逐步尝试数据库日志解析获取增量变更进行同步，由此衍生出了大量的数据库增量订阅和消费业务。
基于日志增量订阅和消费的业务包括
数据库镜像
数据库实时备份
索引构建和实时维护(拆分异构索引、倒排索引等)
业务 cache 刷新
带业务逻辑的增量数据处理
当前的 canal 支持源端 MySQL 版本包括 5.1.x , 5.5.x , 5.6.x , 5.7.x , 8.0.x
工作原理
MySQL主备复制原理
MySQL master 将数据变更写入二进制日志( binary log, 其中记录叫做二进制日志事件binary log events，可以通过 show binlog events 进行查看)
MySQL slave 将 master 的 binary log events 拷贝到它的中继日志(relay log)
MySQL slave 重放 relay log 中事件，将数据变更反映它自己的数据
canal 工作原理
canal 模拟 MySQL slave 的交互协议，伪装自己为 MySQL slave ，向 MySQL master 发送dump 协议
MySQL master 收到 dump 请求，开始推送 binary log 给 slave (即 canal )
canal 解析 binary log 对象(原始为 byte 流)
九：Nifi：一个易于使用、功能强大且可靠的系统，用于处理和分发数据
简单的说，NiFi就是为了解决不同系统间数据自动流通问题而建立的。虽然dataflow这个术语在各种场景都有被使用，但我们在这里使用它来表示不同系统间的自动化的可管理的信息流。自企业拥有多个系统开始，一些系统会有数据生成，一些系统要消费数据，而不同系统之间数据的流通问题就出现了。这些问题出现的相应的解决方案已经被广泛的研究和讨论，其中企业集成eip就是一个全面且易于使用的方案。
dataflow要面临的一些挑战包括：
Systems fail：网络故障，磁盘故障，软件崩溃，人为事故。
Data access exceeds capacity to consume：有时，给定的数据源可能会超过处理链或交付链的某些部分的处理能力，而只需要一个环节出现问题，整个流程都会受到影响。
Boundary conditions are mere suggestions：总是会得到太大、太小、太快、太慢、损坏、错误或格式错误的数据。
What is noise one day becomes signal the next：现实业务或需求变更快，设计新的数据处理流程或者修改已有的流程必必须要迅速。
Systems evolve at different rates：给定的系统所使用的协议或数据格式可能随时改变，而且常常跟周围其他系统无关。dataflow的存在就是为了连接这种大规模分布的，松散的，甚至根本不是设计用来一起工作的组件系统。
Compliance and security*法律，法规和政策发生变化。企业对企业协议的变化。系统到系统和系统到用户的交互必须是安全的，可信的，负责任的。
Continuous improvement occurs in production通常不可能在测试环境中完全模拟生产环境。
Nifi架构
多年来，数据流一直是架构中不可避免的问题之一。现在有许多活跃的、快速发展的技术，使得dataflow对想要成功的特定企业更加重要，比如soa,API，iot,bigData。此外，合规性，隐私性和安全性所需的严格程度也在不断提高。尽管不停的出现这些新概念新技术，但dataflow面临的困难和挑战依旧，其中主要的区别还是复杂的范围，需要适应的需求变化的速度以及大规模边缘情况的普遍化。NiFi旨在帮助解决这些现代数据流挑战。
NiFi的基本设计概念与基于流程的编程fbp的主要思想密切相关。以下是一些主要的NiFi概念以及它们如何映射到FBP：
| NiFi术语 | FBP Term | 描述 |
| FlowFile | Information Packet | FlowFile表示在系统中移动的每个对象，对于每个FlowFile，NIFI都会记录它一个属性键值对和0个或多个字节内容(FlowFile有attribute和content)。 |
| FlowFile Processor | Black Box | 实际上是处理器起主要作用。在eip术语中，处理器就是不同系统间的数据路由，数据转换或者数据中介的组合。处理器可以访问给定FlowFile的属性及其内容。处理器可以对给定工作单元中的零或多个流文件进行操作，并提交该工作或回滚该工作。 |
| Connection | Bounded Buffer | Connections用来连接处理器。它们充当队列并允许各种进程以不同的速率进行交互。这些队列可以动态地对进行优先级排序，并且可以在负载上设置上限，从而启用背压。 |
| Flow Controller | Scheduler | 流控制器维护流程如何连接，并管理和分配所有流程使用的线程。流控制器充当代理，促进处理器之间流文件的交换。 |
| Process Group | subnet | 进程组里是一组特定的流程和连接，可以通过输入端口接收数据并通过输出端口发送数据，这样我们在进程组里简单地组合组件，就可以得到一个全新功能的组件(Process Group)。 |
十、DataX : 离线数据同步工具/平台
DataX 是一个异构数据源离线同步工具，致力于实现包括关系型数据库(MySQL、Oracle等)、HDFS、Hive、ODPS、HBase、FTP等各种异构数据源之间稳定高效的数据同步功能。
设计理念
为了解决异构数据源同步问题，DataX将复杂的网状的同步链路变成了星型数据链路，DataX作为中间传输载体负责连接各种数据源。当需要接入一个新的数据源的时候，只需要将此数据源对接到DataX，便能跟已有的数据源做到无缝数据同步。
当前使用现状
DataX在阿里巴巴集团内被广泛使用，承担了所有大数据的离线同步业务，并已持续稳定运行了6年之久。目前每天完成同步8w多道作业，每日传输数据量超过300TB。
DataX本身作为离线数据同步框架，采用Framework + plugin架构构建。将数据源读取和写入抽象成为Reader/Writer插件，纳入到整个同步框架中。
Reader：Reader�为数据采集模块，负责采集数据源的数据，将数据发送给Framework。
Writer： Writer为数据写入模块，负责不断向Framework取数据，并将数据写入到目的端。
Framework：Framework用于连接reader和writer，作为两者的数据传输通道，并处理缓冲，流控，并发，数据转换等核心技术问题。
DataX3.0核心架构
DataX 3.0 开源版本支持单机多线程模式完成同步作业运行，本小节按一个DataX作业生命周期的时序图，从整体架构设计非常简要说明DataX各个模块相互关系。
核心模块介绍：
DataX完成单个数据同步的作业，我们称之为Job，DataX接受到一个Job之后，将启动一个进程来完成整个作业同步过程。DataX Job模块是单个作业的中枢管理节点，承担了数据清理、子任务切分(将单一作业计算转化为多个子Task)、TaskGroup管理等功能。
DataXJob启动后，会根据不同的源端切分策略，将Job切分成多个小的Task(子任务)，以便于并发执行。Task便是DataX作业的最小单元，每一个Task都会负责一部分数据的同步工作。
切分多个Task之后，DataX Job会调用Scheduler模块，根据配置的并发数据量，将拆分成的Task重新组合，组装成TaskGroup(任务组)。每一个TaskGroup负责以一定的并发运行完毕分配好的所有Task，默认单个任务组的并发数量为5。
每一个Task都由TaskGroup负责启动，Task启动后，会固定启动Reader—>Channel—>Writer的线程来完成任务同步工作。
DataX作业运行起来之后， Job监控并等待多个TaskGroup模块任务完成，等待所有TaskGroup任务完成后Job成功退出。否则，异常退出，进程退出值非0
DataX调度流程：
举例来说，用户提交了一个DataX作业，并且配置了20个并发，目的是将一个100张分表的mysql数据同步到odps里面。 DataX的调度决策思路是：
DataXJob根据分库分表切分成了100个Task。
根据20个并发，DataX计算共需要分配4个TaskGroup。
4个TaskGroup平分切分好的100个Task，每一个TaskGroup负责以5个并发共计运行25个Task。
DataX 3.0六大核心优势
可靠的数据质量监控
完美解决数据传输个别类型失真问题DataX旧版对于部分数据类型(比如时间戳)传输一直存在毫秒阶段等数据失真情况，新版本DataX3.0已经做到支持所有的强数据类型，每一种插件都有自己的数据类型转换策略，让数据可以完整无损的传输到目的端。
提供作业全链路的流量、数据量�运行时监控DataX3.0运行过程中可以将作业本身状态、数据流量、数据速度、执行进度等信息进行全面的展示，让用户可以实时了解作业状态。并可在作业执行过程中智能判断源端和目的端的速度对比情况，给予用户更多性能排查信息。
提供脏数据探测在大量数据的传输过程中，必定会由于各种原因导致很多数据传输报错(比如类型转换错误)，这种数据DataX认为就是脏数据。DataX目前可以实现脏数据精确过滤、识别、采集、展示，为用户提供多种的脏数据处理模式，让用户准确把控数据质量大关！
丰富的数据转换功能
DataX作为一个服务于大数据的ETL工具，除了提供数据快照搬迁功能之外，还提供了丰富数据转换的功能，让数据在传输过程中可以轻松完成数据脱敏，补全，过滤等数据转换功能，另外还提供了自动groovy函数，让用户自定义转换函数。详情请看DataX3的transformer详细介绍。
精准的速度控制
还在为同步过程对在线存储压力影响而担心吗？新版本DataX3.0提供了包括通道(并发)、记录流、字节流三种流控模式，可以随意控制你的作业速度，让你的作业在库可以承受的范围内达到最佳的同步速度。
"speed": {
"channel": 5,
"byte": 1048576,
"record": 10000
}强劲的同步性能
DataX3.0每一种读插件都有一种或多种切分策略，都能将作业合理切分成多个Task并行执行，单机多线程执行模型可以让DataX速度随并发成线性增长。在源端和目的端性能都足够的情况下，单个作业一定可以打满网卡。另外，DataX团队对所有的已经接入的插件都做了极致的性能优化，并且做了完整的性能测试。性能测试相关详情可以参照每单个数据源的详细介绍：DataX数据源指南
健壮的容错机制
DataX作业是极易受外部因素的干扰，网络闪断、数据源不稳定等因素很容易让同步到一半的作业报错停止。因此稳定性是DataX的基本要求，在DataX 3.0的设计中，重点完善了框架和插件的稳定性。目前DataX3.0可以做到线程级别、进程级别(暂时未开放)、作业级别多层次局部/全局的重试，保证用户的作业稳定运行。
线程内部重试DataX的核心插件都经过团队的全盘review，不同的网络交互方式都有不同的重试策略。
线程级别重试目前DataX已经可以实现TaskFailover，针对于中间失败的Task，DataX框架可以做到整个Task级别的重新调度。
极简的使用体验
易用下载即可用，支持linux和windows，只需要短短几步骤就可以完成数据的传输。请点击：Quick Start
详细DataX在运行日志中打印了大量信息，其中包括传输速度，Reader、Writer性能，进程CPU，JVM和GC情况等等。
传输过程中打印传输速度、进度等
传输过程中会打印进程相关的CPU、JVM等
在任务结束之后，打印总体运行情况
wx添加kubedata，加入云原生大数据交流群，或者关注公众号：云原生大数据技术荟，领取干货资料
十款开源数据集成工具对比
| 社区活跃度 | 开源时间 | 主导者 | 可视化能力 | 底层执行引擎 | 开源协议 | Apache顶级项目 | 推荐系数 | |
| InLong | Github：InLong Star：1.3kFork：482活跃度：比较活跃 | 2020.5.30 | 腾讯，腾讯云的数据集成平台基于InLong构建的 | 支持 | FlinkPulsar/Kafka | Apache-2.0 license | 是 | |
| SeaTunnel（原名：Waterdrop） | Github：SeaTunnel Star：7.2kFork：1.5k活跃度：非常活跃 | 2018.1.6 | 乐视创建，目前主导者是白鲸开源科技 | 支持 | 支持 SeaTunnel Zeta、Flink、Spark 3 个引擎选其一作为运行时 | Apache-2.0 license | 是 | |
| chunjun（FlinkX） | Github：chunjun Star：3.9kFork：1.7k活跃度：一般活跃 | 2018.4 | 袋鼠云 | 不支持 | Flink | Apache-2.0 license | 否 | |
| BitSail | github地址：BitSailStar：1.6kFork：323活跃度：非常不活跃 | 2022.9.29 | 字节跳动 | 不支持 | Flink依赖Hadoop环境 | Apache-2.0 license | 否 | |
| AirByte | github地址：AirByteStar：14kFork：3.6活跃度：非常活跃 | 2020.9.24 | AirByte (专门做数据集成的公司，也有对应的企业版） | 支持 | 自研引擎 | MIT开源协议 | 否 | |
| Sqoop | github地址：Sqoop活跃度：缅怀一下吧 | 始于2009.5终于2021.5.6 | 不支持 | MapReduce | Apache-2.0 license | 是 | ||
| Flume | github地址：FlumeStar：1.6kFork：323活跃度：一般活跃 | 2010年 | Flume 最初是 Cloudera 开发的日志收集系统，受到了业界的认可与广泛应用，后来逐步演化成支持任何流式数据收集的通用系统。 | 不支持 | Source、Channel、Sink | Apache-2.0 license | 是 | |
| canal | github地址：CanalStar：1.6kFork：323活跃度：一般活跃 | 2012 | 阿里巴巴 | 不支持 | client-server 模式，交互协议使用 protobuf 3.0 | Apache-2.0 license | 否 | |
| Nifi | github地址：NifiStar：4.4kFork：2.6k活跃度：非常活跃 | 2014 | 2006年NiFi由美国国家安全局（NSA）的Joe Witt创建 | 支持 | 基于DataFlow的编程模型构建的模块化的架构 | Apache-2.0 license | 是 | |
| DataX | github地址：DataXStar：15.2kFork：5.2k活跃度：非常活跃 | 2015 | 阿里巴巴 | 开源版不支持，有其他人开源的webui，可以参考datax-webui | 基于插件式的单机数据同步 | Apache-2.0 license | 否 |
发布于 2024-05-07 12:47・IP 属地北京
