大数据学习笔记(正在更新)

---

前言

提示：以下是本篇文章正文内容

一、HDFS

作为Hadoop的基础存储设施实现了一个分布式，高容错，可线性扩展的文件系统分布式文件系统，对部署在多台独立物理机器上的文件进行管理
个人特性：
1.高容错性
2.高吞吐量
3.大文件存储
HDFS适合做：
1.大文件存储与访问
2.流式数据访问
不适合做：
1.大量小文件存储
2.随机读写
3.低延迟读取

1.基本系统架构

采用master/slaves主从结构模型来管理数据，这种结构模型主要由四个部分构成：client(客户端)，Namenode(名称节点)，Datanode（数据节点）和SecondaryNamenode（第二名称节点，辅助节点）。一般是一个Namenode节点和若干数目的Datanode。
Namenode节点
Namenode节点是中心服务器，负责管理客户端的读写请求，负责管理文件系统的命名空间（Namespace）和客户端对文件的访问。
储存每个文件中各个快所在数据节点的位置信息（元数据信息）"数据块->Datanode列表"映射根据心跳机制来进行更新。
元数据信息主要为
"文件名->数据块"映射（可控）
"数据块->Datanode列表"映射（从Datanode的心跳机制读，不可控）
Namenode执行文件系统的名称空间(namespace)操作，例如打开、关闭、重命名文件和目录，同时决定文件数据块到具体Datanode节点的映射。
Datanode节点
一般是一个节点运行一个进程，负责管理客户端的读写请求，是由Namenode调度，数据块保存在Datanode的本地文件系统中。
Datanode心跳机制：
每个Datanode会定时（秒级，默认3秒一次）向Namenode发送信息，若不发送，则会被标记为宕机，不会分配I/O任务。

2.读写进程

2.1写入

1.客户端（client）向Namenode申请上传文件
2.Namenode进行判断比对，若文件不存在时才可上传
3.若文件不存在，返回可存储文件的Datanode节点信息
4.（文件在上传是会先切成数据块（block），一个数据块在上传时以数据包（Packet）为单位进行上传）
4.1向一个Datanode建立通信管道，然后由该节点向后发送请求
4.2所有被连接的Datanode逐级应答客户端，通信管道建立成功
4.3上传数据 Datanode先保存在缓存中，并写入本地磁盘并向后续Datanode发送数据

2.2读取

1.客户端程序（client）通过调用FileSystem对象的open()方法来打开需要读取的文件，在HDFS中的FileSystem是DistributedFileSystem类的一个实例
2.DistributedFileSystem 使用RPC调用namenode的相关接口，来获取要读取的文件所包含的数据块（block）信息。（如果要读取的文件很大，它就包含许多数据块（block），这时DistributedFileSystem一次只会加载一部分块信息。）
3.客户端程序调用DFSInputStream的read()方法从最近的datanode上读取数据块。
4.DFSInputStream执行read()方法，即从指定的datanode上读取数据。
5.当前一个数据块已经读取完成之后，DFSInputStream将会关闭与对应datanode的连接，然后寻找下一个数据块所在的datanode。从客户端程序的角度来看，所读取的流依然是同一个，因此数据块之间的切换对其是透明的。
6.当客户端所需文件的全部数据都读取完成时，客户端程序将调用FSDataInputStream的close()方法来关闭流。

2.2读取性能提升

客户端程序只在namenode上获取所需文件的数据块信息，而读取数据时则是客户端程序直接连接datanode。这种设计可以允许更多的客户端程序同时访问HDFS，因为数据传输的压力被分布到了集群中的各个datanode上，而namenode仅仅负责处理对数据块地址的请求。由于文件与数据块副本的对应关系是存储在namenode的内存中的，则namenode在处理来自客户端的请求时效率是很高的。在一个集群中，namenode通常只有不到10个（一般的小型集群通常只有一个活动的namenode），这时namenode的带宽和性能就成了整个集群的瓶颈所在，这种不需要namenode处理数据块传输的设计方式极大地解放了namenode，使得集群的效率明显提升，可扩展性也极大增强。

3.HDFS架构关键设计

3.1HDFS高可用性（HA）

HA HDFS集群中会同时运行两个Namenode，一个作为活动的Namenode（Active），一个作为备份的Namenode（Standby）。备份的Namenode的命名空间与活动的Namenode是实时同步的，所以当活动的Namenode发生故障而停止服务时，备份Namenode可以立即切换为活动状态，而不影响HDFS集群服务。
活动的Namenode负责执行所有修改命名空间以及删除备份数据块的操作，而备份的Namenode则执行同步操作，以保持与活动节点命名空间的一致性。

