概要
在大数据时代，数据研发人员总是想把各类数据采集到我们的数据仓库。最典型的方案是日志收集方案： flume采集文件，转发到kafka，再使用storm、spark写到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方案技术上没什么特别难点，重点还是运营的坑比较多
参考资料：
https://blog.csdn.net/u013128262/article/details/80040310
