HBase篇(1)-特性与应用场景

每日五分钟搞定大数据】系列,HBase第一篇

结束了Zookeeper篇, 接下来我们来说下Google三驾马车之一BigTable的开源实现:HBase,要讲的内容暂定如下:
1491039-20181018092505205-941940869.png

这是第一篇我们先不聊技术实现,只讨论特性和场景

hbase的特点

  • 千万级高并发
  • PB级存储
  • 非结构化存储
  • 动态列,稀疏列
  • 支持二级索引
  • 强一致性,可靠性,扩展性(CP系统,可用性做了一点让步)

场景

1. 写密集型应用,每天写入量巨大,而相对读数量较小的应用

2. 不需要复杂查询条件来查询数据的应用

使用rowkey,单条记录或者小范围的查询性能不错,大范围的查询由于分布式的原因,可能在性能上有点影响。

使用HBase的过滤器的话性能比较差。

3. 不需要关联的场景,HBase为NoSQL无法支持join

4. 可靠性要求高

master支持主备热切。

regionServer宕机,region会分配给在线的机器。

数据持久化在HDFS,默认3份,HDFS保证数据可靠性。

内存的数据若丢失可以通过Wal预写日志恢复。

5. 数据量较大,而且增长量无法预估的应用

HBase支持在线扩展,即使在一段时间内数据量呈井喷式增长,也可以通过HBase横向扩展来满足功能。

应用

  • 对象存储系统

HBase MOB(Medium Object Storage),中等对象存储是hbase-2.0.0版本引入的新特性,用于解决hbase存储中等文件(0.1m~10m)性能差的问题。这个特性适合将图片、文档、PDF、小视频存储到Hbase中。

  • OLAP的存储

Kylin的底层用的是HBase的存储,看中的是它的高并发和海量存储能力。kylin构建cube的过程会产生大量的预聚合中间数据,数据膨胀率高,对数据库的存储能力有很高要求。

Phoenix是构建在HBase上的一个SQL引擎,通过phoenix可以直接调用JDBC接口操作Hbase,虽然有upsert操作,但是更多的是用在OLAP场景,缺点是非常不灵活。

  • 时序型数据

openTsDB应用,记录以及展示指标在各个时间点的数值,一般用于监控的场景,是HBase上层的一个应用。

  • 用户画像系统

动态列,稀疏列的特性。用于描述用户特征的维度数是不定的且可能会动态增长的(比如爱好,性别,住址等);不是每个特征维度都会有数据

  • 消息/订单系统

强一致性,良好的读性能,至于hbase如何保证强一致性的后面的文章会详细说明。

  • feed流系统存储

见下面的一波分析。

feed流系统

前几天据说支持八个一线明星并发出轨的微博挂了....蹭个热度,上面的系统我就不一一说了,大家应该知道微博是典型的feed流系统,那我们来详细说下feed流系统。

什么是feed流系统

feed流系统有三个概念,如图(来自云栖社区)
1491039-20181018092533722-1928271107.png

feed:

一个终端发布的一些内容

  • 可以是用户发布的动态消息
  • 可以是广告系统推荐的广告
  • 也可以是系统本身推荐的一些公告

比如你在微博发了条动态,那这条动态就是feed

feeds流;

feeds流就是系统实时推送的根据了一定规则排序的信息流

比如你刷了下微博,在你的首页出现了按时间排好序的一堆新消息,那这就是feed流

feeds订阅;

这个比较简单,就是你通过应用,微博,朋友圈这些,关注了某个人,那就是订阅了Ta的feeds

Feed流系统的存储

Feed流系统中需要存储的内容大致可以分为两部分,

  • 账号关系数据(比如关注列表)
  • Feed消息内容

其实有很多方案实现,但是这篇说的是HBase,那我们就说说如何用HBase实现。

关注列表

关注列表就不重点讨论了,数据特点是:列数量不定,量大,关系简单,有序,性能要求高,可靠性要求高。互相关注,单向关注这种场景用二级索引很好实现。

Feed消息

数据的特点:

1.读多写少,举个栗子,看我文章的人里面有多少人是暗中观察的,不评论不点赞自己也不发文章的,这样“暗中观察”的同学占总用户的比例是很大的。

2.数据模型简单,消息时间,消息体,发布人,订阅人,很少会有需要关联的场景

3.高并发,波峰波谷式访问,Feed流系统属于社交类系统,热点来得快去得也快。

4.持久化可靠性存储
每个人发布的内容都是需要永久存储且不能丢失的,存储量会随着时间的推移会越来越大。需要系统有很强的扩展性和可靠性。

5.消息排序,HBase的rowKey按字典序排序正好适用于这个场景。比如rowkey可以设计成这样

<userId><timestamp><feedId>

这样获取某个用户发布的消息时就可以指定时间范围来scan,性能不错的同时还能保证时间线正确。

总结

从上面feed数据的特性可以看出,HBase是适合做feed流系统的,实际生产中也确实有feed流应用是用HBase来做的存储,

我这里只是一个初步的讨论,实际上还是有很多细节要考虑的,光靠HBase来实现肯定是远远不够的,它也有很多不适用的地方,要靠开发者自己去判断,

没有最好的只有最合适的,希望对大家有帮助。

1491039-20181018092547757-1751170065.jpg

转载于:https://www.cnblogs.com/uncledata/p/9808636.html

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值