用Apache Kafka建構流資料平台

近來，有許多關于“流處理”和“事件資料”的讨論，它們往往都與像Kafka、Storm或Samza這樣的技術相關。但并不是每個人都知道如何将這種技術引入他們自己的技術棧。于是，Confluent聯合創始人Jay Kreps釋出了《流資料平台建構實戰指南》。他結合自己過去五年中在LinkedIn建構Apache Kafka的經驗，介紹了如何建構一個公司範圍的實時流資料中心。

他們将該實時流資料中心稱為流資料平台，其出現主要是由于需要：

在關系型OLTP資料庫、Hadoop、Teradata、搜尋系統、監控系統、OLAP資料庫等若幹不同的系統之間傳遞資料，而且這些系統處于地理上分散的環境中；

進行更豐富的資料分析處理，而且延遲要低，也就是需要進行所謂的“流處理”或“複雜事件處理”。

在流資料平台出現之前，他們是通過系統之間的點對點連接配接來實作資料傳輸和處理。但随着時間推移，系統之間的資料傳輸管道越來越複雜（如下圖所示）：

這些管道存在着各種各樣的問題，如日志資料管道會丢失資訊，Oracle執行個體之間的管道無法供其它系統使用等。而且，在不同的地方增加資料中心時，需要複制所有的資料流。也就是說，這些管道建立的時候很簡單，但擴充非常麻煩。更糟糕的是，過高的複雜性常常意味着不可靠，資料品質可能會成為問題。比如Jay舉了一個例子，他們曾發現某兩個系統的資料不一緻，但當它們将這兩個系統的資料與另外一個系統的資料進行對比時發現，第三個系統中的資料與兩者之中的任何一個都不相同。

另外，除了将資料從一個地方搬運到另外一個地方，他們還希望可以對資料做些處理。本來，Hadoop已經提供了這樣一個平台，它具備批處理、資料歸檔等功能。但是，它無法滿足低延時應用系統的需求。

是以，在2010年，他們決定建構一個系統，專門用于捕獲資料流。該系統要既能用于系統內建，又能對資料流進行實時處理。這就是Apache Kafka的起源。之後，他們有了“流資料平台”的構想（如下圖所示）：

他們的系統架構因而變得更加清晰整潔（如下圖所示）：

圍繞Apache Kafka建構的、以流為中心資料架構

在上述架構中，Kafka是作為一個全局資料管道。每個系統都向這個中心管道發送資料或者從中擷取資料。應用程式或流處理程式可以接入管道并建立新的派生流。這些派生流又可以供其它各種系統使用。現如今，在LinkedIn，Kafka每天處理超過5000億個事件。它成為各種系統之間資料流的基礎、Hadoop資料的核心管道以及流處理的中心。

接下來，Jay對上述架構進行了更為詳細的介紹。

首先，他對流資料的概念進行了特别說明。他指出，每項業務大體上都可以看作是事件流。比如，零售是下訂單、銷售、發貨、退貨的事件流。所謂的“大資料”就是捕獲這些事件，用于分析、優化和決策。在資料庫方面，雖然它存儲的是資料的目前狀态，但實際上，資料庫中的資料也是事件流的結果，即經過一系列的操作才能到達目前狀态。比如，Oracle、MySQL會按時間先後記錄每行資料的每次變化。

其次，它詳細說明了流資料平台的兩個用途：

資料內建——借助流資料平台，應用程式內建時不需要知道原始資料源的細節，釋出資料時也不需要知道哪個應用程式會消費和加載這些資料。增加新系統，也隻需要接入現有的流資料平台就可以。Hadoop也能夠維護組織所有資料的一個副本，然後作為一個“資料湖”或“企業資料中心”，但Hadoop使用HDFS與資料源內建，這非常耗時，而且它的最終結果隻能供自己使用；

流處理——流處理的結果是一個新的派生流。這個流與其它任何流一樣，可以同等對待，供其它內建到流資料平台的系統使用。流處理過程在應用程式中使用簡單的代碼就可以實作。這些代碼接入事件流并對外釋出新的事件流。但借助一些流處理架構，如Storm、Samza，會更容易實作。

然後，他列舉了流資料平台需要具備的功能：

它必須足夠可靠，能夠處理關鍵更新。比如，可以複制資料庫的變更日志，而且能夠按順序傳輸，并保證不丢失資訊；

它必須能夠支援足夠高的吞吐量；

它必須能夠緩存或持久化資料，支援與批處理系統（如Hadoop）的內建；

它必須能夠為實時應用程式提供低延時資料傳輸和處理；

它必須能夠擴充，進而承擔組織的全部負載；

它必須支援與流處理系統的緊密內建。

Apache Kafka就是這樣一個為流資料而設計的分布式系統。它具有容錯能力、高吞吐量、橫向擴充等特性，并且支援地理上分散的資料流和資料流處理。Kafka的關鍵抽象是一個結構化的更新送出日志（如下圖所示）：

生産者将一連串的記錄追加到送出日志，然後任意數量的消費者可以連續地以流的方式使用這些記錄，而延遲隻有幾毫秒。每個消費者都記錄自己在日志中的位置，彼此之間互不影響。另外，還有一個關鍵的方面，就是Kafka可以處理持久化。

最後，Jay分析了流資料平台與消息系統、企業服務總線和資料倉庫的不同之處。與消息系統相比，它更多的是一個資料中心，可以更好地與批處理系統內建，并且提供了相容流處理的語義。它展現了許多企業服務總線的思想，但相比之下其實作方式更好，因為它實作了資料流與資料轉換的解耦。另外，該平台并不會取代資料倉庫。實際上，它可以為資料倉庫提供資料。

此外，Jay還對其中的若幹細節進行了深入探讨，并提供了一些實作建議。感興趣的讀者可以檢視這裡。

感謝郭蕾對本文的審校。

給InfoQ中文站投稿或者參與内容翻譯工作，請郵件至[email protected]。也歡迎大家通過新浪微網誌（@InfoQ）或者騰訊微網誌（@InfoQ）關注我們，并與我們的編輯和其他讀者朋友交流。

【QCon北京2015大會】“可擴充、高可用架構設計”專題，由新浪微網誌技術總監楊衛華出品，邀請不同領域實踐者，分享系統架構設計方面的思考及啟發，探讨解決思路的共性。6場演講已确認，涵蓋：“基于SQL的秒殺解決方案”，“搜狗商業廣告流式計算實踐”，“你的網站是高可用的嗎？”等話題。了解詳情。

轉載:http://www.infoq.com/cn/news/2015/03/apache-kafka-stream-data?utm_source=infoq&utm_medium=popular_widget&utm_content=homepage&utm_campaign=popular_content_list