时间回到2011年，Hadoop作为新生事物，在阿里巴巴已经玩得风生水起，上千台规模的”云梯”是当时国内名声显赫的计算平台。
|
时间回到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的基本原理，读者可以从社区官方Book中获得详细内容，本文便不再阐述。 下面的篇幅，将主要介绍阿里在使用Replication过程中的经验与改进，期望能和在类似场景工作的同学有所共鸣。 复制效率 由于在线业务的可用性要求，阿里HBase很早便开始使用Replication功能去部署双机房容灾，迎之而来的第一个大问题是数据复制的效率，尤其异地远距离部署（比如上海与深圳跨城复制）时更加严重，表现为数据复制的吞吐小于客户端写入主集群的吞吐，数据不断积压，延迟逐渐增大，只能等待凌晨低峰期逐渐消化。我们对此进行深入分析，着重优化了以下几点，才得以保障跨城集群复制也能稳定保持在秒级内。
HBase Replication的基本数据复制过程是源端串行读取HLog的内容，发送到目标端机器，由目标端解析HLog并写入数据写。我们发现，因为源端的串行读取、发送HLog，当集群写入吞吐大的时候，会存在严重的性能瓶颈，为此，我们重构了这一块逻辑，将HLog的读取与发送解耦，并且发送由单线程优化为多线程，使得整体的源端发送能力大幅提升。
在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团队投入研发集群同步复制功能，使得主集群不可用时，备集群的数据能达到和主集群完全一致，业务可以无感知的切换到备集群。相比于异步复制，同步复制会带来的额外的开销，但整个写入吞吐/性能的影响，在我们的设计中，做到了尽量的相近。其整体功能点如下：
关于数据的强一致，我们进行了如下定义：
我们遵从简单、高效的原则去设计同步复制功能，简单意味着该功能与原核心逻辑保持最大程度的隔离，能够快速达到生产稳定性要求，并能很好地降级成异步复制；高效意味着主备必须并行写，这在错误处理上增加了不少的难度。整体实现方案如下：
其基本结构如图：  在这里，主备角色是不对等的，我们通过部署进行分配。其中，主->备使用同步复制模式，一旦流量切换到备后，备->主使用异步复制模式。 由于主备双Log的并发写入，使得同步复制的性能能够与异步复制接近，在实际使用中，我们观察到客户端写入响应时间增加小于10%。最后，我们列举一些应用同步复制容灾的场景，以供大家参考。
总结集群间的数据复制是HBase用来构建机房容灾、提供高可用性的重要武器，阿里HBase通常使用异步复制方式部署，着重改进其在复制效率、多链路、一致性等方面的能力。同时，也研发了一种高效的同步复制方式，以满足数据强一致场景的容灾需求。 数据传输管道设施数据流动的诉求在大数据的发展背景下，没有一个系统可以处理所有的场景。因此，打通各个系统之间的数据通道，让数据在在线存储、实时分析、离线计算中高速流动，形成闭环，是打造大数据平台、挖掘数据价值的关键一环。 HExporter系统HBase作为一款高吞吐的在线数据存储系统，我们希望其能高效、准确地吐出数据，以满足业务对数据计算分析的多元化需求，这是我们建设HExporter系统的出发点。 HBase业务的数据规模飞速增长，单个业务数据量达到10T，百T级别非常常见，且越来越多的业务要求同步数据到离线计算系统进行计算。同时大部分离线计算任务是周期型，比如按天为单位进行计算，因此数据要按时间分区进行同步并保证单调性，这需要一个高效的时间分区增量方式的数据导出方案来应对日益增长的需求。这是我们建设HExporter系统的场景。 基于以上出发点和场景，我们期望建设一个实时的、高效的HBase数据管道设施，使得写入到HBase系统的数据可以方便地传输复制到其他异构系统，让数据因为流动、计算、加工而产生新的价值。为此，阿里HBase团队投入研发HExporter系统，其整体上具备以下能力：
HExporter系统的整体架构如下： 
目前，HExporter作为阿里HBase系统的基础数据传输管道设施，每天有上百TB的数据被传输到离线计算平台、在线分析引擎、搜索引擎等系统，这些系统协力配合满足应用丰富多样的数据需求。 性能与成本数据冗余的背后前面章节提到，我们使用数据在集群间的冗余复制来提高系统可用性，对于主备容灾，这意味着我们需要花费一倍的额外成本来换取高可用，能不能降低开销成为高可用能力是否可以普及的重要门槛。 跨集群分区数据复制HBase使用HDFS作为其文件存储系统，底层数据存储默认使用三副本冗余以保障数据的可靠性，这也意味着HBase内部的HLog、Flush、Compaction过程会产生三份数据流量和存储空间，包括网络和磁盘。如果HBase的底层副本数能够从3降低为2，很大程度上可以减少近1/3的成本，但是2个副本在实际运行中的数据丢失率仍然是不小的。所以，对于数据可靠性有要求的环境，三副本是最基本的要求。但是，当我们部署主备容灾后，全局拥有了六个副本，能否降低单个集群的副本为两个，全局从六个副本降低成四个副本，这成为资源优化的重要入口。 为了容忍单集群在两副本下的数据丢失，我们需要建立跨集群的分区数据复制机制，使得当某一个集群数据文件丢失时，可以快速地从另一个集群进行恢复。为了适用于更多的场景，比如集群迁移、一键建站，我们在设计上会更加通用，支持将某个表的指定范围数据高效、准确地复制到指定集群，整体功能可以概括如下：
在实现上，其类似于分布式任务调度，每一个提交的复制作业，会按照RowKey范围拆成多个子任务，并且子任务的起止范围是Region的子集，由Master派发给集群中的服务器，并保证失败后的重新派发。任务调度中的相关数据，统一存储在zookeeper上，从而保证宕机情况下作业的可恢复性。数据的具体复制根据情况会采用完全拷贝和部分复制两种方式，如果文件内容的RowKey范围是子任务的子集，则将其完全拷贝到指定集群；不然，则使用部分复制的方式，在拷贝期间过滤掉无效的数据。 详细系统架构如下：  图中的部分角色说明：
在拥有跨集群分区数据复制能力后，双集群双副本的运行方式得以应用普及，这能有效降低容灾成本。同时，我们的集群迁移、表迁移能力大大增强，在不限流下单节点可以达到70MB/秒，更重要的是这变成了一项能力、一个接口服务，而不是一堆运维操作，大大提升运维效率。 多集群多活服务对于通常的双集群容灾部署，同一时间只有单个集群提供服务，使得另一个集群在大部分时间内处于资源闲置。为了改善这一情况，阿里HBase使用了以下几种方式：
我们经常使用上述一二的方式去优化双集群容灾下的资源使用，并且取得很不错的效果。 更多性能工作在过去的几年，阿里HBase投入了很大的精力去进行系统的性能优化，包括Region级二级索引、Bucket Cache、Small Scan、Reversed Scan等很多重要优化已经反馈给社区，并在开源伙伴的一起努力下，不断更新迭代，读者可以从社区了解具体的原理与实现。 刚刚过去的2016年双11，可以说是HBase的一场圣战，面对巨大峰值流量从容应战的背后是我们在性能优化上的很多新型武器。
一直以来，HBase只能使用同步API方式访问服务，使得吞吐型场景应用端大量线程阻塞在HBase接口，严重影响性能，而异步的思想并不陌生。 在去年双11后，阿里HBase开发实现了一套全新的异步API，使得客户端不需要阻塞等待到服务端返回结果,通过回调函数执行请求成功或失败后的业务逻辑，大大提升请求吞吐。我们将其应用于监控、安全、日志等场景，整体写入吞吐可以提升1至3倍。
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%以上的访问压力。
推广广告
星点云香港服务器，CN2高速连接,ping值低可免费换IP,安全稳定,技术团队24小时在线稳定无忧
近期文章
 
推荐阅读
热门问答
 云萌主
云萌主-BIGSAAS旗下，由北京合智互联信息技术有限公司在2018年创立，为广大云应用技术爱好者的平台。在云萌主论坛可以查看云应用技术文章、云产品产品最新资讯、技术问答、技术视频。在畅游云上技术的同时，学到最新的云应用产品和技术。
|
评论