建议先阅读前文HBase Snapshot基本原理。
HBase作为数据库，可以用于线上TP类需求，但如果直接基于HBase表运行AP类的离线分析型任务，则有2个问题：
所以HBase提供了工具，可以直接越过HBase层直接读存储在HDFS上的文件，常用的就是Scan Snapshot功能。好处是：
公司的HBase集群偶尔有个很奇怪的现象：内存占用会逐渐升高，超过堆内堆外内存限制，直到把操作系统内存占满被oom-killer杀死。在内存占用逐步升高的期间，响应延迟越来越高，最终服务宕机也会造成集群抖动，影响SLA。
内存增长过程非常缓慢，大概一两个月宕机一次。之前一直苦恼于没有现场，这次终于抓到了一个稳定复现的集群。
目前还没正式修复，修复验证也要几周时间，所以等我验证后再补充效果。
现代数据库中，为提高并发行能，对于读写冲突，往往避免采用全程加锁的方案，而采用MVCC多版本并发控制。
本文简单介绍下HBase的MVCC的实现机制。
成熟的数据库都有备份与恢复的功能，在意外或故障时还能尽量恢复数据，同时还能实现数据迁移。接下来就是介绍HBase的备份与恢复功能——Snapshot。
出于学习目的，代码参考社区master分支，最接近的release版本应该是3.0.0-alpha-4，目前肯定是没有公司在线上使用的。也许实现细节上会有些区别，但核心逻辑基本一致。
HBase Snapshot具备以下能力：
在基于LSMT实现的数据库中，compaction是很重要的机制。compaction虽然有助于维持长期运行过程中的读低延迟，但在compaction过程中读延迟牺牲大。这篇论文中，深度分析了compaction相关的性能损耗，并提出了缓解的技术。我们将大的昂贵的compaction offload到了单独的compaction server，让datastore server更好地利用他自己的资源。此外，因为新compact的数据已经在compaction server的主内存里了，我们通过网络从compaction server把数据抓到datastore server的本地内存，避免读filesystem的性能损耗。事实上，在把workload切换到compaction server之前，预取 compact的数据已经可以消除缓存失效的影响，这时候compaction server只当是远程缓存。因此，我们实现了一个更智能的预热算法确保所有读请求都能被datastore server的本地缓存服务，即使它还在预热。我们已经集成进了hbase，使用YCSB和TPC-C的benchmark显示我们的方法显著消除了compaction相关的性能问题。也展示了compaction server可扩展性。
最近在组内进行的一次SCP和TRSP两个Procedure执行过程的分享，在这里记录一下，懒得去整理出文章了 😜
最近接到两个用户提的JIRA，都是目前数据只存在了一个srv集群，需要将数据备份prc集群做数据备份或者离线计算，同时两集群之间还要做数据实时同步。所以在这里记录下操作过程并介绍下原因。