大数据计算服务(MaxCompute,原名ODPS)是一种快速、完全托管的EB级数据仓库,致力于批量结构化数据的存储和计算,提供海量数据仓库的解决方案及分析建模服务。
Hologres是兼容PostgreSQL协议的实时交互式分析数据仓库,在底层与MaxCompute无缝连接,支持您使用创建外部表的方式实现MaxCompute加速查询,无冗余存储,无需导入导出数据,即可快速获取查询结果。您也可以导入数据至Hologres后,再进行查询。相比其他非大数据生态产品,Hologres导入导出数据的速度性能更佳。
本文总结了Hologres在对接MaxCompute时的常见问题以及对应的处理手段,以帮助您更好的使用Hologres。
common sense
Hologres与MaxCompute的区别:
MaxCompute |
Hologres |
|
使用场景 |
ETL加工,面向DWD、DWS |
在线查询、服务,面向ADS |
用户使用 |
异步的MaxComputeJob/Instance/Task |
同步的Query |
集群资源 |
共享大集群 |
独享集群 |
计算引擎 |
基于Stage和File设计的,持久化的,可扩展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的权限问题,可以前往文档权限。
更多问题可以通过文档查看。
了解Hologres:https://www.aliyun.com/product/bigdata/hologram