首先需要注意的是，本文即將提到的 Druid，并非阿里巴巴的 Druid 數(shù)據(jù)庫連接池，而是另一個大數(shù)據(jù)場景下的解決方案：Apache Druid。

Apache Druid 是一個用于大數(shù)據(jù)實時查詢和分析的高容錯、高性能開源分布式時序數(shù)據(jù)庫系統(tǒng)，旨在快速處理大規(guī)模的數(shù)據(jù)，并能夠?qū)崿F(xiàn)快速查詢和分析。尤其是當(dāng)發(fā)生代碼部署、機(jī)器故障以及其他產(chǎn)品系統(tǒng)遇到宕機(jī)等情況時，Druid 仍能夠保持 100% 正常運(yùn)行。創(chuàng)建 Druid 的最初意圖主要是為了解決查詢延遲問題，當(dāng)時試圖使用 Hadoop 來實現(xiàn)交互式查詢分析，但是很難滿足實時分析的需要。而 Druid 提供了以交互方式訪問數(shù)據(jù)的能力，并權(quán)衡了查詢的靈活性和性能而采取了特殊的存儲格式。

目前 Druid 廣泛應(yīng)用在國內(nèi)外各個公司，比如阿里，滴滴，知乎，360，eBay，Hulu 等。

本文 作者 Mohan Garadi 披露了 eBay 如何使用 Druid 進(jìn)行監(jiān)控的技術(shù)細(xì)節(jié)。

在 eBay 中，我們將監(jiān)控技術(shù)棧從傳統(tǒng)的本地架構(gòu)轉(zhuǎn)換為基于 Druid 的實時監(jiān)控系統(tǒng)。在本文中，我們將討論如何過渡到新技術(shù)棧，以及它為我們帶來了什么好處。

eBay 每天要支撐數(shù)百萬用戶進(jìn)行電子商務(wù)交易。隨著支持不同產(chǎn)品的各種應(yīng)用所產(chǎn)生的數(shù)據(jù)爆炸式增長，用戶數(shù)量也在大幅增長。日志是應(yīng)用程序的核心，用于決定應(yīng)用程序執(zhí)行哪些操作。隨著應(yīng)用程序大小的增長，日志變得很難進(jìn)行可視化。我們還有一個集中式日志存儲來處理所有日志，要直接從日志中獲取有用的信息非常困難，而且從日志中實時獲取有用信息的想法也不可行。在 eBay 中，監(jiān)控團(tuán)隊以不同的方式對問題進(jìn)行可視化。解決問題的更好方法是：從日志中提取有用事件并通過數(shù)據(jù)管理處理這些事件。

事件的數(shù)量直接與根據(jù)當(dāng)前系統(tǒng)的流量生成的日志數(shù)量相關(guān)。一些應(yīng)用程序可能會生成數(shù)百到數(shù)千個事件，而其他應(yīng)用程序可能會生成數(shù)百萬個事件。我們的興趣是基于從日志中提取的事件來監(jiān)控各個應(yīng)用程序的執(zhí)行情況，以及在系統(tǒng)中出現(xiàn)太多錯誤或異常行為時提醒用戶的能力。

應(yīng)用程序事件包括錯誤狀態(tài)代碼、url 事務(wù)、命令執(zhí)行以及在不同主機(jī)上的應(yīng)用程序項目的構(gòu)建 ID 等。這些事件都有不同的目的。

應(yīng)用程序開發(fā)人員和網(wǎng)站可靠性管理（Site reliability engineering，SRE）團(tuán)隊都會對這些事件感興趣，因為他們可以實時監(jiān)控應(yīng)用程序的性能。它們能夠?qū)⑾到y(tǒng)中發(fā)生的錯誤數(shù)量以可視化的形式呈現(xiàn)，通過命令執(zhí)行對這些錯誤進(jìn)行切片和切塊，并構(gòu)建導(dǎo)致這些錯誤的程序，然后根據(jù)可能影響應(yīng)用程序性能的錯誤閾值設(shè)置警報。

