用 Apache Pulsar SQL 查询数据流

????️ 阅读本文需要大约 7 分钟

Apache Pulsar 越来越受欢迎，尤其在成为 Apache 软件基金会的顶级项目后。

用户不仅将 Pulsar 用于发布/订阅消息，还利用其可扩展的存储架构和分层存储的特性来存储数据流。存储数据后，用户需要对存储在 Pulsar 中的数据进行查询。

另外，一些用户希望可以在数据存储到 Pulsar 后立即进行查询，而无需等待直至数据移入数据库等外部系统。

这一需求促成了 Pulsar SQL 的开发。Apache Pulsar 2.2.0 中首次发布 Pulsar SQL 这一新框架，通过 Pulsar SQL，用户可以使用 SQL 接口高效查询存储在 Pulsar 中的数据流。

本文从技术层面介绍 Pulsar SQL 的架构、实现、功能等，以及促成 Pulsar SQL 开发的背景和用例。

---

背 景 介 绍

Apache Pulsar 最初是作为下一代发布/订阅消息系统而开发的，旨在改善现有消息系统和流系统的不足，与传统的发布/订阅消息系统相比，Apache Pulsar 能够处理更多的用例。

Pulsar 拥有将服务/计算与存储分离的创新型架构，用户因此可以轻松地独立扩展计算或存储资源，添加附加存储资源也更容易。

由于这一架构的优势，用户不仅将 Pulsar 用作一个发布/订阅系统，还将其用作存储新、旧流数据的存储平台。Pulsar 中增加了分层存储后，“流存储”和“事件存储”的实用性也变得越来越重要。

借助分层存储，用户可以通过云存储（例如：Amazon S3、Google Cloud Storage 等）扩展现有 Pulsar 集群，从而以极低的单位成本在云中存储近乎无限量的流数据。

Pulsar 同时具有存储、归档与处理数据流的能力，这使得在单个系统中同时访问实时数据与历史数据成为可能。直到现在，在单个系统中同时访问实时数据与历史数据仍然需要多个系统和工具。

而 Apache Pulsar 支持在一个系统中同时访问这两类数据。Schema registry 的实现为支持 SQL 的查询提供了更加容易的方法。

数据流以结构化的方式在 Pulsar 中被生产，消费和存储

Pulsar SQL 是基于 Apache Pulsar 建立的查询层，用户可以在 Pulsar SQL 中动态查询存储在 Pulsar 内部的所有新、旧流，用户可以通过查询单个系统中的新数据流和历史数据流来进一步理解 Pulsar SQL。

Pulsar SQL 的另一个重要用例在于它可以在很大程度上简化某些数据管道。传统的 ETL 管道（例如：用于输出数据到数据湖），需要从一组外部系统提取数据，并对数据进行一系列转换，以在加载到目标系统前清除旧格式、添加新格式。

格式转换一般作为独立步骤按顺序进行，任一步骤中出现故障，整个过程都会停止。这种方法有两个致命缺点：

• 每个 ETL 步骤都要根据其运行的框架进行专门设计，例如：Sqoop 或 Flume 用于提取数据，Hive 和 Pig 脚本用于转换数据，Hive 或 Impala 进程加载数据到可查询表。

• 本质上看，简化数据管道的过程是面向批处理的，因此加载到数据湖的数据与传入的数据流不一致。批次之间的间隔越长，数据越不及时；相应地，基于数据的决策也就越不及时。

借助 Pulsar SQL，Apache Pulsar 可以实现在同一系统上提取、清除格式、转换格式、查询数据流等操作，从而更好地应对上述问题。

Pulsar 的存储层可扩展（因为Pulsar 使用 Apache BookKeeper 作为其事件存储层），因此 Pulsar 可以实现在单一系统中对数据的操作，并对所有数据（流数据和历史数据）一视同仁。

