Airbnb 數(shù)據(jù)基礎(chǔ)設(shè)施與其背后的哲學(xué)

在 Airbnb 我們提倡數(shù)據(jù)文化并使用數(shù)據(jù)作為關(guān)鍵輸入去決策。跟蹤指標(biāo)，通過實(shí)驗(yàn)驗(yàn)證假設(shè)，建立機(jī)器學(xué)習(xí)模型和深入挖掘商業(yè)洞察是我們快速聰明前進(jìn)的關(guān)鍵。經(jīng)過多年的進(jìn)化，我們覺得數(shù)據(jù)基礎(chǔ)設(shè)施服務(wù)穩(wěn)定，可靠，可擴(kuò)展，因此是一個(gè)很好的機(jī)會(huì)來分享我們的經(jīng)驗(yàn)給社區(qū)。

這第一篇關(guān)于 Airbnb。云計(jì)算尤其亞馬遜的云服務(wù)(AWS)提供彈性計(jì)算能力，無需購買昂貴服務(wù)器甚至機(jī)房，通過虛擬化主機(jī)，還提供豐富配套組件，節(jié)約運(yùn)維成本，方便擴(kuò)展，成為很多創(chuàng)業(yè)公司的首選。這里 Airbnb 工程師 James Mayfield 以 AWS 作為基礎(chǔ)搭建數(shù)據(jù)架構(gòu)中走過的坑和經(jīng)驗(yàn)分享，由于筆者也剛好做過，難度 2 星，供做數(shù)據(jù)的朋友學(xué)習(xí)。

第 1 部分：數(shù)據(jù)基礎(chǔ)設(shè)施的背后哲學(xué)

在 Airbnb 我們提倡數(shù)據(jù)文化并使用數(shù)據(jù)作為關(guān)鍵輸入去決策。跟蹤指標(biāo)，通過實(shí)驗(yàn)驗(yàn)證假設(shè)，建立機(jī)器學(xué)習(xí)模型和深入挖掘商業(yè)洞察是我們快速聰明前進(jìn)的關(guān)鍵。

經(jīng)過多年的進(jìn)化，我們覺得數(shù)據(jù)基礎(chǔ)設(shè)施服務(wù)穩(wěn)定，可靠，可擴(kuò)展，因此是一個(gè)很好的機(jī)會(huì)來分享我們的經(jīng)驗(yàn)給社區(qū)。在接下來的幾周內(nèi)，我們將發(fā)布一系列突出我們的分布式架構(gòu)和工具組件的博客文章。由于開源貢獻(xiàn)者提供了許多我們每天使用的基礎(chǔ)系統(tǒng)，使我們不僅樂意分享在公共 GitHub 的項(xiàng)目，而且還會(huì)聊我們一路上學(xué)到的東西。

了解我們數(shù)據(jù)基礎(chǔ)設(shè)施的一些非正式理念：

放眼開源世界：在開源社區(qū)中數(shù)據(jù)基礎(chǔ)設(shè)施有很多好的資源，我們盡量采用這些系統(tǒng)。此外，如果我們建立一些對(duì)自己有用又對(duì)社有回報(bào)的東西。

首選標(biāo)準(zhǔn)組件和方法：有些時(shí)候是發(fā)明一種全新的一塊基礎(chǔ)設(shè)施是合理的，但很多時(shí)候，這沒有很好的利用資源。建立一個(gè)獨(dú)特解決方案是靠直覺還是采用現(xiàn)有的是非常重要的，而靠直覺必須正確考慮維護(hù)支持的隱性成本。

確保它能夠擴(kuò)展：我們發(fā)現(xiàn)數(shù)據(jù)與業(yè)務(wù)不是線性增長(zhǎng)，但隨著技術(shù)員工建立新的產(chǎn)品和在業(yè)務(wù)采取新方式后，將超線性增長(zhǎng)。

通過傾聽你的同事解決實(shí)際問題：與公司的數(shù)據(jù)用戶溝通是了解路線圖的重要組成部分。與亨利·福特的口號(hào)一致，我們必須在找更快的馬與造汽車上保持平衡 – 但首先要聽你的客戶。

留有一定的余量：我們超額認(rèn)購資源如集群，促進(jìn)探索的文化。對(duì)基礎(chǔ)設(shè)施團(tuán)隊(duì)實(shí)現(xiàn)資源利用最大化還高興的太早，但我們的假設(shè)是，在存儲(chǔ)中發(fā)現(xiàn)了一個(gè)新的商業(yè)機(jī)會(huì)將抵消了這些額外的機(jī)器費(fèi)用。

