更多騰訊海量技術文章，請關注騰訊雲+社區：https://cloud.tencent.com/developer?fromSource=waitui

本文首發在雲+社區，未經許可，不得轉載。

大家好，我大概簡單的介紹一下，我叫饒軍，我是矽谷的初創公司Con?uent的聯合創始人之一，我們公司的三個創始人都是在最開始在領這個公司做kafka開發出身的。我們公司是2014年成立的，成立的宗旨想把公司做成一個幫助各種各樣企業做基於kafka之上的數據流的事情。

在開始之前，我想大概做一個簡單的調查，在座的有誰用過Kafka。大概有80%的人都用了。好，謝謝。今天跟大家分享，想分享一下我們的項目，Kafka的發展，它是怎麼創建起來的，然後他的一些經歷。說起Kafka的話，那就要回朔到2010年，在這個領域，我是在2010年加入領英，可能很多人都熟悉，這是一個提供人才和機會的社交平台。在2010年的時候，領英初具了一點規模，這也是領英高速成長的一個階段。在2010年我加入領英的時候大概是600號員工，我是2014年離開領英，離開的時候已經發展到6000號員工，在短短的四年的過程這個組織高速發展。在領英的高速發展的過程中，之所以它能有這麼高速發展與數據有不可分割的關係，領英像很多互聯網公司一樣，數據是它的核心，領英有自己的用戶，通過自己提供的服務和用戶交流，用戶把自己的數據直接的或者間接地提供給領英，領英通過做各樣的科研或者分析，可以提取出很多新的見識和認知，這些信息會被反饋到我們的產品上，這個產品就會做得更有效，可以吸引更多的用戶到我們平台，所以如果數據做得好的話，可以形成一個非常好的良性循環，用戶可以得到更多的數據，可以做更好的分析，可以生產更好的產品，又可以吸引到更多的用戶。

數據源的多樣性

從數據上角度來講，領英的數據是非常多元化的，最常見的數據，可能大家都知道這是一種——交易數據，這些數據一般是存在資料庫里的，從領英的角度來講，這種這種交易數據就很簡單，你提供工作簡歷，或者你上學的一些簡歷，包括你和裡面成員的連接關係，都是一種交易性的數據，但是還存在大量的非交易數據，一些很多用戶的行為數據，比如說作為一個用戶，你點了哪個連接，你輸入哪些搜索的關鍵詞，這些其實都是非常有價值的信息。從我們內部的運營來講，有很多的運營服務指標，一些應用程序的日誌，然後到最後我們很多智能手機上的一些信息，這也非常有價值。所以從價值來講，這些非交易性的數據的價值不亞於這些交易性數據的價值。但是從流量上來講，這些非交易型的數據的流量可能是這種交易性數據的一百倍，甚至一千萬倍的數據源。下面就舉一個小的例子，看看領英怎麼用這些數據的理念提供這個服務。

英文叫做people you may know，簡稱PYMK，這個機構做的事情就是提供給領英的用戶一些推薦，他想推薦一些其他的領英的用戶，目前還沒有在你的連接里，他這個推薦是怎麼做的呢？它內部里要用到30到40種信息，把這些信息加起來，使得給你最後一個推薦。舉一些簡單的例子，比如說我們兩個人去過同一個學校，或者在一個公司工作過，這是一個很強的信息，也許我們就是需要連接在一起，但是有很這種非直接的信息，比如說甲和乙兩個人，他們沒有直接這種共同的一些明顯的關係，但是如果在某一個很短的時間，有很多人同時看到這兩個人的簡歷，那說明他們可能還有一些這種隱藏的信息，使得他們值得連在一起。所以在早期的領英，大家使用這個服務的話，就會發現很多的推薦非常神奇。你乍一看的話，可能覺得他怎麼會推薦這麼一個人給我，但是你如果細想一下，就會發現它有很多很強的理由，確實是有些道理，類似的在裡面還有很多的服務，使得他可以用到各種各樣的實時數據。但當時在2010年的時候，我們領英有很大的一塊問題，就是在數據的集成上，其實是一個非常不完善的過程。這個圖大概就介紹了一下當時的狀態，所以在上面我看到這是各種各樣的數據源，領英最開始是一個老牌的互聯網公司，所有的數據都是存在資料庫裡頭，隨著理念的發展，我有一個系統是收集所有的用戶行為的數據，很多的數據都是存在本地的文件里，還有一些其他的信息是存在運行上的日誌里，運行一些識別監測數據。

