大数据技术概述复习（一）

本文整理复习自用，仅供参考

引用：

1《大数据技术原理与应用（第3版）》

2 https://blog.csdn.net/weixin_45207388/article/details/102933958

3 https://buwenbuhuo.blog.csdn.net/article/details/105690566

这里写目录标题

大数据技术概述复习（一）
- 1.大数据的四大特点（4V）
- 2.大数据两大核心技术
- - 2.1分布式存储
  - - 2.1.1概述
    - 2.1.2分布式文件系统
  - 2.2分布式计算
  - - 2.2.1概述
    - 2.2.2计算过程概览
- 3.Hadoop及其生态圈
- - 3.1 Hadoop
  - - 3.1.1版本演变
    - - 3.1.1.1 YARN
    - 3.1.2配置文件
  - 3.2 Hadoop-分布式文件系统HDFS
  - - 3.2.1HDFS分块存储
    - 3.2.2HDFS相关概念
    - 3.2.3HDFS的组成架构
    - 3.2.4命名空间
    - 3.2.5**冗余数据保存**
    - 3.2.6**数据错误与恢复**
    - **3.2.7**数据存取策略
    - 3.2.8HDFS数据读写过程
  - 3.3 Hadoop-分布式计算引擎MapReduce
  - - 3.3.2MapReduce的核心思想
    - 3.3.2分布式并行计算框架
    - 3.3.3 MapReduce设计构思
    - 3.3.4MapReduce工作流程概述
  - 3.4 分布式数据库HBASE
  - - 3.4.1NoSQL
    - - 3.4.1.1简介
      - 3.4.1.2NoSQL兴起的原因
      - 3.4.1.2.1传统的关系数据库无法满足web2.0网站的需求
        
        3.4.1.2.2关系数据库的关键特性在web2.0时代成为“鸡肋”
      - 3.4.1.3NoSQL与SQL的比较
      - 3.4.1.3.1两种数据库的优缺点总结
      - 3.4.1.4NoSQL数据库的四大类型
      - 3.4.1.5NoSQL的三大基石
      - 3.4.1.5.1CAP
        
        3.4.1.5.2BASE
    - 3.4.2HBASE
    - - 3.4.2.1HBASE概述
      - 3.4.2.2HBase与传统的关系数据库的区别
      - 3.4.2.3**HBASE是面向列的存储**
      - 3.4.2.4HBase数据模型
      - 3.4.2.4.1概述
        
        3.4.2.4.2相关概念
        
        3.4.2.4.3数据模型实例
        
        3.4.2.4.4数据坐标
        
        3.4.2.4.5HBase数据的概念视图和物理视图
      - 3.4.2.5HBASE的实现原理
      - 3.4.2.5.1 HBase功能组件
        
        **3.4.2.5.2数据分区机制。**
        
        3.4.2.5.3**HBase中的分区定位**
      - 3.4.2.6HBASE的运行机制
      - 3.4.2.6.1**HBase系统基本架构以及每个组成部分的作用。**
        
        3.4.2.6.2**Region服务器向HDFS文件系统中读写数据的基本原理**
  - 3.5 云数据库
  - - 3.5.1云数据库的概念
    - 3.5.2云计算模式的优势
    - 3.5.3云数据库特性
    - 3.5.4 云数据库厂商及其代表性产品

1.大数据的四大特点（4V）

Volume（大量）

根据IDC作出的估测，数据一直都在以每年50%的速度增长，也就是说每两年就增长一倍（大数据摩尔定律）

人类在最近两年产生的数据量相当于之前产生的全部数据量

预计到2020年，全球将总共拥有35ZB的数据量，相较于2010年，数据量将增长近30倍

Velocity（高速）

这是大数据区于传统数据挖掘的最显著特征。

从数据的生成到消耗，时间窗口非常小，可用于生成决策的时间非常少

Variety（多样）

相对于以往便储存的以数据库/文本为主的结构化数据，非结构化数据越来越多，包括网络日志、音频、视频、图片、地理位置信息等。这些多类型的数据对数据的处理能力提出了更高要求。

Value（低价值密度）

价值密度低，商业价值高。

2.大数据两大核心技术

2.1分布式存储

2.1.1概述

大数据时代的到来促成了分布式文件系统：

*数据更新快、数据量大、数据种类多、数据来源广，传统的单机存储系统无法适应。

互联网上一分钟内有3万小时的音乐播放记录

43万次维基百科页面的访问记录

4百万条谷歌搜索记录

单台计算机磁盘无法存放海量数据

于是出现了分布式存储

将海量数据分配到多个操作系统管理的磁盘中进行存储。

2.1.2分布式文件系统

特点

数据分块，分布式的存储在多台机器上。
各个节点可分布在不同地点，通过网络进行节点间的通信和数据传输。
节点符合主从结构，主节点存储元数据，从节点存储时间数据。
数据块冗余存储在多台机器以提高数据块的高可用性。
用户调用数据时，不用关心数据在从节点的存储位置，客户端向主节点发送请求即可。

2.2分布式计算

