為數(shù)據(jù)而生，以 20 世紀(jì)***影響力的作家命名，一個(gè)很酷的開(kāi)源項(xiàng)目——我們說(shuō)的是Kafka。進(jìn)入出生第九個(gè)年頭的 Kafka 已經(jīng)算不上年輕，但依舊活力四射。這篇文章簡(jiǎn)單梳理一下 Kafka 的發(fā)展脈絡(luò)，文末給出了本文的參考資料，以及一個(gè)快速實(shí)用 Kafka 的課程，參考資料和課程以供感興趣的讀者深入學(xué)習(xí)。

誕生背景

每一次科學(xué)家們發(fā)生分歧，都是因?yàn)檎莆盏臄?shù)據(jù)不夠充分。所以我們可以先就獲取哪一類數(shù)據(jù)達(dá)成一致。只要獲取了數(shù)據(jù)，問(wèn)題也就迎刃而解了。要么我是對(duì)的，要么你是對(duì)的，要么我們都是錯(cuò)的。然后我們繼續(xù)研究。

——Neil deGrasse Tyson

2010 年前后， 跟不少互聯(lián)網(wǎng)公司一樣，Linkedin 每天采集的數(shù)據(jù)種類多（日志消息、度量指標(biāo)、用戶活動(dòng)記錄、響應(yīng)消息，等等），規(guī)模大，其中很多數(shù)據(jù)由不同數(shù)據(jù)源實(shí)時(shí)生成。數(shù)據(jù)生產(chǎn)者和消費(fèi)者之間點(diǎn)對(duì)點(diǎn)的數(shù)據(jù)傳輸方式和多個(gè)獨(dú)立發(fā)布與訂閱系統(tǒng)的維護(hù)成本越來(lái)越高，由此， 把不同來(lái)源數(shù)據(jù)整合到一起集中管理的需求越來(lái)越強(qiáng)，公司開(kāi)始研究一套高效的數(shù)據(jù)管道。隨后，Kafka 從 Linkedin 內(nèi)部作為一套基于發(fā)布與訂閱的消息系統(tǒng)誕生。

關(guān)鍵時(shí)間節(jié)點(diǎn)

2010 年 10 月，Kafka 在 Linkedin 誕生

2011 年 7 月，進(jìn)入 Apache 孵化器，并發(fā)布***個(gè)開(kāi)源版本 0.7.0

2012 年 10 月，從孵化器畢業(yè)，成為***開(kāi)源項(xiàng)目，同時(shí)發(fā)布 0.8.0 版本

2014 年 11 月，Confluent 成立。同年，發(fā)布 0.8.2 和 0.9.0，在 0.9.0 版本加入了配額和安全性

2017 年 11 月，1.0.0 版本正式發(fā)布，Exactly-Once 與運(yùn)維性能提升

2018 年 7 月，2.0.0 版本發(fā)布，注重流式數(shù)據(jù)平臺(tái)的在線可進(jìn)化性

2018 年 12 月，Kafka 團(tuán)隊(duì)修改 KSQL 等的開(kāi)源許可

簡(jiǎn)單介紹

Kafka 數(shù)據(jù)關(guān)鍵詞

消息與鍵

Kafka 的數(shù)據(jù)單元稱為消息，可以把消息看成數(shù)據(jù)庫(kù)里的一個(gè)“數(shù)據(jù)行”或一條“記錄”。消息由字節(jié)數(shù)組組成，對(duì)于 Kafka 來(lái)說(shuō)，消息里的數(shù)據(jù)沒(méi)有特別的格式或含義。消息可以有一個(gè)可選的元數(shù)據(jù)——鍵。鍵也是一個(gè)字節(jié)數(shù)組，沒(méi)有特殊含義。為消息選取分區(qū)的時(shí)候會(huì)用到鍵。

消息與批次

為提高效率，消息分批次寫(xiě)入 Kafka。批次就是一組消息，它們屬于同一個(gè)主題和分區(qū)。把消息分成批次傳輸可以減少網(wǎng)絡(luò)開(kāi)銷。

主題與分區(qū)

