来自： http://my.oschina.net/lwhmdj0823/blog/617726

大数据存储方案

Cap思想

  分布式领域CAP理论，
Consistency(一致性), 数据一致更新，所有数据变动都是同步的
Availability(可用性), 好的响应性能
Partition tolerance(分区容错性) 可靠性
定理：任何分布式系统只可同时满足二点，没法三者兼顾。
忠告：架构师不要将精力浪费在如何设计能满足三者的完美分布式系统，而是应该进行取舍。
关系数据库的ACID模型拥有 高一致性 + 可用性 很难进行分区：
Atomicity原子性：一个事务中所有操作都必须全部完成，要么全部不完成。
Consistency一致性. 在事务开始或结束时，数据库应该在一致状态。
Isolation隔离层. 事务将假定只有它自己在操作数据库，彼此不知晓。
Durability. 一旦事务完成，就不能返回。
跨 数据库事务：2PC (two-phase commit)， 2PC is the anti-scalability pattern (Pat Helland) 是反可伸缩模式的，JavaEE中的JTA事务可以支持2PC。因为2PC是反模式，尽量不要使用2PC，使用BASE来回避。

 

BASE思想

  BASE模型反ACID模型，完全不同ACID模型，牺牲高一致性，获得可用性或可靠性：
Basically Available基本可用。支持分区失败(e.g. sharding碎片划分数据库)
Soft state软状态 状态可以有一段时间不同步，异步。
Eventually consistent最终一致，最终数据是一致的就可以了，而不是时时高一致。

BASE思想的主要实现有
1.按功能划分数据库
2.sharding碎片 

BASE思想主要强调基本的可用性，如果你需要High 可用性，也就是纯粹的高性能，那么就要以一致性或容错性为牺牲，BASE思想的方案在性能上还是有潜力可挖的。

现在NoSQL运动丰富了拓展了BASE思想，可按照具体情况定制特别方案，比如忽视一致性，获得高可用性等等，NOSQL应该有下面两个流派：
1. Key-Value存储，如Amaze Dynamo等，可根据CAP三原则灵活选择不同倾向的数据库产品。
2. 领域模型 + 分布式缓存 + 存储 （Qi4j和NoSQL运动），可根据CAP三原则结合自己项目定制灵活的分布式方案，难度高。

这两者共同点：都是关系数据库SQL以外的可选方案，逻辑随着数据分布，任何模型都可以自己持久化，将数据处理和数据存储分离，将读和写分离，存储可以是异步或同步，取决于对一致性的要求程度。

不同点：NOSQL之类的Key-Value存储产品是和关系数据库头碰头的产品BOX，可以适合非Java如PHP RUBY等领域，是一种可以拿来就用的产品，而领域模型 + 分布式缓存 + 存储是一种复杂的架构解决方案，不是产品，但这种方式更灵活，更应该是架构师必须掌握的。_x000B_

 

由于业务数据量的爆炸式增长从而导致了存储成本的不断上涨，同时加大了存储管理的难度，目前我们公司大数据架构采用结构化、非结构化数据库、（Nosql），HDFS分布式文件系统相结合的存储结构模式进行数据的存储工作，且存储结构均采用集群化的方式进行存储从而保证数据的安全、稳定性、易于扩展、大数据量高性能、灵活的数据模型。

1.系统大致存储图为：

2.大数据存储特点：

  2.1易扩展性：NoSQL

数据库种类繁多，但是一个共同的特点都是去掉关系数据库的关系型特性。数据之间无关系，这样就非常容易扩展。也无形之间，在架构的层面上带来了可扩展的能力。

  2.2大数据量，高性能：NoSQL

数据库都具有非常高的读写性能，尤其在大数据量下，同样表现优秀。这得益于它的无关系性，数据库的结构简单。一般MySQL使用 Query Cache，每次表的更新Cache

就失效，是一种大粒度的Cache，在针对web2.0的交互频繁的应用，Cache性能不高。而NoSQL的 Cache

是记录级的，是一种细粒度的Cache，所以NoSQL在这个层面上来说就要性能高很多了。

  2.3灵活的数据模型：NoSQL

无需事先为要存储的数据建立字段，随时可以存储自定义的数据格式。而