2.2.1概述

分布式计算简单来说，是把一个大计算任务拆分成多个小计算任务分布到若干台机器上去计算，然后再进行结果汇总。

目的在于分析计算海量的数据，从雷达监测的海量历史信号中分析异常信号，淘宝双十一实时计算各地区的消费习惯等。

海量计算最开始的方案是提高单机计算性能，如大型机，后来由于数据的爆发式增长、单机性能却跟不上，才有分布式计算这种妥协方案。因为计算一旦拆分，问题会变得非常复杂，像一致性、数据完整、通信、容灾、任务调度等问题也都来了。

2.2.2计算过程概览

3.Hadoop及其生态圈

Hadoop生态圈基本上是为了处理超过单机尺度的数据处理而诞生的。

可以把生态圈比作一个厨房所需要的各种工具：锅碗瓢盆，各有各的用处，互相之间又有重合。你可以用汤锅直接当碗吃饭喝汤，你也可以用小刀或者刨子去皮。每个工具都有自己的特性，也能组合起来工作，但要达到最佳效果，则需要一番努力。

3.1 Hadoop

Hadoop是Apache软件基金会旗下的一个开源分布式计算平台，为用户提供了系统底层细节透明的分布式基础架构

Hadoop是基于Java语言开发的，具有很好的跨平台特性，并且可以部署在廉价的计算机集群中
Hadoop的核心是分布式文件系统HDFS（Hadoop Distributed File System）和MapReduce
Hadoop被公认为行业大数据标准开源软件，在分布式环境下提供了海量数据的处理能力

几乎所有主流厂商都围绕Hadoop提供开发工具、开源软件、商业化工具和技术服务，如谷歌、雅虎、微软、思科、淘宝等，都支持Hadoop

Hadoop是一个能够对大量数据进行分布式处理的软件框架，并且是以一种可靠、高效、可伸缩的方式进行处理的，它具有以下几个方面的特性：

高可靠性
高效性
高可扩展性
高容错性
成本低
运行在Linux平台上
支持多种编程语言

3.1.1版本演变

Apache Hadoop版本分为两代，我们将第一代Hadoop称为Hadoop 1.0，第二代Hadoop称为Hadoop 2.0
第一代Hadoop包含三个大版本，分别是0.20.x，0.21.x和0.22.x，其中，0.20.x最后演化成1.0.x，变成了稳定版，而0.21.x和0.22.x则增加了NameNode HA等新的重大特性
第二代Hadoop包含两个版本，分别是0.23.x和2.x，它们完全不同于Hadoop 1.0，是一套全新的架构，均包含HDFS Federation和YARN两个系统，相比于0.23.x，2.x增加了NameNode HA和Wire-compatibility两个重大特性

3.1.1.1 YARN

Apache Hadoop YARN （Yet Another Resource Negotiator，另一种资源协调者）是一种新的 Hadoop 资源管理器，它是一个通用资源管理系统和调度平台，可为上层应用提供统一的资源管理和调度。

它的引入为集群在利用率、资源统一管理和数据共享等方面带来了巨大好处。

我们可以把yarn理解为相当于一个分布式的操作系统平台，而mapreduce等运算程序则相当于运行于操作系统之上的应用程序，Yarn为这些程序提供运算所需的资源（CPU，内存，磁盘等）。

同时大家需要了解以下几点:

yarn并不清楚用户提交的程序的运行机制
yarn只提供运算资源的调度（用户程序向yarn申请资源，yarn就负责分配资源）
yarn中的主管角色叫ResourceManager
yarn中具体提供运算资源的角色叫NodeManager
yarn与运行的用户程序完全解耦，意味着yarn上可以运行各种类型的分布式运算程序，比如mapreduce、storm，spark等
spark、storm等运算框架都可以整合在yarn上运行，只要他们各自的框架中有符合yarn规范的资源请求机制即可
yarn成为一个通用的资源调度平台.企业中以前存在的各种运算集群都可以整合在一个物理集群上，提高资源利用率，方便数据共享

3.1.2配置文件

伪分布式安装需要修改的配置文件

1.修改配置文件 core-site.xml

<configuration><property><name>hadoop.tmp.dir</name><value>file:/usr/local/hadoop/tmp</value><description>Abase for other temporary directories.</description></property><property><name>fs.defaultFS</name><value>hdfs://localhost:9000</value></property>
</configuration>

hadoop.tmp.dir表示存放临时数据的目录，即包括NameNode的数据，也包括DataNode的数据。该路径任意指定，只要实际存在该文件夹即可

name为fs.defaultFS的值，表示hdfs路径的逻辑名称

2.修改配置文件 hdfs-site.xml

<configuration><property><name>dfs.replication</name><value>1</value></property><property><name>dfs.namenode.name.dir</name><value>file:/usr/local/hadoop/tmp/dfs/name</value></property><property><name>dfs.datanode.data.dir</name><value>file:/usr/local/hadoop/tmp/dfs/data</value></property>
</configuration>

dfs.replication表示副本的数量，伪分布式要设置为1

