1.背景概述

業務上有一定的需求, 希望能實時地對從中介軟體進來的資料已經已有的維度表進行inner join, 以便後續的統計. 維表十分巨大, 有近3千萬記錄,約3G資料, 而叢集的資源也較緊張, 因此希望儘可能壓榨Spark Streaming的效能和吞吐量.

技術架構大致上如下述: 資料從Kafka流入, SparkStreaming 會從HDFS中拿到維度表的資料, 與流入的訊息進行計算, 最後進行inner join, 計算結果會插入HBase.

為什麼選擇Kafka去承擔類似資料匯流排的角色呢,絕大部分是由於它簡單的架構以及出色的吞吐量, 並且與Spark也有專門的整合模組. Kafka的出色吞吐量主要是來自於最大化利用系統快取以及順序讀寫所帶來的優點, 同時offset和partition的涉及也提供了較好的容災性.

為什麼選擇Spark作為流計算引擎呢,主要是由於Spark本身優雅的RDD設計讓分散式程式設計更簡單, 同時結合Spark的記憶體快取層也使得計算更快,而Spark對各種技術的整合與支援, 能夠使技術棧更簡單和通用, 也是選用它的一個重要原因. 而Spark的DirectKafkaInputDStream也提供了簡單有效的HA.

而對於HBase的選擇,則更多的是出於歷史原因吧,因為公司一直都有在用HBase.

然後, 硬體資源大概是開了6個計算節點(也就是executor),每個節點佔3G記憶體和3個核, 包括主節點(也就是driver)在內, 整個spark應用佔用的叢集資源大概是18.5G記憶體和19個核. 噢, 對了, Kafka用於測試的topic有3個partition, 每個partition兩個replication.

         現在前面大概描述下測試結果吧, 一開始根本無法在1小時內跑完一個batch, 優化後可以達到每秒處理近6萬條Kafka輸入資料, 對6萬*2千3百萬資料(近3G)進行inner join. 與Storm稍微做了下對比, 從網上的資料”http://blog.linezing.com/?p=1048”可以看到Storm可以每秒處理3.5萬資料, Spark Streaming則打到了它的近兩倍吞吐量. 但需要說明的是, 網上使用的Storm版本不是最新的, 而且也沒說明業務邏輯與是否有做優化, 因此只能大概作一些感性上的比較.

2.壓之初體驗

程式碼編寫完後,不做任何優化, 全量資料壓著玩玩, 由於一開始沒打算記錄這個過程, 所以第一次壓測體驗的資料木有記錄, 估計也是從Kafka一次獲得30多萬條記錄, 然後與HDFS上的3G多資料逐條進行轉換後再進行inner join.

結果不大記得, 貌似跑了大半天吧, 同時在shuffle階段記憶體嚴重不夠用, 要把資料spill到磁碟進行shuffle.如果是自己的機子這樣玩的話, 估計會很心疼吧.