(特价书)HBase企业应用开发实战

1.5.2　增量数据存储 15
1.5.3　用户内容服务 17
1.5.4　实时消息系统构建 18
1.6　本章小结 18
第2章　HBase安装与配置 19
2.1　先决条件 19
2.2　HBase运行模式 23
2.2.1　单机模式 23
2.2.2　分布式模式 24
2.3　HBase的Web UI 31
2.4　HBase Shell工具使用 31
2.5　停止HBase集群 33
2.6　本章小结 33
第3章　数据模型 34
3.1　两类数据模型 34
3.1.1　逻辑模型 35
3.1.2　物理模型 35
3.2　数据模型的重要概念 36
3.2.1　表 36
3.2.2　行键 37
3.2.3　列族 38
3.2.4　单元格 38
3.3　数据模型的操作 38
3.3.1　读Get 39
3.3.2　写Put 39
3.3.3　扫描Scan 39
3.3.4　删除Delete 40
3.4　数据模型的特殊属性 40
3.4.1　版本 40
3.4.2　排序 42
3.4.3　列的元数据 42
3.4.4　连接查询 43
3.4.5　计数器 43
3.4.6　原子操作 43
3.4.7　事务特性ACID 43
3.4.8　行锁 45
3.4.9　自动分区 45
3.5　CAP原理与最终一致性 46
3.6　本章小结 47
第4章　HBase表结构设计 48
4.1　模式创建 48
4.2　Rowkey设计 49
4.3　列族定义 51
4.3.1　可配置的数据块大小 51
4.3.2　数据块缓存 52
4.3.3　布隆过滤器 52
4.3.4　数据压缩 53
4.3.5　单元时间版本 53
4.3.6　生存时间 54
4.4　模式设计实例 54
4.4.1　实例1：动物分类 54
4.4.2　实例2：店铺与商品 56
4.4.3　实例3：网上商城用户消费记录 57
4.4.4　实例4：微博用户与粉丝 58
4.5　本章小结 60
第5章　HBase客户端 61
5.1　精通原生Java客户端 61
5.1.1　客户端配置 62
5.1.2　创建表 69
5.1.3　删除表 70
5.1.4　插入数据 70
5.1.5　查询数据 72
5.1.6　删除数据 76
5.1.7　过滤查询 77
5.2　使用HBase Shell工具操作HBase 79
5.2.1　命令分类 79
5.2.2　常规命令 80
5.2.3　DDL命令 81
5.2.4　DML命令 82
5.2.5　工具命令Tools 86
5.2.6　复制命令 87
5.2.7　安全命令 87
5.3　使用Thrift客户端访问HBase 88
5.3.1　Thrift与Thrift2区别 88
5.3.2　安装与部署Thrift2 89
5.3.3　Python使用案例 93
5.4　通过REST客户端访问HBase 95
5.4.1　启动服务 95
5.4.2　使用REST访问example表 96
5.5　使用MapReduce批量操作HBase 97
5.5.1　三种访问模式 98
5.5.2　实现MapReduce API 98
5.5.3　HBase作为输入源示例 99
5.5.4　HBase作为输出源示例 101
5.5.5　HBase作为共享源示例 103
5.6　通过Web UI工具查看HBase状态 106
5.6.1　Master状态界面 106
5.6.2　RegionServer状态界面 107
5.6.3　ZooKeeper统计信息页面 109
5.7　其他客户端 110
5.8　本章小结 110
第二部分　实战篇
第6章　整合SQL引擎层 114
6.1　NoSQL背景知识 114
6.1.1　什么是NoSQL 114
6.1.2　将SQL整合到HBase的原因 115
6.1.3　基于HBase的SQL引擎实现 116
6.2　Hive整合HBase的实现 119
6.2.1　认识Hive 119
6.2.2　Hive整合HBase的环境准备 122
6.2.3　Linux环境下重新编译Hive 123
6.2.4　Hive参数配置 125
6.2.5　启动Hive 127
6.2.6　Hive与HBase整合后的框架如何使用 127
6.2.7　HBase到Hive的字段映射 133
6.2.8　多列与Hive Map类型 134
6.3　查询引擎Phoenix 137
6.3.1　认识Phoenix 138
6.3.2　Phoenix安装环境准备 141
6.3.3　Phoenix安装部署 142
6.3.4　Phoenix源码编译 143
6.3.5　Phoenix中SQLLine的快速使用 149
6.3.6　使用JDBC访问Phoenix 153
6.4　对象映射框架Kundera 155
6.4.1　认识Kundera 155
6.4.2　Kundera的客户端API快速使用 158
6.4.3　Kundera模块介绍 161
6.4.4　Kundera的REST访问方式 162
6.5　分布式SQL引擎Lealone 165
6.5.1　认识Lealone 165
6.5.2　Lealone的安装部署 166
6.5.3　通过JDBC访问Lealone 168
6.5.4　通过Python访问Lealone 169
6.5.5　Lealone特有的建表语法 170
6.6　本章小结 171
第7章　构建音乐站用户属性库 173
7.1　案例背景 173
7.1.1　音乐站 173
7.1.2　需求概述 175
7.1.3　需求范围和系统边界 175
7.1.4　需求详述 176
7.1.5　名词解释 180
7.2　概要设计 181
7.2.1　设计目标 181
7.2.2　数据规模假设 181
7.2.3　功能指标 182
7.2.4　系统流程 182
7.3　表结构设计 183
7.3.1　功能抽象 183
7.3.2　逻辑结构 184
7.3.3　Rowkey设计 188
7.3.4　列族设计 188
7.3.5　版本定义 188
7.3.6　优化属性定义 188
7.4　数据加载 189
7.4.1　加载流程 189
7.4.2　Mapper类 190
7.4.3　Main类 192
7.4.4　运行 193
7.5　数据检索 193
7.5.1　HBaseTable 193
7.5.2　HBaseAdmin 193
7.5.3　几种检索类型 195
7.6　后台查询 198
7.6.1　二级索引实现 198
7.6.2　后台查询系统 205
7.7　本章小结 206
第8章　构建广告实时计算系统 208
8.1　理解广告数据和流处理框架 208
8.1.1　网络广告的几大特性 209
8.1.2　网络广告的数据类型 210
8.1.3　流处理框架 211
8.1.4　背景与需求描述 217
8.2　概要设计 218
8.2.1　设计目标 219
8.2.2　主要功能 219
8.2.3　系统架构 219
8.3　详细设计 221
8.3.1　表结构设计 221
8.3.2　功能模块设计 222
8.4　核心功能实现 223
8.4.1　规划集群环境部署 223
8.4.2　安装ZooKeeper集群 225
8.4.3　安装Kafka分布式集群 228
8.4.4　实现Kafka生产者 231
8.4.5　安装Storm分布式集群 233
8.4.6　查看集群节点部署情况 240
8.4.7　基于Storm-kafka中间件实现计算逻辑 240
8.4.8　如何使用HBase中统计数据 251
8.5　本章小结 252
第三部分　高级篇
第9章　核心概念 254
9.1　核心结构 254
9.1.1　B+树 255
9.1.2　LSM树 255
9.1.3　两种结构本质区别 257
9.2　底层持久化 258
9.2.1　存储基本架构 258
9.2.2　HDFS文件 259
9.2.3　Region切分 264
9.2.4　合并 265
9.2.5　HFile格式 266
9.2.6　KeyValue格式 269
9.3　预写日志 270
9.3.1　概要流程 270
9.3.2　相关Java类 271
9.3.3　日志回放 274
9.3.4　日志一致性 275
9.4　写入流程 276
9.4.1　客户端 276
9.4.2　服务器端 281
9.5　查询流程 286
9.5.1　两种查询操作 286
9.5.2　客户端 286
9.5.3　服务器端 287
9.6　数据备份 291
9.6.1　备份机制架构 292
9.6.2　故障恢复 292
9.7　数据压缩 294
9.7.1　支持的压缩算法 295
9.7.2　使用配置 295
9.8　本章小结 296
第10章　HBase高级特性 297
10.1　过滤器 297
10.1.1　过滤器的两类参数 297
10.1.2　比较器 298
10.1.3　列值过滤器 300
10.1.4　键值元数据过滤器 300
10.1.5　行键过滤器 303
10.1.6　功能过滤器 303
10.1.7　Thrift使用过滤器 304
10.1.8　过滤器总结 309
10.2　计数器 310
10.2.1　使用Shell操作计数器 310
10.2.2　基于单列的计数器 312
10.2.3　多列计数器 313
10.3　协处理器 314
10.3.1　认识协处理器 315
10.3.2　观察者Observer 316
10.3.3　终端EndPoint 318
10.3.4　协处理器部署 320
10.4　Schema设计要点 323
10.4.1　行键设计 323
10.4.2　列族设计 325
10.5　二级索引 325
10.5.1　Client-managed方式 326
10.5.2　ITHBase实现 326
10.5.3　IHBase实现 329
10.5.4　Coprocessor方式 329
10.5.5　MapReduce两种方式 330
10.6　布隆过滤器 330
10.6.1　基本概念 331
10.6.2　配置布隆过滤器 332
10.6.3　使用布隆过滤器 333
10.7　负载均衡 333
10.7.1　全局计划 334
10.7.2　随机分配计划 337
10.7.3　批量启动分配计划 337
10.7.4　通过Shell控制负载均衡 338
10.8　批量加载 338
10.8.1　准备数据：importtsv 338
10.8.2　加载数据：completebulkload 340
10.9　本章小结 340
第11章　集群运维管理 341
11.1　HBase常用工具 341
11.1.1　文件检测修复工具hbck 342
11.1.2　文件查看工具hfile 346
11.1.3　WAL日志查看工具hlog 348
11.1.4　压缩测试工具CompressionTest 349
11.1.5　数据迁移工具CopyTable 350
11.1.6　导出工具export 351
11.1.7　导入工具Import 351
11.1.8　日志回放工具WALPlayer 351
11.1.9　行数统计工具RowCounter 352
11.2　Region和RegionServer管理 353
11.2.1　大合并工具major_compact 353
11.2.2　Region合并工具Merge 354
11.2.3　下线节点 354
11.2.4　滚动重启 355
11.3　性能指标Metrics 356
11.3.1　Master Metrics 357
11.3.2　RegionServer Metrics 357
11.3.3　RPC Metrics 358
11.3.4　JVM Metrics 359
11.3.5　集群属性Metrics 360
11.4　监控系统Ganglia 360
11.4.1　HBase监控指标 360
11.4.2　安装、部署和使用Ganglia 361
11.5　HBase管理扩展JMX 366
11.5.1　如何使用JMX 366
11.5.2　基于JMX的监控工具Ella 368
11.6　报警工具Nagios 371
11.7　故障处理 376
11.7.1　问题咨询渠道 377
11.7.2　常用日志信息 377
11.7.3　常用故障调试工具 379
11.7.4　客户端故障排查 384
11.7.5　MapReduce故障排查 386
11.7.6　网络故障排查 387
11.7.7　RegionServer相关问题解决 387
11.7.8　Master相关问题解决 391
11.7.9　ZooKeeper相关问题解决 392
11.8　集群备份 392
11.8.1　冷备份 393
11.8.2　热备份之Replication 393
11.8.3　热备份之CopyTable 393
11.8.4　热备份之Export 393
11.9　本章小结 393
第12章　性能调优 395
12.1　硬件和操作系统调优 395
12.1.1　配置内存 395
12.1.2　配置CPU 396
12.1.3　操作系统 396
12.2　网络通信调优 399
12.2.1　配置交换机 399
12.2.2　添加机架感知 401
12.3　JVM优化 402
12.3.1　Java垃圾回收算法 402
12.3.2　Java垃圾收集器 403
12.3.3　垃圾回收器的选择 405
12.3.4　JVM参数设置 406
12.4　HBase查询优化 408
12.4.1　设置Scan缓存 408
12.4.2　显式地指定列 409
12.4.3　关闭ResultScanner 410
12.4.4　禁用块缓存 410
12.4.5　优化行键查询 410
12.4.6　通过HTableTool访问 410
12.4.7　使用批量读 411
12.4.8　使用Filter降低客户端压力 412
12.4.9　使用Coprocessor统计行数 412
12.4.10　缓存查询结果 413
12.5　HBase写入优化 413
12.5.1　关闭写WAL日志 413
12.5.2　设置AutoFlush 414
12.5.3　预创建Region 415
12.5.4　延迟日志flush 419
12.5.5　通过HTableTool访问 419
12.5.6　使用批量写 420
12.6　HBase基本核心服务优化 421
12.6.1　优化分裂操作 421
12.6.2　优化合并操作 423
12.7　HBase配置参数优化 423
12.7.1　设置RegionServer Handler数量 423
12.7.2　调整BlockCache大小 425
12.7.3　设置MemStore的上下限 426
12.7.4　调整影响合并的文件数 427
12.7.5　调整MemStore的flush因子 427
12.7.6　调整单个文件大小 427
12.7.7　调整ZooKeeper Session的有效时长 428
12.8　分布式协调系统ZooKeeper优化 428
12.8.1　配置ZooKeeper节点数 428
12.8.2　独立ZooKeeper集群 429
12.9　表设计优化 430
12.9.1　开启布隆过滤器 430
12.9.2　调整列族块大小 430
12.9.3　设置In Memory属性 432
12.9.4　调整列族最大版本数 434
12.9.5　设置TTL属性 435
12.10　其他优化 436
12.10.1　关闭MapReduce的预测执行功能 436
12.10.2　修改负载均衡执行周期 438
12.11　性能测试 438
12.12　本章小结 441
附录A　HBase配置参数介绍 442
附录B　Phoenix SQL语法详解 451
附录C　YCSB编译安装 468