dfs.namenode.name.dir表示本地磁盘目录，是存储fsimage文件的地方

dfs.datanode.data.dir表示本地磁盘目录，HDFS数据存放block的地方

3.2 Hadoop-分布式文件系统HDFS

首先你要能存的下大数据。

HDFS（Hadoop Distributed File System）的设计本质上是为了大量的数据能横跨成百上千台机器，但是你看到的是一个文件系统而不是很多文件系统。

比如你说我要获取路径为“/hdfs/tmp/file1”的数据，你可以只用引用一个文件路径，但是实际的数据存放在很多不同的机器上。

你作为用户，不需要知道这些，就好比在单机上你不关心文件分散在什么磁道什么扇区一样。HDFS为你透明地管理这些分布式的数据。

总体而言，HDFS要实现以下目标：

兼容廉价的硬件设备
流数据读写
大数据集
简单的文件模型
强大的跨平台兼容性

3.2.1HDFS分块存储

HDFS将所有的文件全部抽象成为block块来进行存储，不管文件大小，全部一视同仁都是以block块的统一大小和形式进行存储，方便我们的分布式文件系统对文件的管理。

块的默认大小在Hadoop2.x版本中是128M，老版本为64M。block块的大小可以通过hdfs-site.xml当中的配置文件进行指定。
<property><name>dfs.block.size</name><value>块大小 以字节为单位</value>  //只写数值就可以
</property>

抽象成数据块的好处

HDFS采用抽象的块概念可以带来以下几个明显的好处：

● 支持大规模文件存储：文件以块为单位进行存储，一个大规模文件可以被分拆成若干个文件块，不同的文件块可以被分发到不同的节点上，

因此，一个文件的大小不会受到单个节点的存储容量的限制，可以远远大于网络中任意节点的存储容量

● 简化系统设计：首先，大大简化了存储管理，因为文件块大小是固定的，这样就可以很容易计算出一个节点可以存储多少文件块；

以块作为存储单位,块的大小远远大于普通文件系统，可以最小化寻址开销；

其次，方便了元数据的管理，元数据不需要和文件块一起存储，可以由其他系统负责管理元数据。

● 适合数据备份：每个文件块都可以冗余存储到多个节点上，大大提高了系统的容错性和可用性

3.2.2HDFS相关概念

①NameNode（Master）

1.管理HDFS的名称空间，保存了两个核心的数据结构，即FsImage和EditLog

FsImage用于维护文件系统树以及文件树中所有的文件和文件夹的元数据

操作日志文件EditLog中记录了所有针对文件的创建、删除、重命名等操作
2.配置副本策略
3.管理数据块(Block)映射信息

名称节点记录了每个文件中各个块所在的数据节点的位置信息
4.处理客户端读写请求

试述HDFS1.0中只包含—个名称节点会带来哪些问题?

HDFS1.0只设置唯一的名称节点，这样做虽然大大简化了系统设计，但也带来了一些明显的局限性，具体如下：

（1）命名空间的限制：名称节点是保存在内存中的，因此，名称节点能够容纳的对象（文件、块）的个数会受到内存空间大小的限制。

（2）性能的瓶颈：整个分布式文件系统的吞吐量，受限于单个名称节点的吞吐量。

（3）隔离问题：由于集群中只有一个名称节点，只有一个命名空间，因此，无法对不同应用程序进行隔离。

（4）集群的可用性：一旦这个唯一的名称节点发生故障，会导致整个集群变得不可用。

②DataNode（Slave）

1.存储实际的数据块
2.执行数据块的读/写操作

根据客户端或者是名称节点的调度来进行数据的存储和检索

向名称节点定期发送自己所存储的块的列表

③ Client

1.文件切分。文件上传HDFS的时候，Client将文件切分成一个一个的Block，然后进行上传
2.与NaneNode交互，获取文件的位置信息
3.与DataNode交互，读取或者写入数据
4.Client提供一些命令来管理HDFS，比如NameNode格式化
5.Client可以通过一些命令来访问HDFS，比如对HDFS增删查改操作

④SecondaryNameNode：

1.辅助NameNode，分担其工作量，比如定期合并Fsimage和Edits，并推送给NameNode
2.在紧急情况下，可辅助恢复NameNode

3.2.3HDFS的组成架构

在HDFS中，使用主从节点的方式，即使用Master和Slave结构对集群进行管理。一般一个 HDFS 集群只有一个Namenode 和一定数目的Datanode 组成。

Namenode 是 HDFS 集群主节点，Datanode 是 HDFS集群从节点，两种角色各司其职，共同协调完成分布式的文件存储服务。

3.2.4命名空间

HDFS的命名空间包含目录、文件和块

在HDFS1.0体系结构中，在整个HDFS集群中只有一个命名空间，并且只有唯一一个名称节点，该节点负责对这个命名空间进行管理

**HDFS 支持传统的层次型文件组织结构。**用户或者应用程序可以创建目录，然后将文件保存在这些目录里。文件系统名字空间的层次结构和大多数现有的文件系统类似：用户可以创建、删除、移动或重命名文件。

