在大数据时代，无论是电商、社交、大文娱、广告等互联网领域，还是日活百万级别的互联网应用，很多场景的核心服务日均生产和消费数据都在数亿级别。而在一家小而美的互联网公司做研发时，可能你所负责的服务每天生产和消费的数据仅仅在百万级别或更少。

在生产和消费的数据量在百万级别或更低时，无论是数据存储引擎，还是数据同步组件，主流的技术方案在使用过程中性能是非常稳定的。然而，如果数据量增长到数十亿级别的时候，服务的整体技术架构就会面临可用性和稳定性的挑战了。

在面临这种挑战的时候，我们自然而然要面对多种异构数据源的海量数据同步问题。但是，目前市面上有应对海量数据存储的NoSQL存储引擎（如：MongoDB、Elasticsearch、Cassandra、TSDB、Clickhouse等），也有应对海量数据离线和实时计算的计算引擎（如：Spark、Sparking Streaming、Flink等），还有应对OLAP场景联机分析处理能力的系统（如：Hive、Presto、Kylin、SparkSQL、Druid、Clickhouse等），就是没有负责多种异构数据源海量数据同步的技术产品。

而这就是我想在小册中和大家一起探讨的。

我叫甘罗（笔名），是一名在互联网行业从事了近十年后端研发工作的程序员，现任职于贝壳找房商业化团队，是广告中台技术负责人，负责贝壳C端广告流量分发、分发策略编排引擎、策略智能推荐、广告物料离线和实时计算、物料数据同步与检索、流量数据回收、流量风险识别与治理等中台能力建设工作，有近5年架构师和技术负责人相关经验。

我所带领的团队主要负责 C 端广告流量分发、分发策略编排、物料数据同步与检索、数据回收等基础能力，作为一个中台为公司 20+ 的业务接入方提供广告分发服务。在提升接入效率的同时，我们需要保证服务的稳定性和高可用。

2020 年，我们的核心服务遇到了前所未有的挑战。当时平台流量从 3 亿 PV 增长到峰值 12 亿 PV，流量分发涉及的物料数据达 10 亿级，物料检索 QPS 达 6W+。这就导致生产环境频繁间歇性 499 报警，线上数据库频繁慢查询并触发熔断降级，核心服务稳定性也从 4 个 9 降到 3 个 9。

经过排查后发现，MySQL 和 MongoDB 在亿级数据下高频查询的性能比较差。考虑到 MySQL 索引优化效果不明显，分库分表改造成本高；MongoDB 无法支持全文索引、数据路由等情况，在对业界主流的存储引擎（TiDB、Druid、Hazelcast、ClickHouse）经过充分的真实场景性能压测之后，我们决定将底层存储引擎统一切换为 Elasticsearch，以此支撑数十亿级物料数据的高频低延迟检索服务。

成功搭建 Easticsearch 集群后问题来了，如何把原来存储在 MySQL、MongoDB、Hive 中的数十亿离线数据无缝迁移到 Elasticsearch 集群呢？Kafka 中的实时数据如何无缝同步到 Elasticsearch 集群呢？

如果只是数据量大，那么通过开发数据同步调度任务进行迁移的成本到还不大。不过，我们的物料数据存在以下特点：

• 涉及 20+ 业务方的 100+ 份数据，最大的接入方数据量达 4 亿；

• 底层的存储系统异构，主要有 MySQL、MongoDB、Hive、Kafka；

• 物料数据更新场景复杂，有每日一次从 Hive 到 MySQL/MongoDB 的 T+1 离线数据更新场景，也有消费 Kakfa 流的实时数据更新场景，还有提供 API 给业务接入方实时写入的场景；

• 不同接入方的数据时效性不同，数据版本生命周期管理复杂。