Kafka 的消息通過(guò)主題進(jìn)行分類。主題就好比數(shù)據(jù)庫(kù)的表。主題可以被分為若干個(gè)分區(qū)，一個(gè)分區(qū)就是一個(gè)提交日志。消息以追加的方式寫(xiě)入分區(qū)，然后以先入先出的順序讀取。一個(gè)主題一般包含幾個(gè)分區(qū)。

圖片來(lái)自 https://kafka.apache.org

流

我們通常會(huì)使用流這個(gè)詞來(lái)描述 Kafka 這類系統(tǒng)的數(shù)據(jù)。很多時(shí)候，人們把一個(gè)主題的數(shù)據(jù)看成一個(gè)流。流是一組從生產(chǎn)者移動(dòng)到消費(fèi)者的數(shù)據(jù)。

核心API

• Kafka Producer API：直接生成數(shù)據(jù)的應(yīng)用程序（如日志、物聯(lián)網(wǎng)）
• Kafka Connect Source API：用于數(shù)據(jù)集成的 API（如 MongoDB、REST API）
• Kafka Streams API / KSQL：用于流處理的 API，如果能夠以 SQL 方式實(shí)現(xiàn)查詢邏輯就使用 KSQL，如果需要編寫(xiě)復(fù)雜邏輯就用 Kafka Streams
• Kafka Consumer API：讀取數(shù)據(jù)流并執(zhí)行實(shí)時(shí)操作（如發(fā)送電子郵件）
• Kafka Connect Sink API ：讀取數(shù)據(jù)流并將其存儲(chǔ)到目標(biāo)存儲(chǔ)中（如 Kafka 到 HDFS、Kafka 到 MongoDB 等）

中間部分的 Kafka 集群，由多個(gè) broker 組成。一個(gè)獨(dú)立的 Kafka 服務(wù)器被稱為 broker。broker 接收來(lái)自生產(chǎn)者的消息，為消息設(shè)置偏移量，并提交消息到磁盤保存。broker 為消費(fèi)者提供服務(wù)，對(duì)讀取分區(qū)的請(qǐng)求作出響應(yīng)，返回已經(jīng)提交到磁盤上的消息。根據(jù)特定的硬件及其性能特征，單個(gè) broker 可以輕松處理數(shù)千個(gè)分區(qū)以及每秒***的消息量。

應(yīng)用場(chǎng)景

活動(dòng)跟蹤

Kafka 最初的使用場(chǎng)景是跟蹤用戶的活動(dòng)。網(wǎng)站用戶與前端應(yīng)用程序發(fā)生交互，前端應(yīng)用程序生成用戶活動(dòng)相關(guān)的消息。這些消息可以是一些靜態(tài)的信息，比如頁(yè)面訪問(wèn)次數(shù)和點(diǎn)擊量，也可以是一些復(fù)雜的操作，比如添加用戶資料。這些消息被發(fā)布到一個(gè)或多個(gè)主題上，由后端應(yīng)用程序負(fù)責(zé)讀取。這樣，我們就可以生成報(bào)告，為機(jī)器學(xué)習(xí)系統(tǒng)提供數(shù)據(jù)，更新搜索結(jié)果，或者實(shí)現(xiàn)其他更多的功能。

傳遞消息

Kafka 的另一個(gè)基本用途是傳遞消息。應(yīng)用程序向用戶發(fā)送通知（比如郵件）就是通過(guò)傳遞消息來(lái)實(shí)現(xiàn)的。這些應(yīng)用程序組件可以生成消息，而不需要關(guān)心消息的格式，也不需要關(guān)心消息是如何被發(fā)送的。一個(gè)公共應(yīng)用程序會(huì)讀取這些消息，對(duì)它們進(jìn)行處理：

• 格式化消息（也就是所謂的裝飾）；
• 將多個(gè)消息放在同一個(gè)通知里發(fā)送；
• 根據(jù)用戶配置的***項(xiàng)來(lái)發(fā)送數(shù)據(jù)。

使用公共組件的好處在于，不需要在多個(gè)應(yīng)用程序上開(kāi)發(fā)重復(fù)的功能，而且可以在公共組件上做一些有趣的轉(zhuǎn)換，比如把多個(gè)消息聚合成一個(gè)單獨(dú)的通知，而這些工作是無(wú)法在其他地方完成的。

