Trino Coordinator高可用技术方案

背景

        我们的分析引擎产品是基于开源trino引擎来实现，同时为了trino可以在kubernetes集群使用，我们定制开发了一个trino operator来用于Trino集群的kubernetes部署。

        而目前架构中trino集群的coordinator存在单点问题，从而存在以下的问题：

1. 当coordinater 挂了，需要k8s拉起Pod，启动过程需要1分钟以上，导致trino集群在1分钟时间不可用。
2. 当trino集群比较大，查询qps比较多，coordinater会成为瓶颈。可能导致无法充分使用集群资源，或者无法配置更大的trino集群。

        基于此，我们希望做一个基于支持kubernetes部署模式的多主模式的HA方案同时解决上面两个问题。在调研了业界的一些HA方案，形成了我们的方案，总体上参考Presto Disaggregated Coordinators的设计思路。

技术方案

引入resource manager

1. 将添加一个新的角色，资源管理器（resource manager）。它负责在整个集群中汇总信息，即查询信息和节点信息。可以有多个资源管理器以便于处理资源管理器中的故障，但是每个resource manager都将拥有整个集群资源的视图。
2. resource manager同时作为discovery，用于实例之间的服务发现。
3. 在coordinator多实例之上提供一个负载均衡器，可以在几个coordinator之间进行适当的负载均衡。
4. 每一个coordinator web ui都能看到整个集群的query信息。

查询流程

1. 客户端提交一个查询执行的POST请求。这会发送到负载均衡器（k8s service），然后重定向到具体coordinator。
2. coordinator解析、分析并像以前一样提交查询给资源组（resouce group）。资源组会定期从resource manager获取集群级别的信息进行刷新。
3. 在从资源组出队之前和之后，coordinator和worker都会向资源管理器发送心跳，包括查询的CPU利用率、资源组选择器和内存池利用率等基本信息。
4. coordinator可以看到整个工作节点群。然而，更详细的信息是从resource manager中获取的，这有助于coordinator选择最少使用的节点来执行。
5. 在查询执行时，节点级别的信息也会定期发送回resource manager。

内存管理

内存管理：coordinator会监视整个集群Memory Pool

1. 由于coordinator和worker会汇报信息给resource manager，resource manager可以聚合总的消耗情况。
2. coordinator会定期从resource manager获取Memory Pool

Resource Group

1. 由于coordinator会汇报query信息给resource manager，resource manager会基于query信息聚合每一个ResourceGroupId
2. 每一个coordinator实例自身维护经过自己的query的ResourceGroup消耗信息，再通过定期获取额外其他coordinator的ResourceGroup消耗信息，形成了最终的ResourceGroup消耗视图。基于最终汇总的ResourceGroup消耗视图解决query查询的排队、运行或者拒绝。

statement API

核心问题：在多个coordinator，一次正常statement请求过程中的多次http请求路由到不同的cn实例的情况下是可用。

1. 当statement的第一次请求POST /v1/statement经过前置service（可以是NodePort或者Ingress）路由到某个cn实例。
2. cn会在内部创建一个新的query放入队列进行后续的处理，同时返回一个queryResult给客户端，queryResult包含了一个nextUrl和partialCancelUri
3. 当开启resource manager时，cn会对两个url进行改写，改写后的url会增加一个query参数包含了真实cn的url地址。比如原地址http://NodePort/v1/statement/queued/20230515_093559_00000_z34q3 改写为http://NodePort/v1/proxy?url=http://cn0/v1/statement/queued/20230515_093559_00000_z34q3
4. 当任何一个cn收到下一次的url请求/v1/proxy，会提取出真实的url，然后进行proxy请求响应。

web ui

核心问题：在多个coordinator，如何实现统一的ui视图。

1. 每个coordinator都可以承担服务UI请求的责任。
2. 由于coordinator会汇报query信息给resource manager，所以每一个resource manager都有所有query的信息。
3. web ui上的集群级别的信息，例如查询列表和集群统计信息，会被重定向到resource manager，后者具有重建这些端点中的数据所需的足够信息。
4. 查询级别的信息，例如终止查询或检查查询详情的功能，如果本地coordinator具有该查询，则本地服务，否则将其重定向到资源管理器，然后代理请求到适当的coordinator。
5. 多个cn保持web-ui.shared-secret配置值相同，保证认证cookie在不同的实例都是有效的。

总结

        基于上面描述的技术方案，我们在kubernetes部署模式下实现了trino coordinator的高可用，通过将coordinator内部的相关状态下沉到新的角色resource manager中（resource manager来构建全局的状态视图），使coordinator变成一个无状态的形式，从而可以完成coordinator的水平扩展能力，既解决了coordinator的单点故障问题，也解决coordinator后续的性能瓶颈问题。