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

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

目前 Druid 廣泛應用在國內外各個公司，比如阿里，滴滴，知乎，360，eBay，Hulu 等。

本文 作者 Mohan Garadi 披露了 eBay 如何使用 Druid 進行監控的技術細節。

在 eBay 中，我們將監控技術棧從傳統的本地架構轉換為基于 Druid 的實時監控系統。在本文中，我們將討論如何過渡到新技術棧，以及它為我們帶來了什么好處。

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

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

應用程序事件包括錯誤狀態代碼、url 事務、命令執行以及在不同主機上的應用程序項目的構建 ID 等。這些事件都有不同的目的。

應用程序開發人員和網站可靠性管理（Site reliability engineering，SRE）團隊都會對這些事件感興趣，因為他們可以實時監控應用程序的性能。它們能夠將系統中發生的錯誤數量以可視化的形式呈現，通過命令執行對這些錯誤進行切片和切塊，并構建導致這些錯誤的程序，然后根據可能影響應用程序性能的錯誤閾值設置警報。

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

傳統架構

傳統架構是多年前設計的，當時整個站點每天生成的事件數量大約為 1000 萬次。這在當時是可擴展的，并且在未來幾年內也可以進行擴展。

隨著時間的推移，傳統架構暴露了一些缺點：

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

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

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

新架構

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

新架構的要點如下：

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

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

Kubernetes 部署使我們在升級或維護時，能夠在幾分鐘之內刪除集群并重新創建集群。使用 100 個節點執行滾動更新非常容易。

Druid 可有效地處理高基數數據，只要為索引任務提供足夠的可擴展性，即使是數以百萬計的緯度值，也可以使用 Druid 來處理，而不會產生任何額外的延遲，索引任務可在零停機時間內實現。

（Tibco 是一種用于數據傳輸的企業消息總線。Tranquilty 是 Druid-io 的一部分，它帶了一個將數據流發送到 Druid 的 API。）

事件處理

事件包括系統中發生的事情，這些事情從本質上來講是零星的。一些應用程序每天會生成一些事件，而其他應用程序在一分鐘內會生成數百萬個事件。不同類型的事件可根據它們的用途來生成。我們在此背景下討論監控事件。

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

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

擴展

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

我們的 Druid 集群部署在多個可用區域，以實現高可用性，并保持每個數據中心的每個示例保留 2 個副本。這使得我們可以在 2 個數據中心共有 4 個副本可用。每個數據中心都有幾百個中間管理器、2 個統治 + 協調（Overlord+Coordinator）節點，15 個代理節點和 80 個歷史節點。

峰值數據流量如下圖所示。

出口設計

數據出口的設計目標是保持數據的高可用性。Druid 代理前面的一層被設計用于查詢 Druid 的數據，以確定每個數據中心的健康狀況。我們希望兩個數據中心的運行狀況始終保持在最佳狀態，且高度可用。如果任何數據中心出現任何數據丟失的情況，出口會切換到數據質量更好的集群。

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

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

結論

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

參考資料

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

 http://druid.io/ 

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

總結

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