數據導入性能優化
云原生數據倉庫 AnalyticDB MySQL 版提供的多種數據導入方法，滿足不同場景下的數據導入需求。然而數據導入性能依然受各種各樣的因素影響，如表的建模不合理導致長尾、導入配置低無法有效利用資源等。本文介紹不同場景下的數據導入調優方法。
通用外表導入數據調優
檢查分布鍵
分布鍵決定著數據導入的一級分區，每個表在導入時以一級分區為粒度并發導入。當數據分布不均勻時，導入數據較多的一級分區將成為長尾節點，影響整個導入任務的性能，因此要求導入時數據均勻分布。如何選擇分布鍵，請參見選擇分布鍵。
判斷分布鍵合理性：
導入前，根據導入數據所選分布鍵的業務意義判斷是否合理。以表Lineitem為例，當選擇l_discount列為分布鍵，訂單折扣值區分度很低，僅有11個不同值，l_discount值相同的數據會分布到同一分區，造成嚴重傾斜，導入會有長尾，影響性能。選擇l_orderkey列則更為合適，訂單ID互不相同，數據分布相對較為均勻。
導入后，數據建模診斷中如有分布字段傾斜，則說明選擇的分布鍵不均勻。如何查看分布鍵診斷信息，請參見存儲空間診斷。
檢查分區鍵
INSERT OVERWRITE SELECT導入數據的基本特性為分區覆蓋，即導入的二級分區會覆蓋原表的同名二級分區。每個一級分區內的數據會再按二級分區定義導入各個二級分區。導入時需要避免一次性導入過多二級分區，多個二級分區同時導入可能引入外排序過程，影響導入性能。如何選擇分區鍵，請參見選擇分區鍵。
判斷分區鍵合理性：
導入前，根據業務數據需求及數據分布判斷分區鍵是否合理。如Lineitem表按l_shipdate列做二級分區，數據范圍橫跨7年，按年做分區有7個分區，按日做分區有2000多個分區，單分區約3000萬條記錄，選擇按月或者按年做分區則更合適。
導入后，數據建模診斷中如有不合理的二級分區，則選擇的分區鍵不合適。如何查看分區鍵診斷信息，請參見分區表診斷。
檢查索引
AnalyticDB for MySQL建表時默認全列索引，而構建寬表的全列索引會消耗部分資源。導入數據到寬表時，建議使用主鍵索引。主鍵索引用于去重，主鍵列數過多影響去重性能。如何選擇主鍵索引，請參見選擇主鍵。
判斷索引合理性：
離線導入場景通常已經通過離線計算進行去重，無需指定主鍵索引。
在頁簽，查看表數據量、索引數據量和主鍵索引數據量。當索引數據量超過表數據量時，需要檢查表中是否有較長的字符串列，這種索引列不僅構建耗時，還占用存儲空間，可以刪除索引，請參見ALTER TABLE。
說明主鍵索引無法刪除。需要重建表。
增加Hint加速導入
在導入任務前增加Hint（direct_batch_load=true）可以加速導入任務。
該Hint僅數倉版彈性模式集群3.1.5版本支持，若使用后導入性能無明顯提升，請提交工單。
示例如下：
SUBMIT JOB /*+ direct_batch_load=true*/INSERT OVERWRITE adb_table
SELECT * FROM adb_external_table;使用彈性導入功能加速導入
僅內核版本3.1.10.0及以上的集群支持使用彈性導入功能。
已創建Job型資源組的企業版、基礎版及湖倉版集群支持使用彈性導入功能。
彈性導入僅支持導入MaxCompute數據和以CSV、Parquet、ORC格式存儲的OSS數據。
使用彈性導入功能加速導入時，需確保Job型資源組中可用資源充足，避免資源不足導致任務長時間等待、耗時長、任務失敗等問題。
彈性導入支持同時運行多個彈性導入任務，也支持通過增大單個彈性導入任務使用的資源加速導入。更多信息，請參見數據導入方式介紹。
示例如下：
/*+ elastic_load=true, elastic_load_configs=[adb.load.resource.group.name=resource_group]*/
submit job insert overwrite adb_table select * from adb_external_table;參數說明，請參見Hint參數說明。
通過DataWorks導入數據調優
優化任務配置
優化批量插入條數
表示單次導入的批大小，默認為2048，一般不建議修改。
如果單條數據量過大達到數百KB，如高達512 KB，則建議修改此配置為16，保證單次導入量不超過8 MB，防止占用過多前端節點內存。
優化通道控制
數據同步性能與任務期望最大并發數配置項大小成正比，建議盡可能增加任務期望最大并發數。
重要任務期望最大并發數越高，占用DataWorks資源會越多，請合理選擇。
建議打開分布式處理能力，以取得更好的同步性能。
常見問題及解決方法
當客戶端導入壓力不足時，會導致集群CPU使用率、磁盤IO使用率及寫入響應時間處于較低水位。數據庫服務器端雖然能夠及時消費客戶端發送的數據，但由于總發送量較小，導致寫入TPS不滿足預期。
解決方法：調大單次導入的批量插入條數及增加任務期望最大并發數，數據導入性能會隨著導入壓力的增加而線性增加。
當導入的目標表存在數據傾斜時，集群部分節點負載過高，影響導入性能。此時，集群CPU使用率、磁盤IO使用率處于較低水位，但寫入響應時間較高，同時您可以在頁面的傾斜診斷表中發現目標表。
解決方法：重新設計表結構后再導入數據，詳情請參見表結構設計。
通過JDBC使用程序導入數據調優
客戶端優化
應用端攢批，多條批量導入
在通過JDBC使用程序導入數據過程中，為減少網絡和鏈路上的開銷，建議攢批導入。無特殊要求，請避免單條導入。
批量導入條數建議為2048條。如果單條數據量過大達到數百KB，建議攢批數據大小不超過8 MB，可通過8 MB/單條數據量得到攢批條數。否則單批過大容易占用過多前端節點內存，影響導入性能。
應用端并發配置
應用端導入數據時，建議多個并發同時導入數據。單進程無法完全利用系統資源，且一般客戶端需要處理數據、攢批等操作，難以跟上數據庫的導入速度，通過多并發導入可以加快導入速度。
導入并發受攢批、數據源、客戶端機器負載等影響，沒有最合適的數值，建議通過測試逐步計算合適的并發能力。如導入不達預期，請翻倍加大并發，導入速度下降再逐步降低并發，尋找最合適的并發數。
常見問題及解決方法
當通過程序導入數據到AnalyticDB for MySQL性能不佳時，首先排查客戶端性能是否存在瓶頸。
保證數據源的數據生產速度足夠大，如果數據源來自其他系統或文件，排查客戶端是否有輸出瓶頸。
保證數據處理速度，排查數據生產消費是否同步，保證有足夠的數據等待導入AnalyticDB for MySQL。
保證客戶端機器負載，檢查CPU使用率或磁盤IO使用率等系統資源是否充足。