eBay使用Teradata已經(jīng)有二十年的歷史，這個數(shù)倉系統(tǒng)中積累了60PB數(shù)據(jù)和上萬張核心表，他們支撐著eBay最核心的商務邏輯和站點功能。從今年開始，eBay開始將這個龐大的數(shù)倉由Teradata向Spark做遷移，使用eBay自己開發(fā)的工具，遷移過程中90%的工作都可以由自動化完成。與此同時，研究人員通過優(yōu)化Spark框架，節(jié)省了一半的內存。

正所謂“數(shù)據(jù)遷移無小事”，是什么痛點促使eBay決定要啟動數(shù)據(jù)倉庫遷移這項工作?eBay在數(shù)據(jù)倉庫遷移的過程中做了哪些嘗試?又得到了哪些經(jīng)驗和教訓?為了進一步了解eBay將數(shù)據(jù)倉庫從Teradata遷移到Spark過程中的實踐和經(jīng)驗，我們與eBay大數(shù)據(jù)架構師俞育才聊了聊。

Teradata在過去的二十年為eBay提供了非常優(yōu)秀的數(shù)倉服務，支撐起了eBay龐大的業(yè)務規(guī)模。二十多年積累下來的數(shù)據(jù)已經(jīng)將數(shù)據(jù)倉庫變得非常龐大，所謂“牽一發(fā)而動全身”，哪怕只是微小的改動也會牽涉大量數(shù)據(jù)和業(yè)務邏輯，更何況是數(shù)據(jù)倉庫遷移這樣的大動作。

為什么決定遷移?

俞育才表示，隨著業(yè)務的發(fā)展，原有的模式體現(xiàn)出了一些不方便的地方，這些問題促使eBay開始嘗試數(shù)據(jù)倉庫遷移的工作。

首先，技術上不夠靈活。eBay有很多自己特有的場景，供應商的軟件很難為此去定制，或者需要eBay去適應供應商的路線圖，這存在很大的局限性。如果使用開源軟件，可以主動地參與開發(fā)，為自己的需求做深度的定制，更好地滿足業(yè)務的發(fā)展。

其次，通過開源軟件可以大大擴展數(shù)倉的能力。傳統(tǒng)的數(shù)倉就是做批處理，但是現(xiàn)代的數(shù)倉是個很寬泛的概念。除了批處理，eBay還需要處理實時數(shù)據(jù)、做圖計算、做機器學習。不可能要求Teradata來提供這么多的功能。

另外，eBay還可以基于開源軟件對成本和性能做極致的優(yōu)化。早在2014年的時候，eBay就開始嘗試使用開源軟件。剛開始，開源軟件的成本也是很高的。隨著持續(xù)地優(yōu)化，成本下降得很快。到2018年，開源軟件的開銷已經(jīng)和供應商的專有軟件差不多了。按照這個趨勢，明年的開源系統(tǒng)的TCO甚至可以超過專有軟件。”

最后，從公司的角度講，也希望有更加多樣化多元化的投資。

Spark是新數(shù)據(jù)倉庫的最優(yōu)選擇

下定了遷移的決心，下一步就要開始技術選型工作了，市面上開源的大數(shù)據(jù)框架、數(shù)據(jù)倉庫那么多，eBay最終選擇了Spark。

問及個中緣由，俞育才表示：“我們想要打造一個真正的現(xiàn)代化數(shù)倉，除了支持超大規(guī)模數(shù)據(jù)處理，還要能夠支持實時化和智能化。Spark提供了一站式數(shù)據(jù)處理的能力，不僅可以做傳統(tǒng)的批處理，還可以做流處理、圖計算和機器學習，這非常符合我們的期望，也是其他系統(tǒng)所不具備的。其次，Spark的性能非常好。這得益于它強大的內存計算能力，以及Catalyst、Tungsten帶來的諸多優(yōu)化。另外，Spark的社區(qū)很強大。Spark是Github上最活躍的大數(shù)據(jù)框架之一，各種問題都可以得到很快的反饋。最后，在兼容性方面， Spark對SQL有非常好的支持，使得我們的分析師可以很方便地遷移到Spark上。隨著2.0的發(fā)布，Spark已經(jīng)日趨成熟，我們認為在這個時間點做遷移是個非常正確的選擇。”

