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

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

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

原因一：當(dāng)人們?cè)噲D采集其他類型的數(shù)據(jù)集(例如用戶行為跟蹤記錄，運(yùn)營(yíng)性能指標(biāo)，應(yīng)用日志等), 數(shù)據(jù)庫(kù)變的越來(lái)越昂貴。相比于交易數(shù)據(jù)，這些數(shù)據(jù)集同等重要，因?yàn)槔盟鼈兡芨钊氲乩斫鈽I(yè)務(wù)，然而它們的數(shù)據(jù)量會(huì)大到2-3倍的規(guī)模。由于傳統(tǒng)數(shù)據(jù)庫(kù)通常依賴于昂貴又高端的存儲(chǔ)系統(tǒng)(例如SAN), 因而數(shù)據(jù)庫(kù)存儲(chǔ)所有數(shù)據(jù)集的開(kāi)銷變的極其昂貴。

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

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

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

1. 鍵/值對(duì)存儲(chǔ)：Cassandra，MongoDB，HBase等
2. 搜索：ElasticSearch, Solr 等
3. 流式處理：Storm， Spark Streaming，Samza等
4. 圖：GraphLab，F(xiàn)lockDB 等
5. 時(shí)序數(shù)據(jù)庫(kù)：OpenTSDB等

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

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

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

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

• 為了能在商業(yè)硬件上，存儲(chǔ)高容量的數(shù)據(jù)而設(shè)計(jì)的分布式系統(tǒng)。
• 設(shè)計(jì)成能支持多訂閱的系統(tǒng)，同份發(fā)布的數(shù)據(jù)集能被消費(fèi)多次。
• 天生保存數(shù)據(jù)到磁盤，在沒(méi)有性能損耗的條件下，能同時(shí)傳送消息到實(shí)時(shí)和批處理消費(fèi)者。
• 內(nèi)置的數(shù)據(jù)冗余，因而可以保障高可用性，以用于關(guān)鍵任務(wù)的數(shù)據(jù)發(fā)布消費(fèi)。

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

未來(lái)展望

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

【本文是51CTO專欄作者“董飛”的原創(chuàng)文章，轉(zhuǎn)載請(qǐng)聯(lián)系作者本人獲取授權(quán)】

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