在关系数据库里，增删字段是一件非常麻烦的事情。如果是非常大数据量的表，增加字段简直就是一个噩梦。这点在大数据量的web2.0时代

非结构数据库的备份：

3.HBase介绍

 3.1 HBase架构介绍

 

3.1.1 Hbase基本组件说明：

3.1.1.1 Client

ü包含访问HBase的接口，并维护cache来加快对HBase的访问，比如region的位置信息

3.1.1.2 Master

ü为Region server分配region

ü负责Region server的负载均衡

ü发现失效的Region server并重新分配其上的region

ü管理用户对table的增删改查操作

3.1.1.3 Region Server

üRegionserver维护region，处理对这些region的IO请求

üRegionserver负责切分在运行过程中变得过大的region

3.1.1.4 Zookeeper作用

ü通过选举，保证任何时候，集群中只有一个master，Master与RegionServers 启动时会向ZooKeeper注册

ü存贮所有Region的寻址入口

ü实时监控Region server的上线和下线信息。并实时通知给Master

ü存储HBase的schema和table元数据

ü默认情况下，HBase 管理ZooKeeper 实例，比如， 启动或者停止ZooKeeper

üZookeeper的引入使得Master不再是单点故障

 

   3.1.1.5 Write-Ahead-Log（WAL）

该机制用于数据的容错和恢复：

每 个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，完成数据恢复。

   3.1.1.6 HBase容错性

Master容错：Zookeeper重新选择一个新的Master
ü无Master过程中，数据读取仍照常进行；
ü无master过程中，region切分、负载均衡等无法进行；
RegionServer容错：定时向Zookeeper汇报心跳，如果一旦时间内未出现心跳，Master将该RegionServer上的Region重新分配到其他RegionServer上，失效服务器上“预写”日志由主服务器进行分割并派送给新的RegionServer
Zookeeper容错：Zookeeper是一个可靠地服务，一般配置3或5个Zookeeper实例
Region定位流程：

寻找RegionServer

ZooKeeper--> -ROOT-(单Region)--> .META.--> 用户表

-ROOT-
ü表包含.META.表所在的region列表，该表只会有一个Region；

üZookeeper中记录了-ROOT-表的location。

.META.

ü表包含所有的用户空间region列表，以及RegionServer的服务器地址。

   3.1.1.7 Hbase使用场景

storing large amounts  of data(100s of TBs)
need high write throughput
need efficient random access(key lookups) within large data sets
need to scale gracefully with data
for structured and semi-structured data
don't need fullRDMS capabilities(cross row/cross table transaction, joins,etc.)

大数据量存储，大数据量高并发操作

需要对数据随机读写操作

读写访问均是非常简单的操作

 

 

 

 3.1.2 Hbase介绍

   3.1.2.1 HBase基本概念

RowKey：

是Byte array，是表中每条记录的“主键”，方便快速查找，Rowkey的设计非常重要。
Column Family：

  列族，拥有一个名称(string)，包含一个或者多个相关列
Column：

 属于某一个columnfamily，familyName:columnName，每条记录可动态添加
Version Number：

  类型为Long，默认值是系统时间戳，可由用户自定义
Value(Cell)：

 Byte array

   3.1.2.2 HBase介绍

HBase是一个构建在HDFS上的分布式列存储系统；
HBase是基于Google BigTable模型开发的，典型的key/value系统；
HBase是Apache Hadoop生态系统中的重要一员，主要用于海量结构化数据存储；
   从逻辑上讲，HBase将数据按照表、行和列进行存储。
与hadoop一样，Hbase目标主要依靠横向扩展，通过不断增加廉价的商用服务器，来增加计算和存储能力

 3.1.3 HBase特点

Ø 大：一个表可以有数十亿行，上百万列；

Ø 无模式：每行都有一个可排序的主键和任意多的列，列可以根据需要动态的增加，同一张表中不同的行可以有截然不同的列；

Ø 面向列：面向列（族）的存储和权限控制，列（族）独立检索；

Ø 稀疏：空（null）列并不占用存储空间，表可以设计的非常稀疏；

Ø 数据多版本：每个单元中的数据可以有多个版本，默认情况下版本号自动分配，是单元格插入时的时间戳；
数据类型单一：Hbase中的数据都是字符串，没有类型。

 3.1.5 HBase数据类型

 3.1.4 HBase物理模型

