大数据技术与实践学习笔记（2 of 3，from hitwh）

大数据技术与实践

注意！由于文章图片是通过typora一键上传图片实现，该功能还存在bug，容易导致图片顺序混乱，文章（1 of 3）开头提供了原版文章的 pdf 资源下载，推荐下载 pdf 后观看，或评论区联系我获取下载链接

3.2-分布式数据库HBase

一、概述

从BigTable说起

1. BigTable是一个分布式存储系统，BigTable起初用于解决典型的互联网搜索问题
   • 建立互联网索引
     • 爬虫持续不断地抓取新页面，这些页面每页一行地存储到BigTable里
     • MapReduce计算作业运行在整张表上，生成索引，为网络搜索应用做准备
   • 搜索互联网
     • 用户发起网络搜索请求
     • 网络搜索应用查询建立好的索引，从BigTable得到网页
     • 搜索结果提交给用户
2. BigTable是一个分布式存储系统
   • 利用谷歌提出的MapReduce分布式并行计算模型来处理海量数据
   • 使用谷歌分布式文件系统GFS作为底层数据存储
   • 采用Chubby提供协同服务管理
   • 可以扩展到PB级别的数据和上千台机器，具备广泛应用性、可扩展 性、高性能和高可用性等特点
   • 谷歌的许多项目都存储在BigTable中，包括搜索、地图、财经、打印、 社交网站Orkut、视频共享网站YouTube和博客网站Blogger等

HBase简介

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

   

2. HBase和BigTable的底层技术对应关系

   

3. 关系数据库已经流行很多年，并且Hadoop已经有了HDFS和MapReduce， 为什么需要HBase?

   • Hadoop可以很好地解决大规模数据的离线批量处理问题，但是，受限 于Hadoop MapReduce编程框架的高延迟数据处理机制，使得Hadoop 无法满足大规模数据实时处理应用的需求
   • HDFS面向批量访问模式，不是随机访问模式
   • 传统的通用关系型数据库无法应对在数据规模剧增时导致的系统扩展 性和性能问题（分库分表也不能很好解决）
   • 传统关系数据库在数据结构变化时一般需要停机维护；空列浪费存储 空间
   • 因此，业界出现了一类面向半结构化数据存储和处理的高可扩展、低 写入/查询延迟的系统，例如，键值数据库、文档数据库和列族数据库 （如BigTable和HBase等）
   • HBase已经成功应用于互联网服务领域和传统行业的众多在线式数据 分析处理系统中

HBase与传统关系数据库的对比分析

1. HBase与传统的关系数据库的区别主要体现在以下几个方面：
   • 数据类型：关系数据库采用关系模型，具有丰富的数据类型和存 储方式，HBase则采用了更加简单的数据模型，它把数据存储为未经解 释的字符串
   • 数据操作：关系数据库中包含了丰富的操作，其中会涉及复杂的 多表连接。HBase操作则不存在复杂的表与表之间的关系，只有简单的 插入、查询、删除、清空等，因为HBase在设计上就避免了复杂的表和 表之间的关系
   • 存储模式：关系数据库是基于行模式存储的。HBase是基于列存 储的，每个列族都由几个文件保存，不同列族的文件是分离的
   • 数据索引：关系数据库通常可以针对不同列构建复杂的多个索引 ，以提高数据访问性能。HBase只有一个索引——行键，通过巧妙的设 计，HBase中的所有访问方法，或者通过行键访问，或者通过行键扫描 ，从而使得整个系统不会慢下来
   • 数据维护：在关系数据库中，更新操作会用最新的当前值去替换 记录中原来的旧值，旧值被覆盖后就不会存在。而在HBase中执行更新 操作时，并不会删除数据旧的版本，而是生成一个新的版本，旧有的 版本仍然保留
   • 可伸缩性：关系数据库很难实现横向扩展，纵向扩展的空间也比 较有限。相反，HBase和BigTable这些分布式数据库就是为了实现灵活 的水平扩展而开发的，能够轻易地通过在集群中增加或者减少硬件数 量来实现性能的伸缩

HBase访问接口

二、HBase数据模型

1. 数据模型概述

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

2. 数据模型相关概念

   • 表：HBase采用表来组织数据，表由行 和列组成，列划分为若干个列族

   • 行：每个HBase表都由若干行组成，每 个行由行键（row key）来标识。

   • 列族：一个HBase表被分组成许多“列 族”（Column Family）的集合，它是 基本的访问控制单元

   • 列限定符：列族里的数据通过列限定符 （或列）来定位

   • 单元格：在HBase表中，通过行、列族 和列限定符确定一个“单元格”（cell ），单元格中存储的数据没有数据类型 ，总被视为字节数组byte[]

   • 时间戳：每个单元格都保存着同一份数 据的多个版本，这些版本采用时间戳进 行索引

     

