整套大数据学习资料(视频+笔记)百度网盘无门槛下载:http://www.edu360.cn/news/content?id=3377

13.6.3 实例:HBase 在 Streamy.com 的使用

hadoop 花牛 24℃ 0评论

Streamy.com是一个实时新闻聚合器和社会化分享平台。它有很多功能特 性。我们最早是在PostgreSQL上开始的,实现很复杂。PostgreSQL是一个 很棒的产品,社区支持很好,代码很漂亮。我们尝试了教材中所有可以在扩展时提速的技巧,甚至为了适应我们的应用需求而修改了 PostgreSQL。 一开始,我们利用了 RDBMS的所有优点。但是,我们逐渐一一放弃了这 些特性。最后,所有的团队都成了 DBA(需要在开发的同时考虑管理任务)。

我们的确解决了碰到的很多问题,但是有两个问题最终迫使我们必须寻求 RDBMS以外的解决办法。

Streamy从几千个RSS源爬取数据并对其中的上亿个信息项进行聚合。除了 必须存储这些信息项以外,我们应用中有一个复杂的查询需要从一个源的 集合中读取按时间排序的列表。在极端情况下,在单个査询中会牵涉数千 个源及其所有的信息项。

1. 超大规模的信息项表

一开始,只有一个信息项表,但大量的二级索引导致插入和更新非常慢。 我们开始把数据项分成几个一对一链接的表来存储其他信息,通过这种方 式把静态字段和动态字段区分开,根据字段査询方式来对字段分组,并据此进行反规范化。即使做了这些修改,单独的各个更新操作也需要重写整 个记录,所以要跟踪信息项的统计信息就很难做到可扩展。重写记录、更 新索引都是RDBMS的固有特性,它们是不能去除的。我们对表进行了分区,由于有时间属性可以作为自然分区的属性,所以这本身并不困难。但 应用的复杂性还是很快超出我们能够控制的范围。我们需要另外一种解决 办法!

2. 超大规模的排序合并

对按时间进行排序的列表进行“排序合并sort merge)Web 2.0应用中常 见的操作。相应的SQL査询示例可能如下所示:

SELECT id, stamp, type FROM streams
WHERE type IN ('typel','type2','type3'type4',...,'typeN')
ORDER BY stamp DESC LIMIT 10 OFFSET 0;


假设idstreams上的主键,在stamptype上有二级索引RDBMS 的査询规划器会像下面这样处理査询:

MERGE (
SELECT id, stamp, type FROM streams
WHERE type = 'typel' ORDER BY stamp DESC,
...,
SELECT id, stamp, type FROM streams
WHERE type = 'typeN' ORDER BY stamp DESC 
)ORDER BY stamp DESC LIMIT 10 OFFSET 0;

这里的问题是我们只要最前面的10个ID。但査询规划器实际会物化整个合并操作,然后在再最后限定返回结果。简单地对每个type使用堆排序(heap sort)让你可以在有10个结果以后就进行“提早过滤”(early out)。在我们的 应用中,每个type可以有数万个ID,因此物化整个列表再进行排序极其 缓慢,而且没有必要。事实上,我们进一步写了一个定制的PL/Python脚本,用一系列的査询来进行堆排序。査询如下:

SELECT id, stamp, type FROM streams 
WHERE type = 'typeN'
ORDER BY stamp DESC LIMIT 1 OFFSET 0;

如果从typeN中获得了结果(在堆中第二个最近的项),我们继续执行下面的查询:

SELECT id, stamp, type FROM streams 
WHERE type = 'typeN'
ORDER BY stamp DESC LIMIT 1 OFFSET 0;

在几乎所有情况下,这都胜于直接用SQL实现和采用査询规划器的策略。 在SQL最差的执行情况下,我们采用Python过程的方法比它们要快一个数 量级。我们发现,要想满足需求,需要不停尝试优于査询规划器的方法。

在这里,我们再一次觉得需要有其他解决办法。

3. 有了 HBase以后的日子

我们的基于RDBMS的系统始终能够正确地满足我们的需求:问题出在可扩展性上。如果重点关注扩展和性能问题而非正确性,最终少不了千方百计地找出捷径,并针对问题进行定制优化。一旦为了数据的问题开始实现 自己的解决方案,RDBMS的开销和复杂性就成为障碍,逻辑抽象和存储层的独立性与ACID要求会成为巨大的屏障,它们成为在开发可扩展系统时 无法承受的负担。HBase只是一个分布式、面向列、支持排序映射的存储系统。它唯一进行抽象的部分就是分布式处理,而这正是我们不想自己面对的。另一方面,我们的业务逻辑(business logic)是高度定制化和优化的。HBase并不试图解决我们的所有问题,这些部分我们自己能够处理得更好。我们只依靠HBase来解决存储的扩展,而不是业务逻辑。能够把精力集中在我们的应用和业务逻辑,而不需要关心数据的扩展问题,使我们完全得到了解放。

我们目前已经有包含数亿数据行和数万列的表。能够存储这样的数据让人感到兴奋,而不是恐惧。

转载请注明:全栈大数据 » 13.6.3 实例:HBase 在 Streamy.com 的使用

喜欢 (0)or分享 (0)
发表我的评论
取消评论

表情

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址