http://www.infoq.com/cn/news/2015/03/apache-kafka-stream-data?utm_source=infoq&utm_medium=related_content_link&utm_campaign=relatedContent_articles_clk
近來，有許多關於“流處理”和“事件數據”的討論，它們往往都與像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還對其中的若干細節進行了深入探討，並提供了一些實現建議。感興趣的讀者可以查看這裏。