Hbase基础优化

HBase的操作数据的步骤?

• Hbase写数据过程：
  • Client写⼊ -> 存⼊MemStore，⼀直到MemStore满 -> Flush成⼀个StoreFile，直⾄增长到⼀定阈值 -> 出发Compact合并操作 -> 多个StoreFile合并成⼀个StoreFile，同时进⾏版本合并和数据删除 -> 当StoreFiles Compact后，逐步形成越来越⼤的StoreFile -> 单个StoreFile⼤⼩超过⼀定阈值后，触发Split操作，把当前Region Split成2个Region，Region会下线，新Split出的2个孩⼦Region会被HMaster分配到相应的HRegionServer 上，使得原先1个Region的压⼒得以分流到2个Region上由此过程可知，HBase只是增加数据，有所得更新和删除操作，都是在Compact阶段做的，所以，⽤户写操作只需要进⼊到内存即可⽴即返回，从⽽保证I/O⾼性能。
• Hbase读数据：
  client -> zookeeper ->.ROOT ->.META -> ⽤户数据表zookeeper记录了.ROOT的路径信息（root只有⼀个region），.ROOT⾥记录了.META的region信息（.META可能有多个region），.META⾥⾯记录了region的信息。

HDFS和HBase各⾃使⽤场景

⾸先⼀点需要明⽩：Hbase是基于HDFS来存储的。

HDFS：

• ⼀次性写⼊，多次读取。
• 保证数据的⼀致性。
• 主要是可以部署在许多廉价机器中，通过多副本提⾼可靠性，提供了容错和恢复机制。

HBase：

• 瞬间写⼊量很⼤，数据库不好⽀撑或需要很⾼成本⽀撑的场景。
• 数据需要长久保存，且量会持久增长到⽐较⼤的场景
• HBase不适⽤与有join，多级索引，表关系复杂的数据模型
• ⼤数据量 （100s TB级数据） 且有快速随机访问的需求。
  如：淘宝的交易历史记录。数据量巨⼤⽆容置疑，⾯向普通⽤户的请求必然要即时响应。
• 容量的优雅扩展⼤数据的驱使，动态扩展系统容量。例如：webPage DB。
• 业务场景简单，不需要关系数据库中很多特性（例如交叉列、交叉表，事务，连接等等）
• 优化⽅⾯：合理设计rowkey

RowKey的设计原则？

• 总的原则：避免热点现象，提⾼读写性能；
• 长度原则：rowkey是⼀个⼆进制码流，可以是任意字符串，最⼤长度 64kb ，实际应⽤中⼀般为10-100bytes，以 byte[]形式保存，⼀般设计成定长。建议越短越好，不要超过16个字节，原因如下：数据的持久化⽂件HFile中是按照KeyValue存储的，如果rowkey过长，⽐如超过100字节，1000w⾏数据，光rowkey就要占⽤100*1000w=10亿个字节，将近1G数据，这样会极⼤影响HFile的存储效率；MemStore将缓存部分数据到内存，如果rowkey字段过长，内存的有效利⽤率就会降低，系统不能缓存更多的数据，这样会降低检索效率。⽬前操作系统都是64位系统，内存8字节对齐，控制在16个字节，8字节的整数倍利⽤了操作系统的最佳特性；
• 散列原则：如果rowkey按照时间戳的⽅式递增，不要将时间放在⼆进制码的前⾯，建议将rowkey的⾼位作为散列字段，由程序随机⽣成，低位放时间字段，这样将提⾼数据均衡分布在每个RegionServer，以实现负载均衡的⼏率。如果没有散列字段，⾸字段直接是时间信息，所有的数据都会集中在⼀个RegionServer上，这样在数据检索的时候负载会集中在个别的RegionServer上，造成热点问题，会降低查询效率；
• 唯⼀原则：必须在设计上保证其唯⼀性，rowkey是按照字典顺序排序存储的，因此，设计rowkey的时候，要充分利⽤这个排序的特点，将经常读取的数据存储到⼀块，将最近可能会被访问的数据放到⼀块。
• Rowkey设计结合业务：在满⾜rowkey设计原则的基础上，往往需要将经常⽤于查询的字段正和岛rowkey上，以提⾼检索查询效率

hbase、hregion、max.filesize应该设置多少合适?

• 默认是256，HStoreFile的最⼤值。如果任何⼀个Column Family（或者说HStore）的HStoreFiles的⼤⼩超过这个值，那么，其所属的HRegion就会Split成两个。
• 众所周知hbase中数据⼀开始会写⼊memstore，当memstore满64MB以后，会flush到disk上⽽成为storefile。当storefile数量超过3时，会启动compaction过程将它们合并为⼀个storefile。这个过程中会删除⼀些timestamp过期的数据，⽐如update的数据。⽽当合并后的storefile⼤⼩⼤于hfile默认最⼤值时，会触发split动作，将它切分成两个region。

