【大数据技术Hadoop+Spark】HDFS概念、架构、原理、优缺点讲解(超详细必看)

简介: 【大数据技术Hadoop+Spark】HDFS概念、架构、原理、优缺点讲解(超详细必看)

一、相关基本概念

文件系统。文件系统是操作系统提供的用于解决“如何在磁盘上组织文件”的一系列方法和数据结构。

分布式文件系统。分布式文件系统是指利用多台计算机协同作用解决单台计算机所不能解决的存储问题的文件系统。如单机负载高、数据不安全等问题。

HDFS。英文全称为Hadoop Distributed File System,是Hadoop项目的核心子项目,是分布式计算中数据存储管理的基础,它是基于流式数据访问和处理超大文件的需求而开发的分布式文件系统,可以运行于廉价的商用服务器上。 HDFS 源于谷歌公司在2003年10月份发表的GFS(Google File System) 论文

二、HDFS存储架构

HDFS采用主从架构(Master/Slave架构)

HDFS集群是由一个NameNode和多个的 DataNode组成。

HDFS集群是由一个NameNode和多个的 DataNode组成

1:Namenode

NameNode是HDFS集群的主服务器,通常称为名称节点或者主节点。一旦NameNode关闭,就无法访问Hadoop集群。NameNode主要以元数据的形式进行管理和存储,用于维护文件系统名称并管理客户端对文件的访问;NameNode记录对文件系统名称空间或其属性的任何更改操作;HDFS负责整个数据集群的管理,并且在配置文件中可以设置备份数量,这些信息都由NameNode存储。

2:Datanode

DataNode是HDFS集群中的从服务器,通常称为数据节点。文件系统存储文件的方式是将文件切分成多个数据块,这些数据块实际上是存储在DataNode节点中的,因此DataNode机器需要配置大量磁盘空间。它与NameNode保持不断的通信,DataNode在客户端或者NameNode的调度下,存储并检索数据块,对数据块进行创建、删除等操作,并且定期向NameNode发送所存储的数据块列表。

三、HDFS写入流程

1)Hadoop客户端和NameNode通信请求上传文件,NameNode检查目标文件是否已存在,父目录是否存在。

2)NameNode返回信息给hadoop客户端是否可以上传。

3)Hadoop客户端会先对文件进行切分,比如:一个block块大小为128M,如果上传文件300M大小,文件会被切分成3个块,两个128M、一个44M,并向NameNode发上传请求。

4)NameNode返回DataNode的服务器信息给hadoop客户端。

5)hadoop客户端请求一台DataNode上传数据(本质上是一个RPC调用,建立通道),第一个DataNode收到请求会继续调用第二个DataNode,然后第二个调用第三个DataNode,将整个通道建立完成,逐级返回hadoop客户端。

6)hadoop客户端开始往第一个DataNode上传第一个block(先从磁盘读取数据放到一个本地内存缓存),以packet为单位(一个packet为64kb),当然在写入的时候通道会进行数据校验,它并不是通过一个packet进行一次校验而是以checksum为单位进行校验(512byte),第一台DataNode收到一个packet就会传给第二台,第二台传给第三台;第一台每传一个packet会放入一个应答队列等待应答。

7)当一个block传输完成之后,hadoop客户端再次请求NameNode上传第二个block的DataNode服务器,直至所有的block上传完成。

四、HDFS读取流程

1)hadoop客户端发送请求,调用Distributed File System API的open方法发送请求到NameNode,获得存放在NameNode节点上文件的block位置映射信息。

2)Namenode把文件所有block的位置信息返回给hadoop客户端。

3)hadoop客户端拿到block的位置信息后调用FSDataInputStream API的read方法并行的读取block信息,block默认有3个副本,所以每一个block只需要从一个副本读取。

4)hadoop客户端从DataNode上取回文件的所有block按照一定的顺序组成最终需要的文件。

五、HDFS的优缺点

随着互联网数据规模的不断增大,对文件存储系统提出了更高的要求,需要更大的容量、好更的性能以及安全性更高的文件存储系统,与传统分布式文件系统一样,HDFS分布式文件系统也是通过计算机网络与节点相连,也有传统分布式文件系统的优点和缺点。

1:HDFS的优点

高容错性

适合处理高吞吐量

适合存储和管理大规模数据

适合一次写入 多次读取

适合处理非结构化数据

2:HDFS的缺点

不适合低延时数据访问

不适合小文件存储

不支持文件随机修改

创作不易 觉得有帮助请点赞关注收藏~~~

