HBASE常见问题

HBase搭建过程中需要注意什么
是否使用外部ZooKeeper，这个一般使用Hadoop集群的ZooKeeper集群即可。
HBASE_MANAGES_ZK=false
hbase-site.sh的配置
hbase.zookeeper.quorum=“host1:2181,host2:2181”
HBase优化方法

• 1减少调整
  减少调整这个如何理解呢？HBase中有几个内容会动态调整，如region（分区）、HFile，所以通过一些方法来减少这些会带来I/O开销的调整
  Region
  如果没有预建分区的话，那么随着region中条数的增加，region会进行分裂，这将增加I/O开销，所以解决方法就是根据你的RowKey设计来进行预建分区，减少region的动态分裂
  HFile
  HFile是数据底层存储文件，在每个memstore进行刷新时会生成一个HFile，当HFile增加到一定程度时，会将属于一个region的HFile进行合并，这个步骤会带来开销但不可避免，但是合并后HFile大小如果大于设定的值，那么HFile会重新分裂。为了减少这样的无谓的I/O开销，建议估计项目数据量大小，给HFile设定一个合适的值
  2减少启停
  数据库事务机制就是为了更好地实现批量写入，较少数据库的开启关闭带来的开销，那么HBase中也存在频繁开启关闭带来的问题。
  关闭Compaction，在闲时进行手动Compaction
  因为HBase中存在Minor Compaction和Major Compaction，也就是对HFile进行合并，所谓合并就是I/O读写，大量的HFile进行肯定会带来I/O开销，甚至是I/O风暴，所以为了避免这种不受控制的意外发生，建议关闭自动Compaction，在闲时进行compaction
  批量数据写入时采用BulkLoad
  如果通过HBase-Shell或者JavaAPI的put来实现大量数据的写入，那么性能差是肯定并且还可能带来一些意想不到的问题，所以当需要写入大量离线数据时建议使用BulkLoad
• 3减少数据量
  虽然我们是在进行大数据开发，但是如果可以通过某些方式在保证数据准确性同时减少数据量，何乐而不为呢？
  开启过滤，提高查询速度
  开启BloomFilter，BloomFilter是列族级别的过滤，在生成一个StoreFile同时会生成一个MetaBlock，用于查询时过滤数据
  使用压缩：一般推荐使用Snappy和LZO压缩
