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

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

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

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

common sense

Hologres與MaxCompute的區(qū)別：

Hologres外表和內(nèi)表的選擇場景

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

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

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

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

報錯信息： 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ù)據(jù)導(dǎo)入holo內(nèi)表，則沒有分區(qū)限制。

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

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ù)據(jù)掃描量為200GB的限制導(dǎo)致報錯。200G是SQL命中的數(shù)據(jù)量，不是指表的數(shù)據(jù)量。但如全表掃描，則按照該表的大小計算，如按照分區(qū)字段查詢，掃描的數(shù)據(jù)量為分區(qū)過濾完200G。

解決辦法：

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

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

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

set hg_experimental_foreign_table_max_scan_size = 400；

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

查外表很慢

建議優(yōu)化sql，見文檔外表性能調(diào)優(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配置報錯導(dǎo)致。

解決方法：請在用戶群聯(lián)系Hologres值班開發(fā)恢復(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ù)據(jù)存在問題，

解決辦法：

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ù)據(jù)做了修改

解決辦法：

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做了灰度配置變更），導(dǎo)致holo讀MaxCompute的decimal類型出錯

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

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

報錯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ù)據(jù)的并發(fā)度；
• 默認值：256
• 范圍：0-1024 （不建議低于實例節(jié)點數(shù)）
• 修改后的風險：

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

• 示例：set hg_experimental_foreign_table_executor_max_dop = 18

3.導(dǎo)入內(nèi)表，內(nèi)表可以設(shè)置索引，讓性能更好。

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

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

解決方案：

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

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

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

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

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

set hg_experimental_query_batch_size = 1024;--默認為8192

insert into holo_table select * from mc_table;

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

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

set hg_experimental_foreign_table_executor_max_dop = 8;

insert into holo_table select * from mc_table;

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

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

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

可以升級至1.1.24版本，新版本會對內(nèi)存進行動態(tài)調(diào)整，后臺會實時刷新當前內(nèi)存水位，若是有空閑，則會分配更多內(nè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）權(quán)限。
• 解決方法需要MaxCompute管理員在MaxCompute中授予當前賬號查詢表（Select）的權(quán)限，具體操作請參見授權(quán)。

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

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

解決方法：

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

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

set hg_experimental_enable_MaxCompute_executor=on; set hg_experimental_enable_query_master=on;

更多關(guān)于MaxCompute的權(quán)限問題，可以前往文檔權(quán)限。