【大数据技术与实践--提纲--持续更新中】

为啥要写这玩意儿？因为实在是太抽象了，看完ppt跟竹篮打水一样。

感觉没啥用但是可能会考简答的

**什么是大数据：**大数据是指无法在容许的时间内用常规软件工具对其内容进行抓取，管理和处理的 数据。

大数据特点4V：

1. 数据量大(Volume)
2. 数据类型繁多(Variety)
3. 处理速度快(Velocity)
4. 价值密度低(Value)

大数据，云计算和物联网三者之间的区别和联系：

区别：
大数据侧重于对海量数据的存储、处理与分析，海量数据中发现价值，服务于生产和生活
云计算本质上旨在整合和优化各种IT资源,并通过向络以服务的方式廉价地提供给用户
物联网的发展目标是实现物相连，应用创新是物联网发展的核心。

联系：三者是相辅相成的
大数据根植于云计算，大数据分析的很多技术都来自于云计算，云计算的分布式数拟存储和管理系统(包括分布式文件系统和分布式数据库系统)提供了海量数据的存储和管理能力，分布式井行处理框架MapReduce提供了海量数据分析能力，没有这些云计算技术作为支撑，大数据分析就无从谈起。
反之。大数据为云计算提供了“用武之地"，没有大数据这个“练兵场”。云计算技术再先进，也不能发挥它的应用价值。物联网的传感器源源不断产生的大量数据，构成了大数据的重要数据来源，没有物联网的飞速发展，就不会带来数据产生方式的变革，即由人工产生阶段转向自动产生阶段，大数据时代也不会这么快就到来。
同时，物联网需要借助于云计算和大数据技术。实现物联阿大数据的存储、分析和处理。

列举几种较流行的可视化工具及其功能。
入门工具：Excel
信息图标工具：Google Chart API, D3,Visual.ly,Tableau,大数据墨镜
地图工具：Googel Fusion Tables, Modest Maps，Leaflet
时间线工具：Timetoaset, Xtimeline
高级分析工具：R, Weka,Gephi

大数据的获取、存储与并行计算

大数据挖掘过程

数据的来源与采集

大数据的采集相对于传统的数据采集有如下特点:

1. 数据来源广泛,数据量大
2. 数据库类型丰富(结构化,半结构化,非结构化)
3. 采用分布式数据库,分布式文件系统存储

数据采集三大要点:全面性,多维性,高效性 (不会真有人考这玩意儿吧)

数据采集的数据源:

1. 传感器数据
2. 互联网数据:借助网络爬虫完成
3. 日志文件:系统产生
4. 企业业务系统数据

数据分类:

1. 内部数据: 公司等组织机构从内部的团体、员工、用户或信息中获取的数据
2. 外部数据: 互联网开放的数据,合作的组织机构的交流数据

数据获取:

1. 内部数据: 问卷调查,信息登记,业务的数据记录等
2. 外部数据: 与合作机构的数据交换,网上下载,网络爬虫等

数据存储方法

1. 单机文件系统: 缺点在于数据无法在服务器之间共享
2. 网络文件系统: 缺点在于存在单点瓶颈,服务器访问性能有限
3. 分布式文件系统: 性能优越,扩展性好,成本低廉.典型代表:hadoop

Hadoop

一个能够对大数据进行分布式处理的软件框架.


混个脸熟就行了:
yarn:资源管理和调度器
Tez: 有向无环图DAG生成(用于Spark计算,后面会提到)
Spark: 高速内存计算
Hive: 数据仓库,将SQL作业转化为MapReduce作业
Pig: 数据分析,提供类SQL语言查询
Oozie: 作业流调度
ZooKeeper: 分布式协调一致性服务
HBase: 分布式数据库
Flume: 日志收集
Sqooq: 各组件之间的互通
Storm: 流计算,高速响应

数据访问

1. 数据库
2. 结构化文件访问:csv,excel等结构化文件
3. 访问文件系统:

基于MapReduce的大数据并行处理

1. 单机处理:读取,累加,读取…数据量大时候极慢而且可能无法运行
2. 传统集群处理: 分数据到不同服务器,再合并数据
3. 分布式集群处理: 数据不移动, 运算移动(实际上是针对shuffle之前的map 端而言的，而不是针对reduce端的。这个具体后面会提到)

分布式文件处理系统HDFS

HDFS概述

物理结构:

集群所用的硬件都是普通硬件,而不是专业硬件,这就大大减少了开销.

逻辑结构

主节点(Master Node)也可称为名称节点(Name Node)
从节点(Slave Node)也可称为数据节点(Data Node)

