使用实践：Hologres对接MaxCompute常见问题排查

大数据计算服务（MaxCompute，原名ODPS）是一种快速、完全托管的EB级数据仓库，致力于批量结构化数据的存储和计算，提供海量数据仓库的解决方案及分析建模服务。

Hologres是兼容PostgreSQL协议的实时交互式分析数据仓库，在底层与MaxCompute无缝连接，支持您使用创建外部表的方式实现MaxCompute加速查询，无冗余存储，无需导入导出数据，即可快速获取查询结果。您也可以导入数据至Hologres后，再进行查询。相比其他非大数据生态产品，Hologres导入导出数据的速度性能更佳。

本文总结了Hologres在对接MaxCompute时的常见问题以及对应的处理手段，以帮助您更好的使用Hologres。

common sense

Hologres与MaxCompute的区别：

Hologres外表和内表的选择场景

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

外表不存储数据，数据还是存储在MaxCompute。外表没有索引，全靠cpu资源进行计算，因此外表比较适用于小数据量，低QPS的查询，见文档外表访问。

• 导入数据至Hologres进行加速查询

内表的数据存储在hologres，当有数据更新、复杂查询、高qps的查询时，建议导入内表，能充分发挥hologres底层的性能优势，见文档导入查询。

报错信息： 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个分区数

解决办法：

1、超过512个分区，请加上分区过滤条件。

2、可以将数据导入holo内表，则没有分区限制。

3、调整每次query命中的分区数大小，默认512，最大为1024，不建议调整太大，会影响查询性能

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

补充说明：holo当前最多支持一级分区。

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

报错原因：超出查询中最大的底层数据扫描量为200GB的限制导致报错。200G是SQL命中的数据量，不是指表的数据量。但如全表扫描，则按照该表的大小计算，如按照分区字段查询，扫描的数据量为分区过滤完200G。

解决办法：

1、增加过滤条件，一次query在200GB以内可直接查询；

2、将MaxCompute表数据导入至holo中，再进行查询，详情见文档：MaxCompute导入查询；（推荐）

3、设置参数调大数据量限制（不推荐使用）：

set hg_experimental_foreign_table_max_scan_size = 400；

过分调大外表数据量限制，可以无法得到预期的性能，也可能造成实例OOM，影响正常使用。（不推荐使用）

查外表很慢

建议优化sql，见文档外表性能调优

报错：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配置报错导致。

解决方法：请在用户群联系Hologres值班开发恢复正确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 加密数据存在问题，

解决办法：

1、在sql前面加以下参数绕过：

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表的元数据做了修改

解决办法：

1、更新了MaxCompute外表schema之后（eg：增加列，删除列操作），需要执行import foreign schema来做刷新。

2、如果执行了import foreign schema报错的话，需要重新建一次MaxCompute的表，再建外表（原因是：MaxCompute修改schema之后进入到schema evolution状态，我们无法读取这种的table，所以需要重新建一次MaxCompute的表）。

报错：Open ORC file failed for schema mismatch. Reader schema:

报错原因：MaxCompute的表为orc格式，然后表的decimal类型存储方式改变（一般是MaxCompute新加了decimal字段或者MaxCompute做了灰度配置变更），导致holo读MaxCompute的decimal类型出错

解决办法：1：执行set MaxCompute.storage.orc.enable.binary.decimal=false，重新导下MaxCompute数据。

2：将MaxCompute的表的decimal类型都改成double类型绕过，重新刷新一遍数据解决。

报错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.优化sql，让sql更加充分合理的使用资源，详情见外表优化手段。

2.合理的使用一些参数改善：

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

• 降低并发度：set hg_experimental_foreign_table_executor_max_dop = <并发数>（推荐降低一半）
• 参数含义：外表单个执行节点读取外表数据的并发度；
• 默认值：256
• 范围：0-1024 （不建议低于实例节点数）
• 修改后的风险：

• 并发度太大可能造成实例oom ，导入/查询失败，甚至实例重启，以至于服务不可用。
• 并发度太小会导致外表查询/外表导入内表性能较差

• 示例：set hg_experimental_foreign_table_executor_max_dop = 18

3.导入内表，内表可以设置索引，让性能更好。

导入时发生OOM，一般报错为：Query executor exceeded total memory limitation xxxxx: yyyy bytes used

报错原因：数据量太大或者导入逻辑太复杂，导致超出了内存限制。（说明：实例由多个节点组成，一个节点标准的内存上限是64G，节点内存会分为3部分，1/3计算，1/3缓存，1/3元数据。这里的报错是计算内存超了）

解决方案：

排查步骤1：查看执行计划

可以执行explain analyze sql看执行计划中具体的数据行数。当导入query包含查询，但部分table没有analyze，或者analyze过，但数据又有更新导致不准确，导致查询优化器决策join order有误，会引起内存开销多高。

解决方法：对所有参与的内表、外表执行analyze tablename，更新表的统计元信息，可以帮助查询优化器生成更优的执行计划。

排查步骤2：设置单行导入条数

当表的列数较多，单行数据量较大时，单次读取的数据量会更大，通过在sql前加以下参数来控制单词读取数据行数，可以有效减少OOM情况

set hg_experimental_query_batch_size = 1024;--默认为8192

insert into holo_table select * from mc_table;

排查步骤3：降低导入的并发度。

降低导入并发度，也会有效减少导入过程中的内存开销，并发度通过参数hg_experimental_foreign_table_executor_max_dop控制，默认为实例的Core数，可以在导入时设置更小的dop参数，降低导入的内存使用。

set hg_experimental_foreign_table_executor_max_dop = 8;

insert into holo_table select * from mc_table;

排查步骤4：排查外表重复数据是否过多

以上操作都做完了，还是导入不了，如果使用的是insert on conflict，排查是否外表重复数据太多，重复数据太多也会导致导入性能不好，可以现在是MaxCompute做一下去重，再导入。

排查步骤5：升级新版本动态调整内存

可以升级至1.1.24版本，新版本会对内存进行动态调整，后台会实时刷新当前内存水位，若是有空闲，则会分配更多内存给计算使用。

排查步骤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，您可以在执行的Query前增加如下参数解决报错问题。

set hg_experimental_enable_MaxCompute_executor=on; set hg_experimental_enable_query_master=on;

更多关于MaxCompute的权限问题，可以前往文档权限。