HBase之Rowkey设计总结及方舟实战篇

  • 时间:
  • 浏览:1
  • 来源:uu快3下载网址_uu快3IOS下载_电脑版

2、只按照event_id查询

2. Rowkey的排序原则

三、方舟HBase Rowkey设计实战

此外易观方舟也使用HBase做用户画像的标签存储方案,存储每个app的用户的人口学属性和商业属性等标签信息,不可能 其设计的更为错综复杂,后续会另起篇幅完整版展开。

二、Rowkey设计原则

其一是HBase的持久化文件HFile是按照KeyValue存储的,不可能 Rowkey过长比如800个字节,800万列数据光Rowkey就要占用800*800万=80亿个字节,将近1G数据,这会极大影响HFile的存储传输效率

3、按照event_id和date查询

结合易观方舟使用HBase作为事件(事件指的的终端在APP中居于的行为,比如登录、下单等等统称事件(event))的临时存储(HBase只存储了最近10分钟的热数据)来举例:

1、全表scan

在实际的设计中亲戚朋友 不可能 更多的是结合多种设计法律法律依据来实现Rowkey的最优化设计,比如设计订单具体具体情况时使用:Rowkey: reverse(order_id) + (Long.MAX_VALUE – timestamp),然后设计的好处一是通过reverse订单号出理 Region热点,二是都时需按时间倒排显示。

95e6-abc003

其二是MemStore缓存累积数据到内存,不可能 Rowkey字段过长内存的有效利用率会降低,系统无法缓存更多的数据,这会降低检索传输效率

时需在设计上保证其唯一性。不可能 在HBase中数据存储是Key-Value形式,若HBase中同一表插入相同Rowkey,则然后的数据会被覆盖掉(不可能 表的version设置为1语句),太久务必保证Rowkey的唯一性

若然后一一一好有几个 字符作为不同分区的起止,里面有几个Rowkey数据会分布在一好有几个 region中。实际应用场景是当数据量这样大的然后,你你你这个设计会使得分区之间更加均衡。

然后设计的好处是:

亲戚朋友 设计的Rowkey应均匀的分布在各个HBase节点上。拿常见的时间戳举例,假如Rowkey是按系统时间戳的法律法律依据递增,Rowkey的第一累积不可能 是时间戳信息语句将造成所有新数据全是一一一好有几个 RegionServer上堆积的热点问提,也也不 通常说的Region热点问提, 热点居于在几滴 的client直接访问集中在个别RegionServer上(访问不可能 是读,写不可能 许多操作),原因分析分析单个RegionServer机器自身负载居于问题,引起性能下降甚至Region不可用,常见的是居于jvm full gc不可能 显示region too busy异常具体情况,当然这也会影响同一一一好有几个 RegionServer上的许多Region。

4、列族(Column Family)在表创建然后就要定义好

一、引言

Rowkey长度设计原则:Rowkey是一一一好有几个 二进制,Rowkey的长度被太久开发者建议说设计在10~80个字节,建议是越短越好。

ΩΩ3、Hash散列不可能 Mod

加Salt前的Rowkey:abc001、abc002、abc003

然后做的缺点是牺牲了Rowkey的有序性。

3. Rowkey的散列原则

都时需看多,加盐前的Rowkey默认会在第一一一好有几个 region中,加盐后的Rowkey数据会分布在一好有几个 region中,理论上出理 后的吞吐量应是然后的3倍。不可能 前缀是随机的,读那此数据时时需耗费更多的时间,太久Salt增加了写操作的吞吐量,不过缺点是一起增加了读操作的开销。

不可能 Rowkey是数字类型的,也都时需考虑Mod法律法律依据。

1、在HBase表中是通过Rowkey的字典序来进行数据排序的

ΩΩ2、Salt加盐

设计event事件的Rowkey为:两位随机数Salt + eventId + Date + kafka的Offset

之类将上述的原始Rowkey经过hash出理 ,此处亲戚朋友 采用md5散列算法取前4位做前缀,结果如下

四、总结

1.Rowkey的唯一原则

附:常用ASCII码表

4. Rowkey的长度原则

在做Rowkey设计时,请先考虑业务是读比写多、还是读比写少,HBase三种生活是为写优化的,即便是然后,也不 可能 会老是出先热点问提,而不可能 亲戚朋友 读比较多语句,除了考虑以上Rowkey设计原则外,还都时需考虑HBase的Coprocessor甚至elastic search结合的法律法律依据,无论哪种法律法律依据,都建议做实际业务场景下数据的压力测试以得到最优结果。

