Hadoop技术之HDFS分布式文件系统基础
Posted 黑马程序员官方
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Hadoop技术之HDFS分布式文件系统基础相关的知识，希望对你有一定的参考价值。
Spark是大数据体系的明星产品，是一款高性能的分布式内存迭代计算框架，可以处理海量规模的数据。下面就带大家一起来开始学Spark！
▼往期内容汇总：
目录
一、文件系统、分布式文件系统
文件系统定义
- 文件系统是一种存储和组织数据的方法，实现了数据的存储、分级组织、访问和获取等操作， 使得用户对文件访问和查找变得容易；
- 文件系统使用树形目录的抽象逻辑概念代替了硬盘等物理设备使用数据块的概念， 用户不必关心数据底层存在硬盘哪里， 只需要记住这个文件的所属目录和文件名即可；
- 文件系统通常使用硬盘和光盘这样的存储设备，并维护文件在设备中的物理位置。
传统常见的文件系统
所谓传统常见的文件系统更多指的的单机的文件系统，也就是底层不会横跨多台机器实现。比如windows操作系统上的文件系统、 Linux上的文件系统、 FTP文件系统等等。
这些文件系统的共同特征包括：
1. 带有抽象的目录树结构，树都是从/根目录开始往下蔓延；
2. 树中节点分为两类： 目录和文件；
3. 从根目录开始，节点路径具有唯一性。
数据、元数据
- 数据
指存储的内容本身，比如文件、视频、图片等，这些数据底层最终是存储在磁盘等存储介质上的，一般用户无需关心， 只需要基于目录树进行增删改查即可， 实际针对数据的操作由文件系统完成。
- 元数据
元数据(metadata)又称之为解释性数据，记录数据的数据；
文件系统元数据一般指文件大小、最后修改时间、底层存储位置、属性、所属用户、权限等信息。
海量数据存储遇到的问题
- 成本高
传统存储硬件通用性差， 设备投资加上后期维护、 升级扩容的成本非常高。
- 如何支撑高效率的计算分析
传统存储方式意味着数据：存储是存储，计算是计算，当需要处理数据的时候把数据移动过来。
程序和数据存储是属于不同的技术厂商实现， 无法有机统一整合在一起。
- 性能低
单节点I/O性能瓶颈无法逾越，难以支撑海量数据的高并发高吞吐场景。
- 可扩展性差
无法实现快速部署和弹性扩展， 动态扩容、缩容成本高，技术实现难度大。
（1）分布式存储的优点
- 问题： 数据量大，单机存储遇到瓶颈
- 解决：
单机纵向扩展： 磁盘不够加磁盘，有上限瓶颈限制
多机横向扩展：机器不够加机器，理论上无限扩展
（2）元数据记录的功能
问题：文件分布在不同机器上不利于寻找
解决：元数据记录下文件及其存储位置信息， 快速定位文件位置
（3）分块存储好处
问题：文件过大导致单机存不下、上传下载效率低
解决：文件分块存储在不同机器， 针对块并行操作提高效率
（4）副本机制的作用
问题：硬件故障难以避免，数据易丢失
解决：不同机器设置备份， 冗余存储， 保障数据安全
二、HDFS简介
HDFS简介
HDFS (Hadoop Distributed File System ) ， 意为： Hadoop分布式文件系统。
是Apache Hadoop核心组件之一， 作为大数据生态圈最底层的分布式存储服务而存在。也可以说大数据首先要解决的问题就是海量数据的存储问题。
HDFS简介
- HDFS主要是解决大数据如何存储问题的。分布式意味着是HDFS是横跨在多台计算机上的存储系统。
- HDFS是一种能够在普通硬件上运行的分布式文件系统， 它是高度容错的，适应于具有大数据集的应用程序，它非常适于存储大型数据 (比如 TB 和 PB)。
- HDFS使用多台计算机存储文件, 并且提供统一的访问接口, 像是访问一个普通文件系统一样使用分布式文件系统。
三、HDFS起源发展、设计目标
HDFS起源发展
- Doug Cutting领导Nutch项目研发， Nutch的设计目标是构建一个大型的全网搜索引擎， 包括网页抓取、索引、查询等功能。
- 随着爬虫抓取网页数量的增加， 遇到了严重的可扩展性问题——如何解决数十亿网页的存储和索引问题。
- 2003年的时候, Google 发表的论文为该问题提供了可行的解决方案。
- 《分布式文件系统(GFS)，可用于处理海量网页的存储》
- Nutch的开发人员完成了相应的开源实现HDFS， 并从Nutch中剥离和MapReduce成为独立项目HADOOP。
HDFS设计目标
- 硬件故障(Hardware Failure) 是常态， HDFS可能有成百上千的服务器组成，每一个组件都有可能出现故障。因此故障检测和自动快速恢复是HDFS的核心架构目标。
- HDFS上的应用主要是以流式读取数据(Streaming Data Access) 。 HDFS被设计成用于批处理，而不是用户交互式的。相较于数据访问的反应时间，更注重数据访问的高吞吐量。
- 典型的HDFS文件大小是GB到TB的级别。所以， HDFS被调整成支持大文件(Large Data Sets) 。它应该提供很高的聚合数据带宽，一个集群中支持数百个节点，一个集群中还应该支持千万级别的文件。
- 大部分HDFS应用对文件要求的是write-one-read-many访问模型。一个文件一旦创建、写入、关闭之后就不需要修改了。这一假设简化了数据一致性问题， 使高吞吐量的数据访问成为可能。
- 移动计算的代价比之移动数据的代价低。一个应用请求的计算，离它操作的数据越近就越高效。将计算移动到数据附近，比之将数据移动到应用所在显然更好。
- HDFS被设计为可从一个平台轻松移植到另一个平台。这有助于将HDFS广泛用作大量应用程序的首选平台。
四、HDFS应用场景
整体概述
主从架构
分块存储
副本机制
元数据记录
抽象统一的目录树结构(namespace)
( 1)主从架构
HDFS集群是标准的master/slave主从架构集群。
一般一个HDFS集群是有一个Namenode和一定数目的Datanode组成。
Namenode是HDFS主节点， Datanode是HDFS从节点，两种角色各司其职，共同协调完成分布式的文件存储服。
官方架构图中是一主五从模式， 其中五个从角色位于两个机架(Rack)的不同服务器上。
(2)分块存储
HDFS中的文件在物理上是分块存储(block) 的， 默认大小是128M ( 134217728)， 不足128M则本身就是一块。
块的大小可以通过配置参数来规定，参数位于hdfs-default.xml中： dfs.blocksize。
( 3)副本机制
文件的所有block都会有副本。副本系数可以在文件创建的时候指定， 也可以在之后通过命令改变。
副本数由参数dfs.replication控制， 默认值是3，也就是会额外再复制2份， 连同本身总共3份副本。
(4)元数据管理
在HDFS中， Namenode管理的元数据具有两种类型：
- 文件自身属性信息
文件名称、权限，修改时间，文件大小，复制因子， 数据块大小。
- 文件块位置映射信息
记录文件块和DataNode之间的映射信息，即哪个块位于哪个节点上。
( 5) namespace
HDFS支持传统的层次型文件组织结构。用户可以创建目录，然后将文件保存在这些目录里。文件系统名字空间的层次结构和大多数现有的文件系统类似：用户可以创建、删除、移动或重命名文件。
Namenode负责维护文件系统的namespace名称空间， 任何对文件系统名称空间或属性的修改都将被Namenode记录下来。
HDFS会给客户端提供一个统一的抽象目录树，客户端通过路径来访问文件， 形如： hdfs://namenode:port/dir-
a/dir-b/dir-c/file.data。
(6)数据块存储
文件的各个block的具体存储管理由DataNode节点承担。
每一个block都可以在多个DataNode上存储。
以上是关于Hadoop技术之HDFS分布式文件系统基础的主要内容，如果未能解决你的问题，请参考以下文章