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

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

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

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

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

• 放眼開源世界：在開源社區(qū)中數(shù)據(jù)基礎(chǔ)設(shè)施有很多好的資源，我們盡量采用這些系統(tǒng)。此外，如果我們建立一些對自己有用又對社有回報的東西。
• 首選標準組件和方法：有些時候是發(fā)明一種全新的一塊基礎(chǔ)設(shè)施是合理的，但很多時候，這沒有很好的利用資源。建立一個獨特解決方案是靠直覺還是采用現(xiàn)有的是非常重要的，而靠直覺必須正確考慮維護支持的隱性成本。
• 確保它能夠擴展：我們發(fā)現(xiàn)數(shù)據(jù)與業(yè)務(wù)不是線性增長，但隨著技術(shù)員工建立新的產(chǎn)品和在業(yè)務(wù)采取新方式后，將超線性增長。
• 通過傾聽你的同事解決實際問題：與公司的數(shù)據(jù)用戶溝通是了解路線圖的重要組成部分。與亨利·福特的口號一致，我們必須在找更快的馬與造汽車上保持平衡 - 但首先要聽你的客戶。

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

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

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

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

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

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

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

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

其他的一些在圖中要注意的東西，包括 Airpal，使用 Presto 支持基于 Web 查詢執(zhí)行的工具，我們搭建并開源了。這是在數(shù)據(jù)倉庫即席 SQL 查詢，1/3 以上的所有員工都使用該工具運行查詢主界面。作業(yè)調(diào)度功能就是通 Airflow，一個以編程方式編寫，調(diào)度和監(jiān)控的平臺，可以運行在 Hive，Presto，Spark，MySQL 的數(shù)據(jù)管道等。我們在邏輯上跨集群共享 Airflow，但物理作業(yè)運行在合適的集群機器上。Spark 集群是工程師和數(shù)據(jù)科學(xué)家機器學(xué)習工作偏愛的另一處理工具，對流處理非常有用。你可以在 Aerosolve 查看我們在機器學(xué)習上的努力。 S3 是一個獨立的存儲系統(tǒng)，我們可以從 HDFS 數(shù)據(jù)得到便宜的長期存儲。Hive 管理的表可以對自己存儲改變，并指向 S3 的文件，容易訪問和管理元數(shù)據(jù)。

第 3 部分：Hadoop 集群的詳細演化

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

1)在 Mesos 架構(gòu)上運行一個獨特的 Hadoop

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

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

Mesos 上 Hadoop 問題：

• 很少能見到工作運行和日志文件
• 很少能見到集群健康狀態(tài)
• Hadoop 在 Mesos 只能運行 MR1
• Task Tracker 競爭的性能問題
• 集群的低利用率
• 高負荷，難調(diào)試系統(tǒng)
• 缺乏整合 Kerberos 安全

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

2)遠程讀取和寫入

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

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

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

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

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

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

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

4)HDFS Federation

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

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

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

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

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

結(jié)論

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

現(xiàn)在，遷移完成后，我們已經(jīng)大大減少了平臺事故和故障的數(shù)量。不難想象我們在不成熟的平臺上處理的 bug 和問題，但系統(tǒng)現(xiàn)在基本上是穩(wěn)定的。另一個好處是，當我們雇傭新工程師加入我們的團隊，上手很快因為系統(tǒng)也被其他公司采用。

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

我們能夠明顯削減成本，并同時提高性能。這里有一些數(shù)據(jù)：

• 磁盤讀 / 寫從 70-150MB / 秒提高到 400 + MB / 秒
• Hive 的 CPU 效率提高〜2 倍
• 網(wǎng)卡可以完全跑滿的我們的機器
• 讀吞吐量〜3 倍提升
• 寫吞吐量〜2 倍提升
• 成本減少 70%