使用Dataworks完成数仓的离线全量+实时增量ETL可以有多种具体实现方案。笔者进行了多种实践，也大概了解到各种实践方案的优缺点。回忆当时，如今满脸泪水。当时主管让我开发一个按小时统计的离线计算，使用数仓完成。经过技术调研，发现阿里的Dataworks的实时同步解决方案开发量最少，因此采用该方案开发。
Dataworks实时同步解决方案：通过在Dataworks实时同步解决方案一键式配置并发布。遗憾的是，该方案要求数据库表存在主键id，除此以外该方案生成了大量节点，且默认节点名称确实不优雅，管理起来很难受,同时该方案无法给表额外增加etl_time字段（ods数据质量的及时性校验需要使用该字段）。不过最终剔除这个方案的原因是：该方案生成的小时任务被阿里下线了(据说有Bug)，后续我们改用了DTS实时同步解决方案。使用后的感悟：阿里太强大了，不过从数仓角度说，如果阿里都做好了，我们是不是就要失业了....
DTS实时同步解决方案：如果说上个方案是飞机大炮的话，那么这个方案就轻量化多了。DTS解决方案通过配置完成了全量数据的首次同步+增量数据的实时同步，最后由数据开发人员通过SQL完成全量+增量数据的合并。那我们最终没有坚持这个方案的原因有2。1是DTS必须要全部由DBA配置，每次接入数据都需要联系DBA，不是特别方便(这个理由在其他公司可能不成立)。2是DTS默认生成的全量表没有快照分区，同时我们没法增量额外字段如数据的etl_time，这让我们很难接受，基于这个理由我们又发现DTS太贵了-。-，从而废弃了该套方案。
Dataworks实时同步+离线同步方案：第一步我们使用Dataworks的实时同步任务，将mysql-binlog日志映射到自动生成的增量maxcompte表里,接着我们修改maxcompute增量表的ddl语句创建全量表。第二步创建离线同步任务，将数据全量同步到全量表中。第三步创建数据合并任务，定时将增量数据与全量数据合并，重写到全量表中，在数据合并的SQL中我们可以将etl_time字段设置为systime。最终选择了这套方案，可以理解是干的工作最多，但最灵活的了，后期SQL的优化，包括超级大表数据的归档、数据漂移等问题都可以想办法解决了。这里需要注意的是一定是首先进行数据的实时同步再进行数据的离线同步，并且在一个周期内上线数据合并任务。
