背景
为了让业务团队能够更好的跟踪本人音讯的生产和生产状态，须要一个相似于表格视图的音讯列表，用户能够直观的看到发送的音讯；同时点击详情后也能查到音讯的整个轨迹。
音讯列表
点击详情后查看轨迹
原理介绍
因为 Pulsar 并没有关系型数据库中表的概念，所有的数据都是存储在 Bookkeeper 中，为了模仿应用 SQL 查问的成果 Pulsar 提供了 Presto (当初曾经更名为 Trino) 的插件。
Trino 是一个分布式的 SQL 查问引擎，它也提供了插件能力，如果咱们想通过 SQL 从自定义数据源查问数据时，基于它的 SPI 编写一个插件是很不便的。
这样便能够相似于查询数据库一样查问 Pulsar 数据：
Pulsar 插件的运行流程如上图所示：
- 启动的时候通过
Pulsar-Admin接口获取一些元数据，比方 Scheme，topic 分区信息等。 - 而后会创立一个只读的 Bookkeeper 客户端，用于获取数据。
- 之后依据 SQL 条件过滤数据即可。
相干代码：
应用 Pulsar-SQL
应用起来也很简略，官网提供了两个命令：
- sql-worker: 会启动一个 trino 服务端同时运行了 Pulsar 插件
- sql: 就是一个 SQL 命令行终端。
遇到的问题
本人在本地运行的时候天然是没问题，可是一旦想在生产运行，同时如果你的 Pulsar 集群是运行再 k8s 环境中时就会碰到一些问题。
无奈应用现有 Trino 集群
首先第一个问题是如果生产环境曾经有了一个 Trino 集群想要复用的时候就会碰到问题，惯例流程是将 Pulsar 的插件复制到 Trino 的 Plugin 目录，而后重启 Trino 后就能应用该插件。
当然社区也是反对这么做的：
然而当我将 Pulsar-plugin 复制到 Trino 中运行的时候却失败了，整体的流程能够参考这个 issue：
https://github.com/apache/pulsar/discussions/20941
简略来说 Trino 的官网镜像和 pulsar-plugin 并不能兼容，这个问题间接影响到咱们是否能够在生产环境应用它。
然而手动编译进去的 Trino 服务和插件是兼容的，能够间接运行。
因而我只能在本地编译出 Trino 服务端和 pulsar-plugin 而后打包成一个镜像来运行了，当然这样的害处就是无奈利用到咱们现有的 Trino 集群，又得重新部署一个了。
流程也比拟麻烦：
- 首先是本地编译
Pulsar-SQL模块 - 将生成物复制到当前目录
- 执行
make docker打出 docker 镜像并上传到私服 - 再执行
kubectl将 trino 部署到k8s环境中
整个流程做下来加上和社区的沟通，更加确定这个性能应该是很少有人在生产环境应用的，毕竟第一个坑就很麻烦，更别提后续的问题了😂。
Presto 插件不反对 AuthToken
第二个问题也是个深坑，当我把 Trino 部署好查问数据的时候间接抛了一个调用 pulsar-admin 接口连贯超时的异样。
后果排查了半天发现原来是 pulsar-plugin 里没有提供 JWT 的验证形式，而咱们的 Pulsar 集群恰好是关上了 JWT 验证的。
为此我只能先在本地修复了这个问题，同时也提交了 PR，预计会在下一个大版本合并吧：
https://github.com/apache/pulsar/pull/20860
新创建的 topic 查问失败
第二个问题是当查问一个新创建的 topic 时，客户端会间接 block，相干的复现流程在这里：
https://github.com/apache/pulsar/issues/20910
这个问题还好，不是很致命，是我在本地测试的时候无意间发现的。
本地我曾经修复了，前面也提交了一个 PR，目前还在探讨中：
https://github.com/apache/pulsar/pull/20911
查问音讯会失落最初一条
这个问题也不是很重大，数据量少的时候会发现，就是在指定了音讯发送工夫的查问条件时，最初一条音讯会被过滤掉，相干 issue 在这里：
https://github.com/apache/pulsar/issues/20919
这个我只是定位到了起因，但不太分明 为什么要这么做 (-1)，影响也不是很大，就放在这里搁置了。
Schema 不兼容
最初发现的一个问题是咱们线上某些 topic 查问数据的时候会抛出 Not a record: "string" 的异样，但只是局部 topic，也排查了很久，整个源码中没有任何一个中央有这个异样。
https://github.com/apache/pulsar/issues/20945
根本原因是生产者生成的 schema 有问题，类型曾经是 JSON 了，然而 schema 却是 string，这样导致 pulsar-plugin 在反序列化 schema 的时候抛出了异样，因为是 pb 反序列化抛出的异样，所以源码中都搜寻不到。
没有问题的 topic 应用了正确的 schema
后续我也在本地修复了这个问题，当抛出异样后就将 schema 降级为根本类型进行解析。
不过实质问题还是客户端应用有误，如果对 schema 了解不精确的话还是倡议应用 byte[] 吧，这样至多兼容性不会有问题。
相干 PR：
https://github.com/apache/pulsar/pull/20955
总结
Pulsar-SQL 是一个十分有用的性能，只是咱们应用过程中的确发现了一些问题，大部分都曾经修复了；
心愿对后续应用该性能的敌人有所帮忙。