度量指標(biāo)和日志記錄

Kafka 也可以用于收集應(yīng)用程序和系統(tǒng)度量指標(biāo)以及日志。Kafka 支持多個(gè)生產(chǎn)者的特性在這個(gè)時(shí)候就可以派上用場(chǎng)。應(yīng)用程序定期把度量指標(biāo)發(fā)布到 Kafka 主題上，監(jiān)控系統(tǒng)或告警系統(tǒng)讀取這些消息。Kafka 也可以用在像 Hadoop 這樣的離線系統(tǒng)上，進(jìn)行較長(zhǎng)時(shí)間片段的數(shù)據(jù)分析，比如年度增長(zhǎng)走勢(shì)預(yù)測(cè)。日志消息也可以被發(fā)布到 Kafka 主題上，然后被路由到專門的日志搜索系統(tǒng)（比如 Elasticsearch）或安全分析應(yīng)用程序。更改目標(biāo)系統(tǒng)（比如日志存儲(chǔ)系統(tǒng)）不會(huì)影響到前端應(yīng)用或聚合方法，這是 Kafka 的另一個(gè)優(yōu)點(diǎn)。

提交日志

Kafka 的基本概念來(lái)源于提交日志，所以使用 Kafka 作為提交日志是件順理成章的事。我們可以把數(shù)據(jù)庫(kù)的更新發(fā)布到 Kafka 上，應(yīng)用程序通過(guò)監(jiān)控事件流來(lái)接收數(shù)據(jù)庫(kù)的實(shí)時(shí)更新。這種變更日志流也可以用于把數(shù)據(jù)庫(kù)的更新復(fù)制到遠(yuǎn)程系統(tǒng)上，或者合并多個(gè)應(yīng)用程序的更新到一個(gè)單獨(dú)的數(shù)據(jù)庫(kù)視圖上。數(shù)據(jù)持久化為變更日志提供了緩沖區(qū)，也就是說(shuō)，如果消費(fèi)者應(yīng)用程序發(fā)生故障，可以通過(guò)重放這些日志來(lái)恢復(fù)系統(tǒng)狀態(tài)。另外，緊湊型日志主題只為每個(gè)鍵保留一個(gè)變更數(shù)據(jù)，所以可以長(zhǎng)時(shí)間使用，不需要擔(dān)心消息過(guò)期問(wèn)題。

流處理

流處理是又一個(gè)能提供多種類型應(yīng)用程序的領(lǐng)域?？梢哉f(shuō)，它們提供的功能與 Hadoop 里的 map 和 reduce 有點(diǎn)類似，只不過(guò)它們操作的是實(shí)時(shí)數(shù)據(jù)流，而 Hadoop 則處理更長(zhǎng)時(shí)間片段的數(shù)據(jù)，可能是幾個(gè)小時(shí)或者幾天，Hadoop 會(huì)對(duì)這些數(shù)據(jù)進(jìn)行批處理。通過(guò)使用流式處理框架，用戶可以編寫(xiě)小型應(yīng)用程序來(lái)操作 Kafka 消息，比如計(jì)算度量指標(biāo)，為其他應(yīng)用程序有效地處理消息分區(qū)，或者對(duì)來(lái)自多個(gè)數(shù)據(jù)源的消息進(jìn)行轉(zhuǎn)換。

為什么選擇 Kafka

基于發(fā)布與訂閱的消息系統(tǒng)那么多，為什么 Kafka 會(huì)是一個(gè)更好的選擇呢？

多個(gè)生產(chǎn)者

Kafka 可以無(wú)縫地支持多個(gè)生產(chǎn)者，不管客戶端在使用單個(gè)主題還是多個(gè)主題。所以它很適合用來(lái)從多個(gè)前端系統(tǒng)收集數(shù)據(jù)，并以統(tǒng)一的格式對(duì)外提供數(shù)據(jù)。例如，一個(gè)包含了多個(gè)微服務(wù)的網(wǎng)站，可以為頁(yè)面視圖創(chuàng)建一個(gè)單獨(dú)的主題，所有服務(wù)都以相同的消息格式向該主題寫(xiě)入數(shù)據(jù)。消費(fèi)者應(yīng)用程序會(huì)獲得統(tǒng)一的頁(yè)面視圖，而無(wú)需協(xié)調(diào)來(lái)自不同生產(chǎn)者的數(shù)據(jù)流。