以上这些特点无疑给数据同步增加了不少难度，对业界主流数据 ETL 技术方案（DataX、Maxwell、Spark、Flink）充分调研和技术验证，类DataX 或 Maxwell 开源方案，不是支持数据源单一，就是扩展性差，而 Spark 和 Flink 是当下大数据领域离线和实时计算的利器，核心能力在计算，而对于数据迁移同步和轻量级ETL场景属于大材小用，且针对异构数据的迁移缺少通用组件，需要维护无数的调度任务，且需要引入 Spark 或 Flink 计算集群，对于数据迁移场景来说比较重，不但浪费机器资源，还带来了集群维护成本。从集群维护成本、接入成本、扩展性、数据生产和消费的吞吐能力、监控体系等几个方面考虑，最终我们选择基于 Kafka Connect 构建异构数据双向流式同步服务。

目前，我们基于 Kafka Connect 自建的异构数据双向流式同步服务运行着 100+ Source 和 Sink Connectors 集群，覆盖 MySQL、MongoDB、Hive、Elasticsearch、Kafka 多种异构存储引擎，日均处理离线和实时数据量级 10+ 亿，异构数据源之间数据流转吞吐 TPS 轻松支持 20+ W，基于开源 Connectors 和 Transforms 组件定制开发支持一些特定数据迁移场景，如：数据路由、轻量级流式数据处理等。

此外，我们还定制开发了 Kafka Connect 集群控制台，除了满足日常 Connectors 集群管理，还实现了数据同步任务从异构数据接入，到选择数据清洗规则，到选择写入数据源的全流程自助接入，真正实现了零开发即可新建异构数据流式同步 Connectors 集群。

而目前开源社区提供的 Source 和 Sink Connectors 有上百个，覆盖了主流的存储引擎，真正做到了开箱即用，所有的这一切只需要依赖 Kafka 集群即可完成。Kafka Connect 分布式模式依赖 Kafka 作为数据通道，可以支持方便地创建和管理数据流管道。它为 Kafka 和其他系统创建规模可扩展、高可靠的流数据提供了一种简单的架构实现，通过 Source Connectors 可以将多种异构存储系统的海量数据导入到 Kafka 中，也可以使用 Sink Connectors 从 Kafka 中将流数据导出到多种异构存储系统中。

这个过程中，我们踩过很多坑，也总结出了很多最佳实践，我希望在小册中把它们分享给你。

基于此，小册将划分为7个模块，从当前主流的各种数据同步框架选型，到基于 Kafka Connect 开源生态到搭建新的数据流式双向同步新架构，再到定制开发异构数据双向流式同步 Connector 组件。

最终，你不仅能收获一个工业级可用、可伸缩扩展、易接入维护的支撑日均处理数十亿级海量异构数据的双向流式处理平台，还能在面对海量数据的同步和清洗工作时，更加游刃有余！

总的来说，你将获得：

• 面对海量异构数据的通用流式处理技术方案和架构设计

• 一个工业级可用、可扩展、易维护的多种异构数据双向流式处理平台

• 掌握 Kafka Connect 作为异构数据流式处理的新架构

• 掌握 MySQL 和 MongoDB 底层存储机制，以及CDC 机制的架构理念和适用场景

• 掌握 MySQL binlog 的底层原理，并能实现基于 binlog 的数据同步组件

• 掌握 MongoDB oplog 的底层原理，并能实现基于 oplog 的数据同步组件

• 掌握 Elasticsearch 分片、路由、管道、根据时间序列滚动创建索引、索引模板和版本管理等高阶操作

• 掌握 Source 和 Sink Connectors 的架构实现，并能自定义开发通用的 Connectors 组件

• 掌握 Transforms 的架构设计理念，并能自定义开发轻量级 ETL 组件

• 深入理解 Kafka 的核心特性设计理念和实践

• 掌握基于 JMX、Prometheus Exporter、Grafana 一站式的指标收集和监控体系搭建

最后我想说，随着 Kafka Connect 生态的持续壮大，我相信它一定会成为大多数互联网公司相识业务场景的通用解决方案。因此，无论你是后端研发、大数据研发还是架构师，小册的内容都将成为你的加分项！