第 2 部分：基礎(chǔ)設(shè)施概況

這里是我們的基礎(chǔ)設(shè)施的主要部件的簡(jiǎn)圖。

源數(shù)據(jù)進(jìn)入我們的系統(tǒng)有兩個(gè)主要渠道：源代碼發(fā)送 Kafka 事件和線上數(shù)據(jù)庫將 AWS RDS 中的存儲(chǔ)導(dǎo)出，再通過 Sqoop 傳遞。

這里數(shù)據(jù)源包含用戶的活動(dòng)事件數(shù)據(jù)和快照源數(shù)據(jù)，發(fā)送到 “金” 集群存儲(chǔ)，并開始運(yùn)行我們的提取，轉(zhuǎn)換和加載(ETL)。在此步驟中，我們針對(duì)業(yè)務(wù)邏輯，匯總表格，并執(zhí)行數(shù)據(jù)質(zhì)量檢查。

在上面的圖中，有 “金” 和 “銀” 兩個(gè)獨(dú)立集群，我們將在后面詳細(xì)描述。分離原因是保證計(jì)算和存儲(chǔ)資源的隔離，如果一個(gè)掛了可以做災(zāi)難恢復(fù)。這種架構(gòu)提供了一個(gè)理想環(huán)境，最重要的工作嚴(yán)格保障 SLA(服務(wù)保證協(xié)議)，避免資源密集型即席查詢的影響。我們把 ‘銀’ 集群作為一個(gè)生產(chǎn)環(huán)境，但是放寬保證，可以承受資源密集型查詢。

通過兩個(gè)集群我們獲得隔離力量，在管理大量的數(shù)據(jù)復(fù)制并維持動(dòng)態(tài)系統(tǒng)之間有同步的成本?！敖稹?是我們的真正來源，我們將復(fù)制 “金” 數(shù)據(jù)的每一位到 “銀”?！般y” 集群上生成的數(shù)據(jù)不會(huì)被復(fù)制回 “金”，所以你可以認(rèn)為這是 “銀” 作為一個(gè)超集集群，是單向復(fù)制方案。因?yàn)槲覀兊暮芏喾治龊蛨?bào)告從 “銀” 簇發(fā)，當(dāng) “金” 有新數(shù)據(jù)產(chǎn)生，我們盡快復(fù)制它到 “銀”，去保證其他工作刻不容緩運(yùn)行。更關(guān)鍵的是，如果我們更新預(yù)先存在的 “金” 集群上的數(shù)據(jù)，我們必須小心的更新并同步傳播給 “銀”。這種復(fù)制優(yōu)化問題并沒有一個(gè)開源的很好解決方案，所以我們建立了一套新的工具，我們會(huì)以后更詳細(xì)地介紹。

我們改進(jìn) HDFS 已經(jīng)取得了很大效果，并更準(zhǔn)確地用 Hive 管理表，作為我們中心源的數(shù)據(jù)。倉庫的質(zhì)量和完整性取決于數(shù)據(jù)不變的，繼承數(shù)據(jù)可通過重新推導(dǎo)計(jì)算的 – 使用分區(qū) Hive 表對(duì)這個(gè)目標(biāo)非常重要。此外，我們不鼓勵(lì)數(shù)據(jù)系統(tǒng)的擴(kuò)散，不希望維護(hù)單獨(dú)的基礎(chǔ)設(shè)施，比如我們的源數(shù)據(jù)和我們終端用戶報(bào)告。根據(jù)我們的經(jīng)驗(yàn)，這些中間系統(tǒng)混淆真理的來源，增加 ETL 的管理負(fù)擔(dān)，難以跟蹤從原始數(shù)據(jù)一路上來自的迭代指標(biāo)。我們不跑 Oracle，Teradata，Vertica，Redshift 等，而是使用 Presto 對(duì)所有 Hive 管理的表做即席查詢。我們都希望在不久的將來，聯(lián)通 Presto 和 Tableau。