相关实践学习
基于MaxCompute的热门话题分析
Apsara Clouder大数据专项技能认证配套课程:基于MaxCompute的热门话题分析
相关文章
|
4月前
|
存储 缓存 安全
某鱼电商接口架构深度剖析:从稳定性到高性能的技术密码
某鱼电商接口架构揭秘:分层解耦、安全加固、性能优化三维设计,实现200ms内响应、故障率低于0.1%。详解三层架构、多引擎存储、异步发布、WebSocket通信与全链路防护,助力开发者突破电商接口“三难”困境。
|
5月前
|
数据采集 监控 JavaScript
移动端性能监控探索:鸿蒙 NEXT 探针架构与技术实现
阿里云 ARMS 团队倾力打造的鸿蒙 NEXT SDK,为鸿蒙应用提供了业界领先的全链路监控解决方案。这不仅仅是一个 SDK,更是您洞察用户体验、优化应用性能的智能伙伴。
726 45
|
4月前
|
人工智能 自然语言处理 安全
AI助教系统:基于大模型与智能体架构的新一代教育技术引擎
AI助教系统融合大语言模型、教育知识图谱、多模态交互与智能体架构,实现精准学情诊断、个性化辅导与主动教学。支持图文语音输入,本地化部署保障隐私,重构“教、学、评、辅”全链路,推动因材施教落地,助力教育数字化转型。(238字)
815 23
|
4月前
|
Java Linux 虚拟化
【Docker】(1)Docker的概述与架构,手把手带你安装Docker,云原生路上不可缺少的一门技术!
1. Docker简介 1.1 Docker是什么 为什么docker会出现? 假定您在开发一款平台项目,您的开发环境具有特定的配置。其他开发人员身处的环境配置也各有不同。 您正在开发的应用依赖于您当前的配置且还要依赖于某些配置文件。 您的企业还拥有标准化的测试和生产环境,且具有自身的配置和一系列支持文件。 **要求:**希望尽可能多在本地模拟这些环境而不产生重新创建服务器环境的开销 问题: 要如何确保应用能够在这些环境中运行和通过质量检测? 在部署过程中不出现令人头疼的版本、配置问题 无需重新编写代码和进行故障修复
450 2
|
5月前
|
Cloud Native API 开发者
Gemini 2.5 Flash 技术拆解:从 MoE 架构到阿里云生态落地指南
2025年9月,谷歌Gemini 2.5 Flash发布,性能提升5%、成本降24%,引发行业关注。其MoE架构、百万上下文与“思考”范式,助力阿里云开发者高效构建云原生应用。本文解析技术内核,结合汽车、物流等案例,提供落地指南与避坑建议,展望大模型与流计算融合前景。
674 6
|
4月前
|
存储 人工智能 搜索推荐
拔俗AI助教系统:基于大模型与智能体架构的新一代教育技术引擎
AI助教融合大语言模型、教育知识图谱、多模态感知与智能体技术,重构“教、学、评、辅”全链路。通过微调LLM、精准诊断错因、多模态交互与自主任务规划,实现个性化教学。轻量化部署与隐私保护设计保障落地安全,未来将向情感感知与教育深度协同演进。(238字)
475 0
|
8月前
|
人工智能 分布式计算 大数据
大数据≠大样本:基于Spark的特征降维实战(提升10倍训练效率)
本文探讨了大数据场景下降维的核心问题与解决方案,重点分析了“维度灾难”对模型性能的影响及特征冗余的陷阱。通过数学证明与实际案例,揭示高维空间中样本稀疏性问题,并提出基于Spark的分布式降维技术选型与优化策略。文章详细展示了PCA在亿级用户画像中的应用,包括数据准备、核心实现与效果评估,同时深入探讨了协方差矩阵计算与特征值分解的并行优化方法。此外,还介绍了动态维度调整、非线性特征处理及降维与其他AI技术的协同效应,为生产环境提供了最佳实践指南。最终总结出降维的本质与工程实践原则,展望未来发展方向。
424 0
|
分布式计算 大数据 Apache
ClickHouse与大数据生态集成:Spark & Flink 实战
【10月更文挑战第26天】在当今这个数据爆炸的时代,能够高效地处理和分析海量数据成为了企业和组织提升竞争力的关键。作为一款高性能的列式数据库系统,ClickHouse 在大数据分析领域展现出了卓越的能力。然而,为了充分利用ClickHouse的优势,将其与现有的大数据处理框架(如Apache Spark和Apache Flink)进行集成变得尤为重要。本文将从我个人的角度出发,探讨如何通过这些技术的结合,实现对大规模数据的实时处理和分析。
1043 2
ClickHouse与大数据生态集成:Spark & Flink 实战
|
11月前
|
存储 分布式计算 Hadoop
从“笨重大象”到“敏捷火花”:Hadoop与Spark的大数据技术进化之路
从“笨重大象”到“敏捷火花”:Hadoop与Spark的大数据技术进化之路
568 79