一 、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 獲取課程通知**