Hadoop
Hadoop
基础知识
大数据
大数据概念
大数据是指无法在一定时间内用常规软件工具对其内容进行抓取、管理和处理的数据集合。
大数据技术，是指从各种各样类型的数据中，快速获得有价值信息的能力
大数据不仅仅是数据的“大量化”，而是包含“快速化”、“多样化”和“价值化”等多重属性。
数据量大
根据IDC作出的估测，数据一直都在以每年50%的速度增长，也就是说每两年就增长一倍（大数据摩尔定律）
人类在最近两年产生的数据量相当于之前产生的全部数据量
预计到2020年，全球将总共拥有35ZB的数据量，相较于2010年，数据量将增长近30倍。
数据类型繁多
大数据是由结构化和非结构化数据组成的
10%的结构化数据，存储在数据库中
90%的非结构化数据，它们与人类信息密切相关
科学研究
–基因组 –LHC 加速器 –地球与空间探测
企业应用
–Email、文档、文件 –应用日志 –交易记录
Web 1.0数据
–文本 –图像 –视频
Web 2.0数据
–查询日志/点击流 –Twitter/ Blog / SNS –Wiki
处理速度快
从数据的生成到消耗，时间窗口非常小，可用于生成决策的时间非常少
1秒定律：这一点也是和传统的数据挖掘技术有着本质的不同
价值密度低
价值密度低，商业价值高
以视频为例，连续不间断监控过程中，可能有用的数据仅仅有一两秒，但是具有很高的商业价值
关键技术
数据采集
利用ETL工具将分布的、异构数据源中的数据如关系数据、平面数据文件等，抽取到临时中间层后进行清洗、转换、集成，最后加载到数据仓库或数据集市中，成为联机分析处理、数据挖掘的基础；或者也可以把实时采集的数据作为流计算系统的输入，进行实时处理分析
数据存储和管理
利用分布式文件系统、数据仓库、关系数据库、NoSQL数据库、云数据库等，实现对结构化、半结构化和非结构化海量数据的存储和管理
数据处理与分析
利用分布式并行编程模型和计算框架，结合机器学习和数据挖掘算法，实现对海量数据的处理和分析；对分析结果进行可视化呈现，帮助人们更好地理解数据、分析数据
数据隐私和安全
在从大数据中挖掘潜在的巨大商业价值和学术价值的同时，构建隐私数据保护体系和数据安全体系，有效保护个人隐私和数据安全
hadoop与google项目对比
hadoop特性
高可靠性 、 高效性、高可扩展性、高容错性、成本低、运行在Linux平台上、支持多种编程语言
hadoop版本变化
hadoop项目结构
| 组件 | 功能 |
|---|---|
| HDFS | 分布式文件系统 |
| MapReduce | 分布式并行编程模型 |
| YARN | 资源管理和调度器 |
| Tez | 运行在YARN之上的下一代Hadoop查询处理框架 |
| Hive | Hadoop上的数据仓库 |
| HBase | Hadoop上的非关系型的分布式数据库 |
| Pig | 一个基于Hadoop的大规模数据分析平台，提供类似SQL的查询语言Pig Latin |
| Sqoop | 用于在Hadoop与传统数据库之间进行数据传递 |
| Oozie | Hadoop上的工作流管理系统 |
| Zookeeper | 提供分布式协调一致性服务 |
| Storm | 流计算框架 |
| Flume | 一个高可用的，高可靠的，分布式的海量日志采集、聚合和传输的系统 |
| Ambari | Hadoop快速部署工具，支持Apache Hadoop集群的供应、管理和监控 |
| Kafka | 一种高吞吐量的分布式发布订阅消息系统，可以处理消费者规模的网站中的所有动作流数据 |
| Spark | 类似于Hadoop MapReduce的通用并行框架 |
hadoop体系结构
- NameNode：主控制服务器，负责维护文件系统的命名空间（Namespace）并协调客户端对文件的访问，记录命名空间内的任何改动或命名空间本身的属性改动
- DataNode：负责它们所在的物理节点上的存储管理
名称节点
在HDFS中，名称节点（NameNode）负责管理分布式文件系统的命名空间（Namespace），保存了两个核心的数据结构，即FsImage和EditLog
-
FsImage用于维护文件系统树以及文件树中所有的文件和文件夹的元数据
-
操作日志文件EditLog中记录了所有针对文件的创建、删除、重命名等操作
名称节点记录了每个文件中各个块所在的数据节点的位置信息
FsImage文件
fsimage文件其实是Hadoop文件系统元数据的一个永久性的检查点，其中包含Hadoop文件系统中的所有目录和文件idnode的序列化信息；
每个inode是一个文件或目录的元数据的内部表示，并包含此类信息：文件的复制等级、修改和访问时间、访问权限、块大小以及组成文件的块。对于目录，则存储修改时间、权限和配额元数据。
Editlog文件或Edits文件
editlog主要是在NameNode已经启动情况下对HDFS进行的各种更新操作进行记录，HDFS客户端执行所有的写操作都会被记录到editlog中。
edits文件存放的是Hadoop文件系统的所有更新操作的路径，文件系统客户端执行的所有写操作首先会被记录到edits文件中。
名称节点的启动
在名称节点启动的时候，它会将FsImage文件中的内容加载到内存中，之后再执行EditLog文件中的各项操作，使得内存中的元数据和实际的同步，存在内存中的元数据支持客户端的读操作。
一旦在内存中成功建立文件系统元数据的映射，则创建一个新的FsImage文件和一个空的EditLog文件
名称节点起来之后，HDFS中的更新操作会重新写到EditLog文件中，因为FsImage文件一般都很大（GB级别的很常见），如果所有的更新操作都往FsImage文件中添加，这样会导致系统运行的十分缓慢，但是，如果往EditLog文件里面写就不会这样，因为EditLog 要小很多。每次执行写操作之后，且在向客户端发送成功代码之前，edits文件都需要同步更新。
名称节点运行期间EditLog不断变大的问题
在名称节点运行期间，HDFS的所有更新操作都是直接写到EditLog中，久而久之， EditLog文件将会变得很大
虽然这对名称节点运行时候是没有什么明显影响的，但是，当名称节点重启的时候，名称节点需要先将FsImage里面的所有内容映像到内存中，然后再一条一条地执行EditLog中的记录，当EditLog文件非常大的时候，会导致名称节点启动操作非常慢，而在这段时间内HDFS系统处于安全模式，一直无法对外提供写操作，影响了用户的使用
如何解决？答案是：SecondaryNameNode第二名称节点
SecondaryNameNode
第二名称节点是HDFS架构中的一个组成部分，它是用来保存名称节点中对HDFS 元数据信息的备份，并减少名称节点重启的时间。SecondaryNameNode一般是单独运行在一台机器上。
流程
第一步：将hdfs更新记录写入一个新的文件 edits.new。
第二步：将fsimage和editlog通过http协议发送至secondary namenode。
第三步：将fsimage与editlog合并，生成一个新的文件fsimage.ckpt。这步之所以要在secondary namenode中进行，是因为比较耗时，如果在namenode中进行，或导致整个系统卡顿。
第四步：将生成的fsimage.ckpt通过http协议发送至namenode。
第五步：重命名fsimage.ckpt为fsimage，edits.new为edits。
secondary namenode会周期性合并fsimage和edits成新的fsimage，新的操作记录会写入新的editlog中，这个周期可以自己设置。
数据节点（DataNode）
数据节点是分布式文件系统HDFS的工作节点，负责数据的存储和读取，会根据客户端或者是名称节点的调度来进行数据的存储和检索，并且向名称节点定期发送自己所存储的块的列表。
每个数据节点中的数据会被保存在各自节点的本地Linux文件系统中。
块（block）
- DataNode在存储数据的时候是按照block为单位读写数据，block是hdfs读写数据的基本单位。
- HDFS默认一个块64MB，一个文件被分成多个块。
块（block）带来的好处：
- 支持大规模文件存储：文件以块为单位进行存储，一个大规模文件可以被分拆成若干个文件块，不同的文件块可以被分发到不同的节点上，因此，一个文件的大小不会受到单个节点的存储容量的限制，可以远远大于网络中任意节点的存储容量
- 简化系统设计：首先，大大简化了存储管理，因为文件块大小是固定的，这样就可以很容易计算出一个节点可以存储多少文件块；其次，方便了元数据的管理，元数据不需要和文件块一起存储，可以由其他系统负责管理元数据
- 适合数据备份：每个文件块都可以冗余存储到多个节点上，大大提高了系统的容错性和可用性
块的结构
一个数据块在DATANode以文件形式存储，包括两个文件
- 数据本身
- 元数据 包括数据块的长度、块数据的校验和、时间戳
通信协议
-
所有的HDFS通信协议都是构建在TCP/IP协议基础之上的
-
客户端与数据节点的交互是通过RPC（Remote Procedure Call）来实现的。在设计上，名称节点不会主动发起RPC，而是响应来自客户端和数据节点的RPC请求
HDFS
HDFS存储原理
冗余数据保存 数据存取策略 数据错误与恢复
冗余数据保存
作为一个分布式文件系统，为了保证系统的容错性和可用性，HDFS采用了多副本方式对数据进行冗余存储，通常一个数据块的多个副本会被分布到不同的数据节点上，这种多副本方式具有以下几个优点：
（1）加快数据传输速度 2）容易检查数据错误 （3）保证数据可靠性
数据存取策略
-
数据存放
第一个副本：放置在上传文件的数据节点；如果是集群外提交，则随机挑选一台磁盘不太满、CPU不太忙的节点
第二个副本：放置在与第一个副本不同的机架的节点上
第三个副本：与第一个副本相同机架的其他节点上
更多副本：随机节点 -
数据读取
HDFS提供了一个API可以确定一个数据节点所属的机架ID，客户端也可以调用API获取自己所属的机架ID
当客户端读取数据时，从名称节点获得数据块不同副本的存放位置列表，列表中包含了副本所在的数据节点，可以调用API来确定客户端和这些数据节点所属的机架ID，当发现某个数据块副本对应的机架ID和客户端对应的机架ID相同时，就优先选择该副本读取数据，如果没有发现，就随机选择一个副本读取数据
数据错误与恢复
HDFS具有较高的容错性，可以兼容廉价的硬件，它把硬件出错看作一种常态，而不是异常，并设计了相应的机制检测数据错误和进行自动恢复，主要包括以下几种情形：
（1）名称节点出错（2）数据节点出错（3）数据出错。
-
名称节点出错
名称节点保存了所有的元数据信息，其中，最核心的两大数据结构是FsImage和Editlog，如果这两个文件发生损坏，那么整个HDFS实例将失效。因此，HDFS设置了备份机制，把这些核心文件同步复制到备份服务器SecondaryNameNode上。当名称节点出错时，就可以根据备份服务器SecondaryNameNode中的FsImage和Editlog数据进行恢复。 -
数据节点出错
每个数据节点会定期向名称节点发送“心跳”信息，向名称节点报告自己的状态
当数据节点发生故障，或者网络发生断网时，名称节点就无法收到来自一些数据节点的心跳信息，这时，这些数据节点就会被标记为“宕机”，节点上面的所有数据都会被标记为“不可读”，名称节点不会再给它们发送任何I/O请求
这时，有可能出现一种情形，即由于一些数据节点的不可用，会导致一些数据块的副本数量小于冗余因子
名称节点会定期检查这种情况，一旦发现某个数据块的副本数量小于冗余因子，就会启动数据冗余复制，为它生成新的副本
HDFS和其它分布式文件系统的最大区别就是可以调整冗余数据的位置 -
数据出错
网络传输和磁盘错误等因素，都会造成数据错误
客户端在读取到数据后，会采用md5和sha1对数据块进行校验，以确定读取到正确的数据
在文件被创建时，客户端就会对每一个文件块进行信息摘录，并把这些信息写入到同一个路径的隐藏文件里面
当客户端读取文件的时候，会先读取该信息文件，然后，利用该信息文件对每个读取的数据块进行校验，如果校验出错，客户端就会请求到另外一个数据节点读取该文件块，并且向名称节点报告这个文件块有错误，名称节点会定期检查并且重新复制这个块
保障可靠性的措施
1．冗余备份
每个文件存储成一系列数据块（Block），默认块大小为64MB（可配置）。为了容错，文件的所有数据块都会有副本（副本数量即复制因子，可配置）
2．副本存放
采用机架感知（Rack-aware）的策略来改进数据的可靠性、可用性和网络带宽的利用率
3.心跳检测
NameNode周期性地从集群中的每个DataNode接受心跳包和块报告，收到心跳包说明该DataNode工作正常
4.安全模式
系统启动时，NameNode会进入一个安全模式。此时不会出现数据块的写操作
5.数据完整性检测
HDFS客户端软件实现了对HDFS文件内容的校验和（Checksum）检查
6.空间回收
文件被用户或应用程序删除时，先把它移动到/trash目录里；只要还在这个目录里，文件就可以被迅速恢复
7.元数据磁盘失效
NameNode可以配置为支持维护映像文件和事务日志的多个副本，任何对映像文件或事务日志的修改，都将同步到它们的副本上
8.快照
快照支持存储某个时间的数据复制，当HDFS数据损坏时，可以回滚到过去一个已知正确的时间点。HDFS目前还不支持快照功能
提升性能的措施
副本选择
HDFS会尽量使用离程序最近的副本来满足用户请求，这样可以减少总带宽消耗和读延时
负载均衡
HDFS的架构支持数据均衡策略
客户端缓存
HDFS客户端先把数据缓存到本地的一个临时文件，程序的写操作透明地重定向到这个临时文件
流水线复制
DataNode从前一个节点接收数据的同时，即时把数据传给后面的节点，这就是流水线复制
Hbase
简介
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作为对应。
体系结构
HBase位于结构化存储层，Hadoop HDFS为HBase提供了高可靠性的底层存储支持，Hadoop MapReduce为HBase提供了高性能的计算能力，Zookeeper为HBase提供了稳定服务和failover（失效备援）机制。
此外，Pig和Hive还为HBase提供了高层语言支持，使得在HBase上进行数据统计处理变的非常简单。 Sqoop则为HBase提供了方便的RDBMS数据导入功能，使得传统数据库数据向HBase中迁移变的非常方便。
HBase和BigTable的底层技术对应关系
| BigTable | Hbase | |
|---|---|---|
| 文件存储系统 | GFS | HDFS |
| 海量数据处理 | MapReduce | Hadoop MapReduce |
| 协同服务管理 | Chubby | Zookeeper |
关系数据库已经流行很多年，并且Hadoop已经有了HDFS和MapReduce，为什么需要HBase?
Hadoop可以很好地解决大规模数据的离线批量处理问题，但是，受限于Hadoop MapReduce编程框架的高延迟数据处理机制，使得Hadoop无法满足大规模数据实时处理应用的需求
HDFS面向批量访问模式，不是随机访问模式
传统的通用关系型数据库无法应对在数据规模剧增时导致的系统扩展性和性能问题（分库分表也不能很好解决）
传统关系数据库在数据结构变化时一般需要停机维护；空列浪费存储空间
因此，业界出现了一类面向半结构化数据存储和处理的高可扩展、低写入/查询延迟的系统，例如，键值数据库、文档数据库和列族数据库（如BigTable和HBase等）
HBase已经成功应用于互联网服务领域和传统行业的众多在线式数据分析处理系统中
HBase与传统的关系数据库的区别主要体现在以下几个方面：
（1）数据类型：关系数据库采用关系模型，具有丰富的数据类型和存储方式，HBase则采用了更加简单的数据模型，它把数据存储为未经解释的字符串
（2）数据操作：关系数据库中包含了丰富的操作，其中会涉及复杂的多表连接。HBase操作则不存在复杂的表与表之间的关系，只有简单的插入、查询、删除、清空等，因为HBase在设计上就避免了复杂的表和表之间的关系
（3）存储模式：关系数据库是基于行模式存储的。HBase是基于列存储的，每个列族都由几个文件保存，不同列族的文件是分离的。
（4）数据索引：关系数据库通常可以针对不同列构建复杂的多个索引，以提高数据访问性能。HBase只有一个索引——行键，通过巧妙的设计，HBase中的所有访问方法，或者通过行键访问，或者通过行键扫描，从而使得整个系统不会慢下来
（5）数据维护：在关系数据库中，更新操作会用最新的当前值去替换记录中原来的旧值，旧值被覆盖后就不会存在。而在HBase中执行更新操作时，并不会删除数据旧的版本，而是生成一个新的版本，旧有的版本仍然保留
（6）可伸缩性：关系数据库很难实现横向扩展，纵向扩展的空间也比较有限。相反，HBase和BigTable这些分布式数据库就是为了实现灵活的水平扩展而开发的，能够轻易地通过在集群中增加或者减少硬件数量来实现性能的伸缩
访问接口
| 类型 | 特点 | 场合 |
|---|---|---|
| Native Java API | 最常规和高效的访问方式 | 适合Hadoop MapReduce作业并行批处理HBase表数据 |
| HBase Shell | HBase的命令行工具，最简单的接口 | 适合HBase管理使用 |
| Thrift Gateway | 利用Thrift序列化技术，支持C++、PHP、Python等多种语言 | 适合其他异构系统在线访问HBase表数据 |
| REST Gateway | 解除了语言限制 | 支持REST风格的Http API访问HBase |
| Pig | 使用Pig Latin流式编程语言来处理HBase中的数据 | 适合做数据统计 |
| Hive | 简单 | 当需要以类似SQL语言方式来访问HBase的时候 |
数据模型概述
HBase是一个稀疏、多维度、排序的映射表，这张表的索引是行键、列族、列限定符和时间戳
每个值是一个未经解释的字符串，没有数据类型
用户在表中存储数据，每一行都有一个可排序的行键和任意多的列
表在水平方向由一个或者多个列族组成，一个列族中可以包含任意多个列，同一个列族里面的数据存储在一起
列族支持动态扩展，可以很轻松地添加一个列族或列，无需预先定义列的数量以及类型，所有列均以字符串形式存储，用户需要自行进行数据类型转换
HBase中执行更新操作时，并不会删除数据旧的版本，而是生成一个新的版本，旧有的版本仍然保留（这是和HDFS只允许追加不允许修改的特性相关的）
数据模型相关概念
表：HBase采用表来组织数据，表由行和列组成，列划分为若干个列族
行：每个HBase表都由若干行组成，每个行由行键（row key）来标识。
列族：一个HBase表被分组成许多“列族”（Column Family）的集合，它是基本的访问控制单元
列限定符：列族里的数据通过列限定符（或列）来定位
单元格：在HBase表中，通过行、列族和列限定符确定一个“单元格”（cell），单元格中存储的数据没有数据类型，总被视为字节数组byte[]
时间戳：每个单元格都保存着同一份数据的多个版本，这些版本采用时间戳进行索引
数据坐标
HBase的实现原理
1 HBase功能组件
2 表和Region
3 Region的定位
HBase功能组件
HBase的实现包括三个主要的功能组件：
（1）库函数：链接到每个客户端
（2）一个Master主服务器
（3）许多个Region服务器
主服务器Master负责管理和维护HBase表的分区信息，维护Region服务器列表，分配Region，负载均衡
Region服务器负责存储和维护分配给自己的Region，处理来自客户端的读写请求
客户端并不是直接从Master主服务器上读取数据，而是在获得Region的存储位置信息后，直接从Region服务器上读取数据
客户端并不依赖Master，而是通过Zookeeper来获得Region位置信息，大多数客户端甚至从来不和Master通信，这种设计方式使得Master负载很小
表和Region
开始只有一个Region，后来不断分裂
Region拆分操作非常快，接近瞬间，因为拆分之后的Region读取的仍然是原存储文件，直到“合并”过程把存储文件异步地写到独立的文件之后，才会读取新文件
Region的定位
元数据表，又名.META.表，存储了Region和Region服务器的映射关系
当HBase表很大时， .META.表也会被分裂成多个Region
根数据表，又名-ROOT-表，记录所有元数据的具体位置
-ROOT-表只有唯一一个Region，名字是在程序中被写死的
Zookeeper文件记录了-ROOT-表的位置
HBase的三层结构中各层次的名称和作用
| 层次 | 名称 | 作用 |
|---|---|---|
| 第一层 | Zookeeper文件 | 记录了-ROOT-表的位置信息 |
| 第二层 | -ROOT-表 | 记录了.META.表的Region位置信息 -ROOT-表只能有一个Region。通过-ROOT-表，就可以访问.META.表中的数据 |
| 第三层 | .META.表 | 记录了用户数据表的Region位置信息，.META.表可以有多个Region，保存了HBase中所有用户数据表的Region位置信息 |
-
为了加快访问速度，.META.表的全部Region都会被保存在内存中
-
假设.META.表的每行（一个映射条目）在内存中大约占用1KB，并且每个Region限制为128MB，那么，上面的三层结构可以保存的用户数据表的Region数目的计算方法是：
-
（-ROOT-表能够寻址的.META.表的Region个数）×（每个.META.表的 Region可以寻址的用户数据表的Region个数）
-
一个-ROOT-表最多只能有一个Region，也就是最多只能有128MB，按照每行（一个映射条目）占用1KB内存计算，128MB空间可以容纳128MB/1KB=217行，也就是说，一个-ROOT-表可以寻址217个.META.表的Region。
-
最终，三层结构可以保存的Region数目是(128MB/1KB) × (128MB/1KB) = 234个Region
客户端访问数据时的“三级寻址”
• 为了加速寻址，客户端会缓存位置信息，同时，需要解决缓存失效问题
• 寻址过程客户端只需要询问Zookeeper服务器，不需要连接Master服务器
Hbase系统架构
- 客户端
客户端包含访问HBase的接口，同时在缓存中维护着已经访问过的Region位置信息，用来加快后续数据访问过程 - Zookeeper服务器
Zookeeper可以帮助选举出一个Master作为集群的总管，并保证在任何时刻总有唯一一个Master在运行，这就避免了Master的“单点失效”问题
Zookeeper是一个很好的集群管理工具，被大量用于分布式计算，提供配置维护、域名服务、分布式同步、组服务等。
- Master
主服务器Master主要负责表和Region的管理工作：
管理用户对表的增加、删除、修改、查询等操作
实现不同Region服务器之间的负载均衡
在Region分裂或合并后，负责重新调整Region的分布
对发生故障失效的Region服务器上的Region进行迁移
Region服务器
Region服务器是HBase中最核心的模块，负责维护分配给自己的Region，并响应用户的读写请求
Region服务器工作原理
- 用户读写数据过程
用户写入数据时，被分配到相应Region服务器去执行
用户数据首先被写入到MemStore和Hlog中
只有当操作写入Hlog之后，commit()调用才会将其返回给客户端
当用户读取数据时，Region服务器会首先访问MemStore缓存，如果找不到，再去磁盘上面的StoreFile中寻找
- 缓存的刷新
系统会周期性地把MemStore缓存里的内容刷写到磁盘的StoreFile文件中，清空缓存，并在Hlog里面写入一个标记
每次刷写都生成一个新的StoreFile文件，因此，每个Store包含多个StoreFile文件
每个Region服务器都有一个自己的HLog 文件，每次启动都检查该文件，确认最近一次执行缓存刷新操作之后是否发生新的写入操作；如果发现更新，则先写入MemStore，再刷写到StoreFile，最后删除旧的Hlog文件，开始为用户提供服务
- StoreFile的合并
每次刷写都生成一个新的StoreFile，数量太多，影响查找速度
调用Store.compact()把多个合并成一个
合并操作比较耗费资源，只有数量达到一个阈值才启动合并
HLog工作原理
分布式环境必须要考虑系统出错。HBase采用HLog保证系统恢复
HBase系统为每个Region服务器配置了一个HLog文件，它是一种预写式日志（Write Ahead Log）
用户更新数据必须首先写入日志后，才能写入MemStore缓存，并且，直到MemStore缓存内容对应的日志已经写入磁盘，该缓存内容才能被刷写到磁盘
Zookeeper会实时监测每个Region服务器的状态，当某个Region服务器发生故障时，Zookeeper会通知Master
Master首先会处理该故障Region服务器上面遗留的HLog文件，这个遗留的HLog文件中包含了来自多个Region对象的日志记录
系统会根据每条日志记录所属的Region对象对HLog数据进行拆分，分别放到相应Region对象的目录下，然后，再将失效的Region重新分配到可用的Region服务器中，并把与该Region对象相关的HLog日志记录也发送给相应的Region服务器
Region服务器领取到分配给自己的Region对象以及与之相关的HLog日志记录以后，会重新做一遍日志记录中的各种操作，把日志记录中的数据写入到MemStore缓存中，然后，刷新到磁盘的StoreFile文件中，完成数据恢复
共用日志优点：提高对表的写操作性能；缺点：恢复时需要分拆日志
隐私保护
需求
技术分类
身份匿名：
- 链接攻击带来身份隐私威胁
- K-匿名基本模型
- 数据去匿名算法的攻击威胁
属性匿名
- 同质攻击
- K-匿名模型的变体
- L-多样化模型
- 近似攻击与T-贴近性模型
面向数据发布的隐私保护
- (k，δ)-匿名及相关模型：
- LKC-匿名及相关模型
- 可逆位置泛化
基于用户活动规律的攻击
- 马尔科夫模型及攻击
- 隐马尔科夫模型及攻击
- 贝叶斯模型及攻击
- 混合高斯模型及攻击
- 推荐系统模型及攻击
大数据安全与隐私保护介绍
大数据的生命周期包括数据产生、采集、传输、存储、使用、分享、销毁等诸多环节，每个环节都面临不同的安全威胁。其中，安全问题较为突出的是数据采集、数据传输、数据存储、数据分析与使用四个阶段
数据采集阶段
数据采集是指采集方对于用户终端、智能设备、传感器等产生的数据进行记录与预处理的过程。在大多数应用中数据不需要预处理直接上传，而在某些特殊场景下，例如传输带宽存在限制、或采集数据精度存在约束时，数据采集方需要先进行数据压缩、变换甚至加噪处理等步骤，以降低数据大小或精度。一旦真实数据被采集，则用户隐私保护完全脱离用户自身控制，因此，数据采集是数据安全与隐私保护的第一道屏障，可根据场景需求选择安全多方计算等密码学方法，或选择本地差分隐私（LDP）等隐私保护技术。
数据传输阶段
数据传输是指将采集到的大数据由用户端、智能设备、传感器等终端传送到大型集中式数据中心的过程。数据传输阶段中的主要安全目标是数据安全性。为了保证数据在传输过程中内容不被恶意攻击者收集或破坏，有必要采取安全措施保证数据的机密性和完整性。现有的密码技术已经能够提供成熟的解决方案，例如目前普遍使用的SSL通讯加密协议、或采用专用加密机、VPN技术等。
数据存储阶段
大数据被采集后常汇集存储于大型数据中心，而大量集中存储的有价值数据无疑容易成为高水平黑客团体的攻击目标。因此，大数据存储面临的安全风险是多方面的，不仅包括来自外部黑客的攻击、来自内部人员的信息窃取，还包括不同利益方对数据的超权限使用等。因此，该阶段集中体现了数据安全、平台安全、用户隐私保护等多种安全需求。
数据分析与使用阶段
大数据采集、传输、存储的主要目的是为了分析与使用，通过数据挖掘、机器学习等算法处理，从而提取出所需的知识。本阶段焦点在于如何实现数据挖掘中的隐私保护，降低多源异构数据集成中的隐私泄露。防止数据使用者对用户数据挖掘，得出用户刻意隐藏的知识；防止分析者在进行统计分析时，得到具体用户的隐私信息。
大数据安全与隐私保护技术框架
大数据安全技术
（1）大数据访问控制
角色挖掘 风险自适应访问控制 基于密码学的访问控制
（2）安全检索
PIR系列与Oblivious RAM 对称可搜索加密 非对称可搜索加密 密文区间检索
（3）安全计算
同态加密 可验证计算 安全多方计算 函数加密 外包计算
大数据隐私保护技术
（1）关系型数据隐私保护
身份匿名 属性匿名 多次发布模型与个性化匿名
（2）社交图谱数据隐私保护
节点匿名 边匿名 属性匿名
（3）位置与轨迹数据隐私保护
面向LBS应用的隐私保护 面向数据发布的隐私保护 基于用户活动规律的攻击分析
（4）差分隐私
基本差分隐私 本地差分隐私（Local Differential Privacy，LDP） 基于差分隐私的轨迹隐私保护
大数据服务于信息安全
基于大数据的威胁发现技术
由于大数据分析技术的出现，企业可以超越以往的“保护-检测-响应-恢复”（PDRR）模式，更主动地发现潜在的安全威胁。相比于传统技术方案，基于大数据的威胁发现技术具有如下优点
- 分析内容的范围更大
在威胁检测方面引入大数据分析技术，可更全面地发现针对数据资产、软件资产、实物资产、人员资产、服务资产和其他为业务提供支持的无形资产等信息资产的攻击 - 分析内容的时间跨度更长
引入大数据分析技术后，威胁分析窗口可以横跨若干年的数据，因此，威胁发现能力更强，可有效应对APT类攻击 - 攻击威胁的预测性
而基于大数据的威胁分析，可进行超前的预判。它能够寻找潜在的安全威胁，对未发生的攻击行为进行预防 - 未知威胁检测
大数据分析的特点是侧重于普通的关联分析，而不侧重因果分析，因此，通过采用恰当的分析模型，可发现未知威胁
基于大数据的认证技术
认证技术中引入大数据分析具有如下优点
- 攻击者很难模拟用户行为特征来通过认证，安全性更高
攻击者很难在方方面面都模仿到用户行为 - 减小了用户负担
用户行为和设备行为特征数据的采集、存储和分析都由认证系统完成 - 可更好地支持各系统认证机制的统一
基于大数据的认证技术可以让用户在整个网络空间采用相同的行为特征进行身份认证，而避免不同系统采用不同认证方式
虽然基于大数据的认证技术具有上述优点，但同时也存在一些问题和挑战亟待解决，例如：1）初始阶段的认证问题。以及2）用户隐私问题。
基于大数据的数据真实性分析
目前，基于大数据的数据真实性分析被广泛认为是最为有效的方法。许多企业将其应用于过滤垃圾邮件、识别虚假评论等。
基于大数据的数据真实性分析技术能够提高垃圾信息的鉴别能力。表现在以下两个方面：
引入大数据分析可获得更高的识别准确率
在进行大数据分析时，通过机器学习技术，可发现更多具有新特征的垃圾信息
大数据与“安全-即-服务”
未来必将涌现出更多、更丰富的安全应用和安全服务，大数据也必将充分展现“安全-即-服务（Security-as-a-Service)”的理念。
对于大多数信息安全企业来说，可以通过某种方式获得大数据服务，再结合自己的技术特色领域，对外提供专业化安全服务。
一种未来的发展前景是，以底层大数据服务为基础，各个企业之间组成相互依赖、互相支撑的信息安全服务体系，总体上形成信息安全产业界的良好生态环境
基本密码学工具
（1）加密技术
- 对称加密技术
- 公钥加密技术
（2）数字签名技术
（3）Hash和MAC技术
（4）密钥交换技术
