八年磨一剑，阿里云ApsaraDB for HBase2.0正式上线

一、HBase2.0和阿里云的前世今生

      ApsaraDB for HBase2.0于2018年6月6日即将正式发布上线啦！       ApsaraDB for HBase2.0是基于社区HBase2.0稳定版的升级，也是阿里HBase多年的实践经验和技术积累的持续延伸，全面解决了旧版本碰到的核心问题，并做了很多优化改进，附加HBase2.0 开源新特性，可以说是HBase生态里的一个里程碑。       HBase在2007年开始发布第一个“可用”版，2010年成为Apache的顶级项目，阿里巴巴集团也在2010当年就开始研究,于2011年就已经开始把HBase投入生产环境使用，并成为阿里集团主要的存储系统之一。那个时候HBase已经运行在上千台级别的大集群上，阿里巴巴可以说算是HBase当时得到最大规模应用的互联网公司之一。从最初的淘宝历史交易记录，到蚂蚁安全风控数据存储，HBase在几代阿里专家的不懈努力下，HBase已经表现得运行更稳定、性能更高效，是功能更丰富的集团核心存储产品之一。       阿里集团自2012年培养了第一位“东八区” HBase Committer，到今天，阿里巴巴已经拥有3个PMC，6个Committer，阿里巴巴是中国拥有最多HBase Committer的公司之一。他们贡献了许多bug fix以及性能改进feature等，很可能你在用的某个特性，正是出自他们之手。他们为HBase社区，也为HBase的成长贡献了一份宝贵的力量。当然，也孕育了一个更具有企业针对性的云上HBase企业版存储系统——ApsaraDB for HBase。       ApsaraDB for HBase2.0是基于开源HBase2.0基础之上，融入阿里HBase多年大规模实战检验和技术积累的新一代KV数据库产品，结合了广大企业云上生产环境的需求，提供许多商业化功能，比如 HBase on OSS、HBase云环境公网访问、HBase on 本地盘、HBase on 共享存储、冷热分离、备份恢复、HBase安全机制等等，是适合企业生产环境的企业级大规模云KV数据库。       ApsaraDB for HBase2.0，源于HBase，不仅仅是HBase!

二、深入解读云HBase架构

      ApsaraDB for HBase2.0是建立在庞大的阿里云生态基础之上，重新定义了HBase云上的基础架构，对企业云上生产需求更有针对性，满足了许多重要的云上应用场景。其中最常见的有：存储计算分离、一写多读、冷热分离、SQL/二级索引、安全等。下面针对这些场景简单介绍一下ApsaraDB for HBase2.0的基础架构。

2.1 存储计算分离

      早期存储和计算一般都是一起的，这样做带来的好处是数据本地化，不消耗网络资源。但是这会带来一个问题，给应用企业对集群起初的规划带来一定的难度，如果一开始使用过大的存储、过大的计算资源，就是一种浪费，但是如果开始规划存储、计算过小，后期运维升级扩展有变得非常复杂，甚至升级/扩展过程会出现故障等等问题，这些都不不企业业务发展规划不可忽略的问题。       随着网络技术的发展，现在已经进入25G甚至100G以上时代，网络带宽已经不再是瓶颈。ApsaraDB for HBase2.0建立在阿里云之上，利用阿里云强大基础技术，实现了云上HBase的高性能存储计算分离的架构。

      如上图所示，分布式region如上图所示，分布式region计算层负责HBase相关的数据库逻辑运算操作; 通过分布式HDFS&API接口读写远端底层分布式文件存储系统；其中远端读写质量和安全隔离由QOS层保障，QOS层利用高性能硬件加速远端读写性能，保障了存储分离的性能、安全要求；最终读写落到分布式存储层，分布式存储层通过副本形式保障数据安全可靠，可以容忍单节点、单rack fail的数据可靠性。云上HBase计算存储分离架构的实现，使得用户集群规划则变得简单很多，存储容量动态扩展，计算资源动态升配。基本不需要估算未来业务的规模了，真正做到按需使用，帮助用户在业务运行之初就开始尽可能地降低成本，同时又可以随时满足业务发展导致资源的弹性扩展的需要。

2.2 冷热分离/分级存储

      一般企业随着业务数据不断增长，数据量开始变大，这个时候就需要对数据进行冷热程度区分对待，以优化系统整体运行效率，并降低成本。举个例子，如：冷数据写入一次后，可能很久才被访问一次，但是因为和热数据存储在一个数据块上，可能读这个热数据的时候，冷数据也被顺带读到内存中，这可能是没有必要的，我们更多希望被顺带读出来的也是即将被访问的热数据。另外，因为热数据的频繁更新写入，可能会引起系统更多得split、compaction等动作，这个时候，冷数据也被顺带一起多次读写磁盘了，实际上冷数据可能不需要这么频繁地进行这种系统动作。再从成本考虑，业务上如果普遍可以接受陈年旧事——冷数据被访问延时相对高一点点，那么就可以考虑把这些数据存储在成本较低的介质中。       基于这种常见的企业场景需求，ApsaraDB for HBase2.0在阿里云基础体系之上，设计了云HBase冷热分离/分级存储架构，实现企业云上HBase应用的冷热分离场景需求，提高系统运行效率的同时，又降低存储成本。

      如图所示，架构分两阶段，第一阶段实现分级存储，用户可以清晰的按照不同访问频度将数据存储到不同冷热级别的表上，从表级别上区分冷热数据，实现分级存储。第二阶段是同表数据冷热数据自动分离，用户可以按照访问频率或者创建时间等条件，指定冷热数据判断标准依据，最终后端自动分离冷热数据分别存储。

2.3 一写多读/读高可用

      在旧版HBase运行的时候，当一台机器宕机的时候，这个机器所负责的region主要需要经历3个的处理流程才能恢复读——发现宕机、重新分配此机器负责的region、上线region恢复。其中发现宕机可能就需要几十秒，依赖于zookeeper的session timeout时间。在这个恢复过程中，用户client是不可以读这些region数据的。也就是此架构的读不是高可用的，无法保证99.9%的延时都