我们为什么从 Kafka 迁移至 Pulsar？.docxVIP

我们为什么从 Kafka 迁移至 Pulsar？ StreamSQL 是什么？ StreamSQL 是一个围绕大事源构建的数据存储系统。StreamSQL 由三个组件组成：大事存储、转换和物化形态。大事存储是发送到我们系统的每个域大事不行篡改的账本。我们使用类似于 Cassandra、Redis 和 CockroachDB 的 API 为物化形态供应服务。Transformation （转换）是将大事映射到形态的纯函数。依据 Transformation，我们接收到的每个大事都被处理并应用到物化形态。 StreamSQL 在全部数据中追溯性地运转新的 Transformation。最终形态是整个大事流的真实物化。此外，你还可以通过回滚和回放大事来生成一个“虚拟”形态。虚拟形态可用于训练和验证机器学习模型，也可以用于调试目的（如用于前端开发的 Redux）。 要求 系统需要能够执行以下操作： 将每个域大事永久存储在系统中； 通过保证对每个传入的大事只处理一次，以保持物化形态的全都性； 能够依据我们接收到的相同挨次对全部历史大事进行 Transformation； 回滚并回放大事账本，并在该点物化视图。 最后的基于 Kafka 处理方案 最后的基于 Kafka 处理方案，由一组拼接在一起的大数据工具组成。系统将过去的大事存储在 S3 中，并用 Spark 对它们进行处理。对于流数据，它使用 Kafka 和 Flink。要保持大事和物化视图的全都性，需要在每个系统之间进行简单的协调。 无限存储每个域大事 每个域大事都将通过 Kafaka 进入系统，然后 Kafaka 会将其保存到 S3 中。这就使得我们能够存储大量很少使用的数据，并且具有高长久性和低成本。 我们曾尝试在流上使用 Kafaka 的无限保留，但是发觉它不只成本昂贵，而且难以维护。在更大的主题（Topic）上，我们开头看到功能下降和不稳定的延迟的现象。由于此时我们已经几乎完全迁移到 Pulsar 上，因而没有进一步争辩缘由。 从批数据引导物化视图 我们通过按挨次处理每个大事来物化视图。我们使用 Spark 来处理存储在 S3 的大部分历史数据。假如我们可以在这种情况发生时将大事暂停，事情就会变得简约了。在这种情况下，我们可以读取全部 S3 数据，然后切换处处理主题开头的 Kafaka。实际上，从 Kafka 长久化到 S3 的大事之间有一个延迟，在将大型批集群交换为较小的流处理集群之间还存在另一个延迟。由于我们不能错过任何大事的处理，因而，我们使用 Spark 在 S3 中处理尽可能多的大事，然后让它前往最终一个大事的 ID。由于我们已经将 Kafka 配置为保留最近几周的数据，所以我们可以将 Kafaka 的其余大事回填。 从 Kafaka 回填 Spark 能够处理过去的大多数大事，但它并不能让我们了解最新的形态。为了处理最终一组过去的大事，我们已经配置了 Kafaka 集群，以保留最终两周确认的大事。我们运转一个 Flink 作业来连续 Spark 启动的 SQL Transformation。我们将 Flink 指向 Kafaka 中的第一个大事，并让它通读一遍，什么也不做，直到它到达 Spark 停止的 messageID 为止。从那时起，它将连续更新物化视图，直到它到达流的头部。最终，它通知 Transformermation API，物化视图是最新的，可以使用。 更新传入大事 一旦启动物化视图，StreamSQL 就必需保持物化视图是最新的。在这一点上，这个问题是微不足道的。Kafaka 将每个传入大事直接传递给 Flink，然后 Flink 执行必要的更新。此时，Transformermation API 和 Spark 处于空闲形态。但是，我们仍旧将每个传入的大事保存在 S3 中，以防用户更新或创建 Transformation。 多租户、回滚和回放、错误处理等 我们协调 Flink 和 Kafaka 一起工作，保存物化视图的快照。通过适当的协调，我们可以实现无缝的回滚和回放功能。要对这一过程进行阐述，需要特地写一篇博文（我们期望在不久的将来会撰写）。 在本文中，我们也不会争辩如何扩展 Flink 和 Kafaka 集群、如何处理服务毛病，或者如何在全部这些不同的服务之间实现平安的多租户（提示：每个处理方案都有不同的答案）。 为什么是 Pulsar？ Pulsar 的构建是为了永久存储大事，而不是在系统之间传输大事。此外，Pulsar 是在 Yahoo! 为在全球范围内开发各种产品的团队服务之上构建的。它本身就支持地理分布和多租户。Pulsar 执行简单的部署变得很简约，如为某些租户保留公用服务器。我们尽可能利用这些特性。这使得我们可以将大部分的自定义规