Brooklin: LinkedIn開源的近實時數據流大規模可擴展可靠分佈式系統

       近日LinkedIn又開源了一個新工具Brooklin，一個近實時分佈式可擴展的流數據服務。Brooklin從2016年開始在LinkedIn線上運行，天天處理數千條數據流和2萬億條消息。  

爲何開發Brooklin

      高速、可靠地傳輸大規模數據已經不是LinkedIn惟一須要解決的問題，快速增長的數據存儲和流式系統的多樣性的帶來的問題同樣十分嚴峻，LinkedIn構建Brooklin用來解決對系統可擴展性方面的新需求，即系統既要在數據規模方面可擴展，又要在系統多樣性方面可擴展。

Brooklin是什麼

Brooklin是一個分佈式系統，用於跨多個不一樣的數據存儲和消息系統流式傳輸數據，具備高可靠性。 它暴露了一系列的抽象，經過編寫新的Brooklin消費者和生產者，能夠擴展其功能，實現重新系統消費和生成數據。

Brooklin 用例

Brooklin有兩大類用例：流橋和變動數據捕獲。

數據流橋(stream bridge)

數據能夠分佈在不一樣的環境（公共雲和公司數據中心），地理位置或不一樣的部署組中。一般，因爲訪問機制、序列化格式、合規性和安全性等需求都會增長額外的複雜性。Brooklin能夠做爲這些環境之間傳輸數據的一個橋。好比，Brooklin能夠在不一樣的雲服務之間、一個數據中心不一樣的集羣之間、甚至不一樣的數據中心之間傳輸數據。

圖2 一個假設場景:：一個brooklin集羣被用做流橋來傳輸數據，數據從Kinesis傳入kafka，再從kafka傳入EventHubs

       因爲Brooklin是一個在不一樣環境間傳輸數據流的專屬服務，全部的複雜性均可以在一個服務中被管理，因此開發者能夠把注意力集中於數據的處理而非傳輸。此外，這種集中式的、託管式的、可擴展的框架能夠讓組織實施策略和促進數據治理。舉例說明，Brooklin能夠配置實施公司範圍的策略，好比全部數據流都必須是json格式，或者流中的任何數據都必須是加密的。

Kafka mirroring

        在Brooklin以前，Kafka集羣之間的的數據傳輸是經過Kafka MirrorMaker(KMM)實現的，可是它在大規模傳輸方面存在問題。而Brooklin被設計爲傳輸流數據的通用橋，因此它能夠輕鬆的傳輸極大規模的kafka數據。

       在LinkedIn，一個使用Brooklin做爲流橋的例子就是在Kafka集羣及數據中心之間鏡像kafka數據。

圖3 一個假設場景:：經過使用Brooklin，讓用戶在一個數據中訪問全部的數據變得很容易。每一個數據中內心，一個單獨的Brooklin集羣能夠處理多個source/destination對。

Brooklin鏡像kafka數據的方案已經在LinkedIn經過大規模測試，而且已經徹底取代KMM。經過使用這個方案，解決了KMM的一些痛點，並從它的新特性中受益，這些特色在下面討論.

特性1 Multitenancy（多租戶）

在KMK部署模型中，鏡像只能在兩個Kafka集羣之間進行。這就形成要爲每一個數據pipeline都搭建一個KMM，結果就是會出現幾十上百個KMM集羣，這會形成管理十分困難。可是，Brooklin被設計成能夠同時管理不一樣的數據pipeline，因此咱們只需部署一個Brooklin集羣就能夠了。經過對比圖3和圖4，你能夠有一個更直觀的感覺。

圖4 一個假設場景: 使用KMM來實現跨數據中心的數據鏡像

特性2 Dynamic provisioning and management（動態配置和管理）

       使用Brooklin，只需對REST端點進行HTTP調用便可輕鬆完成建立新data pipeline（也稱爲data stream）和修改現有data pipeline。對於Kafka鏡像用例，此端點能夠很是輕鬆地建立新的鏡像管道或修改現有管道的鏡像白名單，而無需更改和部署靜態配置。

       雖然鏡像管道能夠在同一個集羣中共存，但Brooklin能夠單獨控制和配置每一個管道。例如，能夠編輯管道的鏡像白名單或向管道添加更多資源，而不會影響任何其餘管道。此外，Brooklin容許按需暫停和恢復單個管道，這在臨時操做或修改管道時很是有用。對於Kafka鏡像用例，Brooklin支持暫停或恢復整個管道，白名單中的單個主題，甚至單個主題分區。