每个column family存储在HDFS上的一个单独文件中，空值不会被保存。
Key 和 Version number在每个 column family中均有一份；
HBase 为每个值维护了多级索引，即：<key, column family, column name, timestamp>

物理存储:
1、Table中所有行都按照row key的字典序排列；
2、Table在行的方向上分割为多个Region；
3、Region按大小分割的，每个表开始只有一个region，随着数据增多，region不断增大，当增大到一个阀值的时候，region就会等分会两个新的region，之后会有越来越多的region；
4、Region是Hbase中分布式存储和负载均衡的最小单元，不同Region分布到不同RegionServer上。

 

5、Region虽然是分布式存储的最小单元，但并不是存储的最小单元。Region由一个或者多个Store组成，每个store保存一个columns family；每个Strore又由一个memStore和0至多个StoreFile组成，StoreFile包含HFile；memStore存储在 内存中，StoreFile存储在HDFS上。

 3.2 HBase原理

 3.3 HBase复制（HBase Relication）

   HBase复制是另外一个负载较轻的备份工具。文章《HBase复制概述》有对它的详细描述。总的来说，赋值被定义为列簇级别，可以工作在后台并且保证所有的编辑操作在集群复制链之间的同步。

复制有三种模式：主->从(master->slave)，主<->主(master<->master)和循环（cyclic）。这种方法给你灵活的从任意数据中心获取数据并且确保它能获得在其他数据中心的所有副本。在一个数据中心发生灾难性故障的情况下，客户端应用程序可以利用DNS工具，重定向到另外一个备用位置。

复制是一个强大的，容错的过程。它提供了“最终一致性”，意味着在任何时刻，最近对一个表的编辑可能无法应用到该表的所有副本，但是最终能够确保一致。

注：对于一个存在的表，你需要通过本文描述的其他方法，手工的拷贝源表到目的表。复制仅仅在你启动它之后才对新的写/编辑操作有效。

表2 集群复制架构图

 3.4导出（Export）

   HBase的导出工具是一个内置的实用功能，它使数据很容易从hbase表导入HDFS目录下的SequenceFiles文件。它创造了一个 map reduce任务，通过一系列HBase API来调用集群，获取指定表格的每一行数据，并且将数据写入指定的HDFS目录中。这个工具对集群来讲是性能密集的，因为它使用了mapreduce和 HBase 客户端API。但是它的功能丰富，支持制定版本或日期范围，支持数据的筛选，从而使增量备份可用。

下面是一个导出命令的简单例子：

1. hbase org.apache.hadoop.hbase.mapreduce.Export <tablename> <outputdir>  

一旦你的表导出了，你就可以复制生成的数据文件到你想存储的任何地方（比如异地/离线集群存储）。你可以执行一个远程的HDFS集群/目录作为命令的输出目录参数，这样数据将会直接被导出到远程集群。使用这个方法需要网络，所以你应该确保到远程集群的网络连接是否可靠以及快速。

 3.5拷贝表（CopyTable）

    拷贝表功能在文章《使用CopyTable在线备份HBase》中有详细描述，但是这里做了基本的总结。和导出功能类似，拷贝表也使用HBase API创建了一个mapreduce任务，以便从源表读取数据。不同的地方是拷贝表的输出是hbase中的另一个表，这个表可以在本地集群，也可以在远程集群。

一个简单的例子如下：

1. hbase org.apache.hadoop.hbase.mapreduce.CopyTable --new.name=testCopy test  

这个命令将会拷贝名为test的表到集群中的另外一个表testCopy。

请注意，这里有一个明显的性能开销，它使用独立的“puts”操作来逐行的写入数据到目的表。如果你的表非常大，拷贝表将会导致目标region server上的memstore被填满，会引起flush操作并最终导致合并操作的产生，会有垃圾收集操作等等。

此外，你必须考虑到在HBase上运行mapreduce任务所带来的性能影响。对于大型的数据集，这种方法的效果可能不太理想。

 3.6 HBase API（比如作为一个java应用）

   由于总是这样使用hadoop，你可以使用公用的api写自己定制的客户端应用程序来直接查询表格。你也可以通过mapreduce任务的批量处理优势，或者自己设计的其他手段。然而，这个方法需要对hadoop开发以及因此对生产集群带来的影响有深入的理解。

