数据源主要为 Mysql，希望实时同步 Mysql 数据到大数据集群中(肯定是越快越好)。

　　目前每日 20 亿数据，可遇见的一段时间后的规模是 100 亿每日以上。

　　能快速地查到最新的数据，这里包含两部分含义：从 Mysql 到大数据集群的速度快、从大数据集群中查询的速度要快。

　　遇到这个场景的时候，根据经验我们主要考虑下面两个点：数据抽取引擎和存储引擎。

　　数据抽取引擎

　　这里我们主要考虑两种方案：

　　Sqoop 定时抽取 Mysql 数据到 HDFS 中，可以每天全量抽取一份，也可以隔段时间就抽取一份变更的数据。

　　Canal 监听 Mysql 的 binlog 日志，相当于是 Mysql 有一条数据久变动，我们就抽取一条数据过来。

　　优缺点的对比也很明显：

　　Sqoop 相对比较通用一些，不管是 Mysql 还是 PostgreSql都可以用，而且很成熟。但是实时性较差，每次相当于是启动一个 MR 的任务。

　　Canal 速度很快，但是只能监听 Mysql 的日志。

　　存储引擎

　　存储引擎主要考虑 HDFS、Hbase 和 ES。

　　一般情况下，HDFS 我们尽量都会保存一份。主要纠结的就是 Hbase 和 ES。本来最初是想用 Hbase 来作为实时查询的，但是由于考虑到会有实时检索的需求，就暂定为ES

　　使用 Canal 来实时监听 Mysql 的数据变动

　　使用 Kafka 作为消息中间件，主要是为了屏蔽数据源的各种变动。比如以后即使用 Flume 了，我们架构也不用大变

　　数据落地，有一份都会落地 HDFS，这里使用 Spark Streaming，算是准实时落地，而且方便加入处理逻辑。

下一篇

ODS有的公司说几乎不处理，有的说这一层要做第一次数据清洗，你怎么看？