上传文件至hdfs

① hdfs详解之块、小文件和副本数

1、block：block是物理切块，在文件上传到HDFS文件系统后，对大文件将以每128MB的大小切分若干，存放在不同的DataNode上。例如一个文件130M，那么他会存被切分成2个块，一个块128M，另一个块2M.

1、HDFS 适应场景: 大文件存储，小文件是致命的
2、如果小文件很多的，则有可能将NN(4G=42亿字节)撑爆。例如:1个小文件(阈值<=30M),那么NN节点维护的字节大约250字节。一亿个小文件则是250b * 1亿=250亿.将会把NN节点搜念撑爆。如果世兄困一亿个小文件合并成100万个大文件:250b * 1百万=2亿字节。
3、在生产上一般会:
1）调整小文件阈值
2）合并小文件:
a.数据未落地到hdfs之前合并
b.数据已经落到hdfs，调用spark service服务 。每天调度去合并 （-15天 业务周期）
3）小文件的危害:
a.撑爆NN。
b.影响hive、spark的计算。占用集群计算资源

1、如果是伪分布式，那么副本数只能为一。
2、生成上副本数一般也是官方默认参数尘枝: 3份

如果一个文件130M，副本数为3。那么第一个block128M，有三份。另外一个block2M，也有三份。
题目:
blockSize128M,副本数3份，那么一个文件260M，请问多少块，多少实际存储？
260%128=2....4M 3个块 3个副本=9块
260M 3=780M

② Hive四种数据导入方式

Hive提供了多种数据导入方式，以下是其中几种常见的方法：

1、从本地系统导入数据至Hive表：Hive通过Hadoop的HDFS接口，可以从本地文件系统导入数据。首先将数据文件上传至HDFS，然后在Hive中使用命令`LOAD DATA INPATH '本地文件路径' INTO TABLE 表名;`实现数据导入。

2、从HDFS导入数据至Hive表：数据存储在HDFS中时，可以使用`LOAD DATA INPATH 'HDFS文件路径' INTO TABLE 表名;`命令将数据导入Hive表。这种方式适用于数据已经在HDFS上的场景。

3、从一个Hive表导入到另一个Hive表：使用`INSERT INTO TABLE 目标表 SELECT * FROM 源表`语句可以将源表的数据导入至目标表。确保目标表结构与源表结构相匹配，包括列名、类型和数量。

4、创建表时从其他表导入数据：在创建表的过程中，可以使用`PARTITIONED BY`子句和`SELECT * FROM`子句将其他表的数据作为新表的一部分。例如`CREATE TABLE 新表 (LIKE 源表 INCLUDING ALL);`命令创建的新表结构与源表相同，包括所有列和分区。

这些导入方式在大数据处理中非常实用，能够根据实际需求灵活选择和使用。通过Hive的导入功能，数据分析师可以快速将各种来源的数据整合到Hive中，便于进行进一步的查询、分析和管理。

③ HDFS笔记

1.Hadoop 分布式 文件系统。特点：性能高、效率高、速度快
2.可以在廉价的机器上运行的 可容错 文件系统。
当集群中有机器挂掉时，HDFS会自动将挂掉的机器上的任务分配给正常的机器，使任务继续保持正常工作。

2.HDFS处理更加容易。当对一个大型文件进行写操作时，如果将该文件整个写入一个节点，那么该节点的负载便会急剧增加，这样就丧失了分布式文件系统的意义。所以，应该利用HDFS将文件拆分成不同的块，然后将不同的块分配到不同的节点上去，此时，DFS就需要管理者确定文件如何进行拆分，以及每一个块应该分配到哪一个节点。对文件进行操作时，在单机情况下，首先需要知道文件被拆分成多少块，每一个块被放在了哪一个节点上，以及块之间的顺序(文件的粘连)。而HDFS的出现，使得分布式文件集群不再需要人进行管理，利用HDFS读取文件时，我们不需要关心文件如何拆分，分配，粘连。只用告诉HDFS文件的路径即可。

HDFS的指令类似于linux下的指令。
查看文件：hdfs dfs -ls /查询的文件目录
删除文件：hdfs dfs -rm r /删除的文件
创建文件夹：hdfs dfs -mkdir /文件夹名称
上传文件至HDFS：hdfs dfs -put 需要上传的文件 /上传的文件路径

为什么需要学习HDFS结构？
1.面试中，能够运用于所有分布式文件系统设计。
既然分布式系统下是多节点运行，那么节点之间是否通信？slave节点只接受来自master节点的命令，向master节点发送心跳指令，slave节点之间不会主动通信。
a.Master slaver 模式：
1.High consistency:一致性。当文件中的一个数据块写入slave节点时，当且仅当数据块被成功写入到所有备份的slave节点，slave节点向client反馈写入操作成功，否则，重传写入；
2.Simple design:易设计：不需要考虑子节点如何通信。只需要考虑主节点的工作；
3.单master节点不具有鲁棒性。
b.Peer peer 模式：
1.所有的读写操作均匀分布在每一个节点上，每一个节点的负载不会很高；
2.任意一个节点挂掉不会影响其他节点；
3.低一致性。没有数据的复制步骤。
2.更好的理解hadoop生态系统