离线备份原生的HDFS数据（Offline Backup of Raw HDFS Data）

最强力的备份机制，也是破坏性最大的一个。涉及到最大的数据占用空间。你可以干净的关闭你的HBase集群并且手工的在HDFS上拷贝数据。因为 HBase已经关闭，所以能确保所有的数据已经被持久化到HDFS上的HFile文件中，你也将能获得一个最准确的数据副本。但是，增量的数据几乎不能再获得，你将无法确定哪些数据发生了变化。

   同时也需要注意，恢复你的数据将需要一个离线的元数据因为.META.表将包含在修复时可能无效的信息。这种方法需要一个快速的，可信赖的网络来传输异地的数据，如果需要在稍后恢复它的话。

由于这些原因，Cloudera非常不鼓励在HBase中这种备份方法。

 3.7 故障恢复（Disaster Recory）

   HBase被设计为一个非常能容忍错误的分布式系统，假设硬件失败很频繁。在HBase中的故障恢复通常有以下几种形式：

· 在数据中心级别的灾难性故障，需要切换到备份位置；

· 需要恢复由于用户错误或者意外删除的数据的之前一个拷贝；

· 出于审计目的，恢复实时点数据拷贝的能力

正如其他的故障恢复计划，业务需要驱动这你如何架构并且投入多少金钱。一旦你确定了你将要选择的备份方案，恢复将有以下几种类型：

· 故障转移到备份集群

· 导入表/恢复快照

· 指向HBase在备份位置的根目录

   如果你的备份策略是这样的，你复制你的HBase数据在不同数据中心的备份集群，故障转移将变得简单，仅需要使用DNS技术，转移你的应用程序。

   请记住，如果你打算允许数据在停运时写入你的备份集群，那你需要确保在停运结束后，数据可以回到主机群。主<->主或循环的复制架构能自动处理这个过程，但对于一个主从结构来讲，你就需要手动进行干预了。

   你也可以在故障时通过简单的修改hbase-site.xml的 hbase.root.dir属性来更改hbase根目录，但是这是最不理想的还原选项，因为你复制完数据返回生产集群时，正如之前提到的，可能会发现.META是不同步的。

 

 4.  HDFS介绍

 4.1 HDFS架构介绍

 

如上图所示，HDFS也是按照Master和Slave的结构。分NameNode、SecondaryNameNode、DataNode这几个角色。

NameNode：是Master节点，是大领导。管理数据块映射；处理客户端的读写请求；配置副本策略；管理HDFS的名称空间；

SecondaryNameNode：是一个小弟，分担大哥namenode的工作量；是NameNode的冷备份；合并fsimage和fsedits然后再发给namenode。

DataNode：Slave节点，奴隶，干活的。负责存储client发来的数据块block；执行数据块的读写操作。

热备份：b是a的热备份，如果a坏掉。那么b马上运行代替a的工作。

冷备份：b是a的冷备份，如果a坏掉。那么b不能马上代替a工作。但是b上存储a的一些信息，减少a坏掉之后的损失。

fsimage:元数据镜像文件（文件系统的目录树。）

edits：元数据的操作日志（针对文件系统做的修改操作记录）

namenode内存中存储的是=fsimage+edits。

SecondaryNameNode负责定时默认1小时，从namenode上，获取fsimage和edits来进行合并，然后再发送给namenode。减少namenode的工作量。

 

  4.1.1 HDFS介绍

HDFS（Hadoop Distributed File System ）Hadoop分布式文件系统。是根据google发表的论文翻版的。论文为GFS（Google File System）Google 文件系统。

  4.1.2 HDFS特点

      ① 保存多个副本，且提供容错机制，副本丢失或宕机自动恢复。默认存3份。

    ② 运行在廉价的机器上。

    ③ 适合大数据的处理。多大？多小？HDFS默认会将文件分割成block，64M为1个block。然后将block按键值对存储在HDFS上，并将键值对的映射存到内存中。如果小文件太多，那内存的负担会很重。

 

 4.2 HDFS原理

4.2.1 写操作

有一个文件FileA，100M大小。Client将FileA写入到HDFS上。

