精华内容
下载资源
问答
  • rowkey

    千次阅读 2018-06-02 10:03:53
    rowkey

    Row Key

    HBase中row key用来检索表中的记录,支持以下三种方式:


    • 通过单个row key访问:即按照某个row key键值进行get操作;
    • 通过row key的range进行scan:即通过设置startRowKey和endRowKey,在这个范围内进行扫描;
    • 全表扫描:即直接扫描整张表中所有行记录。

    在HBase中,row key可以是任意字符串,最大长度64KB,实际应用中一般为10~100bytes,存为byte[]字节数组,一般设计成定长的。

    row key是按照字典序存储

      设计row key时,要充分利用这个排序特点,将经常一起读取的数据存储到一块,将最近可能会被访问的数据放在一块。

      举个例子:如果最近写入HBase表中的数据是最可能被访问的,可以考虑将时间戳作为row key的一部分,由于是字典序排序,所以可以使用Long.MAX_VALUE - timestamp作为row key,这样能保证新写入的数据在读取时可以被快速命中。

    Rowkey:

      1、 大小越小越好

      2、 值根据功能需求决定

      3、 Row最好有散列原则。

        a) 取反

        b) Hash

    展开全文
  • 大白话彻底搞懂HBase RowKey详细设计

    万次阅读 多人点赞 2020-05-08 14:18:42
    本文从RowKey的原理,可能出现的问题,如何优化及各个优化措施对应的缺点和适用的场景,设计原则等角度对RowKey进行了详细全面的解析,相信一定能对你有所帮助。

    写在前面:我是「且听风吟」,目前是某上市游戏公司的大数据开发工程师,热爱大数据开源技术,喜欢分享自己的所学所悟,现阶段正在从头梳理大数据体系的知识,以后将会把时间重点放在Spark和Flink上面。

    如果你也对大数据感兴趣,希望在这个行业一展拳脚。欢迎关注我,我们一起努力,一起学习。博客地址:https://ropledata.blog.csdn.net

    博客的名字来源于:且听风吟,静待花开。也符合我对技术的看法,想要真正掌握一门技术就需要厚积薄发的毅力,同时保持乐观的心态。

    你只管努力,剩下的交给时间!

    图片

    一、前言

    RowKey作为HBase的核心知识点,RowKey设计会影响到数据在HBase中的分布,还会影响我们查询效率,所以RowKey的设计质量决定了HBase的质量。是咱们大数据从业者必知必会的,自然也是面试必问的考察点。

    那么rowkey到底是什么呢?原理是什么呢?怎么设计RowKey呢?使用场景是怎样的呢?有哪些设计原则呢?又如何进行优化呢?

    下面就让我们带着这些问题,一起探索RowKey的世界!
    探索RowKey

    二、RowKey的概念

    RowKey从字面意思来看是行键的意思,咱们知道HBase可以理解为一个nosql(not only sql)数据库,既然是数据库,那么咱们日常使用最多的就是增删改查(curd)。其实在增删改查的过程中RowKey就充当了主键的作用,它和众多的nosql数据库一样,可以唯一的标识一行记录。

    RowKey行键 (RowKey)可以是任意字符串,在HBase内部,RowKey保存为字节数组。存储时,数据按照RowKey的字典序(byte order)排序存储。设计RowKey时,要充分利用排序存储这个特性,将经常一起读取的行存储放到一起。

    RowKey的特点小结如下:

    1. RowKey类似于主键,可以唯一的标识一行记录;
    2. 由于数据按照RowKey的字典序(byte order)排序存储,因此HBase中的数据永远都是有序的。
    3. RowKey可以由用户自己指定,只要保证这个字符串不重复就可以了。

    知识点补充:在HBase中检索数据时使用到RowKey的一共有三种方式:

    • get:通过指定单个RowKey来获取对应的唯一一条记录;
    • like:通过RowKey的range来进行匹配;
    • scan:通过设置startRow和stopRow参数来进行范围匹配(注意:如果不设置就是全表扫描)。


    三、RowKey的作用

    要了解RowKey的作用,首先我们需要知道在HBase中,一个Region就相当于一个数据分片,每个Region都有StartRowKey和StopRowKey(用来表示 Region存储的RowKey的范围),HBase表里面的数据是按照RowKey来分散存储到不同的Region里面的。

    为了避免热点现象咱们需要将数据记录均衡的分散到不同的Region中去,因此需要RowKey满足这种散列的特点。此外,在数据读写过程中也是与RowKey密切相关的。RowKey的作用可以归纳如下:

    1. Hbase在读写数据时需要通过RowKey找到对应的Region;
    2. MemStore和HFile中的数据都是按照 RowKey 的字典序排序。

    那到底啥是热点现象呢?咱们接着分析!


    四、热点现象

    4.1、热点现象怎么产生

    我们知道HBase中的行是按照rowkey的字典顺序排序的,这种设计优化了 scan操作,可以将相关的行以及会被一起读取的行存取在临近位置,便于 scan读取。

    然而万事万物都有两面性,在咱们实际生产中,当大量请求访问HBase集群的一个或少数几个节点,造成少数RegionServer的读写请求过多,负载过大,而其他RegionServer负载却很小,这样就造成热点现象(吐槽:其实和数据倾斜类似,还整这么高大上的名字)。

    掌握了热点现象的概念,我们就应该知道大量的访问会使热点Region所在的主机负载过大,引起性能下降,甚至导致Region不可用。所以我们在向HBase中插入数据的时候,应优化RowKey的设计,使数据被写入集群的多个region,而不是一个。尽量均衡地把记录分散到不同的Region中去,平衡每个Region的压力。

    其实RowKey的优化主要就是在解决怎么避免热点现象。那么有哪些避免热点现象的方法呢?各有什么缺点?带着问题,接着往下看。

    4.2、如何避免热点现象(RowKey的优化)

    在日常使用中,主要有3个方法来避免热点现象,分别是反转,加盐和哈希。听起来很奇怪,下面咱们逐个举例详细分析:

    4.2.1、反转(Reversing)

    第一种咱们要分析的方法是反转,顾名思义它就是把固定长度或者数字格式的 rowkey进行反转,反转分为一般数据反转和时间戳反转,其中以时间戳反转较常见。

    适用场景:

    比如咱们初步设计出的RowKey在数据分布上不均匀,但RowKey尾部的数据却呈现出了良好的随机性(注意:随机性强代表经常改变,没意义,但分布较好),此时,可以考虑将RowKey的信息翻转,或者直接将尾部的bytes提前到RowKey的开头。反转可以有效的使RowKey随机分布,但是反转后有序性肯定就得不到保障了,因此它牺牲了RowKey的有序性。

    缺点:

    利于Get操作,但不利于Scan操作,因为数据在原RowKey上的自然顺序已经被打乱。

    举例:

    比如咱们通常会有需要快速获取数据的最近版本的数据处理需求,这时候就需要把时间戳作为RowKey来查询了,但是时间戳正常情况下是这样的:

    1588610367373
    1588610367396
    

    前面这部分是相同的,在查询的时候就容易造成热点现象,因此需要使用时间戳反转的方式来处理。实际生产中可以用 Long.Max_Value - timestamp 追加到 key 的末尾,比如 [key][reverse_timestamp], [key] 的最新值可以通过 scan [key]获得[key]的第一条记录,因为HBase中RowKey是有序的,所以第一条记录是最后录入的数据。

    常见的场景,比如需要保存一个用户的操作记录,就可以按照操作时间倒序排序,在设计rowkey的时候,可以这样设计 [反转后的userId][Long.Max_Value - timestamp],在查询用户的所有操作记录数据的时候,直接指定反转后的userId,startRow 是 [反转后的userId][000000000000],stopRow 是 [反转后的userId][Long.Max_Value - timestamp]。如果需要查询某段时间的操作记录,startRow 是[反转后的userId[Long.Max_Value - 起始时间], stopRow 是[反转后的userId][Long.Max_Value - 结束时间]

    4.2.2、加盐(Salting)

    第二种咱们要介绍的方法是加盐,玩过密码学的可能知道密码学里也有加盐的方法,但是咱们RowKey的加盐和密码学不一样,它的原理是在原RowKey的前面添加固定长度的随机数,也就是给RowKey分配一个随机前缀使它和之前的RowKey的开头不同。

    适用场景:

    比如咱们设计的RowKey是有意义的,但是数据类似,随机性比较低,反转也没法保证随机性,这样就没法根据RowKey分配到不同的Region里,这时候就可以使用加盐的方式了。

    需要注意随机数要能保障数据在所有Regions间的负载均衡,也就是说分配的随机前缀的种类数量应该和你想把数据分散到的那些region的数量一致。只有这样,加盐之后的rowkey才会根据随机生成的前缀分散到各个region中,避免了热点现象。

    缺点:

    大白话来理解就是加了盐就尝不到原有的味道了。因为添加的是随机数,添加后如果还基于原RowKey查询,就无法知道随机数是什么,那样在查询的时候就需要去各个可能的Region中查找,同时加盐对于读取是利空的。并且加盐这种方式增加了读写时的吞吐量。

    4.2.3、哈希(Hashing)

    最后介绍大家最熟悉的哈希方法,不管是学的啥技术,都会涉及到哈希,也都大同小异,比较简单。

    这里的哈希是基于RowKey的完整或部分数据进行Hash,而后将哈希后的值完整替换或部分替换原RowKey的前缀部分。这里说的hash常用的有MD5、sha1、sha256 或 sha512 等算法。

    适用场景:

    其实哈希和加盐的适用场景类似,但是由于加盐方法的前缀是随机数,用原rowkey查询时不方便,因此出现了哈希方法,由于哈希是使用各种常见的算法来计算出的前缀,因此哈希既可以使负载分散到整个集群,又可以轻松读取数据。

    缺点:

    与反转类似,哈希也打乱了RowKey的自然顺序,因此也不利于Scan。


    五、RowKey设计原则

    通过前面的分析我们应该知道了HBase中RowKey设计的重要性了,为了帮助我们设计出完美的RowKey,HBase提出了RowKey的设计原则,一共有四点:长度原则、唯一原则、排序原则,散列原则

    RowKey在字段的选择上,需要遵循的最基本原则是唯一原则,因为RowKey必须能够唯一的识别一行数据。无论应用的负载特点是什么样,RowKey字段都应该首先考虑最高频的查询场景。数据库通常都是以如何高效的读取和消费数据为目的,而不仅仅是数据存储本身。然后再结合具体的负载特点,再对选取的RowKey字段值进行改造,结合RowKey的优化,也就是避免热点现象的那些方法来优化就可以了。

    5.1、长度原则

    RowKey本质上是一个二进制码的流,可以是任意字符串,最大长度为64kb,实际应用中一般为10-100byte,以byte[]数组形式保存,一般设计成定长。官方建议越短越好,不要超过16个字节,原因可以概括为如下几点:

    1. **影响HFile的存储效率:**HBase里的数据在持久化文件HFile中其实是按照Key-Value对形式存储的。这时候如果RowKey很长,比如达到了200byte,那么仅仅1000w行的记录,只考虑RowKey就需占用近2GB的空间,极大的影响了HFile的存储效率。
    2. **降低检索效率:**由于MemStore会缓存部分数据到内存中,如果RowKey比较长,就会导致内存的有效利用率降低,也就不能缓存更多的数据,从而降低检索效率。
    3. **16字节是64位操作系统的最佳选择:**64位系统,内存8字节对齐,控制在16字节,8字节的整数倍利用了操作系统的最佳特性。

    5.2、唯一原则

    其实唯一原则咱们可以结合HashMap的源码设计或者主键的概念来理解,由于RowKey用来唯一标识一行记录,所以必须在设计上保证RowKey的唯一性。

    需要注意:由于HBase中数据存储的格式是Key-Value对格式,所以如果向HBase中同一张表插入相同RowKey的数据,则原先存在的数据会被新的数据给覆盖掉(和HashMap效果相同)。

    5.3、排序原则

    HBase会把RowKey按照ASCII进行自然有序排序,所以反过来我们在设计RowKey的时候可以根据这个特点来设计完美的RowKey,好好的利用这个特性就是排序原则。

    5.4、散列原则

    散列原则用大白话来讲就是咱们设计出的RowKey需要能够均匀的分布到各个RegionServer上。

    比如设计RowKey的时候,当Rowkey 是按时间戳的方式递增,就不要将时间放在二进制码的前面,可以将 Rowkey 的高位作为散列字段,由程序循环生成,可以在低位放时间字段,这样就可以提高数据均衡分布在每个Regionserver实现负载均衡的几率。

    结合前面分析的热点现象的起因,思考:

    如果没有散列字段,首字段只有时间信息,那就会出现所有新数据都在一个 RegionServer上堆积的热点现象,这样在做数据检索的时候负载将会集中在个别RegionServer上,不分散,就会降低查询效率。

    HBase里的RowKey是按照字典序存储,因此在设计RowKey时,咱们要充分利用这个排序特点,将经常一起读取的数据存储到一块,将最近可能会被访问的数据放在一块。如果最近写入HBase表中的数据是最可能被访问的,可以考虑将时间戳作为row key的一部分,由于是字典序排序,所以可以使用Long.MAX_VALUE - timestamp作为row key,这样能保证新写入的数据在读取时可以被快速找到。


    六、总结

    看到这里RowKey的各个方面应该都已经搞懂了,本文从RowKey的原理,可能出现的问题,如何优化及各个优化措施对应的缺点和适用的场景,设计原则等角度对RowKey进行了详细全面的解析,相信一定能对你有所帮助。

    如果您对我的文章感兴趣,欢迎关注点赞收藏,如果您有疑惑或发现文中有不对的地方,还请不吝赐教,非常感谢!!

    展开全文
  • Rowkey设计

    2021-09-22 08:55:08
    HBase是根据Rowkey来进行检索的,系统通过找到某个Rowkey (或者某个 Rowkey 范围)所在的Region,然后将查询数据的请求路由到该Region获取数据。HBase的检索支持3种方式: (1) 通过单个Rowkey访问,即按照某个...

    HBase是根据Rowkey来进行检索的,系统通过找到某个Rowkey (或者某个 Rowkey 范围)所在的Region,然后将查询数据的请求路由到该Region获取数据。HBase的检索支持3种方式:

    (1) 通过单个Rowkey访问,即按照某个Rowkey键值进行get操作,这样获取唯一一条记录;

    (2) 通过Rowkey的range进行scan,即通过设置startRowKey和endRowKey,在这个范围内进行扫描。这样可以按指定的条件获取一批记录;

    (3) 全表扫描,即直接扫描整张表中所有行记录。

    HBASE按单个Rowkey检索的效率是很高的,耗时在1毫秒以下,每秒钟可获取1000~2000条记录,不过非key列的查询很慢。

    目前操作系统是都是64位系统,内存8字节对齐。控制在16个字节,8字节的整数倍利用操作系统的最佳特性。

    (2)MemStore将缓存部分数据到内存,如果Rowkey字段过长内存的有效利用率会降低,系统将无法缓存更多的数据,这会降低检索效率。因此Rowkey的字节长度越短越好。

    (3)目前操作系统是都是64位系统,内存8字节对齐。控制在16个字节,8字节的整数倍利用操作系统的最佳特性。

    如果没有散列字段,首字段直接是时间信息将产生所有新数据都在一个 RegionServer上堆积的热点现象,这样在做数据检索的时候负载将会集中在个别RegionServer,降低查询效率。

    通过巧妙的RowKey设计使我们批量获取记录集合中的元素挨在一起(应该在同一个Region下),可以在遍历结果时获得很好的性能。

    rowkey唯一原则:
    必须在设计上保证其唯一性,rowkey是按照字典顺序排序存储的,因此,设计rowkey的时候,要充分利用这个排序的特点,将经常读取的数据存储到一块,将最近可能会被访问的数据放到一块。

    加盐
    这里所说的加盐不是密码学中的加盐,而是在rowkey的前面增加随机数,具体就是给rowkey分配一个随机前缀以使得它和之前的rowkey的开头不同。分配的前缀种类数量应该和你想使用数据分散到不同的region的数量一致。加盐之后的rowkey就会根据随机生成的前缀分散到各个region上,以避免热点。
    哈希
    哈希会使同一行永远用一个前缀加盐。哈希也可以使负载分散到整个集群,但是读却是可以预测的。使用确定的哈希可以让客户端重构完整的rowkey,可以使用get操作准确获取某一个行数据
    反转
    第三种防止热点的方法时反转固定长度或者数字格式的rowkey。这样可以使得rowkey中经常改变的部分(最没有意义的部分)放在前面。这样可以有效的随机rowkey,但是牺牲了rowkey的有序性。

    展开全文
  • Rowkey设计指南

    2019-07-23 16:50:09
    为什么Rowkey这么重要 RowKey 到底是什么 RowKey的作用 Rowkey对查询的影响 Rowkey对Region划分影响 RowKey设计技巧 避免热点的方法 - Salting 避免热点的方法 - Hashing 避免热点的方法 - Reversing ...

    目录

     

    为什么Rowkey这么重要

    RowKey 到底是什么

    RowKey的作用

    Rowkey对查询的影响

    Rowkey对Region划分影响

    RowKey设计技巧

    避免热点的方法 - Salting

    避免热点的方法 - Hashing

    避免热点的方法 - Reversing

    RowKey的长度

    RowKey 设计案例剖析

    交易类表 Rowkey 设计

    金融风控 Rowkey 设计

    车联网 Rowkey 设计

    查询最近的数据

    OpenTSDB 的 Rowkey 设计


    为什么Rowkey这么重要

    RowKey 到底是什么

    HBase Rowkey 设计指南

    我们常说看一张 HBase 表设计的好不好,就看它的 RowKey 设计的好不好。可见 RowKey 在 HBase 中的地位。那么 RowKey 到底是什么?RowKey 的特点如下:

    • 类似于 MySQL、Oracle中的主键,用于标示唯一的行;
    • 完全是由用户指定的一串不重复的字符串;
    • HBase 中的数据永远是根据 Rowkey 的字典排序来排序的。

    RowKey的作用

    • 读写数据时通过 RowKey 找到对应的 Region;
    • MemStore 中的数据按 RowKey 字典顺序排序;
    • HFile 中的数据按 RowKey 字典顺序排序。

    Rowkey对查询的影响

    如果我们的 RowKey 设计为 uid+phone+name,那么这种设计可以很好的支持以下的场景:

    • uid = 111 AND phone = 123 AND name = iteblog
    • uid = 111 AND phone = 123
    • uid = 111 AND phone = 12?
    • uid = 111

    难以支持的场景:

    • phone = 123 AND name = iteblog
    • phone = 123
    • name = iteblog

    Rowkey对Region划分影响

    HBase 表的数据是按照 Rowkey 来分散到不同 Region,不合理的 Rowkey 设计会导致热点问题。热点问题是大量的 Client 直接访问集群的一个或极少数个节点,而集群中的其他节点却处于相对空闲状态。

    HBase Rowkey 设计指南
    如果想及时了解Spark、Hadoop或者Hbase相关的文章,欢迎关注微信公共帐号:iteblog_hadoop

    如上图,Region1 上的数据是 Region 2 的5倍,这样会导致 Region1 的访问频率比较高,进而影响这个 Region 所在机器的其他 Region。

    RowKey设计技巧

    我们如何避免上面说到的热点问题呢?这就是这章节谈到的三种方法。

    避免热点的方法 - Salting

    这里的加盐不是密码学中的加盐,而是在rowkey 的前面增加随机数。具体就是给 rowkey 分配一个随机前缀 以使得它和之前排序不同。分配的前缀种类数量应该和你想使数据分散到不同的 region 的数量一致。 如果你有一些 热点 rowkey 反复出现在其他分布均匀的 rwokey 中,加盐是很有用的。考虑下面的例子:它将写请求分散到多个 RegionServers,但是对读造成了一些负面影响。

    假如你有下列 rowkey,你表中每一个 region 对应字母表中每一个字母。 以 'a' 开头是同一个region, 'b'开头的是同一个region。在表中,所有以 'f'开头的都在同一个 region, 它们的 rowkey 像下面这样:

    foo0001

    foo0002

    foo0003

    foo0004

    现在,假如你需要将上面这个 region 分散到 4个 region。你可以用4个不同的盐:'a', 'b', 'c', 'd'.在这个方案下,每一个字母前缀都会在不同的 region 中。加盐之后,你有了下面的 rowkey:

    a-foo0003

    b-foo0001

    c-foo0004

    d-foo0002

    所以,你可以向4个不同的 region 写。理论上说,如果这四个 Region 存放在不同的机器上,经过加盐之后你将拥有之前4倍的吞吐量。

    现在,如果再增加一行,它将随机分配a,b,c,d中的一个作为前缀,并以一个现有行作为尾部结束:

    a-foo0003

    b-foo0001

    c-foo0003

    c-foo0004

    d-foo0002

    因为分配是随机的,所以如果你想要以字典序取回数据,你需要做更多工作。加盐这种方式增加了写时的吞吐量,但是当读时有了额外代价。

    避免热点的方法 - Hashing

    Hashing 的原理是计算 RowKey 的 hash 值,然后取 hash 的部分字符串和原来的 RowKey 进行拼接。这里说的 hash 包含 MD5、sha1、sha256或sha512等算法。比如我们有如下的 RowKey:

    foo0001

    foo0002

    foo0003

    foo0004

    我们使用 md5 计算这些 RowKey 的 hash 值,然后取前 6 位和原来的 RowKey 拼接得到新的 RowKey:

    95f18cfoo0001

    6ccc20foo0002

    b61d00foo0003

    1a7475foo0004

    优缺点:可以一定程度打散整个数据集,但是不利于 Scan;比如我们使用 md5 算法,来计算Rowkey的md5值,然后截取前几位的字符串。subString(MD5(设备ID), 0, x) + 设备ID,其中x一般取5或6。

    避免热点的方法 - Reversing

    Reversing 的原理是反转一段固定长度或者全部的键。比如我们有以下 URL ,并作为 RowKey:

    flink.iteblog.com

    www.iteblog.com

    carbondata.iteblog.com

    def.iteblog.com

    这些 URL 其实属于同一个域名,但是由于前面不一样,导致数据不在一起存放。我们可以对其进行反转,如下:

    moc.golbeti.knilf

    moc.golbeti.www

    moc.golbeti.atadnobrac

    moc.golbeti.fed

    经过这个之后,这些 URL 的数据就可以放一起了。

    RowKey的长度

    RowKey 可以是任意的字符串,最大长度64KB(因为 Rowlength 占2字节)。建议越短越好,原因如下:

    • 数据的持久化文件HFile中是按照KeyValue存储的,如果rowkey过长,比如超过100字节,1000w行数据,光rowkey就要占用100*1000w=10亿个字节,将近1G数据,这样会极大影响HFile的存储效率;
    • MemStore将缓存部分数据到内存,如果rowkey字段过长,内存的有效利用率就会降低,系统不能缓存更多的数据,这样会降低检索效率;
    • 目前操作系统都是64位系统,内存8字节对齐,控制在16个字节,8字节的整数倍利用了操作系统的最佳特性。

    RowKey 设计案例剖析

    交易类表 Rowkey 设计

    • 查询某个卖家某段时间内的交易记录
      sellerId + timestamp + orderId
    • 查询某个买家某段时间内的交易记录
      buyerId + timestamp +orderId
    • 根据订单号查询
      orderNo
    • 如果某个商家卖了很多商品,可以如下设计 Rowkey 实现快速搜索
      salt + sellerId + timestamp 其中,salt 是随机数。
      可以支持的场景:

       

      • 全表 Scan
      • 按照 sellerId 查询
      • 按照 sellerId + timestamp 查询

    金融风控 Rowkey 设计

    查询某个用户的用户画像数据

    • prefix + uid
    • prefix + idcard
    • prefix + tele

    其中 prefix = substr(md5(uid),0 ,x), x 取 5-6。uid、idcard以及 tele 分别表示用户唯一标识符、身份证、手机号码。

    车联网 Rowkey 设计

    • 查询某辆车在某个时间范围的交易记录
      carId + timestamp
    • 某批次的车太多,造成热点
      prefix + carId + timestamp 其中 prefix = substr(md5(uid),0 ,x)

    查询最近的数据

    查询用户最新的操作记录或者查询用户某段时间的操作记录,RowKey 设计如下:
    uid + Long.Max_Value - timestamp
    支持的场景

    • 查询用户最新的操作记录
      Scan [uid] startRow [uid][000000000000] stopRow [uid][Long.Max_Value - timestamp]
    • 查询用户某段时间的操作记录
      Scan [uid] startRow [uid][Long.Max_Value – startTime] stopRow [uid][Long.Max_Value - endTime]

    OpenTSDB 的 Rowkey 设计

    参见 《OpenTSDB 底层 HBase 的 Rowkey 是如何设计的》

    如果 RowKey 无法满足我们的需求,可以尝试二级索引。Phoenix、Solr 以及 ElasticSearch 都可以用于构建二级索引。


    转载自过往记忆(https://www.iteblog.com/)

    展开全文
  • Hbase rowkey设计

    2020-04-26 23:12:52
    hbase的rowkey设计决定了数据的分区和查询的方式,是使用hbase前一定要想清楚的,以下简单列举了设计hbase rowkey时需要考虑的问题 1. rowkey是唯一的吗? rowkey相同的记录在hbase里被认为是同一条数据的多个版本...
  • HBase Rowkey 设计

    2019-07-03 21:10:27
    1、RowKey 到底是什么 我们常说看一张 HBase 表设计的好不好,就看它的 RowKey 设计的好不好。可见 RowKey 在 HBase 中的地位。那么 RowKey 到底是什么?RowKey 的特点如下: 类似于 MySQL、Oracle中的主键,...
  • rowkey设计案例.zip

    2020-03-19 09:47:10
    Spark存储数据到HBase实现RowKey完全散列-多进程多线程间Random完全随机,完美解决热点问题
  • RowKey设计篇

    2021-02-25 10:07:36
    RowKey的设计需要遵守以下三个原则: 1.Rowkey的唯一原则 必须在设计上保证其唯一性。由于在HBase中数据存储是Key-Value形式,若HBase中同一表插入相同Rowkey,则原先的数据会被覆盖掉(如果表的version设置为1的话)...
  • HBase RowKey设计

    2020-09-07 10:09:50
    为什么Rowkey这么重要 RowKey 到底是什么 我们常说看一张 HBase 表设计的好不好,就看它的 RowKey 设计的好不好。可见 RowKey 在 HBase 中的地位。那么 RowKey 到底是什么?RowKey 的特点如下: 类似于 MySQL、...
  • hbase RowKey设计

    2021-02-08 15:16:23
    一条数据的唯一标识就是RowKey,那么这条数据存储于哪个分区,取决于RowKey处于哪个一个预分区的区间内,设计RowKey的主要目的 ,就是让数据均匀的分布于所有的region中,在一定程度上防止数据倾斜。接下来我们就谈...
  • rowkey设计原则

    千次阅读 2018-04-27 17:21:44
    rowkey是二进制码流,可以是任意字符串,最大长度64kb。一、rowkey长度原则建议越短越好,因为如果要存储多行数据的话,单凭rowkey就要占用很多的存储空间,这样会严重影响HFile的存储效率。二、rowkey散列原则如果...
  • Hbase rowkey 设计

    2021-06-10 11:27:07
    第一种: rowkey长度原则 rowkey是一个二进制码流,可以是任意字符串,最大长度64kb,实际应用中一般为10-100bytes,以byte[]形式保存,一般设计成定长。 建议越短越好,不要超过16个字节, 第二种: rowkey散列原则...
  • rowkey字典排序

    2020-05-12 17:17:09
    rowkey从高位到低位依照ASCII码表排序;如A排在a前面,a排在aa ab前面; 如果rowkey一样,按照column family:qualifier排序; 如果column family:qualifier一样,按照时间戳排序; 充分利用rowkey会排序特性 如果热点数据...
  • hbaseRowkey设计

    2020-06-11 19:15:54
    1.RowKey的设计需要充分考虑到业务的读写特点 当客户端需要频繁写一张表,随机的RowKey会获得更好的性能 当客户端需要频繁的读一张表,有序的rowkey则会获得更好的性能 2. Rowkey特性 唯一性:Rowkey必须能够唯一...
  • HBase Rowkey 设计指南

    2020-08-14 17:06:08
    HBase 的 Rowkey 设计可以说是使用 HBase 最为重要的事情,直接影响到HBase的性能 前言 RowKey 到底是什么? 常说看一张 HBase 表设计的好不好,就看它的 RowKey 设计的好不好。可见 RowKey 在 HBase 中的地位。...
  • HBase之RowKey设计

    2020-11-08 12:58:53
    HBase RowKey设计HBaseHBase的存储RowKey设计原则热点问题 HBase 工作中一直有使用到HBase,但是却一直没有好好的总结整理过,最近换工作过程中,经常会被问到HBase相关的知识(裸面被鞭打的惨不忍睹啊),在回顾、...
  • HBase 之Rowkey设计

    2020-01-15 08:11:52
    Rowkey的作用 Rowkey用于标识唯一的行 HBase中的数据都是根据Rowkey的字典序存储的,比如memstore中的数据和HFile中的数据 读写数据都需要通过Rowkey来定位Region Rowkey的设计原则 长度原则 rowkey可以是任意字符...
  • HBase之Rowkey设计

    2020-02-13 16:34:06
    HBase之Rowkey设计 Rowkey基础 Rowkey按自然顺序存储的,且具有唯一性,示例如下a_022 a_101 b_123 f_031 f_051 f_131 z_121 当数据是有序的时候,通常利用二分查找的方式进行点查询、范围查询是最有效的(hash...
  • hbase rowkey 排序

    2019-08-12 22:23:02
    HBase里面同一列的元素按照rowkey进行排序,排序规则是rowkey的ASCII码排序,小的在前大的在后。 举例说明:rowkey的时间设计是Long.MAX_VALUE减去真实的timestamp(单位:秒)(System.currentTimeMillis()/1000...
  • hbase rowkey

    2015-03-05 10:30:53
    大数据性能调优之HBase的RowKey设计  
  • hbase rowkey 设计

    2019-09-25 10:49:53
    HBase中的rowkey是按字典顺序排序的,通过rowkey查询可以对千万级的数据实现毫秒级响应。然而,如果rowkey设计不合理的话经常会出现一个很普遍的问题----热点。当大量client的请求(读或者写)只指向集群的一个节点...
  • HBase的rowkey设计原则

    2021-08-01 12:58:16
    Region二个重要的属性:StartKey与EndKey表示这个Region维护的rowKey范围,当我们要读/写数据时,如果rowKey落在某个start-end key范围内,那么就会定位到目标region并且读/写到相关的数据。 那怎么快速精准的定位...
  • HBase Rowkey的设计

    2021-05-15 18:58:18
    HBase Rowkey的设计 1、Rowkey为什么这么重要? 首先,先介绍一下什么是Rowkey。 类似于 MySQL、Oracle中的主键,用于标示唯一的行; 完全是由用户指定的一串不重复的字符串; HBase 中的数据永远是根据 Rowkey...
  • hbase rowkey设计

    2020-05-20 08:12:25
    hbase存储是按照rowkey排序的 所以如果经常需要scan,而且没有热点,那么不需要打散, 如果有一批相近的rowkey是热点,那么就需要打散,通过加既然前缀,或者倒过来, 打散是要有规则的,否则就没法查了, 可以一批...
  • HBase rowkey概念

    2021-09-28 16:00:38
    决定一行数据 按照字典序排列 1 - 11 - 111 - 2 - 22 查询范围的数据场景较多 精确查询场景少 字典序能提高查询效率 row key只能存储64k的字节数据 非常大 一般10-100个字节 rowkey越短越好

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 26,298
精华内容 10,519
关键字:

RowKey