Airbnb正在為我們社群的數百萬客人和主人提供服務。每一秒，他們都在Airbnb.com上的活動，例如搜尋，預訂和訊息傳遞，都會產生大量資料，我們將其匿名化並用於改善社群在我們平臺上的體驗。

        Airbnb的資料平臺團隊致力於利用這些資料來改善客戶體驗並優化Airbnb的業務。我們的使命是提供基礎設施來收集，組織和處理大量資料（所有這些都以隱私安全的方式），並使Airbnb的各個組織能夠從中獲得必要的分析並從中做出資料知情決策。

        公司內部公開和共享高階分析的主要方式是通過各種儀表板。很多人每天都使用這些儀表板來做出各種決定。儀表板還允許實時跟蹤和監控我們業務和系統的各個方面。因此，這些儀表板的及時性對於Airbnb的日常運營至關重要。但是，我們面臨三個挑戰：

        首先，在倉庫中聚合資料需要很長時間，並在查詢時使用Hive和Presto等系統為這些儀表板生成必要的資料。Hive / Presto必須讀取所有資料並按需聚合，從而導致在查詢時呼叫所有必要的計算。即使這些引擎用於預先計算聚合並存儲它們，儲存格式也不會針對分析查詢所需的資料的重複切片和切割進行優化。

        其次，系統需要可靠和可擴充套件。它正在為Airbnb的核心分析用例提供支援，因此任何停機都會對業務及其員工產生嚴重影響。此外，資料量，查詢量和使用者量也在不斷增長，我們的分析系統應該能夠應對不斷增長的需求。

        再次，我們需要一個與基於開源框架的資料基礎架構完美整合的系統。例如，我們的大多數資料集都儲存在Hadoop中，我們使用Kafka和Spark Streaming來處理我們的資料流。

        這就是我們為什麼要採用Druid的原因。

Druid的優點

快速查詢時間

        通過預定義的資料來源和預先計算的聚合，Druid提供亞秒查詢延遲。建立在Druid之上的儀表板明顯快於在其他系統上構建的儀表板。與Hive和Presto相比，Druid可以快一個數量級。

提供可靠性和可伸縮性的架構

        Druid的架構很好地分為不同的組成部分，用於注入、服務和整體協調。我們發現這種元件化架構對我們的工作負載來說是可靠和穩定的，並且它使我們能夠根據需要輕鬆擴充套件系統。

        Druid將資料儲存分離到深度儲存以便長期儲存資料，同時在歷史節點中臨時快取資料的架構對我們來說效果很好。將分析資料永久儲存在S3中可以免費進行災難恢復，並允許我們輕鬆管理群集硬體的升級和維護（例如，輕鬆切換節點型別以利用最新硬體）。

與開源框架整合

        Druid還與主要基於Hadoop和Kafka的開源資料基礎架構順利整合：

1、Druid的API允許我們輕鬆地從Hadoop中提取資料以進行批量分析

2、Druid通過流處理引擎實現實時分析。Druid提供了一個流媒體客戶端API，Tranquility，它與Samza或Storm等流媒體引擎整合，可以與任何其他基於JVM的流媒體引擎整合。在Airbnb，通過採用Tranquility客戶端的Spark Streaming工作，將資料流傳輸到Druid進行實時分析。

3、Druid與Apache Superset很好地整合，Apache Superset是由Airbnb開發和開源的開源資料視覺化系統。Superset是使用者在Druid上編寫和執行分析查詢並可視化結果的介面。