为了使备份节点与活动节点的状态能够同步一致，两个节点都需要同一组独立运行的节点（JournalNodes，JNS）通信。当Active Namenode执行了修改命名空间的操作时，它会定期将执行的操作记录在editlog中，并写入JNS的多数节点中。而Standby Namenode会一直监听JNS上editlog的变化，如果发现editlog有改动，Standby Namenode就会读取editlog并与当前的命名空间合并。当发生了错误切换时，Standby节点会保证已经从JNS上读取了所有editlog并与命名空间合并，然后才会从Standby状态切换为Active状态。通过这种机制，保证了Active Namenode与Standby Namenode之间命名空间状态的一致性，也就是第一关系链的一致性。

Standby Namenode只会更新数据块的存储信息，并不会向namenode 发送复制或者删除数据块的指令，这些指令只能由Active namenode发送。

在HA架构中有一个非常重非要的问题，就是需要保证同一时刻只有一个处于Active状态的Namenode，否则机会出现两个Namenode同时修改命名空间的问，也就是脑裂（Split-brain）。脑裂的HDFS集群很可能造成数据块的丢失，以及向Datanode下发错误的指令等异常情况。为了预防脑裂的情况，HDFS提供了三个级别的隔离机制（fencing）:
1.共享存储隔离：同一时间只允许一个Namenode向JournalNodes写入editlog数据。
2.客户端隔离：同一时间只允许一个Namenode响应客户端的请求。
3.Datanode隔离：同一时间只允许一个Namenode向Datanode下发名字节点指令，例如删除、复制数据块指令等等。

Active Namenode和Standby Namenode之间如何共享editlog日志文件？
读 写 恢复 日志文件

所有的HA实现方案都依赖于一个保存editlog的共享存储。

Active Namenode会将日志文件写到共享存储上。Standby Namenode会实时的从共享存储读取edetlog文件，然后合并到Standby Namenode的命名空间中。这样一旦Active Namenode发生错误，Standby Namenode可以立即切换到Active状态。在Hadoop2.6中，提供了QJM（Quorum Journal Manager）方案来解决HA共享存储问题。

所有的HA实现方案都依赖于一个保存editlog的共享存储，这个存储必须是高可用的，并且能够被集群中所有的Namenode同时访问。Quorum Journa是一个基于paxos算法的HA设计方案。

1.JN: JournalNoe
运行在N台独立的物理机器上，它将editlog文件保存在JournalNode的本地磁盘上，同时JournalNode还对外提供RPC接口QJournalProtocol以执行远程读写editlog文件的功能。
2.QuorumJournalManager(QJM)
运行在NameNode上，（目前HA集群只有两个Namenode），通过调用RPC接口QJournalProtocol中的方法向JournalNode发送写入、排斥、同步editlog

写入成功：

HDFS集群中有2N+1个JN存储editlog文件，这些editlog 文件是保存在JN的本地磁盘上的。每个JN对QJM暴露QJM接口QJournalProtocol，允许Namenode读写editlog文件。当Namenode向共享存储写入editlog文件时，它会通过ＱＪＭ向集群中所有的ＪＮ发送写editlog文件请求，当有一半以上的ＪＮ返回写操作成功时，即认为写成功。基于paxos算法。即n+1个成功即成功。

读流程

Standby Namenode会从JN读取editlog，然后与Sdtandby Namenode的命名空间合并，以保持和Active Namenode命名空间的同步。当Sdtandby Namenode从JN读取editlog时，它会首先发送RPC请求到集群中所有的JN上。JN接收到这个请求后会将JN本地存储上保存的所有FINALIZED状态的editlog段落文件信息返回，之后QJM会为所有JN返回的editlog段落文件构造输入流对象，并将这些输入流对象合并到一个新的输入流对象中，这样Standby namenode就可以从任一个JN读取每个editlog段落了。如果其中一个ＪＮ失败了输入流对象会自动切换到另一个保存了该edirlog段落的JN上。

恢复（暂无）

互斥机制

当HA集群中发生Namenode异常切换时，需要在共享存储上fencing上一个活动的节点以保证该节点不能再向共享存储写入editlog。基于Quorum Journal模式的ＨＡ提供了epoch number来解决互斥问题，这个概念可以在分布式文件系统中找到。epoch number具有以下几个性质。
1.当一个Namenode变为活动状态时，会分配给他一个epoch number。
2.每个epoch number都是唯一的，没有任意两个Namenode有相同的epoch number。
3.epoch number 定义了Namenode写editlog文件的顺序。对于任意两个namenode ,拥有更大epoch number的Namenode被认为是活动节点。

3.2元数据持久化

3.3HDFS联邦

3.4数据副本机制

3.5储存策略

