大数据

    数据量很大

需要用到的技术：

     hadoop（是一个生态圈）

           hdfs     

           spark     spark  core

                         spark  Streaming

                         spark   sql

hdfs产生背景

数据存储：

    方案一：纵向扩展     在一台服务器上进行硬件的扩展，存在硬件瓶颈的问题。

    方案二：横项扩展     加服务器，本质上符合分布式的思想

数据量越大，在一个操作系统存不下所有的数据，那么就要分配到更多的操作系统管理的磁盘当中，但是不能方便的维护和管理，迫切需要一种系统来管理多台机器上的文件，这就是分布式文件系统。HDFS只是分布式文件管理系统的一种。

HDFS定义：

HDFS（Hadoop Distibuted File System），他是一个文件系统。通过目录树来定位文件，他是分布式的，有很多服务器连起来，每个服务器有各自的定位。

适用场景：一次写入，多次读出的场景，且不支持文件的修改。适合用来做数据分析，不适合用于做网盘应用。

特点：a.易于扩展

           b.运行在大量廉价的机器上，提供容错机制

           c.为大量用户，提供不错的文件存取服务

优点：1.高容错性：a>数据自动保存多个副本 

                                b>丢失一个副本后，他可以自动恢复

           2.适合处理大数据   a>数据规模：GB、TB   

                                           b>处理百万规模以上的文件数量

            3.可构建在廉价的机器上，通过多个副本机制，提高可靠性。

缺点：  1.不适合低延迟时间的数据访问，毫秒级的做不到

             2.无法高效的对大量小文件进行存储  a> 大量小文件，在NameNode上存储的文件目录和块信息就会变大

                                                                        b> 小文件存储  的寻址时间会超过读取时间，反而违反了HDFS的设计目标

              3.不支持并发写入、文件随机修改    a>一个文件只能有一个写，不允许多个线程同时写入

                                                                        b>仅支持数据的追加append，不支持文件的随机修改

HDFS架构：

有哪些进程

Namenode ：                 管理命名空间，是一个主管，配置副本策略，处理客户端的读写请求。
管理元数据：块的大小，块名称，块位置，块的数量，块路径及其他操作日志。Fsimage  Edits
Datanode：                    执行操作，负责实际的数据存储操作。通过心跳带回Namenode的命令。同时会每小时向namenode汇报所有的   块信息。
SecondaryNamenode：并不是NameNode 的热备，NameNode挂掉后，不能马上替换并提供服务，主要是辅助Namnnode合并Fsimage  Edits文件。
Client:                             切分文件,与Namnnode和Datanode交互。HDFS中文件在物理上按块存储（Block），块的大小可以配置参数（dfs.blocksize)来规定，默认大小是128M。（版本2.x之后）

块大小的选择：

块的大小太小时：会增加寻址时间，一直在找这个块开始的位置。

块的大小太大时：从磁盘传输的时间会远大于定位这个块开始位置的时间。导致处理这个块所用的时间会非常长。

总结：HDFS的块的大小设置主要取决于磁盘的传输速率。

Namenode的工作机制：

第一次启动会创建Fsimage  Edits，如果是第二次启动，首先会加载Fsimage 和 Edits。达到一定数量的时候会有SecondaryNamenode进行辅助合并。

SecondaryNamenode工作机制：

达到检测点（每60分钟 /文件大小到128M）拷贝Namenode的Fsimage  Edits到内存进行合并，然后  复制到Namenode中改名字。

NN和2NN工作机制：

NameNode中的元数据存储在哪里？

 如果存在NameNode节点的磁盘中，因为要进行随机访问，还有响应客户请求，必然是效率过低。因此，元数据要存放在内存中。但只是简单的存放在内存中，如果断电，内存中的所有元数据将会丢失，整个集群就无法工作了，因此，产生在磁盘中备份元数据的FsImage。

这样又会带来问题，当内存中的元数据更新时，如果同时响应请求，还要更新磁盘中的FsImage，会使效率过低（内存忙不过来），如果不更新，会产生一致性问题。因此，引入Edits文件（只进行追加操作，效率很高）。每当元数据有更新或者添加时，修改内存中的元数据，并追加到Edits中，这样即使断电，也可以通过FsImage和Edits的合并，合成元数据。

如果这个工作只由NameNode完成，效率又会过低，所有，引入了Secondary NameNode 专门用于FsImage和Edits的合并，辅助NameNode完成。

Secondary NameNode工作机制：

DataNode的工作机制:

• 1.DataNode 启动后向NameNode注册。
• 2.DataNode 向NameNode注册成功
• 3.DataNode 以后每一周期（1小时）上报所有的块信息。
• 4.DataNode 每3秒心跳一次，心跳结果带有NameNode给该DataNode 的命令。
• 5.NameNode超过10分钟收不到心跳，则认为节点已经挂掉了。

 a.DataNode文件上传过程：

b. DataNode文件下载过程：