Namenode 负责维护文件系统的名字空间，任何对文件系统名字空间或属性的修改都将被Namenode 记录下来。HDFS 会给客户端提供一个统一的抽象目录树，客户端通过路径来访问文件，
形如：hdfs://namenode:port/dir-a/dir-b/dir-c/file.data。

3.2.5冗余数据保存

作为一个分布式文件系统，为了保证系统的容错性和可用性，HDFS采用了多副本方式对数据进行冗余存储，通常一个数据块的多个副本会被分布到不同的数据节点上

如图所示，数据块1被分别存放到数据节点A和C上，数据块2被存放在数据节点A和B上。这种多副本方式具有以下几个优点：

（1）加快数据传输速度

（2）容易检查数据错误

（3）保证数据可靠性

3.2.6数据错误与恢复

HDFS具有较高的容错性，可以兼容廉价的硬件，它把硬件出错看作一种常态，而不是异常，并设计了相应的机制检测数据错误和进行自动恢复，主要包括以下几种情形：名称节点出错、数据节点出错和数据出错。

1. 名称节点出错

名称节点保存了所有的元数据信息，其中，最核心的两大数据结构是FsImage和Editlog，如果这两个文件发生损坏，那么整个HDFS实例将失效。因此，HDFS设置了备份机制，把这些核心文件同步复制到备份服务器SecondaryNameNode上。当名称节点出错时，就可以根据备份服务器SecondaryNameNode中的FsImage和Editlog数据进行恢复。

2. 数据节点出错

每个数据节点会定期向名称节点发送“心跳”信息，向名称节点报告自己的状态
当数据节点发生故障，或者网络发生断网时，名称节点就无法收到来自一些数据节点的心跳信息，这时，这些数据节点就会被标记为“宕机”，节点上面的所有数据都会被标记为“不可读”，名称节点不会再给它们发送任何I/O请求

这时，有可能出现一种情形，即由于一些数据节点的不可用，会导致一些数据块的副本数量小于冗余因子

名称节点会定期检查这种情况，一旦发现某个数据块的副本数量小于冗余因子，就会启动数据冗余复制，为它生成新的副本

HDFS和其它分布式文件系统的最大区别就是可以调整冗余数据的位置

3. 数据出错

网络传输和磁盘错误等因素，都会造成数据错误

客户端在读取到数据后，会采用md5和sha1对数据块进行校验，以确定读取到正确的数据
在文件被创建时，客户端就会对每一个文件块进行信息摘录，并把这些信息写入到同一个路径的隐藏文件里面
当客户端读取文件的时候，会先读取该信息文件，然后，利用该信息文件对每个读取的数据块进行校验，如果校验出错，客户端就会请求到另外一个数据节点读取该文件块，并且向名称节点报告这个文件块有错误，名称节点会定期检查并且重新复制这个块

3.2.7数据存取策略

1.数据存放

第一个副本：放置在上传文件的数据节点；如果是集群外提交，则随机挑选一台磁盘不太满、CPU不太忙的节点

第二个副本：放置在与第一个副本不同的机架的节点上

第三个副本：与第一个副本相同机架的其他节点上

更多副本：随机节点

2. 数据读取

HDFS提供了一个API可以确定一个数据节点所属的机架ID，客户端也可以调用API获取自己所属的机架ID

当客户端读取数据时，从名称节点获得数据块不同副本的存放位置列表，列表中包含了副本所在的数据节点，可以调用API来确定客户端和这些数据节点所属的机架ID，

当发现某个数据块副本对应的机架ID和客户端对应的机架ID相同时，就优先选择该副本读取数据，如果没有发现，就随机选择一个副本读取数据

3.2.8HDFS数据读写过程

FileSystem是一个通用文件系统的抽象基类，可以被分布式文件系统继承，所有可能使用Hadoop文件系统的代码，都要使用这个类

Hadoop为FileSystem这个抽象类提供了多种具体实现,DistributedFileSystem就是FileSystem在HDFS文件系统中的具体实现

FileSystem的open()方法返回的是一个输入流FSDataInputStream对象，在HDFS文件系统中，具体的输入流就是DFSInputStream；FileSystem中的create()方法返回的是一个输出流FSDataOutputStream对象，在HDFS文件系统中，具体的输出流就是DFSOutputStream。

3.2.8.1 读数据

3.2.8.2写数据

3.3 Hadoop-分布式计算引擎MapReduce

存下数据之后，你就开始考虑怎么处理数据。

虽然HDFS可以为你整体管理不同机器上的数据，但是这些数据太大了。如果只让一台机器读取成T上P的数据，很多时候需要好几天甚至好几周的时间。因此，对于很多应用场景来说，单机处理是不可忍受的，比如微博要更新24小时热博，它必须在24小时之内跑完这些处理。那么我如果要用很多台机器处理，我就面临了如何分配工作，如果一台机器挂了如何重新启动相应的任务，机器之间如何互相通信交换数据以完成复杂的计算等等。这就是MapReduce/Tez/Spark的功能。

