hdfs有哪些进程并说明其作用
Hadoop分布式文件系统(HDFS)被设计成适合运行在通用硬件modity hardware)上的分布式文件系统。它和现有的分布式文件系统有很多共同点。但同时，它和其他的分布式文件系统的区别也是很明显的。HDFS是一个高度容错性的系统，适合部署在廉价的机器上。HDFS能提供高吞吐量的数据访问，非常适合大规模数据集上的应用。HDFS放宽了一部分POSIX约束，来实现流式读取文件系统数据的目的。HDFS在最开始是作为Apache Nutch搜索引擎项目的基础架构而开发的。HDFS是Apache Hadoop Core项目的一部分。 Hadoop分布式文件系统架构
1 NameNode（名称节点） HDFS命名空间采用层次化（树状——译者注）的结构存放文件和目录。
2 映像和日志 Inode和定义metadata的系统文件块列表统称为Image(映像).NameNode将整个命名空间映像保存在RAM中。而映像的持久化记录则保存在NameNode的本地文件系统中，该持久化记录被称为Checkpoint(检查点)。NameNode还会记录HDFS中写入的操作，并将其存入一个记录文件，存放在本地文件系统中，这个记录文件被叫做Journal(日志)。
3 数据节点 DataNode上的每一个块(block)副本都由两个本地文件系统上的文件共同表示。其中一个文件包含了块（block）本身所需包含的数据，另一个文件则记录了该块的元数据，包括块所含数据大小和文件生成时间戳。数据文件的大小等于该块（block）的真实大小，而不是像传统的文件系统一样，需要用额外的存储空间凑成完整的块。因此，如果一个块里只需要一半的空间存储数据，那么就只需要在本地系统上分配半块的存储空间即可。
4 HDFS客户端 用户应用程序通过HDFS客户端连接到HDFS文件系统，通过库文件可导出HDFS文件系统的接口。像很多传统的文件系统一样，HDFS支持文件的读、写和删除操作，还支持对目录的创建和删除操作。与传统的文件系统不同的是，HDFS提供一个API用以暴露文件块的位置。这个功能允许应用程序。
5 检查点节点 HDFS中的NameNode节点，除了其主要职责是相应客户端请求以外，还能够有选择地扮演一到两个其他的角色，例如做检查点节点或者备份节点。该角色是在节点启动的时候特有的。
6 备份节点 HDFS的备份节点是最近在加入系统的一项特色功能。就像CheckpintNode一样，备份节点能够定期创建检查点，但是不同的是，备份节点一直保存在内存中，随着文件系统命名空间的映像更新和不断更新，并与NameNode的状态随时保持同步。
7 系统更新和文件系统快照 在软件更新的过程中，由于软件的bug或者人为操作的失误，文件系统损坏的几率会随之提升。在HDFS中创建系统快照的目的，就在于把系统升级过程中可能对数据造成的隐患降到最低。快照机制让系统管理员将当前系统状态持久化到文件系统中，这样以来，如果系统升级后出现了数据丢失或者损坏，便有机会进行回滚操作，将HDFS的命名空间和存储状态恢复到系统快照进行的时刻。
Hadoop是什么前景怎么样
1、不论什么技术，搞精了都有不错的就业前景；
2、如今移动互联网发展迅猛，后台云计算、分布式方面的技术必不可少；
3、具我了解，不仅仅互联网公司，不少软件公司在Hadoop方面也有很大投入；
4、在国内相关概念的确被炒作的过了头，不过背后的技术确实是实在、大有用武之地的；
5、结论：我的观点是Hadoop这个方向值得探索。
4. Hive分区表对应的HDFS物理结构是什么?
每个磁盘都有默认的数据块大小，这是磁盘进行数据读/写的最小单位。构建于单个磁盘之上的文件系统通过磁盘块来管理该文件系统中的块，该文件系统块的大小可以是磁盘块的整数倍。文件系统块一般为几千字节，而磁盘块一般为512字节。这些信息——文件系统块大小——对于需要读/写文件的文件系统用户来说是透明的。尽管如此，系统仍然提供了一些工具(如df和fsck)来维护文件系统，由它们对文件系统中的块进行操作。 HDFS同样也有块(block)的概念，但是大得多，默认为64MB。与单一磁盘上的文件系统相似，HDFS上的文件也被划分为块大小的多个分块(chunk)，作为独立的存储单元。但与其他文件系统不同的是，HDFS中小于一个块大小的文件不会占据整个块的空间。如果没有特殊指出，本书中提到的“块”特指HDFS中的块。
以下哪一项不是hdfs体系架构构成内容
设计目标： -（硬件故障是常态，而非偶然）自动快速检测应对硬件错误 -流式访问数据（数据批处理） -转移计算比移动数据本身更划算（减少数据传输） -简单的数据一致性模型（一次写入，多次读取的文
hbase是怎样删除和修改数据的，和oracle这类传统的rdbms有什么区别
简单来说，传统关系型数据库的修改与删除，可以快速通过主键、列或索引直接锁定到某一行或某些行，进行物理删除。 而对于Hbase来说，受到hdfs文件系统的局限（hdfs文件系统不能修改，添加也很不方便），进行CRUD的操作就会变得相对复杂。 Hbase的修改，是根据某个行键添加一行数据，并未这行数据生成一个较新的时间戳来实现，每个行键都会对应多个时间戳的数据，那么最新的时间戳就是最终修改后的内容。 而删除则是通过标记来实现，如果要删除某行记录，Hbase会添加一个带有删除标记的行，通过这个删除标记来辨认该行建的数据是否删除。 Hbase与关系型数据库的区别：
1、场景 Hbase是面向列的数据库，适合大量的插入的同时又要具备不俗的读功能，而Oracle或其他关系型数据库适合处理比较复杂的业务关系或事务处理，而且，在数据在一定量级下都会有良好的表现，并不是所有业务的数据压力都会发生比较极端的情况。
2、索引 Hbase只能做主键索引，而关系型数据库可以根据需求不同加入适合的索引机制，供用户查询。
3、瓶颈 Hbase的瓶颈是硬盘的传输速度，Oracle的瓶颈是硬盘的寻道时间（可以看做是硬盘的转数）。
4、业务 Hbase适合按照时间排序的业务，而Oracle或其他关系型数据库应用比较广泛，如OLTP或OLAP
hdfs为什么不适合处理大量的小文件
在HDFS中，namenode将文件系统中的元数copy据存储在内存中，因此，HDFS所能存储的文件数量会受到namenode内存的限制。一般来说，每个文件、目录、2113数据块的存储信息大约占150个字节，根据当前namenode的内存空间5261的配置，就可以计算出大约能容纳多少个文件了。 有一种误解就是，之所以HDFS不适合大量4102小文件，是因为即使很小的文件也会占用一个块的存储空间。这是错误的，HDFS与其它1653文件系统不同，小于一个块大小的文件，不会占用一个块的空间。
hdfs小文件过多，会带来什么问题
因为在hdfs 中，数据的元数据信息是保存在NameNode上的，hdfs本身的作用就是用来存储海量文件的，首先小文件过多的话，会增加NameNode 的压力，，因为NameNode是要接收集群中所有的DataNode的心跳信息，来确定元数据的信息变化的，另外，文件中可使用的block块的个数是有限制的，hadoop用来处理数据的话，小文件的延迟，和数据量虽然很小，但是有些地方和大文件所耗的时间相同，所以最好做优化，避免这种情况的发生。
