Trino 资源组功能测试并与Yarn对比思考
Trino 资源组功能测试并与Yarn对比思考
Trino（原Presto）的资源组功能是管理和分配计算资源的重要机制，主要用于控制查询的资源使用、优先级和限制。本文通过详细的测试，探讨了Trino资源组的排队查询、并发查询和内存资源限制等功能，并与Yarn的资源限制机制进行了对比分析。
背景
在 Trino（原 Presto）中，资源组（Resource Groups） 是一种用于管理和分配计算资源的机制，主要作用是控制查询的资源使用、优先级和限制，从而保证集群在多任务和多用户环境下的稳定性与高效性。
为什么 OLAP 引擎需要资源组？
在 OLAP 引擎（如 Trino）中，查询通常会涉及大量的计算和内存消耗。以下是 OLAP 引擎需要资源组的几个关键原因：
复杂查询的高资源消耗
OLAP 查询通常是复杂的分析性查询，涉及大规模数据扫描、聚合、连接等操作。这些查询往往需要大量的 CPU 和内存资源。因此，合理的资源组管理可以确保这类查询不会耗尽所有资源，影响其他查询的执行。
长时间运行的查询
OLAP 查询可能需要较长时间来执行，尤其是在处理大规模数据时。如果多个长时间运行的查询同时执行，它们可能会对资源产生竞争，从而导致系统的响应时间变慢或无法完成查询。资源组通过限制每个查询的资源使用，帮助保持系统的响应性。
多租户环境的资源管理
在一些 OLAP 系统中，可能需要同时支持多个租户或工作负载。资源组允许管理员为不同的租户或工作负载配置独立的资源池，避免某个租户的查询消耗过多资源影响其他租户的性能。
优化并发性
OLAP 查询往往具有高度并发性，尤其是在面向分析的实时查询时。如果不对查询进行资源管理，可能会造成集群过载，导致查询响应时间变慢。通过资源组，系统可以管理并发任务的数量，确保集群不会因为过多查询并发而瘫痪。
避免过度消耗内存和网络带宽
许多 OLAP 查询可能会消耗大量内存、网络带宽以及磁盘 I/O。资源组提供了内存、带宽等的配额和限制，防止某些查询消耗过多资源，影响整个系统的稳定性。
总结
在 OLAP 引擎中，资源组主要作用是合理分配计算资源、保证查询的公平性和优先级，避免单个查询消耗过多资源。通过这种方式，可以提高查询的吞吐量、稳定性和系统的可扩展性，尤其是在处理复杂分析任务和大规模数据时。
Trino 资源组功能项测试
资源组测试项目
序号 测试项目
1 排队查询（maxQueued）测试
2 并发查询（softConcurrencyLimit/hardConcurrencyLimit）测试
3 内存资源（softMemoryLimit） 测试
排队查询测试
使用代码提交sql，观察原本命中策略状况,并测试最大排队参数（maxQueued）
maxQueued：排队查询的最大数量。一旦达到此限制，新的查询将被拒绝。
策略修改
把用户改为资源组12，且12 对应的parent 为资源组8（default）。所以再度提交后 资源组将变为root.adhoc.default.datatest
并限制资源组12的最大排队4和并发2
策略验证
提交10并发查询。可以看到代码提交处生效
再通过wei ui 验证
测试结论
按策略修改后，原本提交的策略组从 root.adhoc.rghight.datatest 变为 root.adhoc.default.datatest 。且最大排队数从10改到4。触发：
Too many queued queries for "root.adhoc.default.datatest。超出排队的查询会被拒绝掉。比如10个并行查询，maxqueued=4,concurrent=2，那代表会有4个查询被拒绝掉。
集群可接受查询数：正在运行数+排队数
maxqueued 为100，concurrency 为10。
使用代码并行提交100个100GB 查询
通过web ui 查看集群当前消化情况，并在消费达到一定限制的时候重复提交，观察集群是否会崩掉
如图，首次提交 100个。10个运行 90个排队符合预期 。观察集群消化情况
并发查询测试
softConcurrencyLimit：并发运行的查询数。当查询数量超过这个限制时，新的查询可能会被推迟执行，但在某些情况下仍然可以超出这个限制。在负载较高时允许适度超出以提高资源利用率。
hardConcurrencyLimit：正在运行的查询的最大数量。当查询数量达到这个限制时，新的查询将被严格限制，必须排队等待。不允许超过这个限制，新查询必须等待直到有资源可用。
策略修改
修改最大派对数为20，软并发查询为2，硬并发查询为4。
策略验证
同时提交10个运行100G 资源的大查询。看能并行查询的数量为2 还是4
并行提交10个。可以看到并行查询数为4，另外6个排队。
测试结论
按策略修改后，由于修改了排队数为20。软限制为2，硬限制为4。从结果看提交的这10个并行查询都会运行完，但整个资源组下同时最多只能运行4个查询，剩余6个要排队。
内存限制测试（softMemoryLimit）
softMemoryLimit：在新查询排队之前，此组可以使用的最大分布式内存量。可以指定为集群内存的绝对值（即1GB）或百分比10%
是一个软限制，这意味着在资源充足时可以暂时超过该限制，在资源紧张时，Trino 会优先调度和限制内存使用在该软限制之内。
在 Trino 中，查询的内存限制机制是分层次的，涉及多个配置项和资源组限制。如下：
query.max-memory-per-node：这个配置项限制了每个节点上单个查询可以使用的最大内存量。这个限制是针对单个节点的，并且是在节点级别上强制执行的。
query.max-memory：这个配置项限制了整个集群中单个查询可以使用的最大内存量。它是在集群级别上强制执行的。
资源组的 softMemoryLimit：这个限制是在资源组级别上设置的，它限制了该资源组内所有查询总共可以使用的内存量。这个限制是相对于集群总内存的百分比。
我们来使用大资源查询来测试下这三者的关系
策略修改
可以看到当前资源组的软限制为20%。
资源评估：
当前4个worker 节点集群最大可用资源为{416GB（jvm）}64G 。默认单节点查询最大上限约为4.8G（160.3）。跨节点最大可用用户内存20G,最大可用内存40G。
策略验证
使用1TB 代码测试
超出资源限制，命中策略为单节点最大限制4.8GB。即（query.max-memory-per-node）
修改单节点配置为10G,再进行测试。
触发全局最大限制，即（query.max-memory）超出限制的20G
测试结论
没有触发 soft_memory_limit 资源组的软内存资源限制
软限制的性质：soft_memory_limit 是建议限制而非强制限制。系统在达到这个限制时，仍然可能允许查询继续执行，尤其是在负载较低的情况下。
优先级顺序：硬限制（如 query.max-memory-per-node，query.max-memory）的优先级高于软限制。当查询内存使用量接近硬限制时，硬限制会被优先触发。
后续思考，Trino 资源组与yarn 资源限制区别和联系
从当前的测试可以得出结论：YARN 的资源限制（如 memory 和 vcores）是硬限制，明确规定了应用程序在集群中可以使用的最大资源量，超过限制的应用程序将被强制等待或中止，
但trino 不是。
Trino 的 soft_memory_limit 作用：
建议限制：
soft_memory_limit 是一个软限制，用于提示系统在分配内存时尽量不要超过这个限制。但在资源充足或系统负载不高的情况下，可能会暂时允许超出这个限制。
资源控制：
主要用于资源组级别的内存控制，确保同一资源组内的查询不会过度占用系统资源，从而影响其他资源组的查询。
性能优化：帮助优化资源使用，避免因为短时间内的突发负载而导致系统性能急剧下降。
工作原理：
在查询执行过程中，如果内存使用接近 soft_memory_limit，系统会尝试控制内存分配，可能会推迟新的查询或减少现有查询的资源分配。
但因为是软限制，在特定条件下，可能会允许查询暂时超出这个限制，特别是在其他资源组没有使用大量资源时
YARN 的资源限制作用：
严格限制：
YARN 的资源限制（如 memory 和 vcores）是硬限制，明确规定了应用程序在集群中可以使用的最大资源量。超过限制的应用程序将被强制等待或中止。
资源分配：
YARN 使用资源调度器（如 Capacity Scheduler 或 Fair Scheduler）来分配资源，确保所有应用程序公平地获得集群资源。
工作原理：
YARN 将集群资源分为多个队列，每个队列有严格的资源限制和配额。当队列中的资源使用接近或超过限制时，新的应用程序将被排队等待，直到有可用资源。
YARN 的资源限制是严格的，任何超出配额的资源请求都会被拒绝，确保资源分配的公平性和集群的稳定性。