MapReduce是第一代计算引擎，Tez和Spark是第二代。MapReduce的设计，采用了很简化的计算模型，只有Map和Reduce两个计算过程（中间用Shuffle串联），用这个模型，已经可以处理大数据领域很大一部分问题了。

3.3.2MapReduce的核心思想

MapReduce的思想核心是“分而治之”，适用于大量复杂的任务处理场景（大规模数据处理场景）。

另一个设计的重要理念就是“计算向数据靠拢”，而不是“数据向计算靠拢”，因为，移动数据需要大量的网络传输开销

Map负责“分”，即把复杂的任务分解为若干个“简单的任务”来并行处理。可以进行拆分的前提是这些小任务可以并行计算，彼此间几乎没有依赖关系。
Reduce负责“合”，即对map阶段的结果进行全局汇总。
这两个阶段合起来正是MapReduce思想的体现。

比较形象的语言解释MapReduce：　　
我们要数图书馆中的所有书。你数1号书架，我数2号书架。这就是“Map”。我们人越多，数书就更快。
现在我们到一起，把所有人的统计数加在一起。这就是“Reduce”。

3.3.2分布式并行计算框架

计算框架是指实现某项任务或某项工作从开始到结束的计算过程或流的结构。

MapReduce具体的计算框架分布如下所示:

并行计算框架

一个大的任务拆分成多个小任务，将多个小任务分发到多个节点上。每个节点同时执行计算的框架即为并行计算框架

MapReduce相较于传统的并行计算框架有什么优势

3.3.3 MapReduce设计构思

MapReduce是一个分布式运算程序的编程框架，核心功能是将用户编写的业务逻辑代码和自带默认组件整合成一个完整的分布式运算程序，并发运行在Hadoop集群上。

既然是做计算的框架，那么表现形式就是有个输入（input），MapReduce操作这个输入（input），通过本身定义好的计算模型，得到一个输出（output）。

对许多开发者来说，自己完完全全实现一个并行计算程序难度太大，而MapReduce就是一种简化并行计算的编程模型，降低了开发并行应用的入门门槛。

MapReduce构思体现在如下的方面：

1. 如何对付大数据处理：分而治之

对相互间不具有计算依赖关系的大数据，实现并行最自然的办法就是采取分而治之的策略。并行计算的第一个重要问题是如何划分计算任务或者计算数据以便对划分的子任务或数据块同时进行计算。不可分拆的计算任务或相互间有依赖关系的数据无法进行并行计算！

2. 构建抽象模型：Map和Reduce

 MapReduce借鉴了函数式语言中的思想，用Map和Reduce两个函数提供了高层的并行编程抽象模型。Map: 对一组数据元素进行某种重复式的处理；Reduce: 对Map的中间结果进行某种进一步的结果整理。MapReduce中定义了如下的Map和Reduce两个抽象的编程接口，由用户去编程实现:map: (k1; v1) → [(k2; v2)]reduce: (k2; [v2]) → [(k3; v3)]

Map和Reduce为程序员提供了一个清晰的操作接口抽象描述。

通过以上两个编程接口，大家可以看出MapReduce处理的数据类型是<key,value>键值对。

3. 统一构架，隐藏系统层细节

如何提供统一的计算框架，如果没有统一封装底层细节，那么程序员则需要考虑诸如数据存储、划分、分发、结果收集、错误恢复等诸多细节；为此，MapReduce设计并提供了统一的计算框架，为程序员隐藏了绝大多数系统层面的处理细节。

MapReduce最大的亮点在于通过抽象模型和计算框架把需要做什么(what need to do)与具体怎么做(how to do)分开了，为程序员提供一个抽象和高层的编程接口和框架。

程序员仅需要关心其应用层的具体计算问题，仅需编写少量的处理应用本身计算问题的程序代码。如何具体完成这个并行计算任务所相关的诸多系统层细节被隐藏起来,交给计算框架去处理：从分布代码的执行，到大到数千小到单个节点集群的自动调度使用。

3.3.4MapReduce工作流程概述

不同的Map任务之间不会进行通信
不同的Reduce任务之间也不会发生任何信息交换
用户不能显式地从一台机器向另一台机器发送消息
所有的数据交换都是通过MapReduce框架自身去实现的

3.4 分布式数据库HBASE

3.4.1NoSQL

3.4.1.1简介

NoSQL是一种不同于关系数据库的数据库管理系统设计方式，是对非关系型数据库的一类统称，它采用的数据模型并非传统关系数据库的关系模型，而是类似键/值、列族、文档等非关系模型

3.4.1.2NoSQL兴起的原因

3.4.1.2.1传统的关系数据库无法满足web2.0网站的需求

随着互联网web2.0网站的兴起，传统的关系数据库在应付web2.0网站，特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心，暴露了很多难以克服的问题，主要表现在以下几个方面：

无法满足海量数据的管理需求
无法满足数据高并发的需求
无法满足高可扩展性和高可用性的需求

而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。

NoSQL数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战，尤其是大数据应用难题，包括超大规模数据的存储。

