作者：骆撷冬 Hologres PD
本次主题是 Hologres 的计算组实例和分时弹性的入门实践。分三个部分介绍。第一部分介绍 Hologres 计算组实例的原理、架构等，第二部分展示计算组实例的入门实践，第三部分具体演示分时弹性的相关使用实践。
![]()
一、Hologres 计算组实例介绍
1.1 实时数仓的资源难题
![]()
在使用实时数仓的过程中，在资源方面会遇到一些难题。主要有四个方面。
第一个难题是负载隔离。公司通常有很多业务使用数仓资源，数据中台需要通过计算资源进行数据写入，所有的业务都要进行查询，这些业务共用一份资源，会产生资源的争抢。
第二个难题是资源浪费。很多业务的波峰波谷的分时特征非常明显，比如数据中台通常会在凌晨把数据T+1的写入到 Hologres 里，还有很多的业务方在白天会有一个明显的查询流量的高峰。针对这些场景，需要为流量峰值预留足够的资源，但在流量波谷的时候，这些资源往往会产生大量的闲置浪费。
第三个难题是大任务难题。Hologres 实例中，预留计算资源量通常是固定的，如果有一些大型的ETL导入、查询任务等，可能会遇到 Out Of Memory，即 OOM 的问题。这些任务不仅会自己跑不出来，还会长时间的占用计算资源，可能影响其他查询。
第四个难题是运维难题。Hologres 实例的管理团队通常是中台的大数据团队，中台有时很难预估到下游各个业务方的流量波峰。并且业务团队有时会发出一些没有过滤条件的大查询请求，这些查询对于中台团队是未知的，很难提前预留计算资源来解决。
针对这四个难题， Hologres 一直长期迭代，通过不同的方式提供非常好的解决方案。
1.2 Hologres 的弹性计算组实例（V2.0）：负载隔离
![]()
首先是负载隔离问题。Hologres 在 2.0 版本推出了弹性计算组实例（Virtual Warehouse）。实例采用存算分离的架构，只需要保留一份数据，把计算资源拆成多个计算组，就可以解决业务的负载隔离问题。
自下而上来看架构图。在存储层，只需要保留一份存储，所有计算资源访问同一份存储即可。在计算层，可以把计算资源拆分成若干个计算组，通过一个主计算组来负责数据的实时写入，再针对不同的业务来拆分不同的计算组，比如零售业务使用零售计算组，其他业务分别使用物流计算组、风控计算组、营销计算组等。这些计算组的上层会有一个网关（Getway）组件，当 SQL 请求发送到 Hologres 实例，会通过 Getway 来判断 SQL 应该由哪个计算组执行，Gateway在其中起到路由的作用。因此，这个架构可以比较好的解决业务的负载隔离问题。
计算组实例有几个好处：
首先，多个计算组之间的计算资源物理隔离。
第二，所有计算组之间共享一份数据，共享元数据，不需要增加存储成本。
第三，每个计算组可以按需创建，也可以单独灵活扩缩容。
最后，该架构整体是一个实例，只有一个连接串（Endpoint），业务方只需要通过一个固定的连接串请求就可以使用 Hologres 实例。每个业务方具体使用哪个计算组，只需要中台团队通过SQL定义好账号和权限，就可以实现计算组的自动路由。
因此，可以通过 Hologres 的计算组实例来解决第一个难题，即负载隔离难题。
1.3 计算组分时弹性（V2.2）：提高资源利用率
![]()
第二个难题是资源浪费难题。Hologres 在 2.2 版本发布的分时弹性功能可以解决资源浪费的问题，提高资源利用率。
以一个典型的场景为例，如上图所示，业务在每天早上大概两点到九点期间会有一个很明显的流量峰值。在没有使用分时弹性的情况下，为解决流量峰值的问题，需要预留 752CU 的资源，在白天的时候流量较少，这部分资源有很多被闲置浪费。这种场景非常适合使用分时弹性功能。如果使用分时弹性，可以参考下图。首先只需要包年包月预留 400CU 的计算资源，就可以满足除凌晨流量波峰之外的所有任务需要。针对于每天凌晨两点到九点的流量峰值，则只需要为计算组配置一个弹性计划，计划的内容就是每天两点到九点弹出 352CU ，通过这样的方式就可以实现每天定时自动的调度，实现弹性扩容和弹性缩容。整体看一天的资源情况，可以发现资源的利用率显著提升，这样的方式也能帮助进一步的降低成本。
每个计算组都支持单独设置弹性计划，每个计算组的弹性计划也可以设置多个时间段。如果不仅在凌晨有流量高峰，其他时间也有，则可以设置多个弹性时间段来解决多个流量峰值的问题。因此，可以通过计算组分时弹性功能来解决第二个难题，即资源浪费难题。
1.4 Serverless Computing（V2.1）：稳定执行大任务
![]()
第三个难题是大任务难题。可以通过 2.1 版本发布的 Serverless Computing 功能解决。该功能在 2.1 版本起支持，在后续的版本也逐渐迭代，增加越来越多的能力。该功能的核心要点是通过使用本实例预留计算资源以外的资源，即通过使用 Serverless Computing 资源池中的计算资源来解决写入、查询请求中的疑难杂症。该功能在上期课程中已经详细介绍与演示。
1.5 Query Queue（V3.0）：负载限流+大查询隔离
![]()
第四个难题是运维难题。Hologres在 3.0 版本推出了的查询队列（Query Queue）的功能，能够实现负载限流和大查询隔离的能力，从而解决运维难题。该功能将在下期课程中进一步介绍并演示。
1.6 Hologres 资源管理的 Serverless 方案
![]()
最后总结来看，针对于资源管理时可能遇到的一系列难题，Hologres 提供了完整的 Serverless 方案，通过持续演进的 Serverless 能力解决分析服务一体化架构下的隔离、弹性、成本等一系列难题。具体看就是使用计算组实例解决负载隔离的难题，使用分时弹性解决资源浪费的难题，使用 Serverless Computing 解决大查询、大任务难题，使用 Query Queue 解决运维难题。
Hologres 目前已经发布 3.0 版本，涵盖上述所有的功能。未来将在 3.1 版本进一步迭代演进 Serverless 方案。
针对计算组实例，当前已经支持计算组的无损扩容，将会在 3.1 版本进一步支持计算组的无损缩容，这意味着从 3.1 版本起，用户就可以完全无感的对计算组进行扩缩容操作。针对弹性能力，3.1 版本将会在分时弹性的基础上进一步支持计算组的自动弹性。针对运维问题，将会基于查询队列 Query Queue，进一步支持自动限流，解决一些预期以外的流量和运维难题。 3.1 版本将会在2025年上半年和大家见面。
二、计算组实例入门实践
![]()
第二部分，具体演示计算组实例的入门实践。分为七个小部分，包括计算组管理、计算组授权、计算组连接、如何实现负载隔离、如何实现流量切换、如何完成监控告警以及实例类型转换。
2.1 计算组管理
首先演示计算组管理部分。用于演示的实例类型是计算组型，该实例已经预留 64CU 的计算资源。来到计算组管理的页面，可以看到一系列的信息。首先是实例资源的使用情况。实例预留了 64CU 的资源，目前已经创建了一个计算组 init_warehouse，它使用 32CU 的资源。还有 32CU 的资源没有分配出去。这种情况下，可以通过页面来使用未分配的 32CU 来新建计算组，取名叫 readonly ，点击确定，发现计算组已经创建出来，目前在处理中，等待它处理完成即可。同样针对于每一个计算组，可以点击调整配置来完成计算组的升降配，也可以点击重启来重启计算组。Rebalance 功能可以在一些特殊情况下，对计算组中的多个计算节点做负载均衡的处理，通常情况下不需要操作。此时可以看到，实例已经建出两个计算组，每个计算组使用的资源是 32CU。这就是计算组管理相关的能力。
2.2 计算组授权
![]()
第二部分是计算组授权的相关内容。首先解释计算组授权相关的原理。
如果使用的是 Hologres 的通用型实例，只有一份计算资源，这份资源默认能被所有权限的用户使用，默认能够访问所有的数据，所以用户与资源、资源与数据这两个环节不需要专门做显示授权，只有用户与数据之间需要做授权，也即为某个用户授予某张表的读写权限。
如果使用的是计算组型实例，在授权方面需要做一些演进。对于用户与数据之间的权限，仍然沿用通用型实例的授权方式，为用户授予相关表的读写权限。发生变化的是资源相关的授权。由于计算组型实例可以拆分出多组计算资源，每个用户能使用哪一份计算资源便需要管理员显式定义，因此该部分需要显式授权。同样，这份资源能够访问哪些数据，即能够访问哪一个表组（Table Group），也需要做显示授权。
接下来具体演示一下两个授权的过程。回到Hologres管控台，发现实例下的两个计算组都已经是正在运行的状态，表示这两个计算组都可用。点击登录实例进入 HoloWeb，登录数据库，点击安全中心，进入 DB 授权页，首先可以看到目前的实例有一个，数据库名叫 demo ，使用的是简单权限策略。点击用户授权，这里已经提前建好两个用户，分别叫 demo_1 和 demo_2 ，这两个用户都给他授予 demo 数据库下的 Developer 即开发者权限，也就是两个用户都有所有表的读写权限。进一步进行计算组授权相关的动作。
点击计算组管理，首先进行计算组与数据的授权。在计算组 Table Group 授权页，点击新增计算组授权，这里已经默认选好实例和数据库，选择 readonly 计算组，选择 Table Group ，点击确定即可完成授权。这里还有两个其他的配置。首先是副本数量，副本的作用是在有计算节点 Worker 不健康时可以实现读写请求不报错，2 个副本即为有 2 个 Worker 加载同一份数据，可以容忍 1 个 Worker 不健康。第二个配置是把计算组设置为 Table Group 的 Leader 计算组，Leader 计算组可以进行数据写入，如果设置否就是 Follower 计算组，Follower 计算组只能执行读任务。这里仍然把 readonly 计算组设为 Follower，即填否，点击确定。这时可以看到，init_warehouse 是 Leader 计算组，只有一个副本；readonly 是 Follower 计算组，有两个副本。此时便完成了计算组与数据的授权操作
进一步完成计算组与用户的授权操作。在默认情况下，所有的用户都拥有 init_warehouse 的使用权限。针对刚刚创建的 readonly 计算组，则需要进一步的授权。选择 readonly 计算组，新增用户授权，给 demo_2 用户授予 readonly 计算组的使用权限，并且设置为 demo_2 用户的默认计算组。默认计算组的含义就是如果在连接的实例的连接串中不显式指定计算组，则会使用默认计算组。通过这样的设置就可以直接实现切流的效果。点击确定就可以完成授权操作。授权完成后，所有 demo_2 用户的连接请求都会默认连接到 readonly 计算组上。
通过这两步方式，就可以完成计算组相关权限的设定。
2.3 连接计算组
![]()
接下来介绍如何连接计算组，有两个方式。包括默认方式和显示指定方式。
针对于默认方式，以 JDBC 和 PSQL 为例，原本使用通用型实例的连接串如上。对于计算组实例的默认方式同样是这样，不需要做任何改造。以刚刚的授权场景为例，使用 demo_2 用户连接到 Hologres 实例上，会使用它的默认计算组，也就是 readonly 计算组来连接。
除默认方式外，还可以显式指定连接的计算组。只需要通过 JDBC 连接串，在最后 database_name 后面加上一个 @warehouse_name , PSQL 连接方式同理，通过这样的方式就可以连接到指定计算组。针对 demo_2 用户，如果在连接串最后加上一个 @init_warehouse，就会自动的连上 init_warehouse , 而不会默认连上 readonly 计算组。
2.4 使用计算组进行负载隔离
下一步演示如何使用计算组进行负载隔离，通过具体的用户演示。回到 HoloWeb ，来到元数据管理，这里已经提前用 demo_1 和 demo_2 的账密分别登录实例，接下来依次演示。
首先使用 demo_1 账号登录实例，进入 SQL 编辑器，新建一个 SQL 查询窗口。使用 demo_1 为一张已经建好的表写入 1 亿行数据，点击运行。再使用 demo_2 用户登录同一个实例，把 TPC-H Q1 作为示例，使用 demo_2 用户连接 readonly 计算组来运行 SQL 。等待一段时间，可以发现 demo_1 用户使用 init_warehouse 执行的 1 亿行数据写入操作已经完成，耗时 54 秒；demo_2 用户使用 readonly 计算组来执行 Q1 的数据查询也已经执行完成，耗时 28 秒。回到 Hologres 管理控制台，刷新监控信息，可以发现 warehouse_id 为 1 计算组已经出现明显的 CPU 使用峰值，意味 demo_1 用户的数据导入任务已经成功使用 Warehouse 1，即 init_warehouse 来执行。进一步刷新，监控指标回到计算组 Warehouse 3，可以发现只读计算组 readonly 也出现明显的流量峰值，说明 demo_2 用户执行的TPC-H Q1 查询也成功使用了 readonly 计算组的计算资源。
最后还有一个问题，对于 demo_2 用户，默认使用的是只读计算组，那么该用户还能不能执行数据写入的操作？答案是可以的。Hologres 实例默认会开启计算组的自动路由功能，该功能的作用是针对 demo_2 用户使用 readonly 计算组的场景下，如果其发起了一个数据写入的请求，系统会自动判断其是否有主计算组 init_warehouse 的使用权限。如果有，则会自动使用主计算组的计算资源来完成这次数据的写入操作。接下来具体演示。同样使用 demo_2 用户指定 readonly 计算组，执行同样的 1 亿行数据写入任务，点击运行。首先可以发现这条 SQL 没有报错，意味着这条 SQL 在正常执行。等待一段时间，发现导入任务已经完成，回到 Hologres 管理控制台的监控指标页面，进一步刷新，选择主计算组 init_warehouse, 发现已经有明显的第二个流量峰值，意味着 demo_2 用户刚刚执行的数据导入任务成功执行，并且已经自动路由使用主计算组 init_warehouse 的计算资源，实现负载隔离的效果。 demo_2 这一类用户的查询请求默认使用的是 readonly 计算组，如果需要写入也可以把写入任务自动路由到主计算组，通过这样的方式便实现了读写分离的能力。
针对计算组的流量切换，也是使用类似的方式来实现。再登录一次 HologWeb，回到安全中心的计算组管理用户授权页，默认情况下所有的用户默认使用主计算组 init_warehouse。当需要做流量切换的时候，在该页面把希望切流的用户选择出来，比如 demo_2 用户，选择切流的目标计算组并设为默认计算组，就可以完成所有切流的工作。设置完成之后，未来所有 demo_2 的连接请求都会自动的连接到 readonly 计算组上，所有的查询请求都会使用 readonly 的计算资源来运行。
2.5 计算组的监控指标
下一个部分演示计算组的监控指标。在管控台上，可以选择每一个计算组，查看具体的监控指标。监控指标包括 CPU、内存等资源维度，QPS、查询延时、IO、流量等其他维度，都可以针对某个计算组进行查看。
2.6 通用型/主从实例转为计算组型
![]()
如果目前使用的不是计算组型实例，而是一个通用型，甚至是主从实例，要如何把它转成计算组型？
首先有两方面的限制：
转换期间采用标准模式的转换方式，业务影响是需要停机 10 到 20 分钟。如果实例的表数量非常多，原数据量非常大，可能会更久。不同的实例类型转为计算组型，所需步骤也有区别：
-
如果是通用型实例，只需要业务上选择一个时间窗口提交工单，后台协助从通用型实例转成计算组型即可。
-
如果是主从实例，由于主实例和从实例是不同的 Endpoint，而计算组实例只有一个 Endpoint ，因此需要用户先把只读从实例的流量迁移到主实例上，并把只读从实例解绑或者释放掉。这一步完成之后，相当于把原本的主从实例转化成了通用性实例。这种情况下，可以按照刚刚所说的方式确定时间窗口提交工单，后台就可以协助进一步转换成计算组型。
当完成实例类型的转换之后。实例下会有几个主要参数的变化：
-
一是实例类型，在管控台上可以看到它从通用型变成了计算组型。
-
二是 Getway 节点数量，在转换前的通用型实例中没有此概念，转换后新增该组件。可以实际根据 Getway 的使用情况来修改 Getway 配置，也有具体的监控指标可以查看。
-
三是计算资源，转换前的所有计算资源在转换后都会分配给 init_warehouse，保证转换前后的业务不受任何影响，完全兼容。
三、分时弹性入门实践
![]()
第三部分演示分时弹性的入门实践。这里包括三个部分。第一点是分时弹性的相关概念和计费内容，第二点是演示分时弹性如何配置、如何使用，第三点是演示分时弹性的监控与告警。
3.1 分时弹性概念与计费
![]()
首先是分时弹性相关的概念。当使用分时弹性前，计算资源不论是包年包月或者按量付费的付费模式，都是预留的模式。使用分时弹性之后，会多出两层的概念，一个是实例的弹性资源，一个是实例的总计算资源。弹性资源顾名思义就是计算组使用分时弹性额外弹出的资源总量，这一部分资源只需要按使用时长和资源量按量付费。总计算资源则是预留与弹性之和。计算组级别同样有这三个概念。
针对于最开始介绍的分时弹性的使用场景，通过 400CU 预留、352CU 弹性的方式进行使用，在成本上会有什么样的变化？如果不使用分时弹性，有 752CU 的预留计算资源，这部分如果包年包月，目录价如上图所示。如果使用分时弹性，其中 400CU 预留， 352CU 弹性，并且每天只有两点到九点使用七小时，总体计算，可以降本接近 30% ，资源使用率能够显著提升。
3.2 分时弹性使用实践
接下来具体演示分时弹性的使用方法。
回到 Hologres 管控台，进入实例，点击计算组管理，可以看到在计算组管理页面的顶部，有计算组弹性计划选项。在这个页面中，首先是弹性计划时序图，这张图会具体展示实例和计算组在每天每个时刻的预留资源量、弹性资源量和总量 。
计算组列表中，可以为每一个计算组单独设置弹性计划。比如给 init_warehouse 设置一个弹性计划，选择每天的两点到六点，弹性资源 32CU ，点击保存即可生效。这时可以发现在时序图里选择到 init_warehouse 计算组，会发现这张时序图已经发生变化。弹性计划如果所设的时间段涵盖当前的时间范围，它会立刻生效。
接下来进一步对 readonly 计算组配置弹性计划，增加一个时间段，选择晚上 8 点到晚上 24 点时间段，预留计算资源是 32CU ，设置弹性计算资源是 16CU ，点击保存。这时候会收到提示，当前时刻位于该时间段内，保存后计算组会立即变配，所以在使用配置分时弹性的时候也需要谨慎操作，避免配置弹性计划的时候直接对计算组进行扩缩容，影响线上的其他业务。在 Hologres 3.0 版本，计算组扩容期间已经能够做到无损，但缩容还是有影响的。 3.1 版本才会扩缩容全部都无损。
当操作完之后。在时序图里选择 readonly 计算组，可以看到计算组每天的预留计算资源是 32CU ，在每天晚上 8 点到 24 点时间段，会增加 16CU 的弹性计算资源。因为设置的时间段涵盖目前录制视频的时间点，所以配置立即生效，回到计算组资源管理页面，可以看到对 readonly 计算组的弹性计算资源已经是 16CU ，计算组的总计算资源是 48CU ，实例目前的弹性计算资源是 16CU。在弹性计划执行日志里可以进一步的看到每一次弹性计划的扩容和缩容的执行状态以及一些资源变化情况。
3.3 分时弹性监控与告警实践
首先是监控指标。来到监控信息页，选择 Serverless 和资源弹性，可以看到已经支持了分时弹性弹出 Core 数指标，会具体展示一个实例每天几点到几点会弹出多少计算资源。
第二个监控方式是弹性计划执行日志，这里会具体展示每一次执行的状态。
第三个是云监控里会上报计算组每个扩缩容事件。进入云监控页面，选择系统事件，可以看到刚刚所操作的实例在 9:58 的时候开始进行分时弹性的变配操作，在 9:59 的时候完成计算组分时弹性的变配操作。日志中包括详情、资源、时间等全部信息。还可以进一步使用云监控的能力，对计算组分时弹性的变配事件进行订阅，帮助监控分时弹性的具体使用。
更多演示Demo请参考：https://cloud.video.taobao.com/vod/dPNbxc7wlXvxCAfL7Y1cdaUgWzgTingHET0aKUFVZKM.mp4