3.5.1分级存储

按不同活跃度对数据进行分级，然后按不同的活跃度分配不同的资源

3.5.2标签存储

按不同模块分目录进行存储

3.5.3节点组存储

3.5colocation同分布

将存在关联关系的数据或者可能要进行关联操作的数据存储在相同的存储节点上，在进行关联操作时降低网络带宽的占用

3.6数据完整性保障和其他关键设计要点说明

HDFS主要目的是保证存储数据的完整性，对于各组件的失效，做了可靠性处理。

3.6.1重建失效数据盘的副本数据

datanode向NameNode周期上报失败时，NameNode发起副本重建动作以恢复丢失副本

3.6.2集群数据均衡

HDFS架构设计了数据均衡机制，此机制保证数据在各个Datanode上分布是平均的

3.6.3元数据可靠性保证

采用日志机制操作元数据，同时元数据存放在主备NameNode上
快照机制实现了文件系统常见的快照机制，保证数据误操作时，能及时恢复。

3.6.4统一的文件系统

hdfs对外仅呈现一个统一的文件系统

3.6.5空间回收机制

支持回收站机制，以及副本数的动态设置机制

3.6.6数据组织

数据存储以数据块为单位，存储在操作系统的hdfs文件系统上

3.6.7访问方式

提供java api http shell方式访问hdfs数据

二、MapReduce和Yarn

2.1MapReduce

内部机制：
1.分区 根据reduce task 个数来确定分区个数。具备相同key值得记录送到相同的reduce task来处理
2.排序 将map输出得记录排序
3.组合 将相同key值的（,）进行合并处理
4.spill map task再处理后会产生很多溢出文件（spill file）这时需要把多个溢出文件进行合并处理，生成一个经过分区和排序的spill file(MOF)。为减少写入磁盘的数据量，MR支持对MOF进行压缩再写入
5.Map Task 任务完成MOF输出到3%时启动Reduce
6.从各个Map task获取MOF文件，reduce task个数由客户端绝对，reduce task个数决定MOF文件分区数，因此每个MOF文件都能找到相应的reduce task来处理
后边缓存多了，会进行合并可以直接输出到用户自定义的reduce文件

2.1.1shuffle机制

1).Collect阶段：将MapTask的结果输出到默认大小为100M的环形缓冲区，保存的是key/value序列化数据，Partition分区信息等。

2).Spill 阶段：当内存中的数据量达到一定的阀值的时候，就会将数据写入本地磁盘，在将数据写入磁盘之前需要对数据进行一次排序的操作，如果配置了combiner，还会将有相同分区号和key的数据进行排序。

3).Merge 阶段：把所有溢出的临时文件进行一次合并操作，以确保一个MapTask最终只产生一个中间数据文件。

4).Copy阶段： ReduceTask启动Fetcher线程到已经完成MapTask的节点上复制一份属于自己的数据，这些数据默认会保存在内存的缓冲区中，当内存的缓冲区达到一定的阀值的时候，就会将数据写到磁盘之上。

5).Merge阶段：在ReduceTask远程复制数据的同时，会在后台开启两个线程(一个是内存到磁盘的合并，一个是磁盘到磁盘的合并)对内存到本地的数据文件进行合并操作。

6).Sort阶段：在对数据进行合并的同时，会进行排序操作，由于MapTask 阶段已经对数据进行了局部的排序，ReduceTask只需保证Copy的数据的最终整体有效性即可

Shuffle的大致流程为：Maptask会不断收集我们的map()方法输出的kv对，放到内存缓冲区中，当缓冲区达到饱和的时候(默认占比为0.8)就会溢出到磁盘中，如果map的输出结果很多，则会有多个溢出文件，多个溢出文件会被合并成一个大的溢出文件，在文件溢出、合并的过程中，都要调用partitoner进行分组和针对key进行排序(默认是按照Key的hash值对Partitoner个数取模)，之后reducetask根据自己的分区号，去各个maptask机器上取相应的结果分区数据，reducetask会将这些文件再进行合并（归并排序)。
1

合并成大文件后，shuffle的过程也就结束了，后面进入reducetask的逻辑运算过程（从文件中取出每一个键值对的Group，调用UDF函数(用户自定义的方法))
源码分析

2.2Yarn

2.2.1MapReduce on Yarn

2.2.2Yarn HA方案

2.2.3Yarn AppMaster容错机制

2.2.4资源管理

1.当前Yarn页面支持内存和cpu两种资源类型的管理和分配
2.每个NodeManager可分配的内存和CPU数量可通过配置选项

2.2.5资源分配模型

2.2.6容量调度器