• 4合理设计
  在一张HBase表格中RowKey和ColumnFamily的设计是非常重要，好的设计能够提高性能和保证数据的准确性
  RowKey设计：应该具备以下几个属性
  散列性：散列性能够保证相同相似的rowkey聚合，相异的rowkey分散，有利于查询
  简短性：rowkey作为key的一部分存储在HFile中，如果为了可读性将rowKey设计得过长，那么将会增加存储压力
  唯一性：rowKey必须具备明显的区别性
  业务性：举些例子
  假如我的查询条件比较多，而且不是针对列的条件，那么rowKey的设计就应该支持多条件查询
  如果我的查询要求是最近插入的数据优先，那么rowKey则可以采用叫上Long.Max-时间戳的方式，这样rowKey就是递减排列
  列族的设计
  列族的设计需要看应用场景
  多列族设计的优劣
  优势：HBase中数据时按列进行存储的，那么查询某一列族的某一列时就不需要全盘扫描，只需要扫描某一列族，减少了读I/O；其实多列族设计对减少的作用不是很明显，适用于读多写少的场景
  劣势：降低了写的I/O性能。原因如下：数据写到store以后是先缓存在memstore中，同一个region中存在多个列族则存在多个store，每个store都一个memstore，当其实memstore进行flush时，属于同一个region
  的store中的memstore都会进行flush，增加I/O开销
  HBase简单读写流程
  读：
  1,Client先访问zookeeper，从meta表获取相应region信息，然后找到meta表的数据
  2,根据namespace、表名和rowkey根据meta表的数据找到写入数据对应的region信息
  3,找到对应的regionserver
  4,把数据分别写到HLog和MemStore上一份
  4,MemStore达到一个阈值后则把数据刷成一个StoreFile文件。（若MemStore中的数据有丢失，则可以总HLog上恢复）
  5,当多个StoreFile文件达到一定的大小后，会触发Compact合并操作，合并为一个StoreFile，（这里同时进行版本的合并和数据删除。）
  6,当Storefile大小超过一定阈值后，会把当前的Region分割为两个（Split），并由Hmaster分配到相应的HRegionServer，实现负载均衡
  写：
  1,Client先访问zookeeper，从meta表读取region的位置，然后读取meta表中的数据。meta中又存储了用户表的region信息。
  2,根据namespace、表名和rowkey在meta表中找到对应的region信息
  3,找到这个region对应的regionserver
  4,查找对应的region
  5,先从MemStore找数据，如果没有，再到StoreFile上读(为了读取的效率)。
  每天百亿数据存入HBase，如何保证数据的存储正确和在规定的时间里全部录入完毕，不残留数据
  1）存入HBase：普通写入是用JavaAPI put来实现，批量导入推荐使用BulkLoad
  2）保证数据的正确：这里需要考虑RowKey的设计、预建分区和列族设计等问题
  3）在规定时间内完成也就是存入速度不能过慢，并且当然是越快越好，使用BulkLoad
  HBASE和mysql比较
  Hbase的优点
  1 列的可以动态增加，并且列为空就不存储数据,节省存储空间.
  2 Hbase自动切分数据，使得数据存储自动具有水平scalability.
  3 Hbase可以提供高并发读写操作的支持
  Hbase的缺点：
  1 不能支持条件查询，只支持按照Row key来查询.
  2 暂时不能支持Master server的故障切换,当Master宕机后,整个存储系统就会挂掉.
  补充
  1.数据类型，Hbase只有简单的字符类型，所有的类型都是交由用户自己处理，它只保存字符串。而关系数据库有丰富的类型和存储方式。
  2.数据操作：HBase只有很简单的插入、查询、删除、清空等操作，表和表之间是分离的，没有复杂的表和表之间的关系，而传统数据库通常有各式各样的函数和连接操作。
  3.存储模式：HBase是基于列存储的，每个列族都由几个文件保存，不同的列族的文件时分离的。而传统的关系型数据库是基于表格结构和行模式保存的
  4.数据维护，HBase的更新操作不应该叫更新，它实际上是插入了新的数据，而传统数据库是替换修改
  5.可伸缩性，Hbase这类分布式数据库就是为了这个目的而开发出来的，所以它能够轻松增加或减少硬件的数量，并且对错误的兼容性比较高。而传统数据库通常需要增加中间层才能实现类似的功能
  HIVE HBASE 区别
  两个完全不同的技术
  hive可以认为是map-reduce的一个包装。hive的意义就是把好写的hive的sql转换为复杂难写的map-reduce程序。
  hbase可以认为是hdfs的一个包装。他的本质是数据存储，是个NoSql数据库；hbase部署于hdfs之上，并且克服了hdfs在随机读写方面的缺点。
  HBASE中compact用途是什么，什么时候触发，分为哪两种,有什么区别，有哪些相关配置参数
  在hbase中每当有memstore数据flush到磁盘之后，就形成一个storefile，当storeFile的数量达到一定程度后，就需要将 storefile 文件来进行 compaction 操作。
  Compact 的作用：
  1>.合并文件
  2>.清除过期，多余版本的数据
  3>.提高读写数据的效率
  HBase 中实现了两种 compaction 的方式：minor and major. 这两种 compaction 方式的区别是：
  1、Minor 操作只用来做部分文件的合并操作以及包括 minVersion=0 并且设置 ttl 的过期版本清理，不做任何删除数据、多版本数据的清理工作。
  2、Major 操作是对 Region 下的HStore下的所有StoreFile执行合并操作，最终的结果是整理合并出一个文件。
  HBASE预分区
  减少由于region split带来的资源消耗。从而提高HBase的性能
  create ‘t1’, ‘f1’, SPLITS => [‘10’, ‘20’, ‘30’, ‘40’]
  提高HBASE的读写性能
  （1）开启bloomfilter过滤器，开启bloomfilter比没开启要快3、4倍
  （2）在硬件允许的情况下配足够多的内存给它
  通过修改hbase-env.sh中的
  export HBASE_HEAPSIZE=3000 #这里默认为1000m
  （3）增大RPC数量
  通过修改hbase-site.xml中的
  hbase.regionserver.handler.count属性，可以适当的放大。默认值为10有点小
  （4） 做程序开发是注意的地方
  需要判断所求的数据行是否存在时，尽量不要用HTable.exists(final byte [] row)
  而用HTable.exists(final byte [] row, final byte[]column)等带列族的方法替代。
  不要使用HTable.get(final byte [] row, final byte []column) == null来判断所求的数据存在，而是用HTable.exists(final byte [] row, final byte[] column)替代
  LSMtree原理以及应用
  特点
  总的来说就是通过将大量的随机写转换为顺序写，从而极大地提升了数据写入的性能，虽然与此同时牺牲了部分读的性能。
  只适合存储 key 值有序且写入大于读取的数据，或者读取操作通常是 key 值连续的数据
  写入
  在 LSM Tree 中，写入操作是相当快速的，只需要在 WAL 文件中顺序写入当次操作的内容，成功之后将该 k-v 数据写入 MemTable 中即可。尽管做了一次磁盘 IO，但是由于是顺序追加写入操作，效率相对来说很高，并不会导致写入速度的降低。数据写入 MemTable 中其实就是往 SkipList 中插入一条数据，过程也相当简单快速。
  读取：
  LSM Tree 的读取效率并不高，当需要读取指定 key 的数据时，先在内存中的 MemTable 和 Immutable MemTable 中查找，如果没有找到，则继续从 Level 0 层开始，找不到就从更高层的 SSTable 文件中查找，如果查找失败，说明整个 LSM Tree 中都不存在这个 key 的数据。如果中间在任何一个地方找到这个 key 的数据，那么按照这个路径找到的数据都是最新的。
  在每一层的 SSTable 文件的 key 值范围是不重复的，所以只需要查找其中一个 SSTable 文件即可确定指定 key 的数据是否存在于这一层中。Level 0 层比较特殊，因为数据是 Immutable MemTable 直接写入此层的，所以 Level 0 层的 SSTable 文件的 key 值范围可能存在重复，查找数据时有可能需要查找多个文件。
  总结：
  由于时间序列数据库的特性，运用 LSM Tree 的算法非常合适。持续写入数据量大，数据和时间相关，编码到 key 值中很容易使 key 值有序。读取操作相对来说较少，而且通常不是读取单个 key 的值，而是一段时间范围内的数据，这样就把 LSM Tree 读取性能差的劣势缩小了，反而由于数据在 SSTable 中是按照 key 值顺序排列，读取大块连续的数据时效率也很高。

HBASE过滤器相关问题
Bloom filter原理：
个人认为布隆过滤器原理就类似于hashTable，复杂度很低，就是数组级别的，在hbase插入时候，bloom会把自己所有的空间设置成m个比特位，其值均为0，插入的id，会通过m个hash函数，生成m个信息指纹，再通过一个hash函数，把这些英系指纹映射为m个比特位，并把这些比特位值设置为1，当在查询时候也执行这些操作，查看是否对应的比特位均为1，不存在的值不可能都为1，但是都为1，可能会不存在，这里就存在一个误判的问题，按时几率不大，这里解决的也就是一个数据库有这条记录进行查询，无记录，直接返回空。

https://blog.csdn.net/u013384984/article/details/80808353

https://blog.csdn.net/qq595662096/article/details/81297156

https://blog.csdn.net/HaixWang/article/details/79514886

https://blog.csdn.net/lp284558195/article/details/80406847

https://m.toutiaolite.com/i6627456650460529159/?iid=52195082048&app=news_article×tamp=1543207321&group_id=6627456650460529159&tt_from=weixin_moments&utm_source=weixin_moments&utm_medium=toutiao_ios&utm_campaign=client_share&wxshare_count=2&from=timeline&isappinstalled=0&pbid=6661784048241722883