Pulsar SQL 利用 Presto 和 Pulsar 独特的架构以高度可扩展的方式进行查询，而无需考虑组成流的 topic 分区的数量。接下来我们将讨论一下 Pulsar SQL 的架构。

---

架 构

Presto Pulsar connector 是 Pular 和 Presto 的集成，该 connector 在 Presto 集群中的 Presto worker 上运行。Presto worker 借助 connector 来读取 Pulsar 集群中的数据，并对读取的数据进行查询。

Presto Pulsar connector 如何高效地从 Pulsar 读取数据？

在 Pulsar 中，producer 向 Pulsar 写入消息，写入的消息被放入不同的通道，这些通道又称 为 topic。Pulsar 中的 topic 以分片形式存储在 Apache BookKeeper 中，并复制每个 topic 分片到 Bookie 中，Bookie 是数量可配置（默认值为 2 个）的 BookKeeper 节点。

Pulsar SQL 架构概览

Pulsar SQL 旨在最大化数据扫描速度，因此 Presto Pulsar connector 可以直接从 Bookie 读取数据（而不是从 Pulsar Consumer API 读取），以利用 Pulsar 分片架构的优势。Consumer API 适用于在发布/订阅用例中消费消息，但不一定能优化批量读取。

为了保证排序，Pulsar 中仅由一个 Broker 为单个 topic 提供服务，由此将读取吞吐量限制为一个 Broker 的读取吞吐量。用户可以利用 topic 分区来提高读取吞吐量，但是 Pulsar 希望用户可以在不修改现有 topic 的条件下，以高性能的方式查询 topic。对于查询用例，我们不关心排序，只需读取全部数据即可。

直接从组成 topic 的分片读取数据是一个更优方案。因为分片及其副本散布在多个 BookKeeper Bookie 之间，Presto worker 可以并发地从多个 BookKeeper 节点上读取分片数据，，以实现高吞吐量。用户还可以通过配置更大的 topic 副本数来实现更高的吞吐量，这一操作简便易行。

Worker 从多个副本并行读取以实现高吞吐量

Pulsar SQL 不仅可以查询 Bookie 中的数据，还可以查询卸载到云存储中的数据。通过分层存储，用户不仅可以存储超出物理集群实际容量的数据，还可以对这些数据进行查询，获取更多有价值的信息。

---

用 例

下面是一些常见的 Pulsar SQL 用例。Pulsar 简化了用例中的架构，原本需要多个系统才能实现的任务，在添加了 Pulsar SQL 之后，用户就可以使用 Pulsar 进行日志提取与查询。

• 实时分析：Pulsar 在收到消息后立即可以查询，这一功能使得通过 SQL 查询来合并最新数据到实时数据仪表板，或监控最新数据成为可能。

• Web 分析/移动端应用程序分析：Web 和移动端应用程序生成使用数据流和交互数据流，可以实时查询这些数据流以检测用户使用习惯、提升应用、优化体验等。

• 事件日志和分析：Pulsar 可以处理并存储用户应用程序中的事件日志或操作系统中的系统日志。然后，可以使用 Pulsar SQL 查询存储的日志，调试应用程序、搜索故障等。

• 事件回放：可以使用 SQL 查询按时间顺序提取事件。例如，短时间内识别欺诈性交易的峰值。可以捕获这些事件流，在改进欺诈检测算法时通过回放来模拟欺诈活动。

---

怎 样 测 试 ？

Pulsar SQL 是 Apache Pulsar 2.2.0 版本中的一个预览特性。Pulsar 2.2.0 版本包含一些可以轻松设置环境的工具，可以通过这些工具开始使用 Pulsar SQL 的功能。

更多详细信息，参阅 Pulsar SQL 文档（复制下方链接或直接点击「阅读原文」）。
http://pulsar.apache.org/docs/en/sql-overview/

推荐阅读：

十款性能最佳的压缩算法

盘点开发中那些常用的MySQL优化

kafka｜使用Interceptors实现消息端到端跟踪