郭斯杰：重新思考流计算时代的分布式存储

　　所以Lambda的架构，其实只是把这两个Data Silo在最终的结果端做了一个汇总，让用户看起来是一个统一体。但实际上，你最开始的数据进来，会被分流到两个不同的系统里面去，一个是所谓的消息中间件，一个是文件系统或者对象存储。你整个业务的代价、机房的开销、硬件设施的代价、维护人员代价，其实都是双倍的。所以在这种情况下，我们发现Lambda会变得越来越重，因为随着数据量变得越来越大，本质上是没法使用Lambda支撑更大的业务。

　　所以在这种情况下，就有人提出了Kappa的概念。它的概念其实很简单，就是所有的数据都以日志的方式存进来，因为日志它其实是一个append-only的存储。存进来了以后，日志本身上它具有流的一个特性，然后所有的访问都是以追尾读的方式去读，所以它可以做到消息中间间的低时延。那就可以把所有数据存起来，当你需要回放历史数据时，还可以做相应的批处理。

　　在计算引擎上，因为你的数据表征变成一份了，你的计算引擎、API就可以统一起来，所以这也是后来为什么那么多计算框架在做批、流一体。比如Flink既可以支持批，也可以支持流。其实都在做一个事情，就是要让API在处理批跟处理流上是统一的，只需要学一个计算框架、一套API，就能做原来的两件事情。

　　Kappa这个架构是很好的一个想法，但要真正做到真正意义上的Kappa，你不能拿一个消息中心间去做一个Kappa。因为消息中间件基本上是为消息，就是你的尾端数据去做设计的，所以它基本上没有考虑存储方面的一些特性。所以我们认为在批、流一体的时代，当你需要去做批、流一体化的计算时，其实是需要一个真正意义上的流存储。

　　流存储的意思就是，你的数据可以通过流的一个或者append-only log的方式去表征。你最新的数据被append到log里面以后，它其实是作为我们通常意义上说的流计算的尾端数据进行处理，但你的数据被append之后会慢慢累加，就会变成你的历史数据。当你需要去做全量计算，需要回溯到7天前、30天前这样一个处理历史数据的时候，你可以进行相应的回溯。所以我们认为Kappa是你做批、流一体的一个正确基础，但是我们需要为Kappa去做一个真正意义上的流存储。所以我们streamlio大部分创始团队都是来自于Twitter、雅虎原来做消息中间件跟流计算的，所以我们一直在琢磨一个事情，就是说我们怎么去做真正的流存储。

　　二、关于Apache Pulsar

　　接下来，主要分享我们正在做的一些工作，然后我会回过头来怎么看我们做的工作是怎么映射到现在针对于批、流一体的计算方式下的一个考量。

　　我们先来看一个特点，什么叫流存储?流存储，它其实两个单词，一个stream，一个是storage。Stream代表了它的访问模式，就是在数据写入以后，我的消费者或者我的读者，是立马可见的，不需要等经过比如5分钟的批处理，等文件全部写完了以后，才能提交到执行引擎去处理。通常stream的一个接口，就是传统意义上的消费订阅模式，就是说我的数据生产到这个stream里面之后，我的订阅者、消费者就立马可见。

　　Storage的意思是跟传统意义上storage类似，它本质上是一个分布式存储，它需要保证我能够可靠稳定地保存数据，不丢数据，而且无论我什么时候再去访问这个数据，我的架构上都有能力把这个数据给存下来。因为我们刚才一直在说的就是所谓的大数据，有大量的数据要算，所以这个东西必须是水平可扩展的，并且是高吞吐的。

　　所以我们围绕一个开源的项目叫Apache Pulsar来做这个事情。Pulsar是什么呢?其实最简单的、最容易理解的是，我们通常来说这个事情的话，我们会把它放到消息队列里面，就跟大家知道的Kafka、ACTIVE MQ、RabbitMQ都是在一个space里面，但是它不同的地方是什么?就是说Pulsar在整个设计上，并不只是一个简简单单的消息队列，我们通常用一句话来概括Pulsar是什么，“Flexible Pub/Sub messaging backed by durable log/stream storage”，它其实有两层意思，就是说你是一个面向消息或者面向流的消息系统，但是这个消息系统可以提供低延时地消费你的数据的能力，但是你的底层是以一个这种持久化的append-only的日志或者流的存储，作为分布式存储的一个支撑。

　　在解释这个事情之前，我大概介绍一下这个项目。这个项目是在2012年雅虎内部启动，然后经过了无数的迭代以后，在2016年9月把它贡献、开源出来。在开源不到一年之后，去年6月份，把它捐献给Apache软件基金会，今年的9月它正式成为顶级项目。在雅虎的Github上我们做了22个releases，然后把Pulsar捐献给软件基金会之后不到一年的时间，我们做了9个发布，基本上是不到一个半月有一次发布，目前是相对比较活跃的一个项目。

　　Pulsar与传统消息系统的不同

　　那我说了那么多，它跟传统的消息系统不同的地方是什么?首先是因为是消息系统，那不可避免地要跟传统的消息系统做对比。它在应用层面上其实是做了一个数据消费模型的统一，既支持传统的队列，也支持高性能的流的处理。这是从API的角度来说。但我们其实更关注的是分布式存储，它跟传统的消息系统不一样的地方是，传统的消息系统其实是面对消息数据去做的，所以它其实没所谓存储的概念。但是在Pulsar里面，我们其实是把存储跟计算分离，但计算更多的是强调messaging的那一块。

　　我们把这两个分离了以后，同时把传统消息中间件使用的一个物理分区的模型，变成了一个更多分布式系统用的分片模型，那这样的话可以打造出一个既有实时消息系统的streaming的一个API，然后你又能够有一层是可提供无限存储的一个存储系统。

　　灵活统一的消息模型：队列+流

　　我简单说一下队列加流的模型，基本上在流计算里面都不可避免要用消息中间件，那消息中间件无外乎就是生产者、消费者，然后中间加一个topic，或者是consumer group和subscription这样的概念。

　　不一样的地方是，像Kafka这样的一个消息中间件，它更多的是面向流去做设计的。像传统的ACTIVE MQ以及阿里的RocketMQ，更多的是面向队列去做设计，这时候Pulsar其实是在这上面做了一个统一。统一的意思是，我的生产者都往一个地方去发消息，这个消息的载体叫topic，但是我允许在topic上有不同的订阅模式。所谓的订阅模式，它处理的场景是不一样的，可以是顺序消费的streaming的模式，可以是共享消费的队列模式。

（编辑：温州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!