本文主要是介绍大数据采集方案：mysql-binlog 注意点，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
之前做的比较浅，感兴趣的查阅美团的这篇文章：
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方案技术上没什么特别难点，重点还是运营的坑比较多
这篇关于大数据采集方案：mysql-binlog 注意点的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
