我們最終選用了Redshift,它是基于亞馬遜網(wǎng)絡(luò)服務(wù)的數(shù)據(jù)倉庫服務(wù)，它增強(qiáng)了我們的交互分析能力，每天盡可能快的導(dǎo)入數(shù)以億計(jì)的記錄，來確保核心數(shù)據(jù)源的可用性。Redshift是一個(gè)偉大的解決方案，它可以在幾秒鐘內(nèi)回答問題來保證交互數(shù)據(jù)分析和快速的原型(然而Hadoop和Hive用來處理每天兆兆字節(jié)量級(jí)的數(shù)據(jù)，只能在幾鐘或者幾個(gè)小時(shí)內(nèi)給出答案)。

來看看我們?cè)谑褂肦edshift中的一起體驗(yàn)吧：包括了挑戰(zhàn)和收獲，這只是系統(tǒng)的數(shù)億分之一的縮影。

Redshift啟動(dòng)方便并且相當(dāng)可靠，然而面對(duì)千萬億字節(jié)量級(jí)的大量數(shù)據(jù)和快速擴(kuò)張的組織規(guī)模，在生產(chǎn)環(huán)境中使用Redshift,我們將會(huì)面對(duì)一些有趣的挑戰(zhàn)。

挑戰(zhàn)1： 創(chuàng)建100萬億字節(jié)量級(jí)的ETL完成從Hive到Redshift的轉(zhuǎn)化

在Hive中有萬億字節(jié)量級(jí)的數(shù)據(jù)，它需要我們花一些時(shí)間來思考一個(gè)***的實(shí)踐，如何把100萬億字節(jié)的核心數(shù)據(jù)導(dǎo)入到Redshift中。在Hive中有各種格式的數(shù)據(jù)，包括了原始的json,Thrift, RCFile,這些都需要轉(zhuǎn)化成帶有一個(gè)平面模式的文本文件。我們用Python撰寫了模式映射的腳本，通過這些腳本生成Hive查詢來處理重量級(jí)的ETL。

在Hive中，大部分的表都是時(shí)間序列數(shù)據(jù)且按日期分片。為了保證***結(jié)果，我們使用了日期作為排序鍵，每天在各張表后追加數(shù)據(jù)，從而避免高成本的VACUUM操作。另一種方法是每天使用一張表，通過視圖把它們關(guān)聯(lián)，但是我們發(fā)現(xiàn)Redshift沒有很好的視圖查詢優(yōu)化的機(jī)制(例如，它不能下壓LIMIT)。

加載一張大的快照表同樣是一件具有挑戰(zhàn)的事情。我們***的表db_pins它包括了200億個(gè)Pins，在規(guī)模上遠(yuǎn)不止10TB的數(shù)據(jù)。在快照表中加載它會(huì)導(dǎo)致開銷巨大的分片和排序，因此我們?cè)贖ive中做了大量的分片，同時(shí)逐塊兒的加載到Redshift中。

由于Redshift只有有限的存儲(chǔ)空間，我們采用表保留的方式去處理大數(shù)據(jù)的時(shí)間序列的表格，通過周期性的運(yùn)行插入查詢到Redshift中去將有限的數(shù)據(jù)拷貝到新的表格中，這樣做會(huì)比刪除行然后做耗費(fèi)極高的清空，或者舍棄整個(gè)表再重新導(dǎo)入的方法要快得多。

也許***的挑戰(zhàn)是來自于S3最終的一致性。我們發(fā)現(xiàn)在Redshift中有時(shí)候會(huì)有嚴(yán)重的丟數(shù)據(jù)現(xiàn)象，然后追查下來是S3的問題。我們通過綁定一些小的文件的方法來減少在S3上的文件數(shù)量，這樣來減少數(shù)據(jù)丟失。我們同時(shí)在ETL的每一步中添加審計(jì)，這樣數(shù)據(jù)丟失率現(xiàn)在通常已經(jīng)在可以接受的0.0001%以下。

挑戰(zhàn)2：通過Redshift之外的Hives得到100x的速度提升

Redshift生來具備高性能，這使得在原型中對(duì)于一些查詢不需要什么額外的努力，我們可通過Hive得到50-100x的提速，然而一旦進(jìn)入生產(chǎn)環(huán)境，它并不總能像測(cè)試時(shí)那樣與預(yù)期的性能相符。

