1年將30PB資料遷移到Spark，eBay的經驗有何可借鑑之處？
Teradata在過去的二十年為eBay提供了非常優秀的數倉服務，支撐起了eBay龐大的業務規模。二十多年積累下來的資料已經將資料倉庫變得非常龐大，所謂“牽一髮而動全身”，哪怕只是微小的改動也會牽涉大量資料和業務邏輯，更何況是資料倉庫遷移這樣的大動作。
為什麼決定遷移？
俞育才表示，隨著業務的發展，原有的模式體現出了一些不方便的地方，這些問題促使eBay開始嘗試資料倉庫遷移的工作。
首先，技術上不夠靈活。eBay有很多自己特有的場景，供應商的軟體很難為此去定製，或者需要eBay去適應供應商的路線圖，這存在很大的侷限性。如果使用開源軟體，可以主動地參與開發，為自己的需求做深度的定製，更好地滿足業務的發展。
其次，通過開源軟體可以大大擴充套件數倉的能力。傳統的數倉就是做批處理，但是現代的數倉是個很寬泛的概念。除了批處理，eBay還需要處理實時資料、做圖計算、做機器學習。不可能要求Teradata來提供這麼多的功能。
另外，eBay還可以基於開源軟體對成本和效能做極致的優化。早在2014年的時候，eBay就開始嘗試使用開源軟體。剛開始，開源軟體的成本也是很高的。隨著持續地優化，成本下降得很快。到2018年，開源軟體的開銷已經和供應商的專有軟體差不多了。按照這個趨勢，明年的開源系統的TCO甚至可以超過專有軟體。”
最後，從公司的角度講，也希望有更加多樣化多元化的投資。
Spark是新資料倉庫的最優選擇
下定了遷移的決心，下一步就要開始技術選型工作了，市面上開源的大資料框架、資料倉庫那麼多，eBay最終選擇了Spark。
問及箇中緣由，俞育才表示：“我們想要打造一個真正的現代化數倉，除了支援超大規模資料處理，還要能夠支援實時化和智慧化。Spark提供了一站式資料處理的能力，不僅可以做傳統的批處理，還可以做流處理、圖計算和機器學習，這非常符合我們的期望，也是其他系統所不具備的。其次，Spark的效能非常好。這得益於它強大的記憶體計算能力，以及Catalyst、Tungsten帶來的諸多優化。另外，Spark的社群很強大。Spark是Github上最活躍的大資料框架之一，各種問題都可以得到很快的反饋。最後，在相容性方面， Spark對SQL有非常好的支援，使得我們的分析師可以很方便地遷移到Spark上。隨著2.0的釋出，Spark已經日趨成熟，我們認為在這個時間點做遷移是個非常正確的選擇。”
技術選型方面，eBay做了很多嘗試。一開始嘗試的是MapReduce和Cascading，但它們的開發週期太長了。而且分析師的強項並不是程式設計，他們需要花費很大的精力去學習怎麼開發一個好的作業。接下來，團隊又嘗試了Hive。但是Hive的效能不是非常好，一些案例並沒能跑出來，並且Hive也不支援流和機器學習。Presto在資料量不大的情況下，是可以做記憶體計算的，效能也很不錯，但是大查詢可能會直接失敗，因為它是為互動式查詢設計的，容錯並不是第一考慮。
綜合以上這些，Spark幾乎是一個不二選擇。在做原型的時候，eBay大資料團隊找了一些非常核心也相對比較重的作業，用Spark去跑，發現不僅僅是跑下來了，而且調優之後，效能成本都還不錯，這給了整個團隊很大的信心。
需要1000個人月的資料遷移如何從不可能變為可能？
資料倉庫的遷移主要包含兩方面工作，一個是表的遷移，另一個是作業的遷移。
eBay第一期遷移的數倉就有30PB之大，包括5000張的目標表、20000張的臨時表和50000個作業。經過估算，如果是手動遷移，大概需要1000個人月，相當於50個數據工程師，專職做遷移也需要兩年 ，這是非常大的開銷。所以必須做自動化遷移 。
另一方面，表和作業之間是有依賴關係的。比如，想要把一張目標表遷移過來，需要把它的依賴表都先遷移過來。同時還要搞清楚依賴表用的是什麼時候的資料，是當天的，還是前一天的，這是作業上的依賴。正是因為存在這樣的依賴關係，eBay採用了分層進行的自動化遷移方案，首先那些沒有依賴的表和作業，然後是一級依賴，二級依賴，以此類推。
除此之外，並不是所有的表都適合做自動化遷移。在老的數倉裡面，有些表和作業並不是按照標準流程構建的，這些例外情況往往不大方便在自動化框架中做統一處理。這時候，就需要和相應的開發人員溝通，或者讓他們去做修改來符合標準流程，或者由他們自行手動遷移。綜上所述，eBay制定出了一個以自動化的分層遷移為主，輔之必要的手動遷移的混合遷移方案 。
基於eBay的經驗，俞育才總結出了企業在制定資料遷移方案時最需要考慮的幾點問題：
1.軟硬體基礎設施的架構和實現。 在硬體層，eBay採用了計算儲存分離的結構，這會直接影響到接下來的伺服器選型、網路拓撲及頻寬設計等。在軟體層，需要選擇合適版本的Hadoop、Hive、Spark等元件。
2.資源容量。 遷移一個30PB的Teradata叢集需要規劃多大的Spark叢集？在Teradata上，一般使用CPU-Seconds作為資源的度量。在開始遷移後，團隊發現Spark叢集上的記憶體消耗是很大的，成為了主要瓶頸，所以使用Memory-Seconds作為主要的資源度量。根據業務的實際情況，將Teradata的CPU-Seconds換算成Spark的Memory-Seconds就可以估算出需要的叢集規模。
3. 資料質量。 數倉遷移不僅僅是遷過去就了事了，還需要保證作業結果的正確性。在大規模資料的情況下，這是個相當棘手的問題，有很多細節需要考慮。
4.遷移的效率。 為了加快遷移，eBay開發了很多的工具來幫助提升遷移的效率。這包括一套自動化的遷移框架，大部分的自動化遷移都是通過這個框架完成的，同時框架的各種功能會以Restful API的方式暴露出來，團隊還做了一個介面去呼叫這些功能，這就使得手動遷移的部分也可以儘可能高效。
5.優化叢集。 優化對於遷移是非常重要的，因為遷移的時候叢集的資源通常都很緊張，一個優化良好的系統就可以在有限的資源中容納更多的作業。為此，eBay研發了兩個主要的技術來做效能的優化。一個是Spark的自適應執行（Adaptive Execution），它可以動態的優化執行計劃；另一個是Indexed Bucket，它是對資料物理佈局的優化。這兩個優化為eBay節省了一半的記憶體資源。
儘管團隊已經預先為大型資料倉庫遷移可能會面臨的問題設計了應對方案，但在真正啟動資料倉庫遷移後，依然遇到了很多挑戰。俞育才給我們舉了幾個例子：
“1. 大規模資料下的正確性驗證。我們可能會直觀地認為，雙跑驗證就可以了。儘管理論上是這樣，實際情況往往會複雜很多。首先，資料來源是不斷變化的，目標表依賴的任何一張源表資料發生了變化，結果就會不一致。所以，雙跑的時間點很重要。其次，即使資料來源固定，跑多次結果未必是一致的。比如，在Spark中有個UDF，可以給返回每一行加上個ID。但實際上，這並不是一個冪等操作，因為Shuffle不保證每次返回行的順序，所以每次編上ID都是不一樣的。對於這樣的列，我們就不能做比較。類似這樣的問題還有很多，都需要特別注意。
2. 非標準流程作業的遷移。在老的Teradata數倉中，大約有10-15%的作業並不是按照標準流程建立的，這些作業無法做自動化遷移，或者自動化的成本很高。所以，在初期做規劃的時候，要儘可能收集到足夠的資訊，把他們都標識出來，然後儘早地聯絡相應的開發，或者修改作業，或者做手動遷移。
3. 開源軟體的企業級特性的支援。一些企業級軟體提供的易用功能，現在的Spark、Hadoop還沒有提供。比如：監控和除錯資訊還不是很完善，排錯起來不是那麼方便；對分析師來說，他們也缺乏一個好的IDE幫助他們做開發。這並不全是Spark的問題，我們自己開發了很多外圍的元件來幫助改善這些問題。”
eBay在數倉建設方面經驗比較多，在大的方向上沒有特別多意料之外的狀況，但有些問題還是挺值得注意的。俞育才強調道：“各個系統雖說都支援標準SQL，但實現的細節上是有些差異的。比如字符集編碼，大家都支援Unicode，但實現的方式卻不一樣。Teradata使用的是UTF-16，Spark使用的是UTF-8，做工具的時候需要考慮到。再比如case sensitive，我們一般的理解就是列名，表名的大小寫是否敏感，但是在Teradata裡面，它還支援查詢的內容是否大小寫敏感，遷移到Spark SQL以後，我們就需要做些特殊的處理。”
遷移工作90%自動化是如何做到的？
俞育才對eBay整個資料倉庫的自動遷移工作流程進行了梳理，主要包括以下10個環節。
- 根據自動化需求，定義和採集元資料，並對元資料進行分析。 提取出遷移目標表和作業的屬性，比如表的大小、相關SQL檔案及指令碼的複雜程度，作業Pipeline資訊，資料血緣等。
- 根據元資料分析結果制定整體遷移策略，劃分自動遷移的scope，並決定遷移的順序 。 除非複雜度過高，預設採用自動遷移。無依賴關係的表先進行遷移，上游表遷移完成後才開始下游表的遷移。
- 建立目標表及所需中間表。
- 準備靜態測試資料 ，包括目標表的前一天資料、當天增量資料和當天資料。比對動態資料是相當麻煩的，靜態資料則方便得多。
- 把 Teradata SQL 翻譯成Spark SQL。 基本思想是將Teradata SQL語句解析成邏輯計劃，再將邏輯計劃反向轉換為Spark SQL的語句。
- 結合表的大小等屬性以及Spark叢集的引數特徵，生成優化的Spark作業配置引數 。
- 將原始包含Teradata SQL的pipeline轉換成呼叫Spark SQL的pipeline 。
- 啟動pipeline進行整合測試 ，驗證各個作業和整個pipeline的正確性。
- 部署到生產環境 。包括程式碼釋出、表的建立、歷史資料初始化、pipeline上線和定時排程、以及在生產環境的測試。
- 在連續多天資料比對通過後（預設7天）傳送通知給到表的負責人開始準備交接工作 ，即正式將Teradata的pipeline停止而採用Spark的pipeline 。
上面中提到的第1到第8步均已實現自動化，第9、10步由於涉及到生產環境，根據流程管理的需要，由相關同事半自動化地完成。
俞育才表示，實現自動化難度最大的環節是對元資料的抽象和定義 。“因為自動化遷移專案的時間線非常緊張，一些資料轉換的模式我們一開始沒有考慮到，相應的元資料就沒有收集，這會給後期的自動化帶來不小的麻煩。另外從技術上看，自動化SQL翻譯工具，依賴分析工具也是比較複雜的部分。”
對應上面說的每個步驟，eBay都有相應的自動化工具：Metadata Analyzer，Table Creator，Data Mover，SQL Converter，Spark SQL Optimizer，Pipeline Generator， Data Validator等等。這些工具基本都是eBay大資料團隊自研的，其中還包括一個基於Zeppelin的整合開發環境Dev Suite。
使用eBay自己開發的工具，最終資料倉庫遷移過程中90%的工作都由自動化完成了，數倉遷移原來預計需要的1000個人月銳減到了250個人月。
人工參與的部分主要包括：自動化工具的開發和維護；非標準化流程作業的遷移；無法自動裝換的Teradata功能，例如Recursive Query；資料模型和pipeline的重構；效能的調優與優化。
當然，如此高的自動化完成率自然也給大資料工程師帶來了與以往不同的挑戰。傳統的手動遷移任務，一般的資料工程師就可以完成，而自動化遷移會需要我們的工程師不僅僅對資料熟悉，還要具備軟體開發的能力。
俞育才表示，未來完全自動化意義不是特別大，因為有一些特殊場景出現的頻率不是很多，為它們做專門自動化就不是很有必要。
對於正如火如荼發展中的企業來說，如何保證資料倉庫遷移過程中線上執行的業務不受影響？俞育才也給出了eBay經過實踐得到的經驗：
- 首先，環境隔離。eBay的Spark環境和Teradata環境是完全隔離的，正在使用的Teradata不會受到影響。
- 其次，嚴格的資料比對。新的任務使能以後會和Teradata有一個長達七天的雙跑驗證。
- 最後，灰度上線。任務切換到Spark的pipeline後設置一個觀察期，如果發現有問題，可以立馬切換回Teradata的pipeline。
結語
經過一年的努力，第一期約30PB的數倉遷移已經基本完成。接下來，一方面，俞育才所在的大資料團隊將會將工作重心放在對Spark的改進和優化上，例如更好地支援Teradata的語法和特性、自適應執行、快取、互動式查詢等；另一方面，他們也將繼續推動eBay的現代化數倉建設，使之更加實時化、智慧化。
採訪嘉賓
俞育才， eBay大資料架構師，負責Spark資料平臺的設計與優化。12年軟體開發經驗，Apache Spark的活躍開發者，熟悉系統軟體的效能分析與調優，基於Spark設計和實現了自適應執行引擎和層次化儲存。在加入eBay之前，俞育才在英特爾工作了9年，領導團隊研究各種前沿的硬體技術加速雲和大資料計算。