Kafka在大數(shù)據(jù)生態(tài)系統(tǒng)中的價值

近幾年， Apache Kafka的應(yīng)用有了顯著的增長。Kafka最新的客戶包括Uber, Twitter, Netflix, LinkedIn, Yahoo, Cisco, Goldman Sachs 等。Kafka是個高可擴(kuò)展的生產(chǎn)消費(fèi)者系統(tǒng)。利用Kafka系統(tǒng)，用戶可以發(fā)布大量的消息， 同時也能實時訂閱消費(fèi)消息。本文旨在說明Kafka如何在大數(shù)據(jù)生態(tài)系統(tǒng)中扮演越來越重要的角色。

以不變應(yīng)萬變模式的短板

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

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

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

專用分布式系統(tǒng)的涌現(xiàn)

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

鍵/值對存儲：Cassandra，MongoDB，HBase等

搜索：ElasticSearch, Solr 等

流式處理：Storm， Spark Streaming，Samza等

圖：GraphLab，F(xiàn)lockDB 等

時序數(shù)據(jù)庫：OpenTSDB等

類似專用系統(tǒng)能幫助公司提供更深入地見解, 構(gòu)建前所未有的新應(yīng)用。

專用系統(tǒng)數(shù)據(jù)導(dǎo)入

當(dāng)這些專用系統(tǒng)變革IT技術(shù)棧，它也會引發(fā)新挑戰(zhàn)：如何導(dǎo)入數(shù)據(jù)到這些系統(tǒng)中。首先，要注意的是從交易型數(shù)據(jù)到用戶跟蹤數(shù)據(jù)，運(yùn)營指標(biāo)，服務(wù)日志等，會有很多有趣的數(shù)據(jù)類型。通常，同一份數(shù)據(jù)集需要被注入到多個專用系統(tǒng)內(nèi)。例如，當(dāng)應(yīng)用日志用于離線日志分析，它和搜索單個日志記錄的作用同等重要。這使得構(gòu)建各自獨(dú)立的工作流來采集每種類型的數(shù)據(jù)，直接導(dǎo)入到每個相關(guān)的專用系統(tǒng)中 變的不切實際。

其次，當(dāng)Hadoop常常保存所有類型數(shù)據(jù)的副本，這導(dǎo)致導(dǎo)入數(shù)據(jù)到所有其他Hadoop以外的系統(tǒng) 無法實行 因為大部分系統(tǒng)要求數(shù)據(jù)實時導(dǎo)入 這是Hadoop所無法保證的。這也是為什么Kafka能出現(xiàn)并參與大數(shù)據(jù)生態(tài)系統(tǒng)。Kafka有以下不錯的特性：

為了能在商業(yè)硬件上，存儲高容量的數(shù)據(jù)而設(shè)計的分布式系統(tǒng)。

設(shè)計成能支持多訂閱的系統(tǒng)，同份發(fā)布的數(shù)據(jù)集能被消費(fèi)多次。

天生保存數(shù)據(jù)到磁盤，在沒有性能損耗的條件下，能同時傳送消息到實時和批處理消費(fèi)者。

內(nèi)置的數(shù)據(jù)冗余，因而可以保障高可用性，以用于關(guān)鍵任務(wù)的數(shù)據(jù)發(fā)布消費(fèi)。

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

未來展望

業(yè)界趨勢是多個專用系統(tǒng)能在大數(shù)據(jù)生態(tài)圈內(nèi)共存。當(dāng)更多的公司開始推進(jìn)實時處理時，由分布式生產(chǎn)/消費(fèi)系統(tǒng)(例如：Kafka)驅(qū)動的流式數(shù)據(jù)平臺 在這生態(tài)系統(tǒng)中扮演愈加重要的角色。由此產(chǎn)生的一個影響是人們開始重新思考數(shù)據(jù)策管流程。目前，很多數(shù)據(jù)策管例如模式化數(shù)據(jù)和數(shù)據(jù)模式的演化將被延遲到 數(shù)據(jù)加載到Hadoop系統(tǒng)內(nèi)的階段。由于統(tǒng)一數(shù)據(jù)管理的流程會在其他專用系統(tǒng)重復(fù)執(zhí)行，這對于流式數(shù)據(jù)平臺并不理想。更好的方案是當(dāng)數(shù)據(jù)消化處理，進(jìn)入Kafka時，早期就開始設(shè)計數(shù)據(jù)策管。這也是我們Confluent目前做的部分工作，更多細(xì)節(jié)可以參考我們的網(wǎng)站。