3.4.1.2.2关系数据库的关键特性在web2.0时代成为“鸡肋”

关系数据库的关键特性包括完善的事务机制和高效的查询机制。但是，关系数据库引以为傲的两个关键特性，到了Web2.0时代却成了鸡肋，主要表现在以下几个方面：

Web2.0网站系统通常不要求严格的数据库事务
Web2.0并不要求严格的读写实时性
Web2.0通常不包含大量复杂的SQL查询（去结构化，存储空间换取更好的查询性能）

3.4.1.3NoSQL与SQL的比较

3.4.1.3.1两种数据库的优缺点总结

NoSQL数据库的优点：

1.可以很容易通过添加更多设备来支持更大规模的数据，NoSQL在设计之初就充分考虑了横向扩展的需求，可以很容易通过添加廉价设备实现扩展，可以和云计算紧密结合

2.不存在数据库模式，可以自由灵活定义并存储各种不同类型的数据

3.在NoSQL数据库却无法实现数据完整性

4.大多数NoSQL都能提供较高的可用性

NoSQL数据库的缺点：

1.没有关系代数理论作为基础

2.很多NoSQL数据库没有面向复杂查询的索引，虽然NoSQL可以使用MapReduce来加速查询，但是，在复杂查询方面的性能仍然不如RDBMS

3.很多NoSQL数据库放松了对事务ACID四性的要求，而是遵守BASE模型，只能保证最终一致性

4.NoSQL还没有行业标准，不同的NoSQL数据库都有自己的查询语言，很难规范应用程序接口

5.NoSQL在技术支持方面仍然处于起步阶段，还不成熟，缺乏有力的技术支持

6.NoSQL数据库虽然没有DBMS复杂，也难以维护

RDBMS关系数据库的优点：

1.有关系代数理论作为基础

2.借助于索引机制可以实现快速查询（包括记录查询和范围查询）

3.任何一个RDBMS都可以很容易实现数据完整性，比如通过主键或者非空约束来实现实体完整性，通过主键、外键来实现参照完整性，通过约束或者触发器来实现用户自定义完整性

4.RDBMS已经标准化（SQL）

5.RDBMS经过几十年的发展，已经非常成熟，Oracle等大型厂商都可以提供很好的技术支持

RDBMS关系数据库的缺点：

1.很难实现横向扩展，纵向扩展的空间也比较有限，性能会随着数据规模的增大而降低

2.需要定义数据库模式，严格遵守数据定义和相关约束条件

3.RDBMS严格遵守事务ACID模型，可以保证事务强一致性

4.RDBMS在任何时候都以保证数据一致性为优先目标，其次才是优化系统性能，随着数据规模的增大，RDBMS为了保证严格的一致性，只能提供相对较弱的可用性

5.RDBMS需要专门的数据库管理员(DBA)维护

3.4.1.4NoSQL数据库的四大类型

键值数据库、列族数据库、文档数据库和图数据库

3.4.1.5NoSQL的三大基石

3.4.1.5.1CAP

所谓的CAP指的是：

C（Consistency）：一致性，是指任何一个读操作总是能够读到之前完成的写操作的结果，也就是在分布式环境中，多点的数据是一致的，或者说，所有节点在同一时间具有相同的数据
A:（Availability）：可用性，是指快速获取数据，可以在确定的时间内返回操作结果，保证每个请求不管成功或者失败都有响应；
P（Tolerance of Network Partition）：分区容忍性，是指当出现网络分区的情况时（即系统中的一部分节点无法和其他节点进行通信），分离的系统也能够正常运行，也就是说，系统中任意信息的丢失或失败不会影响系统的继续运作。

不同产品在设计时对CAP理论的运用：

3.4.1.5.2BASE

与BASE相对的ACID：

ACID四性的含义

原子性（Atomicity)

指事务必须是原子工作单元，对于其数据修改，要么全都执行，要么全都不执行。

一致性（consistency）

指事务在完成时，必须使所有的数据都保持一致状态。

隔离性（Isolation)

指并发事务所做的修改必须与其他并发事务所做的修改隔离。

持久性（Durability)

指事务完成之后，它对于系统的影响是永久性的，该修改即使出现致命的系统故障也将一直保持。

关系型数据库系统中设计了复杂的事务管理机制来保证执行过程中严格满足ACID要求，故其较好地满足了银河等领域对数据一致性的要求，得到了广泛的商业应用。

但是，Web2.0网站等场景中，对数据一致性的要求并不高，而是强调系统的高可用性，因此NoSQL适当牺牲了一致性或者分区容忍性，从而获取可用性或可靠性,BASE的思想就是在这个基础上发展起来的。

BASE的具体含义

基本可用（Basically Availble）

基本可用是指一个分布式系统的一部分发生故障变得不可用时，其他部分仍可以正常使用，也就是允许分区失败的情形出现。
软状态（Soft-state）

“软状态（soft-state）”是与“硬状态（hard-state）”相对应的一种提法。

数据库保存的数据是“硬状态”时，可以保证数据一致性，即保证数据一直是正确的。

