深入淺出，詳解Airbnb數據架構
第一部分：數據架構背後的哲學
Airbnb提倡數據信息化，把數據作為決策的重要依據。追蹤指標，假設檢驗、構建機器學習模型和深入挖掘商業機會使得Airbnb一直保持了高速成長。
經過多版本迭代之後，我們認為Airbnb的數據架構棧已經具有穩定、可靠和可擴展性等特性。我們覺得應該把這些構建Airbnb數據架構的經驗回饋給社區。開源貢獻者提供了我們每天使用的許多基礎系統，我們非常樂意不僅回饋公共GitHub repo中的優秀項目，而且還要講述我們在使用過程中學到的東西。
下面基於Airbnb數據架構構建過程的經驗，給出一些我們自己的哲學。
多關注開源社區：在開源社區有很多數據架構方面優秀的資源，需要去學習這些系統。同樣，當我們自己開發了有用的項目也最好回饋給社區，這樣才會有良性循環。
多採用標準組件和方法：雖然有時候創建一個新的組件也是必要的，但更多的時候與其自己重複造輪子還不如充分利用已有的優秀資源。當你憑直覺想去開發出一種獨特的方法時，你得考慮維護和支持這些程序的隱性成本。
確保數據的可擴展性：我們發現數據並不是隨著業務發展線性增長的，隨著技術人員開始開發新產品並在業務增長的基礎上記錄新活動，數據是爆炸式增長的。
通過聆聽同事的意見來解決真正的問題：聆聽公司里的數據使用者的反饋是架構路線圖中非常重要的一步。按照亨利·福特的箴言，我們必須在製造更快的馬和製造汽車之間取得平衡——但首先要傾聽你的客戶。
預留多餘資源：集群資源的超額配置讓我們培養了一種探索無限可能的文化。對於架構團隊來說，經常沉浸在早期資源充足的興奮中，但我們總是假設數據倉庫的新業務總是需要更多的機器資源。
第二部分：數據架構概述
這是一個Airbnb數據架構的簡化示意圖，顯示了我們的架構堆棧的主要組件。
Airbnb數據源主要來自兩個渠道：在代碼中埋點，通過Kafka發送事件；通過RDS上的AWS PITR (AWS point-in-time-restore)獲取的生產資料庫轉儲，然後通過Sqoop交付。
包含用戶活動事件數據和維度快照的源數據隨後被發送到Gold集群，在那裡我們存儲數據並開始執行提取、轉換和載入作業。在這一步中，我們進行業務邏輯計算，生成匯總表和檢查數據質量。
在上圖中，有兩個獨立的Gold集群和Silver集群，我們將在後面更詳細地描述它們。這種分離的主要原因是為了保證計算和存儲資源的隔離，而且如果發生中斷，它可以提供災難恢復保證。在這種架構下，最關鍵的作業可以在嚴格的保證和服務級別協議下運行在Gold環境中，它們不受資源密集的臨時查詢所引起的任何干擾。我們也把Silver集群看作是一個生產環境，但是降低了保證，確保能承受資源密集型查詢的爆發。
請注意，雖然這樣的架構起到了隔離的作用，但它的代價是需要管理大量數據複製和保持動態系統之間的同步。Gold集群是我們的真實數據的來源，我們將所有數據從Gold集群複製到Silver集群，但在Silver集群上產生的數據不會被複制回Gold集群，因此可以將這種方式視為一種單向複製方案，我們將Silver集群作為所有數據的超集。因為我們的許多分析和報告都建立在Silver集群上，所以當新的數據進入Gold集群，我們必須立即把數據從Gold集群複製到Silver集群，以確保所有運行在Silver集群的用戶作業用到的數據是沒有延遲。更重要的是，如果Gold集群上的數據發生了變更，也必須立馬通知Silver集群並將變更傳遞過去。這類複製的優化在現有開源項目中找不到很好的解決方案，因此我們實現了一套新的工具，我們將在後面的文章中詳細描述這些工具。
我們在處理HDFS方面下了大功夫，尤其是更加精確地處理作為數據主要源和接收器的Hive託管表。數據倉庫的質量和完整性取決於數據的不可變性，所有數據的派生都可以使用Hive託管表的分區進行重現，這一點非常重要。此外，我們不提倡建設不同的數據系統，也不希望維護位於源數據和終端用戶報告之間的獨立架構。我們的經驗告訴我們這些中間系統很容易混淆了數據真正的來源，增加了ETL管理的負擔，並使我們想通過儀錶盤迴溯源數據的難度大大增加。我們用Presto執行幾乎所有針對Hive託管表的臨時查詢，而不是Oracle、Teradata、Vertica、Redshift等。我們希望在不久的將來將Presto直接連接到Tableau上。
還有幾點需要注意。首先是上圖中的Airpal，它是我們開發的一個基於Presto的web查詢工具，目前已經開源。Airpal是用戶對數據倉庫的臨時SQL查詢介面，有超過1/3的Airbnb同事在使用此工具進行查詢。然後是Airflow，它是一個作業調度系統，除了提供調度和監控功能，還可以跨平台運行Hive，Presto，Spark，MySQL等平台的作業。邏輯上是跨集群共享Airflow，但是物理上Airflow調度作業是在對應的集群、機器和worker上運行的。接下來是Spark集群，它是機器學習工程師和數據科學家鍾愛的工具，可以提供機器學習和流處理。最後S3作為一個獨立的存儲，數據倉庫團隊從HDFS上取回部分數據，這樣可以減少存儲的成本。可以通過更新Hive託管表來指向S3文件，以便訪問數據和元數據管理。
第三部分：詳述我們Hadoop集群的進化
我們在今年進行了大規模遷移，從一個名為「Pinky and Brain」的糟糕集群遷移到Gold和Silver集群。為了後續擴展性，兩年前遷移Amazon EMR到一組運行HDFS的EC2實例上，其中包含300 TB數據。現在，我們有兩個獨立的HDFS集群，存儲的數據量達11PB。S3上也存儲了好幾PB數據。
下面是遇到的主要問題和對應的解決方案：
在Mesos框架上運行Hadoop
一些早期Airbnb工程師很喜歡一個名為Mesos的框架，便使用這個架構開始在許多伺服器上部署配置。搭建了一個AWS 的c3.8xlarge機器集群，每台機器分配了3TB的EBS(elastic block storage)。在Mesos上運行所有Hadoop、 Hive、Presto、 Chronos和Marathon。
不得不說，許多公司對Mesos委以重任，並採用新穎的解決方案來管理運行重要架構的大型機器。但是，我們的團隊決定運行更標準更普適的部署方式來減少我們在操作和調試上花費的時間。
基於Mesos的Hadoop集群遇到的問題：
- 作業的運行和日誌文件不可見
-Hadoop集群健康狀態不可見
- Mesos只支持MR1
- task tracker連接導致性能問題
- 集群利用率低
- 系統的高負載並很難定位
- 沒有集成安全認證Kerberos
解決方法：轉向「標準」棧，我們選擇了其他運維大型集群的公司都在使用的解決方案，而不是自己造輪子。
遠程讀數據和寫數據
把所有的HDFS數據都存儲在EBS，通過Amazon EC2網路來查詢。Hadoop是基於商用硬體搭建，預先在本地磁碟讀寫，所以這是一個設計錯誤。
我們錯誤地選擇了在AWS中將數據存儲劃分為三個獨立的可用區域AZ(都在一個區域內)。此外，每個可用區域被指定為它自己的機架，因此3個副本存儲在不同的機架上，遠程讀取和寫入經常發生。這又是一個設計缺陷，一旦機器丟失或塊損壞，就會導致數據傳輸緩慢和遠程複製。
解決方法：使用本地存儲的實例以及在單一可用性區域中運行。
同構機器上的異構工作
縱觀我們的工作負載，發現我們的組件有不同的需求。Hive/ Hadoop/ HDFS機器需大量的儲存空間，但並不需要多少內存或CPU。Presto和Spark則需要大量內存和處理能力，但並不需要很多存儲。用3TB EBS來支持c3.8xlarge的運行顯然是筆虧本的買賣，因為存儲正是我們緊缺的資源之一。
解決方法：一旦我們遷移出Mesos架構，我們就能選擇不同類型的機器運行各種集群，例如使用r3.8xlarge實例運行Spark。Amazon正好發布了新一代「D系列」的實例，這使得我們的遷移成本更加低廉。從c3.8xlarge機器每個節點的3TB遠程存儲變為d2.8xlarge機器上48TB本地存儲是非常有吸引力，這會為我們在未來三年節省了數百萬美元。
HDFS Federation
早期我們使用了Pinky和Brain兩個集群聯合，其中數據保存在共享的物理塊池中，而mappers和reducers在每個集群上是邏輯獨立的。這樣用戶可以通過Pinky查詢或Brain查詢訪問任意數據。但不幸的是，這種集群聯合沒有得到廣泛的支持，運行起來也並不穩定。
解決方法：把數據轉移到一組完全不同的HDFS節點，而不是聯合運行，使我們能夠在機器級別真正地隔離集群，這也提供了更好的災難恢復範圍。
繁重的系統監控
定製的系統架構的嚴重問題之一是需要自己開發監控和報警系統。Hadoop、Hive和HDFS都是複雜的系統，經常出現各種bug。試圖跟蹤所有失敗的狀態，並能設置合適的閾值是一項非常具有挑戰性的工作，這又是一個典型的重複製造輪子的例子。
解決方法：通過和Cloudera公司簽訂協議，獲得該公司專家在架構和運維這些大型系統的支持。Cloudera的管理工具大大減少我們維護的負擔，尤其是把它與我們的Chef recipes打通後，減少了監控和報警的工作。
總結
我們分析了舊的集群存在的問題和低效率後，開始系統地解決這些問題。遷移PB級別的數據和數百個用戶作業，而不影響Airbnb正常業務的進行，這是一個漫長的過程。、
遷移已經完成，平台中發生的事件和中斷的數量也大大減少了。不難想像，在不成熟的平台上運行自定義的堆棧時，我們要處理的bug數量和問題的數量是巨大的，但這個系統現在已經經受住考驗，可以說基本上穩定了。遷移的另一個好處是當我們團隊招聘新工程師時，他們上手很快，因為我們使用的這些系統與其他公司採用的系統相似。
最後，因為我們有機會在新的Gold集群和Silver集群設置中構建新的架構，搭建新的實例，以合理的方式添加IAM角色來管理安全性，這意味著在集群之上構建了一個更加合理的訪問控制層，並集成到我們管理所有機器的方式中。
這些改變為公司減少了大量成本，並且優化集群的性能，下面是一些統計數據：
-磁碟讀寫數據的速度從70-150 MB / 秒到400 + MB /秒。
- Hive作業的CPU效率提高2倍。
- 在恰當的情況下，機器上的網路可以完全飽和。
- 讀吞吐量提高了三倍。
- 寫吞吐量提高了兩倍。
- 成本減少了70%。
TAG:BitTiger |