3. 数据坐标：

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

     

4. 概念视图

   

5. 物理视图

   

6. 面向列的存储

   • 行式数据库和列式数据库示意图

     

   • SQL模式：

     

   • 行式存储

     

   • 列式存储

     

三、HBase的实现原理

HBase功能组件

1. HBase的实现包括三个主要的功能组件：
   • 库函数：链接到每个客户端
   • 一个Master主服务器
   • 许多个Region服务器
2. 主服务器Master负责管理和维护HBase表的分区信息，维护Region服 务器列表，分配Region，负载均衡
3. Region服务器负责存储和维护分配给自己的Region，处理来自客户端 的读写请求
4. 客户端并不是直接从Master主服务器上读取数据，而是在获得Region 的存储位置信息后，直接从Region服务器上读取数据
5. 客户端并不依赖Master，而是通过Zookeeper来获得Region位置信息 ，大多数客户端甚至从来不和Master通信，这种设计方式使得Master 负载很小

表和Region

1. 一个HBase表被划分成多个Region，一个Region会分裂成多个新的Region

   

   • 开始只有一个Region，后来不断分裂

   • Region拆分操作非常快，接近瞬间，因为拆 分之后的Region读取的仍然是原存储文件， 直到“合并”过程把存储文件异步地写到独 立的文件之后，才会读取新文件

     

2. 每个Region默认大小是100MB到200MB

   • 每个Region的最佳大小取决于单台服务器的有效处理能力
   • 目前每个Region最佳大小建议1GB-2GB

3. 同一个Region不会被分拆到多个Region服务

4. 每个Region服务器存储10-1000个Region

   

Region的定位

1. HBase的三层结构中各层次的名称和作用

   

2. 详解

   

3. 客户端访问数据时的“三级寻址”

   • 为了加速寻址，客户端会缓存位置信息，同时，需要解决缓存失效问题

   • 寻址过程客户端只需要询问Zookeeper服务器，不需要连接Master服务器

     

四、HBase的运行机制

HBase系统架构

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

2. Zookeeper服务器

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

   • Zookeeper是一个很好的集群管理工具，被大量用于分布式计算， 提供配置维护、域名服务、分布式同步、组服务等。

     

3. Master

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

4. Region服务器

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

Region服务器工作原理

1. 用户读写数据过程
   • 用户写入数据时，被分配到相应Region服务器去执行
   • 用户数据首先被写入到MemStore和Hlog中
   • 只有当操作写入Hlog之后，commit()调用才会将其返回给客户端
   • 当用户读取数据时，Region服务器会首先访问MemStore缓存，如 果找不到，再去磁盘上面的StoreFile中寻找
2. 缓存的刷新
   • 系统会周期性地把MemStore缓存里的内容刷写到磁盘的StoreFile文件中， 清空缓存，并在Hlog里面写入一个标记
   • 每次刷写都生成一个新的StoreFile文件，因此，每个Store包含多个 StoreFile文件
   • 每个Region服务器都有一个自己的HLog 文件，每次启动都检查该文件， 确认最近一次执行缓存刷新操作之后是否发生新的写入操作；如果发现 更新，则先写入MemStore，再刷写到StoreFile，最后删除旧的Hlog文件， 开始为用户提供服务
3. StoreFile的合并
   • 每次刷写都生成一个新的StoreFile，数量太多，影响查找速度
   • 调用Store.compact()把多个合并成一个
   • 合并操作比较耗费资源，只有数量达到一个阈值才启动合并

Store工作原理

• Store是Region服务器的核心
• 多个StoreFile合并成一个
• 单个StoreFile过大时，又触发分裂操作，1个父Region被分裂成两个子Region

HLog工作原理

1. 介绍：
   • 分布式环境必须要考虑系统出错。HBase采用HLog保证系 统恢复
   • HBase系统为每个Region服务器配置了一个HLog文件， 它是一种预写式日志（Write Ahead Log）
   • 用户更新数据必须首先写入日志后，才能写入MemStore 缓存，并且，直到MemStore缓存内容对应的日志已经写 入磁盘，该缓存内容才能被刷写到磁盘