HDFS要实现的目标:兼容廉价的硬件设备、流数据读写、大数据集、简单的文件模型、强大的跨平台兼容性

HDFS的缺点:

1. 不支持低延迟数据访问
2. 无法高效存储大量小文件 (应该是由于HDFS的数据块较大造成的)
3. 不支持多用户写入及任意修改文件

HDFS的块

默认一个块64MB,一个文件被分成多个块 (Windows的NTFS的块大小是4KB,可见其远远大于普通文件系统)

但是这样也减小了寻址开销(可见其块很大是其服务于大数据领域的需求所决定的)

块的大小是固定的,简化了存储管理,也方便了元数据的管理

HDFS主要组件的功能

元数据存储的内容:
例如一个文件example.txt . 元数据记录了其分成两个块 BlockA和BlockB; 然后去哪里找这两个块呢, 元数据也记录了BlockA可以在DataNode1和DataNode3找到, BlockB可以在DataNode2和DataNode3找到.

再去例如DataNode1中, 它记录了BlockA对应的某本地文件,这也就找到了具体的数据.

NameNode

功能: 管理分布式文件系统的命名空间NameSpace

核心数据结构:

1. FsImage:维护文件系统树和元数据. 存储了文件与Block的映射关系, 但是Block和DataNode的关系 由DataNode主动告知
2. EditLog:记录操作日志

NameNode的启动

1. 载入 FsImage
2. 执行 EditLog的操作

启动之后, 所有的更新操作都会写到EditLog文件中, 因为FsImage文件一般很大,对其进行写操作会很耗费时间.

但是由此又导致了EditLog会越变越大,在下一次启动时,会花费大量的时间执行EditLog.
解决方法:SecondaryNameNode第二名称节点

工作流程:

1. 定期与NameNode通信,要求其停用EditLog, 使用edit.new记录日志
2. Http GET获取FsImage和EditLog
3. 载入FsImage, 执行EditLog操作( 实际上就是相当于去预执行了NameNode的启动操作)
4. post 发送执行后的FsImage文件
5. NameNode用收到的FsImage文件替换原有的FsImage, 使用edit.new 替换 EditLog.

数据节点

负责数据存储和读取, 向名称节点定期发送自己所存储的block列表

HDFS体系架构

总体而言,HDFS采用主从结构模型.

HDFS命名空间管理

HDFS命名空间包括目录、文件和块block
HDFS1.0体系中只有一个命名空间和一个NameNode
HDFS使用传统的分级文件体系, 所以对用户来讲,可以像使用普通文件系统那样使用HDFS.

HDFS通信协议

都是以TCP/IP为基础构建的

注意:正如体系结构图那样,NameNode节点不负责将具体的数据返回给客户端, 它只是返回数据块号、数据块位置而言. 取数据是由客户端与对应的DataNode 通信(RPC方式)达成的.

HDFS体系结构的局限性

(对HDFS1.0而言)

1. 命名空间大小限制: 名称节点的数据是保存在内存中的,其能够容纳的对象的个数会受到内存大小的限制
2. 性能的瓶颈: 整个HDFS系统的吞吐量受限于单个Name Node的吞吐量
3. 隔离问题: 只有单个名称节点和命名空间,无法对不同程序进行隔离
4. 集群可用性问题: 如果单个的Name Node故障,则整个集群不可用

HDFS存储原理

冗余数据保存

HDFS采用了多副本方式对数据进行冗余存储. 即: 将一个数据块的多个副本分发到不同的节点上.
这样会带来如下好处:

1. 加快数据传输速度: 多副本可以多并发
2. 容易检查数据错误
3. 保证数据可靠性

数据存取策略

数据存放

◼第一个副本：放置在上传文件的数据节点；如果是集群外提交，则随机
挑选一台磁盘不太满、CPU不太忙的节点
◼ 第二个副本：放置在与第一个副本不同的机架的节点上
◼ 第三个副本：与第一个副本相同机架的其他节点上
◼ 更多副本：随机节点

数据读取:

注意:HDFS中客户端是一个库,它暴露了HDFS文件系统接口,提供了相应的API. 但是它也是运行在机架上的

客户端首先向NameNode获取待读取文件的不同副本存放位置信息, 如果某个数据库副本与客户端所处的机架相同,则优先读取它,否则随机选取一个读取.

数据错误与回复

HDFS具有较高的容错性

名称节点出错

HDFS具有备份机制:将FsImage和EditLog定期备份到SecondaryNameNode上.
如果NameNode出错,则根据SecondaryName Node的数据进行恢复

数据节点出错

