您好,登錄后才能下訂單哦!
本篇內容介紹了“Netflix怎么使用Druid進行業務質量實時分析”的有關知識,在實際案例的操作過程中,不少人都會遇到這樣的困境,接下來就讓小編帶領大家學習一下如何處理這些情況吧!希望大家仔細閱讀,能夠學有所成!
Apache Druid是一個高性能的實時分析數據庫。它是為快速查詢和攝取的工作流而設計的。Druid的優勢在于即時數據可見性,即時查詢,運營分析和處理高并發方面。
Druid不是關系數據庫,需要的是數據源,而不是表。與關系數據庫相同的是,這些是表示為列的數據的邏輯分組。與關系數據庫不同的是沒有連接的概念。因此,Netflix需要確保每個數據源中都包含Netflix要過濾或分組依據的任何列。數據源中主要有三類列-時間,維度和指標。
Druid的一切都取決于時間。每個數據源都有一個timestamp列,它是主要的分區機制。維度是可用于過濾,查詢或分組依據的值。指標是可以匯總的值。
通過消除執行聯接的能力,并假設數據由時間戳作為鍵,Druid可以對存儲,分配和查詢數據的方式進行一些優化,從而使Netflix能夠將數據源擴展到數萬億行,并且仍然可以實現查詢響應時間在十毫秒內。
為了達到這種級別的可伸縮性,Druid將存儲的數據分為多個時間塊。時間塊的持續時間是可配置的。可以根據您的數據和用例選擇適當的持續時間。
Netflix使用來自回放設備的實時日志作為事件源,Netflix可以得出測量值,以了解和量化用戶設備如何無縫地處理瀏覽和回放。
一旦有了這些度量,就將它們輸入數據庫。每項措施均標有關于所用設備種類的匿名詳細信息,例如,設備是智能電視,iPad還是Android手機。這使Netflix能夠根據各個方面對設備進行分類并查看數據。反過來,這又使系統能夠隔離僅影響特定人群的問題,例如應用程序的版本,特定類型的設備或特定國家/地區。以通過儀表板或臨時查詢立即使用此聚合數據進行查詢。還會連續檢查指標是否有警報信號,例如新版本是否正在影響某些用戶或設備的播放或瀏覽。這些檢查用于警告負責的團隊,他們可以盡快解決該問題。
在 軟件更新期間,Netflix為部分用戶啟用新版本,并使用這些實時指標來比較新版本與以前版本的性能。指標中的任何回歸都會使Netflix發出中止更新的信號,并使那些將新版本恢復為先前版本的用戶恢復原狀。
由于該數據每秒可處理超過200萬個事件,因此將其放入可以快速查詢的數據庫是非常艱巨的。Netflix需要足夠的維數以使數據在隔離問題中很有用,因此,Netflix每天產生超過1150億行。
數據攝取
插入到該數據庫是實時發生的。不是從數據集中插入單個記錄,而是從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數據存儲中的數據創建任何額外的學習曲線。
“Netflix怎么使用Druid進行業務質量實時分析”的內容就介紹到這里了,感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站,小編將為大家輸出更多高質量的實用文章!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。