技術選型方面，eBay做了很多嘗試。一開始嘗試的是MapReduce和Cascading，但它們的開發(fā)周期太長了。而且分析師的強項并不是編程，他們需要花費很大的精力去學習怎么開發(fā)一個好的作業(yè)。接下來，團隊又嘗試了Hive。但是Hive的性能不是非常好，一些案例并沒能跑出來，并且Hive也不支持流和機器學習。Presto在數(shù)據(jù)量不大的情況下，是可以做內存計算的，性能也很不錯，但是大查詢可能會直接失敗，因為它是為交互式查詢設計的，容錯并不是第一考慮。

綜合以上這些，Spark幾乎是一個不二選擇。在做原型的時候，eBay大數(shù)據(jù)團隊找了一些非常核心也相對比較重的作業(yè)，用Spark去跑，發(fā)現(xiàn)不僅僅是跑下來了，而且調優(yōu)之后，性能成本都還不錯，這給了整個團隊很大的信心。

需要1000個人月的數(shù)據(jù)遷移如何從不可能變?yōu)榭赡?

數(shù)據(jù)倉庫的遷移主要包含兩方面工作，一個是表的遷移，另一個是作業(yè)的遷移。

eBay第一期遷移的數(shù)倉就有30PB之大，包括5000張的目標表、20000張的臨時表和50000個作業(yè)。經(jīng)過估算，如果是手動遷移，大概需要1000個人月，相當于50個數(shù)據(jù)工程師，專職做遷移也需要兩年，這是非常大的開銷。所以必須做自動化遷移。

另一方面，表和作業(yè)之間是有依賴關系的。比如，想要把一張目標表遷移過來，需要把它的依賴表都先遷移過來。同時還要搞清楚依賴表用的是什么時候的數(shù)據(jù)，是當天的，還是前一天的，這是作業(yè)上的依賴。正是因為存在這樣的依賴關系，eBay采用了分層進行的自動化遷移方案，首先那些沒有依賴的表和作業(yè)，然后是一級依賴，二級依賴，以此類推。

除此之外，并不是所有的表都適合做自動化遷移。在老的數(shù)倉里面，有些表和作業(yè)并不是按照標準流程構建的，這些例外情況往往不大方便在自動化框架中做統(tǒng)一處理。這時候，就需要和相應的開發(fā)人員溝通，或者讓他們去做修改來符合標準流程，或者由他們自行手動遷移。綜上所述，eBay制定出了一個以自動化的分層遷移為主，輔之必要的手動遷移的混合遷移方案。

基于eBay的經(jīng)驗，俞育才總結出了企業(yè)在制定數(shù)據(jù)遷移方案時最需要考慮的幾點問題：

1. 軟硬件基礎設施的架構和實現(xiàn)。在硬件層，eBay采用了計算存儲分離的結構，這會直接影響到接下來的服務器選型、網(wǎng)絡拓撲及帶寬設計等。在軟件層，需要選擇合適版本的Hadoop、Hive、Spark等組件。

2. 資源容量。遷移一個30PB的Teradata集群需要規(guī)劃多大的Spark集群?在Teradata上，一般使用CPU-Seconds作為資源的度量。在開始遷移后，團隊發(fā)現(xiàn)Spark集群上的內存消耗是很大的，成為了主要瓶頸，所以使用Memory-Seconds作為主要的資源度量。根據(jù)業(yè)務的實際情況，將Teradata的CPU-Seconds換算成Spark的Memory-Seconds就可以估算出需要的集群規(guī)模。

3. 數(shù)據(jù)質量。數(shù)倉遷移不僅僅是遷過去就了事了，還需要保證作業(yè)結果的正確性。在大規(guī)模數(shù)據(jù)的情況下，這是個相當棘手的問題，有很多細節(jié)需要考慮。

4. 遷移的效率。為了加快遷移，eBay開發(fā)了很多的工具來幫助提升遷移的效率。這包括一套自動化的遷移框架，大部分的自動化遷移都是通過這個框架完成的，同時框架的各種功能會以Restful API的方式暴露出來，團隊還做了一個界面去調用這些功能，這就使得手動遷移的部分也可以盡可能高效。

5. 優(yōu)化集群。優(yōu)化對于遷移是非常重要的，因為遷移的時候集群的資源通常都很緊張，一個優(yōu)化良好的系統(tǒng)就可以在有限的資源中容納更多的作業(yè)。為此，eBay研發(fā)了兩個主要的技術來做性能的優(yōu)化。一個是Spark的自適應執(zhí)行(Adaptive Execution)，它可以動態(tài)的優(yōu)化執(zhí)行計劃;另一個是Indexed Bucket，它是對數(shù)據(jù)物理布局的優(yōu)化。這兩個優(yōu)化為eBay節(jié)省了一半的內存資源。

