原文作者：孟知之

原文地址：實時計算相關問題及解決方案

目錄

1. 怎么處理 Spark structured streaming 慢速變化數據 join 的問題？

2. Kafka不穩定導致Spark Streaming不穩定

3. Flume當中出現了流量瓶頸

4. Kafka的流量問題

---

1. 怎么處理 Spark structured streaming 慢速變化數據 join 的問題？

問題：

從 MySQL 的一個表里面提取 metadata 然后和 structured streaming 的實時數據做 join，得到想要的結果。而mysql的表的數據有時候會變更，有沒有辦法讓 structured streaming 隔一段時間（比如一天）去自動重新讀一次 MySQL？

解決方案：

1）不cache（緩存）從MySQL讀出來的DataFrame就可以了，這樣每次查詢都會重讀一次 MySQL 表。

2）如果不接受不做cache對性能的負面影響，可以在另一個線程里 （StreamingQueryListener）unpersist再cache，每隔一段時間 unpersist一次MySQL的DataFrame再重新cache。

2. Kafka不穩定導致Spark Streaming不穩定

問題：

Spark Streaming每個批次Job都會通過DirectKafkaInputStream的comput方法獲取消費的Kafka Topic當前最新的offset，如果此時kafka集群由于某些原因不穩定，就會導致 java.lang.RuntimeException: No leader found for partition xx的問題，由于此段代碼運行在Driver端，如果沒有做任何配置和處理的情況下，會導致程序直接掛掉。

解決方案：

配置spark.streaming.kafka.maxRetries大于1，并且可以通過配置refresh.leader.backoff.ms參數設置每次重試的間隔時間。

3. Flume當中出現了流量瓶頸

問題：

Flume是Kafka的前端，是所有數據進入Kafka的一個源頭。我們在實踐過程中發現，在Flume當中出現了流量瓶頸，更準確來說，是Flume的前一級服務器出現了數據堆積。結果發現數據通過連接Source的性能出現了瓶頸。

解決方案：

一旦Flume出現堆積，首先要判斷的就是數據堆積到底是出現在Flume的前面還是后面。后來我發現了一個很簡單的判斷方式，Channel其實是個簡單的共享內存。如果數據的堆積是出現在后面Sink一端的話，那么當數據被源源不斷地寫到Channel里面，Sink又沒法消費掉的時候，那么Channel應該就會滿。所以，只要檢查一下Channel中有沒有滿的報錯，就能夠分析出數據的瓶頸到底是出現在Flume的前面還是后面。經過檢查之后，發現數據的堆積是在Flume的前面。
接下來，第一種方法，可以將數據拆分成多份，進行傳輸。此方法在當前項目中是不現實的。那么就采取第二種方法，可以先把它落盤，把它解到硬盤里面，只要IO性能能夠勉強扛得住，通過一路分成多路，就可以通過多線程并發的方式來解決這個問題。在流計算當中，透傳的性能不見得比落盤的性能要來得高，在實踐過程中，只要IO性能扛得住，有時候可以改用落盤的方式，通過多線程來換取性能的提升。

4. Kafka的流量問題

問題：

當Kafka出現新瓶頸時，是沒有任何告警、日志可以看的，只能是最終數據中，數據的準確性出現問題了，數據量少了，或者如果在統計流量，就只會看到流量出現大幅度減少這個現象。同樣，很多截然不同的原因導致的問題在流計算當中出現的結果都一樣，都是數據量少了，結果不準確了。

解決方案：

在項目中，最后發現問題出在網卡上。因為當時我們配置的是四塊網卡，兩主兩備的方式，也就是說4塊網卡中只有2塊是有流量的，整個帶寬是200MB左右。當出現數據堆積的時候，發現網絡端口的send流量大約為190MB/s左右，幾乎是2塊千兆網卡的吞吐量，即網卡已經跑滿了。因此，既然四塊網卡是兩主兩備，那我就改成“四網卡”模式。最終發現，當流量超過300MB/s，Kafka節點的CPU和IO的使用率仍然不算高，因此可以大膽假設，如果用1塊萬兆網卡來替代現在的4塊千兆網卡，每個Kafka節點的性能有望進一步提升，這樣實際上還有望減少Kafka節點的數量。Kafka的網絡傳輸坑至此解決。

總結

以上是生活随笔為你收集整理的分布式实时计算—实时计算相关问题及解决方案的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。