當(dāng)應(yīng)用程序開發(fā)團(tuán)隊必須在生產(chǎn)中部署應(yīng)用程序的新項目時，這些信息提供了關(guān)鍵的洞見。他們將能夠在一小部分主機(jī)上進(jìn)行代碼的抽樣部署（sampled rollout），并可視化實時儀表盤，以確定新代碼在生成錯誤方面的行為，然后將實時數(shù)據(jù)與歷史數(shù)據(jù)進(jìn)行比較，從而提供一定程度的可信度。

傳統(tǒng)架構(gòu)

傳統(tǒng)架構(gòu)是多年前設(shè)計的，當(dāng)時整個站點每天生成的事件數(shù)量大約為 1000 萬次。這在當(dāng)時是可擴(kuò)展的，并且在未來幾年內(nèi)也可以進(jìn)行擴(kuò)展。

隨著時間的推移，傳統(tǒng)架構(gòu)暴露了一些缺點：

多維數(shù)據(jù)集生成是每個時間間隔的自定義編寫代碼。生成當(dāng)前時間的數(shù)據(jù)通常需要幾分鐘，這對于實時監(jiān)控而言是不可接受的。而且這種延遲隨著數(shù)據(jù)量的增加而增加。

隨著數(shù)據(jù)量的增加，自定義多維數(shù)據(jù)生成的可擴(kuò)展性隨時間的推移效果變得較差。

在維度基數(shù)非常高（幾十萬到幾百萬種組合）的情況下，生成速度緩慢或無法創(chuàng)建多維數(shù)據(jù)集。

新架構(gòu)

在新的架構(gòu)中，已刪除 Tibco 依賴項，并將 Kafka 用做臨時保存信息以供使用的層。Tranquilty 用于使用來自 Kafka 的數(shù)據(jù)并輸入 Druid。

新架構(gòu)的要點如下：

從時間生成到出口實現(xiàn)的最小端到端延遲（對于非常大的應(yīng)用程序，最大不超過 10 秒）。

使用 Druid 處理多種粒度的數(shù)據(jù)，如 1 分鐘、1 刻鐘、1 小時等。重新索引 1 天間隔的數(shù)據(jù)。

Kubernetes 部署使我們在升級或維護(hù)時，能夠在幾分鐘之內(nèi)刪除集群并重新創(chuàng)建集群。使用 100 個節(jié)點執(zhí)行滾動更新非常容易。

Druid 可有效地處理高基數(shù)數(shù)據(jù)，只要為索引任務(wù)提供足夠的可擴(kuò)展性，即使是數(shù)以百萬計的緯度值，也可以使用 Druid 來處理，而不會產(chǎn)生任何額外的延遲，索引任務(wù)可在零停機(jī)時間內(nèi)實現(xiàn)。

（Tibco 是一種用于數(shù)據(jù)傳輸?shù)钠髽I(yè)消息總線。Tranquilty 是 Druid-io 的一部分，它帶了一個將數(shù)據(jù)流發(fā)送到 Druid 的 API。）

事件處理

事件包括系統(tǒng)中發(fā)生的事情，這些事情從本質(zhì)上來講是零星的。一些應(yīng)用程序每天會生成一些事件，而其他應(yīng)用程序在一分鐘內(nèi)會生成數(shù)百萬個事件。不同類型的事件可根據(jù)它們的用途來生成。我們在此背景下討論監(jiān)控事件。

在我們的用例中，數(shù)據(jù)具有一個固定的維度鍵（11 維），一個時間戳和兩個要計算的度量：計數(shù)和延遲。計數(shù)是在特定時間戳收集數(shù)據(jù)時主機(jī)發(fā)生的事件數(shù)量。延遲表示所有事務(wù)的延遲總和?？鐟?yīng)用程序的數(shù)千個主機(jī)可能會生成數(shù)以百萬計的事件，每個事件可以包含不同的緯度值集。每個應(yīng)用程序的每個維度的緯度值可以從十到幾千不等。

開發(fā)團(tuán)隊和 SRE 團(tuán)隊對上述事件很感興趣，以了解特定應(yīng)用程序或多個應(yīng)用程序在網(wǎng)站上發(fā)生錯誤的數(shù)量，這些錯誤可能會造成很大影響。將每分鐘幾百萬個事件實時收集到集中式存儲并對其進(jìn)行處理，會帶來一系列事關(guān)準(zhǔn)確性、速度、可靠性和彈性方面的挑戰(zhàn)。

