阿里沈春辉：HBase发展与改进优化分享
　作者: 景保玉　编辑:
　　【IT168 现场报道】-20日，第四届中国数据库技术大会(DTCC 2013)在北京福朋喜来登酒店拉开序幕。在为期三天的会议中，大会将围绕大数据应用、数据架构、数据管理(数据治理)、传统数据库软件等技术领域展开深入探讨，并将邀请一批国内顶尖的技术专家来进行分享。本届大会将在保留数据库软件应用实践这一传统主题的基础上，向大数据、数据结构、数据治理与分析、商业智能等领域进行拓展，以满足于广大从业人士和行业用户的迫切需要。▲　　自2010年以来，国内领先的IT专业网站IT168联合旗下ITPUB、ChinaUnix技术社区已经连续举办了三届数据库技术大会，每届大会超过千人规模，云集了国内技术水平最高的数据架构师、DBA、数据库开发工程师、研发总监、IT经理等，是目前国内最受欢迎的数据库技术盛会。▲阿里数据平台开发工程师,HBase社区Committer：天梧(沈春辉)　　HBase & Hadoop Database，是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统，利用HBase技术可在廉价PC Server上搭建起大规模结构化存储集群。　　特点：海量数据(TB以上)、很高的随机写能力、在海量数据中实现高效的读取、很好的伸缩能力、强一致性、能够同时处理结构化和非结构化的数据、动态列、不需要复杂的查询需求包括：SQL、事物、Join、多维索引等。　　HBase的版本发展：　　2007.4 第一个版本(HVASE-287 Mike Cafarella)　　.89(Facebook的生产版本 based on)　　.90.2(阿里HBASE的第一个版本 based on)　　.92(Adds 安全，协处理器，HFile V2，分布式log-Splitting)　　.94(Performance Release)，目前是主流版本。　　.95(0.96的预发版，Adds protobuf,Table Snapshot,PrefixTreeCompression等等)　　Coming 0.96　　HBase在阿里的发展：　　2011.3月开始研究　　2011.5月上线第一个应用　　截止目前：以基于0.94的阿里HBase版本为主、稳定性达到在线应用的城池标准之上、近百个业务，特点多样化。　　国内外应用发展HBase的公司：　　Cloudera、Hortonworks、Salesforce等　　faceboook、Yahoo、eBay、Twitter、Pinterest、Line等　　Intel、IBM等　　阿里巴巴、华为、小米、360等。　　实践与改进--Bucket Cache(Allocate Block)　　　　1、将整个逻辑上的存储块切割成一个个的Bucket。2、每一个Bucket都有相同的固定的容量，e.g.2MB3、每一个bucket都拥有一个size tag，cache这个size以内的Block。4、对于完全空闲的Bucket，它的size tag可以被重新指定。5、每一个bucket与物理存储的位置有固定的映射关系，根据Block在Bucket中的偏移，则就可以计算出其在物理存储中的偏移。　　　　　　　　　　实践与改进--优化Java的GC麻烦　　1、Concurrent mode failure　　原因：old区要分配了，但是old区空间不够，而此时CMS正在运行中　　解决：降低YGC频率，降低CMS GC触发时机(降低 CMSInitiatingOccupancyFraction的值)　　2、Promotion Failed(发生很多)　　原因：old区要分配了，但是找不到空间分配，却还没达到CMS的触发值。　　heap碎片+YGC晋升对象(Block，Memstore Chunk)过大　　解决：聚合小数据：开启msalab(注意Region数目)　　HBase自己管理(重用)内存对象：Bucket Cache(HBASE-7404)(使用Byte buffer作为IOEngine的存储介质)、Chunk Pool(HBASE-8163)。　　YGC停顿过长　　原因1：Young区活对象数目过多，old区脏页数目过多　　原因2：MemStore中的Keyvalueset，开启WAL压缩后的字典map　　解决：1、降低young区大小。2、减小-XX:Maxcache/ChunkPool，减少晋升对象，减少拷贝时间。　　实践与改进--更高的服务可用性服务单点▲更多优化　　HBase是Google Bigtable的开源实现，类似Google Bigtable利用GFS作为其文件存储系统，HBase利用Hadoop HDFS作为其文件存储系统;Google运行MapReduce来处理Bigtable中的海量数据，HBase同样利用Hadoop MapReduce来处理HBase中的海量数据;Google Bigtable利用 Chubby作为协同服务，HBase利用Zookeeper作为对应。　　hbase是bigtable的开源山寨版本。是建立的hdfs之上，提供高可靠性、高性能、列存储、可伸缩、实时读写的数据库系统。　　它介于nosql和RDBMS之间，仅能通过主键(row key)和主键的range来检索数据，仅支持单行事务(可通过hive支持来实现多表join等复杂操作)。主要用来存储非结构化和半结构化的松散数据。　　与hadoop一样，Hbase目标主要依靠横向扩展，通过不断增加廉价的商用，来增加计算和存储能力。　　企业面临以下问题时，可以考虑选择HBase。如数据量急剧增加，需要TB级甚至PB级的在线服务;数据量增长速度快，对水平扩展能力有需求，前期少量投入，随着数据量的不断增加，后期可以不断追加;只是简单的kv读写，要求响应延时低;要求强一致性;每秒上万的写入，并且需要批量读取，大量的随机读取，需要大吞吐量;应用程序不断变更，导致schema多变;最后一个则是整个平台是一个Java平台，需要良好的Java接口等等。而HBase无疑很好地满足了这些特点。
IT168企业级概述HBase集群内部的数据是有多备份的，在云盘模式下数据存2份，在本地盘的模式下数据存3份
另外，云HBase团队正在研发HBase集群备份到OSS的自动同步及恢复功能(由于同步数据量巨大、费用会再额外收取)，目前还没有上线，预计在7月份左右。
细节参考文档：HBase数据导入工具总结
建议迁移工具
HBase-&ApsaraDB HBase，数据量&10T
使用CopyTable同步HBase数据
为了更好地使用 HBase，在创建集群过程中，推荐您使用如下配置:
公网状态选择打开。
可用区选择为访问 HBase 的应用服务器所在的可用区，请勿选择随机分配。
硬件节点数请选择 4 个及以上，其包含了 Master 和 Slave 节点，E ...
在一些场景下，比如需要bulkload导入数据，需要打开HBase集群的HDFS端口。
注意：hdfs端口打开后，因误操作hdfs导致的数据丢失等问题客户自身承担，客户需要对hdfs的操作比较了解
开通HDFS端口
首先联系云HBase答疑(钉钉号 ...
0.购买部署ThriftServer的ECS机器；每台机器上准备下面1/2的软件包，并在云HBase页面做好3需要的准备。
1.jdk（java运行环境，因为Thriftserver是java写的）；这里以1.8版本为例子；如何 ...
HBase Writer 插件实现了从向 HBase 中写取数据。在底层实现上，HBase Writer 通过 HBase 的 Java 客户端连接远程 HBase 服务，并通过 put 方式写入 Hbase。
支持的功能支持 Hbase0.94.x 和 ...
HBase Reader 插件实现了从 HBase 中读取数据。在底层实现上，HBase Reader 通过 HBase 的 Java 客户端连接远程 HBase 服务，并通过 Scan 方式读取你指定 rowkey 范围内的数据，并将读取的数据使用数据 ...
实时统计分析 可以支持实时的数据查询分析，直接pushdown，命中索引，返回结果
Spark接HBase
MR接HBase 其实mr、spark对接Hbase主要的目的是为了写代码分析，如果是为了做ETL建议不要频繁处理，做了后就直接存下来即可、或者 ...
使用子账号管理HBase为了方便企业内部管理，保障数据安全，HBase客户可创建并授权子账号对HBase机器进行日常管理。
登录RAM管理控制台，点击用户管理，创建一个子用户。进入子用户管理页面，在用户授权策略TAG中，点击编辑授权策略，在搜索 ...
说明阿里云HBase的服务端是定制的代码，客户端是完全兼容社区的。但是我们会根据阿里云产品特点提供专属的HBase 客户端并开源，且maven jar同步到maven中央仓库，这就意味着，任何地方都能下载并使用。我们不会改变任何语法，主要是提供一些特性 ...
TableStore HBase Client 是基于 HBase Client 的封装，使用方法和 HBase Client 基本一致，但是也有一些事项需要注意。
依赖TableStore HBase Client 1.2.0 版本中依赖了 HBase ...
概述当前，数据入库到HBase之后，不能再实时导出。
阿里云团队正在研发数据入库后，可以实时导出的功能， 如果需要此功能，请提交工单咨询。
此功能主要满足：
不同环境的HBase数据同步，比如 把阿里云的HBase的数据同步到线下，或者其他云平台数据可以实时同步到离线平台，比如ODPS或者存在OSS之中 ...
HBase授权HBase在不开启授权的情况下，任何账号对HBase集群可以进行任何操作，比如disable table/drop table/major compact等等。
对于没有Kerberos认证的集群，即使开启了HBase授权，用户也 ...
当前，数加 & MaxCompute
因为安全的原因不能直接访问HBase集群，只能通过导入导出的方式数据同步，我们正在对接阿里云的AK，后续 公网及数加 & MaxCompute 也可以访问 ApsaraDB for HBase了。
即将上线：
公网访问共享环境访问
本地盘存储系列本地盘实例，自带存储；适合大规模数据存储；单GB价格低；20T起步
磁盘（GB）
国内站点包月价 元/月
国内站点小时价 元/小时
本地SATA D1
hbase.d1.2xlarge ...
阿里云HBase团队，正在研发新建表时，可以直接把数据存放在OSS之中，降低存储成本。
对于冷数据的存储非常友好。
预计在6月会上线，敬请期待 ...
HBase Shell访问 ...
应用场景ApsaraDB for HBase的使用场景比较广泛，以至于很多客户无法把握他。以下我们大致列下，适合的场景：
HBase的设计之初是为了存储互联网，几乎所有非事务类结构化的存储需求都可以使用HBASE来满足。HBase是NoSql，讲的是 ...
TableStore HBase Client 目前支持 HBase Client 1.0.0 及以上版本的 API。
HBase Client 1.0.0 版本相对于之前版本有一些较大的变化，这些变化是不兼容的。
为了协助一些使用老版本 HBase 的 ...
你可能感兴趣自建hbase可以用阿里的hbase jar包吗?_百度知道
自建hbase可以用阿里的hbase jar包吗?
从阿里官网可以了解到，阿里对hbase做了相应的优化，如果用阿里的hbase相关jar，但不用它的阿里云Hbase库是否可以？
我有更好的答案
导入hadoop和hbase的jar包后private static HBaseConfiguration hbaseConfig=static {Configuration config=new Configuration();config.set(&hbase.zookeeper.quorum&,&192.168.1.98&);config.set(&hbase.zookeeper.property.clientPort&, &2181&);hbaseConfig = new HBaseConfiguration(config);
采纳率：72%
为您推荐：
您可能关注的内容
换一换
回答问题，赢新手礼包
个人、企业类
违法有害信息,请在下方选择后提交
色情、暴力
我们会通过消息、邮箱等方式尽快将举报结果通知您。某客户大数据测试场景为：Solr类似画像的数据查出用户标签&&通过这些标签在HBase查询详细信息。以上测试功能以及性能。
其中HBase的数据量为500G，Solr约5T。数据均需要从对方的集群人工迁移到我们自己搭建的集群。由于Solr没有在我们集群中集成，优先开始做HBase的数据迁移，以下总结了HBase使用以及数据迁移遇到的各种问题以及解决方法。
一.迁移过程遇到问题以及解决
客户HBase版本：Version 0.94.15
腾讯大数据套件HBase版本：Version 1.2.1
客户私有云系统版本（测试）：tlinux1.2
遇到的问题以及解决过程如下：
阿里云大学为您免费提供
相关信息，包括
的信息 ，所有
相关内容均不代表阿里云的意见！投稿、删除文章请联系邮箱：zixun-group@service.aliyun.com，工作人员5个工作日内回复。大数据时代的结构化存储—HBase在阿里的应用实践
大数据时代的结构化存储—HBase在阿里的应用实践
时间回到2011年，Hadoop作为新生事物，在阿里巴巴已经玩得风生水起，上千台规模的&云梯&是当时国内名声显赫的计算平台。
这一年，Hadoop的好兄弟HBase由毕玄大师带入淘宝，开启了它的阿里之旅。
时间回到2011年，Hadoop作为新生事物，在阿里巴巴已经玩得风生水起，上千台规模的"云梯"是当时国内名声显赫的计算平台。这一年，Hadoop的好兄弟HBase由毕玄大师带入淘宝，开启了它的阿里之旅。从最初的淘宝历史交易记录，到去年的支付宝消费记录存储在线历史存储统一；从蚂蚁安全风控的多年存储演进，到HBase、TT、Galaxy的大数据激情迭代；HBase在阿里经历过年轻的苦涩，释放过青春的活力，也付出过成长的代价。几代人的不懈努力下，五年陈的HBase开始表现出更成熟、更完善、更丰富的一面，成为公司内部被广泛使用的存储产品之一。经过阿里集团内部的锤炼，集团将这个技术红利输送给广大阿里云客户。现已推出云数据库HBase产品，支持海量的PB级的大数据存储，适用于高吞吐的随机读写的场景。
本篇会系统性的阐述HBase的定位、建设思路，其中相关内容可能并未深入展开，后续会有专项介绍，请大家随时关注云栖社区相关文章。
HBase是一个开源的非关系型分布式数据库（NoSQL）,基于谷歌的BigTable建模，是一个高可靠性、高性能、高伸缩的分布式存储系统，使用HBase技术可在廉价PC Server上搭建起大规模结构化存储集群。
HBase最初是以Hadoop子项目的形式进行开发建设，直到2010年5月才正式成为Apache的顶级项目独立发展。伴随着互联网时代数据的澎湃增长，HBase作为基础存储系统得到了快速发展与应用，大批知名商业公司(Facebook、Yahoo、阿里等)不自主地加入到了HBase生态建设队伍，成为Apache最活跃的社区之一。
HBase的能力特点，可以简单概括为下表，基于这些能力，其被广泛应用于海量结构化数据在线访问、大数据实时计算、大对象存储等领域
阿里从2011年初开始步入HBase的发展、建设之路，是国内最早应用、研究、发展、回馈的团队，也诞生了HBase社区在国内的第一位Committer，成为HBase在中国发展的积极布道者。过去的几年时间，阿里累积向社区回馈了上百个Patch, 在诸多核心模块的功能、稳定性、性能作出积极重大的贡献，拥有多位Committer，成为推动HBase的长远发展的重要力量之一。
阿里是一家综合生态型公司，内部庞大业务矩阵高速发展，在基础存储方面，需要更好的功能灵活性、基础设施适应性、服务稳定性、效率成本。因此，阿里HBase团队发展维护了HBase的内部分支，其基于阿里巴巴/蚂蚁金服的环境和业务需求，对社区HBase进行深度定制与改进，从软件系统、解决方案、稳定护航、发展支撑等全方位提供一站式大数据基础存储服务。
HBase在阿里的使用
Ali-HBase作为阿里巴巴大厦的基础存储设施，全面服务于淘宝、天猫、蚂蚁金服、菜鸟、阿里云、高德、优酷等各个领域，满足业务对于大数据分布式存储的基本需求。
在刚刚过去的2016年双11，HBase承载访问量达到了上百GB/秒(写入)与上百GB/秒(读取)，相当于全国人民一秒收发一条短信，在业务记录、安全风控、实时计算、日志监控、消息聊天等多个场景发挥重要价值。面对如此规模的业务体量，阿里巴巴团队对于如何基于HBase打造稳定、高效、易用的存储服务，形成了一套完善的产品体系与实践经验，其整体大图如下：
总体上，我们以定制的软件内核为中心，建设质量平台、运维平台、业务平台和数据流设施四大内容，以支持业务对于基础数据服务的全方位需求。
接下来，本文会围绕可用性、数据流、性能优化等方面介绍最近的一些具体工作，希望能够给相关领域的同学带来一点帮助。
高可用建设
服务持续可用是互联网系统的显著特征，但由于物理环境、软件Bug的不确定性，要做到系统的高可用往往不是一件容易的事，尤其是对于有状态的存储系统而言。今天，我们统一使用SLA(服务等级协议)去衡量一个分布式系统的可用性，比如SLA达到99.99%的系统，其全年的不可用时间小于52.6分钟；99.999%的系统，其全年的不可用时间小于5.25分钟，达到这个能力的系统一般可以称之为高可用。
面对断电、断网、硬件故障等物理机房的不可靠性，任何一个高可用系统必须通过双机房，甚至多机房部署的方式进行容灾。对于存储系统，这就要求数据能够在机房间冗余复制，并保证各个机房的数据对上层应用的一致性。所以，高可用建设是我们过去很长时间的重要工作。
集群异步复制
Apache HBase从0.92版本开始支持Replication功能，它会实时地、异步地将一个HBase集群中的增量数据复制(推送方式)到另一个HBase集群，当主集群故障不可用时，应用可以切换访问到备集群，从而实现数据与服务的机房容灾。关于HBase Replication的基本原理，读者可以从中获得详细内容，本文便不再阐述。下面的篇幅，将主要介绍阿里在使用Replication过程中的经验与改进，期望能和在类似场景工作的同学有所共鸣。
由于在线业务的可用性要求，阿里HBase很早便开始使用Replication功能去部署双机房容灾，迎之而来的第一个大问题是数据复制的效率，尤其异地远距离部署（比如上海与深圳跨城复制）时更加严重，表现为数据复制的吞吐小于客户端写入主集群的吞吐，数据不断积压，延迟逐渐增大，只能等待凌晨低峰期逐渐消化。我们对此进行深入分析，着重优化了以下几点，才得以保障跨城集群复制也能稳定保持在秒级内。
提升源端发送效率
HBase Replication的基本数据复制过程是源端串行读取HLog的内容，发送到目标端机器，由目标端解析HLog并写入数据写。我们发现，因为源端的串行读取、发送HLog，当集群写入吞吐大的时候，会存在严重的性能瓶颈，为此，我们重构了这一块逻辑，将HLog的读取与发送解耦，并且发送由单线程优化为多线程，使得整体的源端发送能力大幅提升。
提升目标端Sink效率
在Replication的默认实现中，源端会按照HLog的原始写入顺序进行回放。为了提升目标端的写入效率，我们将所有待发送的HLog先进行排序，使得同表同Region的数据都能合并处理，同时将目标端的数据写入尽量并行化。
尽管做了以上两点后，集群间的数据复制能力大大增强，但是个别服务器仍然会由于负载过大，而产生一定的复制延迟。从本质上来说，这是因为HBase的服务器分配了更多的资源服务于来自客户端的写入请求，当某个服务器成为集群中的写入热点并高负载工作时，这个节点的数据复制基本很难再消化庞大的写吞吐。这是一个曾困扰我们很久的问题，你可以用一些运维的方式去解决。比如开启更多的线程数，但这并不能总有效。因为服务于客户端的线程数，要远远大于Replication的线程数。再比如从热点服务器移走Region，降低吞吐与负载，但热点并不保证是恒定的，可能会跳跃在各个服务器，我们也开发了新的基于历史监控的负载均衡算法，以尽可能地让请求均衡。
很多时候，通过运维管理手段能够控制影响、化解问题，但当你需要维护上百个集群时，一点一滴的运维要求慢慢堆积成很高的壁垒。所以，我们尝试改进系统能力，用自动、一劳永逸地方式去解决热点下的数据复制积压问题。面对热点的基本思路是散列，在这个具体场景上，我们打破原先的自生产自推送的设计，利用整个集群的能力，使得热点服务器上积压的数据(HLog文件)，能够由集群中的其他空闲服务器进行消化。
配置在线调整
配置的在线调整不仅能极大提升运维幸福感，而且对于系统改进可以产生更加敏捷的反馈。这并不新鲜，但这是一项十分重要的能力，我们在系统改进的道路上也对其特别重视。HBase的Replication功能会有很多参数，我们将其全部优化为可在线调整，给日常的服务支撑带来了很大的价值。
业务多地多单元部署是阿里技术架构的一项重要特征，这要求基础存储具备数据链路的灵活流动性。今天，阿里HBase会在多地部署多集群，集群间数据相互流动，以满足单元化业务的需求。
在支持数据多链路的生产应用上，我们总结了以下几个要点
表级别链路
当一个HBase集群启用多个数据链路后，我们期望自由设置表的数据可以被复制到其中的一个或多个链路，使得整个数据的流动更加灵活。为此，我们增加了一种特性，通过设置表的属性，以决定该表的数据流向哪些链路，使得整个数据流动图可以由业务架构师任意设计，十分灵活。此外，当需要在集群间热迁移数据时，它也能带来十分重大的作用。
整体效果如下，以表为单位数据可以任意流动：
当数据可以在多个集群任意流动后，一个很迫切的需求是链路拓扑以及复制状况的可视。为此，我们强化了Replication的信息层，不仅源端保留它到多个目标的链路信息，而且每个目标端也会保留多个源端到它的链路信息，从而我们可以从任意一个集群绘制整个链路拓扑图。同时，我们极大丰富Replication的运行状况信息，并将之汇聚到HBase的Master节点，由其统一汇总展现，从中我们可以清晰得到数据是否积压、复制的性能瓶颈、节点间的均衡情况、具体的延迟时间等信息，其中复制的延迟时间是一个十分关键的信息。
基本信息如图
在数据多链路下，会产生一些循环复制的场景。比如集群A-&B-&C-&A，这是一个简单的链接式复制，当数据流过某个集群时，HBase Replication会在数据中添加该集群ID的信息，以防止同一条数据被多次流经同一个集群，基于这个设计，即使复制链路存在环，数据也不会产生无限循环流动。但是，仍然有一个效率问题不得不提，对于A&-&B&-&C&-&A这样一个数据链路，我们发现客户端写入到A集群的数据，在B集群和C集群上会被复制写入两次，一次通过A-&B链路写入，另一次通过A-&C-&B链路写入。所以，为了避免这种写入放大，需要在链路部署上防止产生这种环。在过去实践的一些场景，发现这种环状链路不得不存在，所以系统层面，我们也对Replication做了相关优化，以去除这种写入放大。
当源集群配置了多个数据链路后，我们总是期望这些链路之间相互隔离，不会因为一个链路的积压影响其他链路。在大多数时候，这一切都如预期工作，但当集群故障时，糟糕的事情发生了，我们发现一个异常链路会阻塞全部链路的复制恢复，究其原因，是因为在数据复制的恢复期间，很多资源是所有链路共享的。所以，这些资源的链路解耦成为我们的工作，同时，也好好对数据复制的宕机恢复速度进行了优化。
数据的一致性
今天，大多数生产系统会使用异步方式去实现集群间的数据复制，因为这样效率更高、逻辑更清晰。这意味着，集群间数据是最终一致模型，当流量从主切换到备，从备上无法访问完整的数据，因为复制存在滞后，并且当主集群永久不可恢复，数据也会存在部分丢失。
为了满足业务场景的强一致需求，我们采用了两种方式。
第一种，异步复制下的强一致切换。虽然备集群的数据集滞后于主集群，但是在主集群网络健康的情况下，仍然可以保障切换前后数据的强一致。其基本过程如下，首先让主集群禁止数据写入，然后等待主集群的数据全部复制备集群，切换流量到备集群。这里存在两个依赖，一个是集群的写入控制功能(支持禁止来自客户端的数据写入)，另一个是复制延迟的确定性，虽然数据是异步复制的，但是我们将数据的复制时间点明确化，即该时间点之前写入的数据已经完全复制到了备集群。
第二种，数据复制使用同步的方式。即当数据写入返回客户端成功后，能保证数据在主备集群均已写入，从而即使主集群完全不可恢复，数据在备集群中也能保证完整。
为了满足类似场景的需求，阿里HBase研发了同步方式的集群间数据复制，具体内容可参考下一节。
冗余与成本
数据在集群间的冗余复制，给系统的可用性带来了数量级的提高，但同时也意味着更大的成本开销，在保证可用性下如何优化成本是一个需要重点思考的问题，阿里HBase在这方面投入了较大精力的尝试，具体内容将在接下来的"性能与成本"章节进行介绍。
集群同步复制
上文提到，HBase集群可以使用异步方式的数据复制来构建双机房容灾，当主集群故障不能提供服务时，就会切换请求到备集群，保障系统整体高可用。然而，异步复制模式下存在的问题是：在服务切换后，由于主备集群间的数据并非强一致，存在部分数据无法通过备集群获取或者访问到的内容过旧。也就是说，如果应用对于数据访问具有强一致要求，现有的异步复制设计，无法在主集群故障时，仍然保证系统的高可用。
为此，阿里HBase团队投入研发集群同步复制功能，使得主集群不可用时，备集群的数据能达到和主集群完全一致，业务可以无感知的切换到备集群。相比于异步复制，同步复制会带来的额外的开销，但整个写入吞吐/性能的影响，在我们的设计中，做到了尽量的相近。其整体功能点如下：
数据强一致性保证。数据写入主备集群，主集群不可用后，备集群可以恢复所有在主集群写入成功的数据
高性能。主备集群HLog写入采用异步并行的方式写入，对写入性能影响微弱
列族级粒度。列族级别的配置，支持同集群下同个表的不同列簇可以使用不同的复制方式，同步或异步。
同异步复制共存。任何情况下，同步复制表的任何操作不会影响异步表的读写。
灵活切换。备集群不可用，同步复制可以一键切换为异步复制，不阻塞主集群写入。
关于数据的强一致，我们进行了如下定义：
返回应用成功，则一定主备都写成功
返回应用错误，则未决(主备是否成功不能确定)
数据一旦读取成功，则主备永远均可读，不会出现主读成功切换至备后读不到或者备读得到主读不到的情况
任何情况下，保证主备集群的最终一致性
我们遵从简单、高效的原则去设计同步复制功能，简单意味着该功能与原核心逻辑保持最大程度的隔离，能够快速达到生产稳定性要求，并能很好地降级成异步复制；高效意味着主备必须并行写，这在错误处理上增加了不少的难度。整体实现方案如下：
客户端向主集群写入数据的时候，会并行写入两份Log，一份是本地HLog文件，另一份是备集群的HLog文件，我们称之为RemoteLog.两者皆成功，才返回客户端成功。
RemoteLog仅在故障切换后，用以回放数据。正常运行时，不做任何使用，备集群的数据仍然通过现有的异步复制链路写入。同时，可以通过停写RemoteLog，把同步复制降级成异步复制。
HBase数据的多版本特性，使得基于HLog的操作回放具有幕等性，所以，在故障切换后，RemoteLog中的数据回放会存在一定的重复，但不会影响数据正确性。
主备集群存在Active和Standby状态，只有Active状态的集群才能接受客户端的数据写入
在备集群切换为Active状态之前，会对RemoteLog全局上锁，从而防止客户端写入数据到主集群返回成功。这也意味着，主备集群在任何时刻，只有一个处于Active状态，不会有脑裂发生。
RemoteLog会定期由主集群清理，主集群服务器的一个HLog文件对应一个或多个RemoteLog，所以当主集群的HLog文件中的数据被完全复制到备集群后，相应的RemoteLog就可以被删除。
其基本结构如图
在这里，主备角色是不对等的，我们通过部署进行分配。其中，主-&备使用同步复制模式，一旦流量切换到备后，备-&主使用异步复制模式。
由于主备双Log的并发写入，使得同步复制的性能能够与异步复制接近，在实际使用中，我们观察到客户端写入响应时间增加小于10%。最后，我们列举一些应用同步复制容灾的场景，以供大家参考。
基于状态变更数据的场景。HBase中提供了CheckAndMutate接口，用以支持条件写入/更新/删除，其含义是当某一条件达成时，才执行该写操作。这意味着查询到的数据必须是强一致的，不然就会写入错误的数据。比如，对于一笔交易记录，其状态只能从“已付款”变更为“已发货”，而不能从其他状态变更为“已发货”，所以在数据更新时需要做状态的条件判断。
日志/消息的顺序订阅。对于日志/消息产品而言，订阅数据的完整性是其最核心的保证，也就是说通过HBase进行Scan的时候，必须保证能扫描到范围内的每一行数据。如果切换后，主备数据存在不一致，则会出现scan过程中跳过某些数据，造成订阅少数据。
流计算。由于流计算不停地基于中间结果和新的数据流进行迭代处理，作为存储中间结果的数据库，必须时刻具备数据的强一致，才能保证数据计算结果的正确性。
集群间的数据复制是HBase用来构建机房容灾、提供高可用性的重要武器，阿里HBase通常使用异步复制方式部署，着重改进其在复制效率、多链路、一致性等方面的能力。同时，也研发了一种高效的同步复制方式，以满足数据强一致场景的容灾需求。
数据传输管道设施
数据流动的诉求
在大数据的发展背景下，没有一个系统可以处理所有的场景。因此，打通各个系统之间的数据通道，让数据在在线存储、实时分析、离线计算中高速流动，形成闭环，是打造大数据平台、挖掘数据价值的关键一环。
HExporter系统
HBase作为一款高吞吐的在线数据存储系统，我们希望其能高效、准确地吐出数据，以满足业务对数据计算分析的多元化需求，这是我们建设HExporter系统的出发点。
HBase业务的数据规模飞速增长，单个业务数据量达到10T，百T级别非常常见，且越来越多的业务要求同步数据到离线计算系统进行计算。同时大部分离线计算任务是周期型，比如按天为单位进行计算，因此数据要按时间分区进行同步并保证单调性，这需要一个高效的时间分区增量方式的数据导出方案来应对日益增长的需求。这是我们建设HExporter系统的场景。
基于以上出发点和场景，我们期望建设一个实时的、高效的HBase数据管道设施，使得写入到HBase系统的数据可以方便地传输复制到其他异构系统，让数据因为流动、计算、加工而产生新的价值。为此，阿里HBase团队投入研发HExporter系统，其整体上具备以下能力：
实时性。数据可以秒级复制到其他异构系统
准确性。保证数据在HBase与其他系统间的最终一致性
高吞吐。支持调整缓冲等级和压缩等级，从而协调数据生产端和数据消费端的能力，达到最大的吞吐量。在实际应用中，HExporter可以有效使用95%的网络带宽并保持稳定运行。
容灾性。HBase主备容灾模式下，数据能够正常传输。
时间确定性。明确标注同步时刻，该时刻之前写入的数据都已经传输完成。基于此，保证计算系统对某个时间分区的完整数据进行计算。
可降级。支持按表取消数据传输。
监控告警。支持传输延迟的监控与告警。
HExporter系统的整体架构如下:
HExporter的数据是由HBase系统“推送”过来的，其利用了HBase系统本身的内部数据复制机制，模拟了备库的角色。HBase的RegionServer将自身的数据打包，随机发送到HExporter的采集节点。每一个数据包随机的选择采集节点，因此采集节点之间是完全对等的，可以动态的增加节点来提高HExporter的接收能力，它是水平可扩展的。为了支持主备模式下的HBase，HExporter需要同时采集主备集群，保证客户端写入HBase的数据不会因为主备间的网络中断而延迟采集。此时需要解决数据去重的问题：HExporter在收到数据包时，会检查数据包的标记，这个标记表示了数据是否来自于最源端（客户端写入的集群），如果不是则直接抛弃这个数据包。
大部分离线计算任务是周期型，比如按天为单位进行计算，数据要按时间分区进行同步，因此消费数据时必须能够获取时间信息。HExporter提供两个维度的时间供消费方使用：业务时间(数据的生成时间）和存储时间(数据写入HBase的时间)。
同步时间点指的是一个时刻，在该时刻之前写入HBase的数据都已经被HExporter采集。由于数据的推送是随机的，因此到达采集节点的数据在时间上是乱序的，同步时间点利用HBase在Zookeeper上记录的日志信息计算每个RegionServer的同步时间点，最后选择所有RegionServer同步时间点中的最小值记为集群的同步时间点。由于同步时间点的计算是保障数据有序的关键，必须能够容忍宕机等问题。在HExporter的设计中，每一个采集节点都可以计算同步时间点，所有节点竞争同一个锁（依赖Zookeeper实现），从而获得这一轮计算同步时间点的权利。只要有一个采集节点存活，同步时间点的计算就可以正常工作。
目前，HExporter作为阿里HBase系统的基础数据传输管道设施，每天有上百TB的数据被传输到离线计算平台、在线分析引擎、搜索引擎等系统，这些系统协力配合满足应用丰富多样的数据需求。
性能与成本
数据冗余的背后
前面章节提到，我们使用数据在集群间的冗余复制来提高系统可用性，对于主备容灾，这意味着我们需要花费一倍的额外成本来换取高可用，能不能降低开销成为高可用能力是否可以普及的重要门槛。
跨集群分区数据复制
HBase使用HDFS作为其文件存储系统，底层数据存储默认使用三副本冗余以保障数据的可靠性，这也意味着HBase内部的HLog、Flush、Compaction过程会产生三份数据流量和存储空间，包括网络和磁盘。如果HBase的底层副本数能够从3降低为2，很大程度上可以减少近1/3的成本，但是2个副本在实际运行中的数据丢失率仍然是不小的。所以，对于数据可靠性有要求的环境，三副本是最基本的要求。但是，当我们部署主备容灾后，全局拥有了六个副本，能否降低单个集群的副本为两个，全局从六个副本降低成四个副本，这成为资源优化的重要入口。
为了容忍单集群在两副本下的数据丢失，我们需要建立跨集群的分区数据复制机制，使得当某一个集群数据文件丢失时，可以快速地从另一个集群进行恢复。为了适用于更多的场景，比如集群迁移、一键建站，我们在设计上会更加通用，支持将某个表的指定范围数据高效、准确地复制到指定集群，整体功能可以概括如下:
简单。可以通过一个接口或者命令执行复制，并在系统UI上实时显示进度。
快速。整个复制任务会进行拆分，并由不同节点完成，大大提高速度。
容错和灾难恢复。复制过程中任何出错和宕机都能自我恢复。
在实现上，其类似于分布式任务调度，每一个提交的复制作业，会按照RowKey范围拆成多个子任务，并且子任务的起止范围是Region的子集，由Master派发给集群中的服务器，并保证失败后的重新派发。任务调度中的相关数据，统一存储在zookeeper上，从而保证宕机情况下作业的可恢复性。数据的具体复制根据情况会采用完全拷贝和部分复制两种方式，如果文件内容的RowKey范围是子任务的子集，则将其完全拷贝到指定集群；不然，则使用部分复制的方式，在拷贝期间过滤掉无效的数据。
详细系统架构如下：
图中的部分角色说明：
DataMigrationManager: DMM,运行于HBase Master，负责接收复制作业、切割作业为多个子任务、派发子任务、监听完成情况等。
DataMigrationWorker: DMW, 运行于HBase Regionserver，负责完成子任务的数据复制到指定集群。
Job: 一次数据复制作业，由用户提交，内容包括表名，Rowkey范围以及指定目标集群的地址信息。
Task: Job分割后的子任务，多个子任务的Rowkey范围拼接后组成完整的复制作业的Key范围。
在拥有跨集群分区数据复制能力后，双集群双副本的运行方式得以应用普及，这能有效降低容灾成本。同时，我们的集群迁移、表迁移能力大大增强，在不限流下单节点可以达到70MB/秒，更重要的是这变成了一项能力、一个接口服务，而不是一堆运维操作，大大提升运维效率。
多集群多活服务
对于通常的双集群容灾部署，同一时间只有单个集群提供服务，使得另一个集群在大部分时间内处于资源闲置。为了改善这一情况，阿里HBase使用了以下几种方式:
业务对于数据无强一致要求，同个业务的部分客户端访问主集群，部分客户端访问备集群。这种方式对于业务应用部署存在一定的负担，使其数据库地址管理复杂化。
交叉部署访问，支持数据的强一致要求。一般我们会把类似场景的多个业务部署在同个集群中，通过交叉部署，在同一时间，使得一些业务访问主集群，另一些业务访问备集群，从而同时发挥两个集群的资源。
客户端支持同时访问双集群。我们通过改造HBase的客户端，使其支持同时访问双集群，这不仅可以提升集群的资源使用率，还大大降低了访问毛刺，因为任何超过一定时间的请求都会被重发到另一个集群。
我们经常使用上述一二的方式去优化双集群容灾下的资源使用，并且取得很不错的效果。
现阶段，由于业务场景对请求稳定性的更高要求，我们开发了“客户端支持同时访问双集群”的功能，以规避单节点抖动（如网络、磁盘、GC、锁竞争、热点）的影响，减少应用访问HBase的响应毛刺。从实际测试使用看，开启该功能后，整体毛刺比例下降达到一个数量级以上，有效去除HBase请求服务时间不稳定的影响。
更多性能工作
在过去的几年，阿里HBase投入了很大的精力去进行系统的性能优化，包括Region级二级索引、Bucket Cache、Small Scan、Reversed Scan等很多重要优化已经反馈给社区，并在开源伙伴的一起努力下，不断更新迭代，读者可以从社区了解具体的原理与实现。
刚刚过去的2016年双11，可以说是HBase的一场圣战，面对巨大峰值流量从容应战的背后是我们在性能优化上的很多新型武器。
一直以来，HBase只能使用同步API方式访问服务，使得吞吐型场景应用端大量线程阻塞在HBase接口，严重影响性能，而异步的思想并不陌生。
在去年双11后，阿里HBase开发实现了一套全新的异步API，使得客户端不需要阻塞等待到服务端返回结果,通过回调函数执行请求成功或失败后的业务逻辑，大大提升请求吞吐。我们将其应用于监控、安全、日志等场景，整体写入吞吐可以提升1至3倍。
前缀BloomFilter
HBase利用BloomFilter过滤不必要的文件来提高HBase数据读的性能，其效果只支持Get不支持Scan；在实际使用场景中，有很多业务Scan操作会扫描具有相同前缀的行，比如物流详情场景，其Rowkey结构是：物流单号+时间戳，一个物流商品会经历多个状态，每有一次状态转移需要写入一行数据，这些状态正常在10个左右，通过Scan的方式可以查询一个物流单号下的所有状态。针对这个场景我们设计了前缀BloomFilter，在业务Scan的起止范围存在公共前缀下，使得Scan操作也可以使用BloomFilter来过滤文件，大大提升了查询效率；菜鸟物流详情开启前缀BloomFilter后，查询性能提升一倍，做到大促不扩容，轻松hold住今年大促6.57亿包裹的物流详情查询。
HLog从0.92版本开始支持字典压缩，但其与Replication复制冲突，使得其一直无法真正地被使用，而大量在线业务使用宽表结构，几十个字段的场景比比皆是，HLog的压缩将有效提升写入能力。为此，阿里HBase重构了HLog的压缩机制，与HBase Replication功能完美兼容运行，在消费记录、数据总线、库存对账等多个业务线获得良好效果，提升写入20%。
数据的聚合、校正、清洗是数据库系统常见的计算场景，通过外部客户端进行数据的扫描、计算、更新是我们常用的传统方式。当面对TB级以上规模的时候，这种方式不仅效率低下，而且对本身的数据服务性能影响巨大。
阿里HBase一直在探索一种高效、环保的能力去解决我们对于数据基本计算的需求，几经业务理解与抽象，最终找到一种基于coprocessor的数据库内置计算方案。它不仅可以提供基本的Count、Avg、Sum、PV、UV等分析聚合能力，也可以提供常见的格式转换、内容校正、字段清洗等数据管理能力。其基本原理是，我们在HBase的Flush、Compaction、查询返回等路径添加coprocessor的hook，并开发很多通用的coprocessor插件，使得HBase服务端能够在Compaction、Flush期间就完成数据计算工作，这不仅促使计算结果快速输出，也大大减少数据存储IO，大大提升整体性能。2016年，凭借这个能力，多个几百TB规模业务在一周以内完成字段清洗、格式转换，并且全程对业务在线访问无影响。凭借这个能力，很多秒级生产的指标数据，应用可以零成本聚合成小时级、日级等粗粒度指标，并对HBase系统减少50%以上的访问压力。
随着2016天猫双十一的GMV定格在1207亿，HBase的大促目标圆满完成，然而完美的结果只是开始，阿里HBase团队追求卓越的心永远不会变，推陈出新也永远不会停。在未来的日子里，我们将会重点攻破以下难题。
HBase作为JAVA性存储系统，大容量的内存堆使得YoungGC、FullGC的停顿成为我们一直以来挥之不去的痛苦。探究GC的原理机制，我们明确HBase内部的写缓冲Memstore和读缓存BlockCache是造成GC停顿的最大源头，正在尝试用全新研发的完全自管理内存的Map以替换JDK自带的Map，从而消除GC的影响。
我们正在尝试提供SQL方式访问HBase。它会增加数据类型，降低用户的开发理解门槛，促进异构系统之间的数据流动效率；它会增加全局二级索引，使得多条件查询更加高效；它会简化查询表达，使得性能优化更加普及；它会增加通用的热点解决方案，帮助用户免去复杂的散列逻辑。
我们正在尝试将HBase部署运行于Docker之上，使得整体运维更加敏捷，集群伸缩更加自如，资源使用更加充分。
阿里在HBase领域积累的这些能力，将通过云数据库HBase的产品化，输出给阿里云的广大客户收益。对于使用的公司：不需要再担心技术上遇到的一个个瓶颈难题，云数据库HBase已经为你解决不需要再担心招聘HBase顶尖高手，阿里云技术专家将为你贴身服务不需要弹性扩容、自动化运维等事宜，依托云产品，这些能力将快速实现
用云栖社区APP，舒服~
【云栖快讯】新手小白必看！编程语言系列讲座火爆进行中，与行业资深专家一起学习Python、C++、JavaScript、Java！从入门到进阶&&
有很多解决方案都是参照google的bigtable的论文的，很想知道阿里是基于哪些方面考虑最终选择了HBase作为分布式存储的解决方案？
云数据库 HBase 版（ApsaraDB for HBase）是基于 Hadoop 的一个...
凝聚阿里巴巴多年来在无线业务安全防御的成功经验和技术成果，并面向开发者和企业提供安全扫描、应...
一站式提供企业即时通讯、销售管理、协同办公。
为您提供简单高效、处理能力可弹性伸缩的计算服务，帮助您快速构建更稳定、安全的应用，提升运维效...
云通信517活动