基于 HBase 构建可伸缩的分布式事务队列

一个实时流处理框架通常需要两个基础架构:处理器和队列。处理器从队列中读取事件,执行用户的处理代码,如果要继续对结果进行处理,处理器还会把事件写到另外一个队列。队列由框架提供并管理。队列做为处理器之间的缓冲,传输数据和事件,这样处理器可以单独操作和扩展。例如,一个web 服务访问日志处理应用,可能是这样的:

queue_perf

框架之间的主要区别在于队列语义,通常不同之处有以下几点:

调度保障机制: 至少一次,至多一次,只有一次。

容灾机制: 失败对用户和自动恢复是透明的。

可用性: 数据在出现错误后可以保存并重启。

可扩展性:产品/用户增加时的局限性。

性能Performance: 队列操作的吞吐量和延迟。

我们想在开源的 Cask Data Application Platform (CDAP)上提供一个动态可扩展,强一致性并且有一次性交易机制的实时流处理框架,在这个强大的机制保护下,开发者可以自由操作任何形式的数据操作而不用担心不一致性,潜在的返工和失败。它可以帮助开发者在没有分布式系统背景的情况下建立他们的大数据应用。此外,如果需要可以关闭这种强大的保护机制换取高性能。它总是比其他方式更容易使用。

我们想在开源的 Cask Data Application Platform (CDAP)上提供一个动态可扩展,强一致性并且有一次性交易机制的实时流处理框架,在这个强大的机制保护下,开发者可以自由操作任何形式的数据操作而不用担心不一致性,潜在的返工和失败。它可以帮助开发者在没有分布式系统背景的情况下建立他们的大数据应用。此外,如果需要可以关闭这种强大的保护机制换取高性能。它总是比其他方式更容易使用。

可扩展队列

队列有两种基本操作:入队和出队。生产者将消息写到队头(入队),消费者从队尾读取数据(出队)。如果做为一个整体你添加更多生成者时的入队速度和添加更多消费者时的出队速度足够快,我们说这个队列是可扩展的。

理想状态下,扩展是线性的,这意味着两倍的生产者 /消费者,会产生两位速度的出队/入队,增长只受集群的规模限制。为了支持生产者的线性扩展,队列需要一个存储系统并且需要当前写入者的数量线性扩展。为了应对消费者的线性扩展,队列可以分区,例如一个消费者只处理队列中的一段数据。

队列扩展的另一个方面是它应该可以横向扩展。这意味着队列性能的上限可以通过增加集群结点的方式来提升。这是很重要的,它可以保证队列不受当前集群大小限制根据数据的增长而扩展。

分区的 HBase 队列

我们选择 Apache HBase 做为队列的存储层。它为存储强一致性,可横向扩展的行数据做了设计和优化。它的并发写操作性能非常好,并提供了有序扫描以支持分区消费者。我们使用 HBase Coprocessors 的高效扫描滤波和队列清洗。为了在队列上使用一次性语义,我们用 Tephra’s 为 HBase 提供传输支持。

生产者和消费者具有操作独立性。每个生产者通过 Hbase puts 批处理执行入队操作,消费者通过执行 Hbase Scans 执行出队操作。生产者和消费者的数量之间没有关联,他们可以分离。

此队列存在一个消费者组的概念。一个消费者组,是由相同的关键字划分的消费者集合,这样,每个发布到队列的事件,就会由此消费者组中的消费者去消费。使用消费者组,可以通过不同的关键字划分同一个队列,同时,也可以通过数据的操作性特点来拓展。按照上面访问日志分析的例子,生产者和消费者组可能看起来像这样:

queue_groups

对于Log Parser,这里有两个生产者在运行,它们并发的向队列写数据。在消费者这边,这里存在两个消费者组。 Unique User Counter组有两个消费者,使用UserID作为划分(队列的)关键字。Page View Counter组则有三个消费者,使用 PageID 作为划分(队列的)关键字。

队列行值格式

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/ab426e58db504dc720bbddbe972ea80e.html