LinkedIn大資料平臺深度解析(下)

第三部分:日誌和即時流處理

到此為止，我只是描述從端到端資料複製的理想機制。 但是在存儲系統中搬運位元組不是所要講述內容的全部。 最終我們發現日誌是流的另一種說法，日誌是流處理的核心。

但是，等等，什麼是流處理呢？

如果你是90年代晚期或者21世紀初資料庫文化或者資料基礎架構產品的愛好者，那麼你就可能會把流處理與建創SQL引擎或者創建「箱子和箭頭」介面用於事件驅動的處理等聯繫起來。

如果你關注開源資料庫系統的大量出現，你就可能把流處理和一些開源資料庫系統關聯起來，這些系統包括了：Storm,Akka, S4和Samza.但是大部分人會把這些系統作為非同步消息處理系統，這些系統與支援群集的遠端程序呼叫層的應用沒什麼差別（而事實上在開源資料庫系統領域某些方面確實如此）。

這些視圖都有一些局限性。 流處理與SQL是無關的。 它也局限于即時流處理。 不存在內在的原因限制你不能處理昨天的或者一個月之前的流資料，且使用多種不同的語言表達計算。

我把流處理視為更廣泛的概念：持續資料流程處理的基礎架構。 我認為計算模型可以像MapReduce或者分散式處理架構一樣普遍，但是有能力處理低時延的結果。

處理模型的即時驅動是資料收集方法。 成批收集的資料是分批次處理的。 資料是不斷收集的，它也是按順序不斷處理的。

美國的統計調查就是成批收集資料的良好典範。 統計調查週期性的開展，通過挨門挨戶的走訪，使用蠻力發現和統計美國的公民資訊。 1790年統計調查剛剛開始時這種方式是奏效的。 那時的資料收集是批次處理的，它包括了騎著馬悠閒的行進，把資訊寫在紙上，然後把成批的記錄傳送到人們統計資料的中心網站。 現在，在描述這個統計過程時，人們立即會想到為什麼我們不保留出生和死亡的記錄，這樣就可以產生人口統計資訊這些資訊或是持續的或者是其它維度的。

這是一個極端的例子，但是大量的資料傳送處理仍然依賴于週期性的轉儲，批量轉化和集成。 處理大容量轉儲的唯一方法就是批量的處理。 但是隨著這些批次處理被持續的供給所取代，人們自然而然的開始不間斷的處理以平滑的處理所需資源並且消除延遲。

例如LinkedIn幾乎沒有批量資料收集。 大部分的資料或者是活動資料或者是資料庫變更，這兩者都是不間斷發生的。 事實上，你可以想到的任何商業，正如：Jack Bauer告訴我們的，低層的機制都是即時發生的不間斷的流程事件。 資料是成批收集的，它總是會依賴于一些人為的步驟，或者缺少數位化或者是一些自動化的非數位化流程處理的遺留資訊。 當傳送和處理這些資料的機制是郵件或者人工的處理時，這一過程是非常緩慢的。 首輪自動化總是保持著最初的處理形式，它常常會持續相當長的時間。

每天運行的批量處理作業常常是類比了一種一天的視窗大小的不間斷計算。 當然，低層的資料也經常變化。 在LinkedIn,這些是司空見貫的，並且使得它們在Hadoop運轉的機制是有技巧的，所以我們實施了一整套管理增量的Hadoop工作流的架構。

由此看來，對於流處理可以有不同的觀點。 流處理包括了在底層資料處理的時間概念，它不需要資料的靜態快照，它可以產生使用者可控頻率的輸出，而不用等待資料集的全部到達。 從這個角度上講，流處理就是廣義上的批次處理，隨著即時資料的流行，會兒更加普遍。

這就是為什麼從傳統的視角看來流處理是利基應用。 我個人認為最大的原因是缺少即時資料收集使得不間斷的處理成為了學術性的概念。

我想缺少即時資料收集就像是商用流處理系統註定的命運。 他們的客戶仍然需要處理面向檔的、每日批量處理ETL和資料整合。 公司建設流處理系統關注的是提供附著在即時資料流的處理引擎，但是最終當時極少數人真正使用了即時資料流。 事實上，在我在LinkedIn工作的初期，有一家公司試圖把一個非常棒的流處理系統銷售給我們，但是因為當時我們的全部資料都按小時收集在的檔裡，當時我們提出的最好的應用就是在每小時的最後把這些檔輸入到流處理系統中。 他們注意到這是一個普遍性的問題。 這些異常證明了如下規則：流處理系統要滿足的重要商業目標之一是：財務， 它是即時資料流已具備的基準，並且流處理已經成為了瓶頸。

甚至於在一個健康的批次處理系統中，流處理作為一種基礎架構的實際應用能力是相當廣泛的。 它跨越了即時資料請求-應答服務和離線批量處理之間的鴻溝。 現在的互聯網公司，大約25%的代碼可以劃分到這個類型中。

最終這些日誌解決了流處理中絕大部分關鍵的技術問題。 在我看來，它所解決的最大的問題是它使得多訂閱者可以獲得即時資料。 對這些技術細節感興趣的朋友，我們可以用開源的Samza,它是基於這些理念建設的一個流處理系統。 這些應用的更多技術細節我們在此文檔中有詳細的描述。

(責任編輯：mengyishan)