【学习笔记】大数据技术原理与应用（MOOC视频、厦门大学林子雨）

1 大数据概述

大数据特性：4v volume velocity variety value 即大量化、快速化、多样化、价值密度低

  数据量大：大数据摩尔定律

  快速化：从数据的生成到消耗，时间窗口小，可用于生成决策的时间非常少；1秒定律，这和传统的数据挖掘技术有着本质区别（谷歌的dremel可以在1秒内调动上千台服务器处理PB级数据）

  价值密度低，商业价值高

大数据影响：

  对科学研究影响：出现科学研究第四方式数据（前三个分别是实验、理论、计算）

  对思维方式影响：全样而非抽样、效率而非准确、相关而非因果

大数据应用：无人驾驶、智能医疗…

大数据一般指数据和大数据技术的综合

大数据技术，是指伴随着大数据的采集、存储、分析和应用的相关技术，是一系列使用非传统的工具来对大量的非结构化、半结构化、结构化数据进行处理，从而获得分析和预测结果的一系列数据处理和分析技术

大数据两大核心关键技术：分布式存储+分布式处理

云计算：通过网络以服务的方式为用户提供廉价IT资源

云计算典型特征：虚拟化和多租户

三种：IaaS、PaaS、SaaS

2 大数据处理架构Hadoop

2.1 Hadoop简介

Hadoop是Apache软件基金会旗下的顶级项目，开源分布式计算平台

为普通用户屏蔽大数据底层实现细节

是java开发的，但是支持多种编程语言写应用

不是单一技术，是一整套解决方案的统称，是一个项目

Hadoop两大核心：分布式文件系统HDFS+分布式并行框架MapReduce

Hadoop创始人：Doug Cutting

谷歌发布多种大数据技术：

  2003年，谷歌发布了分布式文件系统GFS（Google File System），2004年Hadoop就把它纳入自己名下进行开源实现，HDFS是GFS的开源实现

  2004年，谷歌发布了分布式并行编程框架MapReduce，2005年Hadoop也把它纳入自己的平台

随着Hadoop发展，各种相关项目独立脱离出来，成为独立子项目，2008年1月Hadoop正式成为Apache顶级项目

2008年4月，Hadoop用910节点构成集群去做计算，对1T数据做排序只用了209秒，由此而火

特性:

  高可靠性，整个Hadoop平台采用冗余副本机制，当某些机器故障剩余机器仍可提供服务

  高效性

  高可扩展性

  成本低

Hadoop不同版本，Apache Hadoop版本分为两代

