HBase企业应用开发实战.html.pdf

《HBase企业应用开发实战.html.pdf》由会员分享，可在线阅读，更多相关《HBase企业应用开发实战.html.pdf（265页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、前言 为什么要写这本书 大数据是继云计算、物联网之后IT行业又一次颠覆性的技术革命。大数据在互联网、军事、金融、通信和物理学等领域已经有不少落地案例，而Hadoop技术的快速发展也引起业界广泛关注。可以 说，现在Hadoop是大数据处理的关键技术，也是迄今为止，最成熟、应用最广泛的技术。 HBase原型是Google的BigTable论文，从基因上讲，HBase已经是Hadoop生态系统不可或缺的一部分。HBase是完全开源的，同时存在多个版本，并且版本升级非常快，其学习成本比较高，学习周 期比较长，所以现在大部分公司的工作人员很难在短时间内快速掌握并使用HBase框架。 此外，现在有关HBa

2、se的中文学习资料非常少，也给研发人员的学习带来了很大的难度。尽管现在市面上已经有几本关于HBase的中文书，但是，这几本书都是翻译作品，语言的组织不符合国人的习 惯，并且实例讲解部分也不能切合本土国情。还有，这几本书分别侧重了某一个方面，如理论、实战、运维等，还没有一本书能够非常系统地阐述HBase框架。本书正是为了解决以上各种问题而编写的， 也是国内第一本系统讲解HBase理论、实战和运维调优的书籍。 本书以HBase 0.94为基础，不仅深入探讨了HBase的原理架构和数据模型，更重要的是通过实际案例教会读者如何运用HBase框架来设计、搭建及运行大数据应用系统，同时结合生产案例剖析HB

3、ase 系统运维和性能调优的技巧。 读者对象 本书适合以下读者阅读。 （1）云计算、大数据处理技术和NoSQL数据库爱好者 “大数据”无疑是继“云计算”之后IT业界最热门的词汇。而云计算、大数据、NoSQL技术本身存在交集，现在不少研究云计算的公司或机构都开始涉猎大数据和NoSQL领域，本书讲解的HBase数据 库是NoSQL的一种，同时是大数据处理的关键技术，本书可以帮助这部分读者快速且全面地了解HBase的原理、架构、使用场景和细节知识点，理解HBase在云计算、大数据和NoSQL中的位置。 （2）对Hadoop及HBase感兴趣的开发人员 Hadoop技术在近几年非常热，它已经是大数据处

4、理的关键技术，而HBase作为Hadoop生态系统的重要组件，已经被越来越多的公司使用。本书详细介绍了HBase与Hadoop的关系、HBase的基本概 念、核心知识点和高级特性，并且结合实战案例讲解，使得读者可以快速掌握HBase的使用。 （3）使用HBase进行数据库开发或运维的高级DBA HBase作为NoSQL数据库的一种，被越来越多的企业应用用作底层存储或者中间存储。本书不但讲解了HBase的原理和架构，更重要的是详细介绍了HBase的使用方法、运维监控和系统调优方法，能 够帮助该部分读者快速掌握大型分布式数据库的安装、运维和调优技巧。 （4）开源软件爱好者 HBase作为Apach

5、e基金会的顶级优秀开源项目，其实现过程中吸收了很多开源领域的优秀思想，同时也值得我们深入研究和学习。本书在讲解过程中剖析了不少HBase源代码，可以帮助该部分读者了 解和掌握HBase框架源代码的设计方法和技巧。 （5）开设相关课程的高等院校学生 现在越来越多的高等院校已经开设了大数据方向的学生培养课程。在这些课程中，Hadoop生态系统技术是核心课程，本书详细介绍Hadoop生态系统重要组件HBase，这部分读者可以将本书作 为参考教材使用。 如何阅读本书 本书分为三大部分。 第一部分为基础篇（第15章），介绍了大数据背景、HBase基本原理、模式设计、HBase的安装部署和所支持客户端AP

6、I及使用方法。 第二部分为实战篇（第68章），通过三个典型的应用案例和代码示例，结合实践技巧和理论知识，深入讲解如何使用HBase设计大型数据应用系统。 第三部分为高级篇（第912章），重点介绍HBase的整体架构、高级特性、运维监控和性能调优等，并结合生产系统的性能优化和运维经验进行讲解，旨在提升读者的实际操作经验。 最后本书列出了三个附录供读者参考。 附录A为HBase框架所有配置参数的介绍。 附录B为基于HBase的SQL引擎工具Phoenix的SQL语法详解。 附录C为HBase性能测试工具YCSB编译安装介绍。 如果你是一名已经具备一定Hadoop、HBase基础知识和使用经验的用户

