近幾年， Apache Kafka的應用有了顯著的增長。Kafka***的客戶包括Uber, Twitter, Netflix, LinkedIn, Yahoo, Cisco, Goldman Sachs 等。Kafka是個高可擴展的生產消費者系統。利用Kafka系統，用戶可以發布大量的消息， 同時也能實時訂閱消費消息。本文旨在說明Kafka如何在大數據生態系統中扮演越來越重要的角色。

以不變應萬變模式的短板

長期以來，數據庫成為人們存放和處理感興趣數據的***。數據庫廠商不斷發布新功能 (例如 搜索，流式處理和分析)，以確保在數據庫內能完成更多有意思的工作。然而，基于以下2點原因，數據庫模式不再是理想的方案。

原因一：當人們試圖采集其他類型的數據集(例如用戶行為跟蹤記錄，運營性能指標，應用日志等), 數據庫變的越來越昂貴。相比于交易數據，這些數據集同等重要，因為利用它們能更深入地理解業務，然而它們的數據量會大到2-3倍的規模。由于傳統數據庫通常依賴于昂貴又高端的存儲系統(例如SAN), 因而數據庫存儲所有數據集的開銷變的極其昂貴。

其次，隨著越來越多的功能堆砌，數據庫變的過于復雜，在維護之前遺留版本的同時，很難增加新的功能。數據庫廠商跨多年的發布變的越來越普遍。

專用分布式系統的涌現

在近10年, 為了克服這些短板，人們開始構建專用系統。這些系統生而為了單一的目標，但能夠非常好地完成。因為他們的簡單性，在商業硬件上構建類似的分布式系統逐漸可行。因而，相比 以SAN為存儲基礎的數據庫，這些專用系統性價比更高。通常，類似系統是構建在開源項目上,進而降低了所有權的成本。而且，由于這些專用系統只關注單一目標，相比于大而全的系統，他們可以發展和改進得更快。Hadoop***了這個風潮。它專注于離線數據處理，通過提供分布式文件系統(HDFS)和計算引擎(MapReduce)來批量存儲和處理數據。相比于數據庫存儲，利用HDFS，企業能夠支持低廉地采集存儲更多有價值的數據集。利用MapReduce，大家能以低廉的代價來針對新數據集 提供報告和分析。在其他很多領域，類似的模式在不斷上演。

1. 鍵/值對存儲：Cassandra，MongoDB，HBase等
2. 搜索：ElasticSearch, Solr 等
3. 流式處理：Storm， Spark Streaming，Samza等
4. 圖：GraphLab，FlockDB 等
5. 時序數據庫：OpenTSDB等

類似專用系統能幫助公司提供更深入地見解, 構建***的新應用。

專用系統數據導入

當這些專用系統變革IT技術棧，它也會引發新挑戰：如何導入數據到這些系統中。首先，要注意的是從交易型數據到用戶跟蹤數據，運營指標，服務日志等，會有很多有趣的數據類型。通常，同一份數據集需要被注入到多個專用系統內。例如，當應用日志用于離線日志分析，它和搜索單個日志記錄的作用同等重要。這使得構建各自獨立的工作流來采集每種類型的數據，直接導入到每個相關的專用系統中 變的不切實際。

其次，當Hadoop常常保存所有類型數據的副本，這導致導入數據到所有其他Hadoop以外的系統 無法實行 因為大部分系統要求數據實時導入 這是Hadoop所無法保證的。這也是為什么Kafka能出現并參與大數據生態系統。Kafka有以下不錯的特性：

• 為了能在商業硬件上，存儲高容量的數據而設計的分布式系統。
• 設計成能支持多訂閱的系統，同份發布的數據集能被消費多次。
• 天生保存數據到磁盤，在沒有性能損耗的條件下，能同時傳送消息到實時和批處理消費者。
• 內置的數據冗余，因而可以保障高可用性，以用于關鍵任務的數據發布消費。

大部分被提及的公司在最初階段總是集成多個專用系統。他們利用Kafka作為數據中轉樞紐來實時消費所有類型的數據。同份Kafka數據可以被導入到不同專用系統中。如下圖所示，我們參考這樣的構架作為流式數據平臺。由于新系統能通過訂閱Kafka，輕易地獲取它想要的數據，我們可以輕松地引入額外的專用系統，進入到這系統構架中。

未來展望

業界趨勢是多個專用系統能在大數據生態圈內共存。當更多的公司開始推進實時處理時，由分布式生產/消費系統(例如：Kafka)驅動的流式數據平臺 在這生態系統中扮演愈加重要的角色。由此產生的一個影響是人們開始重新思考數據策管流程。目前，很多數據策管例如模式化數據和數據模式的演化將被延遲到 數據加載到Hadoop系統內的階段。由于統一數據管理的流程會在其他專用系統重復執行，這對于流式數據平臺并不理想。更好的方案是當數據消化處理，進入Kafka時，早期就開始設計數據策管。

【本文是51CTO專欄作者“董飛”的原創文章，轉載請聯系作者本人獲取授權】

戳這里，看該作者更多好文