在下游我們可以看到這是各種各樣的消費端，領英最開始有這種數據倉庫，隨著時間的推移，我們有越來越多實時的微服務，它和這些批處理差不多，也要奪取或多或少同樣的從這些不同數據源而來的信息。像我們剛才講到的這種推薦引擎，它是其中的一個微服務，我們有很多這樣的，還有一些社交的圖形處理，他可以分析兩個節點之間，比如兩個領英的成員，他們之間是怎麼連起來的，哪個連接是最強，還有一些實時的搜索，所以這些數量逐漸增多，而且他們很多的用法是更加的實時，從數據產生到它更新的系統，很多時候是幾秒，甚至更短的一些延時。

點到點的數據集成

所以當時我們的做法是，如果想把這些數據送到從數據源送到消費端的話，做法就是我們說的點到點的數據集成，我們知道有些數據，我們想要的是把這些數據送到數據倉庫里，我們的做法是寫下腳本或者寫一些程序。過了幾天，我們發現很多系統里也需要讀數據，我們又會做一些類似的工作，又在寫下腳本一些程序，所以我們一直在很長一段時間都在做這種類似的東西，但是我寫了五六個類似的數據流之後，發現這是一個非常低效的做法。主要的問題是什麼？第一個我們要解決的問題是一個叉乘問題，是和數據員和數據消費端叉乘的問題。所以每增加一個數據源，就要把這個數據源和所有的消費端都連起來，同樣增加一個消費端的話，消費端需要和所有的數據源直接連接。第二個問題就是我們在做這種點到點的流數據流的時候，每做一個數據流，我們都要重複很多相同的工作，另外每一個數據源，我們都沒有足夠的時間把它做到百分之百的盡善盡美，所以我們覺得這個體系結構不是非常理想。

理想架構

那麼如果要改進的話，應該改進成什麼樣？我們當時想如果有這麼一個體系結構，假設中間這個地方我們有一個集中式的日誌系統，能夠把所有數據源的信息先緩存住，如果能做到這一點，我們就會把這個框架大大的簡化。所以你如果是數據源的話，你不需要知道所有的消費端，你唯一要做的事，就是把你的數據發送給中央的日誌系統。同樣你如果是一個消費端的話，你也不需要知道所有的數據源，你做的事情只是要像這種中央的日誌系統去訂閱你所要的消息，所以我們就把剛才叉乘問題簡化成一個現實問題，關鍵的就是在體系結構裡頭，什麼樣的系統可以做這個中央的日誌系統，所以這是我們當時在討論的事情，我們最開始的話也沒有想重新造一個新的系統，這個好像是一個非常常見的企業級的問題，那這個企業里應該有一個類似的解決方法。如果你仔細看一看，想一想，中央日誌系統從界面角度來講，類似於傳統的消息系統。我們的消息系統一般把這種生產端和消費端分開，然後又是一個非常實時的系統，所以我們想為什麼不嘗試一些現有的消息系統，當時又有一些開源的消息系統，還有一些企業級的消息系統，但我們發現效果非常的不好。具體的原因有很多，但是最重要的一個原因就是這些傳統的消息系統，從它的設計上來講，不是給我們這個用法來設計的，尤其最大的問題就是它的吞吐量。

Kafka第一版：高吞吐發布訂閱消息系統