Hadoop1.0到2.0变化：

  将资源调度管理部分单独抽离出来成为YARN框架（Yet Another Resource Negotiator)，2.0由HDFS、MapReduce和YARN三个分支构成，MapReduce只做数据处理工作效率提高，MapReduce是架构在YARN之上的第一个计算框架,YARN也可以支持其他计算框架比如流计算框架Storm批处理计算Spark(Spark采用和MapReduce一样逻辑但是是采用内存计算）等等；

  HDFS1.0的可扩展性不好，2.0提出NN Federation技术，是名称节点，做数据目录服务，外界访问都是访问这个服务再去取数据，1.0只有一个名称节点扩展性不好，2.0设置多个名称节点进行分区管理；2.0还增加HA，对NameNode做了个热备份；

知名的其他Hadoop开源版本：Hortonworks企业版，CDH（Cloudera Distribution Hadoop）、MapR、星环 等等

推荐企业来讲用CDH,个人学习就用Apache Hadoop

2.2 Hadoop项目结构

从最初的两大核心项目演化出非常多子项目成为一个生态圈

HDFS负责分布式文件存储

YARN框架负责资源管理和调度

MapReduce是做离线计算和批处理，不能做实时计算

Tez负责DAG计算，把很多MapReduce作业进行分析优化，构建成一个有向无环图，可以保证最好的处理效率，分清有些先做有些后做有些不要重复做

Spark的逻辑和MapReduce一样，但是是基于内存计算，而MapReduce是基于磁盘的计算，所以Spark的性能比MapReduce高一个数量级

Hive是数据仓库，是架构在MapReduce之上，SQL会被转化为一堆的MapReduce作业再去执行

Pig是帮你实现流数据处理的，属于轻量级的分析，提供类似sql的语法叫Pig Latin

Oozie是作业流调度系统

Zookeeper是做分布式协调一致性服务的，负责分布式锁、集群管理等等

HBase 列式数据库，非关系型分布式数据库，支持随机读写和实时应用,HDFS是做顺序读写的，但在实际应用中很多需要随机读写，就由HBase完成

Flume专门做日志收集的

Sqoop是在Hadoop和关系数据库做数据导入导出的

Ambari是个安装部署工具，帮你在一个集群上面非常智能化的部署和管理监控一整套Hadoop平台各种套件

2.3 Hadoop的安装与使用

Hadoop的安装模式：单机模式(默认)、伪分布式模式、分布式模式

HDFS节点：NameNode、DataNode

MapReduce节点：JobTracker、TaskTracker

NameNode管理各种元数据，里面很多数据都是直接保存在内存中，内存要大并且通道优化，带宽需求更大

SecondaryNameNode，是HDFS中的组件，是冷备份，小的集群直接和NameNode放同一台机器即可，大的集群要独立出来

Hadoop集群基准测试：

  自带基准测试程序；

  用TestDFSIO基准测试，来测试HDFS的IO性能；

  用排序测试MapReduce:Hadoop自带一个部分排序的程序，测试过程都会通过Shuffle传输至Reduce，可以充分测试MapReduce各个组件的性能

3 分布式文件系统HDFS

块：不同于文件系统中的块，大很多，默认64M，也可以更大，但是如果太大也会影响MapReduce的性能，是为了降低寻址开销

  支持大规模文件存储，突破单机存储容量上限

  简化系统设计，使元数据设计非常简单

  适合数据备份

NameNode：负责元数据，整个HDFS的管家，相当于数据目录

DataNode：具体负责存储实际数据

元数据包含文件是什么、文件被分成多少块、块与文件的映射关系、块被存在哪个服务器等信息

NameNode两大数据结构FsImage、Editlog

FsImage保存系统文件树以及文件树中所有文件和文件夹的元数据（包括文件的复制等级、修改访问时间、块大小以及组成文件的块），FsImage中没有具体记录块在哪个数据节点存储的，这个信息是单独在内存中维护的，至于块到底被放到哪个节点中去，这个信息是DataNode汇报而来实时维护的

Editlog记录对数据的操作如创建、删除、重命名等

每次启动时候从磁盘加载FsImage和Editlog到内存中，得到最新的元数据FsImage，旧的删除，同时创建新的空的Editlog，这个模式能够提高系统效率

当系统运行一段时间后，Editlog变得非常大的时候，系统效率又变慢了，此时第二名称节点Secondera NameNode开始作用帮助解决Editlog不断增大的问题，先请求NameNode停止使用Editlog并生成edits.new,然后SeconderaNamenode通过HTTP Get方式把Editlog和FsImage下载到本地进行合并操作得到新的FsImage，再发送给NameNode，然后NameNode把edits.new改为Editlog

HDFS的数据冗余保存，冗余因子默认3，当用伪分布式的时候冗余因子只能是1，能够加快数据传输速度，互为备份能够方便检查数据错误，高可靠

写策略：如果是集群内部机器的请求，就把第一个块放到本节点，如果来自集群外部请求，就会挑选一个磁盘不太慢cpu不太忙的节点来存放，第二个块就放到与第一个块不同机架的节点，第三个块会放到与第一个块相同机架的不同节点上，如果4、5、6.等块就会随机算法计算

读策略：一个基本原则是就近读取，HDFS提供一个API可以确定数据节点所属的机架id，客户端也可以调取API获取自己所属机架ID，确定远近关系，当客户端读取数据时，从NameNode获得数据块不同副本的存放位置列表，列表中包含了副本所在的数据节点，可以调用API来确定客户端和这些数据节点所属机架id，当发现同机架id时候优先读取该副本，否则随机选择

容错：

  如果NameNode出错整个HDFS实例将失效，会暂停服务一段时间，从SeconderaNameNode恢复过来后再提供服务，1.0是这样,2.0有热备HA

  如果DataNode出错，运行期间DataNode会发送心跳给NameNode，如果故障，把故障机的块冗余因子恢复，除了故障可以改变冗余副本位置，负载不均衡时候也可以Rebalance

  如果数据出错，校验码机制，块创建的时候同时创建校验码保存在同个目录，读取时候重新计算校验码和保存的校验码对比，不一致说明数据出错，即进行冗余副本的再次复制

HDFS读写数据过程

hadoop fs 命令：-ls  -mkdir –cat

把本地文件复制到hdfs中hadoop fs –cp 本地路径 hdfs路径

50070端口可以web方式看到hdfs信息，用的比较少

java API方式与HDFS交互

Hadoop为HDFS和MapReduce提供基础JAR包，叫hadoop common

4 分布式数据库HBase

4.1 简介

HBase是BigTable的一个开源实现,BigTable最初是为解决谷歌公司内部大规模网页搜索问题的，BigTable是架构在GFS之上，具有非常好的性能(可以支持PB级别的数据),具有非常好的扩展性

HBase是一个高性能 高可靠列式可伸缩的分布式数据库，特长是用来存储非结构化和半结构化的松散数据，目标是通过水平扩展存储海量数据

这个架构之上的pig hive等都是可以访问HBase的数据

为啥有了关系数据库 HDFS等等还要搞个HBase呢，原因：  虽然已经有了HDFS和MapReduce，但Hadoop主要解决大规模数据离线批量处理，Hadoop没办法满足大数据实时处理需求，而传统关系数据库扩展能力没法应对爆炸式数据增长，即使是读写分离分库分表等操作也有不便利效率低等缺陷，只有HBase能够满足不断增长的数据存储需求

和传统关系数据库区别：

  不是使用关系模型设置各种字段类型，而是直接存储未经解释的二进制数据，由应用程序开发人员来对数据做解释

  传统数据库对数据增删改等多种操作在HBase中避免了，比如连接操作，这是非常低效的操作

  存储模式方面基于列

  只支持对行键的简单索引

  在关系数据库中更新数据时候旧数据删除掉，HBase中旧的版本还在，每新加的版本会生成新的时间戳标识

  可伸缩性方面，关系数据库很难水平扩展，最多实现纵向扩展

HBase访问接口：Java API：Shell、Thrift Gateway（异构系统在线访问HBase）、REST Gateway（REST风格的HTTP API）；SQL类型接口：Pig、Hive

4.2 HBase数据模型

HBase是一个稀疏的多维度的排序的映射表，是列式数据库

通过行键、列族、列限定符、时间戳四个元素表示，HBase中每个值都是未经解释的字符串也就是Byte数组，由程序员自行对列类型解析

和关系数据库不同，和关系数据库不同的地方，列族支持动态扩展，且更新数据时候保留旧版本（与HDFS只允许追加不允许修改的特性相关）

以大表的形式来组织，不同于关系数据库遵循第一范式第二范式第三范式等规范化分解来降低数据的冗余存储，查询的时候不需要多表关联，追求的是分析的效率，用空间来换取表连接的时间

数据坐标：关系数据库通过行列定位，HBase是通过四维坐标定位，如果把四维坐标联合来看也可以当成键值数据库

概念试图：是一个稀疏表，很多地方是空

物理视图：底层是按照列族方式存储

列式数据库优点：每列数据类型相似可以带来很高的数据压缩率、分析效率高

4.3 HBase实现原理

HBase功能组件：

  库函数：用于链接每个客户端

  Master服务器：管家，实现对表的分区信息维护和管理；维护了一个Region服务器列表；整个集群当中有哪些Region服务器在工作；负责对Region进行分配；负载均衡

  Region服务器：负责存取Region

客户端并不依赖于Master去获取信息

表会分多个Region，大Region会不断分裂，分裂的过程不设计底层物理数据，只是修改了它的指向信息而已非常快速，访问的还是旧的Region，后台会有合并过程把拆分的数据进行重新操作最终写到新的文件中得到新的Region，2006以前推荐一个Region大小100到200MB，现在一般最佳是1G到2G，实际取决于单台服务器的有效处理能力

同一个Region是不会拆分到不同的Region服务器上的，实际中每个Region服务器能存储10-1000个Region

HBase寻址：三层结构，首先构建一个元数据表称.META.表，当.META.表增大后分区由-ROOT-表来维护（-ROOT-表不允许分裂只有1个Region，-ROOT-表的地址写死在ZooKeeper文件中），为了加快数据存储速率，元数据表都是放在内存中，所以内存大小限制了Region个数从而限制了整个HBase的数据大小，但是是满足企业需求的

为了加速，客户端会缓存，第一次需要三级寻址，后面就不依赖于Master了实现更快的访问，同时要解决缓存失效问题，HBase采用惰性解决机制，每次都按照缓存信息找，当无法找到数据时候才去更新缓存再次经历三级寻址过程

4.4 HBase运行机制

客户端：访问HBase的接口，为了加快访问，将已经访问过的信息缓存

ZooKeeper服务器：实现协同管理服务，实现分布式协调一致性，被大量用于分布式文件系统，提供配置维护、域名服务、分布式同步服务等等，在HBase中就是提供管家功能维护和管理整个HBase集群，动物园管理员，可以确保任何时候只有一个HMaster在运行

Master（主服务器）：负责HBase中表和Region的管理工作，比如对表的增删改查都是通过Master进行管理的，同时对不同Region服务器负载均衡，负责调整分裂、合并后Region的分布，负责重新分配故障、失效的Region服务器

Region服务器：负责用户数据的存储和管理

每个Region服务器可以存储10-1000个region，共用一个日志文件HLog，每个列族单独构成一个Store，Store数据不是直接写到底层，要先写到MemStore缓存中，缓存满后刷写到磁盘文件StoreFile，StoreFile是HBase中的表现形式底层是借助于HDFS来存储的是通过HFile文件存储的

用户读写数据过程：写数据时候先到Region服务器，先写缓存写MemStore，为了保护数据，必须先写日志HLog，只有HLog完整写入磁盘才允许调用返回给客户端；读数据也是先访问MemStore再找StoreFile，因为最新数据都在MemStore而不是磁盘StoreFile中

缓存刷新：系统会周期性把MemStrore缓存中的内容写入磁盘StoreFile中，清空缓存，并在HLog写入个标记，每次刷写都会生成一个StoreFile，所以一个Store会包含多个StoreFile文件；每个Region服务器启动都检查HLog文件确认最近一次执行缓存刷新操作之后是否有新的写入操作，如果发现更新则先写入MemStore再刷写到StoreFile最后删除旧的HLog文件，开始为用户提供服务

StoreFile合并：当StoreFile数量多的时候索引数据变慢，达到一定阈值执行合并为大的StoreFile，这个合并操作相当占用资源；当StoreFile合并大到一定程度后又会引发分裂操作

HLog工作原理：就是通过日志来保护数据，ZooKeeper负责监视整个集群，检测到故障，会告诉Master服务器，Master会处理故障，Master服务器会把故障机器的遗留的HLog拉去过来，然后把各个Region的操作分拆出来，再分配给各个Region日志重做

4.5 HBase应用方案

性能优化方法：

  时间靠近的数据都存在一起   时间戳(升序排序、越到后时间戳越大，长整型64位)，可以用系统最大的整型值减去时间戳long.MAX_VALUE-timestamp作为行键，排序就反过来了从而改变排序顺序，保证最新写的数据读的时候很快命中

  如果对实时性较高，将相关数据放到服务器缓存来提升读写性能，可以在创建表的时候设置HColumnDescriptor.setInMemory选项为true，这样可以把相关表放入region服务器缓存中加快io

  设置HColumnDescriptor.setMaxVersions可以设置最大版本数，设置1，就不会保存过期版本，可以节省空间

  没有达到最大版本数的数据想清理掉咋办，设置TimeToLive参数，一旦超过生命周期就称为过期数据，就自动被系统删除掉，如果只需要最近两天的数据设置setTimeToLive(2*24*60*60)，超过2天的数据自动清空

检测性能：

  Master-status是HBase自带工具通过web方式可以查询HBase运行状态

  Ganglia是UC Berkeley发起的一个开源集群监视项目用于监控系统性能也支持对HBase进行性能监控

  OpenTSDB可以从大规模集群中获取相关的性能参数，然后存储索引并可视化的方式提供给管理员

  Ambari是Hadoop架构上的产品，作用是创建管理，监视整个集群，HBase也是集群一部分，所以也可以对HBase进行监视

sql引擎Hive去整合HBase，另外一个产品叫Phoenix

  Hive0.6.0版本开始已经具备和HBase的整合功能，它们的接口互相通信即可实现对HBase的访问

  Phoenix是致命SaaS提供商Salesforce的产品，开源，是构建在Apache Hadoop之上的一个SQL中间层，通过它允许开发者在HBase上执行SQL查询

构建HBase二级索引（辅助索引）

  原生HBase是不支持二级索引的，默认索引只有行键，HBase原生产品只有通过单个行键或者行键起始结束点或者全表扫描三种方式来访问

  HBase0.92版本以后的新特性叫Coprocessor，充分利用这个特性帮助建立二级索引，比如华为的Hindex、Redis Solr等等

  怎么利用特性构建二级索引Coprocessor提供2个实现：endpoint、observe(endpoint相当于关系数据库的存储过程，observe相当于触发器),在更新表的同时触发器或者存储过程去维护索引表即二级索引，这不是HBase数据库自身的索引，优点是非侵入性，既没有对HBase做任何改动也不需要对上层应用做任何妥协，缺点是同时维护索引对集群压力倍增耗时也是倍增

  华为的Hindex是java编写的支持多个表索引也支持多个列索引，而且也支持基于部分列值的索引

  HBase+Redis，Redis是键值数据库，能高效管理键值对，在Redis数据库中管理索引，再定期把索引更新到HBase底层数据中，效率更高

  HBase+Solr，Solr是高性能基于Lucene的全文搜索服务器，Solr构建的是其他列和行键之间的对应关系，这种方式也是很高效的

4.6 HBase的安装配置和常用Shell命令

下载HBase安装文件，然后解压到/usr/local，如果是单机版本解压即可用，如果是伪分布式需要配置，bin目录加入到path中

HBase配置有三种：单机（解压即可用）、伪分布式（让HBase通过HDFS存取数据）、分布式（用多台机器存取）

伪分布式：要配置JAVA_HOME；要配置Hadoop，实现无密码SSH登录；要先启动hadoop再启动HBase，关闭也是；修改配置文件时候有个选项hbase.managers.zk，这是配置ZooKeeper的，可以单独安装ZooKeeper组件服务来支撑HBase，也可以用HBase自带的ZooKeeper组件来提供服务

SHELL命令：create、list、put、get、drop

4.7 常用Java API 

HBase是java开发的，有原生java api，也支持其他语言的编程

首先要导入jar包，到hbase安装目录中lib目录所有jar包导入（注意不要导入上节课的hadoop的jar包，会发生版本冲突）

Java 和shell的功能是一样的

5 NoSQL数据库

5.1 概述

NoSQL：not only sql  是关系数据库的有益补充，有灵活的可扩展性、灵活的数据模型、和云计算紧密结合

传统数据库缺陷：

  无法满足web2.0的需求：没有办法满足海量数据需求、没有满足高并发需求、无法满足高可扩展性和高可用性

  数据模型的局限性：用一个模型适应所有业务场景是不行的，hadoop针对离线分析、mongoDB和Redis都是针对在线业务，这些都是抛弃了关系模型

  web2.0关系数据库许多特性无法发挥，事务机制和高效的查询机制这两个关系数据库的突出特性在web2.0时代成为鸡肋，

    web2.0通常是不要求严格数据库事务的，比如发个微博失败与否关系不大，不像银行这些，事务机制需要很高额外开销，

    web2.0一般不要求严格的读写实时性

    web2.0不包含大量复杂sql查询，web2.0设计时候就避免了多表连接，连接操作是代价很高的，去结构化非规范化，宁可适当冗余来换来更好的性能

5.2 NoSQL数据库和关系数据库比较

关系数据库有完备的关系代数理论作为基础，NoSQL数据库缺乏统一理论基础

RDBMS是很难横向扩展，纵向扩展也有限，NoSQL有很强的水平扩展性能

关系数据库要事先定义严格的数据模式，NoSQL数据模型灵活

关系数据库在适当数据量的时候查询效率高，数据量级增大后查询效率下降，NoSQL未构建面向复杂查询的索引，查询性能差

事务一致性方面，关系数据库遵循ACID事务模型可以保证事务强一致性，NoSQL在设计时候放松一致性要求，采用BASE模型，BASE模型也是NoSQL数据库三大理论之一(CAP、BASE、最终一致性)

数据完整性，关系数据库具有保证完整性的完备机制来实现实体完整性参照完整性用户自定义完整性等，NoSQL不能实现完整性约束

可扩展性，关系数据库很差，NoSQL很好

可用性，关系数据库在小规模数据时候可用性还可以，数据量级大后可用性削弱，因为关系数据库设计之初优先保证严格的一致性，NoSQL有非常好的可用性，能够迅速返回所需结果

标准化方面，关系数据库遵循SQL标准，标准化完善，NoSQL未形成通用的行业标准，2015图领奖获得者迈克尔·斯通布雷克就认为NoSQL缺乏统一标准会在后面发展受到拖累

技术支持方面，关系数据库很多是商业数据库，能够获得强大的技术支持和后续服务支持，NoSQL很多是开源产品处于起步阶段，技术支持不如rdbms

可维护性，关系数据库需要dba维护，NoSQL维护更加复杂，因为它没有成熟的基础和实践操作规范，维护较为复杂

RDBMS：理论完备、有严格标准、支持事务一致性、可以借助索引机制实现高效查询，可扩展性差，尤其不具备水平可扩展性，无法支持海量数据存储，数据模型定义严格无法满足web2.0应用需求；用于电信银行的关键业务系统

NoSQL：支持超大规模的数据存储、数据模型灵活，缺乏底层基础理论支撑，不支持事务强一致性，导致无法用于关键业务；用于互联网企业以及传统企业的非关键性业务

无法互相取代，甚至有时候需要混合架构

5.3 NoSQL数据库的四大类型

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