一 Durid介紹

  Apache Druid是一個高效能的實時分析資料庫。它是為快速查詢和攝取的工作流而設計的。Druid的優勢在於即時資料可見性，即時查詢，運營分析和處理高併發方面。

Druid不是關聯式資料庫，需要的是資料來源，而不是表。與關聯式資料庫相同的是，這些是表示為列的資料的邏輯分組。與關聯式資料庫不同的是沒有連線的概念。因此，Netflix需要確保每個資料來源中都包含Netflix要過濾或分組依據的任何列。資料來源中主要有三類列-時間，維度和指標。

Druid的一切都取決於時間。每個資料來源都有一個timestamp列，它是主要的分割槽機制。維度是可用於過濾，查詢或分組依據的值。指標是可以彙總的值。

 透過消除執行聯接的能力，並假設資料由時間戳作為鍵，Druid可以對儲存，分配和查詢資料的方式進行一些最佳化，從而使Netflix能夠將資料來源擴充套件到數萬億行，並且仍然可以實現查詢響應時間在十毫秒內。

為了達到這種級別的可伸縮性，Druid將儲存的資料分為多個時間塊。時間塊的持續時間是可配置的。可以根據您的資料和用例選擇適當的持續時間。

二 Netfilx遇到的問題

   Netflix使用來自回放裝置的實時日誌作為事件源，Netflix可以得出測量值，以瞭解和量化使用者裝置如何無縫地處理瀏覽和回放。

   一旦有了這些度量，就將它們輸入資料庫。每項措施均標有關於所用裝置種類的匿名詳細資訊，例如，裝置是智慧電視，iPad還是Android手機。這使Netflix能夠根據各個方面對裝置進行分類並檢視資料。反過來，這又使系統能夠隔離僅影響特定人群的問題，例如應用程式的版本，特定型別的裝置或特定國家/地區。以透過儀表板或臨時查詢立即使用此聚合資料進行查詢。還會連續檢查指標是否有警報訊號，例如新版本是否正在影響某些使用者或裝置的播放或瀏覽。這些檢查用於警告負責的團隊，他們可以儘快解決該問題。

在 軟體更新期間，Netflix為部分使用者啟用新版本，並使用這些實時指標來比較新版本與以前版本的效能。指標中的任何迴歸都會使Netflix發出中止更新的訊號，並使那些將新版本恢復為先前版本的使用者恢復原狀。

由於該資料每秒可處理超過200萬個事件，因此將其放入可以快速查詢的資料庫是非常艱鉅的。Netflix需要足夠的維數以使資料在隔離問題中很有用，因此，Netflix每天產生超過1150億行。

三 Netfilx透過Durid處理海量資料分析

資料攝取

  插入到該資料庫是實時發生的。不是從資料集中插入單個記錄，而是從Kafka流中讀取事件（在Netflix的情況下為指標）。每個資料來源使用1個主題。在Druid中，Netflix使用 Kafka索引編制任務，該 任務建立了多個在實時節點（ 中間管理者）之間分佈的索引編制工作器。

這些索引器中的每一個都訂閱該主題並從流中讀取其事件共享。索引器根據 攝入規範從事件訊息中提取值，並將建立的行累積在記憶體中。一旦建立了行，就可以對其進行查詢。到達索引器仍在填充一個段的時間塊的查詢將由索引器本身提供。由於索引編制任務實際上執行兩項工作，即攝取和現場查詢，因此及時將資料傳送到“歷史節點”以更最佳化的方式將查詢工作分擔給歷史節點非常重要。

Druid可以在攝取資料時對其進行彙總，以最大程度地減少需要儲存的原始資料量。彙總是一種彙總或預聚合的形式。在某些情況下，彙總資料可以大大減少需要儲存的資料大小，從而可能使行數減少幾個數量級。但是，減少儲存量確實需要付出一定的代價：Netflix無法查詢單個事件，而只能以預定義的 查詢粒度進行查詢。對於Netflix的用例，Netflix選擇了1分鐘的查詢粒度。

在提取期間，如果任何行具有相同的維度，並且它們的時間戳在同一分鐘內（Netflix的查詢粒度），則這些行將被彙總。這意味著透過將所有度量標準值加在一起並增加一個計數器來合併行，因此Netflix知道有多少事件促成了該行的值。這種彙總形式可以顯著減少資料庫中的行數，從而加快查詢速度，因為這樣Netflix就可以減少要操作和聚合的行。

一旦累積的行數達到某個閾值，或者該段已開啟太長時間，則將這些行寫入段檔案中並解除安裝到深度儲存中。然後，索引器通知協調器該段已準備好，以便協調器可以告訴一個或多個歷史節點進行載入。一旦將該段成功載入到“歷史”節點中，就可以從索引器中將其解除安裝，並且歷史記錄節點現在將為該資料提供任何查詢。

資料處理

   隨著維數基數的增加，在同一分鐘內發生相同事件的可能性降低。管理基數並因此進行彙總，是獲得良好查詢效能的強大槓桿。為了達到所需的攝取速率，Netflix執行了許多索引器例項。即使彙總在索引任務中合併了相同的行，在相同的索引任務例項中獲取全部相同的行的機會也非常低。為了解決這個問題並實現最佳的彙總，Netflix計劃在給定時間塊的所有段都已移交給歷史節點之後執行任務。此計劃的壓縮任務從深度儲存中獲取所有分段以進行時間塊化，並執行對映/還原作業以重新建立分段並實現完美的彙總。然後，由“歷史記錄”節點載入併發布新的細分，以 替換並取代原始的，較少彙總的細分。透過使用此額外的壓縮任務，Netflix看到行數提高了2倍。知道何時收到給定時間塊的所有事件並不是一件容易的事。可能有關於Kafka主題的遲到資料，或者索引器可能會花一些時間將這些片段移交給Historical Node。

查詢方式

Druid支援兩種查詢語言：Druid SQL和本機查詢。在後臺，Druid SQL查詢被轉換為本地查詢。本機查詢作為JSON提交到REST端點，這是Netflix使用的主要機制。

對叢集的大多數查詢是由自定義內部工具（例如儀表板和警報系統）生成的。

為了加快採用Druid的查詢速度並實現對現有工具的重用，Netflix新增了一個轉換層，該層接受Atlas查詢，將其重寫為Druid查詢，釋出查詢並將結果重新格式化為Atlas結果。這個抽象層使現有工具可以按原樣使用，並且不會為使用者訪問Netflix的Druid資料儲存中的資料建立任何額外的學習曲線。

更多精彩內容可以專注我們的線上課堂

微信搜尋公眾號：jfrogchina 獲取課程通知