LinkedIn大數據后臺是如何運作的_數據分析師

第一部分：Log是什么?

　　第二部分：數據集成

　　第三部分：日志和實時流處理

　　第四部分：系統建設

　　第三部分：日志和實時流處理

　　到此為止，我只是描述從端到端數據復制的理想機制。但是在存儲系統中搬運字節不是所要講述內容的全部。最終我們發現日志是流的另一種說法，日志是流處理的核心。

　　但是，等等，什么是流處理呢?

　　如果你是90年代晚期或者21世紀初數據庫文化或者數據基礎架構產品的愛好者，那么你就可能會把流處理與建創SQL引擎或者創建“箱子和箭頭”接口用于事件驅動的處理等聯系起來。

　　如果你關注開源數據庫系統的大量出現，你就可能把流處理和一些開源數據庫系統關聯起來，這些系統包括了：Storm,Akka,S4和Samza.但是大部分人會把這些系統作為異步消息處理系統，這些系統與支持群集的遠程過程調用層的應用沒什么差別(而事實上在開源數據庫系統領域某些方面確實如此)。

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

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

　　處理模型的實時驅動是數據收集方法。成批收集的數據是分批處理的。數據是不斷收集的，它也是按順序不斷處理的。

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

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

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

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

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

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

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

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

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

　　數據流圖

　　流處理最有趣的角度是它與流處理系統內部無關，但是與之密切相關的是如何擴展了我們談到的早期數據集成的數據獲取的理念。我們主要討論了基礎數據的獲取或日志–事件和各類系統執行中產生的數據等。但是流處理允許我們包括了計算其它數據的數據。這些衍生的數據在消費者看來與他們計算的原始數據沒什么差別。這些衍生的數據可以按任意的復雜度進行壓縮。

　　讓我們再深入一步。我們的目標是：流處理作業可以讀取任意的日志并把日志寫入到日志或者其它的系統中。他們用于輸入輸出的日志把這些處理關聯到一組處理過程中。事實上，使用這種樣式的集中日志，你可以把組織全部的數據抓取、轉化和工作流看成是一系列的日志和寫入它們的處理過程。

　　流處理器根本不需要理想的框架：它可能是讀寫日志的任何處理器或者處理器集合，但是額外的基礎設施和輔助可以提供幫助管理處理代碼。

　　日志集成的目標是雙重的：

　　首先，它確保每個數據集都有多個訂閱者和有序的。讓我們回顧一下狀態復制原則來記住順序的重要性。為了使這個更加具體，設想一下從數據庫中更新數據流–如果在處理過程中我們把對同一記錄的兩次更新重新排序，可能會產生錯誤的輸出。 TCP之類的鏈接僅僅局限于單一的點對點鏈接，這一順序的持久性要優于TCP之類的鏈接，它可以在流程處理失敗和重連時仍然存在。

　　第二，日志提供了流程的緩沖。這是非?；A的。如果處理流程是非同步的，那么上行生成流數據的作業比下行消費流數據的作業運行的更快。這將會導致處理流程阻塞，或者緩沖數據，或者丟棄數據。丟棄數據并不是可行的方法，阻塞將會導致整個流程圖立即停止。 日志實際上是一個非常大的緩沖，它允許流程重啟或者停止但不會影響流程圖其它部分的處理速度。如果要把數據流擴展到更大規模的組織，如果處理作業是由多個不同的團隊提供的，這種隔離性是極其重的。我們不能容忍一個錯誤的作業引發后臺的壓力，這種壓力會使得整個處理流程停止。

　　Storm和Sama這兩者都是按非同步方式設計的，可以使用Kafka或者其它類似的系統作為它們的日志。

　　有狀態的實時流處理

　　一些實時流處理在轉化時是無狀態的記錄。在流處理中大部分的應用會是相當復雜的統計、聚合、不同窗口之間的關聯。例如有時人們想擴大包含用戶操作信息的事件流(一系列的單擊動作)–實際上關聯了用戶的單擊動作流與用戶的賬戶信息數據庫。不變的是這類流程最終會需要由處理器維護的一些狀態信息。例如數據統計時，你需要統計到目前為止需要維護的計數器。如果處理器本身失敗了，如何正確的維護這些狀態信息呢?

　　最簡單的替換方案是把這些狀態信息保存在內存中。但是如果流程崩潰，它就會丟失中間狀態。如果狀態是按窗口維護的，流程就會回退到日志中窗口開始的時間點上。但是，如果統計是按小時進行的，那么這種方式就會變得不可行。

　　另一個替換方案是簡單的存儲所有的狀態信息到遠程的存儲系統，通過網絡與這些存儲關聯起來。這種機制的問題是沒有本地數據和大量的網絡間通信。

　　我們如何支持處理過程可以像表一樣分區的數據呢?

　　回顧一下關于表和日志二相性的討論。這一機制提供了工具把數據流轉化為與處理過程協同定位的表，同時也提供了這些表的容錯處理的機制。

　　流處理器可以把它的狀態保存在本地的表或索引–bdb,或者leveldb,甚至于類似于Lucene 或fastbit一樣不常見的索引。這些內容存儲在它的輸入流中(或許是使用任意的轉化)。生成的變更日志記錄了本地的索引，它允許存儲事件崩潰、重啟等的狀態信息。流處理提供了通用的機制用于在本地輸入流數據的隨機索引中保存共同分片的狀態。

　　當流程運行失敗時，它會從變更日志中恢復它的索引。每次備份時，日志把本地狀態轉化成一系列的增量記錄。

　　這種狀態管理的方法有一個優勢是把處理器的狀態也做為日志進行維護。我們可以把這些日志看成與數據庫表相對應的變更日志。事實上，這些處理器同時維護著像共同分片表一樣的表。因為這些狀態它本身就是日志，其它的處理器可以訂閱它。如果流程處理的目標是更新結點的最后狀態，這種狀態又是流程的輸出，那么這種方法就顯得尤為重要。

　　為了數據集成，與來自數據庫的日志關聯，日志和數據庫表的二象性就更加清晰了。變更日志可以從數據庫中抽取出來，日志可以由不同的流處理器(流處理器用于關聯不同的事件流)按不同的方式進行索引。

　　我們可以列舉在Samza中有狀態流處理管理的更多細節和大量實用的例子。

　　日志壓縮

　　當然，我們不能奢望保存全部變更的完整日志。除非想要使用無限空間，日志不可能完全清除。為了澄清它，我們再來聊聊Kafka的實現。在Kafka中,清理有兩種選擇，這取決于數據是否包括關鍵更新和事件數據。對于事件數據，Kafka支持僅維護一個窗口的數據。通常，配置需要一些時間，窗口可以按時間或空間定義。雖然對于關鍵數據而言，完整日志的重要特征是你可以重現源系統的狀態信息，或者在其它的系統重現。

　　隨著時間的推移，保持完整的日志會使用越來越多的空間，重現所耗費的時間越來越長。因些在Kafka中,我們支持不同類型的保留。我們移除了廢棄的記錄(這些記錄的主鍵最近更新過)而不是簡單的丟棄舊日志。我們仍然保證日志包含了源系統的完整備份，但是現在我們不再重現原系統的全部狀態，而是僅僅重現最近的狀態。我們把這一特征稱為日志壓縮。