多個(gè)消費(fèi)者

除了支持多個(gè)生產(chǎn)者外，Kafka 也支持多個(gè)消費(fèi)者從一個(gè)單獨(dú)的消息流上讀取數(shù)據(jù)，而且消費(fèi)者之間互不影響。這與其他隊(duì)列系統(tǒng)不同，其他隊(duì)列系統(tǒng)的消息一旦被一個(gè)客戶端讀取，其他客戶端就無(wú)法再讀取它。另外，多個(gè)消費(fèi)者可以組成一個(gè)群組，它們共享一個(gè)消息流，并保證整個(gè)群組對(duì)每個(gè)給定的消息只處理一次。

基于磁盤的數(shù)據(jù)存儲(chǔ)

Kafka 不僅支持多個(gè)消費(fèi)者，還允許消費(fèi)者非實(shí)時(shí)地讀取消息，這要?dú)w功于 Kafka 的數(shù)據(jù)保留特性。消息被提交到磁盤，根據(jù)設(shè)置的保留規(guī)則進(jìn)行保存。每個(gè)主題可以設(shè)置單獨(dú)的保留規(guī)則，以便滿足不同消費(fèi)者的需求，各個(gè)主題可以保留不同數(shù)量的消息。消費(fèi)者可能會(huì)因?yàn)樘幚硭俣嚷蛲话l(fā)的流量高峰導(dǎo)致無(wú)法及時(shí)讀取消息，而持久化數(shù)據(jù)可以保證數(shù)據(jù)不會(huì)丟失。消費(fèi)者可以在進(jìn)行應(yīng)用程序維護(hù)時(shí)離線一小段時(shí)間，而無(wú)需擔(dān)心消息丟失或堵塞在生產(chǎn)者端。消費(fèi)者可以被關(guān)閉，但消息會(huì)繼續(xù)保留在 Kafka 里。消費(fèi)者可以從上次中斷的地方繼續(xù)處理消息。

伸縮性

為了能夠輕松處理大量數(shù)據(jù)，Kafka 從一開(kāi)始就被設(shè)計(jì)成一個(gè)具有靈活伸縮性的系統(tǒng)。用戶在開(kāi)發(fā)階段可以先使用單個(gè) broker，再擴(kuò)展到包含 3 個(gè) broker 的小型開(kāi)發(fā)集群，然后隨著數(shù)據(jù)量不斷增長(zhǎng)，部署到生產(chǎn)環(huán)境的集群可能包含上百個(gè) broker。對(duì)在線集群進(jìn)行擴(kuò)展絲毫不影響整體系統(tǒng)的可用性。也就是說(shuō)，一個(gè)包含多個(gè) broker 的集群，即使個(gè)別 broker 失效，仍然可以持續(xù)地為客戶提供服務(wù)。要提高集群的容錯(cuò)能力，需要配置較高的復(fù)制系數(shù)。

高性能

上面提到的所有特性，讓 Kafka 成為了一個(gè)高性能的發(fā)布與訂閱消息系統(tǒng)。通過(guò)橫向擴(kuò)展生產(chǎn)者、消費(fèi)者和 broker，Kafka 可以輕松處理巨大的消息流。在處理大量數(shù)據(jù)的同時(shí)，它還能保證亞秒級(jí)的消息延遲。

生態(tài)系統(tǒng)

Kafka 為數(shù)據(jù)生態(tài)系統(tǒng)帶來(lái)了循環(huán)系統(tǒng)，如圖所示。它在基礎(chǔ)設(shè)施的各個(gè)組件之間傳遞消息，為所有客戶端提供一致的接口。當(dāng)與提供消息模式的系統(tǒng)集成時(shí)，生產(chǎn)者和消費(fèi)者之間不再有緊密的耦合，也不需要在它們之間建立任何類型的直連。我們可以根據(jù)業(yè)務(wù)需要添加或移除組件，因?yàn)樯a(chǎn)者不再關(guān)心誰(shuí)在使用數(shù)據(jù)，也不關(guān)心有多少個(gè)消費(fèi)者。

