引入
通过前面的文章,我们对HBase已经有了基本认识,下面我们从HBase最核心的算法和数据布局进一步深入HBase。
HBase的一个列簇(Column Family)本质上就是一棵LSM树(Log-Structured Merge-Tree)。LSM树分为内存部分和磁盘部分。内存部分是一个维护有序数据聚集的数据布局。一样平常来讲,内存数据布局可以选择平衡二叉树、红黑树、跳跃表(SkipList)等维护有序集的数据布局,这里由于考虑并发性能,HBase选择了表现更优秀的跳跃表。磁盘部分是由一个个独立的文件构成,每一个文件又是由一个个数据块构成。并且为了避免不必要的IO耗时,还可以在磁盘中存储一些额外的二进制数据,这些数据用来判定对于给定的key是否有可能存储在这个数据块中,这个数据布局称为布隆过滤器(Bloom Filter)。
下面我们就深入先容一下提到的核心数据布局与算法:
- LSM树(Log-Structured Merge-Tree)
- 跳跃表(SkipList)
- 布隆过滤器(Bloom Filter)
LSM树(Log-Structured Merge-Tree)
LSM树本质上和B+树一样,是一种磁盘数据的索引布局。但和B+树不同的是,LSM树的索引对写入请求更友好。因为无论是何种写入请求,LSM树的索引布局本质都会将其全部转化成磁盘的顺序写入,而HDFS善于的正是顺序写(且HDFS不支持随机写),因此基于HDFS实现的HBase能极大进步写入操作的性能,但这种计划对读取操作好坏常不利的,因为需要在读取的过程中,通过归并所有文件来读取所对应的KV,这好坏常斲丧IO资源的。因此,在HBase中计划了异步的compaction来降低文件个数,到达进步读取性能的目标。由于HDFS只支持文件的顺序写,不支持文件的随机写,而且HDFS善于的场景是大文件存储而非小文件,以是上层HBase选择LSM树这种索引布局是最符合的。
原理
LSM树是一种用于存储和管理数据的数据布局,特殊适用于写入密集型的工作负载。它的计划灵感来自于日志布局文件系统。LSM树的核心头脑是将写操作集中到一个内存中的有序数据布局(如MemTable),待数据积聚到一定数量后,将这些数据批量写入到磁盘上的有序文件中。这种计划能够显著进步写操作的性能,因为将随机写转换为顺序写,能够减少磁盘的寻道时间。
布局
LSM树的索引一样平常由两部分构成,一部分是内存部分,一部分是磁盘部分。内存部分一样平常采用跳跃表来维护一个有序的KeyValue聚集。磁盘部分一样平常由多个内部KeyValue有序的文件构成。
KeyValue存储格式
在HBase为例,这个字节数组串计划如下图所示,字节数组主要分为以下几个字段:
其中Rowkey、Family、Qualifier、Timestamp、Type这5个字段构成KeyValue中的key部分。
- keyLen:占用4字节,用来存储KeyValue布局中Key所占用的字节长度。
- valueLen:占用4字节,用来存储KeyValue布局中Value所占用的字节长度。
- rowkeyLen:占用2字节,用来存储rowkey占用的字节长度。
- rowkeyBytes:占用rowkeyLen个字节,用来存储rowkey的二进制内容。
- familyLen:占用1字节,用来存储Family占用的字节长度。
- familyBytes:占用familyLen字节,用来存储Family的二进制内容。
- qualifierBytes:占用qualifierLen个字节,用来存储Qualifier的二进制内容。
注意,HBase并没有单独分配字节用来存储qualifierLen,因为可以通过keyLen和其他字段的长度计算出qualifierLen。
代码如下:
- qualifierLen=keyLen -2B - rowkeyLen -1B - familyLen -8B -1B
复制代码
- timestamp:占用8字节,表现timestamp对应的long值。
- type:占用1字节,表现这个KeyValue操作的类型,HBase内有Put、Delete、Delete Column、DeleteFamily,等等。注意,这是一个非常关键的字段,表明白LSM树内存储的不只是数据,而是每一次操作记录。
Value部分直接存储这个KeyValue中Value的二进制内容。以是,字节数组串主要是Key部分的计划。
注意:
在HBase中,timestamp越大的KeyValue,排序越靠前。因为用户盼望优先读取到那些版本号更新的数据。
通常来说,在LSM树的KeyValue中的Key部分,有3个字段必不可少:
- Key的二进制内容。
- 一个表现版本号的64位long值,在HBase中对应timestamp;这个版本号通常表现数据的写入先后顺序,版本号越大的数据,越优先被用户读取。甚至会计划一定的策略,将那些版本号较小的数据逾期镌汰(HBase中有TTL策略)。
- type,表现这个KeyValue是Put操作,照旧Delete操作,或者是其他写入操作。本质上,LSM树中存放的并非数据本身,而是操作记录。这对应了LSM树(Log-Structured Merge-Tree)中Log的含义,即操作日志。
多路归并
如今有K个文件,其中第i个文件内部存储有Ni个正整数(这些整数在文件内按照从小到大的顺序存储),怎样计划一个算法将K个有序文件合并成一个大的有序文件?
在排序算法中,有一类排序算法叫做归并排序,里面就有大家熟知的两路归并实现。如今相当于K路归并,因此可以拓展一下,思绪类似。对每个文件计划一个指针,取出K个指针中数值最小的一个,然后把最小的谁人指针后移,接着继承找K个指针中数值最小的一个,继承后移指针……直到N个文件全部读完为止。
核心实今世码如下:
- /**
- * 该类实现了 k 路归并排序的功能,用于合并多个有序文件的内容。
- */
- public class KMergeSort {
- /**
- * 文件读取器接口,定义了从文件中读取数据的方法。
- */
- public interface FileReader {
- /**
- * 检查文件是否还有更多数据。
- * @return 如果文件还有数据,返回 true;否则返回 false 表示到达文件末尾。
- * @throws IOException 如果在读取文件时发生 I/O 错误。
- */
- //true to indicate the file still has some data, false means EOF.
- boolean hasNext() throws IOException;
- /**
- * 从文件中读取下一个值,并将文件读取偏移量向后移动。
- * @return 文件中的下一个整数值。
- * @throws IOException 如果在读取文件时发生 I/O 错误。
- */
- //Read the next value from file, and move the file read offset.
- int next() throws IOException;
- }
- /**
- * 文件写入器接口,定义了向文件中写入数据的方法。
- */
- public interface FileWriter {
- /**
- * 向文件中追加一个整数值。
- * @param value 要追加的整数值。
- * @throws IOException 如果在写入文件时发生 I/O 错误。
- */
- void append(int value) throws IOException;
- }
- /**
- * 实现 k 路归并排序,将多个有序文件的内容合并到一个文件中。
- * @param readers 一个包含多个 FileReader 的列表,每个 FileReader 对应一个有序文件。
- * @param writer 用于写入合并后数据的 FileWriter。
- * @throws IOException 如果在读取或写入文件时发生 I/O 错误。
- */
- public void kMergeSort(final List<FileReader> readers, FileWriter writer)
- throws IOException {
- // 创建一个优先队列(最小堆),用于存储每个文件的当前最小值
- PriorityQueue<Pair<FileReader, Integer>> heap=
- new PriorityQueue<>((p1, p2) -> p1.getValue() - p2.getValue());
- // 初始化优先队列,将每个文件的第一个值加入队列
- for (FileReader fr : readers) {
- if (fr.hasNext()) {
- // 将文件读取器和其下一个值作为一个 Pair 加入堆中
- heap.add(new Pair<>(fr, fr.next()));
- }
- }
- // 不断从堆中取出最小值,并将其写入输出文件
- while (!heap.isEmpty()) {
- // 从堆中取出最小值对应的 Pair
- Pair<FileReader, Integer> current=heap.poll();
- // 将该值写入输出文件
- writer.append(current.getValue());
- // 获取当前文件读取器
- FileReader currentReader=current.getKey();
- // 如果当前文件还有更多数据,将下一个值加入堆中
- if (currentReader.hasNext()) {
- // 将当前文件读取器和其下一个值作为一个 Pair 加入堆中
- heap.add(new Pair<>(currentReader, currentReader.next()));
- }
- }
- }
- }
复制代码 LSM树的索引布局
一个LSM树的索引主要由两部分构成:内存部分和磁盘部分。内存部分是一个ConcurrentSkipListMap,Key就是前面所说的Key部分,Value是一个字节数组。数据写入时,直接写入MemStore中。随着不停写入,一旦内存占用凌驾一定的阈值时,就把内存部分的数据导出,形成一个有序的数据文件,存储在磁盘上。
内存部分导出形成一个有序数据文件的过程称为flush。为了避免flush影响写入性能,会先把当前写入的MemStore设为Snapshot,不再容许新的写入操作写入这个Snapshot的MemStore。另开一个内存空间作为MemStore,让后面的数据写入。一旦Snapshot的MemStore写入完毕,对应内存空间就可以释放。这样就可以通过两个MemStore来实现稳定的写入性能。(看过深入HDFS的小伙伴会发现,这个和SNN合并元数据的操作很类似)
注意:
在整个数据写入过程中,LSM树全部都是利用append操作(磁盘顺序写)来实现数据写入的,没有利用任何seek+write(磁盘随机写)的方式来写入。无论HDD照旧SSD,磁盘的顺序写操作性能和延迟都远好于磁盘随机写。因此LSM树是一种对写入极为友好的索引布局,它能将磁盘的写入带宽利用到极致。
随着写入的增加,内存数据会不停地革新到磁盘上。最终磁盘上的数据文件会越来越多。如果数据没有任何的读取操作,磁盘上产生很多的数据文件对写入并无影响,而且这时写入速度是最快的,因为所有IO都是顺序IO。但是一旦用户有读取请求,则需要将大量的磁盘文件进行多路归并,之后才气读取到所需的数据。因为需要将那些Key相同的数据全局综合起来,最终选择出符合的版本返回给用户,以是磁盘文件数量越多,在读取的时间随机读取的次数也会越多,从而影响读取操作的性能。
为了优化读取操作的性能,我们可以设置一定策略将选中的多个hfile进行多路归并,合并成一个文件。文件个数越少,则读取数据时需要seek操作的次数越少,读取性能则越好。一样平常来说,按照选中的文件个数,我们将compact操作分成两种类型。一种是major compact,是将所有的hfile一次性多路归并成一个文件。这种方式的好处是,合并之后只有一个文件,这样读取的性能肯定是最高的;但它的标题是,合并所有的文件可能需要很长的时间并斲丧大量的IO带宽,以是major compact不宜利用太频繁,适合周期性地跑。
别的一种是minor compact,即选中少数几个hfile,将它们多路归并成一个文件。这种方式的优点是,可以进行局部的compact,通过少量的IO减少文件个数,提升读取操作的性能,适合较高频率地跑;但它的缺点是,只合并了局部的数据,对于那些全局删除操作,无法在合并过程中完全删除。因此,minor compact虽然能减少文件,但却无法彻底清除那些delete操作。而major compact能完全清理那些delete操作,包管数据的最小化。
在HBase中的应用
写操作优化:通过将数据先写入到内存中的MemTable,HBase能够将随机写转换为顺序写,从而大大进步写操作的性能。这对于HBase这种需要处置惩罚大量写入请求的数据库来说非常紧张。
读操作优化:虽然LSM树的计划主要是为了优化写操作,但通过将多个SSTable的索引信息加载到内存中,HBase也能够有效地处置惩罚读取请求。别的,SSTables的有序存储布局也使得范围查询变得非常高效。
数据同等性:在MemTable写入到SSTable之前,HBase会将数据写入WAL,以确保数据的长期性和同等性。如果在写入过程中发生故障,HBase可以通过WAL规复未写入到SSTable的数据。
优点
高性能写入:LSM树能够将随机写转换为顺序写,从而显著进步写入性能。这对于写入密集型的工作负载非常紧张。
有效利用存储空间:通过将多个小的SSTables合并为更大的SSTable,LSM树能够有效地减少存储空间的占用,并进步数据的存储效率。
易于实现压缩:由于SSTables是按主键排序的,因此可以很容易地对它们进行压缩,从而进一步进步存储效率。
缺点
读操作延迟:在读取数据时,HBase需要在多个SSTables之间进行查找和合并,这可能会导致一定的读取延迟。
合并开销:合并SSTables的过程需要斲丧大量的系统资源,包罗CPU、内存和磁盘I/O。如果合并操作过于频繁或规模过大,可能会对系统的性能产生一定的影响。
跳跃表(SkipList)
跳跃表是一种能高效实现插入、删除、查找的内存数据布局,这些操作的盼望复杂度都是O(logN)。与红黑树以及其他的二分查找树相比,跳跃表的上风在于实现简单,而且在并发场景下加锁粒度更小,从而可以实现更高的并发性。正因为这些优点,跳跃表广泛利用于KV数据库中,诸如Redis、LevelDB、HBase都把跳跃表作为一种维护有序数据聚集的基础数据布局。
众所周知,链表这种数据布局的查询复杂度为O(N),这里N是链表中元素的个数。在已经找到要删除元素的情况下,再实行链表的删除操作其实非常高效,只需把待删除元素前一个元素的next指针指向待删除元素的后一个元素即可,复杂度为O(1)。但标题是,链表的查询复杂度太高,因为链表在查询的时间,需要逐个元素地查找。如果链表在查找的时间,能够避免依次查找元素,那么查找复杂度将降低。而跳跃表就是利用这一头脑,在链表之上额外存储了一些节点的索引信息,到达避免依次查找元素的目标,从而将查询复杂度优化为O(logN)。将查询复杂度优化之后,自然也优化了插入和删除的复杂度。
原理
跳跃表是一种有序数据布局,它通过在每个节点中维护多个指针,以支持快速的插入、删除和查找操作。跳跃表的灵感来自于链表,但它通过添加多层指针来减少查找时间。每个节点在跳跃表中可以有多个条理,每个条理的指针指向比当前节点更大的键。这样,在查找一个键时,可以从最高层开始,快速跳过不相关的节点,从而减少比较的次数。
布局
跳跃表的布局是由多个节点构成的,每个节点包含一个键和多个指向其他节点的指针。节点的层数是随机的,通常通过一个概率函数来确定。最高层的指针可以快速跳过大量的节点,而底层的指针则用于精细的查找。跳跃表的条理布局类似于一个金字塔,最顶层的层数最少,最底层的层数最多。
- 跳跃表由多条分层的链表构成(设为S0, S1, S2, ... , Sn);
- 每条链表中的元素都是有序的;
- 每条链表都有两个元素:+∞(正无穷大)和 -∞(负无穷大),分别表现链表的头部和尾部;
- 从上到下,上层链表元素聚集是下层链表元素聚集的子集,即S1是S0的子集,S2是S1的子集。
注意:跳跃表的高度为水平链表的层数。
代码示例
在HBase中的应用
MemStore:跳跃表是HBase的MemStore中的主要数据布局。MemStore是内存中的一个有序数据集,用于存储即将写入到磁盘的数据。跳跃表的高效插入和查找特性使得MemStore能够快速处置惩罚大量的写入请求,并在需要时将数据革新到磁盘上。
Block Index:在HBase的存储引擎中,块索引(Block Index)也利用跳跃表来加速数据的定位。块索引保存了每个数据块的起始键和竣事键,通过跳跃表的布局,可以快速确定一个键所在的数据块,从而减少磁盘的随机读取次数。
优点
快速的插入、删除和查找:跳跃表在平均情况下的插入、删除和查找操作的时间复杂度为O(log n),这比传统的链表要快得多。
动态性:跳跃表能够在任何时间进行插入、删除和查找操作,而不需要进行任何预处置惩罚或重建操作。
易于实现:跳跃表的实现相对简单,不需要复杂的平衡操作,因此易于理解和实现。
缺点
空间开销:跳跃表需要为每个节点维护多个指针,这会增加空间的开销。在节点数较多的情况下,指针的维护可能会占用较大的内存空间。
性能颠簸:由于跳跃表的层数是随机生成的,因此在极端情况下,可能会出现层数过高的情况,导致性能下降。然而,这种情况的概率较低,可以通过调解随机概率函数来缓解。
布隆过滤器(Bloom Filter)
关于布隆过滤器,保举先阅读这篇论文,里面详细先容了布隆过滤器的原理、变体和在网络中的多种应用,以及利用时需要在空间效率和假阳性概率之间权衡。
原理
布隆过滤器是一种概率性的数据布局,用于判定一个元素是否可能存在于一个聚集中。它通过利用多个哈希函数将元素映射到一个位数组中。当一个元素被添加到聚集时,它会被多个哈希函数处置惩罚,每个哈希函数的结果会设置位数组中对应的位置为1。在查询时,同样利用这些哈希函数处置惩罚待查询的元素,如果位数组中所有对应的位置都为1,则认为该元素可能存在于聚集中。否则,可以确定该元素一定不存在于聚集中。
布局
布隆过滤器的核心是一个位数组和多个哈希函数。位数组的大小和哈希函数的数量会影响布隆过滤器的准确性和空间利用率。较大的位数组和较多的哈希函数可以降低误判率,但会增加空间的利用和计算的时间。
工作流程
- 添加元素
当一个元素被添加到布隆过滤器时,它会通过多个哈希函数生成多个整数,这些整数对应于位数组中的位置。然后,将这些位置的位设置为1。
- 查询元素
要判定一个元素是否存在于聚集中,将其通过相同的哈希函数生成对应的位位置,并检查这些位置是否都为1。如果有任何一个位置为0,则可以确定该元素不存在于聚集中。否则,认为该元素可能存在,但可能存在误判。
- 误判率
布隆过滤器的误判率是指错误地认为一个不存在的元素存在于聚集中的概率。误判率可以通过调解位数组的大小和哈希函数的数量来控制。
在HBase中的应用
HFile:布隆过滤器被广泛应用于HBase的HFile中。HFile是HBase存储数据的基本单元,每个HFile包含多个数据块。在每个数据块中,布隆过滤器用于快速判定某个行键是否可能存在于该块中。当进行数据查询时,起首通过布隆过滤器快速筛选出可能包含目标行键的数据块,从而减少不必要的磁盘I/O操作。
Filter:HBase的过滤器(Filter)也可以利用布隆过滤器来加速数据的过滤过程。例如,在行键过滤器中,可以利用布隆过滤器来判定某个行键是否满足过滤条件,从而快速定位到目标数据。
优点
高效率:布隆过滤器的查询操作非常高效,时间复杂度为O(k),其中k是哈希函数的数量。这使得它非常适合用于大数据场景中的快速查询。
节流空间:与传统的存储所有元素的方式相比,布隆过滤器所需的存储空间非常小。例如,存储一个包含数百万元素的聚集可能只需要几千字节的空间。
并行性:布隆过滤器的查询和插入操作可以并行实行,因为它们不涉及任何共享资源的锁定。这使得它非常适用于大规模并行处置惩罚系统。
缺点
误判率:布隆过滤器存在一定的误判率,即错误地认为一个不存在的元素存在于聚集中的概率。虽然可以通过调解参数来降低误判率,但无法完全消除。
无法删除元素:一旦一个元素被添加到布隆过滤器中,很难将其删除。因为多个元素可能共享同一个位数组中的位置,删除一个元素可能会导致误判率的增加。
参数调解复杂:布隆过滤器的性能和准确度高度依靠于位数组的大小和哈希函数的数量。选择符合的参数需要根据现实的数据量和查询需求进行过细的测试和调解。
免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!更多信息从访问主页:qidao123.com:ToB企服之家,中国第一个企服评测及商务社交产业平台。 |