很多的這種早期的消息，他的設計師給這些資料庫上的數據，這種消費交易型數據來設計，但是你可能很難想像把很多非交易性數據，比如說用戶行為日誌，還有一些這種監測數據，都通過這種傳統的消息來流通。所以在這種情況下，我們覺得我們沒有辦法解決這個問題，但又沒有一個現成的結果，那麼就說我們自己來做一個事情。在2010年左右，我們做了開始做kafka的第一個版本。第一個版本我們的定位也很簡單，就想把它做成一個高吞吐的消息系統，高存儲是我們最重要的目的。

分散式架構

下面的話，我們大概講講我們怎麼實現高吞吐。第一件事我們做了高吞吐，就是把在咖啡的第一個版本里，我們就把它做成一個分散式的框架。很多熟悉kafka的人都知道，kafka裡面有三層，中間這層加服務層下面是生產端，然後下面是消費端。服務端的話一般有一個或者多個節點，基本的概念叫做消息拓片，這個消息源是可以分區的，每一個分區可以放到某一個節點的某一個硬碟上，所以如果想增加吞吐的話，最簡單的方法就是增加集群里的機器，可以有更多的資源，不管是從存儲還是帶寬的角度，你都可以有更多的資源來接受很多的數據，同樣我們生產端和消費端做的也是一個這種多線程的設計。在任何一個情況下，你可以有成千上萬的這種生產端的線程和消費端的線程，從喀斯特機群上寫或者讀取數據。所以這個設計就是說在我們第一個班級有的東西很多，這種老牌的一些消息系統。

簡單實用的日誌存儲

第二點我們做的是使用了一個日誌的存儲結構，這個也非常簡單，但是它是一個非常有效的存儲結構，所以大概是它的一些結構的話是每一個消息源的分區，都會有一個相對應的這麼一個日誌結構，而且日誌結構式和硬碟掛在一起的所有會是通過硬碟來存儲的。這個結構裡面就是每一個小方塊都對應了一個消息，每一個消息有一個代號，代號是連續增加的，如果你是一個生產端的話，你做的事情就是你把你要寫的消息寫到日誌的最後面，你會得到一個新的更大的消息代號日誌，再送到給消費端的話是按順序送的，你按什麼順序寫進去，他就按什麼順序送給消費端，這樣的好處是，從消費端來講你的開銷非常的小，因為不需要記住所有消費端的消息，只需要記住它最後消費過的一個消息的代號。然後記住這個的話，它就可以從這個地方往後繼續消費，因為我們知道所有的消息都是按順序去做發送的，所以在這個消息之前的所有消息應該已經全都被消費過了。

兩個優化

這個設計有幾個好處，第一個好處就是他的訪問的模式非常利於優化，因為不光是從寫的角度還是從讀的角度來講，這個都是線性的寫，讀也是從某一個位置開始線性的讀。所以從這個角度出發，利於操作系統和文件系統來優化它的性能。第二點，我們這個系統設置上可以支持同時多消費，在任何時候你可以有一個或者多個消費者，消費者他可以說從這個地方開始消費，另一個消費者可以從一個不同的地方再消費，但不管你有多少個消費者，這個數據只是存一次，所以從存儲的角度來講，它的性能和你消費的次數是沒有關係的。另外一點並不是很明顯的，由於我們日誌是存在硬碟上的，使得我們可以同時接收實時的消費者，也可以接受一些不實時的批處理的消費者。但是因為所有的數據都在硬碟上，我們可以有一個非常大的緩存，所以不管你是實時還是不實時的，從消費者端的服務方法都是一套的，他不需要做不同的優化，唯一的就是我們依賴這種操作系統來決定哪些數據是可以從內存里提供給消費者，哪些需要從硬碟里來讀。但是從這個框架的設計上都是一樣的。最後一點我們做成這種高吞吐，我們又做了兩個小的優化，這兩個優化是有關聯的，第一個優化就是批處理，所有三個層面在服務端，剛才我們說到這些消息是要存在一個基於硬碟的日誌里，但是寫到硬碟的話它是有一定的開銷，所以我們不是每一個消息就馬上寫了這個硬碟，而是一般會等一段時間，當我們積攢了一些足夠的消息之後，才把他一批寫到硬碟，所以雖然你還有同樣的開銷，但你這個開銷是分攤到很多消息上，同樣在生產端也是這樣，如果你想發送一個消息，我們一般也不是馬上就把這個消息作為一個遠程的請求發送給這個服務端，而是我們也會等一等，希望能夠等到一些更多的消息，把他們一起打包送到這個服務端。和批處理相關的就是數據壓縮，我們壓縮也是在一批數據上進行壓縮，而且是從端到端的壓縮，如果你開啟壓縮的功能的話，再生產端我們先會等一批數據等到一批數據完成之後，我們會把這一批數據一起做一個壓縮，擊壓縮一批數據，往往會得到比這個壓縮每一個消息得到更好的壓縮比例也是。不同的消息往往會有一些這種重複，然後壓縮的數據會被從生產端送到這個服務端，那服務端會把數據壓縮的格式存在日誌裡頭在以壓縮的格式送到消費端，直到消費端在消費一個消息的時候，我們才會把這個消息解壓。所以如果你啟動了壓縮的話，我們不光節省了網路的開銷，還節省了這個寄存開銷，所以這兩個都是非常有效的實現這種高吞吐的方法。所以我們第一個版本kafka做了大概有半年左右的時間，但是我們又花了更多的一點時間把它用到領英的數據線上，因為領英內部有很多的微服務，大概在我們2011年底的時候做完了這件事，這是當時的一些基本的數量。

