1、分布 式数据库 HBase 1 内容 HBase的历史和特点 HBase和其他 Hadoop成员的关系 HBase的数据模型 HBase的访问接口 HBase的运行组成 HBase Region HBase的读写 其他 HBase功能 2 为何需要构建分布式数据库 从数据类型来说，在网络上存在大量的结构化与半结构化数据，如果仅仅使用分布式文件系统的方式就会丢失大量结构信息 URL数据，针对每一个网页有：网页内容，元数据，链接信息，链接描述数据， PageRank的值 对于每个用户的数据来说，有用户自己特定的设定，最近的查询历史等 对于网络应用程序来说，例如购物网站的商品信息以及用户信息；卫星数
2、据的一些标志数据等 数据规模十分庞大 对于网页来说，显然整个互联网的数据无法估量 用户数目也极其庞大，造成用户数据也十分庞大 对于网络应用程序来说，只要服务于整个互联网的，造成的数据规模也十分庞大 3 传统的数据库管理系统是否能够完成工作 对于绝大多数商业数据库来说，云条件下的数据都过于庞大 关系模型对数据的操作使数据的存贮变得复杂。传统数据库的强一致性的要求，往往在处理互联网规模的数据的时候显得无法胜任 即使 不考虑 数据规模，对于任何应用来说，使用如此大规模的商业数据库都会造成花费极多（想象一下昂贵的商用数据库） 可以 对传统的数据库进行改良，但是改良的关系数据库（副本、分区等）难于安装与
3、维护 因此， Google启动了 BigTable项目，用以处理Google内部的大规模的结构化以及半结构化数据 4 关系数据库的理论局限性 RDBMS选择了 ACID 超强的一致性（ transaction）牺牲了水平可扩展性 Scale up, not out 并行数据库 的扩展性 经验定律：当集群节点数每增加 416台 , 每个节点的效率下降一半 无法扩展超过 40节点 最新的 TPC-C世界纪录 : 27 servers 最新的 TPC-H世界纪录 : 32 servers “One size does not fit all” 在所有数据库的主要应用领域，新的架构轻易得有 10x倍性
4、能提升 (数据仓库 , 流处理 ,科学计算 , 非结构化数据处理，OLTP在线事务处理 )* * ACM SIGACT News, Volume 33 Issue 2 (2002): “Brewers conjecture and the feasibility of consistent, available, partition-tolerant web services” * ICDE 2005: “One Size Fits All”: An Idea Whose Time Has Come and Gone * VLDB 2007: The End of an Architectur
5、al Era (Its Time for a Complete Rewrite) 5 CAP One size does not fit all* CAP 一致性 (Consistency) 客 户端知道一系列的操作都会同时发生 (生效 ) 可用性 (Availability) 每 个操作都必须以可预期的响应结束 . 分区容错性 (Partition tolerance) 即 使出现单个组件无法可用 ,操作依然可以完成 . 6 RDBMS的实现局限性 RDBMS实现和操作上的局限性 不适合新的应用 大表 - 在一张表中存储 500GB的数据 ? 灵活动态可变的表结构 - 为大表修改表结构 (A
6、lter Table )？ 无停机时间的在线大表分区和动态扩容 - SQL limitation query on 0.5TB data 关系数据库 vs. Hadoop/Hive Intel silicon design environment usage analysis, 40M records/day 7 HBase的历史与简介 2006年 Google发表了 BigTable论文 2006年底由 PowerSet 的 Chad Walters和 Jim Kellerman 发 起了HBase项目，依据 BigTable的论文重构关系数据库 2007年 2月建立了 HBase的原型版本
7、 2007年 10月建立了第一个可用的 HBase版本 2008年成为 Apache Hadoop的一个子项目 HBase是 Google Bigtable的开源实 现 。 Bigtable利用 GFS作为其文件存储系 统； HBase使用 HDFS作为其文件存储系 统。 Google Bigtable利用 Chubby作 为 一 个可靠服务的根， Chubby提供了BigTable中的根元数据表的指针以及用以监控所有数据分表服务；在 HBase中，对应的系统服务为ZooKeeper 8 9 HBase的特性 Hadoop database and NoSQL database 基本的数据库操
8、作 CRUD 强一致性 无 SQL语言支持 稀疏的多维映射表 列存储 只用 row key来定位行 每行可以有不同的列 数据有多个版本（在不同的时间点的快照信息） 非常高的数据读写速度，为写特别优化 高效的随机读取 对于数据的某一个子集能够进行有效地扫描 HBase特性纵览 (2) 分布式的多层次映射表结构（ key-value形式， value有多个） 固定一个数据模型（固定数据模型能得到高性能，同时满足应用需求） 无数据类型 具有容错特性，能够将数据持久化的非易失性存储 中 使用 HDFS做底层存储，可利用 Hadoop的压缩 Codec等减少空间占用 自 动水平 扩展 只 需要加入新 的
9、结 点即 可 提 高存储容量和吞吐量 服 务器能够被动态加入或者删除（用以维护和升级 ） 服 务器自动调整负载平 衡 10 事务的 ACID 原子 性 (Atomicity) 事务 要么全 部完成，要 么全部不完成 一致性 (Consistency) 在 事务 执行过程中以及前后，数 据库的完整性约 束没有被破坏 隔 离 性 (Isolation) 事务的执行是互不干扰的 ，不能 看到其他事务运行 时中间状态的 数 据 持 久 性 (Durability) 成 功完成的 事务 所 对数据库所作的更改便持久的保存在数据库之中，并不会被回 滚 可见性 (Visibility) 事务对数据的更改对任
10、何后续的读操作可见 11 HBase的原子性保证 HBase仅保证对行操作的原子性 任何行级的操作是原子的 一条记录的 Put操 作要么完全成功，要么完全失败。 操作 返回 成功 (success)表示操作完成 操作返回失败 (failure)表示操作全部失败 超时操作可能是成功也可能失败，但不可能部分成功 即使跨 column family的行操作也是原子的 支持一次性修改多行的 API并不保证跨行的原子性操作 一般情况下， API会在结果中分别返回执行成功、失败以及超时的行操作列表 checkAndPut()方法是原子性的 相当于 典 型的 compareAndSet (CAS)语义 对行
11、的修改顺序被严格定义，不可能出现修改交织 比如，一个用户发出修改 “a=1,b=1,c=1” ，而另一个用户发出修改 “a=2,b=2,c=2”, 这行的值要么为 “a=1,b=1,c=1” ，要么为 “a=2,b=2,c=2” ，而不可能是 “a=1,b=2,c=1“. 如果是跨行的批量修改不保证所有行之间不出现交织 12 HBase的一致性以及可见性 任意 API返回的 任 意多的行都曾经完整的在表历史上的某个时间点上出现过 即使跨 column family也成立 如果试图取一行完整的记录，该纪录同时依次在进行 1,2,3,4,5更改操作，则返回的必定是在1和 5之间某个时间里出现过的一
12、条完整的记录 行的状态是按时间单调递增的 (日志 ) Scan不 能返回一个恒定的表视图，及 Scan不 是快照隔离的 (snapshot isolation) 13 内容 HBase的历史和特点 HBase和其他 Hadoop成员的关系 HBase的数据模型 HBase的访问接口 HBase的运行组成 HBase Region HBase的读写 其他 HBase功能 14 HBase运行环境 HBase与集群中其它系统之间的关系： HDFS：分布式文件系统，用以存储数据，将数据持久化 Zookeeper：分布式的协调服务器，用以提供高可靠的锁服务，提供可靠的小文件的读写；HBase使用 Zo
13、okeeper服务来进行节点管理以及表数据的定位 MapReduce：分布式环境下的一个编程框架；可以把 HBase作为数据源和目的 15 ZooKeeper简介 ZooKeeper是一个为分布式应用程序进行协调的服务，这样的话，每一个分布式的应用程序如果需要进行协调的话就可以直接使用 ZooKeeper所提供的服务 ZooKeeper提供了一系列分布式系统的基本服务或者可以基于 ZooKeeper完成分布式系统的基本服务：同步、配置管理、分组和命名 ZooKeeper提供了一个易于编程的环境，实现了一个简化的文件系统，提供类似的目录树结构 ZooKeeper使用 Java编写，支持了 Jav
14、a以及 C语言绑定 分布 式的协调服务 coordination非常容易出错，出错 之后也很难恢复，例如死锁状态，或者出现资源竞争状态，通过 ZooKeeper可以以良好的编程接口将程序员从自己构造协调服务的负担中解放出来 16 ZNode ZooKeeper文件树 中的节点称作 znode。 znode会维护一个包含数据修改和 ACL修改版本号的 Stat结构体，这个结构体还包含时间戳字段 。 版 本号和时间戳让 ZooKeeper可以校验缓存，协调更新。每次修改 znode数据的时候，版本号会增加 。 客 户端获取数据的同时，也会取得数据的版本号 。 执 行更新或者删除操作时，客户端必须提
15、供版本号 。 如 果提供的版本号与数据的实际版本不匹配，则更新操作失败。 17 临时节点 ZooKeeper有临时节点的概 念 临 时节点在创建它的会话活动期间存 在 会 话终止的时候，临时节点被删除，所以临时节点不能有子节 点 18 Znode上的观察器 客户端可以在 znode上设 置观察器。 对znode的修改将触 发观察器， 然后移 除观察器。观察器被 触发时， ZooKeeper向客户端发送一个通知 。 观察器用来让应用程序可以得到异步的通知 19 Zookeeper数据存取 存储在名字空间中每个 znode节点里的数据是原子地读取和写入的。读取操作获取节点的所有数据，写入操作替换所
16、有数据 。 节 点的访问控制列表 (ACL)控制可以进行操作的用户 。 ZooKeeper不用以真正存储数据，而是保存协调数据。 协 调数 据 例如 配 置、状态信 息等，通 常比较小，以千字节来衡量 。 znode数 据应该小 于 1MB，实 际数 据一般远 小于 1MB。 较 大的数据不适合使用 ZooKeeper存储，如 果需要大数据存储，通常方式是存储到块存储系统，如 NFS或者HDFS中，然后在 ZooKeeper中保存到存储位置的指针。 20 内容 HBase的历史和特点 HBase和其他 Hadoop成员的关系 HBase的数据模型 HBase的访问接 口 HBase的运行组 成
17、 HBase Region HBase的读写 其他 HBase功能 21 HBase中的数据模型 行主键 列族 row Key column-family1 column-family2 column-family3 column1 column2 column1 column2 column3 column1 key1 t1:abc t2:gdxdf t4:dfads t3:hello t2:world key2 t3:abc t1:gdxdf t4:dfads t3:hello t2:dfdsfa t3:dfdf key3 t2:dfadfasd t1:dfdasddsf t2:dfxxd
18、fasd t1: 时 间戳 HBase表不要求是结构化的。本质上， HBase表可认为是一个巨大的稀疏 矩阵 。 22 行主键 (Rowkey) 行主键是用来检索记录的主键 行主键是最大长度 64KB的数组，实际应用中长度一般为 10-100bytes 访问 HBase table中的行，有三种方式： 通过单个 row key访问 通过 row key的范围（ range）来访问 全表扫描 存储时，数据按照 Row key的字典序 (byte order)排序存储 设计 key时，要充分排序存储这个特性，将经常一起读取的行存储放到一起。 (空间局部性 ) 字典序对 int排序的结果是1,10,
19、100,11,12,13,14,15,16,17,18,19,2,20,21,9,91,92,93,94,95,96,97,98,99。要保持整形的自然序，行键必须用 0作左填充。 行的一次读写是原子操作 (不论一次读写多少列 ) 23 列族 列族的设计与传统数据库中的列不一致 HBase表中的每个列，都归属与某个列族。列族是表 的 schema的一部 分， 必须在使用表之前定义。列名都以列族作为前缀。例如 courses:history， courses:math 都属于courses 这个列族。 访问控制、磁盘和内存的使用统计都是在列族层面进行的 。 24 时 间戳 timestamp H
20、Base中通过 row和 column确定一 个存贮单 元 cell 每 个 cell都保存着同一份数据的多个版本。版本通过时间 戳 (64位整型 )来 索 引 时 间戳可以 由 HBase(在数据写入时自 动用当前系统时间 )赋 值 时 间戳也可以由客户显式赋值。如果应用程序要避免数据版本冲突，就必须自己生成具有唯一性的时间戳。每 个 cell中，不同版本的数据按照时间倒序排序，即最新的数据排在最前面。 为了避免数据存在过多版本造成的的管理 (包括存贮和索引 )负担 ， HBase提供了两种数据版本回收方 式 保 存数据的最后 n个版 本 保 存最近一段时间内的版本（比如最近七天）。用户可以
21、针对每个列族进行设 置 TTL （ Time to Live) 25 数据单元的映射关系 每行每列族中的列数量是可以不同的，数量可以很大 简单来说，可以认为每行每列族中保存的是一个Map 由 row key, column family, column name, timestamp 可以唯一的确定一个单元。单元中的数据是没有类型的，全部是字节码形式存贮 实际存储时，也是这个 key-value结构 表设计时要避免由此引起更多的负担 26 内容 HBase的历史和特点 HBase和其他 Hadoop成员的关系 HBase的数据模型 HBase的访问接 口 HBase的运行组 成 HBase R
22、egion HBase的读写 其他 HBase功能 27 HBase的访问接口 Java API 最 常规和高效的访问方 式 HBase Shell HBase的命令行工具，最简单的接口，适合 HBase管理使用 Thrift Gateway 利用 Thrift序列化技术，支持 C+， PHP， Python等多种语言，适合其他异构系统在线访问 HBase表数据 REST Gateway 支持 REST 风格的 Http API访问 HBase, 和 thrift类似 MapReduce/Pig/Hive 使用 TableInputFormat和 TableOutputFormat来支持 HBase作为 MapReduce的输入和输出 28 HBase的客户端基本操作 写 入， 没有 transaction，但对单行的更新是原子 的 Put Delete Append Increment 读取 Get Scan 29 内容 HBase的历史和特点 HBase和其他 Hadoop成员的关系 HBase的数据模型 HBase的访问接 口 HBase的运行组成 HBase Region HBase的读写 其他 HBase功能 30
