Hologres Serverless Computing 快速入门
内容介绍
1. Hologres Serverless Computing 架构介绍
2. Hologres Serverless Computing 使用入门
01、Hologres Serverless Computing 架构介绍
该部分主要介绍 Hologres Serverless Computing 背景及待解决的痛点问题,针对 Hologres Serverless Computing 的架构做简要概述。
1.1 架构介绍
(1)背景介绍
首先,目前大家所购买的 Hologres 实例都是基于预分配好计算资源类型,这部分计算资源是实例级别独占的。在新购实例或升降配实例时,会基于大计算资源需求量作为实例的规格,这会造成用户实例资源的浪费。如一个用户实例在夜间凌晨时主要以大的 ETL 作业为主,此时会充分用到绝大部分的实例资源,但在白天的实时写入和 OLAP Quary 的场景,这类场景的资源消耗小于 ETL,整体实例负载水平较低。这种低负载水平会导致用户预留的大部分闲置资源被浪费。
其次,目前用户实例中的计算资源是所有 Query 一系共享,但实际上用户实例中存在不同类型的工作负载,如果未进行资源隔离的设置,则会造成不同类型工作负载之间的 Query 互相竞争计算资源,导致 Query 性能不稳定,造成一定的抖动现象。
(2)架构介绍
针对上述痛点问题,Hologres Serverless computing 提出了一种新的计算模式,其架构图如下图所示:
Serverless Computing Pool 是由 Hologres 托管的公共资源池,允许用户将自己实例中的大任务提交到该公共资源池中。每个提交的任务都支持动态分配计算资源,确保有充足的计算资源可支持任务的高效执行。
用户使用的 Serverless computing pool 的计算资源整个可用区实例共享,因此,用户之间调度是公平的,用户可以以 Query 级别申请使用。而 Query级别申请的资源存在隔离,避免了不同Query之间的资源竞争,相互干扰,确保大Query能够稳定高效运行。而且执行完毕后,会立刻释放资源。
引入了 Serverless Computing Pool 的计算执行模式,使得实例的资源类型分成两种。一种是用户实例的计算资源,即用户实例预分配好的独享计算资源,被称为独享资源类型,或 Local 资源类型。二是来自 Serverless Computing Pool 的计算资源,即按需分配的计算资源,统一称为 Serverless 资源。这两类计算资源对于不同的场景有不同的优势。 Serverless 资源的弹性较大足的,但是某些场景下,如果 Serverless Computing Pool 的实例资源水位较高,可能会触发一些排队问题,因此,对于查询延迟敏感的 Query 更适合使用用户的独占资源。而实时写入类型的 Query 只能依赖于用户自身的独享资源运行。因此,Serverless 资源不能完全取代用户的独享资源,我们可以将两者共同使用,取得最优的收益。
1.2 适用场景
(1)大SQL作业频繁OOM,期望提升作业成功率与实例稳定性
当实例规格较小,易使得大 SQL 作业运行慢,或频繁 OOM,会影响整体作业的成功率,甚至影响实例级别的稳定性。此时,即可将大 SQL 作业单独使用SQL资源运行,保证作业的稳定高效。上图中是失败 Query QPS的监控指标,可以看到用户在使用 Serverless 资源运行大的ETL作业后,失败的Query数量可降低到零。
(2)实例在流量低峰闲置较多,期望提升资源利用率,降低成本
如果用户实例规格较大,工作呈潮汐分布时,在负载低谷时,资源利用情况率较低,我们可以将资源消耗高的 Query 使用 Serverless 资源,即可按需进行付费,免除大量的闲置资源的费用。
(3)当前实例在流量高峰资源紧张,且通过分时弹性增加一倍资源仍难以缓解资源压力
用户在流量高峰期实例资源较为紧张时,可通过分时弹性扩充一倍资源。
如果在扩充一倍资源后,仍难以缓解资源压力,可以考虑在高峰时段使用 Serverless 资源。Serverless Computing 允许用户使用本实例规格资源数的 3 倍,可显著降低流量高峰带来的查询压力。
1.3 使用成果
这部分介绍 Serverless Computing 前后的对比。
用户在使用 Serverless 之前,使用的是独享资源实例,其实例规格是512 Core。其在夜间的写入 SQL 用掉了大部分计算资源,但在白天的实例负载较低。用户在使用 Serverless 之后,可以将实例降配到256 Core,或将业界的大的写入任务使用 Serverless 资源运行,实现了大任务的隔离,保证独享实例的可用性,实现了整体的降本。
02、Hologres Serverless Computing 使用入门
该部分介绍 Hologres Serverless computing 的重要概念及使用技巧,以及相关工具和一些可观测的手段,并通过几个案例进行实际操作演示,帮助大家快速入门使用 Hologres Serverless Computing。
2.1 在实例级别开启和关闭 Serverless Computing
介绍 Serverless Computing 的相关概念和具体使用,以及工具指标,加深对Serverless Computing 使用情况的观测,并进行操作演示。
(1)Serverless Computing 的开启与关闭
如下图所示:
对于新购实例,需要开启 Serverless,我们在购买实例时,选择实例配置,其中有开启 Serverless Computing 的开关,选择“是”,即可默认将新购实例的 Serverless Computing 打开。对于存量实例,在用户的管控台基础信息页面的右下角即可打开开关,如果需要开启和关闭,按照开关指引,即可完成操作。
另外,在 Serverless Computing 开启之前,还有一些注意事项。
首先,目前仅支持通用型或计算组类型的实例开启 Serverless Computing。
其次,开启 Serverless Computing 有地域和可用区的限制,如果管控台页面的开启按钮是灰色的,则说明当前可用区域或当前地域类暂时不支持 Serverless Computing,可以在官方文档查看可用区的限制。如果通过文档得知到实例所在地域内有可用区支持 Serverless Computing,即可在管控台提交工单,进行可用区的热迁移。另外,如果发现可用区和当前所在地域内均不支持,可以在管控台提出需求。
此外,2.1.17版本以上支持开启 Serverless Computing。但 2.1 版本仅支持 DML 类型的 SQL,2.2 及以后的版本,支持 DQL 和 DML 类型的 SQL。
最后,在实例级别开启和关闭 Serverless Computing 均会导致实例重启。所以,在进行操作时,尽量选择业务低峰期进行操作,大约需花费 2 - 5 分钟。在实例级别关闭后,不再支持指定 Serverless 资源,且当前运行和排队中的 Serverless Query均会失败。
(3)Serverless Computing使用方法
目前,支持在多个级别下进行使用,分别是 SQL 级别、USER 级别、DB 级别和 Query Quere 级别。使用方式非常简单,只要加上简单的配置即可使用 Serverless 资源,无需对业务进行调整。从整体来看,我们建议在 SQL 级别和 USER 级别上设置 Serverless,不建议在 DB 级别下默认设置,因为在DB 级别默认设置后,该DB 下所有能使用 Serverless 资源的 Query 都会使用 Serverless 资源,易造成排队,甚至大幅降低本地资源利用率。另外 Hologres Serverless 3.0版本已经发布了Query Quere,支持大查询熔断后使用 Serverless 重跑,支持每个查询队列中的 Query均使用 Serverless 资源。
另外,Serverless Computing Query有一些限制,如Fixed plan 的实时写入 Query 以及多行 DML 事务的 Query 均不支持使用。在开发时,我们可以通过explain工具查看 Query 的执行计划。我们可以在SQL级别设置好 Computer Resource,如果再使用 Serverless,会在执行计划中展示出 C
omputer
R
esource
:Serverless
的关键字。
接下来是一条实时写入类型的 Query,由于其不支持 Serverless,因此,在它的执行计划中不会显示对应的关键字。另外,如果将参数设置为使用本地计算资源,也不会显示该关键字。
2.2 Serverless Computing资源申请
(1)Serverless Computing Quota资源
第一个重要的概念是的 Quota,它指的是用户实例在运行阶段内所有占用的Serverless Computing Resource的上限值。该值一般是实例独享资源的 3 倍,如果用户当前使用的 Quota 超出了限制,或 Serverless Computing Pool 资源池整体紧张时,用户提交的Query会进入排队状态。对于 Quota 使用情况的监测,可以从管控台的指标看到,相关的技巧会在后文中介绍展示。
(2)Quota资源申请
在资源申请和资源分配方面,在申请资源之前进行资源的估算。该资源数量的估算的目前有两种方式,第一种是自动估算资源,会根据 Query Plan的整体复杂度及读写表所在的 Table Group 数量进行综合预估,保证资源申请的利用率最优,第二种支持手动指定资源,通过hg
_
experimental
_
se
rverless_
computing
_
required
_
cor
es
手动指定资源数量。以下是资源估算两种方式的介绍和对比:
上面两张图中是一条简单 SQL 的两个不同的执行计划,分别是对一个表的两列做 COUNT_DISTINCT 操作。在左边的执行计划中,使用到 CTE,CTE将复用对该表两列的扫描。后续的两个 COUNT_DISTINCT 操作会复用 CTE 的扫描结果。右侧的执行计划分别对表的两列做两次 Scan 操作,再拼接。两种不同的方式展示了同一条SQL的不同执行计划,因此,在 Serverless 场景下,两个不同的执行计划可能会分配到不同的资源,后续我们会根据执行计划的复杂度估算做到资源利用率最优。
(3)Quota 资源管理
更好地管理 Quota 资源,可提高资源利用率,完成更多的业务。下面介绍两种 Quota 资源优化手段。
第一种方法是限制单条 SQL 资源申请的上限。单条 SQL 申请资源上限由三个参数的最小值决定,一是 Quota 资源;二是每条SQL可被分配的资源上限,即
h
g
_
experimental
_
serv
erless_
computing
_
max
_core
s
,默认是 512 CU ;第三个参数取决于当前 Query 所需的计算资源数,在默认使用自动估算资源场景下,该数是由自动估算得出,如果手动指定资源需求量,则会采用该手动指定的数量作为三个参数一起进行计算。若需手动调整该规则,可以设置第二个参数作为最终的最小值。
第二种方法是Serverless Computing Query 优先级的设置。目前,Serverless Computing 提供了五个优先级供用户管理,Serverless Computing 资源的使用,可以通过
hg
_
experimental
_
serve
rless_
computing
_query_
priority
参数进行调整。该参数的默认优先级是 3,取值范围是 [1,5],数值越大,则代表优先级越高,会越优先进行资源的分配。如果用户有两条 Query,即Query 1和Query 2,其优先级分别是 5 和 1,如果当前用户的 Quota 不足,则 Query 1 无法满足,剩余的资源量可以满足 Query 2 。在这种情况下,由于优先级的限制, Serverless Computing Pool 资源会严格根据所指定的优先级进行调度,即强制等到资源充足之后优先调度Query 1,而不会调度Query 2。
其次,可以根据不同 Query 任务场景下紧急程度的不同,为不同的任务设置不同的优先级,避免阻塞排队现象的发生,保证利用率最优。对于一些 OLAP Query,可以一定程度设置高优先级,对于一些离线场景的 ETL 导入,可以使用较低优先级,避免影响其他 Serverless Query 的排队时间,保证Quota利用率最优。
2.3 Serverless Computing观测与监控
这部分主要介绍相关的工具,方便在开发和使用 Serverless Computing 时进行实时的观测和监控。
(1)相关工具
①查看活跃的 Serverless Computing Query
Hologre 中提供了活跃 Query 的管理视图,即
hg
_
stat
_
activity
,其中的
running
_inf
o
包含了一些 Serverless 信息,可根据该信息提供的资源类型、Query 的具体执行阶段以及 Serverless Computing Query 的排队时间和资源使用情况对正在运行的活跃 Serverless Query 进行管理。上图右侧可以从 Running_info中 看到其计算资源类型、所处的阶段、排队过程中的等待时间以及具体资源的分配数。使用该工具可以实时监测 Serverless Computing Query 的排队时间,避免发生阻塞现象。
②查看 Serverless Computing Query 历史运行记录
Hologres 提供了两个系统视图,分别是
h
ologres.
hg
_query_
log
和 h
ologres.
hg
_serverless_
computing
_query_
log
。这两个视图中均提供了完整的 Serverless Computing Query 记录。上图底部展示了一条Query的历史记录,根据相关的字段可以找到其具体的使用情况,如排队时间、资源分配信息、运行时的Query优先级以及单条Query使用资源的上限。另外,还有一个新增字段信息是 Serverless Query 的来源。
③手动优化 Serverless Computing Query 的资源量
第一个方法是使用
h
ologres.
hg
_serverless_
computing
_query_
log
系统视图。我们可以根据该系统视图去获取历史执行的 Serverless Query 记录,也可以根据该视图中提供的 SQL 指纹找到同类型 Query 的历史资源消耗,再根据该历史资源消耗找到合理的资源消耗区间作为手动指定资源数的参考。
另外,在开发时,Explain Analyze 工具会手动执行 SQL 一次,并获取详细的统计信息。在开发时,可以根据该 Explain Analyze 结果提供的实际分配的 Serverless 资源信息、Query的优先级以及排队时间进行判断,并通过手动指定不同的资源数量获得执行时长的判断。如果使用该工具,需要注意它会将所提交的 SQL 实际执行一次,会申请资源并收取相应的费用。
(2)三个监控指标
第一个是正在运行的 Serverless Computing 查询,第二个是排队数量,第三个是Quota使用率。
切换到测试实例的监控信息页面:
从图中可以看到,这三个指标目前都有相应的数值。第一个指标是正在运行的 Serverless Computing 查询的时长,可以通过该监控指标了解当前运行最长的 Serverless Query,对长 Query进行管理和监测。第二个指标是当前正在排队数量的 Serverless Query。第三个指标是实例Quota 的利用率。当 Quota 利用率非常高时,Serverless Computing Query的排队指标也可能会非常高。还有一种情况值得注意,当 Quota利用率相对较低(如80%或90)时出现了大量的排队,需要确认是否为Query设置了不同的优先级。有可能是高优先级的 Query 资源持续未得到满足,导致优先级较低的 Query 阻塞。另外,可以根据该指标设置监控报警的规则。
(3)Demo 演示
① 设置排队数量告警规则
首先,可以点击排队数量的监控指标,跳转到云监控页面。在云监控页面下,可选择对应的实例类型。然后添加具体的规则,先指定该规则的名称。要对 Serverless Computing 排队情况进行监控,如果是紧急的指标,如出现了 100 个排队的 Query,立即紧急告警。如果出现了 50 个,发现警告。
填好所需要的告警规则之后,可以选择告警的对象、推送渠道,提交即可实时地对排队数量进行告警。
② Serverless Computing Query展示和实际操作
打开两个HoloWeb页面,分别是两个用户,第一个是管理员用户,第二个是普通的用户。
a. 在SQL级别开启 Serverless Computing
首先可以通过Explain工具查看执行计划,运行一条 Query,发现该执行计划中没有任何关于 Serverless Computing 信息的关键字说明该Query默认使用本地资源运行。我们可以按照 SQL 级别开启 Serverless Computing,将 hg_computing_resourse
参数设置为 serverless后,再查看执行计划。可以看到该执行计划中有Computing_Resourse:Serverless
的关键字。另外,实际执行一条 Serverless Computing Query,可以在HoloWeb和一些工具页面看到一条提示。这条notice的大致内容是这条 Query 会使用 serverless computing资源。
如需在 SQL 级别关闭,可使用两个开关,即将 hg_computing_resourse
参数设置为成local,或 reset 该参数。当将该参数设置成 local 时,该执行计划中没有 serverless 的关键字,说明该Query会默认使用本地的资源。
b. 在 USER 级别开启 Serverless Computing
上面提到的HoloWeb页面其中的另一个用户是基于basic user的。通过执行alter user “BASICStest_user” set hg_computing_resourse =’serverless’
命令,默认开启该 user 的开关。开启成功后在另一界面执行,查看执行计划,可以看到该用户提交的Query可以不通过设置SQL级别的 Serverless 开关即可默认使用 Serverless 资源。如果需要将该用户默认关掉 Serverless 开关,可以将该资源类型设置成 locol,这样用户运行的 Query 则会默认使用本地资源。
c. 用户使用本地实例资源和 Serverless 资源的场景
用户使用本实例资源的情况下,这条 Query 可能会运行缓慢或出现OMM。在 Query 运行后,已经跑起了,这条 Query tpch 数据量是 100 g,出现了 6 个表的join操作。当 Query 报错后,分析报错信息,可以看到发生了 Query OMM 的现象。换言之,这条 Query 在运行时,其计算内存的消耗超出了当前实例资源的阈值。将这条 Query 切换到 Serverless。切换完成后可看到 Explain Analyze的具体信息,从 Serverless allocated resources:90 cores ,6workers
关键字段,可以看到提交的 Serverless Computing Pool 运行的 Query 申请了90个core, 6 个worker资源,Query 优先级是 3,排队时间是 0 秒,整体的资源消耗是 Serverless 资源。
总之,用户在使用本地资源运行时发生 OMM 后,转而使用 Serverless 资源运行,可以解决 OMM Query和运行速度慢的问题。
d.上述工具的正确使用
第一,通过 hg_stat_activity
视图查看正在运行的 Query 信息。先手动把该 Query 的资源消耗调到最小,降低其运行速度;然后,查看该 Query 的信息;提交,在另一个 HoloWeb 页面展示正在运行的 Query 信息。其中展示了该 Query 的信息及其running_info
字段,可以看到其使用的资源是 Serverless 资源,排队时间是 0 秒,申请到了 15 个 core ,1 个 worker,资源使用时间是 6 秒左右,所处的阶段是执行阶段。说明该 Query 运行成功。
第二,利用 hologres.hg_serverless_computing_q
uery
_log
工具和hologres.hg_q
uery
_log
工具查看上述 Query 的历史运行信息。
首先,hologres.hg_q
uery
_log
系统视图中包含了慢Query 以及所有 Query、Serverless Query 的记录。可以看到排队时间、资源申请量及资源的使用时间,与上一个工具的查询结果对应。换用 hologres.hg_serverless_computing_q
uery
_log
视图查询,也与上述查询结果相同。因此,可以利用这两个视图对 Serverless Query 历史记录进行审计,并通过其他字段了解历史 Query 的具体执行情况以及各资源的申请数量,指导我们手动指定更优的资源。
第三,展示 Explain Analyze工具。首先,手动指定 32 core 的一条 Serverless Query 记录。将这条 Query 手动指定为 32 core 后,可以看到其运行时间及资源分配数量。再将其资源数改到 96 core,可以看到其申请资源数量不超指定的 96 core。
e.Query优先级
分别在两个 HoloWeb 页面指定不同的优先级,运行一条 Query。首先,在第一个 HoloWeb 页面将优先级设置成 5运行。然后,在另一个 HoloWeb 页面优先级设置成 1运行。
可以看到第一条 Query 执行成功并结束,其使用的自动系统预估资源是75 core,优先级是 5,排队时长是 0 秒,即一提交即立马分配了资源。此时,第二条 Query 也运行成功,可以看到其资源申请数量相同,但优先级是 1,排队时间是 8 秒,整体使用时间是 21 秒,说明该 Query 发生了排队。
该例子可为不同类型的 Query 设置不同的优先级,优化整体的使用。
本次分享涵盖了 Hologres Serverless Computing 架构的基本介绍及快速入门使用。Hologres Serverless Computing 拥有资源隔离、弹性加速、查询加速和降低成本的优点,能够稳定执行大规模 ETL和查询。如果实例存在资源负载问题,某些大 Query 运行失败或运行慢的问题,可以考虑使用 Hologres Serverless Computing 解决。如果后续还有疑问或使用相关的问题,可直接在官网提出工单,或加入 Hologres Serverless 用户钉钉群,阿里云会在第一时间解答。
此外, Hologres Serverless 作为一体化实施湖仓平台,已在阿里云上以及阿里集团内部客户的多种不同生产场景中得到了广泛的验证和使用,极大地提高了数据开发和应用效率,官网也提供了不同场景客户的应用案例,可以扫描二维码观看。另外,免费试用 Hologres Serverless 的活动也在如火如荼地进行中,可以扫码试用。