Arrow列存格式高效能同步
DataWorks Data Integration支援使用 Apache Arrow 列存格式實現跨資料來源的高效能資料同步。該方案通過記憶體直通與零拷貝技術，將行式傳輸升級為列式傳輸，提升巨量資料量情境下的同步輸送量。根據測試情境，效能最高可提升近10倍。
業務情境說明
在處理海量資料時，基於行存的資料同步方案常因頻繁的序列化、還原序列化及類型轉換而出現效能瓶頸。尤其在資料倉儲遷移（例如從 Hive 遷移至 MaxCompute）或構建湖倉一體架構時，TB 級資料的同步耗時過長，會影響業務上線和資料分析效率。此方案用於解決大規模列存資料來源之間的資料流轉效率問題，可將同步耗時從小時級縮短至分鐘級。
情境一：巨量資料搬站遷移
痛點：從Hive向MaxCompute遷移數百TB資料，耗時較久，影響業務上線。
方案：啟用Arrow同步，列存直傳，避免格式轉換。
成果：遷移時間從小時級同步縮短至分鐘級，效率提升10倍以上。
情境二：異構資料來源融合與湖倉一體化
讓資料在湖（如Hive生態）與倉（Hologres/MaxCompute）之間自由、高效地流轉。核心價值：一數多用，湖倉協同。
方案架構
DataWorks Data Integration通過引入 Apache Arrow 列式記憶體標準，重構了資料在 Reader 和 Writer 之間的傳輸方式，實現了從行式處理到列式直通的轉變。
傳統行存同步架構
在傳統架構中，資料以行為單位進行處理。即使源和目標均為列存格式（如 Parquet 或 ORC），資料在同步作業引擎內部也會被轉換為通用的行式 Record 對象。面向單行行存的格式設計，每一個Record對象定義了若干個Column，每個Column包含當前行對應該列的列值Value。以MaxCompute(ODPS)列存資料同步到MaxCompute(ODPS)列存為例：
此流程包含以下步驟，並會產生以下效能開銷：
Reader 解碼：Reader 從源端（如 MaxCompute）讀取列存資料，將其解碼並逐行轉換為架構內部的
Record對象。架構傳輸：架構在記憶體隊列中傳輸大量的
Record對象。Writer 編碼：Writer 從架構擷取
Record對象，再將其編碼為目標端所需的列存格式後寫入。
這一過程涉及多次資料格式轉換、序列化/還原序列化以及高頻的對象建立，導致較高的 CPU 和記憶體資源消耗，並引發頻繁的記憶體回收（GC），限制了整體吞吐。
Arrow 列存同步架構
基於 Arrow 的新架構實現了端到端的列式資料流。資料在整個同步鏈路中保持其列存格式，避免了行式轉換的開銷。
通過引入 ArrowTabularRecord 資料結構，同步流程被最佳化為：
Reader 直讀：Reader通過 MaxCompute Tunnel Arrow API直接讀取源端的列存資料，並將其封裝為
ArrowTabularRecord批量投遞給架構。架構傳輸：架構直接傳遞包含二進位列資料的
ArrowTabularRecord。Writer 直寫：Writer通過 Tunnel Arrow API直接從
ArrowTabularRecord中擷取 Arrow 格式的位元據，通過零拷貝技術將其傳輸至目標端（如 Tunnel Server），無需再次序列化。
該架構通過對Arrow的原生支援，消除了中間的行式轉換環節，實現端到端列存“短路同步”，大幅提升輸送量、降低延遲。
實施步驟
在 DataWorks Data Integration任務中添加特定參數可啟用 Arrow 高效能同步。目前支援源端與目標端為 MaxCompute、Hologres、Hive/OSS/HDFS（Parquet/ORC） 這幾種類型的整庫離線同步和單表離線同步。
方式一：整庫離線同步
使用Data Integration提供的整庫離線同步任務功能（例如 Hive 到 MaxCompute 的離線整庫），系統會根據源和目標表的欄位類型自動判斷並啟用 Arrow 高效能同步，無需手動設定。支援在任務編輯介面右上方的中查看。
在運行時配置中，找到是否開啟Arrow短路傳輸參數，可選值包括自動渲染（預設）、強制開啟和強制關閉。
方式二：單表離線同步
在配置 單表離線同步 任務時，通過指令碼模式配置可在 Reader 和 Writer 的 parameter 配置中都添加 "useArrow":true 來手動啟用。
配置前提：啟用此功能要求源端與目標端表的列類型定義保持一致。因為該模式會跳過類型轉換環節，直接進行記憶體資料轉送。
以下是一個從 Hive (Reader) 同步到 MaxCompute (Writer) 的樣本配置：
{
"type": "job",
"steps": [
{
"stepType": "hive",
"parameter": {
"useArrow": true,
"datasource": "my_datasource",
"column": [
"col1",
"col2"
],
"readMode": "hdfs",
"table": "table"
},
"name": "Reader",
"category": "reader"
},
{
"stepType": "odps",
"parameter": {
"useArrow": true,
"truncate": false,
"datasource": "odps_test",
"column": [
"col1",
"col2"
],
"table": "table"
},
"name": "Writer",
"category": "writer"
}
],
"setting": {
"speed": {
"concurrent": 3
}
}
}效能驗證
以下是部分資料來源的效能提升比例。效能驗證的測試條件如下：
壓測條件：伺服器規格：64C 256GB，網卡：2.5萬兆網卡。
測試資料量：42045700 條資料。
資料來源 | 支援能力 | 同步效能提升 |
MaxCompute | 通過Tunnel Arrow API直讀列存資料 | 同步效能提升 200% |
Hologres | 支援Arrow格式匯出，避免JDBC行式瓶頸 | 同步效能提升 95% |
Hive\OSS\HDFS等分布式檔案 | 直接讀取Parquet/ORC底層Arrow格式資料 | PARQUET同步效能提升5.55倍ORC同步效能提升 9.85倍 |
情境一：MaxCompute列存短路同步（Arrow → Arrow）
並發數 | 傳統行存 | Arrow列存 | 效能提升 |
1 | 67.8 MB/s 3740 R/s | 212.6 MB/s 11462 R/s | +206.5% |
3 | 185.6 MB/s 10226 R/s | 569.9 MB/s 30728 R/s | +200.5% |
8 | 462.1 MB/s 25467 R/s | 1321.0 MB/s 71143 R/s | +197.4% |
情境二：Hologres → MaxCompute 同步
並發數 | 傳統同步 | Arrow同步 | 效能提升 |
4 | 439.1 MB/s 216480 R/s | 906.1 MB/s 404270 R/s | +87% |
8 | 773.3 MB/s 381300 R/s | 1669.1 MB/s 745654 R/s | +95% |
情境三：Parquet/ORC → MaxCompute 同步
列存格式 | 傳統同步 | Arrow同步 | 效能提升 |
Parquet | 26.1 MB/s 35631 R/s | 1198.1 MB/s 233587 R/s | 5.55倍 |
ORC | 21.4 MB/s 27661 R/s | 3256.3 MB/s 300326 R/s | 9.85倍 |
Parquet、ORC為HDFS、OSS等Distributed File System中的列存格式。