受歡迎程度

王國(guó)璋在 “Kafka從0.7到1.0：過(guò)去7年我們踩過(guò)哪些坑？” 這篇文章中提到如下數(shù)據(jù)：2018 年上半年，Confluent 做過(guò)一個(gè)統(tǒng)計(jì)，在福布斯 500 強(qiáng)公司里，大概有 35% 的公司都在使用 Kafka。具體到不同的行業(yè)，全世界前 10 大旅行公司中有 6 個(gè)在使用 Kafka，全世界***的 10 個(gè)銀行有 7 個(gè)在用 Kafka，***的 10 個(gè)保險(xiǎn)公司有 8 個(gè)在用 Kafka，***的 10 個(gè)通訊公司中有 9 個(gè)在用 Kafka。在國(guó)外，Netflix、Uber、Airbnb、PayPal、The New York Times 等都是 Kafka 的重度用戶。

道且長(zhǎng)

Kafka 一直是***的消息隊(duì)列解決方案。近年，Kafka 努力轉(zhuǎn)型為一個(gè)流數(shù)據(jù)平臺(tái)。隨著基礎(chǔ)設(shè)施的云化和容器化，跟容器化架構(gòu)的整合，與既有框架的結(jié)合等是 Kafka 面臨的主要挑戰(zhàn)。在計(jì)算與存儲(chǔ)分離、更好地適應(yīng)容器化架構(gòu)方面，Pulsar 的呼聲漸高。Jesse Anderson 詳細(xì)比較了使用 Kafka  和 Pulsar 創(chuàng)建工作隊(duì)列的優(yōu)缺點(diǎn)，你可以訪問(wèn)jesse-anderson的網(wǎng)站參考這篇文章《Creating Work Queues with Apache Kafka and Apache Pulsar》。未來(lái)，不管哪個(gè)架構(gòu)都需要不斷進(jìn)化。

深入了解與使用

如果你想深入細(xì)致了解使用 Kafka 快速高效地構(gòu)建生產(chǎn)者和消費(fèi)者實(shí)例，使用 Kafka Streams、Kafka Connect 和 KSQL 在流處理和運(yùn)維上提升 Kafka 的平臺(tái)性能，以及整個(gè)生態(tài)系統(tǒng)的發(fā)展趨勢(shì)，那么——

資深大數(shù)據(jù)工程師、培訓(xùn)師 Jesse Anderson 在O’Reilly主辦的 AI  Conference 2019北京站上主講的「Kafka 專業(yè)開(kāi)發(fā)」課程值得學(xué)習(xí)。

即使你并不會(huì)編寫(xiě)復(fù)雜的代碼， KSQL 也會(huì)讓你快速上手流處理。

[[265041]]

導(dǎo)師：Jesse Anderson (Big Data Institute)

Topic: Professional Kafka Development

  下面是一個(gè)為期兩天的培訓(xùn)大綱。

  周三（6月18日）

  Data at scale

• Data movement concepts
• Moving data at scale

  Kafka concepts

• Kafka system
• Basic concepts
• Advanced concepts

  Developing with Kafka

• Using Apache Maven
• Kafka APIs
• Kafka API caveats

  Advanced Kafka development

• Advanced consumers and producers
• Advanced offset handling
• Transactions
• Multithreading consumers

  周四（6月19日）

  Kafka and Avro

• Why serialize
• Avro and serialization formats

  Kafka Connect

• Using Kafka Connect
• Importing from JDBC
• Exporting to HDFS

  Kafka Streams

• Kafka Streams
• The Kafka Streams API

  KSQL

• Using KSQL

  Wrap-up and Q&A

參會(huì)指南

AI Conference 2019北京站正在火熱報(bào)名中，請(qǐng)搜索AI大會(huì)或人工智能大會(huì)，進(jìn)入官網(wǎng)查看講師和議題詳情。