其他的一些在圖中要注意的東西，包括 Airpal，使用 Presto 支持基于 Web 查詢執(zhí)行的工具，我們搭建并開源了。這是在數(shù)據(jù)倉庫即席 SQL 查詢，1/3 以上的所有員工都使用該工具運(yùn)行查詢主界面。作業(yè)調(diào)度功能就是通 Airflow，一個(gè)以編程方式編寫，調(diào)度和監(jiān)控的平臺(tái)，可以運(yùn)行在 Hive，Presto，Spark，MySQL 的數(shù)據(jù)管道等。我們?cè)谶壿嬌峡缂汗蚕?Airflow，但物理作業(yè)運(yùn)行在合適的集群機(jī)器上。Spark 集群是工程師和數(shù)據(jù)科學(xué)家機(jī)器學(xué)習(xí)工作偏愛的另一處理工具，對(duì)流處理非常有用。你可以在 Aerosolve 查看我們?cè)?a href='/map/jiqixuexi/' style='color:#000;font-size:inherit;'>機(jī)器學(xué)習(xí)上的努力。 S3 是一個(gè)獨(dú)立的存儲(chǔ)系統(tǒng)，我們可以從 HDFS 數(shù)據(jù)得到便宜的長(zhǎng)期存儲(chǔ)。Hive 管理的表可以對(duì)自己存儲(chǔ)改變，并指向 S3 的文件，容易訪問和管理元數(shù)據(jù)。

第 3 部分：Hadoop 集群的詳細(xì)演化

今年我們從架構(gòu)不佳的集群上進(jìn)行遷移，被稱為 “Pinky 與 Brain”，放到上述的 “金銀” 系統(tǒng)中去。兩年前，我們從 Amazon EMR 移到一組運(yùn)行在 HDFS 300 TB 數(shù)據(jù)的 EC2 實(shí)例。今天，我們有兩個(gè)獨(dú)立的 HDFS 集群，數(shù)據(jù) 11 PB，我們 S3 存儲(chǔ) PB 級(jí)別。有了這樣的背景，我們來解決問題：

1)在 Mesos 架構(gòu)上運(yùn)行一個(gè)獨(dú)特的 Hadoop

早期的 Airbnb 工程師們?cè)谝粋€(gè)叫做 Mesos 上，其中規(guī)定了部署跨多個(gè)服務(wù)器的配置。我們使用 AWS 上 c3.8xlarge 的單一集群。每個(gè) bucket 是 3T 的 EBS，并跑了所有的 Hadoop，Hive，Presto，Chronos 的，和 Mesos 上的 Marathon。

需要明確的是，許多公司都使用 Mesos 實(shí)施新穎的解決方案來管理大型重要基礎(chǔ)設(shè)施。但是，我們的小團(tuán)隊(duì)決定運(yùn)行更加規(guī)范，無處不在的部署，減少我們花在運(yùn)營(yíng)和調(diào)試的時(shí)間。

Mesos 上 Hadoop 問題：

很少能見到工作運(yùn)行和日志文件

很少能見到集群健康狀態(tài)

Hadoop 在 Mesos 只能運(yùn)行 MR1

Task Tracker 競(jìng)爭(zhēng)的性能問題

集群的低利用率

高負(fù)荷，難調(diào)試系統(tǒng)

缺乏整合 Kerberos 安全

解決方法：答案是簡(jiǎn)單地轉(zhuǎn)移到一個(gè) “標(biāo)準(zhǔn)” 棧。我們很樂意從數(shù)百或數(shù)千公司學(xué)習(xí)操作大型集群，而不是試圖去創(chuàng)造一種新的解決方案。

2)遠(yuǎn)程讀取和寫入

之前通過存儲(chǔ)在 EBS(彈性塊存儲(chǔ))上訪問我們所有 HDFS 數(shù)據(jù)，我們發(fā)送到公共 Amazon EC2 運(yùn)行查詢網(wǎng)絡(luò)數(shù)據(jù)。

Hadoop 是為特定硬件搭建，預(yù)先在本地磁盤讀寫，所以這是一個(gè)設(shè)計(jì)不匹配。

關(guān)于遠(yuǎn)程讀寫，我們?cè)e(cuò)誤地選擇了 AWS 在三個(gè)不同的可用性區(qū)域分割我們的數(shù)據(jù)存儲(chǔ)，而它們?cè)谝粋€(gè)區(qū)域內(nèi)。每個(gè)可用區(qū)被定為自己的 “機(jī)架”，3 個(gè)副本分別存放在不同的機(jī)架，因此遠(yuǎn)程讀寫操作都不斷發(fā)生。這又是一個(gè)設(shè)計(jì)缺陷，導(dǎo)致緩慢的數(shù)據(jù)傳輸，當(dāng)一臺(tái)機(jī)器丟失或損壞塊時(shí)候，遠(yuǎn)程拷貝就隨時(shí)發(fā)生。

解決方法：使用本地存儲(chǔ)專門實(shí)例，并在一個(gè)可用性區(qū)域中運(yùn)行，而不是讓 EBS 修正這些問題。

