数据库数据采集

常见的三种采集方案

• 直连同步

  • 通过API和动态链接同步数据库数据，会对源数据库产生较大影响。不建议直接同步主数据库

• 

   

• 数据文件同步

  • 同步源系统生成的文本文件。

    • 文本文件一般由单独的服务器存储

    • 为了保证数据质量，处理源数据，还需要校验文件

  • 

     

• 数据库日志解析同步（一般采用此种方式）

  • 通过同步、解析数据库日志文件系统进行数据同步。可以实现毫秒级延迟且对数据库影响小。

• 

   

一般通过主键去重，按照时间更新顺序抽取最近一条数据。

按照是否保留删除数据，可分为三种方式：

• 全量保留数据（一般采用此种方式，使用时根据是否删除标志，判断数据是否有效）

  • 数仓ODS为满足不同分析场景诉求，需要保存全量数据，下游根据实际使用情况进行判断。如，区域维表中某些区域信息已经不在维护，但是在另外的某些全量表中，查看历史周期数据时扔需要用到该区域的信息（如name等），则仍然需要已经删除的数据。

• 剔除删除的最后一条数据

• 若同一主键在变更中有删除操作，则剔除该主键的所有数据

数据同步的关键点

批量数据同步关键点

• 需要将所有不用数据源转换成统一格式且可支持SQL查询。

实时数据同步关键点和工具

• 订阅数据库binlog日志实时获得增量数据，通过类似kafka的中间件进行处理

数据同步中的常见问题

• 采集中如何处理MYSQL中的分库分表

  • 主流数据库一般采用分库分表涉及，采集中需要一个中间层将不同表的数据汇聚到一起进行采集

    • 如，产研的数据库根据不同区域进行分表，采集时不关注不同区域底表，只抽取同一个库下相关联的汇总表

 

 

如上图所示，阿里通过中间件TDDL实现。TDDL位于JDBC之上

• 增量与全量同步的合并

  • 周期全量同步。效率低，一般只有数据量很小的情况下才会使用此方案（建议小于1000W行）。如关系映射表

  • 同步增量数据，与上一个同步周期的全量数据进行merge。

    • 由于主流大数据平台不支持update，一般采用full outer join + insert onverwrite的方式实现。

    • 同时为了解决数据更新错误，一般会保留多个分区。（当全量ods下游建设不完善时，生命周期不建议设置过短。否则新的中间层回溯历史数据进行初始化时，会受限于ods的tag无法回溯过早的分区）

• 同步性能问题（解决同步线程数）

  • 通过数据库估算的数据量结合期望完成的同步时间+优先级设定线程数

• 数据漂移问题

  • 数据漂移定义：在同一天的分区数据中，包含前一天或后一天的数据（数据多）或丢失应该在当天分区中的数据（数据少）

  • 数据漂移引起的原因：数据同步到ODS时，需要根据时间戳进行切分截取。当时间戳不准时，会导致数据漂移。

  阿里的处理方案：

  • 阿里方案前提：底层需要由对应的数据字段支持

    1. 数据库中存在用来标识整条数据更新的时间戳。设：modify_time

    2. 数据库中存在用来标识数据日志更新的时间戳。设：log_time

    3. 数据库中存在用来标识某一个业务过程实际发生的时间戳。设：pro_time

    4. 存在标识数据被抽取的时间戳。设：extract_time

  • 理论上上述字段数值应该一致，实际上

    • 抽取需要时间extract_time晚于上述3个字段

    • modify_time未更新

    • modify_time或log_time晚于pro_time

  • 根据单个时间戳限制

    1. 根据modify_time限制：可能由于modify_time未维护或更新晚，数据漂移到后一天导致数据丢失。。

    2. 根据log_time限制：可能由于log_time更新晚，数据漂移到后一天导致数据丢失。

    3. 根据pro_time限制：根据某个业务过程的pro_time限制，可能会丢失其他业务过程的数据。如根据订单创建时间限制，丢失支付完成时间数据

    4. 根据extract_time限制：extract_time产生最晚，数据漂移现象最明显。

  • 实际方案

    1. 根据log_time冗余前一天15分和后一天15分数据，并根据modify_time过滤非当天数据

    2. 根据log_time冗余后一天15分数据，并对数据按照主键去重同时根据log_time进行升序排列，取到最接近当天的数据

    3. 对1、2两步的数据进行全外链接，通过限制pro_time时间获取所需数据。

  • 示例（粘贴的书上原话）

  •  

  注释：

  1. 冗余后一天数据，并在限制多个业务的pro_time后，对数据按modify_time做升序排列取最后一条数据比较容易理解。（相当于取到了漂移到了后一天的数据，同时过滤掉了在次日更新的脏数据）

  2. 此外还要冗余前一天最后15分和后一天开始的凌晨15分数据，根据modify_time过滤非当天数据，再对过滤后的数据根据Log_time降序排列，取最后一次变更的数据。此处不是特别容易理解。

  实际情况的处理方案：

  对于大多数公司来讲（非京东、阿里等存在双11双12等类似情况）：

  1. 业务关注

     • 延长采集时间：将下个采集周期的部分数据写入到当前分区。

       • 如：用户12月1日23:59:59发起了订单，12月2日00:01:16支付了订单，如果希望两次行为产生的数据都能落到hive表23点的分区，就可以配置5min的延长采集时间。同时采集时通过where条件，过滤部分脏数据。

     • 注意：

       • 此方法的延长时间最好与业务方达成一致。

  2. 业务不关注（大多数情况）：

     • 数据漂移数据量极小，一般情况下不影响整体分析决策。在抽取数据到ODS时，统一抽取方式，即按照整点（如0点）的数据进行分割。超过0点的算第二天的。各个业务域收口自己业务域的数据，与业务方达成一致，同时不同业务域的抽取方式相同，整体数仓的数据一致性和数据质量都能得到保障。

       • 如：12月1日用户23:59:59发起了订单，12月2日00:01:16支付了订单。每天只看当天支付完成了的订单，则该笔订单数据算到12月2日。（整体数据并未丢失，和业务方达成一致，各个域达成一致，统一口径，数据质量可以得到保障）