Airbnb如何使用Druid：雙群集配置
        在Airbnb，兩個Druid叢集正在投入生產。兩個獨立的叢集允許對不同用途的專用支援，即使單個Druid叢集可以處理比我們需要的更多的資料來源。我們總共有4個Broker節點，2個Overlord結點，2個Coordinator節點，8個 MiddleManager節點和40個Historical節點。此外，我們的叢集由一個MySQL伺服器和一個具有5個節點的ZooKeeper叢集支援。與HDFS和Presto等其他服務叢集相比，Druid叢集相對較小且成本較低。

        在兩個Druid叢集中，一個致力於集中的關鍵指標服務。為了服務Airbnb的所有儀表板，使用者可以通過簡單的YAML檔案輕鬆定義他們的指標。使用者可以在Superset上檢視他們的儀表板和指標，而無需瞭解Druid的任何資訊。

        所有批處理作業都使用Airflow進行排程，從Hadoop叢集中提取資料。

        自助使用者的所有實時和其他資料來源都由其他德魯伊叢集處理。通過Spark Streaming + Tranquility客戶端設定獲取實時資料。

改善Airbnb的Druid用法

        雖然Druid提供了許多強大的廣泛適用的功能，以滿足大多數企業，我們確實在Druid內部或之上實現功能，以更好地服務於我們的特殊用例。

即時應答Ad-hoc分析查詢的框架

Airbnb擁有大量嵌入不同業務團隊的資料科學家。他們每個人都可能有關於需要從資料中獲得洞察力的業務的臨時問題，這通常需要任意方式來聚合資料。

為了滿足這一需求，我們在Druid之上構建了一個自助服務系統，允許各個團隊輕鬆定義應用程式或服務生成的資料應如何聚合並作為Druid資料來源公開。然後，資料科學家和分析師可以查詢Druid來回答臨時問題。

使用者使用下面的配置定義其資料來源。來自Kafka的實時資料和來自HDFS / S3的批量資料將根據配置檔案被注入。

Druid通過5分鐘的視窗聚合其實時資料，加上管道延遲1分鐘。

        來自Druid的實時流媒體使我們能夠為使用者提供許多複雜的功能。實時攝取的一個有趣的用例是異常檢測。通過在Druid快速注入和彙總實時資料，我們可以非常快速地檢測到生產中不符合預期模式的任何內容。

與Presto整合

        除了最近版本的SQL查詢支援外，Druid還有一個成熟的查詢機制，使用JSON over HTTP RESTful API。但是，Druid的一個限制是它還不允許跨資料來源查詢（簡單來說，是一個連線查詢）。所有聚合查詢都限於單個數據源。然而，在Airbnb中，我們確實有這樣的場景，其中具有重疊維度的多個數據源需要連線在一起以用於某些查詢。另一種方法是將所有資料儲存在一個數據源中，由於各種原因（包括資料生成的節奏，資料來源不同（例如，不同的服務產生資料）等），這在我們的場景中不是最佳的。但是，對跨資料來源查詢的需求是真實的，並且最近成為一項硬性要求。

        為了迎合這些情況，我們開發了一個基於Presto的內部解決方案。具體來說，我們為Druid引入了Presto聯結器，可以通過單個數據源將查詢推送到Druid，並且可以檢索和連線資料以完成跨資料來源查詢的執行。實施細節仍在不斷髮展，超出了本文的範圍。我們將在未來的單獨帖子中提供更多詳細資訊。

改善回填效能

        Druid查詢比其他系統快得多的祕密是以注入為代價的。在可用於查詢之前，需要首先從MapReduce作業中提取每個資料段。這非常適合作為一次寫入多次讀取模型，並且框架只需要每天注入新資料。

        但是，當資料來源的所有者想要重新設計它並重新生成歷史資料時，就會出現問題。這意味著過去幾年的資料需要重新注入Druid，以取代舊的資料。這需要一個非常大的注入作業和長時間執行的MapReduce任務，這使得它很昂貴，尤其是在重新注入過程中發生錯誤時。

        一種可能的解決方案是將大量注入分成多個請求，以實現更好的可靠性。但是，查詢結果將不一致，因為它將根據現有舊資料和新攝取資料的混合計算。隨著使用者需求和攝取框架功能的發展，回填作業實際上比我們預期的更頻繁，使其效能成為一個需要改進的痛點。

        為了解決這個問題，我們設計了一個解決方案，基本上保持所有新注入的段無效，直到顯式啟用。這使得提取框架能夠將資料來源分成具有可接受大小的較小間隔。然後，框架並行地注入這些間隔（與Yarn叢集資源允許的並行）。由於新注入的資料仍處於非活動狀態，因此當回填注入仍在進行中時，計算執行查詢的結果時，這些段將隱藏在後臺，並且不會混合不同版本的資料。當我們為資料來源啟用最新版本的段時，它將使用新版本重新整理，而不會停機。拆分和重新整理大大提高了回填效能，並且已經制作了用於執行的回填超過一天，現在在一小時內完成。

