hdfs上传本地文件
❶ 大数据之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中的。
❷ hadoop的几个问题 1.将本地文件复制到hdfs中，那么在hdfs中这个文件是存放在namenode还是分开放在datanode
试着回答：
先说明一下：
1. namenode负责管理目录和文件信息，真正的文件块是存放在datanode上。
2. 每个map和rece（即task)都是java进程，默认是有单独的jvm的，所以不可能同一个类的对象会在不同节点上。
看你的描述是把namenode,datanode和jobtracker,tasktracker有点混了。
所以：
问题1. 分块存放在datanode上
问题2.inputformat是在datanode上，确切的说是在tasktracker中。每个map和rece都会有自己的对象，当多个map读入一个文件时，实际上不同的map是读的文件不同的块，rece也是一样，各个任务读入的数据是不相交的。
问题3.rece输出肯定是在hdfs上，和普通文件一样在datanode上。
问题4.每个recer会有自己的outputformat对象，与前面inputformat原因一样。
❸ 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中，便于进行进一步的查询、分析和管理。
❹ hadoop中在HDFS中创建一个input目录，然后hadoop fs -ls命令
从fs -ls从列出来的文件看，这个文件夹/user/root/input是通过root用户创建的。说明你在从本地文件系统拷贝input目录到hdfs系统的时候，不是采用的hadoop用户，而是用root用户执行的拷贝命令，你可能忘记切换用户了，可以删除现在的input目录(采用root用户运行hadoop的删除命令，或者不删除也没关系)，重新使用hadoop用户把input导入到hdfs系统中试试看。
另外，实际上应用的时候是需要关注hdfs中文件的目录结构的。你现在采用的是默认的方式，缺省会放/user/${user.name}目录下。
在把本地文件导入到hdfs的时候，是可以指定传到什么目录的，比如:
#创建input目录
sh bin/hadoop fs -mkdir /user/hadoop/input
#把myfile.txt导入到hdfs的input目录下
sh bin/hadoop fs –put /usr/hadoop/mydata/myfile.txt /user/hadoop/input