7、，那么可以直接阅读第二部分和第三部分。第二部分侧重实战，第三部分侧重运维，请读者自行选择阅读。但是，如果你是一 名初学者，请一定从第1章的基础理论知识开始学习。 勘误和支持 本书第2、3章由孟鑫书写，第4章由李立松书写，其他章由马延辉书写。由于作者的水平有限，编写时间仓促，书中难免会出现一些错误或者不准确的地方，恳请读者批评指正。读者可以将书中的错 误发布在站点页面 发送邮件至邮箱binma85，期待能够得到你们的真挚反馈。 致谢 首先要感谢Google公司，它开放了如此优秀的论文BigTableHBase的原型。 感谢Apache基金会以及所有对开源软件和开源社区作出贡献的朋友。感谢一直以来

8、帮助过我们的数盟社区和EasyHadoop社区，他们提供的平台让我们认识了很多圈子里的同行，交流中技术和思想的 碰撞让我们受益匪浅。 感谢査礼老师百忙之中抽出时间为本书写推荐。 感谢对我们有过帮助的Ted Yu、叶刚、史彪、向磊、魏兴宝、卢亿磊、赵修湘、史东杰、廖旻可、陈书美、傅杰、费伟、孙利兵等人。 感谢机械工业出版社华章公司的编辑杨福川、姜影和白宇，在这一年多的时间中始终支持我们的写作，他们的鼓励和帮助引导着我们顺利完成本书。 最后感谢我们的爸爸、妈妈、爷爷、奶奶，感谢他们的养育之恩，并时时刻刻为我们灌输着信心和力量！ 谨以此书献给我们最亲爱的家人，以及众多热爱HBase的朋友们！ 马延辉

9、于中国北京 第一部分 基础篇 第1章 认识HBase 第2章 HBase安装与配置 第3章 数据模型 第4章 HBase表结构设计 第5章 HBase客户端 第1章 认识HBase 本章将介绍大数据背景和HBase的基本概念，从大数据引申到NoSQL，并阐述HBase出现的契机。随后，将介绍HBase的概念、发展历史、发行版本和基本特性。其中，HBase的核心功能模块将作为 一个小节单独重点介绍，最后通过介绍HBase的使用场景和经典案例，让读者朋友能够清晰地了解HBase可以做什么。 作为NoSQL家庭的一员，HBase的出现弥补了Hadoop只能离线批处理的不足，同时能够存储小文件，提供海

10、量数据的随机检索，并保证一定的性能。而这些特性也完善了整个Hadoop生态系统，泛 化其大数据的处理能力，结合其高性能、稳定、扩展性好的特行，给使用大数据的企业带来了福音。 因为本章是全书的开篇，唯有简明扼要地介绍才能帮助正在学习和想要学习HBase的读者，所以本章将提纲掣领地介绍HBase的相关知识，重点介绍HBase是什么以及HBase能做什么两部分。 1.1 理解大数据背景 经美国权威机构IDC调查发现，现如今的公司正在以前所未有的速度和丰富的类型产生数据，并且也有能力存储这些数据，但是，如何关联这两方面以便产生最大的商业价值，是所有公司共同面临的 挑战。这个问题非常复杂：虽然业务人员在

11、技能提升和专业工具的帮助下，越来越了解数据，但由于数据的增长速度越来越快，积累量级越来越大，公司可以利用的数据比例正在迅速下降。 1.1.1 什么是大数据 Gartner认为与过去相关概念相比，大数据强调3V特征，即Volume（量级）、Varity（种类）和Velocity（速度），如图1-1所示。 图1-1 大数据三大特性 如今存储的数据量正在急剧增长，2000年全球存储了EB级别的数据，预计到2020年，该值将变为ZB级别。仅Twitter每天就会生成超过10TB的数据，Facebook的数据为几十TB，一些特殊的企业在每 小时就会产生TB级别的数据。 上面这些企业是一些典型的案例，其实

