歡迎大家前往騰訊雲+社群，獲取更多騰訊海量技術實踐乾貨哦~
本文首發在雲+社群，未經許可，不得轉載。
大家好，我大概簡單的介紹一下，我叫饒軍，我是矽谷的初創公司Confluent的聯合創始人之一，我們公司的三個創始人都是在最開始在領這個公司做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年就離開了領英成立了Confluent公司。這個公司我們是想為各種各樣的企業提供方便，用的可以更廣一點，現在我們的公司大概是有超過兩百人。
Kafka的發展
下面大概講一講從14年之後我們做了哪些發展。在這之後，kafka我們主要做了兩塊的東西，第一塊和企業級的功能有關的東西，這塊主要是和資料整合有關的。第二塊是和資料流處理有關的。那麼兩方面都會稍微講一講。這個就跳過去了，在企業界上我們做了很大的一塊，和剛才我們最開始講的資料整合的事情有關。很多的這種公司，如果你的公司時間比較長的話，你會發現你資料來源是分散在很多的系統裡，剛才我們講的就是有kafka之後很方便，你可以把這些資料提取出來，但是不同的公司的話，你不希望每個公司都讀東西來做他們自己的一套東西，所以我們設計的初衷中有兩塊，第一塊是它有一個平臺部分，裡面它把很多常見的東西提取出來，做成一個模組，比如說你需要做一些資料的分佈，你需要做一些並行處理，你還需要做一些這種失敗檢測，檢測之後你能再做一些資料平衡，所以這些常見的東西都做到這個模組裡面，這個模組裡面又有一個開放式的介面，這個介面可以用來設計實現各種各樣的不同的資料來源的連線。在資料的傳送端的地方，如果想搜尋一些副本，我們也可以做一些類似的事情，所以這是我們做的第一塊。
第二塊做的就是和資料流有關的一個方面。如果你有一個系統，像kafka裡能實時把很多的資料收集起來，最開始的用途是當成一個資料傳輸的平臺。但是我們覺得加以時間的話，kafka可能並不只侷限一個傳輸平臺，而且還可以做這種分享合作的平臺，有實時資料之後，你常做的一些事情比如說你要做一些這種資料流的出來，比如說把一個資料從一個格式轉到另外一個格式，你可能還想做一些資料的擴充，比如說你有一個資料流，裡面有一些資料的資訊，但只有使用者的代號，沒有資料的使用者的具體資訊，但是你有一個可能資料庫裡有很多更詳細的使用者的資訊，如果您能夠把這兩個資訊並在一起，這個資料流就更豐富，可以使你做一些更多的更有效的處理。另外你可能也想做一些實時的資料的聚合，應用程式裡，我們想把這一塊再簡化。
Kafka的未來
未來的話，我覺得kafka系統不光是一個實時的資料收集和傳輸的平臺，更多的可能隨著時間發展的話，它可能還是更多的資料流的處理，交換和共享的一個平臺，所以我們會在這個方向上做更多的東西。未來隨著很多的應用更廣，我們覺得很多的應用程式會越來越變成這種實時的應用程式。所以在這個基礎上，我們在kafka上可能會有很強的一套生態系統。
最後給大家分享一個小的故事。這個故事是是我們北美的一個使用者，這個銀行是一個比較傳統的老牌銀行，已經是幾十年的一個歷史銀行，很長時間存在的一個問題是它的資料是非常的分分散的。所以你如果是這個銀行的客戶，你可能有一個銀行的賬戶，你可能有一個貸款，你可能還有一個保險，你可能還有一張信用卡，以前所有這個客戶的資訊，因為它都是不同的商業部門，它都是完全分開的。你如果作為一個銀行的銷售人員，你苦惱的事就是沒法知道這個客戶的所有的資訊。這個公司它做了一個和Kafka有關的專案，一個專案就是把所有的客戶的不同的資料來源資訊都實時地收集起來，然後把這個資訊推提供給他們上萬個銷售人員，這樣的話銷售人員在做銷售的時候，就會有更有效的一些實時資訊可以給客戶做一些更有針對的推薦，所以這個專案就非常成功。
更多分享資料，戳下面的連結：
ask.qcloudimg.com/draft/11844…
問答
apache kafka vs apache storm如何使用？
相關閱讀
白瑜慶：知乎基於Kubernetes的kafka平臺的設計和實現
此文已由作者授權騰訊雲+社群釋出，原文連結：https://cloud.tencent.com/developer/article/1114675?fromSource=waitui
