Others-大資料平臺Lambda架構淺析（全量計算+增量計算）
大資料平臺Lambda架構淺析（全量計算+增量計算）
2016年12月23日 22:50:53 scuter_victor 閱讀數：1642 個人分類： 造輪子Spark筆者剛接觸大資料方面時，只知道Hadoop和時下很火的Spark，對Hadoop、Spark的認知只停留在跑跑demo，寫點離線小app，後來隨著學業專案的需要，開始逐步瞭解時下工業界的大資料平臺是如何搭建起來的。在搜刮大量資料後，從一篇paper裡看到Lambda這一陌生的字眼，再一搜，發現這正是我需要的大資料平臺基礎架構。
廢話不多說，謹以此篇博文記錄自己對lambda架構的理解 
上圖便是從lambda官網盜取的架構圖
1：所有資料都來自於同一入口，然後被分發到batch layer（批處理層）和speed layer（實時計算層）
對於資料來源，可參考Oryx2的做法，統一採用Kafka接入Spark Streaming，然後再根據訂閱的topic分發資料到batch layer和speed layer。關於Kafka接入Spark Streaming，確實挺多坑，當然對Kafka熟悉的大神就很easy，對我這種菜雞來說著實吃力。
我試了兩種方式（Kafka 0.10.1 + Spark 2.0.0）：
1）Spark官網提供的方法，詳盡參考
2）使用開源框架kafka-spark-consumer，由於此框架對應的spark版本是spark1.6.0，kafka支援的版本有0.8、0.9、0.10，所以可以放心接入，只是使用spark2.0+的童鞋需要手動更改下框架中提供的demo(SampleConsumer.java)，此框架親測可用！
2：batch layer官網給出簡略解釋是：兩個作用{1)管理全量資料(不可變的，且只用append方式增加資料；2）處理全量資料得出模型–>結果)
對於batch layer，主要用於全量計算，處理所有歷史資料，這裡有三點注意：
1）資料是有限的
2）資料需要被持久化
3）資料量大–>導致處理過程high latency
那麼，批處理層怎麼實現好呢？
從Kafka接入資料到Spark Streaming後，處理每個rdd，將rdd中資料解析結構化並持久化到HDFS中。筆者是基於HBase+Parquet+Spark SQL的機制來做處理，首先將所有原資料儲存到HBase的一張表中，然後根據row key（可加入時間戳）讀取HBase資料，根據讀取到的資料從remote server檔案資料來源伺服器fetch檔案到平臺的HDFS，用Parquet記錄檔案中需要作為訓練集的資訊，訓練模型時再用Spark SQL去讀parquet file（僅供參考，過程可根據業務不同調整）
3：serving layer主要用於merge 批處理層和speed層結果，供外部web介面查詢結果用的
4：speed layer的出現主要是彌補batch layer高延時的缺點，是一種增量計算的處理層
怎麼理解和實現“增量計算”呢？說實話，這著實讓我費解了好久……
其實，說白了，就是對從時間起始點開始進入系統的資料，採用分塊處理的方式，將資料分成各自獨立的進行處理，即micro-batch processing。Spark Streaming就是基於這種思想衍生而來的。
對於流入speed layer的資料集，有三點需要注意：
1）資料是“無限”的
2）當前處理中的資料集（工作集）可能是相關的，且同時只限制於當前資料集（即與其他資料集無關）
3）處理是基於事件的，只有被明確停止才會結束；得到的結果會立即生效並且隨著新資料進入會實時更新
當前很火的流計算框架有：Storm、Spark Streaming等
Spark Streaming官網這張圖就很直觀的解釋了什麼是micro-batch processing： 
Spark Streaming還提供另一個操作：window operations（滑動窗） 
通過指定window length（窗的長度）+ sliding interval（滑動間隔），即可將資料流分成相對獨立的小塊，隨著視窗的滑動即可分批處理流入的資料，這正是speed layer處理資料流的精髓所在
像Oryx2，batch layer和speed layer是開啟兩個不同的StreamingContext，從kafka消化資料做處理（Spark中，一個JVM程序只能同時存在一個streamingContext）