HBase权威指南—读书笔记(一)

1.1 RDBMS & HBase

#1 传统的关系型数据管理系统(Relational Database Management System,RDBMS)

• （目标）首先，互联网时代，我们都希望通过互联网迅速，准确，切合我们需求的检索到我们问题的答案。
• （因素）数据量增多，处理数据能力增强，需要收集存储的数据容量增大。
• （解决）对应RDBMS，唯一的选择是将收集的数据进行删减再保存，例如：只保存最近N天的数据(此方法短期可行，且不能存储几个月或几年的所有数据)。
• （建议）建议：构建一种数学模型覆盖整个时间段或者改进一个算法，重新跑以前的数据，以达到更好的效果。

结构化数据: 二维表（关系型）
半结构化数据: 树、图
非结构化数据: 文本、图片、图像...

#2 列式存储数据库

以列为单位聚合数据，然后将列值顺序存入磁盘。
基于的假设：对于特定的查询，不是所有的值都是必须的，尤其在分析型数据库中。
优点：减少I/O,利于压缩。

Hbase 和传统的列式存储数据库的不同：传统的适合实时存取数据的场景，Hbase适合键值对或有序的数据存取。

1.2 关系型数据库的问题

问题a：怎么减少压力？

• (1)增加用于并行读取的从服务器，将读写分离。
  此方案保留一个主数据库服务器，但它现在只服务于写请求，网站请求大多为用户浏览产生，所以读请求远大于写请求。
• (2)增加缓存
  现在可以将读操作接入到高速在内存中缓存数据的系统中
  缺点：无法保证数据的一致性。因为用户更新数据到数据库，而数据库不会主动更新缓存系统中的数据。
  解决：可以尽可能快的同步缓存和数据库视图，减少更新缓存和数据库之间的时间差。
• (3)写请求还是存在问题

问题b：数据分区问题（分库分表？？？）

分区主要描述逻辑上水平划分数据的方案，将数据分文件或分服务器存储，而不是连续存储。（缺点多）

1.3 非关系型数据库 NoSQL(not only sql)

标识符号化：最新的存储系统不提供通过SQL查询数据的手段，只提供一些比较简单的，类似于API接口的方式来存取数据。但是也有一些工具为NoSQL数据存储提供了sql语言的入口，用于执行一些关系型数据库中的常用的复杂条件查询。所以在查询方式的限制上，两者没有严格的区别。

1.3.1 维度

(1)数据模型

数据有多种存储方式，包括键/值对（类似HashMap）、半结构化的列式存储和文档结构存储。
问题：用户如何存取数据？数据模式是否随着时间变化？

(2)存储模型

问题：内存还是持久化？考虑持久化方案，该方案是否影响到访问模式？

(3)一致性模型

问题：严格一致性还是最终一致性？问题是存储系统如何实现它的目标：必须降低一致性要求吗？

(4)物理模型

问题：分布式模式还是单机模式？

(5)读/写性能

用户必须了解自己应用程序的访问模式。
问题：是读写相当还是读多写少或是读少写多？是用范围扫描还是随机读请求数据好？

(6)辅助索引

辅助索引支持用户按不同的字段和排序方式来访问表。

(7)故障处理

机器崩溃无法避免，需要一套数据迁移方案来应对。
问题：每个数据存储如何进行服务器故障处理？故障处理完毕后能否正常工作？

(8)压缩

需要存储TB级数据，尤其这些数据差异性很小或由可读性文本组成，压缩能节省大量原始数据存储。
问题：有可选的压缩组件吗？有哪些压缩算法可用？

(9)负载均衡

假设用户有高读写吞吐率的需求，就需要考虑配置一套随着负载自动均衡处理能力的系统。

(10)原子操作的---读/修改/写

因为RDBMS是集中式面向单服务器的系统，故它提供了这类操作。但是这些操作在分布式系统很难实现，这些操作可以帮助用户避免多线程造成的资源竞争。

(11)加锁，等待和死锁

复杂的事务处理，可能造成多个客户端竞争同一资源。
问题：用户需要支持的系统采用哪种锁模型？这种锁模型能否避免等待和死锁？

以上的维度要进行需求评估，再做出明智的选择（RDBMS还是NoSQl，或者两者混合使用）

1.3.2 可扩展性

RDBMS非常适合事务性操作，但不善于超大规模的数据分析处理，因为超大规模的查询需要进行大范围的数据记录扫描或者全表扫描。
用户可以反范式化数据模型来避免等待，并且可以通过降低锁粒度的方式来尽量避免死锁。

1.3.3 数据库的范式化和反范式化

外部资料:
在实际工作中，数据库数据模型的建立和选择对数据的“增删改查”具有直接影响，从基本角度来讲，数据模型具有“范式化”和“反范式化”两种，而在实际工作场景中，常依赖实际情况采取这两种模型混用。

后面章节有详细介绍。。。。(之后再聊)

1.4 结构

1.4.1 背景