生產端我們當時有幾十萬的消息被生產出來，然後有上百萬的消息被消費，這個數據在當時還是非常的可觀，而且領英當時有幾百個微服務，上萬個微服務的線程，更重要的是我們在做了這個事情之後，實現了這個領域內部的一個數據的民主化。在沒有kafka之前，你如果是領英的一個工程師或者是一個產品經理，或者是一個數據分析家，你想做一些新的設計或者新的這種應用程序，最困難的問題是你不知道應該用什麼樣的界面去讀取，也不知道這個數據是不是完整。做了kafka這件事情，我們就把這一塊的問題大大的簡化了，大大解放了工程師創新的能力。所以有了成功的經歷，並且感覺kafka的這個系統非常有用，我們又往後做了一些更多的開發，第二部分的開發主要是做一些這種高可用性上的支持。

Kafka第二版：高可用性

第一個版本里的話，每一個消息只是被存在一個節點上，如果那個節點下機的話，那這個數據就沒法獲取了。如果這個機器是永久性的損壞的話，你的數據還會丟失。所以第二版我們做的時候，就是增加了一些這種高可用性，實現方法就是增加的這種多副本的機制。如果群里有多個節點的話，那我們可以把一個消息冗餘的存在多個副本上，同一個小的顏色是多個不同的副本。在同樣的情況，如果你一個機器下線的話，另外一個跡象，如果還有同樣的副本，他還可以繼續持續提供同樣數據的服務。所以有了第二個版本之後，我們就可以把它可能夠包括的數據的面能夠拓展得更廣一點，不光是這種非交易性的時候，一些包括交易性的數據，也可以通過我們的系統來被收集。

在2000年我們還做了一件事，那一年是kafka這個項目被捐贈給了阿帕奇基金會，當時我們做這個事也是覺得我們做的系統至少對領域內部非常有用，那我們就看看是不是對其他的公司也有一些用處，其他的互聯網公司也許也覺得有用，但是我沒有意識到開源了之後，他用途是非常廣泛，所以往往是布局網，不只是局限於這種互聯網的公司而是整個工業界。只要你的公司有些這種實時數據，你需要收集的話都可以用得上。很大的原因是一些各種各樣的傳統的企業，它也在經歷這種軟體化數字化的過程。有一些傳統行業，以前強的地方可能是在那些傳統的製造業，或者說有一些零售點，但現在必須在軟體上或在數據上也能夠比較強才可以。那kafka就從實時這種數據的集成上，給很多企業都提供了非常有效的渠道。在下一步我們經歷了幾年kafka的開發，知道它用途越來越廣，所以我們就想做一件致力於kafka上的事，因為這個事是全職性的工作，所以我們在2014年就離開了領英成立了Con?uent公司。這個公司我們是想為各種各樣的企業提供方便，用的可以更廣一點，現在我們的公司大概是有超過兩百人。