2. 工作原理
   • Zookeeper会实时监测每个Region服务器的状态，当某个Region服务 器发生故障时，Zookeeper会通知Master
   • Master首先会处理该故障Region服务器上面遗留的HLog文件，这个 遗留的HLog文件中包含了来自多个Region对象的日志记录
   • 系统会根据每条日志记录所属的Region对象对HLog数据进行拆分， 分别放到相应Region对象的目录下，然后，再将失效的Region重新分 配到可用的Region服务器中，并把与该Region对象相关的HLog日志 记录也发送给相应的Region服务器
   • Region服务器领取到分配给自己的Region对象以及与之相关的HLog 日志记录以后，会重新做一遍日志记录中的各种操作，把日志记录中 的数据写入到MemStore缓存中，然后，刷新到磁盘的StoreFile文件 中，完成数据恢复
   • 共用日志优点：提高对表的写操作性能；缺点：恢复时需要分拆日志

五、HBase应用方案

HBase实际应用中的性能优化方法

1. 行键（Row Key）
   • 行键是按照字典序存储，因此，设计行键时，要充分利用这个排序特点，将 经常一起读取的数据存储到一块，将最近可能会被访问的数据放在一块。
   • 举个例子：如果最近写入HBase表中的数据是最可能被访问的，可以考虑将 时间戳作为行键的一部分，由于是字典序排序，所以可以使用Long.MAX_VALUE - timestamp作为行键，这样能保证新写入的数据在读取 时可以被快速命中。
2. InMemory
   • 创建表的时候，可以通过HColumnDescriptor.setInMemory(true)将表放到 Region服务器的缓存中，保证在读取的时候被cache命中。
3. Max Version
   • 创建表的时候，可以通过 HColumnDescriptor.setMaxVersions(int maxVersions)设置表中数据的最大 版本，如果只需要保存最新版本的数据，那么可以设置setMaxVersions(1)。
4. Time To Live
   • 创建表的时候，可以通过HColumnDescriptor.setTimeToLive(int timeToLive) 设置表中数据的存储生命期，过期数据将自动被删除，例如如果只需要存储 最近两天的数据，那么可以设置setTimeToLive(2 * 24 * 60 * 60)。

HBase性能监视

1. Master-status(自带 )

   

2. Ganglia：Ganglia是UC Berkeley发起的一个开源集群监视项目，用于监控系统性能

3. OpenTSDB：OpenTSDB可以从大规模的集群（包括集群中的网络设备、操作系统、应用程序） 中获取相应的metrics并进行存储、索引以及服务，从而使得这些数据更容易让人 理解，如web化，图形化等

4. Ambari：Ambari 的作用就是创建、管理、监视 Hadoop 的集群

在HBase之上构建SQL引擎

1. NoSQL区别于关系型数据库的一点就是NoSQL不使用SQL作为查询语言， 至于为何在NoSQL数据存储HBase上提供SQL接口，有如下原因：

   • 易使用。使用诸如SQL这样易于理解的语言，使人们能够更加轻 松地使用HBase。
   • 减少编码。使用诸如SQL这样更高层次的语言来编写，减少了编 写的代码量。

2. 方案：

   • Hive整合HBase：

     Hive与HBase的整合功能从Hive0.6.0版本已经开始出现，利用两者对外 的API接口互相通信，通信主要依靠hive_hbase-handler.jar工具包(Hive Storage Handlers)。由于HBase有一次比较大的版本变动，所以并不是每个 版本的Hive都能和现有的HBase版本进行整合，所以在使用过程中特别注意 的就是两者版本的一致性。

   • Phoenix

     Phoenix由Salesforce.com开源，是构建在Apache HBase之上的一个 SQL中间层，可以让开发者在HBase上执行SQL查询

构建HBase二级索引

1. HBase只有一个针对行健的索引。访问HBase表中的行，只有三种方式：

   • 通过单个行健访问
   • 通过一个行健的区间来访问
   • 全表扫描

2. 使用其他产品为HBase行健提供索引功能：

   • Hindex二级索引
   • HBase+Redis
   • HBase+solr

   原理：采用HBase0.92版本之后引入的Coprocessor特性

3. Coprocessor构建二级索引

   • Coprocessor提供了两个实现：endpoint和observer，endpoint相当于关系型数 据库的存储过程，而observer则相当于触发器

   • observer允许我们在记录put前后做一些处理，因此，而我们可以在插入数据时 同步写入索引表

     • 优点： 非侵入性：引擎构建在HBase 之上，既没有对HBase进行任 何改动，也不需要上层应用做 任何妥协

     • 缺点：每插入一条数据需要 向索引表插入数据，即耗时 是双倍的，对HBase的集群 的压力也是双倍的

       

Hindex二级索引

1. Hindex 是华为公司开发的纯 Java 编写的HBase二级 索引，兼容 Apache HBase 0.94.8。当前的特性如下
   • 多个表索引
   • 多个列索引
   • 基于部分列值的索引

HBase+Redis

Solr+HBase

3.3-MapReduce

一、概述

分布式并行编程