監測和操作

        我們持續監控Druid的可靠服務和最佳效能。Druid強大且對節點故障具有彈性。大多數節點故障都是透明的，使用者無法察覺。即使作為單點故障的角色（如Coordinator，Overlord甚至ZooKeeper）失敗，Druid叢集仍然能夠為使用者提供查詢服務。但是，SLA出於對使用者的尊重，任何服務中斷都應及時或甚至在發生故障之前發現。

        與其他叢集一樣，我們通過收集機器統計資訊並在任何例項達到其容量或進入不良狀態時發出警報來監控Druid叢集中的每臺機器。為了監控整體群集可用性，我們每隔30分鐘將一段預警資料注入到Druid，並檢查每個Broker節點的查詢結果是否每5分鐘與最新的注入資料匹配。可以在SLA內檢測到服務中的任何降級，包括查詢，注入或下游HDFS不穩定性。

        Druid多年來一直在Airbnb運營，它是維護成本最低的系統之一。Druid的多角色設計使操作變得簡單可靠。群集管理員可以根據監控指標調整群集配置並新增/刪除節點。隨著我們Druid叢集中資料的增長，我們可以繼續新增歷史節點容量來快取並輕鬆地提供大量資料。如果實時注入工作負載顯示上升，我們可以相應地輕鬆新增中間管理器節點。同樣，如果需要更多容量來處理查詢，我們可以增加代理節點數。由於Druid的解耦架構，我們已經完成了一項大型操作，可以將新儲存中的所有資料從HDFS遷移到S3，並重建新的叢集，只需幾分鐘的停機時間。

挑戰和未來的改進
        雖然Druid在我們的資料平臺架構中為我們提供了很好的服務，但隨著我們在公司內部使用Druid的增長，存在新的挑戰。

        我們處理的問題之一是每天產生的需要載入到叢集中的段檔案數量的增長。段檔案是Druid資料的基本儲存單元，包含準備服務的預聚合資料。在Airbnb，我們遇到了一些場景，其中大量的資料來源有時需要完全重新計算，導致大量的段檔案需要一次載入到叢集上。目前，Coordinator在一個執行緒中集中載入所注入的段。隨著越來越多的段生成，Coordinator無法跟上，我們看到注入作業完成的時間與資料可用於查詢的時間（協調器載入後）之間的延遲增加。有時延遲可能是幾個小時。

        通常的解決方案是嘗試增加目標段大小，從而減少段數。但是，在我們的使用中，產生較大段的資料輸入量（由Hadoop工作者執行攝取任務）是如此之高，以至於Hadoop作業執行太長時間處理該資料，並且由於各種原因很多次會失敗。

        我們目前正在探索各種解決方案，包括在注入之後以及在將其傳遞給協調器之前壓縮段，以及不同的配置以增加段大小而不會在可能的情況下危害注入作業穩定性。

結論
        Druid是一個專為可擴充套件性，可維護性和效能而設計的大資料分析引擎。其良好的因素架構可輕鬆管理和擴充套件Druid部署，其優化的儲存格式可實現低延遲分析查詢。目前，國外如Google、Facebook、Airbnb、Instgram、Amazon、Pinterest等，國內如阿里巴巴、小米、360、優酷、知乎、數極客等知名網際網路公司都在使用Druid，發展勢頭如火如荼。相信在不久的將來，Druid將成為下一代OLAP實時分析引擎事實上的標準，讓我們拭目以待吧！

本文由作者吳江林翻譯並整理，轉載請註明出處並保留此資訊，謝謝！