12、我们生活的方方面面都会形成很多“轨迹”。例如，打开手机会生成一个事件；乘坐公共交通刷卡，这是一个事件；检票登机、打卡上班、App Store上购买应 用、更换电视频道、使用高速路电子收费系统等。每一项操作都会生成数据，并且该数据的量级与参与的人数相关，全球60亿人口，如果仅仅1/10的人参与进来，那么这个数据量级就已经非常惊人。就在 10年前IT界超过1TB的数据仓库屈指可数，而现在则是“举不胜举”。 随着传感器、智能设备以及社交协作技术的激增，企业中的数据也变得更加复杂，因为它不仅包含传统的关系型数据，还包含来自网页、Web日志文件、社交媒体论坛、电子邮件、文档、传感器数据 等原始、半结构化

13、和非结构化数据。 传统系统可能很难存储、分析这些数据的内容，更不要说挖掘有价值的信息。因为传统的数据库、数据仓库、联机事务处理等技术并不适合处理这些数据。尽管一些公司正在朝大数据方向大力发展， 但总体而言，大部分公司只是刚开始理解大数据。当回首整个数据库发展的历程会发现，人们将大部分时间都花在仅20%的数据上：这些数据格式整齐且符合严格模式的关系类型。但事实是，全球80%的 数据是非结构化的或者半结构化的。 视频和图片不能轻松或高效地存储在关系型数据库中，某些事件信息可能动态地更改（如气象），它们不太适合严格的模式。要利用大数据，企业必须能够分析所有类型的数据，包括关系和非关系数 据：文本、传

14、感器数据、音频和视频等。 有效处理大数据需要在数据变化的过程中对它的数量和种类进行分析，而不只是在“静止”状态进行分析。业界定义这种情况为从单纯批量计算模式到实时动态计算模式的内涵式转变。内涵式在这里 也比较容易理解，即结构优化、质量提高，是一种实现实质性的跨越式的进程。大数据平台允许用户将所有数据存储为其原生的业务对象格式，通过可用组件上的大规模并行计算实现价值，不仅仅是批量 处理和离线分析，同时支持实时查询和处理等特征，甚至要求响应时间在毫秒级别，并且可承受大规模的并发访问，这些都是“速度”特征的范畴。 1.1.2 为何大数据至关重要 这种非传统分析是否适合企业的业务需求？换句话说就是能否

15、找到一个大数据平台可为当前的分析工具提供补充实现，并且兼容现有解决方案，以实现更好的业务成果。 通常情况下，数据必须经过清理才能规范地存放到数据仓库中。相反大数据解决方案不仅会利用不适合传统仓库且数量庞大的数据，而且不需要改变原有数据格式，保留了数据的真实性，并能够快速 访问海量的信息。对于不能使用传统关系型数据库方法处理的信息所带来的挑战，大数据解决方案非常适合。大数据之所以重要，是因为其具备解决现实问题的三个关键方面。 分析各种不同来源的结构化、结构化和非结构化数据的理想选择。 当需要分析所有或大部分数据，或者对一个数据抽样分析效果不明显时，大数据解决方案是理想的选择。 未预先确定数据的业

16、务度量指标时，是进行迭代式和探索式分析的理想选择。 1.1.3 NoSQL在大数据中扮演的角色 NoSQL，是Not only SQL的缩写，泛指非关系型的数据库。与关系型数据库相比，NoSQL存在许多显著的不同点，其中最重要的是NoSQL不使用SQL作为查询语言。其数据存储可以不需要固定的表 模式，也通常会避免使用SQL的JOIN操作，一般又都具备水平可扩展的特性。NoSQL的实现具有两个特征：使用硬盘和把随机存储器作存储载体。 1.传统关系型数据库的缺陷 随着互联网Web 2.0的兴起，传统的关系数据库在应付Web 2.0网站，特别是超大规模和高并发的SNS类型动态网站时已经力不从心，暴露

17、了很多难以克服的问题。 （1）高并发读写的瓶颈 Web 2.0网站要根据用户个性化信息来实时生成动态页面和提供动态信息，所以基本上无法使用静态化技术，因此数据库并发负载非常高，可能峰值会达到每秒上万次读写请求。关系型数据库应付上 万次SQL查询还勉强顶得住，但是应付上万次SQL写数据请求，硬盘I/O却无法承受。其实对于普通的BBS网站，往往也存在相对高并发写请求的需求，例如，人人网的实时统计在线用户状态，记录热门帖 子的点击次数，投票计数等，这是一个相当普遍的业务需求。 （2）可扩展性的限制 在基于Web的架构中，数据库是最难以进行横向扩展的，当应用系统的用户量和访问量与日俱增时，数据库系统却