Kafka的發展

下面大概講一講從14年之後我們做了哪些發展。在這之後，kafka我們主要做了兩塊的東西，第一塊和企業級的功能有關的東西，這塊主要是和數據集成有關的。第二塊是和數據流處理有關的。那麼兩方面都會稍微講一講。這個就跳過去了，在企業界上我們做了很大的一塊，和剛才我們最開始講的數據集成的事情有關。很多的這種公司，如果你的公司時間比較長的話，你會發現你數據源是分散在很多的系統里，剛才我們講的就是有kafka之後很方便，你可以把這些數據提取出來，但是不同的公司的話，你不希望每個公司都讀東西來做他們自己的一套東西，所以我們設計的初衷中有兩塊，第一塊是它有一個平台部分，裡面它把很多常見的東西提取出來，做成一個模塊，比如說你需要做一些數據的分布，你需要做一些並行處理，你還需要做一些這種失敗檢測，檢測之後你能再做一些數據平衡，所以這些常見的東西都做到這個模塊裡面，這個模塊裡面又有一個開放式的介面，這個介面可以用來設計實現各種各樣的不同的數據源的連接。在數據的發送端的地方，如果想搜索一些副本，我們也可以做一些類似的事情，所以這是我們做的第一塊。

第二塊做的就是和數據流有關的一個方面。如果你有一個系統，像kafka里能實時把很多的數據收集起來，最開始的用途是當成一個數據傳輸的平台。但是我們覺得加以時間的話，kafka可能並不只局限一個傳輸平台，而且還可以做這種分享合作的平台，有實時數據之後，你常做的一些事情比如說你要做一些這種數據流的出來，比如說把一個數據從一個格式轉到另外一個格式，你可能還想做一些數據的擴充，比如說你有一個數據流，裡面有一些數據的信息，但只有用戶的代號，沒有數據的用戶的具體信息，但是你有一個可能資料庫里有很多更詳細的用戶的信息，如果您能夠把這兩個信息並在一起，這個數據流就更豐富，可以使你做一些更多的更有效的處理。另外你可能也想做一些實時的數據的聚合，應用程序里，我們想把這一塊再簡化。

Kafka的未來

未來的話，我覺得kafka系統不光是一個實時的數據收集和傳輸的平台，更多的可能隨著時間發展的話，它可能還是更多的數據流的處理，交換和共享的一個平台，所以我們會在這個方向上做更多的東西。未來隨著很多的應用更廣，我們覺得很多的應用程序會越來越變成這種實時的應用程序。所以在這個基礎上，我們在kafka上可能會有很強的一套生態系統。

最後給大家分享一個小的故事。這個故事是是我們北美的一個用戶，這個銀行是一個比較傳統的老牌銀行，已經是幾十年的一個歷史銀行，很長時間存在的一個問題是它的數據是非常的分分散的。所以你如果是這個銀行的客戶，你可能有一個銀行的賬戶，你可能有一個貸款，你可能還有一個保險，你可能還有一張信用卡，以前所有這個客戶的信息，因為它都是不同的商業部門，它都是完全分開的。你如果作為一個銀行的銷售人員，你苦惱的事就是沒法知道這個客戶的所有的信息。這個公司它做了一個和Kafka有關的項目，一個項目就是把所有的客戶的不同的數據源信息都實時地收集起來，然後把這個信息推提供給他們上萬個銷售人員，這樣的話銷售人員在做銷售的時候，就會有更有效的一些實時信息可以給客戶做一些更有針對的推薦，所以這個項目就非常成功。

更多分享資料，戳下面的鏈接：

https://ask.qcloudimg.com/draft/1184429/hz4fk5b242.pdf

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！