每个数据节点都会定期向名称节点发送心跳信息
如果 没心跳了, 该数据节点就会被标记被"宕机",其上的所有数据都"不可读", 此数据节点不会接受任何IO请求.

NameNode会定期检查是否存在由于部分数据节点宕机,造成某些数据块的副本数量小于冗余因子的情况, 如果有 ,那么会对这些数据块再生成副本.
HDFS可以调整冗余数据的位置,这是与其他分布式文件系统的最大区别

数据出错

在新建文件的时候就生成了md5信息, 如果读取的时候发现校验出错,那么客户端就回去另一个副本读取,并且向名称节点报告这个数据块有错. 名称节点会定期检查并重新复制这个块.

读写数据过程

这里略去具体Java代码, 阐述逻辑 (不会真有人考代码吧)

读数据

1. 客户端提交打开文件请求
2. FSDataInputStream类通过远程方法调用RPC名称节点,获取数据块信息
3. 客户端提交读取请求
4. FSDataInputStream类选择离客户端最近的DataNode建立连接,读取数据
5. 重复步骤2(可能发生)
6. 重复步骤4(可能发生)
7. 客户端关闭文件

写数据

1. 客户端提交创建文件请求
2. FSDataOutputStream类RPC名称节点,创建文件元数据
3. 客户端写入数据
4. FSDataOutputStream类写入数据包
5. 数据节点之间传递数据流,以此创建多个文件副本
6. 数据节点之间传递确认流, 与数据流方向相反,直至FSDataOutputStream类
7. 客户端关闭文件

分布式数据库HBase

HBase概述

HBase是一个高可靠、高性能、面向列、可伸缩的分布式数据库,主要用来存储非结构化和半结构化的数据. 它是谷歌BigTable的开源实现

为何需要HBase?

1. Hadoop MapReduce为高延迟数据处理机制,无法满足大数据实时处理应用的需求
2. HDFS面向批访问模式,而非随机访问模式
3. 传统的通用关系型数据库无法应对数据扩展和性能问题

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

1. 数据类型: HBase将数据统一存储为字符串
2. 数据操作: HBase不存在表与表之间复杂的关系
3. 存储模式: HBase基于列存储, 每个列族由多个文件保存,不同列族的文件是分离的.
4. 数据索引: HBase只有单个索引-----行键
5. 数据维护: HBase中修改值不会替换它,只会生成一个新的值
6. 可伸缩性:HBase可扩展性强

HBase数据模型

每行有一个可排序的行键和任意多的列
列划分为若干列族,列族是基本的访问控制单元

HBase中通过行键、列族、列限定符、时间戳来确定一个单元格

HBase的实现原理

HBase功能组件:

1. 库函数
2. 一个Master主服务器:管理维护HBase的分区信息,维护Region服务器列表,分配Region,负载均衡
3. 多个Region服务器

与HDFS类似,客户端不直接从Master服务器上读取数据,而是获取Region的存储位置信息之后直接去Region服务器上读取相关数据.

客户端通过ZooKeeper来获取Region位置信息,大多数情况下客户端不用于Master服务器通信,这大大减少了Master服务器的负载

一张表可以分成多个Region, Region也可以分裂成多个Region.

Region块到Region服务器之间是单射关系.意即:同一个Region不会被分拆到多个Region服务器

Region的定位

三级映射架构:

1. Zookeeper记录了-ROOT-表的位置
2. -ROOT-只有一个region,它记录了所有元数据表的位置
3. 元数据表.META.可以有多个region,它记录了Region和Region服务器的映射关系,为了加快访问速度, .META.表的所有region都会保存在内存中

