採訪 & 撰稿｜Natalie

嘉賓｜俞育才

出處丨AI 前線

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

正所謂“數據遷移無小事”，是什麼痛點促使 eBay 決定要啟動數據倉庫遷移這項工作？eBay 在數據倉庫遷移的過程中做了哪些嘗試？又得到了哪些經驗和教訓？為了進一步瞭解 eBay 將數據倉庫從 Teradata 遷移到 Spark 過程中的實踐和經驗，InfoQ 與 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 節省了一半的內存資源。

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

• “大規模數據下的正確性驗證。我們可能會直觀地認為，雙跑驗證就可以了。儘管理論上是這樣，實際情況往往會複雜很多。首先，數據源是不斷變化的，目標表依賴的任何一張源表數據發生了變化，結果就會不一致。所以，雙跑的時間點很重要。其次，即使數據源固定，跑多次結果未必是一致的。比如，在 Spark 中有個 UDF，可以給返回每一行加上個 ID。但實際上，這並不是一個冪等操作，因為 Shuffle 不保證每次返回行的順序，所以每次編上 ID 都是不一樣的。對於這樣的列，我們就不能做比較。類似這樣的問題還有很多，都需要特別注意。
• 非標準流程作業的遷移。在老的 Teradata 數倉中，大約有 10-15% 的作業並不是按照標準流程創建的，這些作業無法做自動化遷移，或者自動化的成本很高。所以，在初期做規劃的時候，要儘可能收集到足夠的信息，把他們都標識出來，然後儘早地聯繫相應的開發，或者修改作業，或者做手動遷移。
• 開源軟件的企業級特性的支持。一些企業級軟件提供的易用功能，現在的 Spark、Hadoop 還沒有提供。比如：監控和調試信息還不是很完善，排錯起來不是那麼方便；對分析師來說，他們也缺乏一個好的 IDE 幫助他們做開發。這並不全是 Spark 的問題，我們自己開發了很多外圍的組件來幫助改善這些問題。

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

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

俞育才對 eBay 整個數據倉庫的自動遷移工作流程進行了梳理，主要包括以下 10 個環節。

1. 根據自動化需求，定義和採集元數據，並對元數據進行分析。提取出遷移目標表和作業的屬性，比如表的大小、相關 SQL 文件及腳本的複雜程度，作業 Pipeline 信息，數據血緣等。
2. 根據元數據分析結果制定整體遷移策略，劃分自動遷移的 scope，並決定遷移的順序 。
   除非複雜度過高，默認採用自動遷移。無依賴關係的表先進行遷移，上游表遷移完成後才開始下游表的遷移。
3. 創建目標表及所需中間表。
4. 準備靜態測試數據，包括目標表的前一天數據、當天增量數據和當天數據。比對動態數據是相當麻煩的，靜態數據則方便得多。
5. 把 Teradata SQL 翻譯成 Spark SQL。基本思想是將 Teradata SQL 語句解析成邏輯計劃，再將邏輯計劃反向轉換為 Spark SQL 的語句。
6. 結合表的大小等屬性以及 Spark 集群的參數特徵，生成優化的 Spark 作業配置參數。
7. 將原始包含 Teradata SQL 的 pipeline 轉換成調用 Spark SQL 的 pipeline。
8. 啟動 pipeline 進行集成測試，驗證各個作業和整個 pipeline 的正確性。
9. 部署到生產環境
   。包括代碼發佈、表的建立、歷史數據初始化、pipeline 上線和定時調度、以及在生產環境的測試。
10. 在連續多天數據比對通過後（默認 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 年，領導團隊研究各種前沿的硬件技術加速雲和大數據計算。

閱讀更多 InfoQ 的文章

關鍵字: 軟件 前線 開源軟件