概要
在大數(shù)據(jù)時(shí)代举畸，數(shù)據(jù)研發(fā)人員總是想把各類數(shù)據(jù)采集到我們的數(shù)據(jù)倉庫查排。最典型的方案是日志收集方案： flume采集文件，轉(zhuǎn)發(fā)到kafka抄沮，再使用storm跋核、spark寫到hdfs。但是實(shí)際場景中叛买，我們的數(shù)據(jù)源不止文件砂代，還有mysql這類db數(shù)據(jù)。
眾所周知率挣，mysql是可以開啟binlog的刻伊，也就是說我們對db的每個(gè)操作都可以通過binlog解析得到。所以我們實(shí)時(shí)解析mysql的binlog文件椒功，即可實(shí)時(shí)獲取到db的各個(gè)變更事件捶箱，就可以實(shí)時(shí)地將insert的數(shù)據(jù)，像tail日志文件一樣动漾，以規(guī)范化的形式發(fā)送到我們后端的消息中間件丁屎。
注意點(diǎn)
binlog row模式
最需要支持的點(diǎn)：
mysql必須支持binlog，且必須是row模式旱眯。需要關(guān)注幾個(gè)問題：
1.row模式的binlog是遠(yuǎn)大于其他模式晨川，需要注意磁盤容量
2.從其他模式binlog（如mix）改為row模式，需要斷開已有mysql的連接删豺，需要dba及相關(guān)業(yè)務(wù)開發(fā)評估可行性共虑。
3.不需要采集的庫表要獨(dú)立出去，不然大量無關(guān)binlog會影響采集器的性能呀页，堵塞通道妈拌。（需要推動業(yè)務(wù)改）
4.row模式下日志變多，還有從庫解析方式發(fā)生變化蓬蝶，可能會造成主從不一致（狀態(tài)延遲）的情況供炎，需要dba確認(rèn)
支持的語句
不支持DDL渴逻，只是inset最好，就類似文件的append音诫。update惨奕、delete都會增加后端的處理邏輯。
事務(wù)支持
本身就是用于大數(shù)據(jù)處理的竭钝，不支持事務(wù)
字段問題
建議末尾追加字段梨撞，只用簡易字段（int，string）
總結(jié)
binlog方案技術(shù)上沒什么特別難點(diǎn)香罐，重點(diǎn)還是運(yùn)營的坑比較多
參考資料：
https://blog.csdn.net/u013128262/article/details/80040310
