之前做的比较浅，感兴趣的查阅美团的这篇文章：
https://tech.meituan.com/2018/12/06/binlog-dw.html

概要

在大数据时代，数据研发人员总是想把各类数据采集到我们的数据仓库。最典型的方案是日志收集方案： flume采集文件，转发到kafka，再使用storm写到hdfs。但是实际场景中，我们的数据源不止文件，还有mysql这类db数据。

众所周知，mysql是可以开启binlog的，也就是说我们对db的每个操作都可以通过binlog解析得到。所以我们实时解析mysql的binlog文件，即可实时获取到db的各个变更事件，就可以实时地将insert的数据，像tail日志文件一样，以规范化的形式发送到我们后端的消息中间件。

本文不会拘泥于实现细节，只会列举几个注意点，避免后续人采坑。

注意点

• binlog row模式
  最需要支持的点：
  mysql必须支持binlog，且必须是row模式。需要关注几个问题：
  1.row模式的binlog是远大于其他模式，需要注意磁盘容量
  2.从其他模式binlog（如mix）改为row模式，需要断开已有mysql的连接，需要dba及相关业务开发评估可行性。
  3.不需要采集的库表要独立出去，不然大量无关binlog会影响采集器的性能，堵塞通道。（需要推动业务改）
  4.row模式下日志变多，还有从库解析方式发生变化，可能会造成主从不一致（状态延迟）的情况，需要dba确认

• 支持的语句
  不支持DDL，只是inset最好，就类似文件的append。update、delete都会增加后端的处理逻辑。

• 事务支持
  本身就是用于大数据处理的，不支持事务

• 字段问题
  建议末尾追加字段，只用简易字段（int，string）

总结

binlog方案技术上没什么特别难点，重点还是运营的坑比较多