数据同步方式很多，此次讨论不包括桌面应用方面同步工具（如：kettle）

    数据同步v1.0
    使用Sqoop进行sqlserver数据源同步到Hbase，以sqlserver的表主见id作为Hbase表rowkey字段。
    优点：

    1. 满足当时接入的第一个项目到数据中台中，当时第一个用户项目是sqlserver实现的
    2. 非常适合关系性数据库作为源，导入Hbase或Hive中这种场景
    3. 基于MR的，数据吞吐能力十分高
    4. CDH集成了Sqoop2.0，不需要额外搭建维护组建

    缺点：

    1. 主要用于基于HDFS和关系性数据库之间的数据同步，支持的数据源不如DataX丰富，基于未来的数据中台考虑，不太适合；
    2. 任务调度还是基于LInux的cron（写好Sqoop的.sh脚本，然后linux调度），需要额外管理。另外离线作业调度必须先数据同步再计算，此处两个任务调度没有同步机制约束；

    数据同步v2.0
    使用DataX替换Sqoop，实时计算那块接入的第二个项目是mysql作为业务数据库，使用cannal进行实时同步；
    优点：

    1. 支持实时同步
    2. DataX支持的数据库更多，对于未来开发一个数据同步系统作为底层核心组件，更适合

    缺点：

    1. 实时仅支持mysql，cannal本身利用binlog实现
    2. 任务调度还是基于Linu的cron，存在任务调度异步的问题

    数据同步v3.0
    使用Spark SQL，跑批作业替代DataX；数据实时同步方案，如果是非Mysql的话，需要业务数据库进行数据增删消息投递到Kafka；
    优点：

    1. 自己写同步代码，对于一些复杂映射关系，单写SQL很难实现或实现起来很复杂，可读性不强
    2. 离线跑批是通过Azkaban作为任务调度器的，支持同步方式任务调度
    3. 实时那块通过投递到消息队列实现对业务数据库最小的影响。
      1. 解藕
      2. 降低业务方的可靠性影响
    4. 支持的数据源丰富
    5. 代码集成在gitlab同个仓库下，管理方便