重度使用AWS及Hadoop，Pinterest的自服務(wù)平臺(tái)打造歷程

【編者按】大數(shù)據(jù)為Pinterest打造了線上最豐富的興趣集，在網(wǎng)站的配置和運(yùn)營(yíng)中發(fā)揮著重要的作用，為了迅速搭建大數(shù)據(jù)平臺(tái)，Pinterest將單個(gè)集群Hadoop基礎(chǔ)設(shè)施升級(jí)為一個(gè)通用的自服務(wù)平臺(tái)。近日，Pinterest在該公司的博客上公布了這個(gè)平臺(tái)的打造過程。

免費(fèi)訂閱“CSDN大數(shù)據(jù)”微信公眾號(hào)，實(shí)時(shí)了解最新的大數(shù)據(jù)進(jìn)展！

CSDN大數(shù)據(jù)，專注大數(shù)據(jù)資訊、技術(shù)和經(jīng)驗(yàn)的分享和討論，提供Hadoop、Spark、Imapala、Storm、HBase、MongoDB、Solr、機(jī)器學(xué)習(xí)、智能算法等相關(guān)大數(shù)據(jù)觀點(diǎn)，大數(shù)據(jù)技術(shù)，大數(shù)據(jù)平臺(tái)，大數(shù)據(jù)實(shí)踐，大數(shù)據(jù)產(chǎn)業(yè)資訊等服務(wù)。

大數(shù)據(jù)在Pinterest中扮演著重要的角色。系統(tǒng)中有300多億Pins，我們打造了線上最豐富的興趣集。打造個(gè)性化搜索引擎的一個(gè)挑戰(zhàn)是擴(kuò)展數(shù)據(jù)基礎(chǔ)設(shè)施以遍歷興趣圖譜，進(jìn)而提取每一Pin的內(nèi)容和意圖。

目前我們每天更新20TB數(shù)據(jù)，S3每天會(huì)更新大概10TB數(shù)據(jù)。我們使用Hadoop處理這些數(shù)據(jù)，Hadoop使得我們可以通過Related Pins、Guided Search及image processing等功能將最相關(guān)和最新的內(nèi)容呈現(xiàn)給 Pinners。Hadoop每天可以幫助我們執(zhí)行數(shù)千個(gè)度量，探測(cè)嚴(yán)格實(shí)驗(yàn)條件下的用戶變化并進(jìn)行分析。

為了迅速搭建大數(shù)據(jù)應(yīng)用，我們將單個(gè)集群Hadoop基礎(chǔ)設(shè)施升級(jí)為一個(gè)通用的自服務(wù)平臺(tái)。

為Hadoop搭建一個(gè)自服務(wù)平臺(tái)

盡管Hadoop是一個(gè)強(qiáng)大的處理和存儲(chǔ)系統(tǒng)，但是它還不是一項(xiàng)即插即用的技術(shù)。因?yàn)镠adoop沒有云計(jì)算和彈性計(jì)算，也不面向非技術(shù)用戶，所以最初的Hadoop設(shè)計(jì)無法作為一個(gè)自服務(wù)系統(tǒng)。好在很多Hadoop庫、Hadoop應(yīng)用和服務(wù)提供商針對(duì)這些局限提供了解決方案。在選擇解決方案前，我們先討論了我們的Hadoop設(shè)置需求。

1.  多租戶隔離：MapReduce上有許多需求和配置不同應(yīng)用程序，開發(fā)者應(yīng)該在不影響他人工作的前提下優(yōu)化自己的工作。

2.  彈性：批處理通常需要突發(fā)性能來支持實(shí)驗(yàn)開發(fā)。一個(gè)理想的配置中，我們可以擴(kuò)展至數(shù)千個(gè)節(jié)點(diǎn)集群，然后在不導(dǎo)致任何中斷和數(shù)據(jù)損失的情況下減少規(guī)模。

3.  多集群支持：盡管我們可以水平擴(kuò)展單個(gè)Hadoop集群，我們發(fā)現(xiàn)：很難獲得理想的隔離性和彈性；諸如隱私、安全、成本分?jǐn)偟壬虡I(yè)需求使多集群支持更為實(shí)用。

4.  支持臨時(shí)集群：用戶應(yīng)當(dāng)可以在需要使用集群時(shí)獲得集群，并可以隨時(shí)退出集群。集群在合理的時(shí)間范圍內(nèi)存在，并可以在不需要手動(dòng)配置的情況下全面支持所有的Hadoop工作。

5.  易于軟件包部署：從OS和Hadoop層到具體業(yè)務(wù)腳層面，我們需要為用戶提供定制化的接口。

6.  共享數(shù)據(jù)存儲(chǔ)：Hadoop也應(yīng)可以訪問其它集群產(chǎn)生的數(shù)據(jù)。

7.  訪問控制層：和其它的服務(wù)導(dǎo)向的系統(tǒng)一樣，我們需要快速添加和修改訪問（如非SSH關(guān)鍵詞）。理想情況下，我們可以和現(xiàn)有認(rèn)證（如通過OAUTH）整合。