“软状态”是指状态可以有一段时间不同步，具有一定的滞后性。
最终一致性（Eventual consistency）

一致性的类型包括强一致性和若一致性

强一致性：系统中的某个数据被成功更新后，后续任何对该数据的读取操作都将得到更新后的值；

弱一致性：系统中的某个数据被更新后，后续对该数据的读取操作可能得到更新后的值，也可能是更改前的值。但经过“不一致时间窗口”这段时间后，后续对该数据的读取都是更新后的值；

最终一致性：是弱一致性的特殊形式，允许后续更新的访问操作可以暂时读不到更新后的数据，但是一段时间后必须最终读到更新后的数据。

3.4.2HBASE

3.4.2.1HBASE概述

HBase是一种分布式、可扩展、支持海量数据存储的NoSQL数据库。

HBase是一个高可靠、高性能、面向列、可伸缩的分布式数据库，是谷歌BigTable的开源实现，主要用来存储非结构化和半结构化的松散数据。HBase的目标是处理非常庞大的表，可以通过水平扩展的方式，利用廉价计算机集群处理由超过10亿行数据和数百万列元素组成的数据表

HBase是Google Bigtable的开源实现，但是也有很多不同之处。比如：

Google Bigtable利用GFS作为其文件存储系统，HBase利用Hadoop HDFS作为其文件存储系统；

Google运行MAPREDUCE来处理Bigtable中的海量数据，HBase同样利用Hadoop MapReduce来处理HBase中的海量数据；

Google Bigtable利用Chubby作为协同服务，HBase利用Zookeeper作为对应。

3.4.2.2HBase与传统的关系数据库的区别

（1）数据类型：关系数据库采用关系模型，具有丰富的数据类型和存储方式，HBase则采用了更加简单的数据模型，它把数据存储为未经解释的字符串

（2）数据操作：关系数据库中包含了丰富的操作，其中会涉及复杂的多表连接。HBase操作则不存在复杂的表与表之间的关系，只有简单的插入、查询、删除、清空等，因为HBase在设计上就避免了复杂的表和表之间的关系

（3）存储模式：关系数据库是基于行模式存储的。HBase是基于列存储的，每个列族都由几个文件保存，不同列族的文件是分离的

（4）数据索引：关系数据库通常可以针对不同列构建复杂的多个索引，以提高数据访问性能。HBase只有一个索引——行键，通过巧妙的设计，HBase中的所有访问方法，或者通过行键访问，或者通过行键扫描，从而使得整个系统不会慢下来

（5）数据维护：在关系数据库中，更新操作会用最新的当前值去替换记录中原来的旧值，旧值被覆盖后就不会存在。而在HBase中执行更新操作时，并不会删除数据旧的版本，而是生成一个新的版本，旧有的版本仍然保留

（6）可伸缩性：关系数据库很难实现横向扩展，纵向扩展的空间也比较有限。相反，HBase和BigTable这些分布式数据库就是为了实现灵活的水平扩展而开发的，能够轻易地通过在集群中增加或者减少硬件数量来实现性能的伸缩

3.4.2.3HBASE是面向列的存储

传统的数据库是关系型的，且是按行来存储的。如下图：

其中只有张三把一行数据填满了，李四王五赵六的行都没有填满。因为这里的行结构是固定的，每一行都一样，即使你不用，也必须空到那里，而不能没有。

列式存储

为了与传统的区别，新型数据库叫做非关系型数据库，是按列来存储的。如下图：

行存与列存的转换：

原来张三的一列（单元格）数据对应现在张三的一行数据。原来张三的六列数据变成了现在的六行。

原来的六列数据是在一行，所以共用一个主键（即张三）。现在变成了六行，每行都需要一个主键（不然不知道这行数据是谁的），所以原来的主键（即张三）重复了六次。如下图：

行列对比

① 行式存储倾向于结构固定，列式存储倾向于结构弱化。

（行式存储相当于套餐，即使一个人来了也给你上八菜一汤，造成浪费；列式存储相等于自助餐，按需自取，人少了也不浪费）

② 行式存储一行数据只需一份主键，列式存储一行数据需要多份主键。

③ 行式存储存的都是业务数据，列式存储除了业务数据外，还要存储列名。

④ 行式存储更像一个Java Bean，所有字段都提前定义好，且不能改变；列式存储更像一个Map，不提前定义，随意往里添加key/value。

3.4.2.4HBase数据模型

3.4.2.4.1概述

HBase是一个稀疏、多维度、排序的映射表，这张表的索引是行键、列族、列限定符和时间戳
每个值是一个未经解释的字符串，没有数据类型
用户在表中存储数据，每一行都有一个可排序的行键和任意多的列
表在水平方向由一个或者多个列族组成，一个列族中可以包含任意多个列，同一个列族里面的数据存储在一起
列族支持动态扩展，可以很轻松地添加一个列族或列，无需预先定义列的数量以及类型，所有列均以字符串形式存储，用户需要自行进行数据类型转换
HBase中执行更新操作时，并不会删除数据旧的版本，而是生成一个新的版本，旧有的版本仍然保留（这是和HDFS只允许追加不允许修改的特性相关的）

