企业网站设计多少钱,试用网站空间,wordpress 侧边栏代码,山西推广型网站建设作者 | 且听风吟责编 | Carol封图 | CSDN 付费下载于视觉中国前言RowKey作为HBase的核心知识点#xff0c;RowKey设计会影响到数据在HBase中的分布#xff0c;还会影响我们查询效率#xff0c;所以RowKey的设计质量决定了HBase的质量。是咱们大数据从业者必知必会的#xf… 作者 | 且听风吟责编 | Carol封图 | CSDN 付费下载于视觉中国前言RowKey作为HBase的核心知识点RowKey设计会影响到数据在HBase中的分布还会影响我们查询效率所以RowKey的设计质量决定了HBase的质量。是咱们大数据从业者必知必会的自然也是面试必问的考察点。那么rowkey到底是什么呢原理是什么呢怎么设计RowKey呢使用场景是怎样的呢有哪些设计原则呢又如何进行优化呢下面就让我们带着这些问题一起探索RowKey的世界RowKey的概念RowKey从字面意思来看是行键的意思咱们知道HBase可以理解为一个nosqlnot only sql数据库既然是数据库那么咱们日常使用最多的就是增删改查curd。其实在增删改查的过程中RowKey就充当了主键的作用它和众多的nosql数据库一样可以唯一的标识一行记录。RowKey行键 (RowKey)可以是任意字符串在HBase内部RowKey保存为字节数组。存储时数据按照RowKey的字典序(byte order)排序存储。设计RowKey时要充分利用排序存储这个特性将经常一起读取的行存储放到一起。RowKey的特点小结如下RowKey类似于主键可以唯一的标识一行记录由于数据按照RowKey的字典序(byte order)排序存储因此HBase中的数据永远都是有序的。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的作用可以归纳如下Hbase在读写数据时需要通过RowKey找到对应的RegionMemStore和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]在查询用户的所有操作记录数据的时候直接指定反转后的userIdstartRow 是 [反转后的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设计的重要性了为了帮助我们设计出完美的RowKeyHBase提出了RowKey的设计原则一共有四点长度原则、唯一原则、排序原则散列原则。RowKey在字段的选择上需要遵循的最基本原则是唯一原则因为RowKey必须能够唯一的识别一行数据。无论应用的负载特点是什么样RowKey字段都应该首先考虑最高频的查询场景。数据库通常都是以如何高效的读取和消费数据为目的而不仅仅是数据存储本身。然后再结合具体的负载特点再对选取的RowKey字段值进行改造结合RowKey的优化也就是避免热点现象的那些方法来优化就可以了。5.1 长度原则RowKey本质上是一个二进制码的流可以是任意字符串最大长度为64kb实际应用中一般为10-100byte以byte[]数组形式保存一般设计成定长。官方建议越短越好不要超过16个字节原因可以概括为如下几点影响HFile的存储效率HBase里的数据在持久化文件HFile中其实是按照Key-Value对形式存储的。这时候如果RowKey很长比如达到了200byte那么仅仅1000w行的记录只考虑RowKey就需占用近2GB的空间极大的影响了HFile的存储效率。降低检索效率由于MemStore会缓存部分数据到内存中如果RowKey比较长就会导致内存的有效利用率降低也就不能缓存更多的数据从而降低检索效率。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进行了详细全面的解析相信一定能对你有所帮助。版权声明本文为CSDN博主「且听_风吟」的原创文章遵循CC 4.0 BY-SA版权协议转载请附上原文出处链接及本声明。原文链接https://blog.csdn.net/qq_26803795/article/details/105994960推荐阅读
那天我去逛街发现连大编程语言都摆起地摊了……研发的未来在哪里Serverless 云开发来了从地摊看云计算规模产业历程大揭秘国外小伙怒喷加密货币行业入行两年我受够了重构ncnn腾讯优图开源新一代移动端推理框架TNN墨奇科技汤林鹏如何用 AI 技术颠覆指纹识别性能超越最新序列推荐模型华为诺亚方舟提出记忆增强的图神经网络真香朕在看了