a.master节点会传输数据吗？
不会，master节点只接收client的请求，决定哪一个slave节点进行读写操作，然后，client直接与slave节点进行通信。如果数据从master节点传输，那么master节点就会成为影响数据传输的瓶颈。
b.slave节点如何存储数据？
整个大文件？小的文件块？。HDFS借鉴GFS的设计理念，以block为传输单位，将大文件拆分成一个一个小文件，而一个小文件就是block。block的大小可以由Configuration定义，默认大小是128M。
c.谁来决定将文件拆分成块？
master?slave?。两者都不是，由HDFS client决定将大文件拆分成block(块)。HDFS的目的是将所有的节点包装起来，可以理解成将所有的节点放在一个黑箱里，我们不需要知道黑箱里到底发生了什么，只需要告诉黑箱需要做什么工作，这里的HDFS client相当于HDFS与user通信的中间媒介。HDFS client相当于一个软件包(api)，可以存放在master或者slave或者额外的一个新节点上。

写入in memory失败(ACK出现问题)时，master会重新选择3个新的slave节点。

④ 大数据之HDFS

在现代的企业环境中，单机容量往往无法存储大量数据，需要跨机器存储。统一管理分布在集群上的文件系统称为 分布式文件系统 。

HDFS （Hadoop Distributed File System）是 Hadoop 的核心组件之一， 非常适于存储大型数据 (比如 TB 和 PB)， HDFS 使用多台计算机存储文件，并且提供统一的访问接口，像是访问一个普通文件系统一样使用分布式文件系统。

HDFS是分布式计算中数据存储管理的基础，是基于流数据模式访问和处理超大文件的需求而开发的，可以运行于廉价的商用服务器上。它所具有的 高容错、高可靠性、高可扩展性、高获得性、高吞吐率 等特征为海量数据提供了不怕故障的存储，为超大数据集的应用处理带来了很多便利。

HDFS 具有以下 优点 ：

当然 HDFS 也有它的 劣势 ，并不适合以下场合：

HDFS 采用Master/Slave的架构来存储数据，这种架构主要由四个部分组成，分别为HDFS Client、NameNode、DataNode和Secondary NameNode。

Namenode是整个文件系统的管理节点，负责接收用户的操作请求。它维护着整个文件系统的目录树，文件的元数据信息以及文件到块的对应关系和块到节点的对应关系。

Namenode保存了两个核心的数据结构：

在NameNode启动的时候，先将fsimage中的文件系统元数据信息加载到内存，然后根据edits中的记录将内存中的元数据同步到最新状态；所以，这两个文件一旦损坏或丢失，将导致整个HDFS文件系统不可用。

为了避免edits文件过大， SecondaryNameNode会按照时间阈值或者大小阈值，周期性的将fsimage和edits合并 ，然后将最新的fsimage推送给NameNode。

并非 NameNode 的热备。当NameNode 挂掉的时候，它并不能马上替换 NameNode 并提供服务。其主要任务是辅助 NameNode，定期合并 fsimage和fsedits。

Datanode是实际存储数据块的地方，负责执行数据块的读/写操作。

一个数据块在DataNode以文件存储在磁盘上，包括两个文件，一个是数据本身，一个是元数据，包括数据块的长度，块数据的校验和，以及时间戳。

文件划分成块，默认大小128M，以快为单位，每个块有多个副本（默认3个）存储不同的机器上。

Hadoop2.X默认128M， 小于一个块的文件，并不会占据整个块的空间 。Block数据块大小设置较大的原因：

文件上传 HDFS 的时候，Client 将文件切分成 一个一个的Block，然后进行存储。

Client 还提供一些命令来管理 HDFS，比如启动或者关闭HDFS。

Namenode始终在内存中保存metedata，用于处理“读请求”，到有“写请求”到来时，namenode会首 先写editlog到磁盘，即向edits文件中写日志，成功返回后，才会修改内存 ，并且向客户端返回，Hadoop会维护一个fsimage文件，也就是namenode中metedata的镜像，但是fsimage不会随时与namenode内存中的metedata保持一致，而是每隔一段时间通过合并edits文件来更新内容。

HDFS HA（High Availability）是为了解决单点故障问题。

HA集群设置两个名称节点，“活跃（ Active ）”和“待命（ Standby ）”，两种名称节点的状态同步，可以借助于一个共享存储系统来实现，一旦活跃名称节点出现故障，就可以立即切换到待命名称节点。

为了保证读写数据一致性，HDFS集群设计为只能有一个状态为Active的NameNode，但这种设计存在单点故障问题，官方提供了两种解决方案：

通过增加一个Secondary NameNode节点，处于Standby的状态，与Active的NameNode同时运行。当Active的节点出现故障时，切换到Secondary节点。

