我們都知道, Druid在攝取時需要設定一個時間視窗, 在時間視窗之外的資料,將會丟棄。我們如何將這部分丟棄的資料重新攝取進Druid系統中,以提高資料的準確性?通常的做法是把資料儲存起來, 等待重新攝取。 目前比較流行的處理方法是Lambda架構。

1.Lambda架構

    Lambda是實時處理框架Storm 的作者Nathan Marz 提出的用於同時處理離線和實時資料的架構理念 Lambda架構(LA)旨在滿足一個穩定的大規模資料處理系統所需的修錯性、低延遲 ,可擴充套件的特性。 LA的可行性和必要性基於如下假設利原則。

    • 任何效據系統可定義為: query= functional(all data)。

    • 人為容錯性 (Human Falult-Tolerance):資料是易丟失的。

    • 資料不可變(Data Immutability):資料是隻讀的，不在變化。

    • 重新計算(Recomputation):因為上面兩個原則，執行函式重新計算結果時可能的。

    LA基本架構圖：

    該架構具有如下特點：

    • 所有新資料分別分發到批處理層和實時處理層。

    • 批處理層有兩個功能:管理主要的資料(該類資料特點只能的加, 不能更新}為下一步計算出批處理檢視做預計算。

    • 服務層計算出批處理檢視中的資料做索引.以提供低延時,即使查詢。

    • 實時處理層僅處理實時資料，併為服務層提供查詢服務。

    • 任何查詢都可以通過實時處理層和批處理層的查詢結果合併得到。

    從以上論述我們所以知道,Druid本身就心一個典型的 Lambda 架構系統，Druid有實時節點和所史節點,任何查詢都是聚合實時節點和歷史節點的資料得到查詢結果。那麼, 我們如何在Druid 系統之外採用 Lambda 架構的思維去解決時間視窗面臨的問題呢?

2.解決時間視窗問題

    Druid 在攝取數掘時,對於超山時間視窗的資料會直接丟棄,這對於某些要求資料準確性的系統來說:是不可以接受的,那麼就需要重新攝入這部分資料，參考Lambda的思想，實現方式如下：

流程如下：

(1) 源數揭都進人Kafka.

(2) 資料通過實時節點或者索引服務進人Druid中

(3) Kafka 的資料通過 Flume 備份到 Hadoop.

(4) 定時或者發現有教據丟失時,通過 Druid Hadoop Index Job 重新攝人資料