AirBnB如何在Druid上實現數據的實時和批量分析

? ? ? ? Airbnb正在為我們社區(qū)的數百萬客人和主人提供服務。每一秒，他們都在Airbnb.com上的活動，例如搜索，預訂和消息傳遞，都會產生大量數據，我們將其匿名化并用于改善社區(qū)在我們平臺上的體驗。

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

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

? ? ? ? 首先，在倉庫中聚合數據需要很長時間，并在查詢時使用Hive和Presto等系統(tǒng)為這些儀表板生成必要的數據。Hive / Presto必須讀取所有數據并按需聚合，從而導致在查詢時調用所有必要的計算。即使這些引擎用于預先計算聚合并存儲它們，存儲格式也不會針對分析查詢所需的數據的重復切片和切割進行優(yōu)化。

? ? ? ? 其次，系統(tǒng)需要可靠和可擴展。它正在為Airbnb的核心分析用例提供支持，因此任何停機都會對業(yè)務及其員工產生嚴重影響。此外，數據量，查詢量和用戶量也在不斷增長，我們的分析系統(tǒng)應該能夠應對不斷增長的需求。

? ? ? ? 再次，我們需要一個與基于開源框架的數據基礎架構完美集成的系統(tǒng)。例如，我們的大多數數據集都存儲在Hadoop中，我們使用Kafka和Spark Streaming來處理我們的數據流。

? ? ? ? 這就是我們?yōu)槭裁匆捎肈ruid的原因。

Druid的優(yōu)點

快速查詢時間

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

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

? ? ? ? Druid的架構很好地分為不同的組成部分，用于注入、服務和整體協(xié)調。我們發(fā)現這種組件化架構對我們的工作負載來說是可靠和穩(wěn)定的，并且它使我們能夠根據需要輕松擴展系統(tǒng)。

? ? ? ? Druid將數據存儲分離到深度存儲以便長期存儲數據，同時在歷史節(jié)點中臨時緩存數據的架構對我們來說效果很好。將分析數據永久保存在S3中可以免費進行災難恢復，并允許我們輕松管理群集硬件的升級和維護（例如，輕松切換節(jié)點類型以利用最新硬件）。

與開源框架集成

? ? ? ? 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開發(fā)和開源的開源數據可視化系統(tǒng)。Superset是用戶在Druid上編寫和執(zhí)行分析查詢并可視化結果的界面。

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

? ? ? ? 在兩個Druid集群中，一個致力于集中的關鍵指標服務。為了服務Airbnb的所有儀表板，用戶可以通過簡單的YAML文件輕松定義他們的指標。用戶可以在Superset上查看他們的儀表板和指標，而無需了解Druid的任何信息。

? ? ? ? 所有批處理作業(yè)都使用Airflow進行調度，從Hadoop集群中提取數據。

? ? ? ? 自助用戶的所有實時和其他數據源都由其他德魯伊集群處理。通過Spark Streaming + Tranquility客戶端設置獲取實時數據。

改善Airbnb的Druid用法

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

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

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

為了滿足這一需求，我們在Druid之上構建了一個自助服務系統(tǒng)，允許各個團隊輕松定義應用程序或服務生成的數據應如何聚合并作為Druid數據源公開。然后，數據科學家和分析師可以查詢Druid來回答臨時問題。

用戶使用下面的配置定義其數據源。來自Kafka的實時數據和來自HDFS / S3的批量數據將根據配置文件被注入。

Druid通過5分鐘的窗口聚合其實時數據，加上管道延遲1分鐘。

? ? ? ? 來自Druid的實時流媒體使我們能夠為用戶提供許多復雜的功能。實時攝取的一個有趣的用例是異常檢測。通過在Druid快速注入和匯總實時數據，我們可以非?？焖俚貦z測到生產中不符合預期模式的任何內容。

與Presto集成

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

? ? ? ? 為了迎合這些情況，我們開發(fā)了一個基于Presto的內部解決方案。具體來說，我們?yōu)镈ruid引入了Presto連接器，可以通過單個數據源將查詢推送到Druid，并且可以檢索和連接數據以完成跨數據源查詢的執(zhí)行。實施細節(jié)仍在不斷發(fā)展，超出了本文的范圍。我們將在未來的單獨帖子中提供更多詳細信息。

改善回填性能

? ? ? ? Druid查詢比其他系統(tǒng)快得多的秘密是以注入為代價的。在可用于查詢之前，需要首先從MapReduce作業(yè)中提取每個數據段。這非常適合作為一次寫入多次讀取模型，并且框架只需要每天注入新數據。

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

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

? ? ? ? 為了解決這個問題，我們設計了一個解決方案，基本上保持所有新注入的段無效，直到顯式激活。這使得提取框架能夠將數據源分成具有可接受大小的較小間隔。然后，框架并行地注入這些間隔（與Yarn集群資源允許的并行）。由于新注入的數據仍處于非活動狀態(tài)，因此當回填注入仍在進行中時，計算執(zhí)行查詢的結果時，這些段將隱藏在后臺，并且不會混合不同版本的數據。當我們?yōu)閿祿醇せ钭钚掳姹镜亩螘r，它將使用新版本刷新，而不會停機。拆分和刷新大大提高了回填性能，并且已經制作了用于運行的回填超過一天，現在在一小時內完成。

監(jiān)測和操作

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

? ? ? ? 與其他集群一樣，我們通過收集機器統(tǒng)計信息并在任何實例達到其容量或進入不良狀態(tài)時發(fā)出警報來監(jiān)控Druid集群中的每臺機器。為了監(jiān)控整體群集可用性，我們每隔30分鐘將一段預警數據注入到Druid，并檢查每個Broker節(jié)點的查詢結果是否每5分鐘與最新的注入數據匹配?？梢栽赟LA內檢測到服務中的任何降級，包括查詢，注入或下游HDFS不穩(wěn)定性。

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

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

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

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

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

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

本文由作者吳江林翻譯并整理，轉載請注明出處并保留此信息，謝謝！