【数仓】数据同步-数据仓库的数据来源之二

  数据仓库的数据最主要的来源有两个，一是前面讲过的日志采集，将前端埋点产生的 log 文件解析之后存入数据仓库。而今天要讲解是另外一部分数据——数据库数据同步。这一部分主要是将数据库中的业务数据同步到数据仓库。当然这只是数据同步的一个方面，数仓中计算好的数据也会同步进入数据服务或数据应用两个方面。本文参考《大数据之路》，对书中的要点进行记录。可以关注公众号回复 802 获取 pdf。其他章节更新中。可以点击这里查看其他章节。

1.数据同步基础

  数据同步的原业务系统的数据类型多种多样，主要分为关系型数据库的结构化数据和非关系型数据库的非结构化数据，这两类数据库包括：

• 关系型数据库：MySQL，Oracle，DB2，SQL Server 等；
• 非关系型数据库：OceanBase，HBase，MongoDB 等；
• 文件系统：阿里云对象存储 OSS，文件存储 NAS 等。

同步的方式可以分为三种：

• 直连同步
• 数据文件同步
• 数据库日志解析同步

1.1 直连同步

方法：通过定义好的规范接口 API 直接连接数据库。比如 JDBC 等同一规范的标准接口。

优点：配置简单，容易实现。

缺点：对源系统性能影响大，大批量数据同步时肯能拖垮业务系统，并且性能较差，不适合业务系统到数据仓库系统的同步。

1.2 数据文件同步

方法：直接将源系统的数据文本文件（数据库底层其实也是一些文件）通过专门的文件服务器（例如 FTP 服务器）传到目标系统，然后按照数据文件的编码格式进行解码并加载到目标数据库系统。

优点：数据源包含多个异构的数据库时比较简单实用。另外日志类数据也是以文本形式存在，也适合使用数据文件同步方式。

补充：文件上传下载可能丢包或错误，为保证完整性，还会有一个校验文件。传输中可以通过压缩和加密提高效率和安全性。

1.3 数据库日志解析同步

方法：数据库的大多都可以通过日志文件记录了增、删、改等操作，必要时用于进行系统恢复。于是可以通过读取数据库的日志文件，判断日志中的变更是否属于被收集的对象，将其解析到目标数据文件中。

优点：操作系统层面完成，不通过数据库，不会给源系统带来影响。

缺点：

• 数据延迟：业务系统批量补录使数据量超过系统处理峰值导致延迟；
• 投入较大：需要在源和目标之间部署系统实时抽取数据；
• 数据漂移和遗漏：同一个业务日期数据中包含前一天或后一天凌晨附近的数据或丢失当天的变更数据。

2.数据同步的问题和解决方案

2.1分库分表的处理

问题：业务系统为了处理高并发，采用了分库分表的方案，增加了数据同步的复杂度。

解决：建立中间状态的逻辑表来整合分库分表的访问。

2.2 高效同步和批量同步

问题：重复操作，和数据需求方的沟通成本。

解决：透明化配置，自动生成配置信息；配置、发布、测试一键化处理；降低数据同步的技能门槛，方便数据需求方使用。

2.3 增量与全量同步的合并

问题：数据量越来越大，全量同步效率低甚至不可能做到。

解决：增量同步，然后合并。大数据平台不支持 update 操作，因此使用全外连接（full outer join）+数据全量覆盖重新加载（insert overwirte）。例如日调度，则将当天的增量数据和前一天的全量数据做全外连接，重新加载新的全量数据。

2.4 同步性能的处理

问题：总线程数达不到用户设置的首轮同步线程数；不清楚如何设置线程数；重要程度不同的数据分配线程时平等对待，导致重要数据得不到 CPU 而无法同步。总结：数据同步任务不稳定。

解决：负载均衡思想的同步方案，核心思想是通过目标数据库的元数据估算同步任务的总线程数，并通过优先级决定同步线程的优先级。

2.5 数据漂移的处理

问题：ODS 层数据表的同一个业务日期数据中包含前一天或后一天凌晨附近的数据，或丢失当天的数据。例如，时间戳有四类：

• 数据库表中更新时间 modified_time
• 数据库日志中的更新时间 log_time
• 数据库表中业务发生的时间 proc_time
• 数据记录被抽取到的时间 extract_time

理论上这些时间应该一致。实际上会有差异，原因：

• 数据抽取需要时间，extract_time 最晚
• 前台业务系统手工订正数据未更新 modified_time
• 由于网络或系统压力问题导致 log_time 和 modified_time 会晚于 proc_time

下面的做法导致不同的问题：

• 根据 extract_time 获取数据，数据漂移最明显
• 根据 modified_time 限制，导致数据遗漏，或者凌晨时间的数据漂移到后一天
• 根据 log_time 限制，由于网络或系统压力导致凌晨时间的数据漂移到后一天
• 根据 proc_time 限制，获取的数据只包含一个业务过程产生的记录，遗漏了其他过程的变化记录，违背了一致性

解决：

• 多获取后一天的数据，保证只多不少。
  • 具体数据的切分根据下游业务场景不同选择业务 proc_time 来限制。
  • 缺点：存在误差。例如当天支付，第二天凌晨退款关闭订单，那么这条记录的订单状态会被更新，下游统计支付订单状态时出错。
• 多个时间戳字段限制。
  • 首先根据 log_time 冗余前一天15 分钟和后一天 15 分钟的数据，用 modified_time 过滤非当天数据。
  • 然后针对后一天 15 分钟的数据按照主键根据 log_time 升序去重，根据主键获取最后变化的数据。
  • 将前两步得到的数据做全外连接，限制业务时间 proc_time 来获取数据。

欢迎关注公众号。