E-MapReduce：從自建StarRocks叢集向Serverless StarRocks的遷移方案

遷移流程

整體遷移流程如下圖所示，涵蓋了作業改寫、作業雙跑、資料校正、業務校正以及割接等多個步驟。

前期評估

確認當前叢集情況

請確認當前叢集的基本情況，包括叢集的版本，FE規格和數量，BE規格和數量，以及負載等資訊。

確認業務使用方式

• 資料匯入方式

  資料匯入方式	資料寫入分類	每日資料增量	每日新行數	任務數
  即時寫入（Flink）	即時資料	10 GB	1 億行	80
  Kafka + Routine	即時資料	10 GB	1 億行	20
  離線匯入（Spark Connector、DataX）	離線資料	10 GB	1 億行	120

• 物化視圖使用方式

  物化視圖	任務數	同步頻率
  同步物化視圖	12個	無
  非同步物化視圖	89個	大部分為每小時更新
  Insert Overwrite	120個	大部分為每半小時更新

• 確認業務能夠接受的停服時間

  為了確保商務持續性，必須提前評估業務能夠接受的停服時間。整個遷移的停服時間取決於具體方案，通常在30分鐘至半天左右不等。因此，務必提前與業務方進行充分溝通，明確預期停服時間。

建立目的地組群

根據您的業務需求，選擇適當的執行個體類型建立Serverless StarRocks執行個體。您也可以通過DingTalk群24010016636聯絡我們進行評估。參考文檔如下：

• 快速使用存算一體版執行個體

• 快速使用存算分離版執行個體

資料移轉

1、安裝遷移工具

該工具基於兩個叢集的中繼資料以及檔案中繼資料對比，會定期將源叢集的中繼資料以及資料增量同步處理到目的地組群中。它作為遷移過程的一環，主要解決存量資料同步，中繼資料同步以及離線部分增量資料更新。

• 遷移工具的使用限制、安裝、使用等資訊，請參見StarRocks跨叢集資料移轉工具。

• 遷移工具速率說明：

  • 參考經驗值：約1 TB/小時。

  • 具體遷移速率受以下因素影響：同步的庫表數量、表資料量、表分區數量以及桶的數量。對於單表來說，tablet數量越多，遷移速率會越慢。

  • 遠距離跨地區或跨VPC的遷移速率主要受網路穩定性影響。遷移過程中需要在兩個叢集之間建立大量串連，若網路不穩定或速率較慢，遷移速率也會受到顯著影響。

• 遷移工具測試：在完成安裝並正確配置了源叢集與目的地組群的詳細資料後，進行工具的功能驗證，確保其能夠順暢運作。

2、表結構&存量資料同步

通過上述遷移工具可以實現表結構以及存量資料的同步。您可以參考遷移工具的速率，同時結合實際測試情況來合理評估同步時間。通過配置遷移工具的以下2個參數，可以合理控制期望同步的表和資料的範圍。

3、即時任務遷移

如果您正在執行Flink或Kafka的即時寫入任務，建議進行雙寫配置，以便同時將資料寫入目的地組群和源叢集，從而確保資料一致性。

• 停止遷移工具：首先，停止當前的遷移工具，並調整配置，以排除對正在即時更新的表資料的同步。可通過exclude_data_list參數進行控制。

• Flink作業：在Flink作業的平台上，複製現有任務，並修改資料來源配置，指向目的地組群。

• Stream Load作業：在目的地組群中手動建立相應的Stream Load作業，以實現對Kafka資料的雙寫同步。

4、離線任務遷移

• 離線任務啟動：去掉即時更新的相關表後，繼續啟動離線任務，保持對離線更新資料的持續同步。

• 離線任務複製：複製離線任務實現對目的地組群的更新，但在割接階段之前暫時不啟動相關任務。

5、（可選）物化視圖遷移

請參考以下社區命令，以擷取相關的物化視圖或普通視圖的定義。然後，在目的地組群中逐個建立相應的視圖。

• SHOW CREATE MATERIALIZED VIEW

• SHOW CREATE VIEW

6、（可選）外表遷移

3.x及之後版本，建議使用Catalog對StarRocks的外表進行統一管理。更多Catalog資訊，請參見StarRocks Overview。

