关于Hbase的一些问题
HBase
1. RowKey如何设计，设计不好会产生什么后果
唯一原则：在设计上要保持RowKey的唯一性。
- 因为HBase中的数据是以KV的格式来存储的，所以如果向同一张表中插入RowKey相同的数据，旧的数据会被覆盖掉。
长度原则：建议RowKey的长度不要过长最好不要超过十六字节。对齐RowKey长度。
- 因为数据的持久化文件HFile是按照Key Value存储的，如果RowKey的长度过长，会使得文件过大，从而影响HFile的存储效率。
- MemStore将缓存部分数据到内存，如果RowKey的长度过长就会导致内存的有效利用率降低，系统将无法缓存更多的数据，降低检索速率。
散列原则：设计出来的RowKey需要均匀的分布在各个RegionServer上。
- 如果数据分布的不均匀就可能会造成数据倾斜的发生，进一步导致热点问题的出现，最终造成节点崩溃。
2. 列族如何设计，为什么不建议HBase设计过多列族
-
HBase的列族不是越多越好，官方推荐一个表的列族最好不超过三个，过多的列族不利于HBase数据的管理和索引。
-
将所有相关性很强的key_value都放在同一个列族。这样可以增加查询效率，减少访问不同的磁盘文件。
-
列族的长度尽可能小，一个是为了增加查询速率，一个是为了节省空间。
- 内存开销：列族过多，内存开销会逐渐积累，导致RegionServer的内存占用增加，影响集群的稳定性。
- 磁盘开销：过多的列族会导致更多的磁盘寻址和IO操作，增加磁盘开销。
- 查询性能下降：查询跨越多个列族，会影响性能。
- 写入性能下降：写入操作需要锁定列族，列族过多会导致性能下降。
3. HBase读取数据的流程
- Client访问Zookeeper，获取hbase:meta所在的HRegionServer的节点信息；
- Client访问hbase:meta所在的HRegionServer，获取hbase:meta记录的元数据后加载到内存中，然后再从内从中查询出RowKey所在的Hregion（HRegion所在的HRegionServer）；
- Client对RowKey所在的HRegion对应的HRegionServer发起读取请求；
- HRegionServer构建RegionScanner（需要查询的RowKey分布在多少个HRegion中就需要构建多少个RegionScanner），用于对该HRegion的数据检索；
- RegionScanner构建StoreScanner（HRegion中有多少个Store就需要构建多少个StoreScanner，Store的数量取决于表中的列族的数量），用于对该列族的检索；
- 所有的StoreScanner合并构建最小堆（已排序的完全二叉树）StoreHeap:PriorityQueue；
- StoreScanner构建一个MemStoreScanner和一个或多个StoreFIleScanner（数量取决于StoreFile的数量）；
- 过滤掉能够确定索要查询的RowKey一定不存在的StoreFileScanner或MemStoreScanner（布隆过滤器）；
- 经过筛选后留下的Scanner开始做读取数据的准备，将对应的StoreFile定位到满足的RowKey的起始位置；
- 将所有的StoreFileScanner和MemStoreScanner合并构建最小堆KeyValueHeap:PriorityQueue，排序的规则按照KeyValue从小到大排序；
- 从KeyValueHeap：PriorityQueue中经过一系列筛选后一行行的得到需要查询的KeyValue。
4. HBase写入数据的流程
- Client访问ZooKeeper,获取hbase:meta所在的HRegionServer的节点信息；
- Client访问hbase:meta所在的HRegionServer，获取hbase:meta记录的元数据后现加载到内存中，然后再从内存中查询出RowKey所在的HRegion（HRegion所在的HRegionServer）；
- Client对RowKey所在的HRegion对应的HRegionServer发起写入请求；
- 建立连接后，首先将DML要做的操作写入到日志HLog；
- 然后将数据的修改更新到MemStore中，本次操作结束。一个HRegion由多个Store组成，一个Store对应一个列族，Store包括位于内存的MemStore和位于磁盘的StoreFile，写入操作先写入MemStore；
- 当MemStore数据达到阈值后（128M），创建一个新的MemStore；
- 旧的MemStore将刷写成为一个独立的StoreFIle（HRegionServer会启动FlushCache进程写入StoreFIle）并存放到HDFS，最后删除HLog中的历史数据。
5. Hive 和 HBase的区别
HBase和Hive都是架构在Hadoop之上的，都使用了HDFS作为底层存储。
不同点：
- Hive是一个数仓工具，可以将结构化数据映射为表格。HBase是一个分布式的非关系型数据库。
- Hive本身并不存储和计算数据，它底层通过Hadoop的MapReduce框架来处理数据。HBase底层使用HDFS和ZooKeeper分布式协调服务来存储和管理数据。
- HBase是物理表，提供了一个超大内存的Hash表，搜索引擎通过它来存储索引，方便查询操作。
- Hive不支持随机写入操作，HBase支持随机写入操作。
- Hive适合查询和分析结构化数据，HBase适合存储和查询非结构化数据。
6. 为什么要使用Phoenix
- 提供标准的SQL以及完备的ACID事务支持；
- 通过利用HBase作为存储，让NoSQL数据库具备通过有模式的方式读取数据，可以使用SQL语句来操作HBase。
- Phoenix通过协处理器在服务器端执行操作，最小化客户机/服务器数据传输。
- Phoenix可以很好地与其他的Hadoop组件整合到一起，例如Spark、Hive等。
Phoenix只是在HBase之上构建了SQL查询引擎，Phoenix可以使用SQl快速查询HBase中的数据，但是数据的底层必须符合HBase的存储结构，HBase结合Phoenix可以实现海量数据的快速随机读写。Phoenix就相当于一个特别好用的皮肤，方便了程序员的操作。
7. HBase的热点Key会产生什么问题
HBase中的热点Key是指在同一时间内被频繁访问的行键，造成少数RegionServer的读写请求过多，负载过大，而其他RegionServer负载却很小，造成热点现象。
- 读写性能下降：由于多个请求涌入到一台RegionServer中，导致该RegionServer的负载过高，从而影响读写性能。
- 均衡性差：由于不同RegionServer负责不同的Region，而热点Key的存在会导致某些RegionServer的负载过高，从而影响整个集群的负载不平衡。
- 单点故障：如果某个RegionServer负责的某个Region出现热点Key问题，该RegionServer发生故障会导致该Region不可用，从而影响整个集群的可用性。
避免HBase的热点Key的方式：
- 合理设计RowKey
- 采用哈希算法对RowKey进行分片，使数据分布更均匀
- 使用预分区技术
8. 说一说HBase的数据刷写与合并
数据刷写（FLush）：数据刷写是将内存中的数据写入到磁盘存储的过程。在HBase中，写入的数据首先会被缓存在内存的MemStore中，而不是直接写入磁盘。当MemStore中的数据达到一定大小阈值时，或者出发了一定的时间阈值，HBase会将该MemStore中的数据刷写到磁盘，生成一个新的Store文件。这样可以减少磁盘的随机写入操作，提高写入性能。
数据合并（Comoaction）：数据合并是将多个Store文件合并成为一个更大的文件的过程。在HBase中，随着数据的写入和删除，会产生大量的小文件，这样对于查询操作会引入额外的磁盘寻址开销。为了优化性能和减少磁盘空间的占用，HBase会定期执行那个数据合并操作。数据合并会将多个Store文件合并成更大的文件，从而减少文件数量和磁盘寻址次数。
- 触发数据合并的三种方式：MemStore刷盘，后台线程周期性检查，手动触发。
- 小合并（Minor Compaction）：当一个Region中的Store文件达到一定的数量或累积了一定大小时，会触发小合并。小合并只会合并相邻的几个Store文件，并生成一个新的更大的文件。
- 不做任何删除数据、多版本数据的清理工作，但是会对 minVersion=0 并且设置 TTL 的过期版本数据进行清理。
- 大合并（Major Compaction）：当一个Region中的Store文件数量达到一定阈值，或者手动触发大合并操作时，会执行大合并。大合并会将所有的Store文件都合并为一个更大的文件。大合并 可以进一步优化查询性能和节省磁盘空间，但相应地需要更多的计算和IO资源。
- 清理三类无意义数据：被删除的数据、TTL 过期数据、版本号超过设定版本号的数据。