18、无法像Web Server和App Server那样简单地通过添加更多的硬件和服务节点来扩展 性能和负载能力。对于很多需要提供24小时不间断服务的网站来说，对数据库系统进行升级和扩展是非常痛苦的事情，往往需要停机维护和数据迁移，而不能通过横向添加节点的方式实现无缝扩展。 （3）事务一致性的负面影响 事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。保证数据库一致性是指当事务完成时，必须使所有数据都具有一致的状态。在关系型数据库中，所有的规则必须应用到事务 的修改上，以便维护所有数据的完整性，这随之而来的是性能的大幅度下降。很多Web系统并不需要严格的数据库事务，对读一致性的要求

19、很低，有些场合对写一致性要求也不高。因此数据库事务管理成 了高负载下的一个沉重负担。 （4）复杂SQL查询的弱化 任何大数据量的Web系统都非常忌讳几个大表间的关联查询，以及复杂的数据分析类型的SQL查询，特别是SNS类型的网站，从需求以及产品设计角度就避免了这种情况的产生。更多的情况往往只是 单表的主键查询，以及单表的简单条件分页查询，SQL的功能被极大地弱化了，所以这部分功能不能得到充分发挥。 2.NoSQL数据库的优势 （1）扩展性强 NoSQL数据库种类繁多，但是一个共同的特点就是去掉关系型数据库的关系特性，若数据之间是弱关系，则非常容易扩展。例如，HBase、Cassandra等系统

20、的水平扩展性能非常优越，非常容易实现 支撑数据从TB到PB级别的过渡。 （2）并发性能好 NoSQL数据库具有非常良好的读写性能，尤其在大数据量下，同样表现优秀。这得益于它的弱关系性，数据库的结构简单。一般MySQL使用Query Cache，每当表发生更新操作时，Cache就会失 效，这是一种大粒度的Cache，在针对Web 2.0的交互中频繁应用，Cache性能并不高。而NoSQL的Cache是记录级的，是一种细粒度的Cache，所以NoSQL在这个层面上来说性能要高很多。 （3）数据模型灵活 NoSQL无须事先为要存储的数据建立字段，随时可以存储自定义的数据格式。而在关系型数据库中，增删

21、字段是一件非常麻烦的事情。对于数据量非常大的表，增加字段简直就是一场噩梦。NoSQL允 许使用者随时随地添加字段，并且字段类型可以是任意格式。 HBase作为NoSQL数据库的一种，当然也具备上面提到的种种优势。使用过Hadoop的读者知道，Hadoop最适合的应用场景是离线批量处理数据，其离线分析的效率非常高，能在分钟级别处理TB级 的数据，但是一般的应用系统并不适合批量模式访问，更多的还是用户的随机访问，就类似访问关系型数据库中的某条记录一样。HBase的列式存储的特性支撑它实时随机读取、基于KEY的特殊访问需 求。当然，HBase还有不少新特性，其中不乏有趣的特性，在接下来的内容中将会详

22、细介绍。 1.2 HBase是什么 HBase（Hadoop Database）是一个高可靠、高性能、面向列、可伸缩的分布式数据库，利用HBase技术可在廉价PC上搭建起大规模结构化存储集群。HBase参考Google的BigTable建模，使用类似 GFS的HDFS作为底层文件存储系统，在其上可以运行MapReduce批量处理数据，使用ZooKeeper作为协同服务组件。 HBase的整个项目使用Java语言实现，它是Apache基金会的Hadoop项目的一部分，既是模仿Google BigTable的开源产品，同时又是Hadoop的衍生产品。而Hadoop作为批量离线计算系统已经得 到了业

23、界的普遍认可，并经过了工业上的验证，所以HBase具备“站在巨人肩膀之上”的优势，其发展势头非常迅猛。 HBase还是一种非关系型数据库，即NoSQL数据库。在Eric Brewer的CAP理论中，HBase属于CP类型的系统，其NoSQL的特性非常明显，这些特性也决定了其独特的应用场景。接下来的内容将详细 讲解HBase的发展历史、发行版本和特性。 1.2.1 HBase的发展历史 Apache HBase最初是Powerset公司为了处理自然语言搜索产生的海量数据而开展的项目，由Chad Walters和Jim Kellerman两人发起，经过两年的发展之后被Apache基金会收录为顶级项