盡管團隊已經(jīng)預先為大型數(shù)據(jù)倉庫遷移可能會面臨的問題設計了應對方案，但在真正啟動數(shù)據(jù)倉庫遷移后，依然遇到了很多挑戰(zhàn)。俞育才給我們舉了幾個例子：

“1. 大規(guī)模數(shù)據(jù)下的正確性驗證。我們可能會直觀地認為，雙跑驗證就可以了。盡管理論上是這樣，實際情況往往會復雜很多。首先，數(shù)據(jù)源是不斷變化的，目標表依賴的任何一張源表數(shù)據(jù)發(fā)生了變化，結果就會不一致。所以，雙跑的時間點很重要。其次，即使數(shù)據(jù)源固定，跑多次結果未必是一致的。比如，在Spark中有個UDF，可以給返回每一行加上個ID。但實際上，這并不是一個冪等操作，因為Shuffle不保證每次返回行的順序，所以每次編上ID都是不一樣的。對于這樣的列，我們就不能做比較。類似這樣的問題還有很多，都需要特別注意。

2. 非標準流程作業(yè)的遷移。在老的Teradata數(shù)倉中，大約有10-15%的作業(yè)并不是按照標準流程創(chuàng)建的，這些作業(yè)無法做自動化遷移，或者自動化的成本很高。所以，在初期做規(guī)劃的時候，要盡可能收集到足夠的信息，把他們都標識出來，然后盡早地聯(lián)系相應的開發(fā)，或者修改作業(yè)，或者做手動遷移。

3. 開源軟件的企業(yè)級特性的支持。一些企業(yè)級軟件提供的易用功能，現(xiàn)在的Spark、Hadoop還沒有提供。比如：監(jiān)控和調試信息還不是很完善，排錯起來不是那么方便;對分析師來說，他們也缺乏一個好的IDE幫助他們做開發(fā)。這并不全是Spark的問題，我們自己開發(fā)了很多外圍的組件來幫助改善這些問題。”

eBay在數(shù)倉建設方面經(jīng)驗比較多，在大的方向上沒有特別多意料之外的狀況，但有些問題還是挺值得注意的。俞育才強調道：“各個系統(tǒng)雖說都支持標準SQL，但實現(xiàn)的細節(jié)上是有些差異的。比如字符集編碼，大家都支持Unicode，但實現(xiàn)的方式卻不一樣。Teradata使用的是UTF-16，Spark使用的是UTF-8，做工具的時候需要考慮到。再比如case sensitive，我們一般的理解就是列名，表名的大小寫是否敏感，但是在Teradata里面，它還支持查詢的內容是否大小寫敏感，遷移到Spark SQL以后，我們就需要做些特殊的處理。”

遷移工作90%自動化是如何做到的?

俞育才對eBay整個數(shù)據(jù)倉庫的自動遷移工作流程進行了梳理，主要包括以下10個環(huán)節(jié)。

根據(jù)自動化需求，定義和采集元數(shù)據(jù)，并對元數(shù)據(jù)進行分析。提取出遷移目標表和作業(yè)的屬性，比如表的大小、相關SQL文件及腳本的復雜程度，作業(yè)Pipeline信息，數(shù)據(jù)血緣等。

根據(jù)元數(shù)據(jù)分析結果制定整體遷移策略，劃分自動遷移的scope，并決定遷移的順序 。除非復雜度過高，默認采用自動遷移。無依賴關系的表先進行遷移，上游表遷移完成后才開始下游表的遷移。

創(chuàng)建目標表及所需中間表。

準備靜態(tài)測試數(shù)據(jù)，包括目標表的前一天數(shù)據(jù)、當天增量數(shù)據(jù)和當天數(shù)據(jù)。比對動態(tài)數(shù)據(jù)是相當麻煩的，靜態(tài)數(shù)據(jù)則方便得多。

把 Teradata SQL 翻譯成Spark SQL。基本思想是將Teradata SQL語句解析成邏輯計劃，再將邏輯計劃反向轉換為Spark SQL的語句。

結合表的大小等屬性以及Spark集群的參數(shù)特征，生成優(yōu)化的Spark作業(yè)配置參數(shù)。

將原始包含Teradata SQL的pipeline轉換成調用Spark SQL的pipeline。

啟動pipeline進行集成測試，驗證各個作業(yè)和整個pipeline的正確性。

部署到生產(chǎn)環(huán)境。包括代碼發(fā)布、表的建立、歷史數(shù)據(jù)初始化、pipeline上線和定時調度、以及在生產(chǎn)環(huán)境的測試。

