使用實踐：Hologres對接MaxCompute常見問題排查

大數(shù)據計算服務（MaxCompute，原名ODPS）是一種快速、完全托管的EB級數(shù)據倉庫，致力于批量結構化數(shù)據的存儲和計算，提供海量數(shù)據倉庫的解決方案及分析建模服務。

Hologres是兼容PostgreSQL協(xié)議的實時交互式分析數(shù)據倉庫，在底層與MaxCompute無縫連接，支持您使用創(chuàng)建外部表的方式實現(xiàn)MaxCompute加速查詢，無冗余存儲，無需導入導出數(shù)據，即可快速獲取查詢結果。您也可以導入數(shù)據至Hologres后，再進行查詢。相比其他非大數(shù)據生態(tài)產品，Hologres導入導出數(shù)據的速度性能更佳。

本文總結了Hologres在對接MaxCompute時的常見問題以及對應的處理手段，以幫助您更好的使用Hologres。

common sense

Hologres與MaxCompute的區(qū)別：

Hologres外表和內表的選擇場景

• 新建外部表直接加速查詢

外表不存儲數(shù)據，數(shù)據還是存儲在MaxCompute。外表沒有索引，全靠cpu資源進行計算，因此外表比較適用于小數(shù)據量，低QPS的查詢，見文檔外表訪問。

• 導入數(shù)據至Hologres進行加速查詢

內表的數(shù)據存儲在hologres，當有數(shù)據更新、復雜查詢、高qps的查詢時，建議導入內表，能充分發(fā)揮hologres底層的性能優(yōu)勢，見文檔導入查詢。

報錯信息： specified partitions count in MaxCompute table: exceeds the limitation of 512,

please add stricter partition filter or set axf_MaxCompute_partition_limit. 或者 Build desc failed: Exceeds the partition limitation of 512, current match xxx partitions.

報錯原因：當前hologres只支持查詢最多512個分區(qū)數(shù)

解決辦法：

1、超過512個分區(qū)，請加上分區(qū)過濾條件。

2、可以將數(shù)據導入holo內表，則沒有分區(qū)限制。

3、調整每次query命中的分區(qū)數(shù)大小，默認512，最大為1024，不建議調整太大，會影響查詢性能

set hg_foreign_table_max_partition_limit = 128;--1.1版本  set axf_MaxCompute_partition_limit = xxx --0.10版本

補充說明：holo當前最多支持一級分區(qū)。

報錯信息：Build desc failed: Exceeds the scan limitation of 200 GB, current scan xxx GB.

報錯原因：超出查詢中最大的底層數(shù)據掃描量為200GB的限制導致報錯。200G是SQL命中的數(shù)據量，不是指表的數(shù)據量。但如全表掃描，則按照該表的大小計算，如按照分區(qū)字段查詢，掃描的數(shù)據量為分區(qū)過濾完200G。

解決辦法：

1、增加過濾條件，一次query在200GB以內可直接查詢；

2、將MaxCompute表數(shù)據導入至holo中，再進行查詢，詳情見文檔：MaxCompute導入查詢；（推薦）

3、設置參數(shù)調大數(shù)據量限制（不推薦使用）：

set hg_experimental_foreign_table_max_scan_size = 400；

過分調大外表數(shù)據量限制，可以無法得到預期的性能，也可能造成實例OOM，影響正常使用。（不推薦使用）

查外表很慢

建議優(yōu)化sql，見文檔外表性能調優(yōu)

報錯：Build desc failed: failed to check permission: Currently not supported table type "view"

報錯原因：目前暫時不支持MaxCompute的view。

報錯：Build desc failed: failed to get foregin table split:MaxCompute-0010000: System internal error - get input pangu dir meta fai

報錯原因：讀取MaxCompute時，因為實例的capability配置報錯導致。

解決方法：請在用戶群聯(lián)系Hologres值班開發(fā)恢復正確capability配置。

報錯：ERROR:  status { code: SERVER_INTERNAL_ERROR message: "hos_exception: IO error: Failed to execute pangu open normal file ，err: PanguParameterInvalidException" }

報錯原因：Hologres 1.1較低版本的 引擎 直讀 MaxCompute pangu 加密數(shù)據存在問題，

解決辦法：

1、在sql前面加以下參數(shù)繞過：

set hg_experimental_enable_access_MaxCompute_orc_via_holo = off;

2、升級實例至最新版本

報錯信息：failed to import foregin schema:Failed to get MaxCompute table:Not enable schema evolution

報錯原因：對MaxCompute表的元數(shù)據做了修改

解決辦法：

1、更新了MaxCompute外表schema之后（eg：增加列，刪除列操作），需要執(zhí)行import foreign schema來做刷新。

2、如果執(zhí)行了import foreign schema報錯的話，需要重新建一次MaxCompute的表，再建外表（原因是：MaxCompute修改schema之后進入到schema evolution狀態(tài)，我們無法讀取這種的table，所以需要重新建一次MaxCompute的表）。

報錯：Open ORC file failed for schema mismatch. Reader schema:

報錯原因：MaxCompute的表為orc格式，然后表的decimal類型存儲方式改變（一般是MaxCompute新加了decimal字段或者MaxCompute做了灰度配置變更），導致holo讀MaxCompute的decimal類型出錯

解決辦法：1：執(zhí)行set MaxCompute.storage.orc.enable.binary.decimal=false，重新導下MaxCompute數(shù)據。