三层结构可以保存的用户数据表的Region数目=(-ROOT-表能够寻址的.META.表的Region个数）×（每个.META.表的 Region可以寻址的用户数据表的Region个数）

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

HBase系统架构

客户端中缓存了已经访问过的region信息,可以加快后续的数据访问过程.

Zookeeper可以帮助选举一个Master节点,并保证任何时刻都有一个Master在运行,有效的避免了Master的单点失效问题

Master节点管理用户对表的添加,删除,修改查询等操作. 但是 读写操作是直接对region服务器的

region服务器工作原理

用户读写数据的过程

写入数据:
分配到指定的region服务器 ----> 将用户数据写到MemStore和HLog中 —>写入到Hlog后,返回客户端响应.

读取数据: 访问MemStrore —> 如果没有,访问StoreFile

缓存刷新

(实际上有点类似于传统数据库的数据一致性和恢复机制)
系统周期性的新建StoreFile,然后将MemStore的数据写到其中,清空MemStore,在Hlog中写入一个标记(或者说这是一种IO的缓存机制),

每次启动的时候,如果检查到最新的标记后有写入操作,则执行一次缓存刷新以确保数据一致性.

StoreFile的合并

合并比较耗费时间,只有在数量达到阈值的时候才会启动此机制.

Store的工作原理

HLog工作原理

HLog是一种预写型日志: 更新的日志必须先写到HLog,才能写到MemStore. 缓存刷新时同理, 对于Hlog中的日志数据先写入到StoreFile之后,MemStore才写入到StoreFile.

HLog的故障恢复:
如果一个region服务器发生故障,Zookeeper会通知master,然后master会将其HLog中的每条日志记录归属到对应的region块上, 之后将region块和对应的日志记录一起发给其他正常工作的region服务器, 这些region服务器会对领取到的日志和region做缓存刷新操作.

HBase应用方案

性能优化: 设置合适的行键,创建表的时候设置合适的配置:例如将表放在内存中,设置表的最大版本,设置表中数据的生命周期

性能监视:Master-status(自带)、Ganglia、OpenTSDB、Ambari (那你如果要考这个我直接没话说)

构建SQl引擎:使用Hive

构建二级索引:使用其他组件

MapReduce

概述

MapReduce相较于传统的并行计算框架的优势:

1. 集群资源为非共享式(内存/储存),容错性好
2. 硬件为普通PC机器,便宜,扩展性好
3. 专注于"做什么",而不用关心"怎么做"

MapReduce适用于:批处理、非实时、数据密集型场景
传统的并行计算框架适用于:实时,细粒度计算,计算密集型场景

Map和reduce函数

MapReduce体系架构

client

提交MapReduce程序到JobTracker

JobTracker

负责资源监控和作业调度
跟踪所有TaskTracker和Job的执行状态, 将相关资源信息交付给JobScheduer,以供其调度.

TaskTracker

周期性的以心跳的方式提交资源使用情况和Task执行情况,接受JobTracker的命令并执行
使用slot等量划分资源, slot分为map solt和reduce slot, 分别对应map 任务和 reduce任务, 只有分配到了slot,任务才会执行.

Task

分为 MapTask和ReduceTask,均由TaskTacker启动

工作流程

不同map之间不会通信,不同的reduce之间也不会通信
执行过程用户无法干预
读取文件之后由用户决定split方法, 对每一个划分后的split都会新建一个map任务.
理想的分片大小是一个HDFS文件块)
reduce的任务个数取决于reduce solt的个数 (通常略小于,以防止可能的错误)

shuffle过程详解

溢写:将缓冲区中的数据临时写入磁盘(因为太大了)，然后重新利用这块缓冲区。

Map任务全部结束之后进行归并,将多个溢写文件归并为大文件

合并（Combine）和归并（Merge）的区别：
两个键值对<“a”,1>和<“a”,1>，
如果合并，会得到<“a”,2>，
如果归并，会得到<“a”,<1,1>>

Reduce通过RPC询问JobTracker Map任务是否已经完成,若完成则领取数据
领取数据之后先归并再合并 写入磁盘

MapReduce总体执行过程

示例

Hive

Hive概述

是一个构建于Hadoop顶层的数据仓库工具
Hive本身并不支持数据存储和处理，只是提供了一种类SQL的查询语言
依赖HDFS存储数据，依赖MapReduce处理数据

Hive适用于数据仓库，即分析的是静态数据，使用批处理方式，不要求快速响应，数据本身也不会频繁变化（Hive是不支持数据更新的）
（相比之下，HBase提供了数据的实时访问，他们互相补足）

Hive系统架构

Hive工作原理

其中的 <1,Lily> 和 <1,Tom> 的键 “1”指的是表1，或者说user表。
<2,101>, <2,102>, <2,103> 的键盘“2“指的是表2，或者说order表。

两个score表示的是两个region块，对所有的数据进行查询则不可避免的会有多个region

SQl转换为MapReduce的基本过程

1. 将SQL转化为抽象语法树
2. 将抽象语法树转化为查询块
3. 将查询块转换成逻辑查询计划
4. 重新逻辑查询计划
5. 将逻辑查询计划转换成Map/Reduce物理计划job
6. 优化查询

Hive和JobTracker远程通信来初始化MapReduce任务，所以Hive是不必和JobTracker部署在一台机器上的

Impala

Impala适用于实时性的交互SQL执行，它的运行也依赖于hive的元数据，但是它直接与HDFS和HBase交互，不依赖于MapReduce，或者说Impala拥有自己的计算框架
相对比而言，hive更适合长时间批处理查询分析。
一般在实际企业架构中，会基于hive来对数据进行批处理，然后用Impala进行实时查询

