开始之前，先聊下企业数据的整体架构吧。一般来说，业务系统的数据库有较大的生产压力，大多数的做法是在企业生产库后会追加1到2个只读库，负责实时同步主库数据。业务系统写入到只读库，查询数据从从库。同时为了减轻成本压力，从库不提供binlog日志能力。

阿里巴巴的Dataworks作为一站式数据开发和数据治理的PASS平台，提供多样的数据集成能力，甚至提供了数据集成的解决方案。为完成数仓的ODS层的建设，存在离线全量ETL、离线增量+离线全量的ETL、实时增量+离线全量ETL、实时增量ETL4种方式。这里我们从技术上进行简单拆解，最终选择一个较为合适的方案，为简化起见我们的源端是RDS，即mysql数据库。

离线全量ETL：即使用Dataworks离线集成方式，配置源端mysql通过每日将全量数据抽取，并重写到ODS表，这种方式也叫"直连"方式。通过直连源端(一般都会选择从库-.-，没有从库的话请运维同事构建吧，主库拉挂了就可以祭天了)的方式，对于一般小表来说(即整体看该表整体数据量比较固定，日增量较少，如组织架构表)这种方式是可行的，且操作简单。遗憾的是：每日固定时间拉取的表数据，严格来说并不是某一个时间点的实际真是快照。如定时每天00:00:00同步数据，但实际任务调度时会因调度资源争夺等原因造成数据同步延迟(0点存在大量数据同步任务)，实际落地到ODS的数据并非是00:00:00的快照。同时由于ODS数据同步的延迟，导致下游任务会停滞一段时间，数据的计算结果也会延迟一定时间，使用该方式之前需要从业务角度综合分析。对于大表来说，该方式有点慢性自杀的感觉，数据同步慢，下游计算延迟，拉挂了只读库会不会祭天我不知道，我只知道工作还得做，数据计算还得补回来，怎么解决呢？可以试试使用“离线增量+全量的ETL”的方式。

离线增量+离线全量的ETL:在特定情况下，如解析FTP文件日志、TableStore增量日志时该方案是最佳方案，也可以处理关系型数据库RDS的场景，如对大表(如订单表，每天增量100w+)可以考虑首次进行数据的全量同步到MaxCompute里的全量表table_full，后续接入每日增量的数据同步到MaxCompute的增量表table_inc,在MaxCompute里完成数据合并并重写到table_full的最新分区里。具体实践：源端Mysql定义modify_time，数据每次修改会插入时都会更新该字段。定时抽取源端数据时增加过滤条件modify_time>start_time  and modify_time<end_time将ETL的数据写入ODS增量表的分区里，再与ODS全量表最新分区数据进行合并，并重新写入到一个新的分区数据里。遗憾的是：该方式对于源库来说相当于每次扫描一次全表（可以使用索引优化）对源库也存在一定的性能压力。源端进行了历史数据的物理删除的话，数据合并时无法感知，因此需要先与业务应用系统确定数据是否存在物理删除场景。怎么解决呢？可以试试使用"实时增量+离线全量ETL"的方式。

实时增量+离线全量ETL:工作原理与上述相同。唯一不同的是通过Mysql-binlog日志的方式实时写入，通过解析binlog日志里的日志时间戳，将该时间戳转为maxcompute增量表的分区字段，并根据日志的变更类型(新增、修改、删除)、日志顺序(record_id)与全量表进行数据合并。该方案的解决了离线全量ETL中数据快照不精确的问题，并可以感知到源端数据库物理删除数据的场景，可以说是相当完美的方案了，这也是我实践的方案，后续整体会围绕该方案细说。然而该方案对数据开发人员的技术要求较高。 如何采集binlog日志，如何进行数据合并，阿里Dataworks已有了解决方案，下一章我将会细说这块"数据集成之实时增量+离线全量ETL详解"。

实时增量ETL：严格上来说，该方案是上个方案的子集，单拎出来主要基于业务考虑。数据计算场景需要获取源端完整数据的场景请使用上个方案。部分场景可能只需要关心当前增量的数据，不关心历史数据的只需要进行实时增量ETL。数据源也会多样化如mysql-binlog、rockmq等等。数据的老化策略也会不同。这块后期文章里会详细说明。

喜欢的朋友请帮忙点赞，谢谢大家！