? ? Airbnb正在為我們社區(qū)的數(shù)百萬(wàn)客人和主人提供服務(wù)。每一秒，他們都在Airbnb.com上的活動(dòng)，例如搜索，預(yù)訂和消息傳遞，都會(huì)產(chǎn)生大量數(shù)據(jù)，我們將其匿名化并用于改善社區(qū)在我們平臺(tái)上的體驗(yàn)。
? ? Airbnb的數(shù)據(jù)平臺(tái)團(tuán)隊(duì)致力于利用這些數(shù)據(jù)來(lái)改善客戶(hù)體驗(yàn)并優(yōu)化Airbnb的業(yè)務(wù)。我們的使命是提供基礎(chǔ)設(shè)施來(lái)收集，組織和處理大量數(shù)據(jù)（所有這些都以隱私安全的方式），并使Airbnb的各個(gè)組織能夠從中獲得必要的分析并從中做出數(shù)據(jù)知情決策。
? ? 公司內(nèi)部公開(kāi)和共享高級(jí)分析的主要方式是通過(guò)各種儀表板。很多人每天都使用這些儀表板來(lái)做出各種決定。儀表板還允許實(shí)時(shí)跟蹤和監(jiān)控我們業(yè)務(wù)和系統(tǒng)的各個(gè)方面。因此，這些儀表板的及時(shí)性對(duì)于Airbnb的日常運(yùn)營(yíng)至關(guān)重要。但是，我們面臨三個(gè)挑戰(zhàn)：
? ? 首先，在倉(cāng)庫(kù)中聚合數(shù)據(jù)需要很長(zhǎng)時(shí)間，并在查詢(xún)時(shí)使用Hive和Presto等系統(tǒng)為這些儀表板生成必要的數(shù)據(jù)。Hive / Presto必須讀取所有數(shù)據(jù)并按需聚合，從而導(dǎo)致在查詢(xún)時(shí)調(diào)用所有必要的計(jì)算。即使這些引擎用于預(yù)先計(jì)算聚合并存儲(chǔ)它們，存儲(chǔ)格式也不會(huì)針對(duì)分析查詢(xún)所需的數(shù)據(jù)的重復(fù)切片和切割進(jìn)行優(yōu)化。
? ? 其次，系統(tǒng)需要可靠和可擴(kuò)展。它正在為Airbnb的核心分析用例提供支持，因此任何停機(jī)都會(huì)對(duì)業(yè)務(wù)及其員工產(chǎn)生嚴(yán)重影響。此外，數(shù)據(jù)量，查詢(xún)量和用戶(hù)量也在不斷增長(zhǎng)，我們的分析系統(tǒng)應(yīng)該能夠應(yīng)對(duì)不斷增長(zhǎng)的需求。
? ? 再次，我們需要一個(gè)與基于開(kāi)源框架的數(shù)據(jù)基礎(chǔ)架構(gòu)完美集成的系統(tǒng)。例如，我們的大多數(shù)數(shù)據(jù)集都存儲(chǔ)在Hadoop中，我們使用Kafka和Spark Streaming來(lái)處理我們的數(shù)據(jù)流。
? ? 這就是我們?yōu)槭裁匆捎肈ruid的原因。
Druid的優(yōu)點(diǎn)
快速查詢(xún)時(shí)間
? ? 通過(guò)預(yù)定義的數(shù)據(jù)源和預(yù)先計(jì)算的聚合，Druid提供亞秒查詢(xún)延遲。建立在Druid之上的儀表板明顯快于在其他系統(tǒng)上構(gòu)建的儀表板。與Hive和Presto相比，Druid可以快一個(gè)數(shù)量級(jí)。
提供可靠性和可伸縮性的架構(gòu)
? ? Druid的架構(gòu)很好地分為不同的組成部分，用于注入、服務(wù)和整體協(xié)調(diào)。我們發(fā)現(xiàn)這種組件化架構(gòu)對(duì)我們的工作負(fù)載來(lái)說(shuō)是可靠和穩(wěn)定的，并且它使我們能夠根據(jù)需要輕松擴(kuò)展系統(tǒng)。
? ? Druid將數(shù)據(jù)存儲(chǔ)分離到深度存儲(chǔ)以便長(zhǎng)期存儲(chǔ)數(shù)據(jù)，同時(shí)在歷史節(jié)點(diǎn)中臨時(shí)緩存數(shù)據(jù)的架構(gòu)對(duì)我們來(lái)說(shuō)效果很好。將分析數(shù)據(jù)永久保存在S3中可以免費(fèi)進(jìn)行災(zāi)難恢復(fù)，并允許我們輕松管理群集硬件的升級(jí)和維護(hù)（例如，輕松切換節(jié)點(diǎn)類(lèi)型以利用最新硬件）。
與開(kāi)源框架集成
? ? Druid還與主要基于Hadoop和Kafka的開(kāi)源數(shù)據(jù)基礎(chǔ)架構(gòu)順利集成：
1、Druid的API允許我們輕松地從Hadoop中提取數(shù)據(jù)以進(jìn)行批量分析
2、Druid通過(guò)流處理引擎實(shí)現(xiàn)實(shí)時(shí)分析。Druid提供了一個(gè)流媒體客戶(hù)端API，Tranquility，它與Samza或Storm等流媒體引擎集成，可以與任何其他基于JVM的流媒體引擎集成。在Airbnb，通過(guò)采用Tranquility客戶(hù)端的Spark Streaming工作，將數(shù)據(jù)流傳輸?shù)紻ruid進(jìn)行實(shí)時(shí)分析。
3、Druid與Apache Superset很好地集成，Apache Superset是由Airbnb開(kāi)發(fā)和開(kāi)源的開(kāi)源數(shù)據(jù)可視化系統(tǒng)。Superset是用戶(hù)在Druid上編寫(xiě)和執(zhí)行分析查詢(xún)并可視化結(jié)果的界面。
Airbnb如何使用Druid：雙群集配置
? ? ? ? 在Airbnb，兩個(gè)Druid集群正在投入生產(chǎn)。兩個(gè)獨(dú)立的集群允許對(duì)不同用途的專(zhuān)用支持，即使單個(gè)Druid集群可以處理比我們需要的更多的數(shù)據(jù)源。我們總共有4個(gè)Broker節(jié)點(diǎn)，2個(gè)Overlord結(jié)點(diǎn)，2個(gè)Coordinator節(jié)點(diǎn)，8個(gè) MiddleManager節(jié)點(diǎn)和40個(gè)Historical節(jié)點(diǎn)。此外，我們的集群由一個(gè)MySQL服務(wù)器和一個(gè)具有5個(gè)節(jié)點(diǎn)的ZooKeeper集群支持。與HDFS和Presto等其他服務(wù)集群相比，Druid集群相對(duì)較小且成本較低。
? ? 在兩個(gè)Druid集群中，一個(gè)致力于集中的關(guān)鍵指標(biāo)服務(wù)。為了服務(wù)Airbnb的所有儀表板，用戶(hù)可以通過(guò)簡(jiǎn)單的YAML文件輕松定義他們的指標(biāo)。用戶(hù)可以在Superset上查看他們的儀表板和指標(biāo)，而無(wú)需了解Druid的任何信息。
? ? 所有批處理作業(yè)都使用Airflow進(jìn)行調(diào)度，從Hadoop集群中提取數(shù)據(jù)。
? ? 自助用戶(hù)的所有實(shí)時(shí)和其他數(shù)據(jù)源都由其他德魯伊集群處理。通過(guò)Spark Streaming + Tranquility客戶(hù)端設(shè)置獲取實(shí)時(shí)數(shù)據(jù)。
改善Airbnb的Druid用法
? ? 雖然Druid提供了許多強(qiáng)大的廣泛適用的功能，以滿(mǎn)足大多數(shù)企業(yè)，我們確實(shí)在Druid內(nèi)部或之上實(shí)現(xiàn)功能，以更好地服務(wù)于我們的特殊用例。
即時(shí)應(yīng)答Ad-hoc分析查詢(xún)的框架
Airbnb擁有大量嵌入不同業(yè)務(wù)團(tuán)隊(duì)的數(shù)據(jù)科學(xué)家。他們每個(gè)人都可能有關(guān)于需要從數(shù)據(jù)中獲得洞察力的業(yè)務(wù)的臨時(shí)問(wèn)題，這通常需要任意方式來(lái)聚合數(shù)據(jù)。
為了滿(mǎn)足這一需求，我們?cè)贒ruid之上構(gòu)建了一個(gè)自助服務(wù)系統(tǒng)，允許各個(gè)團(tuán)隊(duì)輕松定義應(yīng)用程序或服務(wù)生成的數(shù)據(jù)應(yīng)如何聚合并作為Druid數(shù)據(jù)源公開(kāi)。然后，數(shù)據(jù)科學(xué)家和分析師可以查詢(xún)Druid來(lái)回答臨時(shí)問(wèn)題。
用戶(hù)使用下面的配置定義其數(shù)據(jù)源。來(lái)自Kafka的實(shí)時(shí)數(shù)據(jù)和來(lái)自HDFS / S3的批量數(shù)據(jù)將根據(jù)配置文件被注入。
Druid通過(guò)5分鐘的窗口聚合其實(shí)時(shí)數(shù)據(jù)，加上管道延遲1分鐘。
? ? 來(lái)自Druid的實(shí)時(shí)流媒體使我們能夠?yàn)橛脩?hù)提供許多復(fù)雜的功能。實(shí)時(shí)攝取的一個(gè)有趣的用例是異常檢測(cè)。通過(guò)在Druid快速注入和匯總實(shí)時(shí)數(shù)據(jù)，我們可以非?？焖俚貦z測(cè)到生產(chǎn)中不符合預(yù)期模式的任何內(nèi)容。
與Presto集成
? ? 除了最近版本的SQL查詢(xún)支持外，Druid還有一個(gè)成熟的查詢(xún)機(jī)制，使用JSON over HTTP RESTful API。但是，Druid的一個(gè)限制是它還不允許跨數(shù)據(jù)源查詢(xún)（簡(jiǎn)單來(lái)說(shuō)，是一個(gè)連接查詢(xún)）。所有聚合查詢(xún)都限于單個(gè)數(shù)據(jù)源。然而，在Airbnb中，我們確實(shí)有這樣的場(chǎng)景，其中具有重疊維度的多個(gè)數(shù)據(jù)源需要連接在一起以用于某些查詢(xún)。另一種方法是將所有數(shù)據(jù)保存在一個(gè)數(shù)據(jù)源中，由于各種原因（包括數(shù)據(jù)生成的節(jié)奏，數(shù)據(jù)來(lái)源不同（例如，不同的服務(wù)產(chǎn)生數(shù)據(jù)）等），這在我們的場(chǎng)景中不是最佳的。但是，對(duì)跨數(shù)據(jù)源查詢(xún)的需求是真實(shí)的，并且最近成為一項(xiàng)硬性要求。
? ? 為了迎合這些情況，我們開(kāi)發(fā)了一個(gè)基于Presto的內(nèi)部解決方案。具體來(lái)說(shuō)，我們?yōu)镈ruid引入了Presto連接器，可以通過(guò)單個(gè)數(shù)據(jù)源將查詢(xún)推送到Druid，并且可以檢索和連接數(shù)據(jù)以完成跨數(shù)據(jù)源查詢(xún)的執(zhí)行。實(shí)施細(xì)節(jié)仍在不斷發(fā)展，超出了本文的范圍。我們將在未來(lái)的單獨(dú)帖子中提供更多詳細(xì)信息。
改善回填性能
? ? Druid查詢(xún)比其他系統(tǒng)快得多的秘密是以注入為代價(jià)的。在可用于查詢(xún)之前，需要首先從MapReduce作業(yè)中提取每個(gè)數(shù)據(jù)段。這非常適合作為一次寫(xiě)入多次讀取模型，并且框架只需要每天注入新數(shù)據(jù)。
? ? 但是，當(dāng)數(shù)據(jù)源的所有者想要重新設(shè)計(jì)它并重新生成歷史數(shù)據(jù)時(shí)，就會(huì)出現(xiàn)問(wèn)題。這意味著過(guò)去幾年的數(shù)據(jù)需要重新注入Druid，以取代舊的數(shù)據(jù)。這需要一個(gè)非常大的注入作業(yè)和長(zhǎng)時(shí)間運(yùn)行的MapReduce任務(wù)，這使得它很昂貴，尤其是在重新注入過(guò)程中發(fā)生錯(cuò)誤時(shí)。
? ? 一種可能的解決方案是將大量注入分成多個(gè)請(qǐng)求，以實(shí)現(xiàn)更好的可靠性。但是，查詢(xún)結(jié)果將不一致，因?yàn)樗鼘⒏鶕?jù)現(xiàn)有舊數(shù)據(jù)和新攝取數(shù)據(jù)的混合計(jì)算。隨著用戶(hù)需求和攝取框架功能的發(fā)展，回填作業(yè)實(shí)際上比我們預(yù)期的更頻繁，使其性能成為一個(gè)需要改進(jìn)的痛點(diǎn)。
? ? 為了解決這個(gè)問(wèn)題，我們?cè)O(shè)計(jì)了一個(gè)解決方案，基本上保持所有新注入的段無(wú)效，直到顯式激活。這使得提取框架能夠?qū)?shù)據(jù)源分成具有可接受大小的較小間隔。然后，框架并行地注入這些間隔（與Yarn集群資源允許的并行）。由于新注入的數(shù)據(jù)仍處于非活動(dòng)狀態(tài)，因此當(dāng)回填注入仍在進(jìn)行中時(shí)，計(jì)算執(zhí)行查詢(xún)的結(jié)果時(shí)，這些段將隱藏在后臺(tái)，并且不會(huì)混合不同版本的數(shù)據(jù)。當(dāng)我們?yōu)閿?shù)據(jù)源激活最新版本的段時(shí)，它將使用新版本刷新，而不會(huì)停機(jī)。拆分和刷新大大提高了回填性能，并且已經(jīng)制作了用于運(yùn)行的回填超過(guò)一天，現(xiàn)在在一小時(shí)內(nèi)完成。
監(jiān)測(cè)和操作
? ? 我們持續(xù)監(jiān)控Druid的可靠服務(wù)和最佳性能。Druid強(qiáng)大且對(duì)節(jié)點(diǎn)故障具有彈性。大多數(shù)節(jié)點(diǎn)故障都是透明的，用戶(hù)無(wú)法察覺(jué)。即使作為單點(diǎn)故障的角色（如Coordinator，Overlord甚至ZooKeeper）失敗，Druid集群仍然能夠?yàn)橛脩?hù)提供查詢(xún)服務(wù)。但是，SLA出于對(duì)用戶(hù)的尊重，任何服務(wù)中斷都應(yīng)及時(shí)或甚至在發(fā)生故障之前發(fā)現(xiàn)。
? ? 與其他集群一樣，我們通過(guò)收集機(jī)器統(tǒng)計(jì)信息并在任何實(shí)例達(dá)到其容量或進(jìn)入不良狀態(tài)時(shí)發(fā)出警報(bào)來(lái)監(jiān)控Druid集群中的每臺(tái)機(jī)器。為了監(jiān)控整體群集可用性，我們每隔30分鐘將一段預(yù)警數(shù)據(jù)注入到Druid，并檢查每個(gè)Broker節(jié)點(diǎn)的查詢(xún)結(jié)果是否每5分鐘與最新的注入數(shù)據(jù)匹配。可以在SLA內(nèi)檢測(cè)到服務(wù)中的任何降級(jí)，包括查詢(xún)，注入或下游HDFS不穩(wěn)定性。
? ? Druid多年來(lái)一直在Airbnb運(yùn)營(yíng)，它是維護(hù)成本最低的系統(tǒng)之一。Druid的多角色設(shè)計(jì)使操作變得簡(jiǎn)單可靠。群集管理員可以根據(jù)監(jiān)控指標(biāo)調(diào)整群集配置并添加/刪除節(jié)點(diǎn)。隨著我們Druid集群中數(shù)據(jù)的增長(zhǎng)，我們可以繼續(xù)添加歷史節(jié)點(diǎn)容量來(lái)緩存并輕松地提供大量數(shù)據(jù)。如果實(shí)時(shí)注入工作負(fù)載顯示上升，我們可以相應(yīng)地輕松添加中間管理器節(jié)點(diǎn)。同樣，如果需要更多容量來(lái)處理查詢(xún)，我們可以增加代理節(jié)點(diǎn)數(shù)。由于Druid的解耦架構(gòu)，我們已經(jīng)完成了一項(xiàng)大型操作，可以將新存儲(chǔ)中的所有數(shù)據(jù)從HDFS遷移到S3，并重建新的集群，只需幾分鐘的停機(jī)時(shí)間。
挑戰(zhàn)和未來(lái)的改進(jìn)
? ? ? ? 雖然Druid在我們的數(shù)據(jù)平臺(tái)架構(gòu)中為我們提供了很好的服務(wù)，但隨著我們?cè)诠緝?nèi)部使用Druid的增長(zhǎng)，存在新的挑戰(zhàn)。
? ? 我們處理的問(wèn)題之一是每天產(chǎn)生的需要加載到集群中的段文件數(shù)量的增長(zhǎng)。段文件是Druid數(shù)據(jù)的基本存儲(chǔ)單元，包含準(zhǔn)備服務(wù)的預(yù)聚合數(shù)據(jù)。在Airbnb，我們遇到了一些場(chǎng)景，其中大量的數(shù)據(jù)源有時(shí)需要完全重新計(jì)算，導(dǎo)致大量的段文件需要一次加載到集群上。目前，Coordinator在一個(gè)線(xiàn)程中集中加載所注入的段。隨著越來(lái)越多的段生成，Coordinator無(wú)法跟上，我們看到注入作業(yè)完成的時(shí)間與數(shù)據(jù)可用于查詢(xún)的時(shí)間（協(xié)調(diào)器加載后）之間的延遲增加。有時(shí)延遲可能是幾個(gè)小時(shí)。
? ? 通常的解決方案是嘗試增加目標(biāo)段大小，從而減少段數(shù)。但是，在我們的使用中，產(chǎn)生較大段的數(shù)據(jù)輸入量（由Hadoop工作者運(yùn)行攝取任務(wù)）是如此之高，以至于Hadoop作業(yè)運(yùn)行太長(zhǎng)時(shí)間處理該數(shù)據(jù)，并且由于各種原因很多次會(huì)失敗。
? ? 我們目前正在探索各種解決方案，包括在注入之后以及在將其傳遞給協(xié)調(diào)器之前壓縮段，以及不同的配置以增加段大小而不會(huì)在可能的情況下危害注入作業(yè)穩(wěn)定性。
結(jié)論
? ? ? ? Druid是一個(gè)專(zhuān)為可擴(kuò)展性，可維護(hù)性和性能而設(shè)計(jì)的大數(shù)據(jù)分析引擎。其良好的因素架構(gòu)可輕松管理和擴(kuò)展Druid部署，其優(yōu)化的存儲(chǔ)格式可實(shí)現(xiàn)低延遲分析查詢(xún)。目前，國(guó)外如Google、Facebook、Airbnb、Instgram、Amazon、Pinterest等，國(guó)內(nèi)如阿里巴巴、小米、360、優(yōu)酷、知乎、數(shù)極客等知名互聯(lián)網(wǎng)公司都在使用Druid，發(fā)展勢(shì)頭如火如荼。相信在不久的將來(lái)，Druid將成為下一代OLAP實(shí)時(shí)分析引擎事實(shí)上的標(biāo)準(zhǔn)，讓我們拭目以待吧！
本文由作者吳江林翻譯并整理，轉(zhuǎn)載請(qǐng)注明出處并保留此信息，謝謝！
另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)scvps.cn，海內(nèi)外云服務(wù)器15元起步，三天無(wú)理由+7*72小時(shí)售后在線(xiàn)，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國(guó)服務(wù)器、虛擬主機(jī)、免備案服務(wù)器”等云主機(jī)租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡(jiǎn)單易用、服務(wù)可用性高、性?xún)r(jià)比高”等特點(diǎn)與優(yōu)勢(shì)，專(zhuān)為企業(yè)上云打造定制，能夠滿(mǎn)足用戶(hù)豐富、多元化的應(yīng)用場(chǎng)景需求。
重慶分公司
重慶分公司