擴(kuò)展

監(jiān)控事件在整個集群中，以每秒 800 萬個事件的速度生成，在高峰流量時平均為每秒 1000 萬個事件，這些來自 5000 多個應(yīng)用程序。監(jiān)控事件需要跨多個維度進(jìn)行切片和切塊，例如應(yīng)用程序名稱、應(yīng)用程序類型、操作名稱、錯誤狀態(tài)、運(yùn)行應(yīng)用程序的構(gòu)建、主機(jī)等。所有數(shù)據(jù)都應(yīng)以近實時服務(wù)級別協(xié)議進(jìn)行匯總和提供。共有 11 個固定維度，所有維度的緯度值基數(shù)在 140 萬到 200 萬個唯一組合之間。

我們的 Druid 集群部署在多個可用區(qū)域，以實現(xiàn)高可用性，并保持每個數(shù)據(jù)中心的每個示例保留 2 個副本。這使得我們可以在 2 個數(shù)據(jù)中心共有 4 個副本可用。每個數(shù)據(jù)中心都有幾百個中間管理器、2 個統(tǒng)治 + 協(xié)調(diào)（Overlord+Coordinator）節(jié)點，15 個代理節(jié)點和 80 個歷史節(jié)點。

峰值數(shù)據(jù)流量如下圖所示。

出口設(shè)計

數(shù)據(jù)出口的設(shè)計目標(biāo)是保持?jǐn)?shù)據(jù)的高可用性。Druid 代理前面的一層被設(shè)計用于查詢 Druid 的數(shù)據(jù)，以確定每個數(shù)據(jù)中心的健康狀況。我們希望兩個數(shù)據(jù)中心的運(yùn)行狀況始終保持在最佳狀態(tài)，且高度可用。如果任何數(shù)據(jù)中心出現(xiàn)任何數(shù)據(jù)丟失的情況，出口會切換到數(shù)據(jù)質(zhì)量更好的集群。

我們每分鐘從每個集群中獲取事件計數(shù)，以確定兩個集群是否具有相似的數(shù)據(jù)（偏差小于集群之間的事件計數(shù)差異的 0.5%）。如果偏差過大，我們則選擇事件計數(shù)更好的集群。計算每分鐘進(jìn)行一次，我們繼續(xù)更新集群的運(yùn)行狀況，以確定能夠在一段時間內(nèi)為數(shù)據(jù)提供服務(wù)的最佳集群。如果檢測到任何數(shù)據(jù)丟失，我們還會標(biāo)記集群，這樣就不會有任何查詢進(jìn)入有問題的集群的代理節(jié)點進(jìn)行查詢。

我們支持早期版本的 Druid 所支持的各種粒度（1 分鐘、1 刻鐘、1 小時、1 天），這取決于查詢數(shù)據(jù)的時間長度。這種粒度的選擇是自動進(jìn)行的。在需要時，由于查詢的數(shù)據(jù)量很大，可以強(qiáng)制粒度以更長的時間段獲取更細(xì)粒度的數(shù)據(jù)，但要付出響應(yīng)時間的代價。

結(jié)論

對于站點監(jiān)控和事件跟蹤而言，帶有需要實時或近實時聚合的高基數(shù)數(shù)據(jù)的用例，對于像 eBay 這樣的大型生態(tài)系統(tǒng)做出數(shù)據(jù)驅(qū)動的決策至關(guān)重要。像 Druid 這樣的分析存儲可以提供洞見的能力，從監(jiān)控的角度來說非常有價值，也很重要；很多團(tuán)隊和開發(fā)人員都依賴維護(hù) eBay 客戶系統(tǒng)的可用性和可靠性。

參考資料

本文中對 Druid 的所有引用都是指 Druid 開源版本，請參考以下鏈接：

 http://druid.io/ 

https://github.com/apache/incubator-druid/

總結(jié)

以上所述是小編給大家介紹的eBay 打造基于 Apache Druid 的大數(shù)據(jù)實時監(jiān)控系統(tǒng)，希望對大家有所幫助，如果大家有任何疑問歡迎給我留言小編會及時回復(fù)大家的！