【Apache Pinot】Controller、Broker 和 Server 的概念和工作流程

背景

笔者最近一段时间使用 Apache Pinot 比较多，发现目前国内使用 Pinot 的很少，所以跟他相关的资料也比较少，本人在扩容，升级，部署，查询等方面操作有些许经验，知道其中有很多细节需要注意和规避，所以打算开个坑来写一下这块相关的实践内容和注意事项，方便自己回溯也方便使用Pinot 的人参考。 顺便以此来回馈 Pinot 社区对我很多的帮助，依稀记得 Pinot 作者之一 fuxiang 在国外跟我用腾讯会议沟通交流为什么升级 Controller 升级不上去的原因，非常感谢。

缘分

从国外空降了一个 Linkedin 的领导，或许跟他的职业经历有关，也或许跟他的爱好有关。他列出了使用 Pinot 的好处和使用 Clickhouse 的坏处，一番不算激烈的讨论，最终还是引入了 Pinot 用来做后续底层基础。

数据比对

要素/用法及其易用性	ClickHouse	Pinot
kafka流数据输入	支持	支持
Join	支持	只能LookUp
cluster可伸缩	需要手动更改权值以让数据写入新节点，均衡后，再次修改权值以维护均衡	每增加一个节点到cluster，在控制台配置新节点，触发rebalance，pinot会自动调节所有表的数据分布
监控	Prometheus + Grafana	Prometheus + Grafana
维护	随着cluster的扩容，表的定义增加，维护成本越来越重	维护成本基本稳定

概念

单表几万几十万的qps，那种需要多一点broker，不然就还是堆server

笔者在这个章节主要核心是简单介绍一下 Pinot 有哪些必要的组件。

抄了一下官方的图，这里可以看到几个拆的比较开的组件，分别是 Controller，Broker 和 Server。

从图中我们可以看出 Controller 里面有一个 Helix，Broker 是接受 Queries 并且在请求到 Server， MINION 是一个比较特殊的块块，是新版本的一个功能，暂不过多介绍。然后 Server 里其实是对应的 Table，Table是有N个segments组成。

Controller

Controller 顾名思义就是控制，核心还是各种 metadata 的管理。他主要是通过 Helix 的组件来做到强一致性。 Helix 是基于 ZK 的一个 Apache 开源项目。看官方介绍，他其实一个通用集群管理框架，用于自动管理托管在节点集群上的分区、复制和分布式资源。面对节点故障和恢复、集群扩展和重新配置，Helix 会自动重新分配资源。

Broker

简单点说是接受并解析用户打过来的查询，通过某种方式定位到需要查询到 Server，并且把数据打过去。

Server

存储数据，索引等信息的地方。Server 里的 Data 目录有两个文件，一个是 index，一个是 segment，其实主要的一些信息都是在 index 里面。

工作流程

上面就简单介绍了组件，那么他们之间比较高层级的工作流程如下

1. 用户通过不同的平台提交查询到 Pinot
2. Broker 接收到 Query，对查询会做解析，生成对应的查询计划，他会根据 Controller 里面的配置信息知道需要查询哪些 Segment 和哪些 Server 有这些Segment。
3. Broker 会生成对应 N 个查询并行去查询 Server，Server 会基于本地的 Index 等其他数据结构来读取对应的 Segment 并且把部分结果计算好了返回给Broker
4. Broker 最终汇总所有 Server 返回回来的结果并且根据对应的逻辑去做后处理，包含不限于排序，聚合等行为。

总结

根据整体流程，我们大概可以知道每个节点分别的职责是什么，以及他们内部是如何工作的。后面会开内容去详细讲解一下 Controller，Server 和 Broker 内部的功能和细节。简单说的话涉及到升级，扩容，查询超时，修改表结构，修改表数据等内容。