您好，想要为我组织的不同团队创建一个 presto 资源计算器来计算集群 CPU 核心和内存需求
根据我的理解，以下是决定presto集群的cpu核心和内存数量的关键点。有人可以检查并建议此处缺少的与 presto 相关的任何其他术语，以创建简化的 presto 集群资源计算器
输入：
Total Data Size(TS):
Split Size(SS):
Concurrent queries(CS):
Threads per worker node:
Expected processing time by one split(SPT):
Expected memory requirement by one task for a split(SM):
Desired Query SLA(SLA) :
计算：
Total number of splits per query = TS / SS
Total processing time per query = Total number of splits * SPT
Required task parallelism = Total processing time per query / Desired Query SLA
Required worker nodes = Required task parallelism / Threads per worker node
Total Memory required per query = Total VCore required per query * SM
Total VCore required for concurrent queries = Total VCore required per query * CS
Total Memory required for all conclurrent queries = Total Memory required per query * CS
例如： 输入：
Total Data Size(TS): 512GB = 512*1024 = 524288 mb
Split Size(SS): 256MB
Concurrent queries(CS): 10
Threads per worker node: 6
Expected scan time by one split(SPT): 3s
Expected memory requirement by one task for a split(SM): Split Size * 5 = 256*5 = 1280MB
Desired Query SLA(SLA) : 30s
计算：
Total number of splits per query = 524288 / 256 = 2048
Total processing time per query = 2048 * 3 = 6144s
Required task parallelism per query = 6144/30 = 204~
Required worker nodes = Required task parallelism / Threads per worker node = 204 / 6 = 34
Total Memory required per query = 204 * 1280 = 261120MB = 255GB
输出
Total VCore required for all concurrent queries = 204 * 10 = 2040
Total Memory required for all conclurrent queries = 255GB * 10 = 2550 GB = 2.5TB~
Total number of worker nodes = Total VCore required for concurrent queries / Threads per worker node = 2040/6 = 340
这是一个相当复杂的话题。我会尽力提供一些指导，但我认为在不了解有关如何使用集群的更多信息的情况下将其压缩为一个简单的公式并不容易。下面，我尝试分享一些可能有助于得出适合您对 Presto 特定用法的启发式方法的建议。
我认为这个问题的出发点是如何使用集群——这将影响您计算的资源。例如，如果您正在优化即席查询，您可能需要优化 Presto 集群以最大程度地减少排队。即席查询可能会持续几毫秒到几十分钟甚至更长，因此您无法推断出每个查询延迟的任何合理预期。相反，您需要确定最坏的过度准入场景，这取决于集群大小和硬件。
为什么优化正确的事情很重要的一个例子是，任务通常可能会变得倾斜，或者分割的大小不正确。这最终会降低可用性。随着时间的推移，您的集群可能会成为多个出现这些问题的查询的热点，当发生这种情况时，可能会降低集群的整体速度。当集群速度变慢时，这意味着您有更多的并发查询正在以低效的方式运行，这将导致集群的资源组中占用更多的并发槽。
在此示例中，您希望使集群能够适应规模较小的拆分或数据倾斜。为此，您需要计算资源组允许的最大并发量，以防止集群过度准入。集群过度接纳通常是不可取的，因此为了计算这一点，我建议从完美利用 Presto 集群的并发级别开始向后工作。 Presto 中有多个并发级别：查询级别（由资源组控制）、阶段级别（一次调度多少个并发阶段）、任务级别（给定阶段在集群上调度多少个任务）以及拆分级别（为工作人员安排了多少正在进行的或待处理的拆分）。您需要尝试估计任务和阶段级并行性，然后在这些估计中计算出您想要允许多少分割级并行性。一旦您这样做，那么您需要考虑散列连接和聚合将在查询的整个持续时间内经常使用内存，因此您还需要尝试限制并发性以防止过多的内存使用（过度入场的另一个症状）。
现在，假设我们正在优化以最小化延迟，并且我们知道查询实际上可以快速完成。在这里，我们可能会设计队列来促进非常快速的查询，但通过杀死它们来惩罚过度使用或不能快速完成的查询。因此，我们可能不会计算资源组并发性，而是可能会计算分层并行性。为了计算上述最坏的情况，我们可能会考虑允许的最长持续时间查询所达到的最大并行度。目标是允许每个查询尽可能安排最多的分割，而不创建过高的工作分割队列。
先验地确定这一点可能非常具有挑战性。也许更好的方法是对上述内容使用启发式方法，并根据生产中的经验观察进行调整。您希望从更保守的一端开始以确保可靠性，然后放宽约束并衡量对总体内存使用、查询并行性的影响，并监视过度准入的迹象，包括聚合工作线程 CPU、工作线程上的拆分队列和资源组排队。