HBase存储单元Cell?

• 单元{row key，column(= < family>+< label>),version}
• 唯⼀性；数据是没有类型的，以字节码形式存储
• 表：(⾏key，列族+列名，版本(timestamp))->值

HBase的客户端Client？

• 整个HBase集群的访问⼊⼜；
• 使⽤HBase RPC机制与HMaster和HRegionServer进⾏通信；
• 与HMaster通信进⾏管理类操作；
• 与HRegionServer进⾏数据读写类操作；
• 包含访问HBase接⼜，并维护cache来加快对HBase的访问

介绍HBase⼆级索引？

• HBase提供了检索数据的功能，不过原有系统仅提供了通过rowkey检索数据的功能，过于单⼀，不灵活，⼀旦查询条件改变了往往涉及到要全表扫描过滤，极⼤浪费机器物理资源，又达不到实时的⼀个效果。HBase⼆级索引功能解决了原有HBase系统中仅能够通过rowkey检索数据的问题，使得⽤户能够指定多种条件，在HBase表中进⾏数据的实时检索与统计。
• HBase只提供了⼀个基于字典排序的主键索引，在查询中只能通过⾏键查询或者扫描全表来获取数据。
• HBase基于rowkey的全局索引：Zookeeper的znode节点/hbase/meta-region-server -> hbase:mat

哪些HBase优化⽅法?

优化⼿段主要有以下四个⽅⾯

• 减少调整
  减少调整这个如何理解呢？HBase中有⼏个内容会动态调整，如region（分区）、HFile，所以通过⼀些⽅法来减少这些会带来I/O开销的调整
  • Region
    如果没有预建分区的话，那么随着region中条数的增加，region会进⾏分裂，这将增加I/O开销，所以解决⽅法就是根据你的RowKey设计来进⾏预建分区，减少region的动态分裂
  • HFile
    HFile是数据底层存储⽂件，在每个memstore进⾏刷新时会⽣成⼀个HFile，当HFile增加到⼀定程度时，会将属于⼀个region的HFile进⾏合并，这个步骤会带来开销但不可避免，但是合并后HFile⼤⼩如果⼤于设定的值，那么HFile会重新分裂。为了减少这样的⽆谓的I/O开销，建议估计项⽬数据量⼤⼩，给HFile设定⼀个合适的值
• 减少启停
  数据库事务机制就是为了更好地实现批量写⼊，较少数据库的开启关闭带来的开销，那么HBase中也存在频繁开启关闭带来的问题。
  • 关闭Compaction，在闲时进⾏⼿动Compaction
    因为HBase中存在Minor Compaction和Major Compaction，也就是对HFile进⾏合并，所谓合并就是I/O读写，⼤量的HFile进⾏肯定会带来I/O开销，甚⾄是I/O⻛暴，所以为了避免这种不受控制的意外发⽣，建议关闭⾃动Compaction，在闲时进⾏compaction批量数据写⼊时采⽤BulkLoad
    如果通过HBase-Shell或者JavaAPI的put来实现⼤量数据的写⼊，那么性能差是肯定并且还可能带来⼀些意想不到的问题，所以当需要写⼊⼤量离线数据时建议使⽤BulkLoad
• 减少数据量
  虽然我们是在进⾏⼤数据开发，但是如果可以通过某些⽅式在保证数据准确性同时减少数据量，何乐⽽不为呢？
  开启过滤，提⾼查询速度
  • 开启BloomFilter，BloomFilter是列族级别的过滤，在⽣成⼀个StoreFile同时会⽣成⼀个MetaBlock，⽤于查询时过滤数据
  • 使⽤压缩：⼀般推荐使⽤Snappy和LZO压缩
• 合理设计
  在⼀张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开销

HRegionServer宕机如何处理？

• ZooKeeper会监控HRegionServer的上下线情况，当ZK发现某个HRegionServer宕机之后会通知HMaster进⾏失效备援；
• 该HRegionServer会停⽌对外提供服务，就是它所负责的region暂时停⽌对外提供服务
• HMaster会将该HRegionServer所负责的region转移到其他HRegionServer上，并且会对HRegionServer上存在memstore中还未持久化到磁盘中的数据进⾏恢复
• 这个恢复的⼯作是由WAL重播来完成，这个过程如下：
  • wal实际上就是⼀个⽂件，存在/hbase/WAL/对应RegionServer路径下
  • 宕机发⽣时，读取该RegionServer所对应的路径下的wal⽂件，然后根据不同的region切分成不同的临时⽂件recover.edits
  • 当region被分配到新的RegionServer中，RegionServer读取region时会进⾏是否存在recover.edits，如果有则进⾏恢复

HBase简单读写流程？

