三、数据技术篇—— 数据同步
- 3.1 数据同步基础 @
- 3.1.1 直连同步
- 3.1.2 数据文件同步
- 3.1.3 数据库日志解析同步
- 3.2 数据仓库同步方式
- 3.2.1 批量数据同步
- 3.2.2 实时数据同步
- 3.3 同步遇到的问题
- 3.3.1 分库分表
- 3.3.2 增量全量同步的合并@
- 3.3.3 数据漂移的处理 @
有多种不同应用场景：主数据库和备份数据库之间的数据备份，主系统和子系统的数据更新，不用地域、数据库类型的数据传输交换
3.1 数据同步基础 @
关系型数据库，结构化数据：MySQL、Oracle、DB2
非关系型数据库，非结构化：OceanBase、HBase、MongoDB
对象存储：OSS
文件存储：NAS
| 名称 | 实现方式 |
|---|---|
| 直连同步 | - 通过定义好的规范接口API和基于动态链接库的方式直接连接业务库。 - 配置简单，容易实现，但是对性能影响较大，不太适合。 |
| 数据文件同步 | - 通过约定好的文件编码等，直接从源系统（包含多个异构的数据库系统）生成数据的文本文件，由专门的文件服务器传输到目标系统。 - 由于通过文件上传、下载会造成丢包，且需要上传校验文件（数据量及文件大小） - 可以增加压缩和加密功能 |
| 数据库日志解析同步 | - 日志文件信息丰富，数据格式稳定，通过解析日志文件获取变化的数据，满足增量数据同步需求 - 通过源系统的进程（操作系统层面，不过数据库），读取日志文档中变化并解析道目标数据文件中。 - 网络协议，保障数据文件正确接收、正确数据、网络传输冗余、文件完整性 - 实时和准实时的能力，毫秒级别延迟 - 缺点：数据延迟（补录数据超出峰值）、投入大、数据漂移 |
3.1.1 直连同步
- 通过定义好的规范接口API和基于动态链接库的方式直接连接业务库。
- 配置简单，容易实现，但是对性能影响较大，不太适合。
3.1.2 数据文件同步
- 通过约定好的文件编码等，直接从源系统（包含多个异构的数据库系统）生成数据的文本文件，由专门的文件服务器传输到目标系统。
- 由于通过文件上传、下载会造成丢包，且需要上传校验文件（数据量及文件大小）
- 可以增加压缩和加密功能
3.1.3 数据库日志解析同步
- 日志文件信息丰富，数据格式稳定，通过解析日志文件获取变化的数据，满足增量数据同步需求
- 通过源系统的进程（操作系统层面，不过数据库），读取日志文档中变化并解析道目标数据文件中。
- 网络协议，保障数据文件正确接收、正确数据、网络传输冗余、文件完整性
- 实时和准实时的能力，毫秒级别延迟
- 缺点：数据延迟（补录数据超出峰值）、投入大、数据漂移
3.2 数据仓库同步方式
数据来源的多样性、数据量大
3.2.1 批量数据同步
主要针对于离线类型的数据仓库，定期批量同步。数据仓库系统是集成各类数据源的地方，数据类型是统一的。需要将数据转换为中间状态，统一数据格式，由于是结构化的，支持标准的SQL查询，所以所有的数据类型都可以转换成字符串类型。数据传输全内存操作，不读写磁盘。
3.2.2 实时数据同步
所产生的日志尽快以数据流的方式不断同步到数据仓库，实现秒级别的刷新。（可以通过解析Mysql的binlog日志来实时获取增量的数据更新，通过消息订阅模式来实现数据的实时同步）
3.3 同步遇到的问题
3.3.1 分库分表
为了使系统有灵活的扩展能力和高并发大数据量的处理能力，数据库系统提供分库分表方案。
我们需要一个分布式数据库的访问引擎，通过建立中间状态的逻辑表来整合统一的分库分表的访问。
- 在持久层框架之下，JDBC驱动之上的中间件
- 与JDBC规范保持一致，解决规则引擎问题
- 实现了SQL解析、规则计算、表名替换、选择执行单元并合并结果集的功能
- 解决读写分离和高性能主备切换的问题
3.3.2 增量全量同步的合并@
数据量比较大时，按周期全量同步的方式会影响处理效率。可以每次只同步新变更的增量数据，然后与上一个同步周期获得的全量数据合并，从而获得最新版本的全量数据。
传统的数据整合方案，合并技术以merge方法为主（update+insert），现在大数据平台基本不支持update，比较推荐全外连接（full outer join）+ 数据全量覆盖重新加载（insert overwrite），如日调度。当天的增量数据和前一天的全量数据做全外连接，重新加载最新全量数据。可以采用分区方式，每天保存一个最新的全量版本。
提出了基于负载均衡思想的数据同步方案：
- 通过目标数据库的元数据 估算 同步任务的总线程数
- 系统预先定义的期望同步速度 估算 首轮同步的线程数
- 业务优先级决定同步线程的优先级。
3.3.3 数据漂移的处理 @
数据漂移时ODS数据的一个顽疾，指ODS表中的同一个业务日期数据中包含前一天或者后一天凌晨附近的数据或者丢失当天的变更数据。
为什么会出现呢？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限制，获取到包含一个业务过程所产生的记录，遗漏很多过程变化记录，违背ODS和业务系统保持一致的设计原则
处理方法
- 多获取后一天的数据，向后多冗余一些数据，具体时间按照不同业务场景用业务时间proc_time来限制。但是如果在第二天凌晨修改，这条订单的状态就会更新（可能多次更新），变得不准。
- 多个时间戳字段来限制时间获取相对准确。
举例
双11时，交易订单漂移到12日。因为下单付钱的时候用支付宝的接口有延迟，导致订单最终生产时间跨天了。log_time和modified_time晚于proc_time。
难点：如果订单只有一个支付业务过程，可以用支付时间来限制就能获取正确数据，但是订单有多个业务过程“下单、支付、成功。每个过程都有相应的时间戳字段，并不只有支付才会漂移。
解决方案：
- 根据实际情况获取后一天15分钟的数据，限制多个业务过程的时间戳字段都是双11当天的，按照主键根据log_time做升序排列去重，获取每个订单首次数据变更的那条记录。
- 根据log_time冗余前一天最后15分钟和后一天凌晨15分钟的数据，用modified_time过滤非当天的数据，每个订单按照log_time做降序排列，获取每个订单当天最后一次数据变更的那条记录。
- 两份数据按照订单做全连接，把漂移数据补回当天数据中