權(quán)衡和實(shí)施

總結(jié)出需求后，我們?cè)谝幌盗凶孕虚_發(fā)的、開源的和商業(yè)專有的解決方案中尋找符合我們需求的解決方案。

解耦計(jì)算和存儲(chǔ)：為加快處理速度，傳統(tǒng)的MapReduce采用數(shù)據(jù)本地化。實(shí)際中，我們發(fā)現(xiàn)網(wǎng)絡(luò)I/O（我們使用的是S3）并沒有比磁盤I/O慢很多。通過支付網(wǎng)絡(luò)I/O的邊際成本和將計(jì)算從存儲(chǔ)分離，我們很容易的實(shí)現(xiàn)我們的自服務(wù)Hadoop平臺(tái)的許多需求。例如，因?yàn)槲覀儾辉傩枰紤]加載或同步數(shù)據(jù)，所以多集群支持變得很容易，任何現(xiàn)有或?qū)淼募憾伎梢酝ㄟ^一個(gè)共享文件系統(tǒng)使用數(shù)據(jù)。不需要擔(dān)心數(shù)據(jù)意味著更簡(jiǎn)單的操作，這是因?yàn)槲覀兛梢栽诓粊G失任何工作的情況下進(jìn)行硬復(fù)位或丟棄一個(gè)集群，遷移到另一個(gè)集群。這也意味著我們可以使用動(dòng)態(tài)的節(jié)點(diǎn)，因此我們可以支付低廉的計(jì)算機(jī)費(fèi)用，不擔(dān)心損失任何持久性數(shù)據(jù)。

集中式Hive元存儲(chǔ)作為解決方案：我們大部分的工作都選用Hadoop，這是因?yàn)镾QL接口很簡(jiǎn)單，業(yè)界對(duì)SQL接口也很熟悉。隨著時(shí)間的推移，我們發(fā)現(xiàn)使用元存儲(chǔ)作為Hadoop工作的數(shù)據(jù)目錄時(shí)，Hive還會(huì)帶來額外的好處。Hive很像其它的SQL工具，它提供了諸如“show tables”，“describe table”和“show partitions”的功能。這個(gè)接口比在目錄中決定生成文件的清單文件簡(jiǎn)潔的多，也快的多，一致性也更好，這是因?yàn)镸ySQL數(shù)據(jù)庫支持著這個(gè)接口。S3的清單文件很慢，S3不支持移動(dòng)，還有一致性的問題。因?yàn)槲覀円蕾囉赟3，所以Hive的這些特性顯得更重要。

我們用與現(xiàn)有磁盤數(shù)據(jù)保持Hive元數(shù)據(jù)一致性的方式排列工作（是Hive，Cascading，Hadoop Steaming還是其它的）。因此，我們可以在多集群和多工作流更新磁盤數(shù)據(jù)，無需擔(dān)心用戶可能獲得部分?jǐn)?shù)據(jù)。

多層包/配置：Hadoop應(yīng)用間差異很大，每個(gè)應(yīng)用都可能有獨(dú)特的需求和依賴項(xiàng)。我們需要一種靈活的、可以權(quán)衡可定制性和快速配置/速度的方法。

我們采用一種三層的方法來管理依賴項(xiàng)，這種方法可以將產(chǎn)生、調(diào)用一個(gè)千節(jié)點(diǎn)集群的時(shí)間從45分鐘減到5分鐘。

1.  Baking AMI

對(duì)于那些較大的、需要花一段時(shí)間安裝的依賴項(xiàng)，我們將他們預(yù)安裝。其中包括我們?yōu)榱藝H化所采用的Hadoop庫和NLP庫包。我們將這一過程稱為“baking an AMI”。不幸的是，很多Hadoop服務(wù)供應(yīng)商尚不支持這種方法。

2.  自動(dòng)化配置（無管理的Puppet）

我們大部分的定制化服務(wù)是使用Puppet管理的。在引導(dǎo)程序階段，我們的集群在每個(gè)節(jié)點(diǎn)都安裝和配置Puppet，僅需幾分鐘的時(shí)間，Puppet就可以將我們的節(jié)點(diǎn)和Puppet配置指定的依賴項(xiàng)匹配。

目前，Puppet主要的局限性如下：當(dāng)我們?cè)谏a(chǎn)系統(tǒng)添加新節(jié)點(diǎn)時(shí)，這些新節(jié)點(diǎn)會(huì)自動(dòng)聯(lián)系Puppet管理，推翻新配置，這常常會(huì)覆蓋主節(jié)點(diǎn)，進(jìn)而導(dǎo)致錯(cuò)誤。為了避免這種錯(cuò)誤，我們?cè)试SPuppet客戶端從S3獲取配置，設(shè)置一個(gè)負(fù)責(zé)同步S3配置和Puppet管理的服務(wù)，從而將Puppet客戶端設(shè)置為“無管理”。

3. 運(yùn)行階段（在S3上）