Hive实践

Hive有三种运行模式，单机模式、伪分布式模式、分布式模式（ 这和hadoop是类似的）
Hive的Sql语句我觉得不会考（我赌你的枪里面没有子弹！）

Spark

Spark概述

基于内存的大数据并行计算框架 （这是与Hadoop MapReduce最大的不同）

Hadoop 存在的缺点：

1. 表达能力有限
2. 磁盘IO开销大
3. 延迟高（调度不合理，任务之间存在不必要的等待）

Spark的优点：

1. 提供了更多的操作类型，表达能力更强
2. 提供了内存计算，迭代运算效率更高
3. 基于DAG的任务调度机制，效率优于Hadoop MapReduce的迭代执行机制（HDFS 读取数据，进行一次操作迭代，写入数据到HDFS中，再读入数据…直至处理结束）

Spark 生态系统

大数据主要有如下三种处理类型：

1. 复杂的批量数据处理：正义史官，后台跑就行，几个小时之内出结果即可
2. 基于历史数据的交互式查询：你问我答，交互式，几分钟内出结果即可
3. 基于实时数据流的数据处理：gkd，没有时间解释了，毫秒级响应

之前这些工作分别交给：hadoop MapReduce 、 Impala、storm处理
但是交给不同的组件，资源协调，同步，管理什么的都挺麻烦
但是Spark都能干 （spark storm的效率还是略逊于storm，如果要求较高的流数据响应，还是得用storm）

Spark运行架构

最最简而言之，首先Spark基于内存，这样减少了IO开销，运行速度也快。其次Spark在MapReduce的Job-Task层次之间加了一个Stage，也就是Job-Stage-Task，通过DAG算法使得多个Task可以并发执行，大大提升了效率

RDD：是Resillient Distributed Dataset（弹性分布式数据集）的简称，是分
布式内存的一个抽象概念，提供了一种高度受限的共享内存模型。简单看来就是一个内存划分块

Stage：是Job的基本调度单位，一个Job会分为多组Task，每组Task被称
为Stage，或者也被称为TaskSet，代表了一组关联的、相互之间没有Shuffle依赖关系的任务组成的任务集

WorkNode中Executor相比较于对应的Hadoop MapReduce的计算节点的TaskTacker，它可以使用多线程，也可以有效减少IO开销。

一个Application由一个Driver和若干个Job构成，一个Job由多个Stage构成，
一个Stage由多个没有Shuffle关系的Task组成

Spark运行基本流程

RDD运行原理

RDD是一个只读的分布式对象集合，简单来讲就是一个存储中间结果的数据结构。说它只读，是指不可以自行随意更改里面的数据，但是可以通过它提供的操作，例如map，join等等来生成新的RDD

Spark通过分析各个RDD的依赖关系生成了DAG

定义依赖如下：
窄依赖：上一个分区的处理结果只给一个分区
宽依赖：上一个分区的处理结果给多个分区

则划分stage方法如下：

1. 在DAG中进行反向解析，遇到宽依赖就断开
2. 遇到窄依赖就把当前的RDD加入到Stage中
3. 将窄依赖尽量划分在同一个Stage中，可以实现流水线计算

例如：对于如下的划分结果

例如对于stage2中，分区7可以一直生成分区9，分区13，这个时候才会进入等待状态，与此同时分区8，分区11，分区12在并发执行。
这就是在算法层面Spark为什么快（在物理层面，内存：这个磁盘IO就是逊啦）

Stage类型

1. ShuffleMapStage：中间stage，输出会经过Shuffle作为后续stage的输入，可有可无
2. ResultStage：结果stage，至少有一个.

SparkContext负责计算RDD之间的依赖关系，构建DAG.
DAGScheduler负责把DAG图分解成多个Stage，每个Stage中包含了多个Task，每个Task会被TaskScheduler分发给各个WorkerNode上的Executor去执行。

Spark SQL

为了实现与Hive兼容,近似认为仅将物理执行计划从MapReduce作业替换成了Spark作业,其他的抽象语法树，查询块，查询计划什么都基本不变

部署方式

1. Standalone（类似于MapReduce1.0，slot为资源分配单位）
2. Spark on Mesos（和Spark有血缘关系，更好支持Mesos）
3. Spark on YARN

最后的“理解数据”和”综合应用”是什么鬼东西，就写到这里吧，其他不会就乱扯叭文章来源地址https://www.toymoban.com/news/detail-544812.html

到了这里，关于【大数据技术与实践--提纲--持续更新中】的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！