.　　第二部分为实战篇（第6～8章），通过三个典型的应用案例和代码示例，结合实践技巧和理论知识，深入讲解如何使用HBase设计大型数据应用系统。
　　第三部分为高级篇（第9～12章），重点介绍HBase的整体架构、高级特性、运维监控和性能调优等，并结合生产系统的性能优化和运维经验进行讲解，旨在提升读者的实际操作经验。
　　最后本书列出了三个附录供读者参考。
　　附录A为HBase框架所有配置参数的介绍。
　　附录B为基于HBase的SQL引擎工具Phoenix的SQL语法详解。
　　附录C为HBase性能测试工具YCSB编译安装介绍。
　　如果你是一名已经具备一定Hadoop、HBase基础知识和使用经验的用户，那么可以直接阅读第二部分和第三部分。第二部分侧重实战，第三部分侧重运维，请读者自行选择阅读。但是，如果你是一名初学者，请一定从第1章的基础理论知识开始学习。
　　勘误和支持
　　本书第2、3章由孟鑫书写，第4章由李立松书写，其他章由马延辉书写。由于作者的水平有限，编写时间仓促，书中难免会出现一些错误或者不准确的地方，恳请读者批评指正。读者可以将书中的错误发布在站点页面http://www.adintellig.com/hbase-in-action/的留言中。同时如果你遇到任何问题，也可以访问该页面，我们将尽量在线上为你提供最满意的解答。如果你有更多的宝贵意见，也欢迎发送邮件至邮箱binma85@gmail.com，期待能够得到你们的真挚反馈。
　　致谢
　　首先要感谢Google公司，它开放了如此优秀的论文BigTable——HBase的原型。
　　感谢Apache基金会以及所有对开源软件和开源社区作出贡献的朋友。感谢一直以来帮助过我们的数盟社区和EasyHadoop社区，他们提供的平台让我们认识了很多圈子里的同行，交流中技术和思想的碰撞让我们受益匪浅。
　　感谢査礼老师百忙之中抽出时间为本书写推荐。
　　感谢对我们有过帮助的Ted Yu、叶刚、史彪、向磊、魏兴宝、卢亿磊、赵修湘、史东杰、廖旻可、陈书美、傅杰、费伟、孙利兵等人。
　　感谢机械工业出版社华章公司的编辑杨福川、姜影和白宇，在这一年多的时间中始终支持我们的写作，他们的鼓励和帮助引导着我们顺利完成本书。
　　最后感谢我们的爸爸、妈妈、爷爷、奶奶，感谢他们的养育之恩，并时时刻刻为我们灌输着信心和力量！
　　谨以此书献给我们最亲爱的家人，以及众多热爱HBase的朋友们！
　　
　　马延辉于中国北京
　　