9bf0-abc001 (abc001在md5后是9bf049097142c168c38a94c626eddf3d,取前4位是9bf0

针对固定长度的Rowkey反转后存储,然后都时需使Rowkey中老是改变的累积装进最前面,都时需有效的随机Rowkey

ΩΩ1、Reverse反转

通常有3种法律法律依据来出理 你你你这个Region热点问提:

最后亲戚朋友 顺带提下HBase的表设计,HBase表设计通常都时需是宽表(wide table)模式,即一行包括太久列。同样的信息也都时需用高表(tall table)形式存储,通常高表的性能比宽表要高出 80%以上,太久推荐亲戚朋友 使用高表来完成表设计。表设计时,亲戚朋友 也应该要考虑HBase数据库的许多行态:

Salting是将每一一一好有几个 Rowkey加一一一好有几个 前缀,前缀使用许多随机字符,使得数据分散在多个不同的Region,达到Region负载均衡的目标。

不可能 HBase是通过Rowkey查询的,一般Rowkey上回会存许多比较关键的检索信息,亲戚朋友 时需提前想好数据具体时需怎么还可以查询,根据查询法律法律依据进行数据存储格式的设计,要出理 做全表扫描,不可能 传输效率很重低。

比如在一一一好有几个 有一一一好有几个 Region(注:以 [ ,a)、[a,b)、[b,c)、[c, )为Region起至)的HBase表中,

3、原子性只在行内保证,HBase不支持跨行事务

时需指出的是不仅Rowkey的长度是越短越好,也不 列族名、列名等尽量使用短名字,不可能 HBase属于列式数据库,那此名字全是会写入到HBase的持久化文件HFile中去,过长的Rowkey、列族、列名回会原因分析分析整体的存储量成倍增加。

Hash散列来替代随机Salt前缀的好处是能让一一一好有几个 给定的行有相同的前缀,这在分散了Region负载的一起,使读操作也也能推断。选者性Hash(比如md5后取前4位做前缀)能让客户端重建完整版的RowKey,都时需使用get操作直接get我太久 的行。

Rowkey设计应遵循以下原则:

Rowkey排序回会先比对一一一好有几个 Rowkey的第一一一好有几个 字节,不可能 相同,也不 会比对第一好有几个 字节,依次类推... 对比到第X个字节时,不可能 超出了其中一一一好有几个 Rowkey的长度,短的Rowkey排在前面。

5. 列族中的列标识(Column Qualifier)都时需在表创建完然后动态插入数据时去掉

HBase的Rowkey是按照ASCII有序设计的,亲戚朋友 在设计Rowkey时需充分利用这点。比如视频网站上对影片《泰坦尼克号》的弹幕信息,你你你这个弹幕是按照时间倒排序展示视频里,你你你这个然后亲戚朋友 设计的Rowkey要和时间顺序相关。都时需使用"Long.MAX_VALUE - 弹幕发表时间"的 long 值作为 Rowkey 的前缀

在你你你这个具体情况下,亲戚朋友 仍然都时需将全表数据切分成n份并发查询,从而实现查询的实时响应。

亲戚朋友 分别去掉 a、b、c前缀,加Salt后Rowkey为:a-abc001、b-abc002、c-abc003

设计加盐的目的是为了增加查询的并发性,假如Salt的范围是0~n,那亲戚朋友 在查询的然后,都时需将数据分为n个split一起做scan操作。经过亲戚朋友 的多次测试验证,增加并发度也能将整体的查询传输效率提升5~20倍以上。然后的eventId和Date是用来做范围Scan使用的。在亲戚朋友 的查询场景中,大累积全是指定了eventId的,也不 亲戚朋友 把eventId装进了第一好有几个 位置上,一起呢,eventId的取值有几一好有几个 ,通过Salt + eventId的法律法律依据都时需保证我太久 形成热点。在单机部署版本中,HBase会存储所有的event数据,太久亲戚朋友 把date装进rowkey的第一一一好有几个 位置上以实现按date做scan,批量Scan性能甚至都时需做到毫秒级返回。

假如有一好有几个 Rowkey:"012", "0", "123", "234", "3",按ASCII字典排序后的结果为:"0", "012", "123", "234", "3"。(注:文末附常用ASCII码表)

2、所有存储在HBase表中的数据全是二进制的字节

反转Rowkey的例子通常以手机举例,都时需将手机号反转后的字符串作为Rowkey,然后的就出理 了以手机号那样比较固定开头(137x、15x等)原因分析分析热点问提,

HBase不可能 其存储和读写的高性能,在OLAP即深冬析中这样发挥重要的作用,在易观精细化运营产品--易观方舟全是广泛的应用。作为Nosql数据库的一员,HBase查询也能通过其Rowkey来查询(Rowkey用来表示唯一一行记录),Rowkey设计的优劣直接影响读写性能。HBase中的数据是按照Rowkey的ASCII字典顺序进行全局排序的,有伙伴不可能 对ASCII字典序印象居于问题深刻,下面举例说明:

原因分析分析有两点:

然后的rowkey设计也能很好的支持如下有几个查询场景:

7006-abc002