24、目，同时 成为非常活跃、影响重大的项目。 2006年11月，Google开放了论文“Bigtable：A Distributed Storage System for Structured Data”，该论文就是HBase的原型。2007年2月，倡导者提出作为Hadoop的模块的HBase原型，该原 型包含HBase的基本介绍、表设计、行键设计和底层数据存储结构设计等内容1。 经过一段时间的酝酿和开发工作，在2007年10月第一个可用的、简单的HBase版本发布，该版本只实现了最基本的模块和功能，因为只是初始开发阶段，此时的HBase版本发展很不完善。2008年1 月，Hadoop升级为顶级项

25、目，HBase作为Hadoop的一个子项目存在，HBase的活跃度非常高，在短短不到2年的时间经历了N多个版本的发布，并且其中包含了版本号的大“跳跃”。下面是一些版本发 布的信息： hbase-0.18.0于2008年9月21日发布 hbase-0.20.6于2010年7月10日发布 hbase-0.89.20100621于2010年6月25日发布 其中，从hbase-0.20.6到hbase-0.89.20100621版本，经历了版本的大“跳跃”。在2009年秋季发布0.20系列版本后，HBase经历了发展历史上的一次版本大变动，在此之前的版本都追随Hadoop的 主版本，例如，hbase

26、0.X.*版本都会伴随着Hadoop 0.X.*版本，之所以出现版本跳跃，官方给出的解释有两点。 Hadoop的版本更新已经放缓，而HBase相比Hadoop开发来讲更加活跃，发布版本更加频繁，并且Hadoop已经有多个分支，HBase也需要兼容多个分支，所以不再需要与Hadoop的版本更新步伐保持一 致。 从HBase的功能实现上来讲，已经基本实现BigTable论文中实现的功能，也就是HBase的实现已经接近“1.0”，应该赋予一个更接近“1.0”的版本。 “跳跃”之后的版本发布比较规律，先后经历了0.90.*、0.92.*、0.94.*、0.96.*、0.98.*五个大的版本，现在稳定版

27、本是0.94.*。 1.2.2 HBase的发行版本 本节主要介绍现有HBase的版本知识，从0.90.0之后，HBase的版本更新是非常有规律的，可以从0.90.0、0.91.0、0.92.0、0.93.0、0.94.0、0.95.0、0.96.0、0.97.0、0.98.0这样的版本变化中发现一些 规律。 这些版本都是大版本，其中偶数版本是稳定发布版，而奇数版本都是开发版，基本不对外发布，但是可以在官方JIRA的项目管理系统中找到这些奇数版本对应的开发信息，并且可以在SVN上找到相关 的最新开发代码。所以，偶数发布版本属于稳定版本，奇数开发版本属于不稳定版本，一般不建议用户在生产环境中使用

28、开发版本，这些也是大版本的发布规律。 小版本一般基于当前大版本的问题进行修正，一般表示小版本的数字在1100之间，例如：0.94.1、0.94.2、0.94.3、0.94.4。这些小版本都是基于0.94大版本的，截止到本书撰写时，最新版本是 0.94.18。小版本都是从小到大依次递增，不存在版本跳跃的情况。对于小版本而言，原则上数值越大越稳定，因为小版本都是基于某一个大版本的，在小版本中并不会增加新特征，而是修正一些代码的漏 洞和问题。 截止到本书完稿时，HBase官方给出的最新版本信息如下面的代码所示。从中可以看出，发布版本存在0.94、0.96、0.98三个大版本。其中stable文件夹包

29、含了最新的稳定发布版本；to_remove表示已 经移除的版本；HEADER.html文件用于对代码发行版进行说明，即下面代码中的前半部分，从“HBase Releases path=/openresources/teach_ebook/uncompressed/14884/OEBPS/Text/.”开始，一直到“fresh.”结束的解释说明。每部分后面都有对应的发布时间，可以通过该时间判断版本发布的间隔和项目 的活跃程度。 HBase Releases Please make sure youre downloading from a nearby mirror site， not from