.　　传统系统可能很难存储、分析这些数据的内容，更不要说挖掘有价值的信息。因为传统的数据库、数据仓库、联机事务处理等技术并不适合处理这些数据。尽管一些公司正在朝大数据方向大力发展，但总体而言，大部分公司只是刚开始理解大数据。当回首整个数据库发展的历程会发现，人们将大部分时间都花在仅20%的数据上：这些数据格式整齐且符合严格模式的关系类型。但事实是，全球80%的数据是非结构化的或者半结构化的。
　　视频和图片不能轻松或高效地存储在关系型数据库中，某些事件信息可能动态地更改（如气象），它们不太适合严格的模式。要利用大数据，企业必须能够分析所有类型的数据，包括关系和非关系数据：文本、传感器数据、音频和视频等。
　　有效处理大数据需要在数据变化的过程中对它的数量和种类进行分析，而不只是在“静止”状态进行分析。业界定义这种情况为从单纯批量计算模式到实时动态计算模式的内涵式转变。内涵式在这里也比较容易理解，即结构优化、质量提高，是一种实现实质性的跨越式的进程。大数据平台允许用户将所有数据存储为其原生的业务对象格式，通过可用组件上的大规模并行计算实现价值，不仅仅是批量处理和离线分析，同时支持实时查询和处理等特征，甚至要求响应时间在毫秒级别，并且可承受大规模的并发访问，这些都是“速度”特征的范畴。
　　1.1.2为何大数据至关重要
　　这种非传统分析是否适合企业的业务需求？换句话说就是能否找到一个大数据平台可为当前的分析工具提供补充实现，并且兼容现有解决方案，以实现更好的业务成果。
　　通常情况下，数据必须经过清理才能规范地存放到数据仓库中。相反大数据解决方案不仅会利用不适合传统仓库且数量庞大的数据，而且不需要改变原有数据格式，保留了数据的真实性，并能够快速访问海量的信息。对于不能使用传统关系型数据库方法处理的信息所带来的挑战，大数据解决方案非常适合。大数据之所以重要，是因为其具备解决现实问题的三个关键方面。
　　分析各种不同来源的结构化、结构化和非结构化数据的理想选择。
　　当需要分析所有或大部分数据，或者对一个数据抽样分析效果不明显时，大数据解决方案是理想的选择。
　　未预先确定数据的业务度量指标时，是进行迭代式和探索式分析的理想选择。
　　1.1.3NoSQL在大数据中扮演的角色
　　NoSQL，是Not only SQL的缩写，泛指非关系型的数据库。与关系型数据库相比，NoSQL存在许多显著的不同点，其中最重要的是NoSQL不使用SQL作为查询语言。其数据存储可以不需要固定的表模式，也通常会避免使用SQL的JOIN操作，一般又都具备水平可扩展的特性。NoSQL的实现具有两个特征：使用硬盘和把随机存储器作存储载体。
　　1.?传统关系型数据库的缺陷
　　随着互联网Web 2.0的兴起，传统的关系数据库在应付Web 2.0网站，特别是超大规模和高并发的SNS类型动态网站时已经力不从心，暴露了很多难以克服的问题。
　　（1）高并发读写的瓶颈
　　Web 2.0网站要根据用户个性化信息来实时生成动态页面和提供动态信息，所以基本上无法使用静态化技术，因此数据库并发负载非常高，可能峰值会达到每秒上万次读写请求。关系型数据库应付上万次SQL查询还勉强顶得住，但是应付上万次SQL写数据请求，硬盘I/O却无法承受。其实对于普通的BBS网站，往往也存在相对高并发写请求的需求，例如，人人网的实时统计在线用户状态，记录热门帖子的点击次数，投票计数等，这是一个相当普遍的业务需求。
　　（2）可扩展性的限制
　　在基于Web的架构中，数据库是最难以进行横向扩展的，当应用系统的用户量和访问量与日俱增时，数据库系统却无法像Web Server和App Server那样简单地通过添加更多的硬件和服务节点来扩展性能和负载能力。对于很多需要提供24小时不间断服务的网站来说，对数据库系统进行升级和扩展是非常痛苦的事情，往往需要停机维护和数据迁移，而不能通过横向添加节点的方式实现无缝扩展。
　　（3）事务一致性的负面影响
　　事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。保证数据库一致性是指当事务完成时，必须使所有数据都具有一致的状态。在关系型数据库中，所有的规则必须应用到事务的修改上，以便维护所有数据的完整性，这随之而来的是性能的大幅度下降。很多Web系统并不需要严格的数据库事务，对读一致性的要求很低，有些场合对写一致性要求也不高。因此数据库事务管理成了高负载下的一个沉重负担。
　　（4）复杂SQL查询的弱化
　　任何大数据量的Web系统都非常忌讳几个大表间的关联查询，以及复杂的数据分析类型的SQL查询，特别是SNS类型的网站，从需求以及产品设计角度就避免了这种情况的产生。更多的情况往往只是单表的主键查询，以及单表的简单条件分页查询，SQL的功能被极大地弱化了，所以这部分功能不能得到充分发挥。
　　2.?NoSQL数据库的优势
　　（1）扩展性强
　　NoSQL数据库种类繁多，但是一个共同的特点就是去掉关系型数据库的关系特性，若数据之间是弱关系，则非常容易扩展。例如，HBase、Cassandra等系统的水平扩展性能非常优越，非常容易实现支撑数据从TB到PB级别的过渡。
　　（2）并发性能好
　　NoSQL数据库具有非常良好的读写性能，尤其在大数据量下，同样表现优秀。这得益于它的弱关系性，数据库的结构简单。一般MySQL使用Query Cache，每当表发生更新操作时，Cache就会失效，这是一种大粒度的Cache，在针对Web 2.0的交互中频繁应用，Cache性能并不高。而NoSQL的Cache是记录级的，是一种细粒度的Cache，所以NoSQL在这个层面上来说性能要高很多。
　　（3）数据模型灵活
　　NoSQL无须事先为要存储的数据建立字段，随时可以存储自定义的数据格式。而在关系型数据库中，增删字段是一件非常麻烦的事情。对于数据量非常大的表，增加字段简直就是一场噩梦。NoSQL允许使用者随时随地添加字段，并且字段类型可以是任意格式。
　　HBase作为NoSQL数据库的一种，当然也具备上面提到的种种优势。使用过Hadoop的读者知道，Hadoop最适合的应用场景是离线批量处理数据，其离线分析的效率非常高，能在分钟级别处理TB级的数据，但是一般的应用系统并不适合批量模式访问，更多的还是用户的随机访问，就类似访问关系型数据库中的某条记录一样。HBase的列式存储的特性支撑它实时随机读取、基于KEY的特殊访问需求。当然，HBase还有不少新特性，其中不乏有趣的特性，在接下来的内容中将会详细介绍。
　　1.2HBase是什么
　　HBase（Hadoop Database）是一个高可靠、高性能、面向列、可伸缩的分布式数据库，利用HBase技术可在廉价PC上搭建起大规模结构化存储集群。HBase参考Google的BigTable建模，使用类似GFS的HDFS作为底层文件存储系统，在其上可以运行MapReduce批量处理数据，使用ZooKeeper作为协同服务组件。
　　HBase的整个项目使用Java语言实现，它是Apache基金会的Hadoop项目的一部分，既是模仿Google BigTable的开源产品，同时又是Hadoop的衍生产品。而Hadoop作为批量离线计算系统已经得到了业界的普遍认可，并经过了工业上的验证，所以HBase具备“站在巨人肩膀之上”的优势，其发展势头非常迅猛。
　　HBase还是一种非关系型数据库，即NoSQL数据库。在Eric Brewer的CAP理论中，HBase属于CP类型的系统，其NoSQL的特性非常明显，这些特性也决定了其独特的应用场景。接下来的内容将详细讲解HBase的发展历史、发行版本和特性。
　　1.2.1HBase的发展历史
　　Apache HBase最初是Powerset公司为了处理自然语言搜索产生的海量数据而开展的项目，由Chad Walters和Jim Kellerman两人发起，经过两年的发展之后被Apache基金会收录为顶级项目，同时成为非常活跃、影响重大的项目。
　　2006年11月，Google开放了论文“Bigtable：A Distributed Storage System for Structured Data”，该论文就是HBase的原型。2007年2月，倡导者提出作为Hadoop的模块的HBase原型，该原型包含HBase的基本介绍、表设计、行键设计和底层数据存储结构设计等内容。
　　经过一段时间的酝酿和开发工作，在2007年10月第一个可用的、简单的HBase版本发布，该版本只实现了最基本的模块和功能，因为只是初始开发阶段，此时的HBase版本发展很不完善。2008年1月，Hadoop升级为顶级项目，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 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.*五个大的版本，现在稳定版本是0.94.*。
　　1.2.2HBase的发行版本
　　本节主要介绍现有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上找到相关的最新开发代码。所以，偶数发布版本属于稳定版本，奇数开发版本属于不稳定版本，一般不建议用户在生产环境中使用开发版本，这些也是大版本的发布规律。
　　小版本一般基于当前大版本的问题进行修正，一般表示小版本的数字在1～100之间，例如：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文件夹包含了最新的稳定发布版本；to_remove表示已经移除的版本；HEADER.html文件用于对代码发行版进行说明，即下面代码中的前半部分，从“HBase Releases...”开始，一直到“'fresh'.”结束的解释说明。每部分后面都有对应的发布时间，可以通过该时间判断版本发布的间隔和项目的活跃程度。
　　HBase Releases
　　Please make sure you're downloading from a nearby mirror site, not from 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.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协议结构；另外一个版本是常规版本，一般搭建不需要用户权限控制的集群可以使用这个版本，权限控制部分可以交由中间业务逻辑层控制。
　　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.*版本的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.tar.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及以上的版本，因为很多的新功能并没有经过工业界的验证。如果必须使用支持Hadoop 2.0的版本，建议使用0.96这个分支，因为这个分支已经迭代过不少小版本，相对稳定。另外，一直致力于Hadoop技术研发和推广、HBase核心贡献者、Hortonworks高级技术成员——Ted Yu对该版本的新功能、特性非常推崇，有些时候还是需要相信权威。
　　这里需要特别声明一下，本书的知识点讲解、安装部署、实战案例和性能调优等都是基于HBase 0.94版本的，该版本是写作本书时的最新稳定版。
　　1.2.3HBase的特性
　　HBase作为一个典型的NoSQL数据库，可以通过行键（Rowkey）检索数据，仅支持单行事务，主要用于存储非结构化和半结构化的松散数据。与Hadoop相同，HBase设计目标主要依靠横向扩展，通过不断增加廉价的商用服务器来增加计算和存储能力。
　　“典型”代表着HBase有不少特性，这些特性都标志着HBase的特立独行、与众不同，同时其良好的出身和特性也奠定了其在大数据处理领域的地位。下面介绍HBase具备的一些非常显著的特点。
　　1.?容量巨大
　　HBase的单表可以有百亿行、百万列，数据矩阵横向和纵向两个维度所支持的数据量级都非常具有弹性。传统的关系型数据库，如Oracle和MySQL等，如果数据记录在亿级别，查询和写入的性能都会呈指数级下降，所以更大的数据量级对传统数据库来讲是一种灾难。而HBase对于存储百亿、千亿甚至更多的数据都不存在任何问题。对于高维数据，百万量级的列没有任何问题。有的读者可能关心更加多的列：千万和亿级别，这种非常特殊的应用场景，并不是说HBase不支持，而是这种情况下访问单个Rowkey可能造成访问超时，如果限定某个列则不会出现这种问题。
　　2.?面向列
　　HBase是面向列的存储和权限控制，并支持列独立检索。有些读者可能不清楚什么是列式存储，下面进行简单介绍。列式存储不同于传统的关系型数据库，其数据在表中是按某列存储的，这样在查询只需要少数几个字段的时候，能大大减少读取的数据量，比如一个字段的数据聚集存储，那就更容易为这种聚集存储设计更好的压缩和解压算法。下面是传统行式数据库与列式数据库的不同特性。
　　传统行式数据库的特性如下：
　　数据是按行存储的。
　　没有索引的查询使用大量I/O。
　　建立索引和物化视图需要花费大量的时间和资源。
　　面对查询需求，数据库必须被大量膨胀才能满足需求。
　　列式数据库的特性如下：
　　数据按列存储，即每一列单独存放。
　　数据即索引。
　　只访问查询涉及的列，可以大量降低系统I/O。
　　每一列由一个线索来处理，即查询的并发处理性能高。
　　数据类型一致，数据特征相似，可以高效压缩。
　　列式存储不但解决了数据稀疏性问题，最大程度上节省存储开销，而且在查询发生时，仅检索查询涉及的列，能够大量降低磁盘I/O。这些特性也支撑HBase能够保证一定的读写性能。
　　3.?稀疏性
　　在大多数情况下，采用传统行式存储的数据往往是稀疏的，即存在大量为空（NULL）的列，而这些列都是占用存储空间的，这就造成存储空间的浪费。对于HBase来讲，为空的列并不占用存储空间，因此，表可以设计得非常稀疏。
　　4.?扩展性
　　HBase底层文件存储依赖HDFS，从“基因”上决定了其具备可扩展性。这种遗传的可扩展性就如同OOP中的继承，“父类”HDFS的扩展性遗传到HBase框架中。这是最底层的关键点。同时，HBase的Region和RegionServer的概念对应的数据可以分区，分区后数据可以位于不同的机器上，所以在HBase核心架构层面也具备可扩展性。HBase的扩展性是热扩展，在不停止现有服务的前提下，可以随时添加或者减少节点。
　　5.?高可靠性
　　HBase提供WAL和Replication机制。前者保证了数据写入时不会因集群异常而导致写入数据的丢失；后者保证了在集群出现严重问题时，数据不会发生丢失或者损坏。而且HBase底层使用HDFS，HDFS本身的副本机制很大程度上保证了HBase的高可靠性。同时，协调服务的ZooKeeper组件是经过工业验证的，具备高可用性和高可靠性。
　　6.?高性能
　　底层的LSM数据结构和Rowkey有序排列等架构上的独特设计，使得HBase具备非常高的写入性能。Region切分、主键索引和缓存机制使得HBase在海量数据下具备一定的随机读取性能，该性能针对Rowkey的查询能够达到毫秒级别。同时，HBase对于高并发的场景也具备很好的适应能力。该特性也是业界众多公司选取HBase作为存储数据库非常重要的一点。
　　1.3HBase与Hadoop的关系
　　HBase参考了Google的BigTable建模，且将下面三篇博文作为HBase实现的理论基础：
　　BigTable by Google（2006）
　　HBase and HDFS Locality by Lars George（2010）
　　No 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，而不是MapReduce这样的批量操作方式。图1-2展示了HBase在Hadoop生态系统中的位置。
　　图1-2Hadoop生态系统总图
　　因为HBase底层依赖Hadoop，所以选择Hadoop版本对HBase部署很关键。表1-1显示了不同HBase发行版本所支持的Hadoop版本信息。基于HBase版本，应该选择合适的Hadoop版本，表1-1中是官方给出的HBase和Hadoop的版本支持矩阵。
　　表1-1Hadoop版本支持矩阵
　　Hadoop版本 HBase 0.92.x HBase 0.94.x HBase 0.96.x HBase 0.98.x
　　Hadoop 0.20.205 S X X X
　　Hadoop 0.22.x S X X X
　　Hadoop 1.0.0-1.0.2 S S X X
　　Hadoop 1.0.3+ S S S X
　　Hadoop 1.1.x NT S S X
　　Hadoop 0.23.x X S NT X
　　Hadoop 2.0.x-alpha X NT X X
　　Hadoop 2.1.0-beta X NT S X
　　Hadoop 2.2.0 X NT S S
　　Hadoop 2.x X S S S
　　表1-1中字母的含义如下。
　　S：经过测试的、支持的。
　　X：不支持。
　　NT：可以运行但测试不充分。
　　当然，并不是说只要满足表1-1中的版本匹配就万事大吉了，在考虑版本匹配的同时，也需要考虑一些其他因素，例如：
　　如果使用0.94.x运行在Hadoop 2.2.0版本上，需要重新编译0.94.x。
　　对于ZooKeeper的版本只需要跟HBase依赖库中的ZooKeeper保持一致即可。
　　1.4HBase的核心功能模块
　　Hadoop框架包含两个核心组件：HDFS和MapReduce，其中HDFS是文件存储系统，负责数据存储；MapReduce是计算框架，负责数据计算。它们之间分工明确、低度耦合、相关关联。对于HBase数据库的核心组件，即核心功能模块共有4个，它们分别是：客户端Client、协调服务模块ZooKeeper、主节点HMaster和Region节点RegionServer，这些组件的描述和相互之间的关联关系如图1-3所示。
　　图1-3HBase架构图
　　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协调服务组件ZooKeeper
　　ZooKeeper Quorum（队列）负责管理HBase中多HMaster的选举、服务器之间状态同步等。再具体一些就是，HBase中ZooKeeper实例负责的协调工作有：存储HBase元数据信息、实时监控RegionServer、存储所有Region的寻址入口，当然还有最常见的功能就是保证HBase集群中只有一个HMaster节点。
　　1.4.3主节点HMaster
　　HMaster没有单点问题，在HBase中可以启动多个HMaster，通过ZooKeeper的Master选举机制保证总有一个Master正常运行并提供服务，其他HMaster作为备选时刻准备（当目前HMaster出现问题时）提供服务。HMaster主要负责Table和Region的管理工作：
　　管理用户对Table的增、删、改、查操作。
　　管理RegionServer的负载均衡，调整Region分布。
　　在Region分裂后，负责新Region的分配。
　　在RegionServer死机后，负责失效RegionServer上的Region迁移。
　　1.4.4Region节点HRegionServer
　　HRegionServer主要负责响应用户I/O请求，向HDFS文件系统中读写数据，是HBase中最核心的模块。HRegionServer内部管理了一系列HRegion对象，每个HRegion对应了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满了以后会缓冲（flush）成一个StoreFile（底层实现是HFile），当StoreFile文件数量增长到一定阈值，会触发Compact操作，将多个StoreFiles合并成一个StoreFile，在合并过程中会进行版本合并和数据删除，因此可以看出HBase其实只有增加数据，所有的更新和删除操作都是在后续的Compact过程中进行的，这使得用户的写操作只要进入内存中就可以立即返回，保证了HBase I/O的高性能。
　　图1-4HRegionServer的组成结构
　　StoreFiles在触发Compact操作后，会逐步形成越来越大的StoreFile，当单个StoreFile大小超过一定阈值后，会触发Split操作，同时把当前Region分裂成2个Region，父Region会下线，新分裂的2个子Region会被HMaster分配到相应的HRegionServer上，使得原先1个Region的压力得以分流到2个Region上。
　　每个HRegionServer中都有一个HLog对象，HLog是一个实现Write Ahead Log的类，在每次用户操作写入MemStore的同时，也会写一份数据到HLog文件中，HLog文件定期会滚动出新，并删除旧的文件（已持久化到StoreFile中的数据）。在HRegionServer意外终止后，HMaster会通过ZooKeeper感知到，首先处理遗留的HLog文件，将其中不同Region的Log数据进行拆分，分别放到相应Region的目录下，然后再将失效的Region重新分配，领取到这些Region的HRegionServer在加载Region的过程中，会发现有历史HLog需要处理，因此会将HLog中的数据回放到MemStore中，然后缓冲（flush）到StoreFiles，完成数据恢复。
　　1.5HBase的使用场景和经典案例
　　了解软件产品的最好方法是如何使用，解决什么问题以及如何适用于大型应用架构。接下来的内容将详细介绍一些业界成功使用HBase的场景。但是，不要认为HBase只能解决下面的这些使用场景，因为它是一个正在发展和完善的技术框架，根据使用场景进行的创新正驱动着系统的发展。
　　下面是对HBase适用场景的一些抽象概括，从需求角度进行抽象，涵盖存储量级、性能、扩展、数据格式和关联关系等方面。
　　存储大量的数据（PB级数据）且能保证良好的随机访问性能。
　　需要很高的写吞吐量，瞬间写入量很大，传统数据库不能支撑或需要很高成本支撑的场景。
　　可以进行优雅的数据扩展，动态扩展整个存储系统容量。
　　数据格式无限制，支持半结构化和非结构化的数据。
　　业务场景简单，不需要全部的关系型数据库特性，例如交叉列、交叉表，事务、连接等。
　　愿意使用HBase的用户数量在过去几年里迅猛增长，部分原因在于HBase产品变得更加可靠，性能变得更好，主要原因在于越来越多的公司开始投入大量资源来支持和使用它。随着越来越多的商业服务供应商提供支持，用户越发自信地把HBase应用于关键应用系统。一个设计初衷是存储互联网持续更新网页副本的技术，用在互联网相关的其他方面也很合适。下面涉及通过实际案例来介绍HBase最适合的应用场景。
　　1.5.1搜索引擎应用
　　搜索是定位用户感兴趣信息的行为：例如，搜索“大话西游”，用户可能非常想观看这部电影，或者想了解这部电影的信息。搜索含有特定词语的文档，需要查找索引，该索引提供了特定词语和包含该词语的所有文档的映射。为了能够搜索，首先必须建立索引。Google、百度以及其他搜索引擎都是这么做的。它们的文档库是互联网的Web页面。
　　HBase为这种文档库提供存储、行级访问。网络爬虫可以基于HBase非常方便地插入和更新单个文档。同时搜索索引可以基于HBase通过MapReduce计算高效生成。如果访问单个文档，可以直接从HBase取出（即随机读取），并且HBase支持多种访问模式。
　　HBase应用于网络搜索的整个逻辑过程如下：
　　1）爬虫持续不断地抓取新页面存储到HBase中；
　　2）在整张表上使用MapReduce计算并生成索引，供网络搜索应用使用；
　　3）用户发起网络搜索请求；
　　4）网络搜索应用查询建立好的索引，或者直接从HBase得到单个文档；
　　5）搜索结果提交给用户。
　　1.5.2增量数据存储
　　在大多数情况下，数据通常是慢慢累加到已有数据库以备将来使用，例如分析、处理和服务。许多HBase使用场景属于这个类别——使用HBase作为数据存储，存储来自各种数据源的增量数据。这种数据源可能是网页爬虫，可能是记录用户看了什么广告和看多长时间的广告效果数据，也可能是记录各种参数的时间序列数据。下面介绍一些有关该使用场景的成功案例。
　　1.?增量监控数据：OpenTSDB系统
　　如果一款Web产品的注册用户达到千万，则后台的基础架构需要数百台以上的服务器，用于承担服务流量、日志收集、数据存储和数据处理等操作。为了保持产品正常运行，监控服务器和其中运行软件的健康状态至关重要。大规模监控整个环境需要能够采集和存储来自不同数据源的各种参数的监控系统。一些公司使用商业工具来收集和展示参数，而其他一些公司采用开源框架。
　　StumbleUpon开源了OpenTSDB框架，其含义是开放时间序列数据库（Open Time Series Database），用来收集服务器的各种监控参数。该框架使用HBase作为核心平台来存储和检索所收集的参数。创建这个框架的目的是为了拥有一个可扩展的监控数据收集系统，一方面能够存储和检索参数数据并保存很长时间，另一方面如果需要增加功能也可以随时添加各种新参数。
　　2.?增量用户交互数据：Facebook Like按钮
　　用过Facebook的读者，应该记得其特有的Like按钮，该按钮已经成为Facebook的标志之一，每次用户喜欢一个特定主题时，计数器就增加一次。这里的计数器是一个整数类型的变量，每次触发喜欢操作就加1。这就是另外一种增量数据——用户交互数据。
　　Facebook使用HBase的计数器来计量用户喜欢特定网页的次数，内容原创人和页面所有者可以得到近乎实时的多少用户喜欢他们网页的数据信息。他们可以因此更敏捷地判断应该提供什么内容。Facebook为此创建了一个叫Facebook Insight的系统，该系统需要一个可扩展的存储系统。在技术选型的时候考虑了很多种可能，包括关系型数据库、内存数据库和Cassandra数据库，最后决定使用HBase。基于HBase，Facebook可以很方便地横向扩展服务规模，提供给数百万用户，也可以继续使用他们已有的运行大规模HBase集群的经验。该系统每天处理数百亿条事件，记录数百个参数。
　　3.?增量遥测数据：Firefox浏览器
　　软件运行和质量数据，不会像监控参数数据那么简单。例如，软件崩溃报告是有用的软件运行数据，经常用来探究软件质量和规划软件开发路线图。HBase可以成功地收集和存储用户计算机上生成的软件崩溃报告。这种使用场景与前两种使用场景不同，不一定与网络服务应用有关系。
　　Mozilla最出色的软件就是Firefox浏览器，该软件安装在全球数千万量级的个人计算机上，支持各种操作系统。当浏览器出现异常或者崩溃时，会以Bug报告的形式返回给Mozilla后台服务器。Mozilla后台使用Socorro系统收集这些报告，该系统的数据存储和分析建构在HBase上，分析结果用于向研发部门提供建议和决策支持。采用HBase可以存储更多的数据，使得分析结果更加准确，可以在更大程度上帮助和指导开发人员。
　　4.?增量广告点击数据：电商、广告监控行业
　　现今，在线广告已经成为互联网产品的一个主要收入来源。绝大部分的互联网产品提供免费服务给用户，在用户使用服务时投放广告给目标用户。这种精准投放需要针对用户交互数据做详细的采集和分析，以便理解用户的特征。精细的用户交互数据带来更好的模型，进而导致更好的广告投放效果和更多的收入。但这类数据有两个特点：以连续流的形式出现、很容易按用户划分。在理想情况下，这种数据一旦产生就能够马上使用，用户特征模型可以没有延迟地持续优化。
　　国内的电商和广告监控等非常前沿、活跃的互联网公司已经在熟练地使用类似Hadoop和HBase这样的新技术，例如淘宝的实时个性化推荐服务，中间推荐结果的存储使用HBase，并且广告相关的用户建模数据也存储在HBase中。广告监控行业中的AdMaster、缔元信等公司的实时广告数据监控和部分报表业务已经在使用HBase。
　　1.5.3用户内容服务
　　传统数据库的一个最大使用场合是为用户提供内容服务。各种各样的数据库支撑着提供各种内容服务的应用系统。多年来，这些应用在发展，它们所依赖的数据库也在发展。用户希望使用和交互的内容种类越来越多。
　　1.?内容推荐引擎系统：搜狐
　　搜狐推荐引擎系统接入几亿用户的行为日志，每日资讯量在百万级，每秒约有几万条左右的用户日志被实时处理入库。在这种数据量上，要求推荐请求和相关新闻请求每秒支持的访问次数在万次以上，推荐请求的响应延时控制在70ms以内，同时系统要求10s左右完成从日志到用户模型的修正过程。
　　这些性能需求指标是整个系统的难点，需要维护几亿用户200GB的短期属性信息，同时依靠这些随用户行为实时变化的属性信息来更新用户感兴趣的文章主题，还要实时计算用户所属的兴趣小组，完成由短期兴趣主导的内容推荐和用户组协同推荐。记录用户浏览历史、周期性计算热门文章等都是在HBase上完成的，由此可见HBase在高性能上的优势。
　　2.?用户模型服务：电商行业
　　经过HBase处理过的内容往往并不直接提交给用户使用，而是用来丰富与用户的交互，具体是决定应该提交给用户什么内容。用户模型可以存储在HBase，用户模型多种多样，可以用于多种不同场景，例如，针对特定用户投放什么广告，用户在电商门户网站购物时是否实时报价，用户在搜索引擎检索时增加背景信息和关联内容，等等。当用户在电商网站上发生交易时，用户模型服务可以用来实时报价。这种模型需要基于不断产生的新用户数据来持续优化。
　　1.5.4实时消息系统构建
　　Facebook全新的Social Inbox产品，集成了E-mail、IM、短信、文本信息、在线消息。最为重要的是，该产品每个月要存储超过1350亿条消息。Facebook的Kannan Muthukkaruppan在《邮件的底层技术：HBase》一文中给了一个十分意外的答案——HBase打败了MySQL、Cassandra和其他一些技术，成为Facebook的选择。为什么说是一个意外的答案？Cassandra是Facebook创造的，并且它就是为邮件类型的应用而打造的，但是Facebook发现Cassandra的最终一致性模型并不适合其全新的实时邮件产品。Facebook同样拥有大量的MySQL架构，但是在使用过程中发现MySQL性能会随着数据和索引的增加变差。所以，Facebook同样可以选择自己来开发一个新的存储模型，但是最终选择了HBase。
　　Facebook检视了自己的应用场景，指出为什么要选择HBase。Facebook所需要的系统应该能处理以下两种数据：
　　一个较小的临时数据集，是经常变化的；
　　一个不断增加的数据集，是很少被访问的。
　　显然HBase就能搞定这一切。Facebook在Hadoop、Hive上积累了丰富的经验，并且成为HBase的“大客户”，基于这点，我们也有充足理由相信它能变得更加流行。
　　1.6本章小结
　　本章主要介绍了HBase上下文相关的知识，包括大数据背景、HBase的发展历史、发行版本、特性、核心功能模块以及使用场景和经典案例等知识点，并且详细介绍了HBase是什么和HBase能做什么两个要点，方便读者快速理解和掌握HBase框架。
　　任何一种框架或者软件都有其特定的应用场景，类似“万金油”的框架是10年前大家追求的设计理念，所以HBase有其特定的使用场景。通过本章学习，初学者可以迅速掌握HBase能用来做什么，不能用来做什么，最大程度上缩短读者的学习和使用成本。
　　第2章 Chapter 2
　　HBase安装与配置
　　本章将讲述如何安装、部署、启动和停止HBase集群，以及如何通过命令行的方式对HBase进行基本操作，例如：插入、查询、删除数据。
　　在安装HBase之前强烈建议各位读者仔细阅读2.1节，确定这些基本需求都已经满足，否则可能遇到各种棘手的问题，比如查询不到数据甚至丢失数据。配置HBase的方式与Hadoop类似，都是通过修改安装包的conf目录下的配置文件完成的。在对一台机器修改配置文件后要记得同步到集群中所有节点，此时可以使用scp或rsync命令，在大多数情况下，需要重新启动HBase使配置生效。