HDFS按默认配置。

HDFS分布在三个机架上Rack1，Rack2，Rack3。

 

a. Client将FileA按64M分块。分成两块，block1和Block2;

b. Client向nameNode发送写数据请求，如图蓝色虚线①------>。

c. NameNode节点，记录block信息。并返回可用的DataNode，如粉色虚线②--------->。

    Block1: host2,host1,host3

    Block2: host7,host8,host4

    原理：

        NameNode具有RackAware机架感知功能，这个可以配置。

        若client为DataNode节点，那存储block时，规则为：副本1，同client的节点上；副本2，不同机架节点上；副本3，同第二个副本机架的另一个节点上；其他副本随机挑选。

        若client不为DataNode节点，那存储block时，规则为：副本1，随机选择一个节点上；副本2，不同副本1，机架上；副本3，同副本2相同的另一个节点上；其他副本随机挑选。

d. client向DataNode发送block1；发送过程是以流式写入。

    流式写入过程，

        1>将64M的block1按64k的package划分;

        2>然后将第一个package发送给host2;

        3>host2接收完后，将第一个package发送给host1，同时client想host2发送第二个package；

        4>host1接收完第一个package后，发送给host3，同时接收host2发来的第二个package。

        5>以此类推，如图红线实线所示，直到将block1发送完毕。

        6>host2,host1,host3向NameNode，host2向Client发送通知，说“消息发送完了”。如图粉红颜色实线所示。

        7>client收到host2发来的消息后，向namenode发送消息，说我写完了。这样就真完成了。如图黄色粗实线

        8>发送完block1后，再向host7，host8，host4发送block2，如图蓝色实线所示。

        9>发送完block2后，host7,host8,host4向NameNode，host7向Client发送通知，如图浅绿色实线所示。

        10>client向NameNode发送消息，说我写完了，如图黄色粗实线。。。这样就完毕了。

分析，通过写过程，我们可以了解到：

    ①写1T文件，我们需要3T的存储，3T的网络流量贷款。

    ②在执行读或写的过程中，NameNode和DataNode通过HeartBeat进行保存通信，确定DataNode活着。如果发现DataNode死掉了，就将死掉的DataNode上的数据，放到其他节点去。读取时，要读其他节点去。

    ③挂掉一个节点，没关系，还有其他节点可以备份；甚至，挂掉某一个机架，也没关系；其他机架上，也有备份。

4.2.2读操作

读操作就简单一些了，如图所示，client要从datanode上，读取FileA。而FileA由block1和block2组成。 

 

那么，读操作流程为：

a. client向namenode发送读请求。

b. namenode查看Metadata信息，返回fileA的block的位置。

    block1:host2,host1,host3

    block2:host7,host8,host4

c. block的位置是有先后顺序的，先读block1，再读block2。而且block1去host2上读取；然后block2，去host7上读取；

 

上面例子中，client位于机架外，那么如果client位于机架内某个DataNode上，例如,client是host6。那么读取的时候，遵循的规律是：

优选读取本机架上的数据。

4.2.3 HDFS常用命令

hadoop fs -ls /

hadoop fs -lsr

hadoop fs -mkdir /user/hadoop

hadoop fs -put a.txt /user/hadoop/

hadoop fs -get /user/hadoop/a.txt /

hadoop fs -cp src dst

hadoop fs -mv src dst

hadoop fs -cat /user/hadoop/a.txt

hadoop fs -rm /user/hadoop/a.txt

hadoop fs -rmr /user/hadoop/a.txt

hadoop fs -text /user/hadoop/a.txt

hadoop fs -copyFromLocal localsrc dst 与hadoop fs -put功能类似。

hadoop fs -moveFromLocal localsrc dst 将本地文件上传到hdfs，同时删除本地文件。

 

hadoop dfsadmin -report

hadoop dfsadmin -safemode enter | leave | get | wait

hadoop dfsadmin -setBalancerBandwidth 1000

 

 

hadoop fsck

start-balancer.sh

5 HDFS与HBase进行比较

Ø 两者都具有良好的容错性和扩展性，都可以扩展到成百上千个节点；

Ø HDFS适合批处理场景

Ø 不支持数据随机查找

Ø 不适合增量数据处理

Ø 不支持数据更新