读：

• 找到要读取数据的region所在的RegionServer，然后按照以下顺序进⾏读取：先去BlockCache读取，若BlockCache没有，则到Memstore读取，若MemStore中没有，则到HFile中读取。
  写：
• 找到要写⼊数据的region所在的RegionServer，然后将数据先写到WAL中，然后再将数据写到MemStore等待刷新，回复客户端写⼊完成。

HBase和Hive的对⽐

	HBase	Hive
类型	列式数据库	数据仓库
内部机制	数据库引擎	MapReduce
增删改查	都⽀持	只⽀持导⼊和查询
Schema	只需要预先定义列族，不需要具体到列，列可以动态修改	需要预先定义表格
应⽤场景	实时	离线处理
特点	以K-V形式存储	类SQL

HBase与传统关系型数据库(如MySQL)的区别？

• 数据类型：没有数据类型，都是字节数组（有⼀个⼯具类Bytes，将java对象序列化为字节数组）。
• 数据操作：HBase只有很简单的插⼊、查询、删除、清空等操作，表和表之间是分离的，没有复杂的表和表之间的关 系，⽽传统数据库通常有各式各样的函数和连接操作。
• 存储模式：Hbase适合于⾮结构化数据存储，基于列存储⽽不是⾏。
• 数据维护：HBase的更新操作不应该叫更新，它实际上是插⼊了新的数据，⽽传统数据库是替换修改
• 时间版本：Hbase数据写⼊cell时，还会附带时间戳，默认为数据写⼊时RegionServer的时间，但是也可以指定⼀个不 同的时间。数据可以有多个版本。
• 可伸缩性，Hbase这类分布式数据库就是为了这个⽬的⽽开发出来的，所以它能够轻松增加或减少硬件的数量，并且 对错误的兼容性⽐较⾼。⽽传统数据库通常需要增加中间层才能实现类似的功能

请描述如何解决Hbase中region太⼩和region太⼤带来的冲突？

Region过⼤会发⽣多次compaction，将数据读⼀遍并重写⼀遍到hdfs 上，占⽤io，region过⼩会造成多次split，region会下线，影响访问服务，调整hbase.hregion.max.filesize 为256m.

解释下 hbase 实时查询的原理？

实时查询，可以认为是从内存中查询，⼀般响应时间在 1 秒内。 HBase 的机制是数据先写⼊到内存中，当数据量达到⼀定的量（如 128M），再写⼊磁盘中， 在内存中，是不进⾏数据的更新或合并操作的，只增加数据，这使得⽤户的写操作只要进⼊内存中就可以⽴即返回，保证了 HBase I/O 的⾼性能

HBase 宕机如何处理？

宕机分为 HMaster 宕机和 HRegisoner 宕机。

• 如果是 HRegisoner 宕机， HMaster 会将其所管理的 region 重新分布到其他活动的 RegionServer 上，由于数据和⽇志都持久在 HDFS中，该操作不会导致数据丢失。所以数据的⼀致性和安全性是有保障的。
• 如果是 HMaster 宕机， HMaster 没有单点问题， HBase 中可以启动多个 HMaster，通过Zookeeper 的Master Election 机制保证总有⼀个 Master 运⾏。即 ZooKeeper 会保证总会有⼀个 HMaster 在对外提供服务

什么时候适合使⽤HBase（应⽤场景）？

1. 半结构化或⾮结构化数据:
2. 对于数据结构字段不够确定或杂乱⽆章⾮常难按⼀个概念去进⾏抽取的数据适合⽤HBase，因为HBase⽀持动态添加列。
3. 记录很稀疏：
4. RDBMS的⾏有多少列是固定的。为null的列浪费了存储空间。⽽如上⽂提到的，HBase为null的Column不会被存储，
   这样既节省了空间⼜提⾼了读性能。
5. 多版本号数据：
6. 依据Row key和Column key定位到的Value能够有随意数量的版本号值，因此对于须要存储变动历史记录的数据，⽤HBase是很⽅便的。⽐⽅某个⽤户的Address变更，⽤户的Address变更记录也许也是具有研究意义的。
7. 仅要求最终⼀致性：
8. 对于数据存储事务的要求不像⾦融⾏业和财务系统这么⾼，只要保证最终⼀致性就⾏。（⽐如HBase+elasticsearch时，可能出现数据不⼀致）
9. ⾼可⽤和海量数据以及很⼤的瞬间写⼊量：
10. WAL解决⾼可⽤，⽀持PB级数据，put性能⾼
11. 索引插⼊⽐查询操作更频繁的情况。⽐如，对于历史记录表和⽇志⽂件。（HBase的写操作更加⾼效）
12. 业务场景简单：
13. 不需要太多的关系型数据库特性，列⼊交叉列，交叉表，事务，连接等