引言
最近云HBase商业化了，HBase在业界应用还是比较广泛。在云上环境下中，不少客户都自建了HBase集群，还有一部分用户是把HBase集群放在Hadoop离线集群内部。此文主要对比下云HBase数据库跟自建HBase的差异。另外，在成本上，云HBase数据库跟自建基本差不多，目前云HBase在推广打折阶段，比自建还便宜不少
自建HBase与ApsaraDB HBase对比
自建目前在云上，基本是基于ecs去自己构建，ApsaraDB HBase我们还是做了不少事情的：
- ApsaraDB HBase的内核在阿里集团使用5年，还是有不少的沉淀的，在一些场景有300%的性能提升，大部分场景都至少有30%的提升，在稳定性恢复速度快3倍左右。阿里现在有3个hbase pmc，6个committer了，有将近25+个人弄hbase
- ApsaraDB HBase的内核会主动修复bug，改进功能，升级的，把高版本有价值的patch打到我们的ApsaraDB HBase内核版本上。自己建设 往往要去下载新版本弄，有时候搞不好数据还丢了
- 安全机制比较健全，如：白名单、VPC、访问UI的账号密码，还有安全部门非得让弄成https加密的。后续会接阿里云的ak，支持共享环境访问ApsaraDB HBase，比如ODPS，开源版本是不行的
- 9月份会支持公网开放：比较方便支持线下测试开发连接环境。（不需要vpn、线下搭建或者proxy了）
- 运维还是比较便利的：15分钟全自动部署新集群、 可以在线扩容磁盘、容量报警、添加节点、修改配置、指标可视化、自动守护进程、链路监控报警 、热点检测转移、大scan过期清理 ………………
可以说这个是 ApsaraDB HBase的大概层次图：
关于把Hbase放到离线集群的坏处
之前阿里云没有提供ApsaraDB HBase的产品，在EMR我们包装了一个开源的HBase，不少用户就使用了这个HBase，后续造成EMR运维上很大的困难，hbase经常是由于离线作业跑的时候会挂掉，但是这个时候正式需要访问hbase的时候，如果这个时候有实时入库或者查询的操作，则影响非常大。另外，我们还不得不分配一定的资源给Regionserver，RS还是非常吃内存的，造成离线任务根本不够用的情况。为此，我们就把单独做了ApsaraDB HBase这个产品，做成全托管的方式，以取代EMR中的HBase
关于节约资源
在用户自建HBase集群时，不少客户基于CDH把HBase放在Hadoop中，想法主要是节约一些资源或者麻烦单独弄一个HBase。其实在云上环境中，磁盘及CPU及内存都是可以在线直接扩容的，比如ApsaraDB HBase的磁盘可以最低每次8G的扩容，计算资源也可以单独添加节点。 资源本身基本是很小粒度可以增加的。整体资源其实是相当的（因为HBase需要起着就占资源），另外，如果把分析按量跑，其实成本反到下降不少（EMR支持定时按需跑job）。另外，还可以享受稳定及高性能的服务。
关于性能
spark访问hbase，再hbase放在hdfs。其实spark并不能享受本地化的好处，spark往往访问region的，region往往不在这个机器上，比如你有10台机器，则在这个上面的概率是10%，再region访问hdfs，则又只有10%(好的情况可能高点)，一算下来，只有1%的概率可以本地化访问。且要走2次进程转化（一般hbase要解压、反编码等一些列的操作），其实这个时间远大于带宽的传输的时间。带宽传输时间基本可以忽略。
ApsaraDB HBase跟客户的ECS或者EMR连接，采取的是点到点的连通方式，走的是跟ECS自建集群一样的内网带宽（完全免费），完全没有区别，其实就跟访问集群内部一样。 跟一些有中转节点的模式不一样，ApsaraDB HBase的regionserver都是可以直连客户端的。
带来的好处
- 离线可以按需跑：emr提供按需跑的spark，比如晚上跑2个小时等，此极大降低成本
- 离线基本不影响HBase集群： 比如入库、访问等不受影响，还可以做scan与put的线程分离，保障入库的速度
- 如果把HBase迁移到ApsaraDB HBase，则享受ApsaraDB HBase的高性能、运维服务及专家服务
写在最后
如果你想迁移，直接使用copytable拷贝吧，还是挺快的。如果你的数据超过10T，可以联系我们。 如果你想来试用下，那就直接按需买一个跑跑，最低6元左右一个小时。
使用CopyTable同步HBase数据：10T以内还是可以满足需求的，另外我们也在研究从服务端直接拖取另外hbase集群的数据，做到一键迁移
ApsaraDB HBase购买地址：https://www.aliyun.com/product/hbase?spm=5176.8142029.388261.280.EZjBmE