前言：前段時(shí)間接觸過一個(gè)流式計(jì)算的任務(wù)，使用了阿里巴巴集團(tuán)的JStorm，發(fā)現(xiàn)這個(gè)領(lǐng)域值得探索，就發(fā)現(xiàn)了這篇文章——Putting Apache Kafka To Use: A Practical Guide to Building a Stream Data Platform（Part 1）。在讀的過程中半總結(jié)半翻譯，形成本文，跟大家分享。
最近你可能聽說很多技術(shù)名詞，例如“流式處理”、“事件數(shù)據(jù)”以及“實(shí)時(shí)”等，與之相關(guān)的技術(shù)有Kafka、Storm、Samza或者是Spark的Steam Model。這些新興的技術(shù)令人興奮，不過還沒有多少人知道如何將這些技術(shù)添加到自己的技術(shù)棧中，如何實(shí)際應(yīng)用于項(xiàng)目中。
這篇指南討論我們關(guān)于實(shí)時(shí)數(shù)據(jù)流的工程經(jīng)驗(yàn)：如何在你的公司內(nèi)部搭建實(shí)時(shí)數(shù)據(jù)平臺(tái)、如何使用這些數(shù)據(jù)構(gòu)建應(yīng)用程序，所有這些都是基于實(shí)際經(jīng)驗(yàn)——我們在Linkdin花了五年時(shí)間構(gòu)建Apache Kafka，將Linkdin轉(zhuǎn)換為流式數(shù)據(jù)架構(gòu)，并幫助硅谷的很多技術(shù)公司完成了同樣的工作。
這份指南的第一部分是關(guān)于流式數(shù)據(jù)平臺(tái)（steam data platform）的概覽：什么是流式數(shù)據(jù)平臺(tái)，為什么要構(gòu)建流式數(shù)據(jù)平臺(tái)；第二部分將深入細(xì)節(jié)，給出一些操作規(guī)范和最佳實(shí)踐。
何為流式數(shù)據(jù)平臺(tái)？
流式數(shù)據(jù)平臺(tái)：簡潔、輕量的事件處理
我們在Linkein構(gòu)建Apache Kafka的目的是讓它作為數(shù)據(jù)流的中央倉庫工作，但是為什么要做這個(gè)工作，有下面兩個(gè)原因：
- 數(shù)據(jù)整合：數(shù)據(jù)如何在各個(gè)系統(tǒng)之間流轉(zhuǎn)和傳輸；
- 流式處理：通常在數(shù)據(jù)倉庫或者Hadoop集群中需要做豐富的數(shù)據(jù)分析，同時(shí)實(shí)現(xiàn)低延時(shí)。
接下來介紹下上述兩個(gè)理論的提出過程。起初我們并沒有意識(shí)到這些問題之間有聯(lián)系，我們采取了臨時(shí)方案：只要需要，就在系統(tǒng)和應(yīng)用程序之間建造數(shù)據(jù)通道或者給web服務(wù)發(fā)送異步請求。隨著時(shí)間推移，系統(tǒng)越來越復(fù)雜，我們在幾乎所有子系統(tǒng)之間都建立了不同的數(shù)據(jù)通道：
每個(gè)數(shù)據(jù)通道都有自己的問題：日志數(shù)據(jù)的規(guī)模很大但是數(shù)據(jù)有缺失，并且數(shù)據(jù)傳輸?shù)难舆t很高；Oracle數(shù)據(jù)庫實(shí)例之間的數(shù)據(jù)傳輸速度快、準(zhǔn)確而且實(shí)時(shí)性好，但是其他系統(tǒng)不能及時(shí)快速得獲得這些數(shù)據(jù)；Oracle數(shù)據(jù)庫的數(shù)據(jù)到Hadoop集群的數(shù)據(jù)通道吞吐量很高，但是只能進(jìn)行批次操作；搜索系統(tǒng)數(shù)據(jù)通道的延遲低，不過數(shù)據(jù)規(guī)模小，并且是直接連接數(shù)據(jù)庫；消息系統(tǒng)數(shù)據(jù)通道的延遲低，但是不可靠且規(guī)模小。
隨著我們在全球各地添加數(shù)據(jù)中心，我們也要為這些數(shù)據(jù)流添加對(duì)應(yīng)的副本；隨著系統(tǒng)規(guī)模的增長，對(duì)應(yīng)的數(shù)據(jù)通道規(guī)模也應(yīng)該相應(yīng)得增長，整個(gè)系統(tǒng)面臨的壓力越來越大。我認(rèn)為我的團(tuán)隊(duì)與其說是由分布式系統(tǒng)工程師組成，還不如說是由一些管道工組成。
更糟的是，復(fù)雜性過高導(dǎo)致數(shù)據(jù)不可靠。由于數(shù)據(jù)的索引和存儲(chǔ)存在問題，導(dǎo)致我們的報(bào)告可信度降低。員工需要花費(fèi)大量時(shí)間處理各種類型的臟數(shù)據(jù)，記得有在處理一起故障中，我們在兩個(gè)系統(tǒng)中發(fā)現(xiàn)一些非常類似但存在微小差異的數(shù)據(jù)，我們費(fèi)了很大力氣檢查這兩個(gè)數(shù)據(jù)哪個(gè)是爭取額的，最后發(fā)現(xiàn)兩個(gè)都不對(duì)。
與此同時(shí)，我們除了要做數(shù)據(jù)遷移，還想對(duì)數(shù)據(jù)進(jìn)行進(jìn)一步的處理和分析。Hadoop平臺(tái)提供了批處理、數(shù)據(jù)打包和專案（ad hoc）處理能力，但是我們還需要一個(gè)實(shí)時(shí)性更好的數(shù)據(jù)處理平臺(tái)。我們的很多系統(tǒng)——特別是監(jiān)控系統(tǒng)、搜索索引的數(shù)據(jù)通道、數(shù)據(jù)分析應(yīng)用以及安全分析應(yīng)用，都需要秒級(jí)的響應(yīng)速度，但是這類型的應(yīng)用在上圖的系統(tǒng)架構(gòu)中表現(xiàn)很差。
2010年左右，我們開始構(gòu)建一個(gè)系統(tǒng)：專注于實(shí)時(shí)獲取流式數(shù)據(jù)（stream data），并規(guī)定各個(gè)系統(tǒng)之間的數(shù)據(jù)交互機(jī)制也以流式數(shù)據(jù)為承載，同時(shí)還允許對(duì)這些流式數(shù)據(jù)進(jìn)行實(shí)時(shí)處理。這就是Apache Kafka的原型。
我們對(duì)整個(gè)系統(tǒng)的構(gòu)想如下所示：
很長一段時(shí)間內(nèi)我們都沒有為我們所構(gòu)建的這個(gè)系統(tǒng)取名字，僅僅稱之為“Kafka stuff”或者“global commit log thingy”，隨著時(shí)間推移，我們開始將這個(gè)系統(tǒng)中的數(shù)據(jù)稱之為流式數(shù)據(jù)（steam data），而負(fù)責(zé)處理這種類型的數(shù)據(jù)的平臺(tái)稱之為流式數(shù)據(jù)平臺(tái)（steam data platform）。
最終我們的系統(tǒng)從前文描述的跟“意大利面條”一樣雜亂進(jìn)化為清晰的以流式數(shù)據(jù)平臺(tái)為中心的系統(tǒng)：
在這個(gè)系統(tǒng)中Kafka的角色是通用數(shù)據(jù)管道。每個(gè)子系統(tǒng)都可以很容易得接入到這個(gè)中央數(shù)據(jù)管道上；流式處理應(yīng)用可以接入到該數(shù)據(jù)管道上，并對(duì)外提供經(jīng)過處理后的流式數(shù)據(jù)。這種固定格式的數(shù)據(jù)類型成為各個(gè)子系統(tǒng)、應(yīng)用和數(shù)據(jù)中心之間的通用語言。舉個(gè)例子說明：如果一個(gè)用戶更新了他的個(gè)人信息，這個(gè)更新信息會(huì)流入我們的系統(tǒng)處理層，在系統(tǒng)處理層會(huì)對(duì)該用戶的公司信息、地理位置和其他屬性進(jìn)行標(biāo)準(zhǔn)化處理；然后這個(gè)數(shù)據(jù)流會(huì)流入搜索引擎和社區(qū)地圖用于查詢和檢索、這個(gè)數(shù)據(jù)也會(huì)流入推薦系統(tǒng)進(jìn)行工作匹配；所有的這些動(dòng)作只需要毫秒量級(jí)的時(shí)間，最后這些數(shù)據(jù)會(huì)流入Hadoop數(shù)據(jù)倉庫。
LinkedIn內(nèi)部在大量使用這套系統(tǒng)，每天為數(shù)百個(gè)數(shù)據(jù)中心處理超過5000億事件請求，該系統(tǒng)已經(jīng)成為其他系統(tǒng)的數(shù)據(jù)后臺(tái)、成為Hadoop集群的數(shù)據(jù)管道，以及流式處理的Hub。
由于Kafka開源，因此有很多公司在做類似的事情：Kafka Powered By
接下來我們將論述流式數(shù)據(jù)平臺(tái)的一些細(xì)節(jié)：該平臺(tái)的工作原理、該平臺(tái)解決了什么重要問題。
流式數(shù)據(jù)（Steam Data）
大部分業(yè)務(wù)邏輯可以理解為事件流（steam of events）。零售業(yè)有訂單流、交易流、物流信息流、價(jià)格調(diào)整事件流，以及各類調(diào)用的返回值等等；金融行業(yè)有訂單流、股票價(jià)格變更事件流，以及其他金融行業(yè)的信息流；網(wǎng)站有點(diǎn)擊流、關(guān)注流（impressions）、搜索流等等。在大規(guī)模的軟件系統(tǒng)中還有請求流、錯(cuò)誤流、機(jī)器監(jiān)控信息流和日志流。總之，業(yè)務(wù)邏輯可以從整體上當(dāng)作一種數(shù)據(jù)處理系統(tǒng)——接收多種輸入流并產(chǎn)生對(duì)應(yīng)的輸出流（有時(shí)還會(huì)產(chǎn)生具體的物理產(chǎn)品）。
這種概念對(duì)于習(xí)慣于將數(shù)據(jù)想象為數(shù)據(jù)庫中的一行的同學(xué)可能有點(diǎn)陌生，接下來我們看一點(diǎn)關(guān)于事件流數(shù)據(jù)的實(shí)際例子。
事件觸發(fā)和事件流
數(shù)據(jù)庫中存放的是數(shù)據(jù)的當(dāng)前狀態(tài)，當(dāng)前狀態(tài)是過去的某些動(dòng)作（action）的結(jié)果，這些動(dòng)作就是事件。庫存表保存購買和交易事件產(chǎn)生的結(jié)果，銀行結(jié)余存放信貸和借記事件的結(jié)果；Web Server的延時(shí)圖是一系列HTTP請求的聚合。
當(dāng)談?wù)摯髷?shù)據(jù)時(shí)，很多人更青睞于記錄上述提到的這些事件流，并在此基礎(chǔ)上進(jìn)行分析、優(yōu)化和決策。某種層度上來說，這些事件流是傳統(tǒng)的數(shù)據(jù)庫沒有反應(yīng)出來的一面：它們表示業(yè)務(wù)邏輯。
事件流數(shù)據(jù)在金融行業(yè)已經(jīng)廣泛使用：股票發(fā)行、市場預(yù)測、股票交易等數(shù)據(jù)都可以當(dāng)作是事件流，但是技術(shù)屆使得搜集和使用這些數(shù)據(jù)的現(xiàn)代技術(shù)開始流行。Google將廣告點(diǎn)擊流和廣告效果轉(zhuǎn)化為幾十億美金的收入。在web開發(fā)屆，這些事件數(shù)據(jù)又被稱為日志數(shù)據(jù)，由于缺乏針對(duì)日志處理的模塊，這些日志事件就存放在日志文件中。Hadoop之類的系統(tǒng)經(jīng)常用于日志處理，但是根據(jù)實(shí)際情況，稱之為“批量事件存儲(chǔ)和處理（batch event storage and processing）”更合適。
網(wǎng)絡(luò)公司應(yīng)該是最早開始記錄事件流的公司，搜集網(wǎng)站上的事件數(shù)據(jù)非常容易：在某些特定節(jié)點(diǎn)加一些代碼即可記錄和跟蹤每個(gè)用戶在改網(wǎng)站上的行為。即使是一個(gè)單頁面或者是某個(gè)流行網(wǎng)站上的移動(dòng)窗口也能記錄很多類似的行為數(shù)據(jù)用于分析和監(jiān)控。
你可能聽說過“機(jī)器產(chǎn)生的數(shù)據(jù)”這個(gè)概念，其實(shí)跟事件數(shù)據(jù)表示相同的含義。某種程度上所有的數(shù)據(jù)都是機(jī)器產(chǎn)生的，因?yàn)檫@些數(shù)據(jù)來自計(jì)算機(jī)系統(tǒng)。
還有很多人在談?wù)撛O(shè)備數(shù)據(jù)和“物聯(lián)網(wǎng)（internet of things）”。不同的人對(duì)這些名詞有各自的理解，但是這個(gè)物聯(lián)網(wǎng)的核心也在于針對(duì)某些數(shù)據(jù)集進(jìn)行分析和決策，只不過我們這里的分析對(duì)象是大規(guī)模網(wǎng)絡(luò)系統(tǒng)，而物聯(lián)網(wǎng)的分析對(duì)象是工業(yè)設(shè)備或者消費(fèi)產(chǎn)品。
數(shù)據(jù)庫是事件流
事件流數(shù)據(jù)很適合描述日志數(shù)據(jù)或諸如訂單、交易、點(diǎn)擊和貿(mào)易這些具備明顯事件特征的數(shù)據(jù)。和大多數(shù)開發(fā)人員相同，你可能將自己系統(tǒng)的大部分?jǐn)?shù)據(jù)保存在各種數(shù)據(jù)庫中：關(guān)系型數(shù)據(jù)庫（Oracle、MySQL和Postgres）或者新興的分布式數(shù)據(jù)庫（MongoDB、Cassandra和Couchbase），這些數(shù)據(jù)可能不容易理解為事件或者事件流。
但實(shí)際上，數(shù)據(jù)庫中存儲(chǔ)的數(shù)據(jù)也可理解為一種事件流（event steam），簡單來說，數(shù)據(jù)庫可以理解為創(chuàng)建數(shù)據(jù)備份或者建立備庫的過程。做數(shù)據(jù)備份的主要方法是周期性得導(dǎo)出數(shù)據(jù)庫內(nèi)容，然后將這些數(shù)據(jù)導(dǎo)入到備庫中。如果我很少進(jìn)行數(shù)據(jù)備份，或者是我的數(shù)據(jù)量不大，那么可以進(jìn)行全量備份。實(shí)際上，隨著備份頻率的提高，全量備份不再可行：如果兩天做一次全量備份，將會(huì)耗費(fèi)兩倍的系統(tǒng)資源、如果每個(gè)小時(shí)做一次全量備份，則會(huì)耗費(fèi)24倍的系統(tǒng)資源。在大規(guī)模數(shù)據(jù)的備份中，顯然增量備份更加有效：只增加新創(chuàng)建的、更新的數(shù)據(jù)和刪除對(duì)應(yīng)的數(shù)據(jù)。利用增量備份，如過我們將備份頻率提高為原來的1倍，則每次備份的數(shù)量將減少幾乎一半，消耗的系統(tǒng)資源也差不多。
那么為什么我們不盡可能提高增量備份的頻率呢？我們可以做到，但是最后只會(huì)得到一系列單行數(shù)據(jù)改變的記錄——這種事件流稱之為變更記錄，很多數(shù)據(jù)庫系統(tǒng)都有負(fù)責(zé)這個(gè)工作的模塊（Oracle數(shù)據(jù)庫系統(tǒng)中的XStreams和GoldenGate、MySQL有binlog replication、Postgres有Logical Log Steaming Replication）。
綜上，數(shù)據(jù)庫的變更過程也可以作為事件流的一部分。你可以通過這些事件流同步Hadoop集群、同步備庫或者搜索索引；你還可以將這些事件流接入到特定的應(yīng)用或者流式處理應(yīng)用中，從而發(fā)掘或者分析出新的結(jié)論。
流式數(shù)據(jù)平臺(tái)解決的問題？
流式數(shù)據(jù)平臺(tái)有兩個(gè)主要應(yīng)用：
- 數(shù)據(jù)整合：流式數(shù)據(jù)平臺(tái)搜集事件流或者數(shù)據(jù)變更信息，并將這些變更輸送到其他數(shù)據(jù)系統(tǒng)，例如關(guān)系型數(shù)據(jù)庫、key-value存儲(chǔ)系統(tǒng)、Hadoop或者其他數(shù)據(jù)倉庫。
- 流式處理：對(duì)流式數(shù)據(jù)進(jìn)行持續(xù)、實(shí)時(shí)的處理和轉(zhuǎn)化，并將結(jié)果在整個(gè)系統(tǒng)內(nèi)開放。
在角色1中，流式數(shù)據(jù)平臺(tái)就像數(shù)據(jù)流的中央集線器。與之交互的應(yīng)用程序不需要考慮數(shù)據(jù)源的細(xì)節(jié)，所有的數(shù)據(jù)流都以同一種數(shù)據(jù)格式表示；流式數(shù)據(jù)平臺(tái)還可以作為其他子系統(tǒng)之間的緩沖區(qū)（buffer）——數(shù)據(jù)的提供者不需要關(guān)心最終消費(fèi)和處理這些數(shù)據(jù)的其他系統(tǒng)。這意味著數(shù)據(jù)的消費(fèi)者與數(shù)據(jù)源可以完全解耦合。
如果你需要部署一個(gè)新的系統(tǒng)，你只需要將新系統(tǒng)接入到流式數(shù)據(jù)平臺(tái)，而不需要為每個(gè)特定的需求選擇（并管理）各自的數(shù)據(jù)庫和應(yīng)用程序。不論數(shù)據(jù)最初來自日志文件、數(shù)據(jù)庫、Hadoop集群或者流式處理系統(tǒng)，這些數(shù)據(jù)流都使用相同的格式。在流式數(shù)據(jù)平臺(tái)上部署新系統(tǒng)非常容易，新系統(tǒng)只需要跟流式數(shù)據(jù)平臺(tái)交互，而不需要跟各種具體的數(shù)據(jù)源交互。
Hadoop集群的設(shè)計(jì)目標(biāo)是管理公司的全量數(shù)據(jù)，直接從HDFS中獲取數(shù)據(jù)是非常耗費(fèi)時(shí)間的方案，而且直接獲取的數(shù)據(jù)不能直接用于實(shí)時(shí)處理和同步。但是，這個(gè)問題可以反過來看：Hadoop等數(shù)據(jù)倉庫可以主動(dòng)將結(jié)果以流式數(shù)據(jù)的格式推送給其他子系統(tǒng)中。
流式數(shù)據(jù)平臺(tái)的角色2包含數(shù)據(jù)聚合用例，系統(tǒng)搜集各類數(shù)據(jù)形成數(shù)據(jù)流，然后存入Hadoop集群歸檔，這個(gè)過程就是一個(gè)持續(xù)的流式數(shù)據(jù)處理。流式處理的輸出還是數(shù)據(jù)流，同樣可以加載到其他數(shù)據(jù)系統(tǒng)中。
流式處理可以使用通過簡單的應(yīng)用代碼實(shí)現(xiàn)，這些處理代碼處理事件流并產(chǎn)生新的事件流，這類工作可以通過一些流行的流式處理框架完成——Storm、Samza或Spark Streaming，這些框架提供了豐富的API接口。這些框架發(fā)展得都不錯(cuò)，同時(shí)它們跟Apache Kafka的交互都很好。
流式數(shù)據(jù)平臺(tái)需要提供的能力？
在上文中我提到了一些不同的用例，每個(gè)用例都有對(duì)應(yīng)的事件流，但是每個(gè)事件流的需求又有所不同——有些事件流要求快速響應(yīng)、有些事件流要求高吞吐量、有些事件流要求可擴(kuò)展性等等。如果我們想讓一個(gè)平臺(tái)滿足這些不同的需求，這個(gè)平臺(tái)應(yīng)該提供什么能力？
我認(rèn)為對(duì)于一個(gè)流式數(shù)據(jù)平臺(tái)，應(yīng)該滿足下列關(guān)鍵需求：
- 它必須足夠可靠，以便于處理嚴(yán)苛的更新，例如將某個(gè)數(shù)據(jù)庫的更新日志變更為搜索索引的存儲(chǔ)，能夠順序傳輸數(shù)據(jù)并保證不丟失數(shù)據(jù)；
- 它必須具備足夠大的吞吐量，用于處理大規(guī)模日志或者事件數(shù)據(jù)；
- 它必須具備緩沖或者持久化數(shù)據(jù)的能力，用于與Hadoop這類批處理系統(tǒng)交互。
- 它必須能夠?yàn)閷?shí)時(shí)處理程序?qū)崟r(shí)提供數(shù)據(jù)，即延時(shí)要足夠低；
- 它必須具備良好的擴(kuò)展性，可以應(yīng)付整個(gè)公司的滿負(fù)載運(yùn)行，并能夠集成成百上千個(gè)不同團(tuán)隊(duì)的應(yīng)用程序，這些應(yīng)用以插件的形式與流式數(shù)據(jù)平臺(tái)整合。
- 它必須能和實(shí)時(shí)處理框架良好得交互
流式數(shù)據(jù)平臺(tái)是整個(gè)公司的核心系統(tǒng)，用于管理各種類型的數(shù)據(jù)流，如果該系統(tǒng)不能提供良好的可靠性以及可擴(kuò)展性，系統(tǒng)會(huì)隨著數(shù)據(jù)量的增長而再次遭遇瓶頸；如果該系統(tǒng)不支持批處理和實(shí)時(shí)處理，那么就不能與Hadoop或者Storm這類系統(tǒng)整合。
Apache Kafka
Apache Kafka是專門處理流式數(shù)據(jù)的分布式系統(tǒng)，它具備良好的容錯(cuò)性、高吞吐量、支持橫向擴(kuò)展，并允許地理位置分布的流式數(shù)據(jù)處理。
Kafka常常被歸類于消息處理系統(tǒng)，它確實(shí)扮演了類似的角色，但同時(shí)也提供了其他的抽象接口。在Kafka中最關(guān)鍵的抽象數(shù)據(jù)結(jié)構(gòu)是用于記錄更新的commit log：
數(shù)據(jù)生產(chǎn)者向commit log隊(duì)列中發(fā)送記錄流，其他消費(fèi)者可以像水流一樣在毫秒級(jí)延時(shí)處理這些日志的最新信息。每個(gè)數(shù)據(jù)消費(fèi)者在commit log中有一個(gè)自己的位置（指針），并獨(dú)立移動(dòng)，這使得可靠、順序更新能夠分布式得發(fā)送給每個(gè)消費(fèi)者。
這個(gè)commit log的作用非常關(guān)鍵：可以多個(gè)生產(chǎn)者和消費(fèi)者共享，并覆蓋一個(gè)集群中的多臺(tái)機(jī)器，每臺(tái)機(jī)器都可用作容錯(cuò)保障；可以提供一個(gè)并行模型，其具備的順序消費(fèi)的特點(diǎn)使得Kafka可以用于記錄數(shù)據(jù)庫的變更。
Kafka是一個(gè)現(xiàn)代的分布式系統(tǒng)，存儲(chǔ)在一個(gè)集群的數(shù)據(jù)（副本和分片存儲(chǔ)）可以水平擴(kuò)張和縮小，同時(shí)上層應(yīng)用對(duì)此毫無感知。數(shù)據(jù)消費(fèi)者的機(jī)器數(shù)量可以隨數(shù)據(jù)規(guī)模的增長而水平增加，同時(shí)可以自動(dòng)應(yīng)對(duì)數(shù)據(jù)處理過程中發(fā)生的錯(cuò)誤。
Kafka的一個(gè)關(guān)鍵設(shè)計(jì)是對(duì)持久化的處理相當(dāng)好，Kafka的消息代理（broker）可以存儲(chǔ)TB量級(jí)的數(shù)據(jù)，這使得Kafka能夠完成一些傳統(tǒng)數(shù)據(jù)庫無法勝任的任務(wù)：
- 接入Kafka的Hadoop集群或者其他離線系統(tǒng)可以放心得停機(jī)維護(hù)，間隔幾小時(shí)或者幾天后再平滑接入，因?yàn)樵谒C(jī)期間到達(dá)的流式數(shù)據(jù)被存儲(chǔ)在Kafka的上行集群。
- 在首次執(zhí)行同步數(shù)據(jù)庫的任務(wù)時(shí)可以執(zhí)行全量備份，以便讓下行消費(fèi)者訪問全量數(shù)據(jù)。
上述這些特性使得Kafka能夠提供比傳統(tǒng)的消息系統(tǒng)更廣的應(yīng)用范圍。
事件驅(qū)動(dòng)的應(yīng)用
自從我們將Kafka開源后，我們有很多機(jī)會(huì)與其他想做類似的事情的公司交流和合作：研究如何Kafka系統(tǒng)的部署以及Kafka在該公司內(nèi)部技術(shù)架構(gòu)的角色如何隨著時(shí)間演進(jìn)和改變。
初次部署常常用于單個(gè)的大規(guī)模應(yīng)用：日志數(shù)據(jù)處理，并接入Hadoop集群；也可能是其他數(shù)據(jù)流，該數(shù)據(jù)流的規(guī)模太大以至于超出了該公司原有的消息系統(tǒng)的處理能力。
從這些用例延伸開來，在接入Hadoop集群后，很快就需要提供實(shí)時(shí)數(shù)據(jù)處理的能力，現(xiàn)存的應(yīng)用需要擴(kuò)展和重構(gòu)，利用現(xiàn)有的實(shí)時(shí)處理框架更高效得處理流式數(shù)據(jù)。以LinkedIn為例，我們最開始是利用Kafka處理job信息流，并將job信息存入Hadoop集群，然后很多ETL-centric的應(yīng)用需求開始出現(xiàn)，這些job信息流開始用于其他子系統(tǒng)，如下圖所示：
在這張圖中，job的定義不需要一些定制就可以與其他子系統(tǒng)交互，當(dāng)上游應(yīng)用（移動(dòng)應(yīng)用）上出現(xiàn)新的工作信息時(shí)，就會(huì)通過Kafka發(fā)送一個(gè)全局事件，下游的數(shù)據(jù)處理應(yīng)用只需要響應(yīng)這個(gè)事件即可。
流式數(shù)據(jù)平臺(tái)與現(xiàn)存中間件的關(guān)系
我們簡單講下流式數(shù)據(jù)平臺(tái)與現(xiàn)存的類似系統(tǒng)的關(guān)系。
消息系統(tǒng)（Messaging）
流式數(shù)據(jù)平臺(tái)類似于企業(yè)消息系統(tǒng)——它接收消息事件，并把它們發(fā)布到對(duì)應(yīng)事件的訂閱者。不過，二者有三個(gè)重要的不同：
- 消息系統(tǒng)通常是作為某個(gè)應(yīng)用中的一個(gè)組件來部署，不同的應(yīng)用中有不同的消息系統(tǒng)，而流式數(shù)據(jù)平臺(tái)希望成為整個(gè)企業(yè)的數(shù)據(jù)流Hub。
- 消息系統(tǒng)與批處理系統(tǒng)（數(shù)據(jù)倉庫或者Hadoop集群）的交互性很差，因?yàn)橄⑾到y(tǒng)的數(shù)據(jù)存儲(chǔ)容量有限；
- 消息系統(tǒng)并未提供與實(shí)時(shí)處理框架整合的API接口。
換句話說，流式數(shù)據(jù)平臺(tái)可以看作在公司級(jí)別（消息系統(tǒng)的級(jí)別是項(xiàng)目）設(shè)計(jì)的消息系統(tǒng)。
數(shù)據(jù)聚合工具（Data Integration Tools）
為了便于跟其他系統(tǒng)整合，流式數(shù)據(jù)平臺(tái)做了很多工作。它的角色跟Informatica這類工具不同，流式數(shù)據(jù)平臺(tái)是可以讓任何系統(tǒng)接入，并可以圍繞該平臺(tái)構(gòu)建不同的應(yīng)用。
流式數(shù)據(jù)平臺(tái)與數(shù)據(jù)聚合工具有一點(diǎn)重合的實(shí)踐：使用一個(gè)統(tǒng)一的數(shù)據(jù)流抽象，保證數(shù)據(jù)格式相同，這樣可以避免很多數(shù)據(jù)清洗任務(wù)。我會(huì)在這個(gè)系列文章的第二篇仔細(xì)論述這個(gè)主題。
企業(yè)服務(wù)總線（Enterprise Service Buses）
我認(rèn)為流式數(shù)據(jù)平臺(tái)借鑒了很多企業(yè)服務(wù)總線的設(shè)計(jì)思想，不過提供了更好的實(shí)現(xiàn)方案。企業(yè)服務(wù)總線面臨的挑戰(zhàn)就是自身的數(shù)據(jù)傳輸效率很低；企業(yè)服務(wù)總線在部署時(shí)也面臨一些挑戰(zhàn)：不適合多租戶使用（PS，此處需要看下原文，歡迎指導(dǎo)）。
流式數(shù)據(jù)平臺(tái)的優(yōu)勢在于數(shù)據(jù)的傳輸與系統(tǒng)本身解耦合，數(shù)據(jù)的傳輸由各個(gè)應(yīng)用自身完成，這樣就能避免平臺(tái)自身成為瓶頸。
變更記錄系統(tǒng)（Change Capture Systems）
常規(guī)的數(shù)據(jù)庫系統(tǒng)都有類似的日志機(jī)制，例如Golden Gate，然而這個(gè)日志記錄機(jī)制僅限于數(shù)據(jù)庫使用，并不能作為通用的事件記錄平臺(tái)。這些數(shù)據(jù)庫自帶的日志記錄機(jī)制主要用于同類型數(shù)據(jù)庫（eg：Oracle-to-Oracle）之前的互相備份。
數(shù)據(jù)倉庫和Hadoop
流式數(shù)據(jù)平臺(tái)并不能替代數(shù)據(jù)倉庫，恰恰相反，它為數(shù)據(jù)倉庫提供數(shù)據(jù)源。它的身份是一個(gè)數(shù)據(jù)管道，將數(shù)據(jù)傳輸?shù)綌?shù)據(jù)倉庫，用于長期轉(zhuǎn)化、數(shù)據(jù)分析和批處理。這個(gè)數(shù)據(jù)管道也為數(shù)據(jù)倉庫提供對(duì)外輸出結(jié)果數(shù)據(jù)的功能。
流式處理系統(tǒng)（Steam Processing Systems）
常用的流式處理框架，例如Storm、Samza或Spark Streaming可以很容易得跟流式數(shù)據(jù)平臺(tái)整合。這些流式數(shù)據(jù)處理框架提供了豐富的API接口，可以簡化數(shù)據(jù)轉(zhuǎn)化和處理。
流式數(shù)據(jù)平臺(tái)的落地與實(shí)踐
我們不只是提出了一個(gè)很好的想法，我們面臨的需求很適合將自己的想法落地。過去五年我們都在構(gòu)建Kafka系統(tǒng)，幫助其他公司落地流式數(shù)據(jù)平臺(tái)。今天，在硅谷有很多公司在實(shí)踐這套設(shè)計(jì)思路，每個(gè)用戶的行為都被實(shí)時(shí)記錄并處理。
前瞻
我們一直在思考如何使用公司掌握的數(shù)據(jù)，因此構(gòu)建了Confluent平臺(tái)，該平臺(tái)上有一些工具用來幫助其他公司部署和使用Apache Kafka。如果你希望在自己的公司部署流式數(shù)據(jù)處理平臺(tái)，那么Confluent平臺(tái)對(duì)你絕對(duì)有用。
還有一些用的資源：
- 我之前寫過的blog post和小書，討論的主題包括Kafka中的日志抽象、數(shù)據(jù)流和數(shù)據(jù)系統(tǒng)架構(gòu)等；
- Kafka的官方文檔也很有用；
- 在這里有關(guān)于Confluent平臺(tái)的更多介紹
這個(gè)教程的下篇將會(huì)論述在構(gòu)建和管理數(shù)據(jù)流平臺(tái)中的一些實(shí)踐經(jīng)驗(yàn)。
本號(hào)專注于后端技術(shù)、JVM問題排查和優(yōu)化、Java面試題、個(gè)人成長和自我管理等主題，為讀者提供一線開發(fā)者的工作和成長經(jīng)驗(yàn)，期待你能在這里有所收獲。