特性3 Diagnostics（診斷）

       Brooklin還公開了一個診斷REST端點，能夠按需查詢數據流的狀態。此API能夠輕鬆查詢管道的內部狀態，包括任何單個主題分區滯後或錯誤。因爲診斷端點整合了整個Brooklin集羣的全部發現，所以這對於快速診斷特定分區的問題很是有用，而無需掃描日誌文件。

Special features（特殊功能）

       因爲Brooklin被用來替代KMM，因此Brooklin在穩定性和可操做性方面作了優化。另外還專門爲Kafka鏡像提供了一些特性。

1.    故障隔離:    最重要的是，咱們努力實現更好的故障隔離，所以鏡像特定分區或主題的錯誤不會像使用KMM那樣影響整個管道或集羣。 Brooklin可以在分區級別檢測錯誤並自動暫停這些有問題的分區的鏡像。這些自動暫停的分區能夠在一段可配置的時間後自動恢復，這樣就不須要手動干預，對瞬態錯誤特別有用。同時，其餘分區和管道的處理不受影響。
2.  無刷生成模式:  爲了改善鏡像延遲和吞吐量，Brooklin Kafka鏡像還能夠在無刷生成模式(flushless-produce mode)下運行，其中Kafka消耗進度在分區級別進行跟蹤。檢查點是針對每一個分區而不是管道級別完成的。這容許Brooklin避免進行昂貴的Kafka生產者刷新調用，這是同步阻塞調用，一般可使整個流水線停頓幾分鐘。

     經過使用Brooklin替代KMM，LinkedIn將鏡像集羣從幾百個下降到了十幾個。同時，這也提升了添加新功能和提高的迭代速度。

Change data capture (CDC)

       Brooklin的第二類主要用例是變動數據捕獲。這些狀況下的目標是以低延遲更改流的形式流式傳輸數據庫更新。例如，LinkedIn的大部分真實數據（例如做業，鏈接和配置文件信息）都駐留在各類數據庫中。有些應用程序有興趣瞭解什麼時候發佈新做業，創建新的專業鏈接或更新成員的我的資料。而不是讓這些感興趣的應用程序中的每個都對在線數據庫進行昂貴的查詢以檢測這些變化，而不是實時地流式傳輸這些數據庫更新。使用Brooklin生成變動數據捕獲事件的最大優點之一是應用程序和在線存儲之間更好的資源隔離。應用程序能夠獨立於數據庫進行擴展，從而避免了數據庫宕機的風險。使用Brooklin，咱們在LinkedIn爲Oracle，Espresso和MySQL構建了變動數據捕獲解決方案;此外，Brooklin的可擴展模型有助於編寫新的鏈接器，爲任何數據庫源添加CDC支持。

                                         圖5

特性1 Bootstrap support（初始化支持）

       有時，在使用增量更新以前，應用程序可能須要數據存儲的完整快照。當應用程序第一次啓動或者因爲處理邏輯的更改而須要從新處理整個數據集時，可能會發生這種狀況。 Brooklin的可擴展鏈接器模型能夠支持這種用例。

特性2 Transaction support（事務支持）

      許多數據庫都有事務支持，對於這些源，Brooklin鏈接器能夠確保維護事務邊界。

更多信息

      有關Brooklin的更多信息，包括其架構和功能的概述，請查看咱們以前的工程博客文章。

      在Brooklin的第一個版本中，引進了Kafka鏡像功能，可使用咱們提供的簡單指令和腳原本測試驅動器。咱們正在努力爲項目增長對更多來源和目的地的支持 - 敬請期待！

將來

        自2016年10月以來，Brooklin已成功運行於LinkedIn生成環境。它已取代Databus做爲Espresso和Oracle源的變動捕獲解決方案，是咱們在Azure，AWS和LinkedIn之間移動數據的流橋解決方案，包括鏡像咱們衆多kafka集羣一天數萬億條的消息。

        咱們將繼續構建鏈接器以支持其餘數據源（MySQL，Cosmos DB，Azure SQL）和目標（Azure Blob存儲，Kinesis，Cosmos DB，Couchbase）。咱們還計劃爲Brooklin添加優化功能，例如基於流量需求進行自動擴展的功能，在鏡像方案中跳過解壓縮和從新壓縮消息以提升吞吐量的能力，以及額外的讀寫優化。

項目地址

Github

總結

1. Brooklin是個分佈式數據流傳輸服務，能夠對接不一樣類型的數據存儲和消息系統
2. Brooklin目前已經實現了Kafka鏡像功能，並提供多租戶、動態配置和管理、診斷、故障隔離、無刷生成模式等特細。
3. Brooklin還提供CDC功能，可是目前僅支持Espresso和Oracle源，尚未Mysql，Azure SQL等鏈接器