ETL介绍与ETL工具
2019-01-22 20:40:20 
阿炯
ETL，是英文 Extract-Transform-Load 的缩写，用来描述将数据从来源端经过萃取(extract)、转置(transform)、加载(load)至目的端的过程。ETL一词较常用在数据仓库，但其对象并不限于数据仓库。
ETL负责将分布的、异构数据源中的数据如关系数据、平面数据文件等抽取到临时中间层后进行清洗、转换、集成，最后加载到数据仓库或数据集市中，成为联机分析处理、数据挖掘的基础。是数据仓库中的非常重要的一环。它是承前启后的必要的一步。相对于关系数据库，数据仓库技术没有严格的数学理论基础，它更面向实际工程应用。所以从工程应用的角度来考虑，按着物理数据模型的要求加载数据并对数据进行一些系列处理，处理过程与经验直接相关，同时这部分的工作直接关系数据仓库中数据的质量，从而影响到联机分析处理和数据挖掘的结果的质量。
数据仓库是一个独立的数据环境，需要通过抽取过程将数据从联机事务处理环境、外部数据源和脱机的数据存储介质导入到数据仓库中；在技术上，ETL主要涉及到关联、转换、增量、调度和监控等几个方面；数据仓库系统中数据不要求与联机事务处理系统中数据实时同步，所以ETL可以定时进行。但多个ETL的操作时间、顺序和成败对数据仓库中信息的有效性至关重要。
ETL中的关键技术
ETL过程中的主要环节就是数据抽取、数据转换和加工、数据装载。为了实现这些功能，各个ETL工具一般会进行一些功能上的扩充，例如工作流、调度引擎、规则引擎、脚本支持、统计信息等。
数据抽取
数据抽取是从数据源中抽取数据的过程。实际应用中，数据源较多采用的是关系数据库。从数据库中抽取数据一般有以下几种方式。
(1)全量抽取
全量抽取类似于数据迁移或数据复制，它将数据源中的表或视图的数据原封不动的从数据库中抽取出来，并转换成自己的ETL工具可以识别的格式。全量抽取比较简单。
(2)增量抽取
增量抽取只抽取自上次抽取以来数据库中要抽取的表中新增或修改的数据。在ETL使用过程中。增量抽取较全量抽取应用更广。如何捕获变化的数据是增量抽取的关键。对捕获方法一般有两点要求：准确性，能够将业务系统中的变化数据按一定的频率准确地捕获到；性能，不能对业务系统造成太大的压力，影响现有业务。目前增量数据抽取中常用的捕获变化数据的方法有：
a.触发器：在要抽取的表上建立需要的触发器，一般要建立插入、修改、删除三个触发器，每当源表中的数据发生变化，就被相应的触发器将变化的数据写入一个临时表，抽取线程从临时表中抽取数据，临时表中抽取过的数据被标记或删除。触发器方式的优点是数据抽取的性能较高，缺点是要求业务表建立触发器，对业务系统有一定的影响。
b.时间戳：它是一种基于快照比较的变化数据捕获方式，在源表上增加一个时间戳字段，系统中更新修改表数据的时候，同时修改时间戳字段的值。当进行数据抽取时，通过比较系统时间与时间戳字段的值来决定抽取哪些数据。有的数据库的时间戳支持自动更新，即表的其它字段的数据发生改变时，自动更新时间戳字段的值。有的数据库不支持时间戳的自动更新，这就要求业务系统在更新业务数据时，手工更新时间戳字段。同触发器方式一样，时间戳方式的性能也比较好，数据抽取相对清楚简单，但对业务系统也有很大的倾入性(加入额外的时间戳字段)，特别是对不支持时间戳的自动更新的数据库，还要求业务系统进行额外的更新时间戳操作。另外，无法捕获对时间戳以前数据的delete和update操作,在数据准确性上受到了一定的限制。
c.全表比对：典型的全表比对的方式是采用MD5校验码。ETL工具事先为要抽取的表建立一个结构类似的MD5临时表，该临时表记录源表主键以及根据所有字段的数据计算出来的MD5校验码。每次进行数据抽取时，对源表和MD5临时表进行MD5校验码的比对，从而决定源表中的数据是新增、修改还是删除，同时更新MD5校验码。MD5方式的优点是对源系统的倾入性较小(仅需要建立一个MD5临时表)，但缺点也是显而易见的，与触发器和时间戳方式中的主动通知不同，MD5方式是被动的进行全表数据的比对，性能较差。当表中没有主键或唯一列且含有重复记录时，MD5方式的准确性较差。
d.日志对比：通过分析数据库自身的日志来判断变化的数据。Oracle的改变数据捕获(CDC，Changed Data Capture)技术是这方面的代表。CDC 特性是在Oracle9i数据库中引入的。CDC能够帮助你识别从上次抽取之后发生变化的数据。利用CDC，在对源表进行insert、update或 delete等操作的同时就可以提取数据，并且变化的数据被保存在数据库的变化表中。这样就可以捕获发生变化的数据，然后利用数据库视图以一种可控的方式提供给目标系统。CDC体系结构基于发布者/订阅者模型。发布者捕捉变化数据并提供给订阅者。订阅者使用从发布者那里获得的变化数据。通常，CDC系统拥有一个发布者和多个订阅者。发布者首先需要识别捕获变化数据所需的源表。然后，它捕捉变化的数据并将其保存在特别创建的变化表中。它还使订阅者能够控制对变化数据的访问。订阅者需要清楚自己感兴趣的是哪些变化数据。一个订阅者可能不会对发布者发布的所有数据都感兴趣。订阅者需要创建一个订阅者视图来访问经发布者授权可以访问的变化数据。CDC分为同步模式和异步模式，同步模式实时的捕获变化数据并存储到变化表中，发布者与订阅都位于同一数据库中。异步模式则是基于Oracle的流复制技术。
ETL处理的数据源除了关系数据库外，还可能是文件，例如txt文件、excel文件、xml文件等。对文件数据的抽取一般是进行全量抽取，一次抽取前可保存文件的时间戳或计算文件的MD5校验码，下次抽取时进行比对，如果相同则可忽略本次抽取。
数据转换和加工
从数据源中抽取的数据不一定完全满足目的库的要求，例如数据格式的不一致、数据输入错误、数据不完整等等，因此有必要对抽取出的数据进行数据转换和加工。
数据的转换和加工可以在ETL引擎中进行，也可以在数据抽取过程中利用关系数据库的特性同时进行。
(1)ETL引擎中的数据转换和加工
ETL引擎中一般以组件化的方式实现数据转换。常用的数据转换组件有字段映射、数据过滤、数据清洗、数据替换、数据计算、数据验证、数据加解密、数据合并、数据拆分等。这些组件如同一条流水线上的一道道工序，它们是可插拔的，且可以任意组装，各组件之间通过数据总线共享数据。
有些ETL工具还提供了脚本支持，使得用户可以以一种编程的方式定制数据的转换和加工行为。
(2)在数据库中进行数据加工
关系数据库本身已经提供了强大的SQL、函数来支持数据的加工，如在SQL查询语句中添加where条件进行过滤，查询中重命名字段名与目的表进行映射，substr函数，case条件判断等等。下面是一个SQL查询的例子。
select ID as USERID, substr(TITLE, 1, 20) as TITLE, case when REMARK is null then ' ' else REMARK end as CONTENT from TB_REMARK where ID > 100;
相比在ETL引擎中进行数据转换和加工，直接在SQL语句中进行转换和加工更加简单清晰，性能更高。对于SQL语句无法处理的可以交由ETL引擎处理。
数据装载
将转换和加工后的数据装载到目的库中通常是ETL过程的最后步骤。装载数据的最佳方法取决于所执行操作的类型以及需要装入多少数据。当目的库是关系数据库时，一般来说有两种装载方式：
(1)直接SQL语句进行insert、update、delete操作。
(2)采用批量装载方法，如bcp、bulk、关系数据库特有的批量装载工具或api。
大多数情况下会使用第一种方法，因为它们进行了日志记录并且是可恢复的。但是，批量装载操作易于使用，并且在装入大量数据时效率较高。使用哪种数据装载方法取决于业务系统的需要。
ETL工具的典型代表有:Informatica、Datastage、ODI ,OWB、微软DTS、Beeload、Kettle、久其ETL……
ETL工具
旗鼓相当：Datastage与Powercenter：
就Datastage和Powercenter而言，这两者目前占据了国内市场绝大部分的份额，在成本上看水平相当，虽然市面上还有诸如Business Objects公司的Data Integrator、Cognos公司的DecisionStream，但尚属星星之火，未成燎原之势。
谈Datastage和Powercenter，如果有人说这个就是比那个好，那听者就要小心一点了。在这种情况下有两种可能：他或者是其中一个厂商的员工，或者就是在某个产品上有很多经验而在另一产品上经验缺乏的开发者。为什么得出这一结论？一个很简单的事实是，从网络上大家对它们的讨论和争执来看，基本上是各有千秋，都有着相当数量的成功案例和实施高手。确实，工具是死的，人才是活的。在两大ETL工具技术的比对上，可以从对ETL流程的支持、对元数据的支持、对数据质量的支持、维护的方便性、定制开发功能的支持等方面考虑。
一个项目中，从数据源到最终目标表，多则上百个ETL过程，少则也有十几个。这些过程之间的依赖关系、出错控制以及恢复的流程处理，都是工具需要重点考虑。在这一方面，Datastage的早期版本对流程就缺乏考虑，而在6版本则加入Job Sequence的特性，可以将Job、shell脚本用流程图的方式表示出来，依赖关系、串行或是并行都可以一目了然，就直观多了。Powercenter有Workflow的概念，也同样可以将Session串联起来，这和Datastage Sequence大同小异。
ETL的元数据包括数据源、目标数据的结构、转换规则以及过程的依赖关系等。在这方面，Datastage和Powercenter从功能上看可谓不分伯仲，只是后者的元数据更加开放，存放在关系数据库中，可以很容易被访问(Informatic把Metadata全部放在数据库中而Datastage是自己管理Metadata，不依赖任何数据库.)。此外，这两个厂家又同时提供专门的元数据管理工具，Ascential有Metastage，而Informatica拥有Superglue。你看，就不给你全部功能，变着法子从你口袋里面多掏点钱。
数据质量方面，两种产品都采用同样的策略——独立出ETL产品之外，另外有专门的数据质量管理产品。例如和Datastage配套用的有ProfileStage和QualityStage，而Informatica最近也索性收购了原先OEM的数据质量管理产品FirstLogic。而在它们的ETL产品中，只是在Job或是Session前后留下接口，所谓前过程、后过程，虽然不是专为数据质量预留的接口，不过至少可以利用它外挂一些数据质量控制的模块。
在具体实现上看，Datastage通过Job实现一个ETL过程，运行时可以通过指定不同参数运行多个实例。Powercenter通过Mapping表示一个ETL过程，运行时为Session，绑定了具体的物理数据文件或表。在修改维护上，这两个工具都是提供图形化界面。这样的好处是直观、傻瓜式的；不好的地方就是改动还是比较费事(特别是批量化的修改)。
定制开发方面，两者都提供抽取、转换插件的定制，但笔者认为，Datastage的定制开发性要比Powercenter要强那么一点点。因为Datastage至少还内嵌一种类BASIC语言，可以写一段批处理程序来增加灵活性，而Powercenter似乎还缺乏这类机制。另外从参数控制上，虽然两者的参数传递都是比较混乱的，但Datastage至少可以对每个job设定参数，并且可以job内部引用这个参数名；而Powercenter显得就有些偷懒，参数放在一个参数文件中，理论上的确可以灵活控制参数，但这个灵活性需要你自己更新文件中的参数值(例如日期更新)。另外，Powercenter还不能在mapping或session中引用参数名，这一点就让人恼火。
总起来看，Datastage和Powercenter可谓旗鼓相当，在国内也都有足够的支持能力，Datastage在2005年被IBM收购之后，可以说后劲十足。而Informatica则朝着BI全解决方案提供商方向发展，Powercenter显然还将是它的核心产品。
ODI的知识模块主要分为几个大类(RKM,CKM,LKM,IKM,SKM)，其中最重要的是LKM(load KM)和IKM(Integration KM)RKM。
RKM：完成从源系统和目标系统的数据结构的反向工程来形成数据模型的功能。
CKM：CKM完成数据质量检查。
LKM：LKM完成从源数据库数据加载到临时表。
IKM：IKM完成从临时表的数据加载到目标表。
SKM：SKM完成ODI和WEB服务接口的功能。
ODI的性能不是很好，Powercenter > Datastage > ODI
独树一帜：Teradata的ETL Automation
继续要说的第三种产品是Teradata的ETL Automation。之所以拿它单独来说是因为它和前面两种产品的体系架构都不太一样。与其说它是ETL工具，不如说是提供了一套ETL框架。它没有将注意力放在如何处理“转换”这个环节上，而是利用Teradata数据库本身的并行处理能力，用SQL语句来做数据转换的工作，其重点是提供对ETL流程的支持，包括前后依赖、执行和监控等。
这样的设计和Datastage、Powercenter风格迥异，后两者给人的印象是具有灵活的图形化界面，开发者可以傻瓜式处理ETL工作，它们一般都拥有非常多的“转换”组件，例如聚集汇总、缓慢变化维的转换。而对于Teradata的ETL Automation，有人说它其实应该叫做ELT，即装载是在转换之前的。的确，如果依赖数据库的能力去处理转换，恐怕只能是ELT，因为转换只能在数据库内部进行。从这个角度看，Automation对数据库的依赖不小，似乎是一种不灵活的设计。也正是这个原因，考虑它的成本就不单单是ETL产品的成本了。
其实，在购买现成的工具之外，还有自己从头开发ETL程序的。
ETL工作看起来并不复杂，特别是在数据量小、没有什么转换逻辑的时候，自己开发似乎非常节省成本。的确，主流的ETL工具价格不菲，动辄几十万；而从头开发无非就是费点人力而已，可以控制。至于性能，人大多是相信自己的，认为自己开发出来的东西知根知底，至少这些程序可以完全由自己控制。就目前自主开发的ETL程序而言，有人用C语言编写，有人用存储过程，还有人用各种语言混杂开发，程序之间各自独立。这很危险，虽然能够让开发者过足编码的瘾，却根本不存在架构。
有位银行的朋友，他们几年前上的数据仓库系统，就是集成商自己用c语言专门为他们的项目开发的。单从性能上看似乎还不赖，然而一两年下来，项目组成员风雨飘零，早已物是人非，只有那套程序还在那里；而且，按照国内目前的软件工程惯例，程序注释和文档是不全或者是不一致的，这样的程序已经对日常业务造成很大阻碍。最近，他们已经开始考虑使用ETL工具重新改造了。
总体比较列表：
ETL工具选型参照表
ETL工具的选择
在数据集成中该如何选择ETL工具呢？一般来说需要考虑以下几个方面：
(1)对平台的支持程度。
(2)对数据源的支持程度。
(3)抽取和装载的性能是不是较高，且对业务系统的性能影响大不大，倾入性高不高。
(4)数据转换和加工的功能强不强。
(5)是否具有管理和调度功能。
(6)是否具有良好的集成性和开放性
上文转自：ETL介绍与ETL工具比较
ETL(是Extract-Transform-Load的缩写，即数据抽取、转换、装载的过程)，对于企业应用来说，我们经常会遇到各种数据的处理、转换、迁移的场景。下文汇总了一些目前市面上比较常用的ETL数据迁移工具，希望对你会有所帮助。
1.Kettle
Kettle是一款国外开源的ETL工具，纯Java编写，绿色无需安装，数据抽取高效稳定 (数据迁移工具)。Kettle 中文名称叫水壶，该项目的主程序员 MATT 希望把各种数据放到一个壶里，然后以一种指定的格式流出。其中有两种脚本文件，transformation 和 job，transformation 完成针对数据的基础转换，job 则完成整个工作流的控制。
Kettle 这个 ETL 工具集，它允许你管理来自不同数据库的数据，通过提供一个图形化的用户环境来描述你想做什么，而不是你想怎么做。Kettle 家族目前包括 4 个产品：Spoon、Pan、CHEF、Kitchen。
SPOON：允许你通过图形界面来设计 ETL 转换过程（Transformation）。
PAN：允许你批量运行由 Spoon 设计的 ETL 转换 (例如使用一个时间调度器)。Pan 是一个后台执行的程序，没有图形界面。
CHEF：允许你创建任务（Job）。任务通过允许每个转换，任务，脚本等等，更有利于自动化更新数据仓库的复杂工作。任务通过允许每个转换，任务，脚本等等。任务将会被检查，看看是否正确地运行了。
KITCHEN：允许你批量使用由 Chef 设计的任务 (例如使用一个时间调度器)。KITCHEN 也是一个后台运行的程序。
2.Datax
DataX是阿里云 DataWorks数据集成的开源版本，在阿里巴巴集团内被广泛使用的离线数据同步工具/平台。
DataX 是一个异构数据源离线同步工具，致力于实现包括关系型数据库(MySQL、Oracle等)、HDFS、Hive、ODPS、HBase、FTP等各种异构数据源之间稳定高效的数据同步功能。
设计理念：为了解决异构数据源同步问题，DataX将复杂的网状的同步链路变成了星型数据链路，DataX作为中间传输载体负责连接各种数据源。当需要接入一个新的数据源的时候，只需要将此数据源对接到DataX，便能跟已有的数据源做到无缝数据同步。
当前使用现状：DataX在阿里巴巴集团内被广泛使用，承担了所有大数据的离线同步业务，并已持续稳定运行了6年之久。目前每天完成同步8w多道作业，每日传输数据量超过300TB。DataX本身作为离线数据同步框架，采用Framework + plugin架构构建。将数据源读取和写入抽象成为Reader/Writer插件，纳入到整个同步框架中。
DataX 3.0 开源版本支持单机多线程模式完成同步作业运行，本小节按一个DataX作业生命周期的时序图，从整体架构设计非常简要说明DataX各个模块相互关系。六大核心优势：
可靠的数据质量监控
丰富的数据转换功能
精准的速度控制
强劲的同步性能
健壮的容错机制
极简的使用体验
3.DataPipeline
DataPipeline采用基于日志的增量数据获取技术（ Log-based Change Data Capture ），支持异构数据之间丰富、自动化、准确的语义映射构建，同时满足实时与批量的数据处理。可实现 Oracle、IBM DB2、MySQL、MS SQL Server、PostgreSQL、GoldenDB、TDSQL、OceanBase 等数据库准确的增量数据获取。平台具备“数据全、传输快、强协同、更敏捷、极稳定、易维护”六大特性。在支持传统关系型数据库的基础上，对大数据平台、国产数据库、云原生数据库、API 及对象存储也提供广泛的支持，并在不断扩展。
DataPipeline 数据融合产品致力于为用户提供企业级数据融合解决方案，为用户提供统一平台同时管理异构数据节点实时同步与批量数据处理任务，在未来还将提供对实时流计算的支持。采用分布式集群化部署方式，可水平垂直线性扩展的，保证数据流转稳定高效，让客户专注数据价值释放。
产品特点：
全面的数据节点支持：支持关系型数据库、NoSQL数据库、国产数据库、数据仓库、大数据平台、云存储、API等多种数据节点类型，可自定义数据节点。
高性能实时处理：针对不同数据节点类型提供TB级吞吐量、秒级低延迟的增量数据处理能力，加速企业各类场景的数据流转。
分层管理降本增效：采用“数据节点注册、数据链路配置、数据任务构建、系统资源分配”的分层管理模式，企业级平台的建设周期从三到六个月减少为一周。
无代码敏捷管理：提供限制配置与策略配置两大类十余种高级配置，包括灵活的数据对象映射关系，数据融合任务的研发交付时间从2周减少为5分钟。
极稳定高可靠：采用分布式架构，所有组件均支持高可用，提供丰富容错策略，应对上下游的结构变化、数据错误、网络故障等突发情况，可以保证系统业务连续性要求。
全链路数据可观测：配备容器、应用、线程、业务四级监控体系，全景驾驶舱守护任务稳定运行。自动化运维体系，灵活扩缩容，合理管理和分配系统资源。
4.Talend
Talend (踏蓝) 是第一家针对的数据集成工具市场的 ETL (数据的提取 Extract、传输 Transform、载入 Load) 开源软件供应商。以它的技术和商业双重模式为 ETL 服务提供了一个全新的远景。它打破了传统的独有封闭服务，提供了一个针对所有规模的公司的公开的，创新的，强大的灵活的软件解决方案。
5.Datastage
DataStage，即IBM WebSphere DataStage，是一套专门对多种操作数据源的数据抽取、转换和维护过程进行简化和自动化，并将其输入数据集市或数据仓库目标数据库的集成工具，可以从多个不同的业务系统中，从多个平台的数据源中抽取数据，完成转换和清洗，装载到各种系统里面。
其中每步都可以在图形化工具里完成，同样可以灵活地被外部系统调度，提供专门的设计工具来设计转换规则和清洗规则等，实现了增量抽取、任务调度等多种复杂而实用的功能。其中简单的数据转换可以通过在界面上拖拉操作和调用一些 DataStage 预定义转换函数来实现，复杂转换可以通过编写脚本或结合其他语言的扩展来实现，并且 DataStage 提供调试环境，可以极大提高开发和调试抽取、转换程序的效率。
Datastage 操作界面
对元数据的支持：Datastage 是自己管理 Metadata，不依赖任何数据库。
参数控制：Datastage 可以对每个 job 设定参数，并且可以 job 内部引用这个参数名。
数据质量：Datastage 有配套用的 ProfileStage 和 QualityStage 保证数据质量。
定制开发：提供抽取、转换插件的定制，Datastage 内嵌一种类 BASIC 语言，可以写一段批处理程序来增加灵活性。
修改维护：提供图形化界面。这样的好处是直观、傻瓜式的；不好的地方就是改动还是比较费事（特别是批量化的修改）。
Datastage 包含四大部件：
Administrator：新建或者删除项目，设置项目的公共属性，比如权限。
Designer：连接到指定的项目上进行 Job 的设计；
Director：负责 Job 的运行，监控等。例如设置设计好的 Job 的调度时间。
Manager：进行 Job 的备份等 Job 的管理工作。
6.Sqoop
Sqoop 是 Cloudera 公司创造的一个数据同步工具，现在已经完全开源了。
目前已经是 Hadoop 生态环境中数据迁移的首选 Sqoop 是一个用来将 Hadoop 和关系型数据库中的数据相互转移的工具，可以将一个关系型数据库（例如 ：MySQL ,Oracle ,Postgres 等）中的数据导入到 Hadoop 的 HDFS 中，也可以将 HDFS 的数据导入到关系型数据库中。
其将我们传统的关系型数据库 | 文件型数据库 | 企业数据仓库 同步到我们的 hadoop 生态集群中。同时也可以将 hadoop 生态集群中的数据导回到传统的关系型数据库 | 文件型数据库 | 企业数据仓库中。
那么 Sqoop 如何抽取数据呢?
首先 Sqoop 去 rdbms 抽取元数据。
当拿到元数据之后将任务切成多个任务分给多个 map。
然后再由每个 map 将自己的任务完成之后输出到文件。
7.FineDataLink
FineDataLink是国内做的比较好的ETL工具，FineDataLink是一站式的数据处理平台，具备高效的数据同步功能，可以实现实时数据传输、数据调度、数据治理等各类复杂组合场景的能力，提供数据汇聚、研发、治理等功能。
FDL拥有低代码优势，通过简单的拖拽交互就能实现ETL全流程。
FineDataLink——中国领先的低代码/高时效数据集成产品，能过为企业提供一站式的数据服务，通过快速连接、高时效融合多种数据，提供低代码Data API敏捷发布平台，帮助企业解决数据孤岛难题，有效提升企业数据价值。
8.canal
canal [kə'næl]，译意为水道/管道/沟渠，主要用途是基于 MySQL 数据库增量日志解析，提供增量数据订阅和消费。
早期阿里巴巴因为杭州和美国双机房部署，存在跨机房同步的业务需求，实现方式主要是基于业务 trigger 获取增量变更。从 2010 年开始，业务逐步尝试数据库日志解析获取增量变更进行同步，由此衍生出了大量的数据库增量订阅和消费业务。
基于日志增量订阅和消费的业务包括：
数据库镜像
数据库实时备份
索引构建和实时维护(拆分异构索引、倒排索引等)
业务 cache 刷新
带业务逻辑的增量数据处理
当前的 canal 支持源端 MySQL 版本包括 5.1~5.7.x , 8.0.x。
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 流)
9、TDSQL
腾讯在2007年搭建了自己的分布式数据库TDSQL，该数据库早期用于支持Q币交易系统。如果腾讯不想限制Q-Coin的交易频率，就必须自己开发TDSQL。后来扩展到微信。支付、腾讯视频、腾讯音乐、腾讯会议、王者荣耀等国家级应用。直到2014年，腾讯的大部分计费业务都是由TDSQL支持的。
互联网带来的爆炸性需求，加速了各类软件技术的国产化。x86和ARM架构服务器迅速取代IBM小型机，EMC存储被分布式存储取代，家庭办公软件和ERP系统也实现了从无到有的突破。云技术的普及开始大幅降低企业的IT成本，进一步推动数据库、专有云等底层软件的研发。互联网的商业化已经成为我国基础软件产业发展的一条隐线。不断增长的需求推动我国基础软件走上了一条新的技术道路，并通过不断的实际应用锻造出了一系列日益流行的技术。有竞争力的产品。这看起来像是另一个“电动汽车时刻”。虽然今天的计算产业生态系统还不一定完整，但至少已经初具规模。在这场高科技生态竞争中，中国基础软件开始将资格摆上牌桌。
在中国各行业产品本土化过程中，一大难点就是缺乏对市场持续、耐心的验证。但对于中国的这群互联网企业来说，在很多场景下，无论是社交、电商还是游戏，都有大量的应用场景和行业需求，解决了“市场在哪里”的问题。比如上面提到的数据库TDSQL，在孵化过程中，Q币的应用是一个非常有趣的尝试，因为腾讯当时对数据库开发团队的内部要求是：即使是虚拟货币，也必须有银行级别。会计系统不能有哪怕一分钱的错误。
在所有行业中，金融行业对数据一致性和可用性的要求最高。如果一家全国性银行半个小时出现故障，该银行的技术总监就必须到银保监会去解释到底出了什么问题。Q币的应用在一定程度上帮助腾讯率先适应了这种相对严峻的需求状况，进而蔓延至“微信支付”等腾讯内部支付系统。也帮助TDSQL数据库赢得了2014年微众银行的胜利案例，打下了很好的基础。国内传统银行核心系统首次迁移至国内银行，并接入TDSQL。当时张家港农商银行就迁移到了TDSQL。要最终实现，其背后的三个要素缺一不可：
首先，中国的数据库能力已经达到了。
截至2023年3月，TDSQL数据库在权威评测机构交易处理性能委员会（TPC）排行榜上排名第一，每分钟处理能力达8.14亿订单。数据库与人工智能不同。大型AI模型的性能测试没有公式，维度太多，多个世界第一层出不穷。但数据库的衡量维度基本上只有两个：一是是否足够快，二是单位成本是否足够低。标准明确，第一就是第一，他的出色表现是毋庸置疑的。
二是生态成熟。
TDSQL数据库背后有一套全栈的内部解决方案，从硬件级芯片到网络DPU和内部服务器；到奥驰分布式云的软件级操作系统和中间件，已经有支持家用的解决方案。 。依托腾讯自身的云计算业务，全计算产业链生态系统已经形成。
第三，大环境下，市场更愿意选择国内厂商。
棱镜门之后，出于数据安全等考虑，银行等重点行业越来越倾向于把机会让给国内厂商。结果真的很好。某大型国有银行更换TDSQL分布式核心数据库后，部署成本降低1亿，且性能和稳定性不受影响。从客户信息、信用卡核心系统有序转向个人债务、投资理财，推动公司业务、信贷产品等分布式核心产品应用。
目前，TDSQL的应用在金融领域得到广泛应用，并正在进入行业复制阶段。实现如此规模的替代不仅是政治倾向的结果，也是市场竞争力的证明。中国的数据库及其背后的全栈云计算解决方案已经具备显着的市场竞争力。在需要较多自主创新的大型政企行业，过去主要基于国外VMware搭建私有云。但传统IT架构计算能力、存储资源利用率低，对业务资源需求的响应周期长，无法满足企业IT基础设施云化、云原生转型的需求。
正如我们在上一篇文章中介绍的，云计算通过统一的操作系统将硬件和虚拟的大型超级计算机结合在一起；那么在这个虚拟的“超级计算机”上，所有的计算都是通过时间表软件来进行的。资源按需自由、灵活分配。与什么样的硬件相结合，成为生态环境建设的关键节点。
对于大型央企来说，从国外软件迁移到国产软件的最大痛点在于，新软件需要与原有的软硬件平台兼容，实现平滑过渡。这其中的核心就是各种芯片云的融合。平台兼容性被业界称为“一云多核”。如果说上层云平台本身比作一辆汽车，而底层芯片比作汽车的燃料，那么拥有云和多核能力的专有云就像是一辆可以充电、加油的汽车。无论底层基于什么硬件，上层都是统一兼容的。
根据云和多核的定义，要实现“适配多种硬件”，这说起来不容易，做起来也不容易：必须从第一行代码开始，搭建开发环境，实际开发和测试，然后从外包给客户，规划、交付、部署、验证……整个流程的每一步都必须能够适应各种底层硬件。
家庭云服务技术的发展提供了很好的解决方案。例如腾讯私有云打造的架构，以1:1的比例为客户提供公有云能力。这些能力在应用于私有云客户之前已经在公有云上经过了数百万用户的测试，失败率比私有云架构少。并且具有云服务的天然优势，按需分配，最大化资源利用，快速响应需求。目前建设银行、人保财险、中国银联等一大批大型金融机构以及工业富联等大型工业企业都在腾讯专有云上运营数字业务。高科技意味着生态竞争。首先取得突破的国产基础软件为家居硬件创新创造了良好的环境。
发力到海外市场
不仅在国内市场，中国厂商基于云服务的软件产品或PaaS产品在海外市场也展现出显着的竞争力。例如在邻近的东南亚，印度尼西亚银行的核心数字银行系统就运行在腾讯云数据库上。到2022年，印尼银行每天可以处理200万笔交易和15万笔贷款支付。高性能的国产数据库助力印尼银行业务爆发式增长，在海外市场提供支持并赢得声誉。
视频云服务表现更好。在全球市场上，中国制造商拥有相当大的市场份额。这与中国近二十年来极其发达的远程工作、即时通讯、网络直播行业有很大关系。新加坡本土视频SaaS公司BeLive、日本领先的视频直播平台MIXCHANNEL、非洲市场最大的音乐流媒体平台Boomplay均由腾讯提供技术支持。这也很容易理解，因为国内90%的直播平台都有腾讯云支持，承受住了中国网民微信抢春晚红包8.1亿次/分钟的峰值，以及B站数亿人次的高峰，斗鱼看LOL全球总决赛，发弹幕，买礼物。从技术上讲，斗鱼没有理由不能处理来自日本和非洲的人们的视频直播。
此外，仅腾讯会议自推出以来就支持了超过4亿用户在线工作，更不用说QQ和微信了。这些应用中打磨出来的实时音视频（TRTC）技术、即时通讯技术都是特殊能力。在技术和产品层面，海外的一些应用场景被认为是对降维的打击。产品的技术和市场竞争力在财报数据中得到了非常直观的体现：2023年上半年，腾讯云国际业务保持两位数增长，在欧洲、日本、新加坡、马来西亚、印尼等地区表现出色。在中东表现突出的是由外国合作伙伴推动的收入增长达到了66%。
1991年，杰弗里摩尔写了著名的管理学著作《跨越鸿沟》。他在书中表示：高科技公司创新产品应该瞄准的第一批种子用户通常是两类人：“技术狂热者”和“梦想家”。但除了这两种之外，还有一类客户是需求驱动的。因为他们面临的问题如此严重，任何新的解决方案都可能比当前的解决方案更好，所以他们更愿意尝试颠覆性的创新产品。
推动中国互联网发展的，正是这样一群“必要的改变”需求的出现。而勇敢满足需求、走技术创新之路的，就是中国的互联网企业。他们在中国互联网的浪潮中做出了一系列世界一流的软件应用。
另一方面，中国互联网企业通过中国特有的发展路径，解决了国产软硬件发展难以逾越的障碍。从2018年到2022年的五年间，仅腾讯的研发投入就超过2000亿元，且研发强度还在逐年加大。它聚集的是一条以IT产业为核心的本土化IT基础设施生态链。AI芯片、网络DPU、自研服务器、奥驰分布式云操作系统、TDSQL数据库等逐步覆盖生态链关键节点。同时，我们将用投资来支持生态链上的创新型企业。
国产软件的发展还有很长的路要走，但在市场竞争中也取得了长足的进步。近20年来，互联网企业在多个方面完成了“从无到有”的突破，实现了一套完整的生态系统的初步构建。依托数字化浪潮，我们能够不断积累波兰产品和各种商业形态的技术；投入资金进一步满足技术研发和创新市场的需求。
ETL负责将分布的、异构数据源中的数据如关系数据、平面数据文件等抽取到临时中间层后进行清洗、转换、集成，最后加载到数据仓库或数据集市中，成为联机分析处理、数据挖掘的基础。是数据仓库中的非常重要的一环。它是承前启后的必要的一步。相对于关系数据库，数据仓库技术没有严格的数学理论基础，它更面向实际工程应用。所以从工程应用的角度来考虑，按着物理数据模型的要求加载数据并对数据进行一些系列处理，处理过程与经验直接相关，同时这部分的工作直接关系数据仓库中数据的质量，从而影响到联机分析处理和数据挖掘的结果的质量。
数据仓库是一个独立的数据环境，需要通过抽取过程将数据从联机事务处理环境、外部数据源和脱机的数据存储介质导入到数据仓库中；在技术上，ETL主要涉及到关联、转换、增量、调度和监控等几个方面；数据仓库系统中数据不要求与联机事务处理系统中数据实时同步，所以ETL可以定时进行。但多个ETL的操作时间、顺序和成败对数据仓库中信息的有效性至关重要。
ETL中的关键技术
ETL过程中的主要环节就是数据抽取、数据转换和加工、数据装载。为了实现这些功能，各个ETL工具一般会进行一些功能上的扩充，例如工作流、调度引擎、规则引擎、脚本支持、统计信息等。
数据抽取
数据抽取是从数据源中抽取数据的过程。实际应用中，数据源较多采用的是关系数据库。从数据库中抽取数据一般有以下几种方式。
(1)全量抽取
全量抽取类似于数据迁移或数据复制，它将数据源中的表或视图的数据原封不动的从数据库中抽取出来，并转换成自己的ETL工具可以识别的格式。全量抽取比较简单。
(2)增量抽取
增量抽取只抽取自上次抽取以来数据库中要抽取的表中新增或修改的数据。在ETL使用过程中。增量抽取较全量抽取应用更广。如何捕获变化的数据是增量抽取的关键。对捕获方法一般有两点要求：准确性，能够将业务系统中的变化数据按一定的频率准确地捕获到；性能，不能对业务系统造成太大的压力，影响现有业务。目前增量数据抽取中常用的捕获变化数据的方法有：
a.触发器：在要抽取的表上建立需要的触发器，一般要建立插入、修改、删除三个触发器，每当源表中的数据发生变化，就被相应的触发器将变化的数据写入一个临时表，抽取线程从临时表中抽取数据，临时表中抽取过的数据被标记或删除。触发器方式的优点是数据抽取的性能较高，缺点是要求业务表建立触发器，对业务系统有一定的影响。
b.时间戳：它是一种基于快照比较的变化数据捕获方式，在源表上增加一个时间戳字段，系统中更新修改表数据的时候，同时修改时间戳字段的值。当进行数据抽取时，通过比较系统时间与时间戳字段的值来决定抽取哪些数据。有的数据库的时间戳支持自动更新，即表的其它字段的数据发生改变时，自动更新时间戳字段的值。有的数据库不支持时间戳的自动更新，这就要求业务系统在更新业务数据时，手工更新时间戳字段。同触发器方式一样，时间戳方式的性能也比较好，数据抽取相对清楚简单，但对业务系统也有很大的倾入性(加入额外的时间戳字段)，特别是对不支持时间戳的自动更新的数据库，还要求业务系统进行额外的更新时间戳操作。另外，无法捕获对时间戳以前数据的delete和update操作,在数据准确性上受到了一定的限制。
c.全表比对：典型的全表比对的方式是采用MD5校验码。ETL工具事先为要抽取的表建立一个结构类似的MD5临时表，该临时表记录源表主键以及根据所有字段的数据计算出来的MD5校验码。每次进行数据抽取时，对源表和MD5临时表进行MD5校验码的比对，从而决定源表中的数据是新增、修改还是删除，同时更新MD5校验码。MD5方式的优点是对源系统的倾入性较小(仅需要建立一个MD5临时表)，但缺点也是显而易见的，与触发器和时间戳方式中的主动通知不同，MD5方式是被动的进行全表数据的比对，性能较差。当表中没有主键或唯一列且含有重复记录时，MD5方式的准确性较差。
d.日志对比：通过分析数据库自身的日志来判断变化的数据。Oracle的改变数据捕获(CDC，Changed Data Capture)技术是这方面的代表。CDC 特性是在Oracle9i数据库中引入的。CDC能够帮助你识别从上次抽取之后发生变化的数据。利用CDC，在对源表进行insert、update或 delete等操作的同时就可以提取数据，并且变化的数据被保存在数据库的变化表中。这样就可以捕获发生变化的数据，然后利用数据库视图以一种可控的方式提供给目标系统。CDC体系结构基于发布者/订阅者模型。发布者捕捉变化数据并提供给订阅者。订阅者使用从发布者那里获得的变化数据。通常，CDC系统拥有一个发布者和多个订阅者。发布者首先需要识别捕获变化数据所需的源表。然后，它捕捉变化的数据并将其保存在特别创建的变化表中。它还使订阅者能够控制对变化数据的访问。订阅者需要清楚自己感兴趣的是哪些变化数据。一个订阅者可能不会对发布者发布的所有数据都感兴趣。订阅者需要创建一个订阅者视图来访问经发布者授权可以访问的变化数据。CDC分为同步模式和异步模式，同步模式实时的捕获变化数据并存储到变化表中，发布者与订阅都位于同一数据库中。异步模式则是基于Oracle的流复制技术。
ETL处理的数据源除了关系数据库外，还可能是文件，例如txt文件、excel文件、xml文件等。对文件数据的抽取一般是进行全量抽取，一次抽取前可保存文件的时间戳或计算文件的MD5校验码，下次抽取时进行比对，如果相同则可忽略本次抽取。
数据转换和加工
从数据源中抽取的数据不一定完全满足目的库的要求，例如数据格式的不一致、数据输入错误、数据不完整等等，因此有必要对抽取出的数据进行数据转换和加工。
数据的转换和加工可以在ETL引擎中进行，也可以在数据抽取过程中利用关系数据库的特性同时进行。
(1)ETL引擎中的数据转换和加工
ETL引擎中一般以组件化的方式实现数据转换。常用的数据转换组件有字段映射、数据过滤、数据清洗、数据替换、数据计算、数据验证、数据加解密、数据合并、数据拆分等。这些组件如同一条流水线上的一道道工序，它们是可插拔的，且可以任意组装，各组件之间通过数据总线共享数据。
有些ETL工具还提供了脚本支持，使得用户可以以一种编程的方式定制数据的转换和加工行为。
(2)在数据库中进行数据加工
关系数据库本身已经提供了强大的SQL、函数来支持数据的加工，如在SQL查询语句中添加where条件进行过滤，查询中重命名字段名与目的表进行映射，substr函数，case条件判断等等。下面是一个SQL查询的例子。
select ID as USERID, substr(TITLE, 1, 20) as TITLE, case when REMARK is null then ' ' else REMARK end as CONTENT from TB_REMARK where ID > 100;
相比在ETL引擎中进行数据转换和加工，直接在SQL语句中进行转换和加工更加简单清晰，性能更高。对于SQL语句无法处理的可以交由ETL引擎处理。
数据装载
将转换和加工后的数据装载到目的库中通常是ETL过程的最后步骤。装载数据的最佳方法取决于所执行操作的类型以及需要装入多少数据。当目的库是关系数据库时，一般来说有两种装载方式：
(1)直接SQL语句进行insert、update、delete操作。
(2)采用批量装载方法，如bcp、bulk、关系数据库特有的批量装载工具或api。
大多数情况下会使用第一种方法，因为它们进行了日志记录并且是可恢复的。但是，批量装载操作易于使用，并且在装入大量数据时效率较高。使用哪种数据装载方法取决于业务系统的需要。
ETL工具的典型代表有:Informatica、Datastage、ODI ,OWB、微软DTS、Beeload、Kettle、久其ETL……
ETL工具
旗鼓相当：Datastage与Powercenter：
就Datastage和Powercenter而言，这两者目前占据了国内市场绝大部分的份额，在成本上看水平相当，虽然市面上还有诸如Business Objects公司的Data Integrator、Cognos公司的DecisionStream，但尚属星星之火，未成燎原之势。
谈Datastage和Powercenter，如果有人说这个就是比那个好，那听者就要小心一点了。在这种情况下有两种可能：他或者是其中一个厂商的员工，或者就是在某个产品上有很多经验而在另一产品上经验缺乏的开发者。为什么得出这一结论？一个很简单的事实是，从网络上大家对它们的讨论和争执来看，基本上是各有千秋，都有着相当数量的成功案例和实施高手。确实，工具是死的，人才是活的。在两大ETL工具技术的比对上，可以从对ETL流程的支持、对元数据的支持、对数据质量的支持、维护的方便性、定制开发功能的支持等方面考虑。
一个项目中，从数据源到最终目标表，多则上百个ETL过程，少则也有十几个。这些过程之间的依赖关系、出错控制以及恢复的流程处理，都是工具需要重点考虑。在这一方面，Datastage的早期版本对流程就缺乏考虑，而在6版本则加入Job Sequence的特性，可以将Job、shell脚本用流程图的方式表示出来，依赖关系、串行或是并行都可以一目了然，就直观多了。Powercenter有Workflow的概念，也同样可以将Session串联起来，这和Datastage Sequence大同小异。
ETL的元数据包括数据源、目标数据的结构、转换规则以及过程的依赖关系等。在这方面，Datastage和Powercenter从功能上看可谓不分伯仲，只是后者的元数据更加开放，存放在关系数据库中，可以很容易被访问(Informatic把Metadata全部放在数据库中而Datastage是自己管理Metadata，不依赖任何数据库.)。此外，这两个厂家又同时提供专门的元数据管理工具，Ascential有Metastage，而Informatica拥有Superglue。你看，就不给你全部功能，变着法子从你口袋里面多掏点钱。
数据质量方面，两种产品都采用同样的策略——独立出ETL产品之外，另外有专门的数据质量管理产品。例如和Datastage配套用的有ProfileStage和QualityStage，而Informatica最近也索性收购了原先OEM的数据质量管理产品FirstLogic。而在它们的ETL产品中，只是在Job或是Session前后留下接口，所谓前过程、后过程，虽然不是专为数据质量预留的接口，不过至少可以利用它外挂一些数据质量控制的模块。
在具体实现上看，Datastage通过Job实现一个ETL过程，运行时可以通过指定不同参数运行多个实例。Powercenter通过Mapping表示一个ETL过程，运行时为Session，绑定了具体的物理数据文件或表。在修改维护上，这两个工具都是提供图形化界面。这样的好处是直观、傻瓜式的；不好的地方就是改动还是比较费事(特别是批量化的修改)。
定制开发方面，两者都提供抽取、转换插件的定制，但笔者认为，Datastage的定制开发性要比Powercenter要强那么一点点。因为Datastage至少还内嵌一种类BASIC语言，可以写一段批处理程序来增加灵活性，而Powercenter似乎还缺乏这类机制。另外从参数控制上，虽然两者的参数传递都是比较混乱的，但Datastage至少可以对每个job设定参数，并且可以job内部引用这个参数名；而Powercenter显得就有些偷懒，参数放在一个参数文件中，理论上的确可以灵活控制参数，但这个灵活性需要你自己更新文件中的参数值(例如日期更新)。另外，Powercenter还不能在mapping或session中引用参数名，这一点就让人恼火。
总起来看，Datastage和Powercenter可谓旗鼓相当，在国内也都有足够的支持能力，Datastage在2005年被IBM收购之后，可以说后劲十足。而Informatica则朝着BI全解决方案提供商方向发展，Powercenter显然还将是它的核心产品。
ODI
ODI提出了知识模块的概念，把这些场景的详细的实现步骤作为一个一个的知识模块并使用Jython脚本语言结合数据库的SQL语句录制成一步一步的步骤忠实地记录下来，这样就形成了ODI里的100多个知识模块，基本上包含了所有普通应用所涉及到的所有场景。更方便的是，用户既可以直接使用ODI的知识模块完成数据的获取工作，也可以直接在知识模块上面做各种定制，比如某一个业务场景可能并不需要知识模块里的某一个特定的步骤，那就可以直接把该步骤删除掉从而提供更好的性能。当然用户也可以完全自己来开发这些知识模块。ODI的知识模块主要分为几个大类(RKM,CKM,LKM,IKM,SKM)，其中最重要的是LKM(load KM)和IKM(Integration KM)RKM。
RKM：完成从源系统和目标系统的数据结构的反向工程来形成数据模型的功能。
CKM：CKM完成数据质量检查。
LKM：LKM完成从源数据库数据加载到临时表。
IKM：IKM完成从临时表的数据加载到目标表。
SKM：SKM完成ODI和WEB服务接口的功能。
ODI的性能不是很好，Powercenter > Datastage > ODI
独树一帜：Teradata的ETL Automation
继续要说的第三种产品是Teradata的ETL Automation。之所以拿它单独来说是因为它和前面两种产品的体系架构都不太一样。与其说它是ETL工具，不如说是提供了一套ETL框架。它没有将注意力放在如何处理“转换”这个环节上，而是利用Teradata数据库本身的并行处理能力，用SQL语句来做数据转换的工作，其重点是提供对ETL流程的支持，包括前后依赖、执行和监控等。
这样的设计和Datastage、Powercenter风格迥异，后两者给人的印象是具有灵活的图形化界面，开发者可以傻瓜式处理ETL工作，它们一般都拥有非常多的“转换”组件，例如聚集汇总、缓慢变化维的转换。而对于Teradata的ETL Automation，有人说它其实应该叫做ELT，即装载是在转换之前的。的确，如果依赖数据库的能力去处理转换，恐怕只能是ELT，因为转换只能在数据库内部进行。从这个角度看，Automation对数据库的依赖不小，似乎是一种不灵活的设计。也正是这个原因，考虑它的成本就不单单是ETL产品的成本了。
其实，在购买现成的工具之外，还有自己从头开发ETL程序的。
ETL工作看起来并不复杂，特别是在数据量小、没有什么转换逻辑的时候，自己开发似乎非常节省成本。的确，主流的ETL工具价格不菲，动辄几十万；而从头开发无非就是费点人力而已，可以控制。至于性能，人大多是相信自己的，认为自己开发出来的东西知根知底，至少这些程序可以完全由自己控制。就目前自主开发的ETL程序而言，有人用C语言编写，有人用存储过程，还有人用各种语言混杂开发，程序之间各自独立。这很危险，虽然能够让开发者过足编码的瘾，却根本不存在架构。
有位银行的朋友，他们几年前上的数据仓库系统，就是集成商自己用c语言专门为他们的项目开发的。单从性能上看似乎还不赖，然而一两年下来，项目组成员风雨飘零，早已物是人非，只有那套程序还在那里；而且，按照国内目前的软件工程惯例，程序注释和文档是不全或者是不一致的，这样的程序已经对日常业务造成很大阻碍。最近，他们已经开始考虑使用ETL工具重新改造了。
总体比较列表：
ETL工具选型参照表
ETL工具选型参照表 | |||
工具 | 优点 | 缺点 | |
主流工具 | Datastage | 内嵌一种类BASIC语言，可通过批处理程序增加灵活性，可对每个job设定参数并在job内部引用 | 早期版本对流程支持缺乏考虑；图形化界面改动费事 |
Powercenter | 元数据管理更为开放，存放在关系数据库中，可以很容易被访问 | 没有内嵌类BASIC语言，参数值需人为更新，且不能引用参数名；图形化界面改动费事 | |
Automation | 提供一套ETL框架，利用Teradata数据仓库本身的并行处理能力 | 对数据库依赖性强，选型时需要考虑综合成本（包括数据库等） | |
udis睿智ETL | 适合国内需求，性价比高 | 配置复杂，缺少对元数据的管理 | |
自主开发 | 相对于购买主流ETL工具，成本较低 | 各种语言混杂开发，无架构可言，后期维护难度大。 | |
ETL工具的选择
在数据集成中该如何选择ETL工具呢？一般来说需要考虑以下几个方面：
(1)对平台的支持程度。
(2)对数据源的支持程度。
(3)抽取和装载的性能是不是较高，且对业务系统的性能影响大不大，倾入性高不高。
(4)数据转换和加工的功能强不强。
(5)是否具有管理和调度功能。
(6)是否具有良好的集成性和开放性
上文转自：ETL介绍与ETL工具比较
ETL(是Extract-Transform-Load的缩写，即数据抽取、转换、装载的过程)，对于企业应用来说，我们经常会遇到各种数据的处理、转换、迁移的场景。下文汇总了一些目前市面上比较常用的ETL数据迁移工具，希望对你会有所帮助。
1.Kettle
Kettle是一款国外开源的ETL工具，纯Java编写，绿色无需安装，数据抽取高效稳定 (数据迁移工具)。Kettle 中文名称叫水壶，该项目的主程序员 MATT 希望把各种数据放到一个壶里，然后以一种指定的格式流出。其中有两种脚本文件，transformation 和 job，transformation 完成针对数据的基础转换，job 则完成整个工作流的控制。
Kettle 这个 ETL 工具集，它允许你管理来自不同数据库的数据，通过提供一个图形化的用户环境来描述你想做什么，而不是你想怎么做。Kettle 家族目前包括 4 个产品：Spoon、Pan、CHEF、Kitchen。
SPOON：允许你通过图形界面来设计 ETL 转换过程（Transformation）。
PAN：允许你批量运行由 Spoon 设计的 ETL 转换 (例如使用一个时间调度器)。Pan 是一个后台执行的程序，没有图形界面。
CHEF：允许你创建任务（Job）。任务通过允许每个转换，任务，脚本等等，更有利于自动化更新数据仓库的复杂工作。任务通过允许每个转换，任务，脚本等等。任务将会被检查，看看是否正确地运行了。
KITCHEN：允许你批量使用由 Chef 设计的任务 (例如使用一个时间调度器)。KITCHEN 也是一个后台运行的程序。
2.Datax
DataX是阿里云 DataWorks数据集成的开源版本，在阿里巴巴集团内被广泛使用的离线数据同步工具/平台。
DataX 是一个异构数据源离线同步工具，致力于实现包括关系型数据库(MySQL、Oracle等)、HDFS、Hive、ODPS、HBase、FTP等各种异构数据源之间稳定高效的数据同步功能。
设计理念：为了解决异构数据源同步问题，DataX将复杂的网状的同步链路变成了星型数据链路，DataX作为中间传输载体负责连接各种数据源。当需要接入一个新的数据源的时候，只需要将此数据源对接到DataX，便能跟已有的数据源做到无缝数据同步。
当前使用现状：DataX在阿里巴巴集团内被广泛使用，承担了所有大数据的离线同步业务，并已持续稳定运行了6年之久。目前每天完成同步8w多道作业，每日传输数据量超过300TB。DataX本身作为离线数据同步框架，采用Framework + plugin架构构建。将数据源读取和写入抽象成为Reader/Writer插件，纳入到整个同步框架中。
DataX 3.0 开源版本支持单机多线程模式完成同步作业运行，本小节按一个DataX作业生命周期的时序图，从整体架构设计非常简要说明DataX各个模块相互关系。六大核心优势：
可靠的数据质量监控
丰富的数据转换功能
精准的速度控制
强劲的同步性能
健壮的容错机制
极简的使用体验
3.DataPipeline
DataPipeline采用基于日志的增量数据获取技术（ Log-based Change Data Capture ），支持异构数据之间丰富、自动化、准确的语义映射构建，同时满足实时与批量的数据处理。可实现 Oracle、IBM DB2、MySQL、MS SQL Server、PostgreSQL、GoldenDB、TDSQL、OceanBase 等数据库准确的增量数据获取。平台具备“数据全、传输快、强协同、更敏捷、极稳定、易维护”六大特性。在支持传统关系型数据库的基础上，对大数据平台、国产数据库、云原生数据库、API 及对象存储也提供广泛的支持，并在不断扩展。
DataPipeline 数据融合产品致力于为用户提供企业级数据融合解决方案，为用户提供统一平台同时管理异构数据节点实时同步与批量数据处理任务，在未来还将提供对实时流计算的支持。采用分布式集群化部署方式，可水平垂直线性扩展的，保证数据流转稳定高效，让客户专注数据价值释放。
产品特点：
全面的数据节点支持：支持关系型数据库、NoSQL数据库、国产数据库、数据仓库、大数据平台、云存储、API等多种数据节点类型，可自定义数据节点。
高性能实时处理：针对不同数据节点类型提供TB级吞吐量、秒级低延迟的增量数据处理能力，加速企业各类场景的数据流转。
分层管理降本增效：采用“数据节点注册、数据链路配置、数据任务构建、系统资源分配”的分层管理模式，企业级平台的建设周期从三到六个月减少为一周。
无代码敏捷管理：提供限制配置与策略配置两大类十余种高级配置，包括灵活的数据对象映射关系，数据融合任务的研发交付时间从2周减少为5分钟。
极稳定高可靠：采用分布式架构，所有组件均支持高可用，提供丰富容错策略，应对上下游的结构变化、数据错误、网络故障等突发情况，可以保证系统业务连续性要求。
全链路数据可观测：配备容器、应用、线程、业务四级监控体系，全景驾驶舱守护任务稳定运行。自动化运维体系，灵活扩缩容，合理管理和分配系统资源。
4.Talend
Talend (踏蓝) 是第一家针对的数据集成工具市场的 ETL (数据的提取 Extract、传输 Transform、载入 Load) 开源软件供应商。以它的技术和商业双重模式为 ETL 服务提供了一个全新的远景。它打破了传统的独有封闭服务，提供了一个针对所有规模的公司的公开的，创新的，强大的灵活的软件解决方案。
5.Datastage
DataStage，即IBM WebSphere DataStage，是一套专门对多种操作数据源的数据抽取、转换和维护过程进行简化和自动化，并将其输入数据集市或数据仓库目标数据库的集成工具，可以从多个不同的业务系统中，从多个平台的数据源中抽取数据，完成转换和清洗，装载到各种系统里面。
其中每步都可以在图形化工具里完成，同样可以灵活地被外部系统调度，提供专门的设计工具来设计转换规则和清洗规则等，实现了增量抽取、任务调度等多种复杂而实用的功能。其中简单的数据转换可以通过在界面上拖拉操作和调用一些 DataStage 预定义转换函数来实现，复杂转换可以通过编写脚本或结合其他语言的扩展来实现，并且 DataStage 提供调试环境，可以极大提高开发和调试抽取、转换程序的效率。
Datastage 操作界面
对元数据的支持：Datastage 是自己管理 Metadata，不依赖任何数据库。
参数控制：Datastage 可以对每个 job 设定参数，并且可以 job 内部引用这个参数名。
数据质量：Datastage 有配套用的 ProfileStage 和 QualityStage 保证数据质量。
定制开发：提供抽取、转换插件的定制，Datastage 内嵌一种类 BASIC 语言，可以写一段批处理程序来增加灵活性。
修改维护：提供图形化界面。这样的好处是直观、傻瓜式的；不好的地方就是改动还是比较费事（特别是批量化的修改）。
Datastage 包含四大部件：
Administrator：新建或者删除项目，设置项目的公共属性，比如权限。
Designer：连接到指定的项目上进行 Job 的设计；
Director：负责 Job 的运行，监控等。例如设置设计好的 Job 的调度时间。
Manager：进行 Job 的备份等 Job 的管理工作。
6.Sqoop
Sqoop 是 Cloudera 公司创造的一个数据同步工具，现在已经完全开源了。
目前已经是 Hadoop 生态环境中数据迁移的首选 Sqoop 是一个用来将 Hadoop 和关系型数据库中的数据相互转移的工具，可以将一个关系型数据库（例如 ：MySQL ,Oracle ,Postgres 等）中的数据导入到 Hadoop 的 HDFS 中，也可以将 HDFS 的数据导入到关系型数据库中。
其将我们传统的关系型数据库 | 文件型数据库 | 企业数据仓库 同步到我们的 hadoop 生态集群中。同时也可以将 hadoop 生态集群中的数据导回到传统的关系型数据库 | 文件型数据库 | 企业数据仓库中。
那么 Sqoop 如何抽取数据呢?
首先 Sqoop 去 rdbms 抽取元数据。
当拿到元数据之后将任务切成多个任务分给多个 map。
然后再由每个 map 将自己的任务完成之后输出到文件。
7.FineDataLink
FineDataLink是国内做的比较好的ETL工具，FineDataLink是一站式的数据处理平台，具备高效的数据同步功能，可以实现实时数据传输、数据调度、数据治理等各类复杂组合场景的能力，提供数据汇聚、研发、治理等功能。
FDL拥有低代码优势，通过简单的拖拽交互就能实现ETL全流程。
FineDataLink——中国领先的低代码/高时效数据集成产品，能过为企业提供一站式的数据服务，通过快速连接、高时效融合多种数据，提供低代码Data API敏捷发布平台，帮助企业解决数据孤岛难题，有效提升企业数据价值。
8.canal
canal [kə'næl]，译意为水道/管道/沟渠，主要用途是基于 MySQL 数据库增量日志解析，提供增量数据订阅和消费。
早期阿里巴巴因为杭州和美国双机房部署，存在跨机房同步的业务需求，实现方式主要是基于业务 trigger 获取增量变更。从 2010 年开始，业务逐步尝试数据库日志解析获取增量变更进行同步，由此衍生出了大量的数据库增量订阅和消费业务。
基于日志增量订阅和消费的业务包括：
数据库镜像
数据库实时备份
索引构建和实时维护(拆分异构索引、倒排索引等)
业务 cache 刷新
带业务逻辑的增量数据处理
当前的 canal 支持源端 MySQL 版本包括 5.1~5.7.x , 8.0.x。
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 流)
9、TDSQL
腾讯在2007年搭建了自己的分布式数据库TDSQL，该数据库早期用于支持Q币交易系统。如果腾讯不想限制Q-Coin的交易频率，就必须自己开发TDSQL。后来扩展到微信。支付、腾讯视频、腾讯音乐、腾讯会议、王者荣耀等国家级应用。直到2014年，腾讯的大部分计费业务都是由TDSQL支持的。
互联网带来的爆炸性需求，加速了各类软件技术的国产化。x86和ARM架构服务器迅速取代IBM小型机，EMC存储被分布式存储取代，家庭办公软件和ERP系统也实现了从无到有的突破。云技术的普及开始大幅降低企业的IT成本，进一步推动数据库、专有云等底层软件的研发。互联网的商业化已经成为我国基础软件产业发展的一条隐线。不断增长的需求推动我国基础软件走上了一条新的技术道路，并通过不断的实际应用锻造出了一系列日益流行的技术。有竞争力的产品。这看起来像是另一个“电动汽车时刻”。虽然今天的计算产业生态系统还不一定完整，但至少已经初具规模。在这场高科技生态竞争中，中国基础软件开始将资格摆上牌桌。
在中国各行业产品本土化过程中，一大难点就是缺乏对市场持续、耐心的验证。但对于中国的这群互联网企业来说，在很多场景下，无论是社交、电商还是游戏，都有大量的应用场景和行业需求，解决了“市场在哪里”的问题。比如上面提到的数据库TDSQL，在孵化过程中，Q币的应用是一个非常有趣的尝试，因为腾讯当时对数据库开发团队的内部要求是：即使是虚拟货币，也必须有银行级别。会计系统不能有哪怕一分钱的错误。
在所有行业中，金融行业对数据一致性和可用性的要求最高。如果一家全国性银行半个小时出现故障，该银行的技术总监就必须到银保监会去解释到底出了什么问题。Q币的应用在一定程度上帮助腾讯率先适应了这种相对严峻的需求状况，进而蔓延至“微信支付”等腾讯内部支付系统。也帮助TDSQL数据库赢得了2014年微众银行的胜利案例，打下了很好的基础。国内传统银行核心系统首次迁移至国内银行，并接入TDSQL。当时张家港农商银行就迁移到了TDSQL。要最终实现，其背后的三个要素缺一不可：
首先，中国的数据库能力已经达到了。
截至2023年3月，TDSQL数据库在权威评测机构交易处理性能委员会（TPC）排行榜上排名第一，每分钟处理能力达8.14亿订单。数据库与人工智能不同。大型AI模型的性能测试没有公式，维度太多，多个世界第一层出不穷。但数据库的衡量维度基本上只有两个：一是是否足够快，二是单位成本是否足够低。标准明确，第一就是第一，他的出色表现是毋庸置疑的。
二是生态成熟。
TDSQL数据库背后有一套全栈的内部解决方案，从硬件级芯片到网络DPU和内部服务器；到奥驰分布式云的软件级操作系统和中间件，已经有支持家用的解决方案。 。依托腾讯自身的云计算业务，全计算产业链生态系统已经形成。
第三，大环境下，市场更愿意选择国内厂商。
棱镜门之后，出于数据安全等考虑，银行等重点行业越来越倾向于把机会让给国内厂商。结果真的很好。某大型国有银行更换TDSQL分布式核心数据库后，部署成本降低1亿，且性能和稳定性不受影响。从客户信息、信用卡核心系统有序转向个人债务、投资理财，推动公司业务、信贷产品等分布式核心产品应用。
目前，TDSQL的应用在金融领域得到广泛应用，并正在进入行业复制阶段。实现如此规模的替代不仅是政治倾向的结果，也是市场竞争力的证明。中国的数据库及其背后的全栈云计算解决方案已经具备显着的市场竞争力。在需要较多自主创新的大型政企行业，过去主要基于国外VMware搭建私有云。但传统IT架构计算能力、存储资源利用率低，对业务资源需求的响应周期长，无法满足企业IT基础设施云化、云原生转型的需求。
正如我们在上一篇文章中介绍的，云计算通过统一的操作系统将硬件和虚拟的大型超级计算机结合在一起；那么在这个虚拟的“超级计算机”上，所有的计算都是通过时间表软件来进行的。资源按需自由、灵活分配。与什么样的硬件相结合，成为生态环境建设的关键节点。
对于大型央企来说，从国外软件迁移到国产软件的最大痛点在于，新软件需要与原有的软硬件平台兼容，实现平滑过渡。这其中的核心就是各种芯片云的融合。平台兼容性被业界称为“一云多核”。如果说上层云平台本身比作一辆汽车，而底层芯片比作汽车的燃料，那么拥有云和多核能力的专有云就像是一辆可以充电、加油的汽车。无论底层基于什么硬件，上层都是统一兼容的。
根据云和多核的定义，要实现“适配多种硬件”，这说起来不容易，做起来也不容易：必须从第一行代码开始，搭建开发环境，实际开发和测试，然后从外包给客户，规划、交付、部署、验证……整个流程的每一步都必须能够适应各种底层硬件。
家庭云服务技术的发展提供了很好的解决方案。例如腾讯私有云打造的架构，以1:1的比例为客户提供公有云能力。这些能力在应用于私有云客户之前已经在公有云上经过了数百万用户的测试，失败率比私有云架构少。并且具有云服务的天然优势，按需分配，最大化资源利用，快速响应需求。目前建设银行、人保财险、中国银联等一大批大型金融机构以及工业富联等大型工业企业都在腾讯专有云上运营数字业务。高科技意味着生态竞争。首先取得突破的国产基础软件为家居硬件创新创造了良好的环境。
发力到海外市场
不仅在国内市场，中国厂商基于云服务的软件产品或PaaS产品在海外市场也展现出显着的竞争力。例如在邻近的东南亚，印度尼西亚银行的核心数字银行系统就运行在腾讯云数据库上。到2022年，印尼银行每天可以处理200万笔交易和15万笔贷款支付。高性能的国产数据库助力印尼银行业务爆发式增长，在海外市场提供支持并赢得声誉。
视频云服务表现更好。在全球市场上，中国制造商拥有相当大的市场份额。这与中国近二十年来极其发达的远程工作、即时通讯、网络直播行业有很大关系。新加坡本土视频SaaS公司BeLive、日本领先的视频直播平台MIXCHANNEL、非洲市场最大的音乐流媒体平台Boomplay均由腾讯提供技术支持。这也很容易理解，因为国内90%的直播平台都有腾讯云支持，承受住了中国网民微信抢春晚红包8.1亿次/分钟的峰值，以及B站数亿人次的高峰，斗鱼看LOL全球总决赛，发弹幕，买礼物。从技术上讲，斗鱼没有理由不能处理来自日本和非洲的人们的视频直播。
此外，仅腾讯会议自推出以来就支持了超过4亿用户在线工作，更不用说QQ和微信了。这些应用中打磨出来的实时音视频（TRTC）技术、即时通讯技术都是特殊能力。在技术和产品层面，海外的一些应用场景被认为是对降维的打击。产品的技术和市场竞争力在财报数据中得到了非常直观的体现：2023年上半年，腾讯云国际业务保持两位数增长，在欧洲、日本、新加坡、马来西亚、印尼等地区表现出色。在中东表现突出的是由外国合作伙伴推动的收入增长达到了66%。
1991年，杰弗里摩尔写了著名的管理学著作《跨越鸿沟》。他在书中表示：高科技公司创新产品应该瞄准的第一批种子用户通常是两类人：“技术狂热者”和“梦想家”。但除了这两种之外，还有一类客户是需求驱动的。因为他们面临的问题如此严重，任何新的解决方案都可能比当前的解决方案更好，所以他们更愿意尝试颠覆性的创新产品。
推动中国互联网发展的，正是这样一群“必要的改变”需求的出现。而勇敢满足需求、走技术创新之路的，就是中国的互联网企业。他们在中国互联网的浪潮中做出了一系列世界一流的软件应用。
另一方面，中国互联网企业通过中国特有的发展路径，解决了国产软硬件发展难以逾越的障碍。从2018年到2022年的五年间，仅腾讯的研发投入就超过2000亿元，且研发强度还在逐年加大。它聚集的是一条以IT产业为核心的本土化IT基础设施生态链。AI芯片、网络DPU、自研服务器、奥驰分布式云操作系统、TDSQL数据库等逐步覆盖生态链关键节点。同时，我们将用投资来支持生态链上的创新型企业。
国产软件的发展还有很长的路要走，但在市场竞争中也取得了长足的进步。近20年来，互联网企业在多个方面完成了“从无到有”的突破，实现了一套完整的生态系统的初步构建。依托数字化浪潮，我们能够不断积累波兰产品和各种商业形态的技术；投入资金进一步满足技术研发和创新市场的需求。