面向列： 面向列的存储和权限控制，并支持独立检索，可以动态增加列，即，可单独对列进行各方面的操作 列式存储，其数据在表中是按照某列存储的，这样在查询只需要少数几个字段的时候，能大大减少读取的数量 3. 多版本： Hbase的每一个列的数据存储有多个Version，比如住址列，可能有多个变更，所以该列可以有多个version 4. 稀疏性： 为空的列并不占用存储空间，表可以设计的非常稀疏。 Region切分、主键索引、缓存机制使得Hbase在海量数据下具备一定的随机读取性能，该性能针对Rowkey的查询能够到达毫秒级别 LSM树，树形结构，最末端的子节点是以内存的方式进行存储的，内存中的小树会 一个 HStore 包含一个 MemStore 和多个 StoreFile （ 每个 HStore 对应 Table 的一个列族 cf ）。 当一个 HStore 里面 StoreFile 的数量增长到一定阈值之后，会触发Compact合并操作，将多个 StoreFiles 合并成一个 StoreFile。
前言 HBase 是一个分布式的、多版本、面向列的开源 KV 数据库。运行在 HDFS 的基础上，支持 PB 级别、百万列的数据存储。 Row key ：表的主键，按照字典序排序。 列簇：在 HBase 中，列簇将表进行横向切割。 列：属于某一个列簇，在 HBase 中可以进行动态的添加。 Cell : 是指具体的 Value 。 TimeStamp 在 HBase 中充当的作用就是版本号，因为在 HBase 中有着数据多版本的特性，所以同一个 KEY 可以有多个版本的 Value 值（可以通过配置来设置多少个版本）。 HStore 是 HBase 的核心存储单元，一个 HStore 由 MemStore 和 StoreFile 组成。 在 HStore 对应着的是 Table 里面的 Column Family，不管有 CF 中有多少的数据，都会存储在 HStore 中，为了避免访问不同的 HStore 而导致的效率低下。
领8888元新春采购礼包，抢爆款2核2G云服务器95元/年起，个人开发者加享折上折
正是因为HBase的良好扩展性，才为海量数据的存储提供了便利。 列式存储：列式存储，HBase是根据列族来存储数据的。列族下面可以有非常多的列，列族在创建表的时候就必须指定，而不用指定列。 稀疏：稀疏主要是针对HBase列的灵活性，在列族中，可以指定任意多的列，在列数据为空的情况下，是不会占用存储空间。 ? 从我们使用Hbase开始，开发和调优将会一直伴随在系统的整个生命周期。 如果业务要进行预分区，首先要明确rowkey的取值范围或构成逻辑，假设我们的rowkey组成为例：两位随机数+时间戳+客户号，两位随机数的范围从00-99，于是我划分了10个region来存储数据,每个 反转固定格式的数值 以手机号为例，手机号的前缀变化比较少（如152、185等），但后半部分变化很多。如果将它反转过来，可以有效地避免热点。不过其缺点就是失去了有序性。 使用扫描缓存 如果HBase作为一个MapReduce作业的而输入源，最好将MapReduce作业的输入扫描器实例的缓存用setCaching()设置为比1大的多的值。
文件数量通常取决于 Compaction 的执行策略，一般和两个配置参数有关：hbase.hstore.compactionThreshold 和 hbase.hstore.compaction.max.size hbase.hstore.compactionThreshold 设置不能太大，默认为3个。 2.3 请求是否可以显式指定列簇或者列 尽量指定列簇或者列进行精确查询。 针对get查询为主的表，可以使用hash预分区策略；针对scan为主的表，建议使用分段预分区的策略。 1.3 使用 SSD 存储 WAL 将 WAL 文件写到SSD上，对于写性能会有非常大的提升。 如果Value过大，建议拆成多列存储，每次返回需要的值，或者将Value存储到HDFS上，在HBase中存储url 原文链接： https://blog.csdn.net/microGP/article
，不做任何删除数据、多版本数据的清理工作。 2）Major操作是对Region下的HStore下的所有StoreFile执行合并操作，最终的结果是整理合并出一个文件。 首先，对于HRegion里的每个HStore进行一次判断，needsCompaction()判断是否足够多的文件触发了Compaction的条件。 Compaction对于读写操作的影响 Compaction与Flush不同之处在于：Flush是针对一个Region整体执行操作，而Compaction操作是针对Region上的一个Store而言，因此 如下图所示，我们假定该RegionServer上仅有一个Region，由于不同的Row是在列簇上有所区别，就会出现有些不同Store内占用的内存不一致的情况，这里会根据整体内存使用的情况，或者RS使用内存的情况来决定是否执行
它是一个针对大型分布式系统的可靠协调系统，提供的功能包括：配置维护、名字服务、分布式同步、组服务等。 HRegionServer内部管理了一系列HRegion对象，每个HRegion对应了Table中的一个Region，HRegion中由多个HStore组成。 HStore HStore存储是HBase存储的核心了，其中由两部分组成，一部分是 MemStore，一部分是StoreFiles。 在理解了上述 HStore的基本原理后，还必须了解一下HLog的功能，因为上述的HStore在系统正常工作的前提下是没有问题的，但是在分布式系统环境中，无法避免系统出错或者宕机，因此一旦HRegionServer 接下来的变化是解决多索引字段查询的问题。我们将主键字段和属性字段分开存储，储存在不同的列族下，多索引查询只需要取出列族1下的数据，再去最小集合的列族2里取得想要的值。储存如下图： ?
Hadoop 可以通过 HDFS 来存储结构化、半结构甚至非结构化的数据，它是传统数据库的补充，是海量数据存储的最佳方法，它针对大文件的存储，批量访问和流式访问都做了优化，同时也通过多副本解决了容灾问题 基本概念 RowKey(行键) 相当于RDBMS中的主键 创建表时不需要指定行键，添加数据时指定 Column Family(列族) 创建表时需要指定列族，理论上列族的数量不受限制，实际开发中 建议不超过三个 行键+列族+列+时间戳 每一条数据都在这个单元中 默认只获取最后一个版本的数据 namespace(名称空间) 相当于RDBMS中的数据库 建表时如果不指定名称空间则使用默认的defult名称空间 ']} #删除person表中行键为p1列族basic列name的值 delete 'person','p1','basic:name' #删除person表中行键为p1的所有列 deleteall ' ，所以HRegion中的数据不会出现交叉 存在不同的HRegion中是为了分布式管理 HRegion中存在多个HStore HStore的数量由列族的数量决定,一个HStore中存在一个列族的数据 一个
某个业务起来之后集群其他部分业务延迟较大 这三种场景是表象，通常某业务反应延迟异常，首先需要明确具体是哪种场景，然后针对性解决问题。 优化原理：HBase是典型的列族数据库，意味着同一列族的数据存储在一起，不同列族的数据分开存储在不同的目录下。 如果一个表有多个列族，只是根据Rowkey而不指定列族进行检索的话不同列族的数据需要独立进行检索，性能必然会比指定列族的查询差很多，很多情况下甚至会有2倍～3倍的性能损失。 默认情况下BlockCache和Memstore的配置相对比较均衡（各占40%），可以根据集群业务进行修正，比如读多写少业务可以将BlockCache占比调大。 文件数量通常取决于Compaction的执行策略，一般和两个配置参数有关：hbase.hstore.compactionThreshold和hbase.hstore.compaction.max.size
minVersion=0并且设置ttl的过期版本清理，不做任何删除数据、多版本数据的清理工作。 来判断用给个大的线程池还是小的线程池 long size = selectNow ? Minor Compaction的文件选择策略 我们再简单看看applyCompactionPolicy这个方法吧，它是minor的时候用的，它的过程就像下图一样。 找出最大的HStore，然后通过它来找这个分裂点，最大的文件的中间点。 重命名目录之后，就是修改Meta表了，splitRegion的方法是通过Put来进行操作的，它修改parent的regioninfo这一列更新为最新的信息，另外又增加了splitA和splitB两列，hri_a
新数仓系列：开源组件运营（3） 新数仓系列：Hbase国内开发者生存现状（2） 新数仓系列：Hbase周边生态梳理（1） HBASE关键能力和特性 1、无固定模式(表结构不固定): 每行都有一个可排序的主键和任意多的列 3、数据多版本：每个单元中的数据可以有多个版本，默认情况下版本号自动分配，是单元格插入时的时间戳。 4、高性能：针对Rowkey的查询能够达到毫秒级别。 5、支持实时更新。 数据压缩，保存到读缓存中) HRegionServer内部管理了一系列HRegion对象，每个HRegion对 应了table中的一个region，HRegion中由多 个HStore组成。 每个HStore对应了Table中的一个column family的存储，可以看出每个columnfamily其实就是一个集中的存储单元，因此最好将具备共同IO特性的column放在一个column family 我们的存储空间又很有限，尤其是HDFS这种多副本容灾存储。再加上HBase在存储每一行数据时，分别要为每一列保存一份rowKey，如果一行有10列，光rowKey就要存储10份，开销可想而知。
minVersion=0并且设置ttl的过期版本清理，不做任何删除数据、多版本数据的清理工作。 来判断用给个大的线程池还是小的线程池 long size = selectNow ? Minor Compaction的文件选择策略 我们再简单看看applyCompactionPolicy这个方法吧，它是minor的时候用的，它的过程就像下图一样。 ? 找出最大的HStore，然后通过它来找这个分裂点，最大的文件的中间点。 重命名目录之后，就是修改Meta表了，splitRegion的方法是通过Put来进行操作的，它修改parent的regioninfo这一列更新为最新的信息，另外又增加了splitA和splitB两列，hri_a
我们在之前的博文中介绍了 HBOSS 。 不幸的是，当针对跨越数千个区域和数十 TB 的更大工作负载和数据集运行 HBOSS 解决方案时，HBOSS 引发的锁争用会严重影响集群性能。 HStore编写高层设计 上面提到的 HStore 组件聚合了几个与存储维护相关的附加结构，包括 StoreEngine，它隔离存储文件处理特定逻辑。 这些文件放在 .filelist 目录中，而该目录又是实际列族文件夹的子目录。 StoreFileListFile初始化 每当区域在区域服务器上打开时，需要初始化其相关的 HStore 结构。 存储文件跟踪转换器命令 可以使用两个新的 HBase shell 命令来更改表或列族的存储文件跟踪实现，并且可以用作转换最初未配置 FILE 跟踪器的导入表的替代方法： change_sft ：允许更改单个表或列族的存储文件跟踪实现
并行回收器（ParallelGC），主要针对年轻带进行优化（JDK 8 默认策略）。 并发回收器（ConcMarkSweepGC，简称CMS），主要针对年老代进行优化。 G1GC回收器，主要针对大内存（32GB以上才叫大内存）进行优化。 区别，用两张图来看。 查询多是针对前缀，比较少跨越多个前缀来查询数据。 如果获取到了则在返回数据的同时把Block块缓存到BlockCache中。它默认是开启的。 如果你想让某个列簇不使用BlockCache,可以通过以下命令关闭它。
那么一个好的环境部署应该是不低于10千兆网络.同时为了保障数据的容错性,使用多机架模式部署可以有效的防止数据单点问题. 05 — regin太多不一定好 首先从hbase的原理来讲,首先一个regionserver regionserver管理着多个region,每个region中有多个hstore组成,每个hstore对应表中的column family中的存储,hstore是hbase存储的核心,由memstore 多个列族会形成更多的hfile小文件 不同列族会共享region,split操作会导致io增加. 也就是说除了空间换时间、时间换空间之外,Bloomfilter使用了一种用很低的错误率来减少空间并且快速查询. ,一旦发现有不均衡情况,可以选择针对用于进行限流或者 罗列几个限制语句 限制用户u1每秒请求10次 hbase> set_quota TYPE => THROTTLE, USER => 'u1', LIMIT
本文从 HBase 写链路开始分析，然后针对少量随机读和海量随机写入场景入手，全方面量化分析各种资源的开销, 从而做到以下两点： 在给定业务量级的情况下，预先评估好集群的合理规模 在 HBase 的众多参数中 ，多版本数据的合并，数据删除标记的清理等等，本文不做展开。 四、系统开销定量分析 为了简化计算，本节针对事件类数据写吞吐型场景，对 HBase 系统中的开销做定量的分析，做以下假设： 数据写入的 Rowkey 是打散的，不存在写热点 数据写入量及总量是可评估的， ： Major Compaction Minor Compaction 两者是独立的，下面将分别针对两种 Compaction 做分析，最后取和。 其中每条数据参与 Minor Compaction 的最大次数可以用公式 math.log( 32000 / 25.6, 3) = 6 得到 这里用到的两个变量是： FlushSize 默认是 128
1、B-tree PostgreSQL中，B-tree索引是最常用的一种索引类型。 用索引扫描比顺序扫描速度快，因为它可能只需要读取少部分页面，而顺序扫描可能读取几千个页面。 默认情况下，使用CREATE INDEX语句，会创建一个B-tree索引，这对于大多数常用数据类型比如文本、数字等的适用性很强。 2、GIN 当数据类型在一列中包含多个值时适用。 这种情况下最常见的数据类型是hstore、range、jsonb等，并不是所有的数据类型都支持这种索引类型。 3、GiST GiST索引适用的情况是： 有一些数据，它们和其他行的同一列中的值在某种程度上相互覆盖，此时适用。 最合适的数据类型是：几何类型、全文检索时的文本类型。 但最大的问题是被限制在等值上所以需要寻找准确的匹配。这使得哈希索引不那么灵活。 总结 B-tree 适用于大多数数据类型和查询。 GIN 适用于json/hstore数据类型。
HBase是一个开源的，分布式的，多版本的，面向列的存储模型。它存储的是松散型数据。 Column Family： 列簇，一个table在水平方向有一个或者多个列簇，列簇可由任意多个Column组成，列簇支持动态扩展，无须预定义数量及类型，二进制存储，用户需自行进行类型转换 Table Table随着记录增多不断变大，会自动分裂成多份Splits，成为Regions 2. 一个region由[startkey，endkey)表示 3. HRegionServer管理一些列HRegion对象； 每个HRegion对应Table中一个Region，HRegion由多个HStore组成； 每个HStore对应Table中一个Column Family 的存储； Column Family就是一个集中的存储单元，故将具有相同IO特性的Column放在一个Column Family会更高效 HStore： HBase存储的核心。
之前在讲put的时候，put是被添加到Store里面，这个Store是个接口，实现是在HStore里面，MemStore其实是它底下的小子。 Region Server下面有若干个Region，每个Region下面有若干的列族，每个列族对应着一个HStore。 HStore里面有三个很重要的类，在这章的内容都会提到。 CacheConf是针对HFileBlock的缓存，专门用来缓存快，默认是在读的时候缓存块，也可以修改列族的参数，让它在写的时候也缓存，这个在数据模型定义的时候提到过。 CacheConfig是一个HStore一个，属性是根据列族定制的，比如是否常驻内存，但是它内存用来缓存块的BlockCache是Region Server全局共享的的globalBlockCache， 是在BucketSizeInfo的数组里面的位置，它的大小都是有固定的值的，不能多也不能少，这里就不详细介绍了。我们直接看WriteToCache这个方法吧，好验证一下之前的想法。
这里值得关注的一点是只有在触发执行major compaction后才会真正删除数据，包含写入的Delete数据、设置TTL的列族中已经过期的数据以及版本号过大的数据。 Minor Compaction 参数 Minor compaction涉及的参数比major compaction要多，各个参数的目标是为了选择合适的StoreFile，具体参数如下： 1.hbase.hstore.compaction.min 如果要调整，不建议调小该参数，这样会带来更频繁的压缩，调大该参数的同时其他相关参数也应该做调整。早期参数名称为hbase.hstore.compactionthreshold。 5.hbase.hstore.compaction.ratio 这个ratio参数的作用是判断文件大小 > hbase.hstore.compaction.min.size的StoreFile是否也是适合进行 Compaction 对读写请求的影响 存储上的写入放大 HBase Compaction会带来写入放大，特别是在写多读少的场景下，写入放大就会比较明显，下图简单示意了写入放大的效果。 ?
1、HRegion 当表的大小超过设置的值时，HBase会自动地将表划分为不同的区域，每个区域包含所有行的子集。 从物理上讲，一张表被拆分成了多块，每一块儿就是一个HRegion.一个HRegion会保存一表里面某段连续的数据，从开始主键到结束主键，一张完整的表格是保存在多个HRegion上面。 读取数据时，HRegion服务器会先访问Hmemcache缓存，如果缓存中没有该数据，才会回到Hstores磁盘上面寻找，每个列族都会有一个Hstore集合，每个Hstore集合包含很多具体的HstoreFile 用这个识别符来区分不同的HRegion，这些数据就是元数据(META),而元数据本身也是被保存在HRegion里面的，所以我们称这个表为源数据表（META Table)，里面保存的就是HRegion标识符和实际 HBase数据模型 （注意的是，每一条数据对应的时间戳都是用数字来表示，编号越大表示数据越旧，反之则表示数据越新） 参考《Hadoop 实战》
腾讯云数据库MySQL是一种高性能、高可靠、高安全、可灵活伸缩的数据库托管服务，其不仅经济实惠，而且提供备份回档、监控、快速扩容、数据传输等数据库运维全套解决方案，为您简化 IT 运维工作，让您能更加专注于业务发展。
扫码关注腾讯云开发者
领取腾讯云代金券
云服务器
云数据库 SQL Server
网站备案
对象存储
文件存储