为了保证Secondary节点能够随时顶替上去，Standby节点需要定时同步Active节点的事务日志来更新本地的文件系统目录树信息，同时DataNode需要配置所有NameNode的位置，并向所有状态的NameNode发送块列表信息和心跳。

同步事务日志来更新目录树由JournalNode的守护进程来完成，简称为QJM，一个NameNode对应一个QJM进程，当Active节点执行任何命名空间文件目录树修改时，它会将修改记录持久化到大多数QJM中，Standby节点从QJM中监听并读取编辑事务日志内容，并将编辑日志应用到自己的命名空间。发生故障转移时，Standby节点将确保在将自身提升为Active状态之前，从QJM读取所有编辑内容。

注意，QJM只是实现了数据的备份，当Active节点发送故障时，需要手工提升Standby节点为Active节点。如果要实现NameNode故障自动转移，则需要配套ZKFC组件来实现，ZKFC也是独立运行的一个守护进程，基于zookeeper来实现选举和自动故障转移。

虽然HDFS HA解决了“单点故障”问题，但是在系统扩展性、整体性能和隔离性方面仍然存在问题：

HDFS HA本质上还是单名称节点。HDFS联邦可以解决以上三个方面问题。

在HDFS联邦中，设计了多个相互独立的NN，使得HDFS的命名服务能够水平扩展，这些NN分别进行各自命名空间和块的管理，不需要彼此协调。每个DN要向集群中所有的NN注册，并周期性的发送心跳信息和块信息，报告自己的状态。

HDFS联邦拥有多个独立的命名空间，其中，每一个命名空间管理属于自己的一组块，这些属于同一个命名空间的块组成一个“块池”。每个DN会为多个块池提供块的存储，块池中的各个块实际上是存储在不同DN中的。

⑤ hdfs的特点有哪些

hdfs的特点
一、hdfs的优点
1.支持海量数据的存储：一般来说，HDFS存储的文件可以支持TB和PB级别的数据。
2.检测和快速应对硬件故障：在集群环境中，硬件故障是常见性问题。因为有上千台服务器连在一起，故障率很高，因此故障检测和自动恢复hdfs文件系统的一个设计目标。假设某一个datanode挂掉之后，因为数据是有备份的，还可以从其他节点里找到。namenode通过心跳机制来检测datanode是否还存活。
3.流式数据访问：（HDFS不能做到低延迟的数据访问，但是HDFS的吞吐量大）=》Hadoop适用于处理离线数据，不适合处理实时数据。HDFS的数据处理规模比较大，应用一次需要大量的数据，同时这些应用一般都是批量处理，而不是用户交互式处理。应用程序能以流的形式访问数据库。主要的是数据的吞吐量，而不是访问速度。访问速度最终是要受制于网络和磁盘的速度，机器节点再多，也不能突破物理的局限。
4.简化的一致性模型：对于外部使用用户，不需要了解hadoop底层细节，比如文件的切块，文件的存储，节点的管理。一个文件存储在HDFS上后，适合一次写入，多次读取的场景。因为存储在HDFS上的文件都是超大文件，当上传完这个文件到hadoop集群后，会进行文件切块，分发，复制等操作。如果文件被修改，会导致重新触发这个过程，而这个过程耗时是最长的。所以在hadoop里，2.0版本允许数据的追加，单不允许数据的修改。
5.高容错性：数据自动保存多个副本，副本丢失后自动恢复。可构建在廉价的机器上，实现线性扩展。当集群增加新节点之后，namenode也可以感知，将数据分发和备份到相应的节点上。
6.商用硬件：Hadoop并不需要运行在昂贵且高可靠的硬件上。它是设计运行在商用硬件（在各种零售店都能买到的普通硬件）的集群上的，因此至少对于庞大的集群来说，节点故障的几率还是非常高的。HDFS遇到上述故障时，被设计成能够继续运行且不让用户察觉到明显的中断。
二、HDFS缺点（局限性）
1、不能做到低延迟数据访问：由于hadoop针对高数据吞吐量做了优化，牺牲了获取数据的延迟，所以对于低延迟数据访问，不适合hadoop。对于低延迟的访问需求，HBase是更好的选择。
2、不适合大量的小文件存储 ：由于namenode将文件系统的元数据存储在内存中，因此该文件系统所能存储的文件总数受限于namenode的内存容量。根据经验，每个文件、目录和数据块的存储信息大约占150字节。因此，如果有一百万个小文件，每个小文件都会占一个数据块，那至少需要300MB内存。如果是上亿级别的，就会超出当前硬件的能力。
3、修改文件：对于上传到HDFS上的文件，不支持修改文件。Hadoop2.0虽然支持了文件的追加功能，但是还是不建议对HDFS上的文件进行修改。因为效率低下。HDFS适合一次写入，然后多次读取的场景。
4、不支持用户的并行写：同一时间内，只能有一个用户执行写操作。