用Apache Kafka構建流數據平臺的建議
原文 http://www.infoq.com/cn/news/2015/03/apache-kafka-stream-data-advice
在 《流數據平臺構建實戰指南》第一部分 中，Confluent聯合創始人Jay Kreps介紹了如何構建一個公司范圍的實時流數據中心。InfoQ前期對此進行過報道。本文是根據 第二部分 整理而成。在這一部分中，Jay給出了一些構建數據流平臺的具體建議。
限制集群數量
Kafka集群數量越少，系統架構就越簡單，也就意味著集成點更少，新增應用程序的增量成本更低，數據流推理更簡單。但出于以下幾個方面的考慮，再少也不可能只有一個集群：
- 將活動限制在本地數據中心。Jay建議將所有的應用程序都連接到本地數據中心的集群。
- 安全方面的原因。Kafka沒有安全控制，通常，這意味著要實現網絡級安全和數據類型的物理隔離。
- SLA控制方面的原因。Kafka有一些多租戶特性，但并不完善。
簡化數據流
以單個基礎設施平臺為中心實現數據交換可以極大地簡化數據流。如果所有系統直接互連，會是下面的樣子：
如果有一個數據流平臺作為中心，則會是下面的樣子：
在第一幅圖中，每兩個系統之間需要建立兩條數據管道，而在第二幅圖中，只需要為每個系統創建一個輸入和輸出連接器來連接流數據管道。系統較多時，這兩種情況下的管道數量會有很大差別。
不僅如此，不同的系統可能會有不同的數據模型。點對點集成時，每個系統都需要處理不同系統提供的不同的數據格式，而以數據流平臺為中心進行集成的話，每個系統都只需要處理流數據平臺的數據格式。這樣可以盡量減少價值不高的語法轉換。
指定一種數據格式
Kafka并不強制事件數據采用任何特定的格式，使用JSON、XML或Avro都可以。但為事件指定一種在公司范圍內通用的數據格式非常關鍵。數據遵循類似的規范，數據生產者和消費者就不用針對不同的格式編寫不同的適配器。這在實現流數據平臺之初是最重要的事情。
根據經驗，Jay建議選擇 Apache Avro 作為統一的數據格式。Avro是一種類似JSON的數據模型，可以用JSON或二進制形式進行表示。它有如下優點：
- 可以與JSON直接映射；
- 有一個非常緊湊的格式；
- 效率非常高；
- 提供了到多種編程語言的綁定；
- 是一個用純JSON定義的、可擴展的模式語言；
- 有最好的兼容性理念。
這在保證數據質量和易用性方面非常關鍵。Avro可以為數據定義一個“模式（schema）”，后者會帶來如下好處：
- 增強架構健壯性：在以流數據平臺為中心的架構中，應用程序之間是松耦合的,如果沒有任何模式，那么系統間極易出現數據不一致的情況。
- 明確語義：模式中每個字段的doc屬性明確定義了字段的語義。
- 兼容性：模式處理數據格式變化，使像Hadoop或Cassandra這樣的系統可以跟蹤上游數據變化，只將有變化的數據傳給它們自己的存儲，而不必進行重新處理。
- 減少了數據科學家的體力勞動：模式使得數據非常規范，使他們不再需要進行低級的數據再加工。
除了上述建議外，Jay還介紹了他們在LinkedIn的一些做法。
共享事件模式
當一項活動在多個系統中都比較常見，就應該為它指定一個通用的模式。一個常見的例子是應用程序錯誤，它可以以一種非常通用的方式建模，讓ErrorEvent流捕獲整個企業的錯誤。
具體數據類型建模
Kafka數據模型是構建來表示數據流的。在Kafka中，一個流被建模成一個topic，即數據的邏輯名稱。每條消息都包含一個用于在集群上進 行數據劃分的鍵和一個包含Avro數據記錄的數據體。Kafka會根據SLA（如保留7天）或大小（如保留100GB）或鍵來維護流的歷史記錄。
- 純事件流：純事件流描述企業內發生的活動。比如，在一家Web企業里，這些活動是點擊、顯示頁面和其它各種用戶行為。每種行為類型的事件可以 表示為一個單獨的邏輯流。為了簡單起見，建議Avro模式和topic使用相同的名稱。純事件流將總是按時間或大小來保留。單個topic中混合多種事件 會導致不必要的復雜性。
- 應用程序日志：結構化日志可以像上文描述的其它事件那樣同等對待，這里說的日志是指半結構化應用程序日志。在LinkedIn，所有的應用程序日志都通過自定義的log4j輸出源發布到Kafka。
- 系統指標：收集Unix性能數據及應用程序定義的指標等統計數據，然后使用一個通用的格式發布成一個統計數據流，供企業中的監控平臺使用。
- Hadoop數據加載：最重要的是實現數據加載過程的自動化，不需要任何自定義設置或者在Kafka topic和Hadoop數據集之間作映射。LinkedIn專門為此開發了一個名為 Camus 的系統。
- Hadoop數據發布：將由Hadoop計算生成的派生流發布到流數據平臺。
- 數據庫變更：由于輪詢可能會丟失中間狀態，因此，LinkedIn選擇直接集成數據庫日志。對于純事件數據，Kafka通常只保留一個較短的時間。但對于數據庫變更流，系統可能需要從Kafka變更日志實現完全恢復。Kafka特性 Log Compaction 可以幫助實現這種需求。
- 按原樣抽取數據庫數據，然后轉換：把數據清理后再發布給客戶不是一個好主意，因為可能會有許多要求各不相同的消費者，導致清理工作需要針對不同的消費者做許多次，而且清理過程本身可能會丟失信息。所以，發布原始數據流，然后基于它創建一個完成清理工作的派生流。
流處理
流數據平臺的一個目標是在數據系統之間以流的方式傳遞數據，另一個目標是在數據到達時進行數據流處理。在流數據平臺中，流處理可以簡單地建模成流之間的轉換，如下圖所示：
在流處理過程中，將處理結果重新發布到Kafka有諸多好處。它將流處理的各部分解耦，不同的處理任務可以由不同的團隊使用不同的技術實現，下游處理過程緩慢不會對上游過程造成反壓，Kafka起到了緩沖區的作用。
實現流處理最基本的方法是使用Kafka API讀取輸入數據流進行處理，并產生輸出數據流。這個過程可以用任何編程語言實現。這種方法比較簡單，易于操作，適應于任何有Kafka客戶端的語言。 不過，有些流處理系統提供了額外的功能，使用它們構建復雜實時流處理會更簡單。常見的流處理框架包括 Storm 、 Samza 和 Spark Streaming 。關于它們之間的差別，感興趣的讀者可以查看 這里 、 這里 和 這里 。