本文为您介绍Hologres计算资源管理最佳实践，帮助您更高效、更智能、更具性价比地承载业务复杂多样的读写请求。
背景信息
本文以某电商公司数据中台为例，中台团队负责数据加工，多个业务团队均需数据查询。各团队业务场景、业务特点如下。
团队 | 职责 | 业务场景 | 业务特点 |
数据中台 | 负责全部业务团队的数据写入与加工，含实时链路、近实时链路和离线链路。 | 实时/近实时链路：
离线链路：
|
|
分析业务方 | 面向运营、门店和销售等多类角色，负责公司销售数据分析。 |
|
|
推荐业务方 | 面向智能推荐业务，负责商品千人千面推荐。 | 在线推荐：基于主键查询用户特征，下游推荐算法基于用户特征返回推荐商品。 | 每晚为用户使用电商平台流量波峰时段。 |
优化原理
如果业务请求始终稳定，则仅需购买一定数量的包年包月计算资源，即可满足业务负载需要。但大部分情况下，业务均存在高并发请求波峰，或存在极端大任务，导致计算资源持续打满，影响实例稳定性。此时，可按如下决策树选择资源优化方案
极端大任务（例如：大量历史数据回刷、无过滤条件的全表扫描、10+表的复杂关联查询、多层子查询嵌套的复杂计算等）推荐直接使用Serverless Computing资源，避免影响本实例资源正在执行的其他Query。
经过Fixed Plan优化的请求不支持使用Serverless Computing资源执行，也不进入查询队列（即不支持限流），因此只能通过扩容计算组解决。
其他请求可根据业务延时需求、波峰时段特征、请求类型特征来选用合适的资源优化方案。
对于使用Serverless Computing的业务请求，可参见资源管理优化实践，选取合适的使用方式。
资源管理优化实践
将从以下业务痛点出发，为您推荐最优的解决方案。
痛点一：不同业务之间资源挤占，互相影响
数据中台的数据加工任务、下游各业务方的数据查询任务可能会互相挤占对方的计算资源，受到其他业务的影响。
推荐使用Hologres计算组型实例，创建如下计算组，以保证不同团队之间负载隔离。计算组型实例请参见计算组实例架构。
主计算组（init_warehouse）：中台团队使用，负责数据写入与加工。
只读计算组1：分析业务方使用。
只读计算组2：推荐业务方使用。
痛点二：业务有固定高峰，资源扩缩容复杂
本文示例场景中，如下业务场景可能存在该难题，可通过计算组分时弹性（Beta）功能，对计算组定时扩、缩容。相比于全部使用包年包月计算资源的方案，分时弹性每天弹出16小时内即可降低成本。
数据中台的实时写入任务：
实时写入任务会经Fixed Plan优化，仅支持计算组扩缩容的方式解决资源问题。
每晚为流量波峰时段，可配置分时弹性，每晚对主计算组定时扩缩容。
分析业务方的BI分析任务：结合流量波峰时段（白天工作时间）特点，配置分时弹性，对只读计算组进行定时扩缩容。
推荐业务方的在线推荐任务：
在线推荐任务属于点查，会经Fixed Plan优化，只可选择对计算组扩缩容的方式解决资源问题。
结合流量波峰时段（每晚），可配置分时弹性，每晚对只读计算组定时扩缩容。
痛点三：大任务OOM频率高并长期占用资源，影响其他任务
本文示例场景中，如下业务场景可能存在“大任务”难题：
数据中台的T+1离线加工任务：单任务的计算量可能非常大，任务本身容易OOM，还可能长期占用计算资源，阻塞其他任务。
方案一（稳定性优先）：所有T+1离线加工任务均使用Serverless Computing资源执行，可通过SQL级别配置，或对执行离线链路的用户级别配置。详情请参见使用Serverless Computing资源执行读写任务。
方案二（稳定性与成本兼顾）：如果离线链路存在大小不一的表的写入与加工任务，可以将小型任务保留在主计算组中执行。
数据中台的Dynamic Table近实时加工任务：每张表每分钟执行一次增量刷新任务，任务计算量与增量数据量相关，存在不稳定因素。
方案一（稳定性优先）：Dynamic Table近实时加工任务均使用Serverless Computing资源执行。详情请参见CREATE DYNAMIC TABLE。
方案二（稳定性与成本兼顾）：将Dynamic Table中大表或存在较大数据量波动的表的刷新任务使用Serverless Computing执行，其余任务保持在主计算组中执行。
分析业务方的BI分析大屏：大屏数量多，任务存在大小差异，大任务可能长期占用计算资源，从而阻塞小任务。
方案一（稳定性、成本与开发量兼顾）：DB级别或用户级别（大屏数据源对应用户）开启自适应Serverless计算功能，可以将大屏中的“大任务”自动指向Serverless资源，小任务仍在本计算组中执行。
方案二（稳定性与成本兼顾）：提取大屏中“大任务”的SQL指纹（具体看板的SQL指纹通常不变），形成一个查询队列，配置该查询队列的请求均使用Serverless资源执行。该方案可通过如下流程实现：
测试大屏，使Hologres执行完大屏中的全部请求。
在Hologres慢Query日志中，按cpu_time_ms字段筛选出“大任务”，提取对应的digest字段，即SQL指纹。详情请参见慢Query日志查看与分析。
将这些“大任务”的SQL指纹配置成一个单独的查询队列。详情请参见配置分类器匹配规则。
配置该查询队列的请求均使用Serverless资源执行。详情请参见使用Serverless Computing资源执行查询队列的查询。
方案三（成本优先）：所有请求均优先在本计算组中执行，同时对查询队列开启“大查询自动重跑”功能，使用Serverless资源重跑超时查询和OOM查询，同时用户对超时和OOM无感知。详情请参见大查询控制。
痛点四：突发性大任务直接打满资源池，影响系统稳定性
分析业务方的运营人员自助分析任务：该类任务可能出现突发性大任务，单个请求可能产生较大开销，影响实例稳定性。
方案一（稳定性优先）：用户级别配置该自助分析人员的全部请求均使用Serverless Computing执行，详情请参见用户级别配置。
方案二（稳定性与成本兼顾）：用户级别开启自适应Serverless计算功能，可以将该用户发起的“大任务”自动指向Serverless资源，小任务仍在本计算组中执行。
方案三（成本优先）：所有请求均优先在本计算组中执行，同时对查询队列开启“大查询自动重跑”功能，使用Serverless资源重跑超时查询和OOM查询，同时用户对超时和OOM无感知。详情请参见大查询控制。
痛点五：不同场景数据时效性、稳定性要求不同
分析业务方的BI分析大屏：企业多类角色（数据开发人员、运营人员、销售人员、企业高层等）均可能访问大屏，同时访问大屏的渠道也有差异（对客展示、内部查看等）。
针对性能要求高的角色/场景：
方案一（稳定性优先）：如果该场景请求量稳定，可为其单独创建计算组以承载其请求。
方案二（稳定性与成本兼顾）：可使用上文方案一（稳定性优先），全部请求均通过Serverless Computing执行，或使用自适应Serverless计算功能。
针对可接受一定延时的角色/场景：
如果大屏的请求类型固定，比如该类角色只会访问一个报表，可在充分压测计算组对该报表的承载能力后，配置手动限流（基于查询队列配置固定数量的并发度上限），详情请参见创建查询队列。
如果大屏的请求类型不固定，比如该类角色数量多且报表数量也多，可开启自动限流功能。Hologres会根据负载情况自动调整查询队列的并发度上限，详情请参见自动限流（Beta）。
高级操作
配置Serverless Computing中任务的优先级
由于多个业务均需使用Serverless Computing计算资源，可以在用户级别对不同用户发送至Serverless Computing中的请求配置优先级。详情请参见设置Serverless Computing任务的优先级。示例如下：
性能要求高的角色的查询请求：配置优先级为5，Serverless资源紧张时优先执行。
离线T+1写入与加工任务：配置优先级为1，Serverless资源紧张时排队等待。
其他任务：使用默认优先级3。
配置Serverless Computing日累计用量限制
由于多个业务均可使用Serverless Computing计算资源，可能产生额外费用。Hologres支持配置实例每日可用的Serverless Computing资源量限制，同时支持对不同用户配置不同的上限，可帮助用户灵活高效地使用Serverless计算资源。详情请参见日累计用量限制。
配置只读计算组的查询高可用
针对只读计算组，尤其是只读计算组承载的在线推荐业务，推荐配置Shard级别多副本，可实现在有计算节点Failover时查询无损。详情请参见单实例Shard级多副本，