datax到hive数据全部为空_DataX在有赞大数据平台的实践

一、需求

有赞大数据技术应用的早期，我们使用 Sqoop 作为数据同步工具，满足了 MySQL 与 Hive 之间数据同步的日常开发需求。

随着公司业务发展，数据同步的场景越来越多，主要是 MySQL、Hive 与文本文件之间的数据同步，Sqoop 已经不能完全满足我们的需求。在2017年初，我们已经无法忍受 Sqoop 给我们带来的折磨，准备改造我们的数据同步工具。当时有这么些很最痛的需求：

多次因 MySQL 变更引起的数据同步异常。MySQL 需要支持读写分离与分表分库模式，而且要兼容可能的数据库迁移、节点宕机以及主从切换

有不少异常是由表结构变更导致。MySQL 或 Hive 的表结构都可能发生变更，需要兼容多数的表结构不一致情况

MySQL 读写操作不要影响线上业务，不要触发 MySQL 的运维告警，不想天天被 DBA 喷

希望支持更多的数据源，如 HBase、ES、文本文件

作为数据平台管理员，还希望收集到更多运行细节，方便日常维护：

统计信息采集，例如运行时间、数据量、消耗资源

脏数据校验和上报

希望运行日志能接入公司的日志平台，方便监控

二、选型

基于上述的数据同步需求，我们计划基于开源做改造，考察的对象主要是 DataX 和 Sqoop，它们之间的功能对比如下

功能

DataX

Sqoop

运行模式

单进程多线程

MapReduce

MySQL读写

单机压力大；读写粒度容易控制

MapReduce 模式重，写出错处理麻烦

Hive读写

单机压力大

扩展性好

文件格式

orc支持

orc不支持，可添加

分布式

不支持，可以通过调度系统规避

支持

流控

有流控功能

需要定制

统计信息

已有一些统计，上报需定制

没有，分布式的数据收集不方便

数据校验

在core部分有校验功能

没有，分布式的数据收集不方便

监控

需要定制

需要定制

社区

开源不久，社区不活跃

一直活跃，核心部分变动很少

DataX 主要的缺点在于单机运行，而这个可以通过调度系统规避，其他方面的功能均优于 Sqoop，最终我们选择了基于 DataX 开发。

三、前期设计

3.1 运行形态

使用 DataX 最重要的是解决分布式部署和运行问题，DataX 本身是单进程的客户端运行模式，需要考虑如何触发运