1. “摩尔定律”， CPU性能大约每隔18个月翻一番。从2005年开始摩尔定律逐渐失效 ，需要处理的数据量快速增加， 人们开始借助于分布式并行编程来提高程序性能。分布式程序运行在大规模计算机集群上，可以并行执行大规模数据 处理任务，从而获得海量的计算能力。谷歌公司最先提出了分布式并行编程模型MapReduce，Hadoop MapReduce是它的开源实现，后者比前者使用门槛低很多。

   

2. 问题：在MapReduce出现之前，已经有像MPI这样非常成熟的并行计算框架 了，那么为什么Google还需要MapReduce？MapReduce相较于传统的并行 计算框架有什么优势？

   

二、MapReduce模型简介

MapReduce模型简介

1. MapReduce将复杂的、运行于大规模集群上的并行计算过程高度地抽象 到了两个函数：Map和Reduce

2. 编程容易，不需要掌握分布式并行编程细节，也可以很容易把自己的程 序运行在分布式系统上，完成海量数据的计算

   

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

   

4. Master/slave架构（主从架构）

   

5. Map和Reduce函数

   

三、MapReduce体系结构

MapReduce的体系结构

1. MapReduce体系结构主要由四个部分组成，分别是：Client、JobTracker、 TaskTracker以及Task

   

2. MapReduce主要有以下4个部分组成：

   • Client

     • 用户编写的MapReduce程序通过Client提交到JobTracker端

     • 用户可通过Client提供的一些接口查看作业运行状态

       

   • JobTracker

     • JobTracker负责资源监控和作业调度

     • JobTracker 监控所有TaskTracker与Job的健康状况，一旦发现失败，就 将相应的任务转移到其他节点

     • JobTracker 会跟踪任务的执行进度、资源使用量等信息，并将这些信息 告诉任务调度器（TaskScheduler），而调度器会在资源出现空闲时，选 择合适的任务去使用这些资源

       

   • TaskTracker

     • TaskTracker 会周期性地通过“心跳”将本节点上资源的使用情况和任 务的运行进度汇报给JobTracker，同时接收JobTracker 发送过来的命令 并执行相应的操作（如启动新任务、杀死任务等）
     • TaskTracker 使用“slot”等量划分本节点上的资源量（CPU、内存等）。 一个Task 获取到一个slot 后才有机会运行，而Hadoop调度器的作用就是 将各个TaskTracker上的空闲slot分配给Task使用。slot 分为Map slot 和 Reduce slot 两种，分别供MapTask 和Reduce Task 使用

   • Task

     • Task 分为Map Task 和Reduce Task 两种，均由TaskTracker 启动

四、MapReduce工作流程

工作流程概述

MapReduce各个执行阶段

1. 关于Split（分片）

   • HDFS 以固定大小的block 为基本单位存储数据，而对于MapReduce 而言，其 处理单位是split。split 是一个逻辑概念，它只包含一些元数据信息，比如数据 起始位置、数据长度、数据所在节点等。它的划分方法完全由用户自己决定。

     

2. Map任务的数量

   • Hadoop为每个split创建一个Map任务，split 的多少决定了Map任务的 数目。大多数情况下，理想的分片大小是一个HDFS块

     

3. Reduce任务的数量

   • 最优的Reduce任务个数取决于集群中可用的reduce任务槽(slot)的数目
   • 通常设置比reduce任务槽数目稍微小一些的Reduce任务个数（这样可 以预留一些系统资源处理可能发生的错误）

五、Shuffle过程原理

Shuffle过程详解

1. Shuffle过程简介

   

2. Map端的Shuffle过程

   

3. Reduce端的Shuffle过程

   • Reduce任务通过RPC向JobTracker询问Map任务是否已经完成，若完成，则领取数据

   • Reduce领取数据先放入缓存，来自不同Map机器，先归并，再合并，写入磁盘

   • 多个溢写文件归并成一个或多个大文件，文件中的键值对是排序的

   • 当数据很少时，不需要溢写到磁盘，直接在缓存中归并，然后输出给Reduce

     

六、MapReduce应用程序执行过程

1. MapReduce应用程序执行过程

   

七、实例分析：WordCount

WordCount程序任务

WordCount设计思路

1. 首先，需要检查WordCount程序任务是否可以采用MapReduce来实现
2. 其次，确定MapReduce程序的设计思路
3. 最后，确定MapReduce程序的执行过程

一个WordCount执行过程的实例

八、MapReduce的具体应用

1. MapReduce可以很好地应用于各种计算问题

   • 关系代数运算（选择、投影、并、交、差、连接）
   • 分组与聚合运算
   • 矩阵-向量乘法
   • 矩阵乘法

2. 用MapReduce实现关系的自然连接