30、 www.apache.org. We suggest downloading the current stable release. The 0.96.x series supercedes 0.94.x. We are leaving the stable pointer on the latest 0.94.x for now while 0.96 is still fresh. File Name File Size Date hbase-0.94.17/ - 26-Feb-2014 01：31 hbase-0.94.18/ - 24-Mar-2014 19：10 hbase-0.96

31、.2/ - 03-Apr-2014 23：18 hbase-0.98.0/ - 07-Feb-2014 01：26 stable/ - 24-Mar-2014 19：10 to_remove/ - 07-Apr-2013 20：38 HEADER.html 429 19-Oct-2013 15：49 stable文件夹中存放的是最新的稳定发布版本，从下面的代码中可以看到最新的稳定版本信息，其中发布版本包含文件名字、文件大小和发布日期等参数。在下面两个版本中，带有security后缀的版本 可以使用安全认证和权限控制，基于Kerberos协议结构；另外一个版本是常规版本，一般搭建不需要用户权限控

32、制的集群可以使用这个版本，权限控制部分可以交由中间业务逻辑层控制。 File Name File Size Date hbase-0.94.18-security.tar.gz 59108691 24-Mar-2014 19：10 hbase-0.94.18.tar.gz 58691770 24-Mar-2014 19：10 HBase版本从0.94.0到0.96.0，变化比较大，由于Hadoop 2.0发布，HDFS已经发生变化，为了适应Hadoop 2.0的架构改变，HBase提供一个基于Hadoop 2.0的独立版本，该版本只支持Hadoop 2.0。同时，基于Hadoop 1.*版本的

33、HBase继续存在，并且将长期存在，两个版本之间并不兼容，所以在发布、下载界面会看到两种版本的HBase同时存在，如下所示： Name Last modified Size Description hbase-0.96.1.1-hadoop1-bin.tar.gz 20-Dec-2013 03：50 70M hbase-0.96.1.1-hadoop1-bin.tar.gz.mds 20-Dec-2013 03：50 1.3K hbase-0.96.1.1-hadoop2-bin.tar.gz 20-Dec-2013 03：50 86M hbase-0.96.1.1-hadoop2-bin.t

34、ar.gz.mds 20-Dec-2013 03：50 1.3K hbase-0.96.1.1-src.tar.gz 20-Dec-2013 03：50 4.9M hbase-0.96.1.1-src.tar.gz.mds 20-Dec-2013 03：50 1.1K 由于在写作本书时，HBase的0.96版本分支上只有0.96.1.1版本，所以这里使用该版本作为示例，该示例中包含hadoop 1、hadoop 2和源码三个部分，也是从0.96版本开始，HBase将保持两个版本并 存的状态，这种状态将会在很长一段时间内持续存在。 这里不建议使用非稳定版本，即0.96及以上的版本，因为很多的新功

35、能并没有经过工业界的验证。如果必须使用支持Hadoop 2.0的版本，建议使用0.96这个分支，因为这个分支已经迭代过不少小版 本，相对稳定。另外，一直致力于Hadoop技术研发和推广、HBase核心贡献者、Hortonworks高级技术成员Ted Yu对该版本的新功能、特性非常推崇，有些时候还是需要相信权威。 这里需要特别声明一下，本书的知识点讲解、安装部署、实战案例和性能调优等都是基于HBase 0.94版本的，该版本是写作本书时的最新稳定版。 1.2.3 HBase的特性 HBase作为一个典型的NoSQL数据库，可以通过行键（Rowkey）检索数据，仅支持单行事务，主要用于存储非结构化

36、和半结构化的松散数据。与Hadoop相同，HBase设计目标主要依靠横向扩展， 通过不断增加廉价的商用服务器来增加计算和存储能力。 “典型”代表着HBase有不少特性，这些特性都标志着HBase的特立独行、与众不同，同时其良好的出身和特性也奠定了其在大数据处理领域的地位。下面介绍HBase具备的一些非常显著的特点。 1.容量巨大 HBase的单表可以有百亿行、百万列，数据矩阵横向和纵向两个维度所支持的数据量级都非常具有弹性。传统的关系型数据库，如Oracle和MySQL等，如果数据记录在亿级别，查询和写入的性能都会 呈指数级下降，所以更大的数据量级对传统数据库来讲是一种灾难。而HBase对于存

