前言：前段時間接觸過一個流式計算的任務，使用了阿里巴巴集團的JStorm徒扶，發(fā)現(xiàn)這個領域值得探索粮彤，就發(fā)現(xiàn)了這篇文章——Putting Apache Kafka To Use: A Practical Guide to Building a Stream Data Platform（Part 1）根穷。在讀的過程中半總結半翻譯姜骡，形成本文，跟大家分享屿良。
最近你可能聽說很多技術名詞圈澈，例如“流式處理”、“事件數(shù)據(jù)”以及“實時”等尘惧，與之相關的技術有Kafka康栈、Storm、Samza或者是Spark的Steam Model喷橙。這些新興的技術令人興奮啥么，不過還沒有多少人知道如何將這些技術添加到自己的技術棧中，如何實際應用于項目中贰逾。
這篇指南討論我們關于實時數(shù)據(jù)流的工程經(jīng)驗：如何在你的公司內(nèi)部搭建實時數(shù)據(jù)平臺悬荣、如何使用這些數(shù)據(jù)構建應用程序，所有這些都是基于實際經(jīng)驗——我們在Linkdin花了五年時間構建Apache Kafka疙剑，將Linkdin轉換為流式數(shù)據(jù)架構氯迂，并幫助硅谷的很多技術公司完成了同樣的工作。
這份指南的第一部分是關于流式數(shù)據(jù)平臺（steam data platform）的概覽：什么是流式數(shù)據(jù)平臺言缤，為什么要構建流式數(shù)據(jù)平臺嚼蚀；第二部分將深入細節(jié)，給出一些操作規(guī)范和最佳實踐管挟。
何為流式數(shù)據(jù)平臺轿曙？
流式數(shù)據(jù)平臺：簡潔、輕量的事件處理
我們在Linkein構建Apache Kafka的目的是讓它作為數(shù)據(jù)流的中央倉庫工作僻孝，但是為什么要做這個工作拳芙，有下面兩個原因：
- 數(shù)據(jù)整合：數(shù)據(jù)如何在各個系統(tǒng)之間流轉和傳輸；
- 流式處理：通常在數(shù)據(jù)倉庫或者Hadoop集群中需要做豐富的數(shù)據(jù)分析皮璧，同時實現(xiàn)低延時舟扎。
接下來介紹下上述兩個理論的提出過程。起初我們并沒有意識到這些問題之間有聯(lián)系悴务，我們采取了臨時方案：只要需要睹限，就在系統(tǒng)和應用程序之間建造數(shù)據(jù)通道或者給web服務發(fā)送異步請求。隨著時間推移讯檐，系統(tǒng)越來越復雜羡疗，我們在幾乎所有子系統(tǒng)之間都建立了不同的數(shù)據(jù)通道：
每個數(shù)據(jù)通道都有自己的問題：日志數(shù)據(jù)的規(guī)模很大但是數(shù)據(jù)有缺失，并且數(shù)據(jù)傳輸?shù)难舆t很高别洪；Oracle數(shù)據(jù)庫實例之間的數(shù)據(jù)傳輸速度快叨恨、準確而且實時性好，但是其他系統(tǒng)不能及時快速得獲得這些數(shù)據(jù)挖垛；Oracle數(shù)據(jù)庫的數(shù)據(jù)到Hadoop集群的數(shù)據(jù)通道吞吐量很高痒钝，但是只能進行批次操作秉颗；搜索系統(tǒng)數(shù)據(jù)通道的延遲低，不過數(shù)據(jù)規(guī)模小送矩，并且是直接連接數(shù)據(jù)庫蚕甥；消息系統(tǒng)數(shù)據(jù)通道的延遲低，但是不可靠且規(guī)模小栋荸。
隨著我們在全球各地添加數(shù)據(jù)中心菇怀，我們也要為這些數(shù)據(jù)流添加對應的副本；隨著系統(tǒng)規(guī)模的增長晌块，對應的數(shù)據(jù)通道規(guī)模也應該相應得增長爱沟，整個系統(tǒng)面臨的壓力越來越大。我認為我的團隊與其說是由分布式系統(tǒng)工程師組成匆背，還不如說是由一些管道工組成钥顽。
更糟的是，復雜性過高導致數(shù)據(jù)不可靠靠汁。由于數(shù)據(jù)的索引和存儲存在問題蜂大，導致我們的報告可信度降低。員工需要花費大量時間處理各種類型的臟數(shù)據(jù)蝶怔，記得有在處理一起故障中奶浦，我們在兩個系統(tǒng)中發(fā)現(xiàn)一些非常類似但存在微小差異的數(shù)據(jù)，我們費了很大力氣檢查這兩個數(shù)據(jù)哪個是爭取額的踢星，最后發(fā)現(xiàn)兩個都不對澳叉。
與此同時，我們除了要做數(shù)據(jù)遷移沐悦，還想對數(shù)據(jù)進行進一步的處理和分析成洗。Hadoop平臺提供了批處理、數(shù)據(jù)打包和專案（ad hoc）處理能力藏否，但是我們還需要一個實時性更好的數(shù)據(jù)處理平臺瓶殃。我們的很多系統(tǒng)——特別是監(jiān)控系統(tǒng)、搜索索引的數(shù)據(jù)通道副签、數(shù)據(jù)分析應用以及安全分析應用遥椿，都需要秒級的響應速度，但是這類型的應用在上圖的系統(tǒng)架構中表現(xiàn)很差淆储。
2010年左右冠场，我們開始構建一個系統(tǒng)：專注于實時獲取流式數(shù)據(jù)（stream data），并規(guī)定各個系統(tǒng)之間的數(shù)據(jù)交互機制也以流式數(shù)據(jù)為承載本砰，同時還允許對這些流式數(shù)據(jù)進行實時處理碴裙。這就是Apache Kafka的原型。
我們對整個系統(tǒng)的構想如下所示：
很長一段時間內(nèi)我們都沒有為我們所構建的這個系統(tǒng)取名字，僅僅稱之為“Kafka stuff”或者“global commit log thingy”舔株，隨著時間推移莺琳，我們開始將這個系統(tǒng)中的數(shù)據(jù)稱之為流式數(shù)據(jù)（steam data），而負責處理這種類型的數(shù)據(jù)的平臺稱之為流式數(shù)據(jù)平臺（steam data platform）督笆。
最終我們的系統(tǒng)從前文描述的跟“意大利面條”一樣雜亂進化為清晰的以流式數(shù)據(jù)平臺為中心的系統(tǒng)：
在這個系統(tǒng)中Kafka的角色是通用數(shù)據(jù)管道。每個子系統(tǒng)都可以很容易得接入到這個中央數(shù)據(jù)管道上诱贿；流式處理應用可以接入到該數(shù)據(jù)管道上娃肿，并對外提供經(jīng)過處理后的流式數(shù)據(jù)。這種固定格式的數(shù)據(jù)類型成為各個子系統(tǒng)珠十、應用和數(shù)據(jù)中心之間的通用語言料扰。舉個例子說明：如果一個用戶更新了他的個人信息，這個更新信息會流入我們的系統(tǒng)處理層焙蹭，在系統(tǒng)處理層會對該用戶的公司信息晒杈、地理位置和其他屬性進行標準化處理；然后這個數(shù)據(jù)流會流入搜索引擎和社區(qū)地圖用于查詢和檢索孔厉、這個數(shù)據(jù)也會流入推薦系統(tǒng)進行工作匹配拯钻；所有的這些動作只需要毫秒量級的時間，最后這些數(shù)據(jù)會流入Hadoop數(shù)據(jù)倉庫撰豺。
LinkedIn內(nèi)部在大量使用這套系統(tǒng)粪般，每天為數(shù)百個數(shù)據(jù)中心處理超過5000億事件請求，該系統(tǒng)已經(jīng)成為其他系統(tǒng)的數(shù)據(jù)后臺污桦、成為Hadoop集群的數(shù)據(jù)管道亩歹，以及流式處理的Hub。
由于Kafka開源凡橱，因此有很多公司在做類似的事情：Kafka Powered By
接下來我們將論述流式數(shù)據(jù)平臺的一些細節(jié)：該平臺的工作原理小作、該平臺解決了什么重要問題。
流式數(shù)據(jù)（Steam Data）
大部分業(yè)務邏輯可以理解為事件流（steam of events）稼钩。零售業(yè)有訂單流顾稀、交易流、物流信息流坝撑、價格調(diào)整事件流础拨，以及各類調(diào)用的返回值等等；金融行業(yè)有訂單流绍载、股票價格變更事件流诡宗，以及其他金融行業(yè)的信息流；網(wǎng)站有點擊流击儡、關注流（impressions）塔沃、搜索流等等。在大規(guī)模的軟件系統(tǒng)中還有請求流阳谍、錯誤流蛀柴、機器監(jiān)控信息流和日志流螃概。總之鸽疾，業(yè)務邏輯可以從整體上當作一種數(shù)據(jù)處理系統(tǒng)——接收多種輸入流并產(chǎn)生對應的輸出流（有時還會產(chǎn)生具體的物理產(chǎn)品）吊洼。
這種概念對于習慣于將數(shù)據(jù)想象為數(shù)據(jù)庫中的一行的同學可能有點陌生，接下來我們看一點關于事件流數(shù)據(jù)的實際例子制肮。
事件觸發(fā)和事件流
數(shù)據(jù)庫中存放的是數(shù)據(jù)的當前狀態(tài)冒窍，當前狀態(tài)是過去的某些動作（action）的結果，這些動作就是事件豺鼻。庫存表保存購買和交易事件產(chǎn)生的結果综液，銀行結余存放信貸和借記事件的結果；Web Server的延時圖是一系列HTTP請求的聚合儒飒。
當談論大數(shù)據(jù)時谬莹，很多人更青睞于記錄上述提到的這些事件流，并在此基礎上進行分析桩了、優(yōu)化和決策附帽。某種層度上來說，這些事件流是傳統(tǒng)的數(shù)據(jù)庫沒有反應出來的一面：它們表示業(yè)務邏輯井誉。
事件流數(shù)據(jù)在金融行業(yè)已經(jīng)廣泛使用：股票發(fā)行士葫、市場預測、股票交易等數(shù)據(jù)都可以當作是事件流送悔，但是技術屆使得搜集和使用這些數(shù)據(jù)的現(xiàn)代技術開始流行慢显。Google將廣告點擊流和廣告效果轉化為幾十億美金的收入。在web開發(fā)屆欠啤，這些事件數(shù)據(jù)又被稱為日志數(shù)據(jù)荚藻，由于缺乏針對日志處理的模塊，這些日志事件就存放在日志文件中洁段。Hadoop之類的系統(tǒng)經(jīng)常用于日志處理应狱，但是根據(jù)實際情況，稱之為“批量事件存儲和處理（batch event storage and processing）”更合適祠丝。
網(wǎng)絡公司應該是最早開始記錄事件流的公司疾呻，搜集網(wǎng)站上的事件數(shù)據(jù)非常容易：在某些特定節(jié)點加一些代碼即可記錄和跟蹤每個用戶在改網(wǎng)站上的行為。即使是一個單頁面或者是某個流行網(wǎng)站上的移動窗口也能記錄很多類似的行為數(shù)據(jù)用于分析和監(jiān)控写半。
你可能聽說過“機器產(chǎn)生的數(shù)據(jù)”這個概念岸蜗，其實跟事件數(shù)據(jù)表示相同的含義。某種程度上所有的數(shù)據(jù)都是機器產(chǎn)生的叠蝇，因為這些數(shù)據(jù)來自計算機系統(tǒng)璃岳。
還有很多人在談論設備數(shù)據(jù)和“物聯(lián)網(wǎng)（internet of things）”。不同的人對這些名詞有各自的理解，但是這個物聯(lián)網(wǎng)的核心也在于針對某些數(shù)據(jù)集進行分析和決策铃慷，只不過我們這里的分析對象是大規(guī)模網(wǎng)絡系統(tǒng)单芜，而物聯(lián)網(wǎng)的分析對象是工業(yè)設備或者消費產(chǎn)品。
數(shù)據(jù)庫是事件流
事件流數(shù)據(jù)很適合描述日志數(shù)據(jù)或諸如訂單犁柜、交易洲鸠、點擊和貿(mào)易這些具備明顯事件特征的數(shù)據(jù)。和大多數(shù)開發(fā)人員相同馋缅，你可能將自己系統(tǒng)的大部分數(shù)據(jù)保存在各種數(shù)據(jù)庫中：關系型數(shù)據(jù)庫（Oracle扒腕、MySQL和Postgres）或者新興的分布式數(shù)據(jù)庫（MongoDB、Cassandra和Couchbase）股囊，這些數(shù)據(jù)可能不容易理解為事件或者事件流袜匿。
但實際上更啄，數(shù)據(jù)庫中存儲的數(shù)據(jù)也可理解為一種事件流（event steam）稚疹，簡單來說，數(shù)據(jù)庫可以理解為創(chuàng)建數(shù)據(jù)備份或者建立備庫的過程祭务。做數(shù)據(jù)備份的主要方法是周期性得導出數(shù)據(jù)庫內(nèi)容内狗，然后將這些數(shù)據(jù)導入到備庫中。如果我很少進行數(shù)據(jù)備份义锥，或者是我的數(shù)據(jù)量不大柳沙，那么可以進行全量備份。實際上拌倍，隨著備份頻率的提高赂鲤，全量備份不再可行：如果兩天做一次全量備份，將會耗費兩倍的系統(tǒng)資源柱恤、如果每個小時做一次全量備份数初，則會耗費24倍的系統(tǒng)資源。在大規(guī)模數(shù)據(jù)的備份中梗顺，顯然增量備份更加有效：只增加新創(chuàng)建的泡孩、更新的數(shù)據(jù)和刪除對應的數(shù)據(jù)。利用增量備份寺谤，如過我們將備份頻率提高為原來的1倍仑鸥，則每次備份的數(shù)量將減少幾乎一半，消耗的系統(tǒng)資源也差不多变屁。
那么為什么我們不盡可能提高增量備份的頻率呢眼俊？我們可以做到，但是最后只會得到一系列單行數(shù)據(jù)改變的記錄——這種事件流稱之為變更記錄粟关，很多數(shù)據(jù)庫系統(tǒng)都有負責這個工作的模塊（Oracle數(shù)據(jù)庫系統(tǒng)中的XStreams和GoldenGate泵琳、MySQL有binlog replication、Postgres有Logical Log Steaming Replication）。
綜上获列，數(shù)據(jù)庫的變更過程也可以作為事件流的一部分谷市。你可以通過這些事件流同步Hadoop集群、同步備庫或者搜索索引击孩；你還可以將這些事件流接入到特定的應用或者流式處理應用中迫悠，從而發(fā)掘或者分析出新的結論。
流式數(shù)據(jù)平臺解決的問題巩梢？
流式數(shù)據(jù)平臺有兩個主要應用：
- 數(shù)據(jù)整合：流式數(shù)據(jù)平臺搜集事件流或者數(shù)據(jù)變更信息创泄，并將這些變更輸送到其他數(shù)據(jù)系統(tǒng)，例如關系型數(shù)據(jù)庫括蝠、key-value存儲系統(tǒng)鞠抑、Hadoop或者其他數(shù)據(jù)倉庫。
- 流式處理：對流式數(shù)據(jù)進行持續(xù)忌警、實時的處理和轉化搁拙，并將結果在整個系統(tǒng)內(nèi)開放。
在角色1中法绵，流式數(shù)據(jù)平臺就像數(shù)據(jù)流的中央集線器箕速。與之交互的應用程序不需要考慮數(shù)據(jù)源的細節(jié)，所有的數(shù)據(jù)流都以同一種數(shù)據(jù)格式表示朋譬；流式數(shù)據(jù)平臺還可以作為其他子系統(tǒng)之間的緩沖區(qū)（buffer）——數(shù)據(jù)的提供者不需要關心最終消費和處理這些數(shù)據(jù)的其他系統(tǒng)盐茎。這意味著數(shù)據(jù)的消費者與數(shù)據(jù)源可以完全解耦合。
如果你需要部署一個新的系統(tǒng)徙赢，你只需要將新系統(tǒng)接入到流式數(shù)據(jù)平臺字柠，而不需要為每個特定的需求選擇（并管理）各自的數(shù)據(jù)庫和應用程序。不論數(shù)據(jù)最初來自日志文件狡赐、數(shù)據(jù)庫窑业、Hadoop集群或者流式處理系統(tǒng)，這些數(shù)據(jù)流都使用相同的格式阴汇。在流式數(shù)據(jù)平臺上部署新系統(tǒng)非常容易数冬，新系統(tǒng)只需要跟流式數(shù)據(jù)平臺交互，而不需要跟各種具體的數(shù)據(jù)源交互搀庶。
Hadoop集群的設計目標是管理公司的全量數(shù)據(jù)拐纱，直接從HDFS中獲取數(shù)據(jù)是非常耗費時間的方案，而且直接獲取的數(shù)據(jù)不能直接用于實時處理和同步哥倔。但是秸架，這個問題可以反過來看：Hadoop等數(shù)據(jù)倉庫可以主動將結果以流式數(shù)據(jù)的格式推送給其他子系統(tǒng)中。
流式數(shù)據(jù)平臺的角色2包含數(shù)據(jù)聚合用例咆蒿，系統(tǒng)搜集各類數(shù)據(jù)形成數(shù)據(jù)流东抹，然后存入Hadoop集群歸檔蚂子，這個過程就是一個持續(xù)的流式數(shù)據(jù)處理。流式處理的輸出還是數(shù)據(jù)流缭黔，同樣可以加載到其他數(shù)據(jù)系統(tǒng)中食茎。
流式處理可以使用通過簡單的應用代碼實現(xiàn)，這些處理代碼處理事件流并產(chǎn)生新的事件流馏谨，這類工作可以通過一些流行的流式處理框架完成——Storm别渔、Samza或Spark Streaming，這些框架提供了豐富的API接口惧互。這些框架發(fā)展得都不錯哎媚，同時它們跟Apache Kafka的交互都很好。
流式數(shù)據(jù)平臺需要提供的能力喊儡？
在上文中我提到了一些不同的用例拨与，每個用例都有對應的事件流，但是每個事件流的需求又有所不同——有些事件流要求快速響應艾猜、有些事件流要求高吞吐量买喧、有些事件流要求可擴展性等等。如果我們想讓一個平臺滿足這些不同的需求箩朴，這個平臺應該提供什么能力岗喉？
我認為對于一個流式數(shù)據(jù)平臺秋度，應該滿足下列關鍵需求：
- 它必須足夠可靠炸庞，以便于處理嚴苛的更新，例如將某個數(shù)據(jù)庫的更新日志變更為搜索索引的存儲荚斯，能夠順序傳輸數(shù)據(jù)并保證不丟失數(shù)據(jù)埠居；
- 它必須具備足夠大的吞吐量，用于處理大規(guī)模日志或者事件數(shù)據(jù)事期；
- 它必須具備緩沖或者持久化數(shù)據(jù)的能力滥壕，用于與Hadoop這類批處理系統(tǒng)交互。
- 它必須能夠為實時處理程序?qū)崟r提供數(shù)據(jù)兽泣，即延時要足夠低绎橘；
- 它必須具備良好的擴展性，可以應付整個公司的滿負載運行唠倦，并能夠集成成百上千個不同團隊的應用程序称鳞，這些應用以插件的形式與流式數(shù)據(jù)平臺整合。
- 它必須能和實時處理框架良好得交互
流式數(shù)據(jù)平臺是整個公司的核心系統(tǒng)稠鼻，用于管理各種類型的數(shù)據(jù)流冈止，如果該系統(tǒng)不能提供良好的可靠性以及可擴展性，系統(tǒng)會隨著數(shù)據(jù)量的增長而再次遭遇瓶頸候齿；如果該系統(tǒng)不支持批處理和實時處理熙暴，那么就不能與Hadoop或者Storm這類系統(tǒng)整合闺属。
Apache Kafka
Apache Kafka是專門處理流式數(shù)據(jù)的分布式系統(tǒng)，它具備良好的容錯性周霉、高吞吐量掂器、支持橫向擴展，并允許地理位置分布的流式數(shù)據(jù)處理俱箱。
Kafka常常被歸類于消息處理系統(tǒng)唉匾，它確實扮演了類似的角色，但同時也提供了其他的抽象接口匠楚。在Kafka中最關鍵的抽象數(shù)據(jù)結構是用于記錄更新的commit log：
數(shù)據(jù)生產(chǎn)者向commit log隊列中發(fā)送記錄流巍膘，其他消費者可以像水流一樣在毫秒級延時處理這些日志的最新信息。每個數(shù)據(jù)消費者在commit log中有一個自己的位置（指針）芋簿，并獨立移動峡懈，這使得可靠、順序更新能夠分布式得發(fā)送給每個消費者与斤。
這個commit log的作用非常關鍵：可以多個生產(chǎn)者和消費者共享肪康，并覆蓋一個集群中的多臺機器，每臺機器都可用作容錯保障撩穿；可以提供一個并行模型磷支，其具備的順序消費的特點使得Kafka可以用于記錄數(shù)據(jù)庫的變更。
Kafka是一個現(xiàn)代的分布式系統(tǒng)食寡，存儲在一個集群的數(shù)據(jù)（副本和分片存儲）可以水平擴張和縮小雾狈，同時上層應用對此毫無感知。數(shù)據(jù)消費者的機器數(shù)量可以隨數(shù)據(jù)規(guī)模的增長而水平增加抵皱，同時可以自動應對數(shù)據(jù)處理過程中發(fā)生的錯誤善榛。
Kafka的一個關鍵設計是對持久化的處理相當好，Kafka的消息代理（broker）可以存儲TB量級的數(shù)據(jù)呻畸，這使得Kafka能夠完成一些傳統(tǒng)數(shù)據(jù)庫無法勝任的任務：
- 接入Kafka的Hadoop集群或者其他離線系統(tǒng)可以放心得停機維護移盆，間隔幾小時或者幾天后再平滑接入，因為在它停機期間到達的流式數(shù)據(jù)被存儲在Kafka的上行集群伤为。
- 在首次執(zhí)行同步數(shù)據(jù)庫的任務時可以執(zhí)行全量備份咒循，以便讓下行消費者訪問全量數(shù)據(jù)。
上述這些特性使得Kafka能夠提供比傳統(tǒng)的消息系統(tǒng)更廣的應用范圍绞愚。
事件驅(qū)動的應用
自從我們將Kafka開源后叙甸，我們有很多機會與其他想做類似的事情的公司交流和合作：研究如何Kafka系統(tǒng)的部署以及Kafka在該公司內(nèi)部技術架構的角色如何隨著時間演進和改變。
初次部署常常用于單個的大規(guī)模應用：日志數(shù)據(jù)處理爽醋，并接入Hadoop集群蚁署；也可能是其他數(shù)據(jù)流，該數(shù)據(jù)流的規(guī)模太大以至于超出了該公司原有的消息系統(tǒng)的處理能力蚂四。
從這些用例延伸開來光戈，在接入Hadoop集群后哪痰，很快就需要提供實時數(shù)據(jù)處理的能力，現(xiàn)存的應用需要擴展和重構久妆，利用現(xiàn)有的實時處理框架更高效得處理流式數(shù)據(jù)晌杰。以LinkedIn為例，我們最開始是利用Kafka處理job信息流筷弦，并將job信息存入Hadoop集群肋演，然后很多ETL-centric的應用需求開始出現(xiàn)，這些job信息流開始用于其他子系統(tǒng)烂琴，如下圖所示：
在這張圖中爹殊，job的定義不需要一些定制就可以與其他子系統(tǒng)交互，當上游應用（移動應用）上出現(xiàn)新的工作信息時奸绷，就會通過Kafka發(fā)送一個全局事件梗夸，下游的數(shù)據(jù)處理應用只需要響應這個事件即可。
流式數(shù)據(jù)平臺與現(xiàn)存中間件的關系
我們簡單講下流式數(shù)據(jù)平臺與現(xiàn)存的類似系統(tǒng)的關系号醉。
消息系統(tǒng)（Messaging）
流式數(shù)據(jù)平臺類似于企業(yè)消息系統(tǒng)——它接收消息事件反症，并把它們發(fā)布到對應事件的訂閱者。不過畔派，二者有三個重要的不同：
- 消息系統(tǒng)通常是作為某個應用中的一個組件來部署铅碍，不同的應用中有不同的消息系統(tǒng)，而流式數(shù)據(jù)平臺希望成為整個企業(yè)的數(shù)據(jù)流Hub线椰。
- 消息系統(tǒng)與批處理系統(tǒng)（數(shù)據(jù)倉庫或者Hadoop集群）的交互性很差胞谈，因為消息系統(tǒng)的數(shù)據(jù)存儲容量有限；
- 消息系統(tǒng)并未提供與實時處理框架整合的API接口士嚎。
換句話說呜魄，流式數(shù)據(jù)平臺可以看作在公司級別（消息系統(tǒng)的級別是項目）設計的消息系統(tǒng)悔叽。
數(shù)據(jù)聚合工具（Data Integration Tools）
為了便于跟其他系統(tǒng)整合莱衩，流式數(shù)據(jù)平臺做了很多工作。它的角色跟Informatica這類工具不同娇澎，流式數(shù)據(jù)平臺是可以讓任何系統(tǒng)接入笨蚁，并可以圍繞該平臺構建不同的應用。
流式數(shù)據(jù)平臺與數(shù)據(jù)聚合工具有一點重合的實踐：使用一個統(tǒng)一的數(shù)據(jù)流抽象趟庄，保證數(shù)據(jù)格式相同括细，這樣可以避免很多數(shù)據(jù)清洗任務。我會在這個系列文章的第二篇仔細論述這個主題戚啥。
企業(yè)服務總線（Enterprise Service Buses）
我認為流式數(shù)據(jù)平臺借鑒了很多企業(yè)服務總線的設計思想奋单，不過提供了更好的實現(xiàn)方案。企業(yè)服務總線面臨的挑戰(zhàn)就是自身的數(shù)據(jù)傳輸效率很低猫十；企業(yè)服務總線在部署時也面臨一些挑戰(zhàn)：不適合多租戶使用（PS览濒，此處需要看下原文呆盖，歡迎指導）。
流式數(shù)據(jù)平臺的優(yōu)勢在于數(shù)據(jù)的傳輸與系統(tǒng)本身解耦合贷笛，數(shù)據(jù)的傳輸由各個應用自身完成应又，這樣就能避免平臺自身成為瓶頸。
變更記錄系統(tǒng)（Change Capture Systems）
常規(guī)的數(shù)據(jù)庫系統(tǒng)都有類似的日志機制乏苦，例如Golden Gate株扛，然而這個日志記錄機制僅限于數(shù)據(jù)庫使用，并不能作為通用的事件記錄平臺汇荐。這些數(shù)據(jù)庫自帶的日志記錄機制主要用于同類型數(shù)據(jù)庫（eg：Oracle-to-Oracle）之前的互相備份洞就。
數(shù)據(jù)倉庫和Hadoop
流式數(shù)據(jù)平臺并不能替代數(shù)據(jù)倉庫，恰恰相反掀淘，它為數(shù)據(jù)倉庫提供數(shù)據(jù)源奖磁。它的身份是一個數(shù)據(jù)管道，將數(shù)據(jù)傳輸?shù)綌?shù)據(jù)倉庫繁疤，用于長期轉化咖为、數(shù)據(jù)分析和批處理。這個數(shù)據(jù)管道也為數(shù)據(jù)倉庫提供對外輸出結果數(shù)據(jù)的功能稠腊。
流式處理系統(tǒng)（Steam Processing Systems）
常用的流式處理框架躁染，例如Storm、Samza或Spark Streaming可以很容易得跟流式數(shù)據(jù)平臺整合架忌。這些流式數(shù)據(jù)處理框架提供了豐富的API接口吞彤，可以簡化數(shù)據(jù)轉化和處理。
流式數(shù)據(jù)平臺的落地與實踐
我們不只是提出了一個很好的想法叹放，我們面臨的需求很適合將自己的想法落地饰恕。過去五年我們都在構建Kafka系統(tǒng)，幫助其他公司落地流式數(shù)據(jù)平臺井仰。今天埋嵌，在硅谷有很多公司在實踐這套設計思路，每個用戶的行為都被實時記錄并處理俱恶。
前瞻
我們一直在思考如何使用公司掌握的數(shù)據(jù)雹嗦，因此構建了Confluent平臺，該平臺上有一些工具用來幫助其他公司部署和使用Apache Kafka合是。如果你希望在自己的公司部署流式數(shù)據(jù)處理平臺了罪，那么Confluent平臺對你絕對有用。
還有一些用的資源：
- 我之前寫過的blog post和小書聪全，討論的主題包括Kafka中的日志抽象泊藕、數(shù)據(jù)流和數(shù)據(jù)系統(tǒng)架構等；
- Kafka的官方文檔也很有用难礼；
- 在這里有關于Confluent平臺的更多介紹
這個教程的下篇將會論述在構建和管理數(shù)據(jù)流平臺中的一些實踐經(jīng)驗娃圆。
本號專注于后端技術汽久、JVM問題排查和優(yōu)化、Java面試題踊餐、個人成長和自我管理等主題景醇，為讀者提供一線開發(fā)者的工作和成長經(jīng)驗，期待你能在這里有所收獲吝岭。
