端到端实时处理解决方案（Streamlio=BookKeeper+Pulsar+Heron）

投稿

作为一家初创公司，Streamlio团队正在全力打造世界上第一个企业级的端到端实时数据处理平台。从前段时间发布的Streamlio Sandbox预览版中，我们可以初步了解Streamlio平台提供的服务内容。

Streamlio实时处理平台由三个核心系统（Heron、Pulsar和BookKeeper）组成，其中Heron提供实时计算（compute），Pulsar提供持久化的消息系统（messaging），BookKeeper提供流存储（stream storage）。Streamlio团队提供了一系列的技术文章来详细阐述平台的各个组成部分的特性：Heron（https://www.streaml.io/blog/why-heron），Pulsar（https://www.streaml.io/blog/why-apache-pulsar）和BookKeeper（https://www.streaml.io/blog/intro-to-bookkeeper）。

在这篇文章里我们将会讨论一下我们希望的实时处理平台是怎样的，应该提供怎样的服务；并讨论实时计算，持久化的消息系统和流存储服务三个方面是怎样相辅相成，共同组成一个高效的实时处理平台。

持久化的消息系统（Pulsar-Durable messaging）

消息系统就像是一个实时处理平台的神经系统，它将平台上的各个组件连接在一起。消息系统作为基础的数据管道，不仅在平台内为各个系统组件提供通信服务；而且还是平台与外部application之间的交互通道。

如果没有记忆功能，神经系统的价值就会大打折扣。一个Messaging系统可以实现得很简单，但是如果一个进入系统的消息不能持久的保存，可以很容易地被丢失，那么这个简单的系统是有缺陷的。一个可靠的消息系统，应该能够保证在系统故障（硬件故障、网络分区等）发生时，未处理的消息也不丢失，这对实时处理平台十分重要。因为实时处理平台的任务是为进入系统的每个消息和请求执行指定的操作，任意一个消息丢失，都可能会带来无法预计的计算结果。特别是有状态计算（stateful computation），在消息的持久化方面有更明显的需求。

例如在一个实时竞拍的系统中。当有人对某个标的出价时，每一个所出的价格，都会直接影响竞拍系统中标的下一个竞拍价。如果丢失掉一个用户的竞拍价格，会影响后面整个竞拍过程，对整个竞拍带来不可预料的结果。

Streamlio平台选择了使用Pulsar来作为消息系统，因为我们需要一个可以信赖的消息传输通道，来避免上面竞价系统所出现的类似的错误场景。Pulsar是可靠的，因为它的底层使用了比较成熟的企业级的实时数据存储系统BookKeeper来作为持久消息的存储，即使在大量数据产生时，它也能够保证零数据丢失。实时处理平台中的消息系统需要提供这样的可靠性和持久化。持久化的消息系统也是实时处理平台的基本需求。

计算（Heron-Compute）

实时处理平台不仅仅需要一个让数据从一个地方流向另一个地方的通道，它还需要、也必须做一些实际的计算工作。从某种意义上说，计算层（Compute）在实时处理平台中扮演的角色非常简单和直接：为数据提供计算。这种计算包括异常模式的检测、应用相关的复杂算法、不同数据源的聚合、对数据的过滤清洗等等。为达到对实时输入得到实时计算结果（每次计算能在几个毫秒内得到结果）的目的，计算系统必须强大而高效。

从易用性方面，计算层需要为开发人员提供便捷的接口。它需要提供易于理解的抽象、稳定可靠的开发环境和较高的开发效率。现在的开发人员已经习惯了在像PaaS（如Heroku）和容器平台（如Kubernetes）上进行应用程序的部署。实时平台计算层的部署过程可以简单的分成两步，首先很容易地将作业处理（对于Streamlio平台的Heron topology）打包成artifact，然后运行一条简单的命令。换句话说，实时计算平台计算层的使用，应该像使用PaaS的感觉。