37、储百亿、千亿甚至更多的数据都不存在任何问题。对于高维数据，百万量级的列没有任何问题。有的读者可能关心更加 多的列：千万和亿级别，这种非常特殊的应用场景，并不是说HBase不支持，而是这种情况下访问单个Rowkey可能造成访问超时，如果限定某个列则不会出现这种问题。 2.面向列 HBase是面向列的存储和权限控制，并支持列独立检索。有些读者可能不清楚什么是列式存储，下面进行简单介绍。列式存储不同于传统的关系型数据库，其数据在表中是按某列存储的，这样在查询 只需要少数几个字段的时候，能大大减少读取的数据量，比如一个字段的数据聚集存储，那就更容易为这种聚集存储设计更好的压缩和解压算法。下面是传统行式

38、数据库与列式数据库的不同特性。 传统行式数据库的特性如下： 数据是按行存储的。 没有索引的查询使用大量I/O。 建立索引和物化视图需要花费大量的时间和资源。 面对查询需求，数据库必须被大量膨胀才能满足需求。 列式数据库的特性如下： 数据按列存储，即每一列单独存放。 数据即索引。 只访问查询涉及的列，可以大量降低系统I/O。 每一列由一个线索来处理，即查询的并发处理性能高。 数据类型一致，数据特征相似，可以高效压缩。 列式存储不但解决了数据稀疏性问题，最大程度上节省存储开销，而且在查询发生时，仅检索查询涉及的列，能够大量降低磁盘I/O。这些特性也支撑HBase能够保证一定的读写性能。 3.稀疏性

39、 在大多数情况下，采用传统行式存储的数据往往是稀疏的，即存在大量为空（NULL）的列，而这些列都是占用存储空间的，这就造成存储空间的浪费。对于HBase来讲，为空的列并不占用存储空间， 因此，表可以设计得非常稀疏。 4.扩展性 HBase底层文件存储依赖HDFS，从“基因”上决定了其具备可扩展性。这种遗传的可扩展性就如同OOP中的继承，“父类”HDFS的扩展性遗传到HBase框架中。这是最底层的关键点。同时，HBase 的Region和RegionServer的概念对应的数据可以分区，分区后数据可以位于不同的机器上，所以在HBase核心架构层面也具备可扩展性。HBase的扩展性是热扩展，在不停

40、止现有服务的前提下，可以随时 添加或者减少节点。 5.高可靠性 HBase提供WAL和Replication机制。前者保证了数据写入时不会因集群异常而导致写入数据的丢失；后者保证了在集群出现严重问题时，数据不会发生丢失或者损坏。而且HBase底层使用 HDFS，HDFS本身的副本机制很大程度上保证了HBase的高可靠性。同时，协调服务的ZooKeeper组件是经过工业验证的，具备高可用性和高可靠性。 6.高性能 底层的LSM数据结构和Rowkey有序排列等架构上的独特设计，使得HBase具备非常高的写入性能。Region切分、主键索引和缓存机制使得HBase在海量数据下具备一定的随机读取性能，

41、该性能针对 Rowkey的查询能够达到毫秒级别。同时，HBase对于高并发的场景也具备很好的适应能力。该特性也是业界众多公司选取HBase作为存储数据库非常重要的一点。 1 参见https:/cwiki.apache.org/confluence/display/DIRxSBOX/HBase+Prototype。 1.3 HBase与Hadoop的关系 HBase参考了Google的BigTable建模，且将下面三篇博文作为HBase实现的理论基础： BigTable by Google（2006） HBase and HDFS Locality by Lars George（2010） No

42、 Relation：The Mixed Blessings of Non-Relational Databases by Ian Varley（2009） 从上面的博文列表中也可以看出，HBase和HDFS有着非常紧密的关系，更准确的说法是：HBase严重依赖Hadoop的HDFS组件，HBase使用HDFS作为底层存储系统。因此，如果要使用HBase，前提 是首先必须有Hadoop系统。从后面第2章的HBase安装过程的讲解中也可以总结出这点。Hadoop的组件之一MapReduce可以直接访问HBase，但是，这不是必需的，因为HBase中最重要的访问方式是 原生Java API，而不是M