• 2003年谷歌发表的一篇论文“The Google File System”(是一个分布式文件系统，简称GFS)。它使用商用硬件集群存储海量数据。
• 不久，Google的另一篇论文问世，“MapReduce:Simplified Data Processing on Large Clusters”。MapReduce加上GFS形成了处理海量数据的核心力量。

但是上面的GFS和MapReduce都缺乏实时随机存取数据的能力（即意味着不足以处理Web服务）。

GFS还有一个缺陷：它适合存储少许非常非常大的文件，而不适合存储非常非常多的小文件。因为文件的元数据信息最后要存储到主节点的内存中，文件越多，主节点的压力越大。

意识到RDBMS在大规模处理中的缺点，开始考虑问题的其他切入点：摒弃关系型的特点，采用简单的API来进行增、查、改、删（Create,Read,Update,and Delete,简称CRUD）操作，再加一个扫描函数，在较大的建范围或者全表范围上迭代扫描。

1.4.2 表、行、列和单元格

最基本的单位是列(column)，一列或多列形成一行(row)，并由唯一的行键(row key) 来确定存储。

反过来说，一个表(table)中有若干行，其中每列可能有多个版本，在每一个单元格(cell)中存储了不同的值。

图1

注：排列的顺序按照先比较首位首位小的在前，大的在后；首位相同比后一位，小的在前，大的在后；以此类推。如row-1，排在row-2前面，row-10它有两位排在row-1后面，但是首位1小于row-2首位，故row-10在row-1后面，在row-2前面。

按行键排序来get数据，类似RDBMS主键索引，也就是说行键是唯一的，并且只出现一次，否则你就是在更新同一行。

一行由若干列组成，若干列又构成一个列族。列族需要在表创建时就定义好，并且不能修改太频繁，数量也不能太多。列族名必须由可打印字符（就是在显示器上输出能看得见的）组成。

常见引用列的格式为family:qualifier,qualifier是任意的字符数组。与列族的数量有限制相反，列的数量没有限制，列值的类型和长度也没有限制。

每一列的值或单元格的值都具有时间戳(TimeStamp)，默认系统指定，也可以由用户显示设置。

时间戳的作用：根据时间戳区分不同版本的值。一个单元格的版本值按照降序排列在一起，访问的时候优先读取最新的数据。

HBase是按照BigTable模型实现的，是一个稀疏的、分布式的、持久化的、多维的映射，由行键、列键和时间戳索引，结合这些可以得出如下的数据存取模式：

（Table,RowKey,Family,Column,TimeStamp）—>value

也可以用下面的格式表示：

SortMap>>>

第一个SortMap代表一个表，包含一个列族List；列族中包含另一个SortMap存储列和对应的值，这些值在最后的List中存储了值和该值被设置的时间戳。

1.4.3 自动分区

HBase中扩展和负载均衡的基本单位称为Region，region的本质上是以行键排序的连续存储的区间。如果region太大，系统就把他们动态拆分；如果太小，就把多个region合并，以减少存储文件数量。

region的拆分和服务相当于其他系统提供的自动分区。当一个服务器出现故障后，该服务器上的region可以快速恢复，并且获得细粒度的负载均衡，因为当服务于某个region的服务器当前负载过大、发生错误或被停止使用导致不可用时，系统会把该region转移到其他服务器上。

1.4.4 存储API

API提供建表、删表、增加列族、和删除列族操作。同时还提供了修改表和列族元数据的功能，如压缩和设置块大小。此外，还提供了客户端对给定的行键值进行增加、删除和查找操作的功能。

scan API提供了高效遍历某个范围的行的功能，同时可以限定返回哪些列或者返回的版本数。通过设置过滤器可以匹配返回的列，通过设置初始和终止的时间范围可以选择查询的版本。

系统支持单行事务，基于这个特性，系统实现了对单个行键下存储的数据的原子读-修改-写序列。虽然不支持跨行跨表的事务，但客户端已经能够支持批量操作以获得更好的性能。

单元格的值还可以当作计数器使用，并且能够支持原子更新。这个计数器能够在一个操作中完成读和修改，因此尽管是分布式的系统架构，客户端依然可以利用此特性实现全局的、强一致的、连续的计数器。

还可以在服务器的地址空间中执行来自客户端的代码，支持该功能的服务端框架叫做协处理器。这个代码能直接访问服务器本地的数据，可以用于实现轻量级批处理作业，或者使用表达式并基于各种操作来分析和汇总数据。

最后，系统通过提供包装器集成了MapReduce框架，该包装器能够将表转换为MapReduce作业的输入源和输出目标。

1.4.5 实现

数据存储在存储文件中，称为HFile,HFile中存储的是经过排序的键值映射结构。文件内部由连续的块组成，块的索引信息存储在文件的尾部。

每一个HFile都有一个块索引，通过一个磁盘查找就可以实现查询。首先，在内存的块索引中进行二分查找，确定包含给定键的块，然后读取磁盘块找到实际要找的键。

存储文件通常保存在Hadoop分布式文件系统(HDFS)中，HDFS提供了一个可扩展、持久的、冗余的HBase存储层。存储文件通过将更改写入到可配置数目的物理服务器中，以保证数据不丢失。