基于 Apache Pulsar 和 Apache Spark 进行批流一体的弹性数据处理

本文介绍了以 Pulsar 做流数据平台，使用 Spark 进行批流一体数据处理的编程实践。

（阅读本文需要约 15 分钟）

批流现状

在大规模并行数据分析领域，AMPLab 的『One stack to rule them all』提出用 Apache Spark 作为统一的引擎支持批处理、流处理、交互查询和机器学习等常见的数据处理场景。 2017 年 7 月，Spark 2.2.0 版本正式推出的 Spark structured streaming 将 Spark SQL 作为流处理、批处理底层统一的执行引擎，提供对无界表（无边界的源源不断到达的流数据）和有界表（静态历史数据）的优化查询，而向用户提供 Dataset/DataFrame API 对批流数据联合处理，进一步模糊了批流数据处理的边界。

另一方面，Apache Flink 在 2016 年左右进入大众视野，凭借其当时更优的流处理引擎，原生的 Watermark 支持『Exaclty Once』的数据一致性保证，和批流一体计算等各种场景的支持，成为 Spark 的有力挑战者。无论是使用 Spark 还是 Flink，用户真正关心的是如何更好地使用数据，更快地挖掘数据中的价值，流数据和静态数据不再是分离的个体，而是一份数据的两种不同表征方式。

然而在实践中，构建一个批流一体的数据平台并不只是计算引擎层的任务。因为在传统解决方案中，近实时的流、事件数据通常采用消息队列（例如 RabbitMQ）、实时数据管道（例如 Apache Kafka）存储，而批处理所需要的静态数据通常使用文件系统、对象存储进行保存。这就意味着，一方面，在数据分析过程中，为了保证结果的正确性和实时性，需要对分别存储在两类系统中数据进行联合查询；另一方面，在运维过程中，需要定期将流数据转存到文件/对象存储中，通过维持流形式的数据总量在阈值之下来保证消息队列、数据管道的性能（因为这类系统的以分区为主的架构设计紧耦合了消息服务和消息存储，而且多数都太过依赖文件系统，随着数据量的增加，系统性能会急剧下降），但人为的数据搬迁不但会提升系统的运维成本，而且搬迁过程中的数据清洗、读取、加载也是对集群资源的巨大消耗。

与此同时，从 Mesos 和 YARN 的流行、Docker 的兴起到现在的 Kubernetes 被广泛采用，整个基础架构正在全面地向容器化方向发展，传统紧耦合消息服务和消息计算的架构并不能很好地适应容器化的架构。以 Kafka 为例，其以分区为中心的架构紧耦合了消息服务和消息存储。Kafka 的分区与一台或者一组物理机强绑定，这带来的问题是在机器失效或集群扩容中，需要进行昂贵且漫长的分区数据重新均衡的过程；其以分区为粒度的存储设计也不能很好利用已有的云存储资源；此外，过于简单的设计导致其为了进行容器化需要解决多租户管理、IO 隔离等方面很多架构上的缺陷。

Pulsar 简介

Apache Pulsar 是一个多租户、高性能的企业级消息发布订阅系统，最初由 Yahoo 研发， 2018 年 9 月从 Apache 孵化器毕业，成为 Apache 基金会的顶级开源项目。Pulsar 基于发布订阅模式（pub-sub）构建，生产者（producer）发布消息（message）到主题（topic），消费者可以订阅主题，处理收到的消息，并在消息处理完成后发送确认（Ack）。Pulsar 提供了四种订阅类型，它们可以共存在同一个主题上，以订阅名进行区分：

• 独享（exclusive）订阅——一个订阅名下同时只能有一个消费者。
• 共享（shared）订阅——可以由多个消费者订阅，每个消费者接收其中一部分消息。
• 失效备援（failover）订阅——允许多个消