43、apReduce这样的批量操作方式。图1-2展示了HBase在Hadoop生态系统中的位置。 图1-2 Hadoop生态系统总图 因为HBase底层依赖Hadoop，所以选择Hadoop版本对HBase部署很关键。表1-1显示了不同HBase发行版本所支持的Hadoop版本信息。基于HBase版本，应该选择合适的Hadoop版本，表1-1中是 官方给出的HBase和Hadoop的版本支持矩阵。 表1-1 Hadoop版本支持矩阵 表1-1中字母的含义如下。 S：经过测试的、支持的。 X：不支持。 NT：可以运行但测试不充分。 当然，并不是说只要满足表1-1中的版本匹配就万事大吉了，在考虑版本匹

44、配的同时，也需要考虑一些其他因素，例如： 如果使用0.94.x运行在Hadoop 2.2.0版本上，需要重新编译0.94.x。 对于ZooKeeper的版本只需要跟HBase依赖库中的ZooKeeper保持一致即可。 1.4 HBase的核心功能模块 Hadoop框架包含两个核心组件：HDFS和MapReduce，其中HDFS是文件存储系统，负责数据存储；MapReduce是计算框架，负责数据计算。它们之间分工明确、低度耦合、相关关联。对于HBase 数据库的核心组件，即核心功能模块共有4个，它们分别是：客户端Client、协调服务模块ZooKeeper、主节点HMaster和Region节点

45、RegionServer，这些组件的描述和相互之间的关联关系如图1-3所 示。 图1-3 HBase架构图 1.4.1 客户端Client 客户端Client是整个HBase系统的入口。使用者直接通过客户端操作HBase。客户端使用HBase的RPC机制与HMaster和RegionServer进行通信。对于管理类操作，Client与HMaster进行RPC通信；对 于数据读写类操作，Client与RegionServer进行RPC交互。这里客户端可以是多个，并不限定是原生Java接口，还有Thrift、Avro、Rest等客户端模式，甚至MapReduce也可以算作一种客户端。 1.4.2

46、协调服务组件ZooKeeper ZooKeeper Quorum（队列）负责管理HBase中多HMaster的选举、服务器之间状态同步等。再具体一些就是，HBase中ZooKeeper实例负责的协调工作有：存储HBase元数据信息、实时监控 RegionServer、存储所有Region的寻址入口，当然还有最常见的功能就是保证HBase集群中只有一个HMaster节点。 1.4.3 主节点HMaster HMaster没有单点问题，在HBase中可以启动多个HMaster，通过ZooKeeper的Master选举机制保证总有一个Master正常运行并提供服务，其他HMaster作为备选时刻准备

47、（当目前HMaster出现问 题时）提供服务。HMaster主要负责Table和Region的管理工作： 管理用户对Table的增、删、改、查操作。 管理RegionServer的负载均衡，调整Region分布。 在Region分裂后，负责新Region的分配。 在RegionServer死机后，负责失效RegionServer上的Region迁移。 1.4.4 Region节点HRegionServer HRegionServer主要负责响应用户I/O请求，向HDFS文件系统中读写数据，是HBase中最核心的模块。HRegionServer内部管理了一系列HRegion对象，每个HRegio

48、n对应了Table中的一个Region。 HRegion由多个HStore组成，每个HStore对应了Table中的一个Column Family的存储。可以看出每个Column Family其实就是一个集中的存储单元，因此最好将具备共同I/O特性的列放在一个Column Family中，这样能保证读写的高效性。HRegionServer的组成结构如图1-4所示。 如图1-4所示，HStore存储是HBase存储的核心，由两部分组成：MemStore和StoreFile。MemStore是Sorted Memory Buffer，用户写入的数据首先会放入MemStore中，当MemStore满

49、了以后会 缓冲（flush）成一个StoreFile（底层实现是HFile），当StoreFile文件数量增长到一定阈值，会触发Compact操作，将多个StoreFiles合并成一个StoreFile，在合并过程中会进行版本合并和数据删除，因 此可以看出HBase其实只有增加数据，所有的更新和删除操作都是在后续的Compact过程中进行的，这使得用户的写操作只要进入内存中就可以立即返回，保证了HBase I/O的高性能。 图1-4 HRegionServer的组成结构 StoreFiles在触发Compact操作后，会逐步形成越来越大的StoreFile，当单个StoreFile大小超过一定阈值后，会触发Split操作，同时把当前Region分裂成2个Region，父Region会下线，新分裂的2个 子Region会被HMaster分配到相应的HRegionServer上，使得原先1个Region的压力得以分流到2个Region上。 每个HRegionServer中都有一个HLog对象，HLog是