3)同構(gòu)機(jī)器上工作負(fù)載的異構(gòu)

縱觀我們的工作量，我們發(fā)現(xiàn)，我們的構(gòu)件有不同的要求。我們的 Hive/ Hadoop/ HDFS 機(jī)器需大量的儲(chǔ)存空間，但并不需要多少內(nèi)存或 CPU。Presto 和 Spark 渴望內(nèi)存和高處理能力，但并不需要多大的存儲(chǔ)。通過 3TB EBS 支持運(yùn)行 c3.8xlarge 被證明是存儲(chǔ)非常昂貴，也是限制因素。

解決方法：一旦我們遷移出 Mesos 架構(gòu)，我們能選擇不同類型的機(jī)器運(yùn)行各種集群，例如使用 r3.8xlarge 實(shí)例運(yùn)行 Spark。亞馬遜發(fā)布新生代 “D 系列” 的實(shí)例，我們正在評(píng)估，這從成本角度所作的過渡更可取的。從 c3.8xlarge 機(jī)器每個(gè)節(jié)點(diǎn)的遠(yuǎn)程存儲(chǔ) 3TB 轉(zhuǎn)變到 d2.8xlarge 機(jī)器上本地存儲(chǔ) 48TB 是非常有吸引力，會(huì)為我們?cè)谖磥砣旯?jié)省了數(shù)百萬美元。

4)HDFS Federation

我們一直在運(yùn)行Federation HDFS 集群，數(shù)據(jù)共享物理塊池，但每個(gè)邏輯集群分離 mapper 和 reducer 集合。這讓我們可以通過 query 查詢?cè)L問任何一塊數(shù)據(jù)，提高終端用戶體驗(yàn)，但我們發(fā)現(xiàn)，F(xiàn)ederation 并沒有得到廣泛的支持，被某些專家認(rèn)為是實(shí)驗(yàn)性和不可靠的。

解決方法：移到一個(gè)完全不同的 HDFS 節(jié)點(diǎn)，而不是運(yùn)行 Federation，做到在機(jī)器水平的真正隔離，這也提供了更好的災(zāi)難恢復(fù)機(jī)制。

5)系統(tǒng)監(jiān)控是累贅

一個(gè)獨(dú)特的基礎(chǔ)設(shè)施體系最嚴(yán)重的問題是創(chuàng)建自定義監(jiān)視和報(bào)警集群。 Hadoop，Hive，HDFS 是復(fù)雜的系統(tǒng)，容易發(fā)生眾多故障。試圖預(yù)測(cè)所有故障狀態(tài)，并設(shè)置合理的門檻是相當(dāng)有挑戰(zhàn)性。

解決方法：我們簽了 Cloudera 的支持合同，用他們的專業(yè)知識(shí)來獲得在架構(gòu)和操作這些大型系統(tǒng)，以及最重要的通過使用 Cloudera 的管理器工具，減少我們的維護(hù)負(fù)擔(dān)。接入到我們內(nèi)部系統(tǒng)，大大減少了我們的監(jiān)控和報(bào)警負(fù)擔(dān)，這樣我們花很少的時(shí)間進(jìn)行系統(tǒng)維護(hù)和警報(bào)。

結(jié)論

在我們舊的集群上評(píng)估錯(cuò)誤和低效率，開始著手系統(tǒng)地解決這些問題。去遷移 PB 數(shù)據(jù)和數(shù)百個(gè)用戶作業(yè)是一個(gè)漫長(zhǎng)的過程，因?yàn)檫€不破壞我們現(xiàn)有服務(wù);我們將單獨(dú)把一些工具貢獻(xiàn)給開源社區(qū)。

現(xiàn)在，遷移完成后，我們已經(jīng)大大減少了平臺(tái)事故和故障的數(shù)量。不難想象我們?cè)诓怀墒斓钠脚_(tái)上處理的 bug 和問題，但系統(tǒng)現(xiàn)在基本上是穩(wěn)定的。另一個(gè)好處是，當(dāng)我們雇傭新工程師加入我們的團(tuán)隊(duì)，上手很快因?yàn)橄到y(tǒng)也被其他公司采用。

最后，因?yàn)槲覀冇袡C(jī)會(huì)在 “金銀” 系統(tǒng)去設(shè)置新鮮的架構(gòu)，搭建所有新實(shí)例，用合理的方式添加 IAM 角色來管理安全性。這意味著在集群之上提供更為精密的訪問控制層，集成管理我們所有的機(jī)器。