3.4.2.4.2相关概念

表：HBase采用表来组织数据，表由行和列组成，列划分为若干个列族
行：每个HBase表都由若干行组成，每个行由行键（row key）来标识。
列族：一个HBase表被分组成许多“列族”（Column Family）的集合，它是基本的访问控制单元
列限定符：列族里的数据通过列限定符（或列）来定位
单元格：在HBase表中，通过行、列族和列限定符确定一个“单元格”（cell），单元格中存储的数据没有数据类型，总被视为字节数组byte[]
时间戳：每个单元格都保存着同一份数据的多个版本，这些版本采用时间戳进行索引

3.4.2.4.3数据模型实例

3.4.2.4.4数据坐标

HBase中需要根据行键、列族、列限定符和时间戳来确定一个单元格，因此，可以视为一个“四维坐标”，即[行键, 列族, 列限定符, 时间戳]

3.4.2.4.5HBase数据的概念视图和物理视图

概念视图

物理视图—按列族进行物理存储

列族contents

列族anchor

3.4.2.5HBASE的实现原理

3.4.2.5.1 HBase功能组件

HBase各功能组建及其作用

（1）库函数：链接到每个客户端；

（2）一个Master主服务器：主服务器Master主要负责表和Region的管理工作；

（3）许多个Region服务器：Region服务器是HBase中最核心的模块，负责维护分配给自己的Region，并响应用户的读写请求

3.4.2.5.2数据分区机制。

HBase采用分区存储，一个大的表会被分拆许多个Region，这些Region会被分发到不同的服务器上实现分布式存储。

3.4.2.5.3HBase中的分区定位

通过构建的映射表的每个条目包含两项内容，一个是Regionde 标识符，另一个是Region服务器标识，这个条目就标识Region和Region服务器之间的对应关系，从而就可以知道某个Region被保存在哪个Region服务器中。

3.4.2.6HBASE的运行机制

3.4.2.6.1HBase系统基本架构以及每个组成部分的作用。

（1）客户端

客户端包含访问HBase的接口，同时在缓存中维护着已经访问过的Region位置信息，用来加快后续数据访问过程

（2）Zookeeper服务器

Zookeeper可以帮助选举出一个Master作为集群的总管，并保证在任何时刻总有唯一一个Master在运行，这就避免了Master的“单点失效”问题

（3）Master

主服务器Master主要负责表和Region的管理工作：管理用户对表的增加、删除、修改、查询等操作；实现不同Region服务器之间的负载均衡；在Region分裂或合并后，负责重新调整Region的分布；对发生故障失效的Region服务器上的Region进行迁移

（4）Region服务器

Region服务器是HBase中最核心的模块，负责维护分配给自己的Region，并响应用户的读写请求

3.4.2.6.2Region服务器向HDFS文件系统中读写数据的基本原理

Region服务器内部管理一系列Region对象和一个HLog文件，其中，HLog是磁盘上面的记录文件，它记录着所有的更新操作。

每个Region对象又是由多个Store组成的，每个Store对象了表中的一个列族的存储。

每个Store又包含了MemStore和若干个StoreFile，其中，MemStore是在内存中的缓存。

HStore的工作原理

每个Store对应了表中的一个列族的存储。每个Store包括一个MenStore缓存和若干个StoreFile文件。MenStore是排序的内存缓冲区，当用户写入数据时，系统首先把数据放入MenStore缓存，当MemStore缓存满时，就会刷新到磁盘中的一个StoreFile文件中，当单个StoreFile文件大小超过一定阈值时，就会触发文件分裂操作。

HLog的工作原理

答：HBase系统为每个Region服务器配置了一个HLog文件，它是一种预写式日志（Write Ahead Log），用户更新数据必须首先写入日志后，才能写入MemStore缓存，并且，直到MemStore缓存内容对应的日志已经写入磁盘，该缓存内容才能被刷写到磁盘。

3.5 云数据库

3.5.1云数据库的概念

云数据库是部署和虚拟化在云计算环境中的数据库。

云数据库是在云计算的大背景下发展起来的一种新兴的共享基础架构的方法，它极大地增强了数据库的存储能力，消除了人员、硬件、软件的重复配置，让软、硬件升级变得更加容易，同时，也虚拟化了许多后端功能。

云数据库具有高可扩展性、高可用性、采用多租形式和支持资源有效分发等特点。

3.5.2云计算模式的优势

3.5.3云数据库特性

动态可扩展
高可用性
较低的使用代价
易用性
高性能
免维护
安全

3.5.4 云数据库厂商及其代表性产品

数据库供应商主要分为三类。

传统的数据库厂商，如Teradata、Oracle、IBM DB2和Microsoft SQL Server等。
涉足数据库市场的云供应商，如Amazon、Google.Yahoo!、阿里、百度、腾讯等。
新兴厂商，如IVertica.LongJump 和EnterpriseDB等。