一、 Nosql
Nosql(Nosql = Not Only sql ) ，意即反 sql 运动，是一项全新的数据库革命性运动，早期就有人提出，发展至 2009 年趋势越发高涨。 Nosql 的拥护者们提倡运用非关系型的数据存储，相对于目前铺天盖地的关系型数据库运用，这一概念无疑是一种全新的思维的注入。
现今的计算机体系结构在数据存储方面要求具备庞大的水平扩展性①，而 Nosql 致力于改变这一现状。目前 Google 的 BigTable 和 Amazon 的 Dynamo 使用的就是 Nosql 型数据库。 Nosql 项目的名字上看不出什么相同之处，但是，它们通常在某些方面相同：它们可以处理超大量的数据。 这场革命目前仍然需要等待。的确， Nosql 对大型企业来说还不是主流，但是，一两年之后很可能就会变个样子。在 Nosql 运动的最新一次聚会中，来自世界各地的 150 人挤满了 CBS Interactive 的一间会议室。分享他们如何推翻缓慢而昂贵的关系数据库的暴政，怎样使用更有效和更便宜的方法来管理数据。 “ 关系型数据库给你强加了太多东西。它们要你强行修改对象数据，以满足 RDBMS （ relational database management system ，关系型数据库管理系统）的需要， ” 在 Nosql 拥护者们看来，基于 Nosql 的替代方案 “ 只是给你所需要的 ” 。
随着互联网 web2.0 网站的兴起，非关系型的数据库现在成了一个极其热门的新领域，非关系数据库产品的发展非常迅速。而传统的关系数据库在应付 web2.0 网站，特别是超大规模和高并发的 SNS 类型的 web2.0 纯动态网站已经显得力不从心，暴露了很多难以克服的问题，例如： 1 、 High performance - 对数据库高并发读写的需求 web2.0 网站要根据用户个性化信息来实时生成动态页面和提供动态信息，所以基本上无法使用动态页面静态化技术，因此数据库并发负载非常高，往往要达到每秒上万次读写请求。关系数据库应付上万次 sql 查询还勉强顶得住，但是应付上万次 sql 写数据请求，硬盘 IO 就已经无法承受了。其实对于普通的 BBS 网站，往往也存在对高并发写请求的需求。 2 、 Huge Storage - 对海量数据的高效率存储和访问的需求 对于大型的 SNS 网站，每天用户产生海量的用户动态，以国外的 FriendFeed 为例，一个月就达到了 2.5 亿条用户动态，对于关系数据库来说，在一张 2.5 亿条记录的表里面进行 sql 查询，效率是极其低下乃至不可忍受的。再例如大型 web 网站的用户登录系统，例如腾讯，盛大，动辄数以亿计的帐号，关系数据库也很难应付。 3 、 High Scalability && High Availability- 对数据库的高可扩展性和高可用性的需求 在基于 web 的架构当中，数据库是最难进行横向扩展的，当一个应用系统的用户量和访问量与日俱增的时候，你的数据库却没有办法像 web server 和 app server 那样简单的通过添加更多的硬件和服务节点来扩展性能和负载能力。对于很多需要提供 24 小时不间断服务的网站来说，对数据库系统进行升级和扩展是非常痛苦的事情，往往需要停机维护和数据迁移，为什么数据库不能通过不断的添加服务器节点来实现扩展呢？ 在上面提到的 “ 三高 ” 需求面前，关系数据库遇到了难以克服的障碍，而对于 web2.0 网站来说，关系数据库的很多主要特性却往往无用武之地，例如： 1 、数据库事务一致性需求 很多 web 实时系统并不要求严格的数据库事务，对读一致性的要求很低，有些场合对写一致性要求也不高。因此数据库事务管理成了数据库高负载下一个沉重的负担。 2 、数据库的写实时性和读实时性需求 对关系数据库来说，插入一条数据之后立刻查询，是肯定可以读出来这条数据的，但是对于很多 web 应用来说，并不要求这么高的实时性。 3 、对复杂的 sql 查询，特别是多表关联查询的需求 任何大数据量的 web 系统，都非常忌讳多个大表的关联查询，以及复杂的数据分析类型的复杂 sql 报表查询，特别是 SNS 类型的网站，从需求以及产品设计角度，就避免了这种情况的产生。往往更多的只是单表的主键查询，以及单表的简单条件分页查询， sql 的功能被极大的弱化了。 因此，关系数据库在这些越来越多的应用场景下显得不那么合适了，为了解决这类问题的非关系数据库应运而生。 Nosql 是非关系型数据存储的广义定义。它打破了长久以来关系型数据库与 ACID 理论大一统的局面。 Nosql 数据存储不需要固定的表结构，通常也不存在连接操作。在大数据存取上具备关系型数据库无法比拟的性能优势。该术语在 2009 年初得到了广泛认同。 当今的应用体系结构需要数据存储在横向伸缩性上能够满足需求。而 Nosql 存储就是为了实现这个需求。 Google 的 BigTable 与 Amazon 的 Dynamo 是非常成功的商业 Nosql 实现。一些开源的 Nosql 体系，如 Facebook 的 Cassandra ， Apache 的 HBase ，也得到了广泛认同。从这些 Nosql 项目的名字上看不出什么相同之处： Hadoop 、 Voldemort 、 Dynomite ，还有其它很多。
关系型数据库中的表都是存储一些格式化的数据结构，每个元组字段的组成都一样，即使不是每个元组都需要所有的字段，但数据库会为每个元组分配所有的字段，这样的结构可以便于表与表之间进行连接等操作，但从另一个角度来说它也是关系型数据库性能瓶颈的一个因素。而非关系型数据库以键值对存储，它的结构不固定，每一个元组可以有不一样的字段，每个元组可以根据需要增加一些自己的键值对，这样就不会局限于固定的结构，可以减少一些时间和空间的开销。
qps : query per second
二、 HBase
HBase 简介
HBase – Hadoop Database ，是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统，利用 HBase 技术可在廉价 PC Server 上搭建起大规模结构化存储集群。
HBase 是 Google Bigtable 的开源实现 ，类似 Google Bigtable 利用 GFS 作为其文件存储系统， HBase 利用 Hadoop HDFS 作为其文件存储系统； Google 运行 MapReduce 来处理 Bigtable 中的海量数据， HBase 同样利用 Hadoop MapReduce 来处理 HBase 中的海量数据 ； Google Bigtable 利用 Chubby 作为协同服务， HBase 利用 Zookeeper 作为对应 。
上图描述了 Hadoop EcoSystem 中的各层系统，其中 HBase 位于结构化存储层， Hadoop HDFS 为 HBase 提供了高可靠性的底层存储支持， Hadoop MapReduce 为 HBase 提供了高性能的计算能力， Zookeeper 为 HBase 提供了稳定服务和 failover 机制。
此外， Pig 和 Hive 还为 HBase 提供了高层语言支持 ，使得在 HBase 上进行数据统计处理变的非常简单。 Sqoop 则为 HBase 提供了方便的 RDBMS 数据导入功能 ，使得传统数据库数据向 HBase 中迁移变的非常方便。
HBase 访问接口
1. Native Java API ，最常规和高效的访问方式，适合 Hadoop MapReduce Job 并行批处理 HBase 表数据
2. HBase Shell ， HBase 的命令行工具，最简单的接口，适合 HBase 管理使用
3. Thrift Gateway ，利用 Thrift 序列化技术，支持 C++ ， PHP ， Python 等多种语言，适合其他异构系统在线访问 HBase 表数据
4. REST Gateway ，支持 REST 风格的 Http API 访问 HBase,解除了语言限制
5. Pig ，可以使用 Pig Latin 流式编程语言来操作 HBase 中的数据，和 Hive 类似，本质最终也是编译成 MapReduce Job 来处理 HBase 表数据，适合做数据统计
6. Hive ，当前 Hive 的 Release 版本尚没有加入对 HBase 的支持，但在下一个版本 Hive 0.7.0 中将会支持 HBase ，可以使用类似 sql 语言来访问 HBase
HBase 数据模型
Table & Column Family
Ø Row Key: 行键， Table 的主键， Table 中的记录按照 Row Key 排序
Ø Timestamp: 时间戳，每次数据操作对应的时间戳，可以看作是数据的 version number
Ø Column Family ：列簇， Table 在水平方向有一个或者多个 Column Family 组成，一个 Column Family 中可以由任意多个 Column 组成，即 Column Family 支持动态扩展，无需预先定义 Column 的数量以及类型，所有 Column 均以二进制格式存储，用户需要自行进行类型转换。
Table & Region
当 Table 随着记录数不断增加而变大后，会逐渐分裂成多份 splits ，成为 regions ，一个 region 由 [startkey,endkey) 表示，不同的 region 会被 Master 分配给相应的 RegionServer 进行管理：
-ROOT- && .Meta. Table
HBase 中有两张特殊的 Table ， -ROOT- 和 .Meta.
Ø .Meta. ：记录了用户表的 Region 信息， .Meta. 可以有多个 regoin
Ø -ROOT- ：记录了 .Meta. 表的 Region 信息， -ROOT- 只有一个 region
Ø Zookeeper 中记录了 -ROOT- 表的 location
Client 访问用户数据之前需要首先访问 zookeeper ，然后访问 -ROOT- 表，接着访问 .Meta. 表，最后才能找到用户数据的位置去访问，中间需要多次网络操作，不过 client 端会做 cache 缓存。
MapReduce on HBase
在 HBase 系统上运行批处理运算，最方便和实用的模型依然是 MapReduce ，如下图：
HBase Table 和 Region 的关系，比较类似 HDFS File 和 Block 的关系， HBase 提供了配套的 TableInputFormat 和 TableOutputFormat API ，可以方便的将 HBase Table 作为 Hadoop MapReduce 的 Source 和 Sink ，对于 MapReduce Job 应用开发人员来说，基本不需要关注 HBase 系统自身的细节。
HBase 系统架构
Client
HBase Client 使用 HBase 的 RPC 机制与 HMaster 和 HRegionServer 进行通信，对于管理类操作， Client 与 HMaster 进行 RPC ；对于数据读写类操作， Client 与 HRegionServer 进行 RPC
Zookeeper
Zookeeper Quorum 中除了存储了 -ROOT- 表的地址和 HMaster 的地址， HRegionServer 也会把自己以 Ephemeral 方式注册到 Zookeeper 中，使得 HMaster 可以随时感知到各个 HRegionServer 的健康状态。此外， Zookeeper 也避免了 HMaster 的单点问题，见下文描述
HMaster
HMaster 没有单点问题， HBase 中可以启动多个 HMaster ，通过 Zookeeper 的 Master Election 机制保证总有一个 Master 运行， HMaster 在功能上主要负责 Table 和 Region 的管理工作 ：
1. 管理用户对 Table 的增、删、改、查操作
2. 管理 HRegionServer 的负载均衡，调整 Region 分布
3. 在 Region Split 后，负责新 Region 的分配
4. 在 HRegionServer 停机后，负责失效 HRegionServer 上的 Regions 迁移
HRegionServer
HRegionServer 主要负责响应用户 I/O 请求，向 HDFS 文件系统中读写数据，是 HBase 中最核心的模块 。
HRegionServer 内部管理了一系列 HRegion 对象，每个 HRegion 对应了 Table 中的一个 Region ， HRegion 中由多个 HStore 组成。每个 HStore 对应了 Table 中的一个 Column Family 的存储 ，可以看出每个 Column Family 其实就是一个集中的存储单元，因此最好将具备共同 IO 特性的 column 放在一个 Column Family 中，这样最高效。
HStore 存储是 HBase 存储的核心了，其中由两部分组成，一部分是 MemStore ，一部分是 StoreFiles 。 MemStore 是 Sorted Memory Buffer ，用户写入的数据首先会放入 MemStore ，当 MemStore 满了以后会 Flush 成一个 StoreFile （底层实现是 HFile ） ，当 StoreFile 文件数量增长到一定阈值，会触发 Compact 合并操作 ，将多个 StoreFiles 合并成一个 StoreFile ，合并过程中会进行版本合并和数据删除，因此可以看出 HBase 其实只有增加数据，所有的更新和删除操作都是在后续的 compact 过程中进行的，这使得用户的写操作只要进入内存中就可以立即返回，保证了 HBase I/O 的高性能 。当 StoreFiles Compact 后，会逐步形成越来越大的 StoreFile ，当单个 StoreFile 大小超过一定阈值后，会触发 Split 操作 ，同时把当前 Region Split 成 2 个 Region ，父 Region 会下线，新 Split 出的 2 个孩子 Region 会被 HMaster 分配到相应的 HRegionServer 上，使得原先 1 个 Region 的压力得以分流到 2 个 Region 上。下图描述了 Compaction 和 Split 的过程：
(HBase 数据恢复机制 )
在理解了上述 HStore 的基本原理后，还必须了解一下 HLog 的功能，因为上述的 HStore 在系统正常工作的前提下是没有问题的，但是在分布式系统环境中，无法避免系统出错或者宕机，因此一旦 HRegionServer 意外退出， MemStore 中的内存数据将会丢失，这就需要引入 HLog 了。每个 HRegionServer 中都有一个 HLog 对象 ， HLog 是一个实现 Write Ahead Log 的类，在每次用户操作写入 MemStore 的同时，也会写一份数据到 HLog 文件中（ HLog 文件格式见后续）， HLog 文件定期会滚动出新的，并删除旧的文件（已持久化到 StoreFile 中的数据）。当 HRegionServer 意外终止后， HMaster 会通过 Zookeeper 感知到， HMaster 首先会处理遗留的 HLog 文件，将其中不同 Region 的 Log 数据进行拆分，分别放到相应 region 的目录下，然后再将失效的 region 重新分配，领取到这些 region 的 HRegionServer 在 Load Region 的过程中，会发现有历史 HLog 需要处理，因此会 Replay HLog 中的数据到 MemStore 中，然后 flush 到 StoreFiles ，完成数据恢复。
HBase 存储格式
HBase 中的所有数据文件都存储在 Hadoop HDFS 文件系统上，主要包括上述提出的两种文件类型：
1. HFile ， HBase 中 KeyValue 数据的存储格式， HFile 是 Hadoop 的二进制格式文件，实际上 StoreFile 就是对 HFile 做了轻量级包装，即 StoreFile 底层就是 HFile
2. HLog File ， HBase 中 WAL （ Write Ahead Log ） 的存储格式，物理上是 Hadoop 的 Sequence File
HFile
下图是 HFile 的存储格式：
首先 HFile 文件是不定长的，长度固定的只有其中的两块： Trailer 和 FileInfo 。正如图中所示的， Trailer 中有指针指向其他数据块的起始点 。 File Info 中记录了文件的一些 Meta 信息 ，例如： AVG_KEY_LEN,AVG_VALUE_LEN,LAST_KEY,COMPARATOR,MAX_SEQ_ID_KEY 等。 Data Index 和 Meta Index 块记录了每个 Data 块和 Meta 块的起始点 。
Data Block 是 HBase I/O 的基本单元，为了提高效率， HRegionServer 中有基于 LRU 的 Block Cache 机制。每个 Data 块的大小可以在创建一个 Table 的时候通过参数指定，大号的 Block 有利于顺序 Scan ，小号 Block 利于随机查询。每个 Data 块除了开头的 Magic 以外就是一个个 KeyValue 对拼接而成,Magic 内容就是一些随机数字，目的是防止数据损坏。后面会详细介绍每个 KeyValue 对的内部构造。
HFile 里面的每个 KeyValue 对就是一个简单的 byte 数组。但是这个 byte 数组里面包含了很多项，并且有固定的结构。我们来看看里面的具体结构：
开始是两个固定长度的数值，分别表示 Key 的长度和 Value 的长度。紧接着是 Key ，开始是固定长度的数值，表示 RowKey 的长度，紧接着是 RowKey ，然后是固定长度的数值，表示 Family 的长度，然后是 Family ，接着是 Qualifier ，然后是两个固定长度的数值，表示 Time Stamp 和 Key Type （ Put/Delete ）。 Value 部分没有这么复杂的结构，就是纯粹的二进制数据了。
HLogFile
上图中示意了 HLog 文件的结构，其实 HLog 文件就是一个普通的 Hadoop Sequence File ， Sequence File 的 Key 是 HLogKey 对象， HLogKey 中记录了写入数据的归属信息，除了 table 和 region 名字外，同时还包括 sequence number 和 timestamp ， timestamp 是“写入时间”， sequence number 的起始值为 0 ，或者是最近一次存入文件系统中 sequence number 。
HLog Sequece File 的 Value 是 HBase 的 KeyValue 对象 ，即对应 HFile 中的 KeyValue ，可参见上文描述。
结束
本文对 HBase 技术在功能和设计上进行了大致的介绍，由于篇幅有限，本文没有过多深入地描述 HBase 的一些细节技术。目前一淘的存储系统就是基于 HBase 技术搭建的，后续将介绍“一淘分布式存储系统”，通过实际案例来更多的介绍 HBase 应用。
一淘网的系统架构主要见这里：
http://www.cnblogs.com/guanjie20/archive/2011/09/01/2162074.html
HBase 实践：
三、