如果需要擷取源表的DDL，可以通過SHOW CREATE TABLE命令，但不推薦在新叢集中採用這種方式進行外表管理，建議優先使用Catalog。

根據您的具體需求，選擇合適的方法在目的地組群中建立外表，並測試外表功能是否正常。

7、（可選）UDF遷移

請參考SHOW FUNCTIONS命令，擷取相關FUNCTION內容，並在目的地組群中逐個建立相應的UDF。

資料校正

1、資料一致性校正

資料一致性校正主要目的是驗證同步資料的準確性，通過對源表與目的地組群進行比較。可以從以下幾個維度進行檢查：

• 庫或表數量對比

• 表記錄數對比

• 每行記錄的匯總或去重計數對比

2、下遊業務校正

下遊業務校正主要從業務角度出發，對結果進行驗證，以確保源表、物化視圖及其他預先處理資料的正確性。具體校正方式如下：

• 有下遊測試系統：可切換資料來源至目的地組群，從業務角度對查詢結果和報表資料進行驗證。

• 無下遊測試系統，可採取以下兩種方法：

  • 業務SQL複現：手動挑選關鍵業務SQL，執行查詢並比對結果，以進行校正。

  • 生產環境驗證：利用業務系統進行驗證，此過程需與業務方提前協商，驗證完成後應儘快切換回源叢集。

3、效能驗證

效能驗證的關鍵在於複現實際生產業務的各種壓力，包括資料匯入、業務查詢以及物化視圖的處理。同時，必須確保即時資料的雙跑、離線任務的同步處理以及物化視圖的正常運行，以類比真實的生產環境。以下是需要驗證的要點：

• 叢集負載：確保CPU、記憶體、磁碟IO、IOPS及磁碟利用率等各項指標均在預期範圍內。

• 業務查詢：驗證業務查詢的回應時間，確保其在業務需求的合理範圍內。

• 資料匯入：檢查資料匯入的延遲情況，確保其在業務需求的合理範圍內。

業務割接

1、確認停服時間

由於業務割接將導致短暫停服，我們需要提前評估停服時間，並與業務方確認。建議在業務低峰期進行停服，以最小化對業務的影響。

通常情況下，割接的停機時間主要集中在第五步（即業務系統切換至目的地組群）。此步驟預計耗時較短，預計30分鐘至1小時。具體時間會根據專案情況進行實際評估。

2、終止源叢集的離線資料同步

為確保割接時目的地組群能夠追平源叢集的資料，請在割接前停止離線同步任務。這意味著需要選擇適當的更新間隔期，並停止新資料的寫入，確保源叢集不再增加新的離線資料。

3、遷移工具持續同步，直至追平源叢集

遷移工具將保持即時同步狀態，直至與源叢集資料完全一致。

4、離線同步任務寫入目的地組群

在之前的遷移步驟中，已配置好離線任務寫入目的地組群。本步驟僅需啟動這些任務，並觀察其運行情況，重點校正：

• 同步任務是否正常運行。

• 目的地組群的資料是否正常更新。

5、業務系統切換為目的地組群

將下遊使用StarRocks的業務系統資料來源配置切換為目的地組群的配置，並驗證業務系統的查詢功能，確保查詢耗時符合預期。

6、割接驗證

割接後，對業務系統進行驗證，主要從下遊進行檢驗，驗證項包括：

• 業務系統查詢結果是否正確。

• 業務系統查詢耗時是否符合預期。

如驗證中發現問題，請參考復原方案。

7、終止即時雙跑任務

驗證通過後，可以停止源叢集的即時寫入任務，正式完成割接。

復原方案

如果割接後驗證存在問題，請首先聯絡阿里雲EMR團隊協同解決相關問題。如果問題無法解決，再考慮復原方案。復原流程如下：

1. 保持即時任務雙跑，避免執行資料校正階段的第7步操作（即終止即時雙跑任務）。

2. 將業務系統切換回源叢集地址，驗證業務系統是否正常運行。

3. 從上次停止的周期開始，恢複離線任務對源叢集的寫入。

4. 停止向目的地組群寫入離線資料。

常見問題