2：將MaxCompute的表的decimal類型都改成double類型繞過，重新刷新一遍數(shù)據解決。

報錯ERROR: failed to import foregin schema:Failed to get MaxCompute table:Not enable acid table

報錯原因：MaxCompute表是transation表

解決方法：當前不支持MaxCompute的transation表，建議改成普通表

查外表報錯：Request denied, may caused by server busy.

報錯原因：外表資源占滿,CPU 用量嚴重超出。

解決方法：

1.優(yōu)化sql，讓sql更加充分合理的使用資源，詳情見外表優(yōu)化手段。

2.合理的使用一些參數(shù)改善：

先看一下當前的配置：show hg_experimental_foreign_table_executor_max_dop

• 降低并發(fā)度：set hg_experimental_foreign_table_executor_max_dop = <并發(fā)數(shù)>（推薦降低一半）
• 參數(shù)含義：外表單個執(zhí)行節(jié)點讀取外表數(shù)據的并發(fā)度；
• 默認值：256
• 范圍：0-1024 （不建議低于實例節(jié)點數(shù)）
• 修改后的風險：

• 并發(fā)度太大可能造成實例oom ，導入/查詢失敗，甚至實例重啟，以至于服務不可用。
• 并發(fā)度太小會導致外表查詢/外表導入內表性能較差

• 示例：set hg_experimental_foreign_table_executor_max_dop = 18

3.導入內表，內表可以設置索引，讓性能更好。

導入時發(fā)生OOM，一般報錯為：Query executor exceeded total memory limitation xxxxx: yyyy bytes used

報錯原因：數(shù)據量太大或者導入邏輯太復雜，導致超出了內存限制。（說明：實例由多個節(jié)點組成，一個節(jié)點標準的內存上限是64G，節(jié)點內存會分為3部分，1/3計算，1/3緩存，1/3元數(shù)據。這里的報錯是計算內存超了）

解決方案：

排查步驟1：查看執(zhí)行計劃

可以執(zhí)行explain analyze sql看執(zhí)行計劃中具體的數(shù)據行數(shù)。當導入query包含查詢，但部分table沒有analyze，或者analyze過，但數(shù)據又有更新導致不準確，導致查詢優(yōu)化器決策join order有誤，會引起內存開銷多高。

解決方法：對所有參與的內表、外表執(zhí)行analyze tablename，更新表的統(tǒng)計元信息，可以幫助查詢優(yōu)化器生成更優(yōu)的執(zhí)行計劃。

排查步驟2：設置單行導入條數(shù)

當表的列數(shù)較多，單行數(shù)據量較大時，單次讀取的數(shù)據量會更大，通過在sql前加以下參數(shù)來控制單詞讀取數(shù)據行數(shù)，可以有效減少OOM情況

set hg_experimental_query_batch_size = 1024;--默認為8192

insert into holo_table select * from mc_table;

排查步驟3：降低導入的并發(fā)度。

降低導入并發(fā)度，也會有效減少導入過程中的內存開銷，并發(fā)度通過參數(shù)hg_experimental_foreign_table_executor_max_dop控制，默認為實例的Core數(shù)，可以在導入時設置更小的dop參數(shù)，降低導入的內存使用。

set hg_experimental_foreign_table_executor_max_dop = 8;

insert into holo_table select * from mc_table;

排查步驟4：排查外表重復數(shù)據是否過多

以上操作都做完了，還是導入不了，如果使用的是insert on conflict，排查是否外表重復數(shù)據太多，重復數(shù)據太多也會導致導入性能不好，可以現(xiàn)在是MaxCompute做一下去重，再導入。

排查步驟5：升級新版本動態(tài)調整內存

可以升級至1.1.24版本，新版本會對內存進行動態(tài)調整，后臺會實時刷新當前內存水位，若是有空閑，則會分配更多內存給計算使用。

排查步驟6:擴容

以上步驟都做完了，需要擴容了！

報錯：Timestamp overflow detected while converting timestampfrom orc VectorBatch to arrow

報錯原因：MaxCompute使用 tunnel 寫入后，holo讀MaxCompute Arrow的接口存在問題。

解決辦法：暫時沒有好的解法，需要用戶改為 在MaxCompute將timestamp改成DateTime類型

報錯：query next from foreign table executor failed，userinfao fail

報錯原因：當前MaxCompute表是存儲加密的表，在1.1以下版本還不支持

解決辦法：升級至1.1版本支持存儲加密的表

查外部表報錯：You have NO privilege 'MaxCompute:Select' on xxx

• 問題原因當前賬號不具備MaxCompute表的查詢（Select）權限。
• 解決方法需要MaxCompute管理員在MaxCompute中授予當前賬號查詢表（Select）的權限，具體操作請參見授權。

查外表報錯：The sensitive label of column 'xxx' is 2, but your effective label is 0

問題原因當前賬號只有MaxCompute表的部分字段權限。

解決方法：

1）核對有權限的賬號和報錯的賬號是否為同一個賬號，若是真的沒有權限，可以去申請MaxCompute的權限，或者只過濾有權限的字段查詢。獲取MaxCompute表全部字段的權限，具體操作請參見授權。

2）若是有權限，并且也只查詢了有權限的字段，在實例比較老的版本可能遇見了bug，您可以在執(zhí)行的Query前增加如下參數(shù)解決報錯問題。

set hg_experimental_enable_MaxCompute_executor=on; set hg_experimental_enable_query_master=on;

更多關于MaxCompute的權限問題，可以前往文檔權限。