flume自定義攔截器遇到的問題

flume自定義攔截器遇到的問題

1:問題場景：
通過flume同步mysql資料到kafka，再由flink消費，kafka分割槽功能可以提高消費能裡，但是我們必須把一些有相同屬性的資料放在同一個partition中。

2：flume對kafkaSink提供兩種指定partition的配置

defaultPartitionId –
指定此通道中要傳送到的所有事件的Kafka分割槽ID(整數)，除非partitionIdHeader覆蓋。預設情況下，如果沒有設定此屬性，則事件將由Kafka生成器的分詞器分發——如果指定，包括按鍵分發(或者由Kafka .partitioner.class指定的分詞器分發)。

partitionIdHeader – 設定後，接收器將從事件頭獲取使用此屬性值命名的欄位的值，並將訊息傳送到主題的指定分割槽。如果該值表示一個無效的分割槽，則將丟擲一個EventDeliveryException。如果頭值存在，則此設定將覆

3：怎麼解決自定義分割槽問題：
我們解決問題1的方法利用了partitionIdHeader 配置，就是想方法給event的頭新增上我們希望他存在的partition，做法是建立maven工程，繼承flume的Interceptor攔截器類，對event進行處理，具體步驟這篇部落格不詳細記錄，只記錄遇到的問題，後續部落格補充。

4：flume和mysql關係：
我為了檢測結果曾經把mysql資料清空方便做驗證，但是導致了我的指令碼獲取不到資料的更新，這個問題我被困擾了很久，我一開始並不知道與我刪除資料有關，結果浪費了很多時間排查，最後的解決方案是把指令碼里配置的state快取檔案刪除，再刪除資料庫從新開始處理資料

5：為什麼flume推送的資料是重複的
推送到kafka的資料我發現並不是我mysql最新新增的資料，並且因為我這個問題讓我思考，flume是怎麼做到推送最新資料的？經過查詢我發現需要設定一個數字型別的自增id，才能實現推送最新資料，且在儲存state的檔案裡記錄著上次消費到的最大數，我曾在網上看到有人說flume的同步是做查詢同步與canal拉取mysql日誌不同，flume是消耗mysql查詢資源的。所以我猜測flume的最新資料推送很可能就是類似mysql做了排序分頁查詢出來的。感覺在高質量資料同步的情況下並不敢貿然使用。

6：資料延遲場景：
在保證實用同一個id自增邏輯的資料，有多臺機器新增到某臺mysql機器，那也許到mysql的新增資料可能是 01273，45689，在我的測試中，第一次kafka收到的資料會是01273，第二次收到的資料是56789，所以就漏了一個4，重複了一個7。所以對於精確度要求高的資料不該使用flume計算