1.HBase面试

1.HBase rowkey如何设计的

https://blog.csdn.net/wangshuminjava/article/details/80575864

实际工作设计:

a.列族整个部门统一使用一个命名空间和列族和rowkey规则;

b.rowkey设计原则,使用订单号的后4位的前3位作为flag进行分区,拼接多个关键字段保持rowkey唯一,依据字段使用权重决定拼接顺序;

c.数据查询,封装HBase的查询工具库,以HBase表为单位抽象为对象,包含通过rowkey获取数据和scan数据和hbase整表获取数据;

2.谈谈热点问题以及如何解决

https://blog.csdn.net/weixin_43203897/article/details/88208582

随机分布加预分区也不是一劳永逸的。因为数据是不断地增长的，随着时间不断地推移，已经分好的区域，或许已经装不住更多的数据，当然就要进一步进行split了，同样也会出现性能损耗问题，所以我们还是要规划好数据增长速率，观察好数据定期维护，按需分析是否要进一步分行手工将分区再分好，也或者是更严重的是新建表，做好更大的预分区然后进行数据迁移。如果数据装不住了，对于partition方式预分区的话，如果让它自然分裂的话，情况分严重一点。因为分裂出来的分区号会是一样的，所以计算到partitionId的话，其实还是回到了顺序写年代，会有部分热点写问题出现，如果使用partition方式生成主键的话，数据增长后就要不断地调整分区了，比如增多预分区，或者加入子分区号的处理.(我们的分区号为long型，可以将它作为多级partition)
————————————————

3.说下HBase的读写流程

https://blog.csdn.net/zhangshk_/article/details/83663642

https://blog.csdn.net/gingerredjade/article/details/63697830 (读流程)

和写流程相比，HBase读数据是一个更加复杂的操作流程，这主要基于两个方面的原因：其一是因为整个HBase存储引擎基于LSM-Like树实现，因此一次范围查询可能会涉及多个分片、多块缓存甚至多个数据存储文件；其二是因为HBase中更新操作以及删除操作实现都很简单，更新操作并没有更新原有数据，而是使用时间戳属性实现了多版本。删除操作也并没有真正删除原有数据，只是插入了一条打上”deleted”标签的数据，而真正的数据删除发生在系统异步执行Major_Compact的时候。很显然，这种实现套路大大简化了数据更新、删除流程，但是对于数据读取来说却意味着套上了层层枷锁，读取过程需要根据版本进行过滤，同时对已经标记删除的数据也要进行过滤。

https://blog.csdn.net/weixin_42644102/article/details/85679617?utm_medium=distribute.pc_relevant.none-task-blog-baidujs_baidulandingword-0&spm=1001.2101.3001.4242

HBASE(架构+读写流程)

4.HBase使用过程中做过哪些优化

https://blog.csdn.net/ruichaoo/article/details/78983128

整个项目程序运行期间建立一次hbase连接

预分区

批量写

多线程并发写

5.HBase的Compaction机制作用

https://blog.csdn.net/liaynling/article/details/54095702

Compaction是buffer->flush->merge的Log-Structured Merge-Tree(LSM)模型的关键操作，主要起到如下几个作用：

1）合并文件

2）清除删除、过期、多余版本的数据

3）提高读写数据的效率

1.HBase面试

公告