在連續(xù)多天數(shù)據(jù)比對通過后(默認7天)發(fā)送通知給到表的負責人開始準備交接工作 ，即正式將Teradata的pipeline停止而采用Spark的pipeline。

上面中提到的第1到第8步均已實現(xiàn)自動化，第9、10步由于涉及到生產(chǎn)環(huán)境，根據(jù)流程管理的需要，由相關同事半自動化地完成。

俞育才表示，實現(xiàn)自動化難度最大的環(huán)節(jié)是對元數(shù)據(jù)的抽象和定義。“因為自動化遷移項目的時間線非常緊張，一些數(shù)據(jù)轉換的模式我們一開始沒有考慮到，相應的元數(shù)據(jù)就沒有收集，這會給后期的自動化帶來不小的麻煩。另外從技術上看，自動化SQL翻譯工具，依賴分析工具也是比較復雜的部分。”

對應上面說的每個步驟，eBay都有相應的自動化工具：Metadata Analyzer，Table Creator，Data Mover，SQL Converter，Spark SQL Optimizer，Pipeline Generator， Data Validator等等。這些工具基本都是eBay大數(shù)據(jù)團隊自研的，其中還包括一個基于Zeppelin的集成開發(fā)環(huán)境Dev Suite。

使用eBay自己開發(fā)的工具，最終數(shù)據(jù)倉庫遷移過程中90%的工作都由自動化完成了，數(shù)倉遷移原來預計需要的1000個人月銳減到了250個人月。

人工參與的部分主要包括：自動化工具的開發(fā)和維護;非標準化流程作業(yè)的遷移;無法自動裝換的Teradata功能，例如Recursive Query;數(shù)據(jù)模型和pipeline的重構;性能的調優(yōu)與優(yōu)化。

當然，如此高的自動化完成率自然也給大數(shù)據(jù)工程師帶來了與以往不同的挑戰(zhàn)。傳統(tǒng)的手動遷移任務，一般的數(shù)據(jù)工程師就可以完成，而自動化遷移會需要我們的工程師不僅僅對數(shù)據(jù)熟悉，還要具備軟件開發(fā)的能力。

俞育才表示，未來完全自動化意義不是特別大，因為有一些特殊場景出現(xiàn)的頻率不是很多，為它們做專門自動化就不是很有必要。

對于正如火如荼發(fā)展中的企業(yè)來說，如何保證數(shù)據(jù)倉庫遷移過程中線上運行的業(yè)務不受影響?俞育才也給出了eBay經(jīng)過實踐得到的經(jīng)驗：

首先，環(huán)境隔離。eBay的Spark環(huán)境和Teradata環(huán)境是完全隔離的，正在使用的Teradata不會受到影響。

其次，嚴格的數(shù)據(jù)比對。新的任務使能以后會和Teradata有一個長達七天的雙跑驗證。

最后，灰度上線。任務切換到Spark的pipeline后設置一個觀察期，如果發(fā)現(xiàn)有問題，可以立馬切換回Teradata的pipeline。

結語

經(jīng)過一年的努力，第一期約30PB的數(shù)倉遷移已經(jīng)基本完成。接下來，一方面，俞育才所在的大數(shù)據(jù)團隊將會將工作重心放在對Spark的改進和優(yōu)化上，例如更好地支持Teradata的語法和特性、自適應執(zhí)行、緩存、交互式查詢等;另一方面，他們也將繼續(xù)推動eBay的現(xiàn)代化數(shù)倉建設，使之更加實時化、智能化。

采訪嘉賓

俞育才， eBay大數(shù)據(jù)架構師，負責Spark數(shù)據(jù)平臺的設計與優(yōu)化。12年軟件開發(fā)經(jīng)驗，Apache Spark的活躍開發(fā)者，熟悉系統(tǒng)軟件的性能分析與調優(yōu)，基于Spark設計和實現(xiàn)了自適應執(zhí)行引擎和層次化存儲。在加入eBay之前，俞育才在英特爾工作了9年，領導團隊研究各種前沿的硬件技術加速云和大數(shù)據(jù)計算。

來源：InfoQ

標簽： 大數(shù)據(jù) 大數(shù)據(jù)架構 代碼 服務器 腳本 開發(fā)者 數(shù)據(jù)分析 網(wǎng)絡

版權申明：本站文章部分自網(wǎng)絡，如有侵權，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉載文章言論不代表本站觀點！
本站所提供的圖片等素材，版權歸原作者所有，如需使用，請與原作者聯(lián)系。