MapReduce工作間發(fā)生的大部分定制化服務(wù)都涉及jars，工作配置和自定義代碼。開發(fā)組需要可以在開發(fā)環(huán)境中修改這些依賴項(xiàng)，并且在不影響其他工作的前提下使這些依賴項(xiàng)在我們的任意一個(gè)Hadoop集群中可用。為了權(quán)衡靈活性、速度和隔離性，我們?yōu)镾3上的每個(gè)開發(fā)者創(chuàng)建了一個(gè)隔離的工作目錄?，F(xiàn)在，當(dāng)一個(gè)工作執(zhí)行時(shí)，一個(gè)工作目錄面向一個(gè)開發(fā)者，工作路徑的依賴項(xiàng)直接從S3獲得。

執(zhí)行抽象層

先前，我們使用亞馬遜的Elastic MapReduce（EMR）運(yùn)行我們的Hadoop工作。EMR和S3、Spot實(shí)例運(yùn)行的很好，通常也很穩(wěn)定。但當(dāng)我們擴(kuò)展到幾百個(gè)節(jié)點(diǎn)時(shí)，EMR變得沒那么穩(wěn)定，我們遇到了EMR的局限。我們?cè)贓MR上搭建了很多應(yīng)用，以至于我們很難遷移到一個(gè)新系統(tǒng)。我們也不知道更換到哪種系統(tǒng)，因?yàn)镋MR的一些細(xì)微差異會(huì)導(dǎo)致實(shí)際工作邏輯差異。為了試驗(yàn)其它類型的Hadoop，我們實(shí)施了一個(gè)執(zhí)行接口，將所有的EMR特定邏輯都遷移到EMR執(zhí)行接口。 這個(gè)接口實(shí)施了一系列方法，如“run_raw_hive_query（query_str）” 和 “run_java_job（class_path）”。這使得我們具有在幾種Hadoop和Hadoop服務(wù)供應(yīng)商上實(shí)驗(yàn)的靈活性，并可以以最小的停機(jī)時(shí)間逐漸遷移。

最終采用Qubole

最終我們決定將我們的Hadoop工作遷移到Qubole，Quble是Hadoop服務(wù)市場(chǎng)的新秀?？紤]到目前我們的規(guī)模下EMR不再穩(wěn)定，我們必須快速遷移到一個(gè)良好支持AWS（特別是spot實(shí)例）和S3的供應(yīng)商。Qubole支持AWS/S3，并且起步簡(jiǎn)單。在審核Qubole，并將其性能和幾個(gè)候選者（包括管理集群）比較后，我們選擇了Qubole，原因如下：

• 單個(gè)集群和橫向擴(kuò)展至1000個(gè)節(jié)點(diǎn)
• 提供24/7的數(shù)據(jù)基礎(chǔ)設(shè)施工程服務(wù)
• 與Hive緊密集成
• Google“面向非技術(shù)用戶的OAUTH ACL和Hive Web UI”
• 面向簡(jiǎn)化的執(zhí)行抽象層+多集群支持的API
• Baking AMI定制化服務(wù)（專業(yè)版支持可用）
• 面向spot實(shí)例的高級(jí)支持―100%支持spot實(shí)例集群
• S3最終一致性保護(hù)
• 優(yōu)雅的集群擴(kuò)展和自動(dòng)擴(kuò)展

總的來說，使用Qubole對(duì)我們而言是一個(gè)正確的決定，Qubole團(tuán)隊(duì)的技術(shù)和實(shí)施工作深深地打動(dòng)了我們。從去年開始，Qubole證明了其在拍字節(jié)規(guī)模的穩(wěn)定性，相比EMR，為我們提高了30%~60%的吞吐量。非技術(shù)用戶也很容易上手Qubole。

我們目前的狀態(tài)

在我們當(dāng)下的配置下，Hadoop是一項(xiàng)應(yīng)用在多組織、操作費(fèi)用低的靈活服務(wù)。我們有100多個(gè)常規(guī)Mapreduce用戶，他們每天通過Qubole網(wǎng)絡(luò)接口、ad-hoc工作和計(jì)劃工作流運(yùn)行著2000多個(gè)工作。

我們有6個(gè)Hadoop集群，他們由3000多個(gè)節(jié)點(diǎn)組成，開發(fā)者可以在幾分鐘內(nèi)選擇創(chuàng)建自己的Hadoop集群。我們每天生成200億日志信息，處理大概1拍字節(jié)的數(shù)據(jù)。

我們也在試驗(yàn)者管理Hadoop集群，其中包括Hadoop2，不過目前，使用諸如S3和Qubole的云服務(wù)對(duì)我們而言是正確的選擇，因?yàn)樗鼈儗⑽覀儚腍adoop的操作開銷中解放出來，使我們可以專注于大數(shù)據(jù)應(yīng)用的工程工作。

原文鏈接： Powering big data at Pinterest（翻譯/仁君  責(zé)編/仲浩）

生活不易，碼農(nóng)辛苦
如果您覺得本網(wǎng)站對(duì)您的學(xué)習(xí)有所幫助,可以手機(jī)掃描二維碼進(jìn)行捐贈(zèng)