写在前面

数据仓库的特性之一是集成，即首先把未经过加工处理的、不同来源的、不同形式的数据同步到ODS层，一般情况下，这些ODS层数据包括日志数据和业务DB数据。对于业务DB数据而言(比如存储在MySQL中)，将数据采集并导入到数仓中(通常是Hive或者MaxCompute)是非常重要的一个环节。

那么，该如何将业务DB数据高效准确地同步到数仓中呢?一般企业会使用两种方案：直连同步与实时增量同步(数据库日志解析)。其中直连同步的基本思路是直连数据库进行SELECT，然后将查询的数据存储到本地文件作为中间存储，最后把文件Load到数仓中。这种方式非常的简单方便，但是随着业务的发展，会遇到一些瓶颈，具体见下文分析。

为了解决这些问题，一般会使用实时增量的方式进行数据同步，其基本原理是CDC (Change Data Capture) + Merge，即实时Binlog采集 + 离线处理Binlog还原业务数据这样一套解决方案。

本文主要包括以下内容，希望对你有所帮助

常见数据同步方式 流式数据集成 数据同步的方式 直连同步

直连同步是指通过定义数仓好的规范接口API和基于动态链接库的方式直接连接业务库，比如ODBC/JDBC等规定了统一的标准接口，不同的数据库基于这套标准提供规范的驱动，从而支持完全相同的函数调用和SQL实现。比如经常使用的Sqoop就是采取这种方式进行批量数据同步的。

直连同步的方式配置十分简单，很容易上手操作，比较适合操作型业务系统的数据同步，但是会存在以下问题：

数据同步时间：随着业务规模的增长，数据同步花费的时间会越来越长，无法满足下游数仓生产的时间要求。 性能瓶颈：直连数据库查询数据，对数据库影响非常大，容易造成慢查询，如果业务库没有采取主备策略，则会影响业务线上的正常服务，如果采取了主备策略，虽然可以避免对业务系统的性能影响，但当数据量较大时，性能依然会很差。

日志解析

所谓日志解析，即解析数据库的变更日志，比如MySQL的Binlog日志，Oracle的归档日志文件。通过读取这些日志信息，收集变化的数据并将其解析到目标存储中即可完成数据的实时同步。这种读操作是在操作系统层面完成的，不需要通过数据库，因此不会给源数据库带来性能上的瓶颈。

数据库 |日志解析的同步方式可以实现实时与准实时的同步，延迟可以控制在毫秒级别的，其最大的优势就是性能好、效率高，不会对源数据库造成影响，目前，从业务系统到数据仓库中的实时增量同步，广泛采取这种方式。当然，这种方式也会存在一些问题，比如批量补数时造成大量数据更新，日志解析会处理较慢，造成数据延迟。除此之外，这种方式比较复杂，投入也较大，因为需要一个实时的抽取系统去抽取并解析日志，下文会对此进行详细解释。

如上图所示架构，在直连同步基础之上增加了流式同步的链路，经过流式计算引擎把相应的 Binlog 采集到 Kafka，同时会经过一个 Kafka 2Hive 的程序把它导入到原始数据，再经过一层 Merge，产出下游需要的 ODS 数据。

上述的数据集成方式优势是非常明显的，把数据传输的时间放到了 T+0 这一天去做，在第二天的时候只需要去做一次 merge 就可以了。非常节省时间和计算资源。

流式数据集成实现 实现思路

首先，采用Flink负责把Kafka上的Binlog数据拉取到HDFS上，生成增量表。

然后，对每张ODS表，首先需要一次性制作快照(Sn 几apshot)，把MySQL里的存量数据读取到Hive上，这一过程底层采用直连MySQL去Select数据的方式，可以使用Sqoop进行一次性全量导入，生成一张全量表。

最后，对每张ODS表，每天基于存量数据和当天增量产生的Binlog做Merge，从而还原出业务数据。

Binlog是流式产生的，通过对Binlog的实时采集，把部分数据处理需求由每天一次的批处理分摊到实时流上。无论从性能上还是对MySQL的访问压力上，都会有明显地改善。Binlog本身记录了数据变更的类型(Insert/Update/Delete)，通过一些语义方面的处理，完全能够做到精准的数据还原。

