你好,游客 登录 注册 搜索
背景:
阅读新闻

实时计算和数据转换,为何赌球网在线Yelp弃用Storm和Heron,自建流处理器PaaStorm?

[日期:2017-01-19] 来源:网络整理  作者: [字体: ]

流

作者:Matt K  译者:足下

美中不足

在2010年时,Yelp开源了一个名叫MRJob的框架,是用来在AWS基础设施上运行大MapReduce Job的。Yelp的工程师们用MRJob实现了很多功能,从广告推送到翻译,比比皆是。事实证明,MRJob是一个非常强大的工具,可以在我们当时丰富的数据集合上完成计算和聚集操作。

不幸的是,随着使用MRJob的服务数量巨增,运行和调度任务开始变得越来越复杂。由于很多任务都是要依赖上游任务的,所以就要好好地安排整个系统的拓扑。MapReduce任务并不是用于实时处理的,所以任务的拓扑要每天调度一次。更糟的是,万一上游的任务失败了,下游的也会失败,最终会输出错误的结果。因此就要有非常专业的能力来判断应该从哪个任务开始、以什么顺序重新运行,最终输出正确的结果。

爱思考的人就会问了:我们有没有什么办法来更高效地完成计算和转换任务呢?我们还想支持一个复杂的数据流中不同数据转换操作之间的依赖关系,尤其是要能优雅地处理模式改变及上游的故障。我们还希望系统能实时或者近实时地运行。这样,系统就可以用于业务分析及指标监控。换句话说,我们需要的是一个流处理器。

Storm之类现成的计算系统本来也是非常不错的。但由于许多主流的流处理框架对Python的支持都不太好,因此要把我们的其他后台程序与Storm或者其他现有流处理系统结合起来就会非常痛苦。

我们最先用的是Pyleus,这是一个让开发者可以用Python处理和转换数据的开源框架。Pyleus的底层仍然是使用Storm的,构建耗时比较久,运行得也慢。Twitter Heron宣布开源后,我们发现我们也碰上了许多他们碰到过的问题。Yelp自己有功能非常强大的用于部署服务的Platform-as-a-Service平台PaasTA,相比之下我们更喜欢使用PaaSTA,而不是运行专用的Storm集群。

从2015年7月开始,有一帮工程师们开始研发一种新型的数据仓库,也碰上了典型的扩展和性能问题。最开始时他们想用Pyleus来先清洗数据,再拷贝到Redshift上。后来他们意识到部署一整套Storm集群来运行些简单的Python逻辑实在太没必要了:用Yelp自己的运行服务的平台去部署一套基于Python的流处理器就足够了。我们的流处理器是基于Samza设计的,目的是提供一些简单的接口,用一种“处理消息”的方法来做数据转换。

工程师们在Hackathon 17上构建了运行在PyPy上的流处理器的原型,这样PassStorm就诞生了。

这名字中有什么含义?

PaaStorm的名字其实是PaaSTA和Storm的组合。那PaaStorm到底是干什么的呢?要回答这个问题,咱们先看看数据管道的基本架构:

架构

主要看看“Transformer”那一步,就会知道大多数存储在Kafka中的消息都并不能直接被导入目标系统。设想有一套Redshift集群是用来存储广告推送数据的。广告推送集群想存储的只是上游系统的某一个字段(比如某个业务的平均权重),否则它就要保存原始数据并对其进行聚合计算。如果Redhift广告推送集群要存储所有上游数据的话,就会浪费存储空间,导致系统性能降低。

在过去,各个服务都会写复杂的MapReduce任务,在把数据写到目标数据存储之前先进行数据处理。可是,这些MapReduce任务都碰到了上文所述的性能和扩展问题。数据管道给大家提供的好处之一是消费者程序可以拿到它所需要的数据的形式,不管上游数据本来是什么样。

减少示例代码

本来我们是可以让每个消费者程序自己按自己需要的方式做数据转换的。比如,广告推送系统可以自己写一个转换服务,从Kafka中的业务数据中提取出查看统计量,并自己维护这个转换服务的。这种办法最初工作得很好,但最终系统上规模时我们就碰上问题了。

我们想提供一个转换框架是基于以下考虑:

把Kafka作为消息总线

最初PaaStorm是一个Kafka-to-Kafka的转换框架,慢慢地才演进成也支持了其他类型的终端节点。把Kafka做为PaaStorm的终端节点简化了很多东西:每个对数据感兴趣的服务都可以注册到Topic上,关注任意转换过的数据或者原始数据,有新消息到来就处理就好了,完全不必在意是谁创建了这个Topic。转换过的数据按Kafka的保留策略持久化。因为Kafka是一个发布-订阅系统,下游系统也可以在任何它想的时候消费数据。

用Storm处理一切