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

　　

　　為什么決定遷移？

　　俞育才表示，隨著業務的發展，原有的模式體現出了一些不方便的地方，這些問題促使eBay開始嘗試數據倉庫遷移的工作。

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

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

　　另外，eBay還可以基于開源軟件對成本和性能做極致的優化。早在2014年的時候，eBay就開始嘗試使用開源軟件。剛開始，開源軟件的成本也是很高的。隨著持續地優化，成本下降得很快。到2021年，開源軟件的開銷已經和供應商的專有軟件差不多了。按照這個趨勢，明年的開源系統的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年，領導團隊研究各種前沿的硬件技術加速云和大數據計算。（作者：蔡芳芳）成都加米谷大數據培訓機構，專注于大數據人才培養。

總結

以上是生活随笔為你收集整理的1年将30PB数据迁移到Spark，eBay的经验有何可借鉴之处？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。