Article / 文章中心

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

发布时间:2022-02-22 点击数:922

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

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

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


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

common sense

Hologres与MaxCompute的区别:

MaxCompute

Hologres

使用场景

ETL加工,面向DWDDWS

在线查询、服务,面向ADS

用户使用

异步的MaxComputeJob/Instance/Task

同步的Query

集群资源

共享大集群

独享集群

计算引擎

基于StageFile设计的,持久化的,可扩展SQLEngine

基于内存的,超快速响应的SQLEngine,计算不落盘

调度方式

进程级别,运行时分配

轻量级线程,资源预留

扩展性

几乎不受限制

复杂查询尽量避免跨多节点数据shuffle

存储格式

列式

行式、列式共存,面向不同场景

存储成本

基于Pangu,成本低

基于Pangu,利用SSD做缓存加速,成本相对高

接口标准

MCSQL

PostgreSQL

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的权限问题,可以前往文档权限