在早期的測(cè)試中我們發(fā)現(xiàn)一些長(zhǎng)達(dá)數(shù)小時(shí)的查詢，調(diào)試性能問題是相當(dāng)棘手的，這需要收集查詢計(jì)劃、查詢執(zhí)行統(tǒng)計(jì)等，但是最終它沒有明顯的性能問題。

由此得到的教訓(xùn)是需要把數(shù)據(jù)準(zhǔn)備好，無論何時(shí)更新系統(tǒng)的統(tǒng)計(jì)信息是必須的，因?yàn)樗鼤?huì)極大的影響優(yōu)化的的工作。為每張表選擇一個(gè)好的排序鍵和分區(qū)鍵，排序鍵會(huì)容易一些，但是糟糕的分區(qū)鍵將會(huì)歪曲和影響系統(tǒng)的性能。

下面是Hive 和Redshift聚簇的基準(zhǔn)測(cè)試結(jié)果，測(cè)試基于db_pins(200億行，每行有50個(gè)列的，總大小是10TB)和一些其它的核心表。要記得這些比較不包括聚簇大小，資源爭(zhēng)用和其它可能的優(yōu)化機(jī)制，因此比較一點(diǎn)也不科學(xué)。

我們也發(fā)現(xiàn)了一些常識(shí)性的錯(cuò)誤，總結(jié)了我們的***實(shí)踐，創(chuàng)建了工具實(shí)時(shí)的監(jiān)控速度慢的查詢。耗時(shí)超過20分鐘的被視為有嫌疑，工程師們就會(huì)收到提醒，來回顧我們遵守的***實(shí)踐。

或許最常見的錯(cuò)誤是趨向于把“Select *” 這樣的內(nèi)容放在select子句中，這有悖于列存儲(chǔ)，因?yàn)樗枰獟呙枞糠潜匦璧牧小?/p>

挑戰(zhàn)3： 管理不斷增長(zhǎng)的查詢/用戶的爭(zhēng)用。

因?yàn)樾阅芰己茫谖覀兣渲煤煤螅琑edshift被廣泛的應(yīng)用到Pinterest中。我們是一個(gè)高速發(fā)展的機(jī)構(gòu)，越來越多的人們對(duì)并行使用Redshift感興趣，由于大量的查詢爭(zhēng)用資源，查詢的速度明顯的下降。一個(gè)代價(jià)較大的查詢會(huì)占用大量的資源且明顯的影響其它并行的查詢，因此我們需要制定規(guī)則來使得爭(zhēng)用最小化。

我們避免在峰值時(shí)段(上午9點(diǎn)到下午5點(diǎn))使用重量級(jí)的ETL查詢。ETL查詢和COPY一樣會(huì)占用大量的輸入輸出和網(wǎng)絡(luò)帶寬，為了保證用戶的交互查詢要避免在這些時(shí)段使用ETL查詢。我們優(yōu)化了ETL的管道使它在峰值時(shí)間之前完成，或者暫停管道，在峰值后再恢復(fù)。甚至于，在峰值時(shí)段暫停用戶交互查詢。可能包含錯(cuò)誤的長(zhǎng)查詢將會(huì)被立即停止，而不是讓它浪費(fèi)資源。

目前狀況

我們建了16個(gè)hs1.8xlarge性能的節(jié)點(diǎn)。通常在Pinterest上會(huì)有100個(gè)用戶同時(shí)使用Redshift,每天我們運(yùn)行300到500個(gè)交互式的查詢。因?yàn)楹芏嗖樵兌寄茉趲酌腌妰?nèi)完成，總體的性能超過了我們的預(yù)期。以下是上周交互式查詢的持續(xù)百分比。我們可以看到75%的查詢是可以在35秒內(nèi)完成的。

因?yàn)槲覀兂晒Φ氖褂昧薘edshift,我們將繼續(xù)將其集成到我們下一代的工具中。如果你對(duì)這一類的挑戰(zhàn)感興趣，并且有快速的、可擴(kuò)展的方法，請(qǐng)加入我們的團(tuán)隊(duì)。