容量调度器是的Hadoop应用能够共享的，多租户的，操作简便的运行在集群上，同时最大化集群的吞吐量和利用率

容量调度器以队列为单位划分资源，每个队列都有资源的使用下限和上限。每个用户可以设定资源使用上限。管理员可以约束单个队列，用户或作业的资源使用。支持作业优先级，但不支持资源抢占

特点
容量保证

灵活性
如果一个队列中的资源有剩余，可以暂时共享给那些需要资源的队列，当该队列有新的应用程序提交，则其他队列释放的资源会归还给该队列
支持优先级

多重租赁
支持多用户共享集群和多应用程序共同运行。为防止单个应用程序，用户或者队列独占集群资源，管理员可为之增加多重约束
动态更新配置文件

2.2.6.1任务选择

选择合适队列：
策略1.
资源利用量最低的队列优先
策略2.
最小队列层级优先
策略3.
按照任务优先级和提交时间顺序选择

选择队列中的任务:
按照任务优先级和提交任务时间顺序选择，同时考虑用户资源量限制合内存限制

2.2.6.2队列资源限制

创建一个租户关联Yarn服务会创建同名的队列
每个队列有一个[].capacity配置

共享空闲资源

由于存在资源共享，因此一个队列使用的资源可能超过其容量
如果某个对了任务较少，可将剩余资源共享给其他队列

三、Spark

3.1Spark体系架构

功能

1.Driver
负责应用的业务逻辑和运行规划（DAG）
2.ApplicationMaster
负责应用的资源管理，根据应用的需要，向Resource Manager申请资源
3.client
提交应用
4.ResourceManager
资源管理部门，负责整个集群的资源统一调度和分配
5.Nodemanager
负责本节点的资源管理
6.executor
实际任务的执行者，一个应用会拆给多个Executor来进行计算

Spark on Yarn-client/Yarn-cluster

区别：
ApplicationMaster进程的区别
client适合测试，cluster适合生产
client提交节点宕机，整个任务会失败，cluster不会

3.2Spark-RDD

RDD-弹性分布式数据集 是一个只读的，可分区的分布式数据集

RDD 默认存储到内存，当内存不足时，溢写到磁盘

RDD数据以分区的形式在集群中存储

RDD具有血统机制，发生数据丢失时，可快速进行数据恢复

3.2.1RDD的依赖关系（待补充）

分为宽窄依赖

3.2.2RDDStage划分

3.2.3RDD的算子

transformation

transformation是通过转换从一个或多个RDD中生成新 的RDD,该操作是lazy的，当调用action算子才会发起job
典型算子：map，flatMap，filter，reduceByKey

Action

当代码调用该类型算子时，立刻启动job
典型算子：take,count,saveasTextFile

3.3Spark-Dataset

RDD
优点：类型安全，面向对象
缺点：GC性能开销，平凡创建和销毁对象，势必会增加GC

DataFrame
优点：自带scheme信息
缺点：不安全

Dataset:
快：避免不必要的格式转化
类型安全： 类似RDD
可互相转化

3.4Spark-SQL和Hive

区别：
Spark SQL执行引擎为Spark core，Hive用的是Mapreduce
Spark SQL速度快，不支持buckets，Hive支持

联系：
Spark SQL依赖Hive的数据源，可兼容绝大部分Hive的语法，可使用Hive的自定义函数

3.4Spark Structured Streaming

structured Streaming 是构建在Spark SQL引擎上的流式数据处理引擎。可以像使用静态RDD数据那样编写流式计算过程。当流数据连续不断产生，会增量持续不断处理这些数据，并将结果更新到结果集中

流处理，合并成<key,value>键值结构

3.5Spark Streaming微批处理

Spark Streaming 计算基于DStream，将流式计算分解成一系列短小的批处理作业

3.6Spark Streaming容错机制

基于RDD计算，当RDDpartition丢失，可通过RDD的血统机制重新恢复丢失的RDD

四、Hbase

一、pandas是什么？

一、pandas是什么？

一、pandas是什么？

示例：pandas 是基于NumPy 的一种工具，该工具是为了解决数据分析任务而创建的。

二、使用步骤

1.引入库

代码如下（示例）：

import numpy as np
import pandas as pd
import matplotlib.pyplot as plt
import seaborn as sns
import warnings
warnings.filterwarnings('ignore')
import  ssl
ssl._create_default_https_context = ssl._create_unverified_context
1
2
3
4
5
6
7
8

2.读入数据

代码如下（示例）：

该处使用的url网络请求的数据。

---

总结

提示：这里对文章进行总结：
例如：以上就是今天要讲的内容，本文仅仅简单介绍了pandas的使用，而pandas提供了大量能使我们快速便捷地处理数据的函数和方法。