实时计算平台计算层需要能很容易地解决大型组织和企业的需求，能够满足组织内众多的团队和部门同时使用，来开发、建立、测试、调优和运行数百甚至数千个具有不同复杂性的计算任务；同时应该提供application级别的资源精细管理，来提高资源使用效率、控制成本。

Streamlio平台选择了使用Heron来作为实时计算层。因为我们知道Heron能够支持上面讨论的计算层的所有需求。Heron已经在Twitter内部非常苛刻的实时计算环境下服务多年，支持了数亿用户级别的服务（如timeline service）。在数年的不断开发积累和进化完善中，Heron已经能满足实时计算的几乎所有需求。

存储（BookKeeper-Stream storage）

尽管我们已经比较熟悉各种各样的存储方案和系统，例如基本的web应用后端存储，HDFS、Ceph、SQL驱动的report系统等等，但是实时计算中的存储需求还是比较特别，传统的存储方案包括各种各样的数据库很难满足。适应实时计算需求的存储系统需要做好这三方面的工作：

• 首先，存储层需要为Messaging系统提供持久化的存储。上面我们已经讨论过，丢失消息会给整个实时处理过程带来不可预料的后果。

• 接着，存储层需要为平台内部和外部application提供便捷的接口，也能让开发人员轻松理解和掌控。

• 第三，存储层需要很容易地支持计算层作业（artifacts）的版本控制（versioning）和分发（distribution）。

Streamlio平台选择了使用BookKeeper来作为存储系统，因为它非常适合实时计算的需求。BookKeeper在Streamlio平台中提供三个方面的支持。

• BookKeeper在后台巧妙地支撑Streamlio的effectively-once语义，保证零数据丢失，为Pulsar系统提供无损的持久化的消息存储。

• BookKeeper为compute applications（Heron topologies）提供便捷易用的后端存储，来支持计算层的有状态处理（Stateful processing）。

• BookKeeper为计算任务和平台外部的应用程序提供可靠的存储。

BookKeeper能够很好地满足企业级实时计算完整需求，它能够使用较少的资源来快速响应各种有状态的处理（Stateful processing）。当然，在Streamlio平台中，开发者也可以使用熟悉的其他数据库来存储计算的结果，比如存储在PostgreSQL或MongoDB中。Streamlio也正在为各种各样的后端存储提供connector。但是使用这些外部存储需要额外的部署，而且只能用在计算层的计算结果存储上。使用集成在Streamlio平台中的BookKeeper则不需要任何额外的部署和管理。

Streamlio的整体视图

从上面的图中，我们可以看到Streamlio的各个组成部分和相互的关联。在这三个部分中，持久化的消息系统、计算系统和流存储系统三者之间是紧密联系不可分割的。

缺了消息系统，计算系统不能获取有效数据；缺了计算系统，整个平台只进行数据传递，失去了处理平台的意义；失去存储系统，消息系统将不再可靠，会丢失数据，有状态的计算任务也不能得到支撑。

Streamlio将最佳的技术整合在了一起，是一个完整的实时处理平台，即使面对最复杂的组织和应用场景，它也能够满足严格的需求，确保了大型组织和公司能够很容易地接受和使用Streamlio平台，使用Streamlio平台来支撑成千上万的实时应用程序。

我将在10月16号和Streamlio创始人郭斯杰共同在QCon全球软件开发大会会前培训中详细介绍流计算相关内容及典型应用，包括10小时的授课和2小时的提问交流。

如果你想学习如何搭建一套高性能、切实可用的实时处理系统，了解分布式系统和实时处理系统设计中常见问题、难点和处理策略，可以点击 【阅读原文】报名参与，开启机器学习工程师之路。报名过程中有任何问题欢迎联系购票经理Hanna，电话：15110019061，微信：qcon-0410。

作者介绍

翟佳，毕业于中科院计算所，目前就职于一家下一代实时处理初创公司Streamlio，是Streamlio的核心创始成员之一。在此之前任职于EMC，是北京EMC实时处理平台的技术负责人。主要从事实时计算和分布式存储系统的相关开发，此外也在开源项目Apache BookKeeper、Distributedlog、DC/OS等项目中持续贡献代码。