引言

在大数据系统中，我们往往无法直接对在线系统中的数据直接进行检索和计算。在线系统所使用关系型数据库、缓存数据库存储数据的方式都非常不同，很多存储系统并不适合分析型（OLAP）的查询，也不允许分析查询影响到在线业务的稳定性。从数仓建设的角度思考，数据仓库需要依赖于稳定和规范的数据源，数据需要经过采集加工后才能真正被数仓所使用。推动数据同步服务的平台化，才有可能从源头规范数据的产出。数据同步服务不像数据挖掘一样可以直接产生价值，但它更像是连接在线系统和离线系统的高速公路，好的同步工具可以很大程度上提升数据开发的效率。

本文主要介绍知乎在数据同步这方面的建设，工具选型和平台化的实践。

业务场景及架构

由于在线业务的数据库在知乎内部还是以 MySQL 为主，在数据同步的数据源方面主要考虑 MySQL 和 Hive 的互相同步，后续可以考虑支持 HBase。早期数据同步使用 Oozie + Sqoop 来完成，基本满足业务需求。但是随着数据同步任务的不断变多，出现了很多重复同步的例子，对同步任务的负载管理也是空白。凌晨同步数据高峰导致 MySQL 不断报警，DBA 苦不堪言。对于业务来说，哪些表已经被同步了，哪些表还没有也是一个黑盒子，依赖其他业务方的数据都只能靠口头的约定。为了解决这些问题，决定对数据同步做一个统一的平台，简化同步任务的配置，调度平衡负载，管理元信息等等。到现在为止，数据同步平台支撑了上千张表的同步，每天同步的数据量超过 10TB。

技术选型

数据同步工具市面上有很多解决方案，面向批的主要有 Apache Sqoop 和阿里开源的 DataX，其他商业的数据同步工具不在本文讨论范围。下面主要对比这两种数据同步工具。

Sqoop

Pros：

Cons：

DataX

Pros：

Cons：

考虑到同步本身要消耗不少的计算和带宽资源，Sqoop 可以更好的利用 Hadoop 集群的资源，而且和 Hive 适配的更好，最终选择了 Sqoop 作为数据同步的工具。

平台化及实践

平台化的目标是构建一个相对通用的数据同步平台，更好的支持新业务的接入，和公司内部的系统集成，满足业务需求。平台初期设计的目标有以下几个：

整体系统架构如下图：

API Server 用于提供用户界面和 RESTFul API。数据源中心存储数据源信息，并从真实的数据源定期更新，保持比较新的数据。Scheduler 负责规划任务的执行资源，保护 MySQL 集群避免负载过高。Worker 真实的执行任务，分布在多个节点上。

简化任务接入

平台不应该要求每个用户都理解底层数据同步的原理，对用户而言，应该是描述数据源 (Source) 和目标存储 (Sink)，还有同步周期等配置。所有提供的同步任务应该经过审核，防止未经许可的数据被同步，或者同步配置不合理，增加平台负担。最后暴露给用户的 UI 大概如下图。

增量同步

对于数据量非常大的数据源，如果每次同步都是全量，对于 MySQL 的压力会特别大，同步需要的时间也会很长。因此需要一种可以每次只同步新增数据的机制，减少对于 MySQL 端的压力。但是增量同步不是没有代价的，它要求业务在设计业务逻辑和表结构的时候，满足下面任意条件：

如果满足上面条件，数据量比较大的表就可以采用增量同步的方式拉取。小数据量的表不需要考虑增量同步，因为数据和合并也需要时间，如果收益不大就不应该引入额外的复杂性。一个经验值是行数