关于Binlog解析部分，可以使用canal工具，采集到Kafka之后，可以使用Flink解析kafka数据并写入到HDFS上，解析kafka的数据可以使用Flink的DataStreamAPI，也可以使用FlinkSQL的canal-json数据源格式进行解析，使用FlinkSQL相对来说是比较简单的。下面是canal-json格式的kafka数据源。

C种常REATE TABLE region (   id BIGINT,   region_name STRING ) WITH (  'connector' = 'kafka',  'topic' = 'mydw.base_region',  'properties.bootstrap.servers' = 'kms-3:9092',  'properties.group.id' = 'testGroup',  'format' = 'canal-json' ,  'scan.startup.mode' = 'earliest-o见的ffset'  ); 

数据解析完成之后，下面的就是合并还原完整数据的过程，关于合并还原数据，一种比较常见的方式就是全外连接(FULL OUTER JOIN)。具体如下：

生成增量表与全量表的Merge任务，当天的增量数据与昨天的全量数据进行全外连接，该Merge任务的基本逻辑是：

INSERT OVERWRITE TABLE user_order PARTITION(ds='20211012') SELECT  CASE    WHEN n.id IS NULL THEN o.id                  ELSE n.id 数据;         END         ,CASE    WHEN n.id IS NULL THEN o.create_time                   ELSE n.create_time           END        &nbs同步p;,CASE    WHEN n.id IS NULL THEN o.modified_time                  ELSE n.modified_time           END         ,CASE    WHEN n.id IS NULL THEN o.user_id    &nb方式sp;              ELSE n.user_id           END                  ,CASE    WHEN n.id IS NULL THEN o.sku_code                数仓;   ELSE n.sku_code           END         ,CASE    WHEN n.id IS NULL THEN o.pay_fee                  ELSE n.pay_fee           END FROM   |;  (             SELECT  *             FROM    user_order_delta             WHERE   ds = '20211012'             AND   &nbs 几p; id IS NOT NULL             AND     user_id IS NOT NULL         ) n FULL OUTER JOIN (-- 全外连接进行数据merge                     SELECT  *  &n种常bsp;                  FROM    user_order                     WHERE   ds = '20211011'                     AND &见的nbsp;   id IS NOT NULL                     AND     user_id IS NOT NULL                                  ) o 数据;ON      o.id = n.id AND     o.user_id = n.user_id ; 

经过上述步骤，即可将数据还原完整。

总结

本文首先介绍了数据仓库构建ODS层常见的数据同步方式，并对每种方式进行了解释，给出了相对应的示意图。接着给出了CDC+Merge的数据同步方案。值得注意的是，Flink1.11引入了CDC的connector，比如MySQL CDC和Postgres CDC，同时对Kafka的Connector支持canal-json和debezium-json以及changelog-json的format，通过这种方式可以很方便地捕获变化的数据，大大简化了数据处理的流程和数据同步的复杂度。

• ·AMD宣布拟以19亿美元收购云计算初创公司Pensando
• ·Google 与 Canonical 合作将 Ubuntu Pro 带到 Google Cloud 上
• ·标签: 台铃 两轮电动车
• ·标签: 南亚科技 DRAM SK海力士 Solidigm
• ·标签: 字节跳动 抖音视界 小红书 社媒治理
• ·亚马逊裁员 1.4 万，AI 与自动化迅速崛起
• ·标签: 华为 鸿蒙 昇腾 鲲鹏
• ·京东云交出11.11答卷：每秒用户访问峰值同比提升124%
• ·标签: 张雪机车 重庆张雪机车工业有限公司
• ·​IBM 发布 Granite 4.0 Nano 模型，突破小型 AI 模型的性能极限
• ·标签: VOLANT沃兰特 VE25-100 磊石STONE 红杉中国
• ·搜索算法，一触即达：GitHub上有个规模最大的开源算法库
• ·标签: 钟慧娟 翰森 胡润女企业家榜 蓝思科技
• ·性能最高提升 6.9 倍，字节跳动开源大模型训练框架 veGiantModel
• ·标签: 腾讯 AILab 混元 蒋杰
• ·标签: 西贝餐饮 贾国龙 餐饮行业 个人IP