hadoop磁盘写入流程

最新推荐文章于 2023-11-20 13:16:00 发布
原创 最新推荐文章于 2023-11-20 13:16:00 发布 · 639 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#map reduce 磁盘写入

map:将输入写入到本地磁盘   reduce：写入到HDFS

因为map产生的是中间结果，中间结果是由reduce任务处理后才是最终结果，而且中间结果一旦使用完后是可以进行删除的，不适合写入到HDFS

Hadoop的磁盘写入策略引发的问题
xiao的博客
10-14 2310
DataNode挂载的磁盘或者DataNode节点挂载多个磁盘，如果存在一些磁盘大小不一样，数据在落盘时就可能会出现磁盘使用率不均匀的情况，容量较小的盘容易被写满，而容量大的盘还剩很多空间。磁盘写满后，影响Hadoop集群的正常工作。国庆第一天，线上集群就报出了JournalNode挂掉的异常情况，经查是由于2T的磁盘被写满，JournalNode无法再写入数据。当时采取了临时的措施，删掉HBase
Hadoop慢磁盘监控
zhongmingyu
03-16 758
慢磁盘”指的时写入数据非常慢的一类磁盘。其实慢性磁盘并不少见，当机器运行时间长了，上面跑的任务多了，磁盘的读写性能自然会退化，严重时就会出现写入数据延时的问题。正常在HDFS上创建一个目录，只需要不到1s的时间。如果你发现创建目录超过1分钟及以上，而且这个现象并不是每次都有。只是偶尔慢了一下，就很有可能存在慢磁盘。一般出现慢磁盘现象，会影响到DataNode与NameNode之间的心跳。结果显示，磁盘的总体混合随机读写，读速度为。结果显示，磁盘的总体顺序读速度为。结果显示，磁盘的总体顺序写速度为。
Hadoop集群中添加硬盘
weixin_33758863的博客
03-12 252
Hadoop工作节点扩展硬盘空间 接到老板任务，Hadoop集群中硬盘空间不够用，要求加一台机器到Hadoop集群，并且每台机器在原有基础上加一块2T硬盘，老板给力啊，哈哈。 这些我把完成这项任务的步骤和我遇到的问题和解决方法总结一下，分享给大家。 1.    首先，介绍一下用到的基本命令和配置，如果本文的网友时间比较紧，可以直接跳过部分内容，直接看“2.   如何加载新硬盘”部分。 （1...
向HBase中导入数据2：使用MapReduce从HDFS或本地文件中读取数据并写入HBase（只使用Map逐条查询）
陈杰
03-16 4102
一、在HBase中创建空表二、准备好要写入HBase的文件（可能存在HDFS或者本地，需要修改输入文件路径，HDFS使用hdfs://开头，本地文件使用file://开头）例如我有这样一份文件：其保存在HDFS上三、检查能否调用hadoop读取该文件package cn.edu.shu.ces.chenjie.tianyi.hadoop; import java.io.IOException; ...
map-reduce 优化
weixin_33736048的博客
09-14 239
map阶段优化 参数：io.sort.mb（default 100） 当map task开始运算，并产生中间数据时，其产生的中间结果并非直接就简单的写入磁盘。 而是会利用到了内存buffer来进行已经产生的部分结果的缓存， 并在内存buffer中进行一些预排序来优化整个map的性能。 每一个map都会对应存在一个内存buffer,map会将已经产生的部分结果先写入到该buffer中， ...
Hadoop集群添加磁盘步骤
huyuxiang999的专栏
12-31 8748
一、实验环境 ： 1、硬件：3台DELL服务器，CPU：2.27GHz*16，内存：16GB，一台为master，另外2台为slave。 2、系统：均为CentOS6.3 3、hadoop版本：CDH4.5，选用的mapreduce版本不是yarn，而是mapreduce1，整个集群在cloudera manager的监控下，配置时也是通过manager来配置（通过更改配置文件是一样的道理）
Hadoop文件写入(详细剖析)
似水流年
09-03 5097
步骤详情: 文件是如何写入 HDFS 的。尽管比较详细，但对于理解数据流还是很有用的，因为它清楚地说明了 HDFS 的一致模型。要考虑的情况是如何创建一个新文件，并把数据写入该文件，最后关闭该文件。参见上图客户端通过对 DistributedFileSystem 对象调用 create()函数来创建文件（图步骤1）。 DistributedFileSystem 对 namenode 创建一个
hadoophdfs写入文件原理详解共2页.pdf.zip
10-30
6. **写入流程**：客户端选择一个DataNode开始写入第一个数据块，并在完成一部分数据后，通知NameNode。NameNode指示客户端将后续数据写入其他DataNode，形成副本。 7. **流式写入**：HDFS设计为顺序写入，不支持...
Linux磁盘扩容&Hadoop纵向扩容
iisbeginner的博客
11-20 363
下一步创建新虚拟磁盘，下一步指定磁盘容量完成后重启虚拟机。
hadoop hdfs 读写流程
热门推荐
lsp的博客
08-31 1万+
概述 开始之前先看看其基本属性，HDFS（Hadoop Distributed File System）是GFS的开源实现。 特点如下： 能够运行在廉价机器上，硬件出错常态，需要具备高容错性 流式数据访问，而不是随机读写 面向大规模数据集，能够进行批处理、能够横向扩展 简单一致性模型，假定文件是一次写入、多次读取 缺点： 不支持低延迟数据访问 不适合大量小文件存储（因为每条元数据占...
hadoop 读写文件流程详解
09-19
在hadoop中，有三大法宝——HDFS，MapReduce，Hbase，但是无论是MapReduce，Hbase还是hadoop中的其他组件如：Hive等他们要处理的数据还是处理完了的数据都是存储在HDFS中。可见HDFS可以说是hadoop存储的基础和核心，因此对HDFS的文件读写操作显得十分重要。
大数据开发：Hadoop数据写入与读取流程
shuimuzh123的博客
07-14 1037
基于Hadoop开发自己的企业大数据平台，这是现如今很多企业刚开始做大数据的选择，而在Hadoop系统框架当中，Hadoop实现数据处理的原理和技术，更是很多同学在学习上的难点。今天，我们就基于Hadoop生成数据、写入数据和读取数据的流程，来给大家做一个简单的分解。 Hadoop系统框架当中，实现数据生成写入的核心组件，就是HDFS。HDFS就是基于Hadoop的分布式文件存储，为数据处理提供底层支持。 Hadoop生成数据不像是往磁盘当中拷贝数据那么简单，HDFS基于数据写入和读取，需..
Hadoop集群配置中如何写入和读取数据？
哆啦A梦的博客
10-30 1421
本节和大家继续学习一下有关Hadoop集群性能优化中机架感知配置方面的内容，主要包括写入数据和读出数据两大部分，希望通过本节的介绍大家对Hadoop集群中机架感知配置有一定的认识。 Hadoop集群功能测试 以下是分别就配置了机架感知信息和没有配置机架感知信息的hadoopHDFS启动instance进行的数据上传时的测试结果。 写入数据 当没有配置机架信息时，所有的机器hadoop都默认在
hadoop原理学习——hdfs写入数据
soapcoder92的博客
04-11 2080
转自：http://blog.sina.com.cn/s/blog_4aca42510102vuxo.htmlHadoop 的存在价值是什么？Hadoop 解决的是哪些问题？简单来讲，大型企业和政府都可能会包含有大量数据, （我们可以看做是一块巨大的豆腐）例如马路卡口监控视频拍摄的机动车号牌，我们如果要对如此海量的数据进行复杂的分析，还要非常快速的得到结果，如果使用一台计算机，根本无法胜任这个工作...
Hadoop3.2.0 HDFS中的内存存储支持
张伯毅的专栏
02-19 1万+
介绍 管理员配置 限制用于内存中副本的RAM 在数据节点上设置RAM磁盘 选择tmpfs（vs ramfs） 安装RAM磁盘 使用RAM_DISK存储类型标记tmpfs卷 确保已启用存储策略 应用用法 使用LAZY_PERSIST存储策略 为目录调用hdfs storagepolicies命令 为目录调用setStoragePolicy方法 通过LAZY_PE...
hadoop任务map将其输入写入本地硬盘，而非hdfs，为什么
weixin_34007020的博客
11-01 1407
2019独角兽企业重金招聘Python工程师标准>>> ...
大数据（十）：MapTask工作机制与Shuffle机制（partitioner输出分区、WritableComparable排序）
敲代码的旺财的博客
09-07 1321
一、MapTask工作机制 Read阶段：MapTask通过用户编写的RecordReader，从输入InputSplit中解析出一个个key/value Map阶段：该节点主要是将解析出的key/value交给用户编写map()函数处理，并产生一系列新的key/value。 Collect收集阶段：在用户编写map()函数中，当数据处理完成后，一般会调用Output...
Hadoop大数据实战开发
05-24
介绍大数据技术生态圈主流技术框架的应用与发展，介绍如何搭建Hadoop大数据分布式系统集群平台、大数据分布式文件系统HDFS 、大数据分布式并行计算框架MapReduce。本课程介绍大数据的学习基础。本课程介绍大数据的背景。带你深入了解大数据，对大数据有不同的认识。介绍大数据的基本概念和技术生态圈。本课程以杨力老师主编的《Hadoop大数据开发实战》为参考，书中详细的介绍了各个步骤，有需要的同学可以留意一下。该课程的后续课程为杨力老师主讲的《hive大数据离线应用开发》，想要更进一步的同学可以继续观看杨老师的系列视频。
Linux纯干货知识总结
weijia521的博客
10-25 488
Linux纯干货知识总结 | 面试专用 绝对路径和相对路径 绝对路径 以正斜杠开始 完整的文件的位置路径 可用于任何想置顶一个文件名的时候 相对路径 不以斜线开始 置顶相对于当前工作目录或某目录的位置 可以作为一个简短的形式指定一个文件名 -基名：basename，就是文件本身的名字 -目录名：dirname ，就是它所在的文件夹名 更改目录 cd 改变目录 使用绝对或相对路径 cd/home/wang cd home/wang 切换至父目录：cd 切换至以...
Hadoop的checkpoint流程
最新发布
07-16
<think>我们正在讨论Hadoop的Checkpoint流程。根据引用[1]和引用[2]，Checkpoint机制是为了管理NameNode的元数据，防止EditLog过大，并提高NameNode的恢复速度。下面我将详细解释Checkpoint流程。 ### 1. 为什么需要Checkpoint？ - NameNode将文件系统的元数据存储在内存中，包括文件与数据块的映射关系、数据块的位置等。 - 为了持久化元数据，NameNode使用两个关键文件： - **FsImage**：文件系统元数据的完整快照（存储在磁盘上）。 - **EditLog**：记录自FsImage生成后所有元数据的更改操作（追加写入）。 - 随着时间推移，EditLog会变得非常大，导致以下问题： - NameNode重启时需要加载FsImage并重放所有EditLog中的操作，耗时很长。 - 过大的EditLog文件可能占用过多磁盘空间，且增加操作延迟。 - Checkpoint机制通过定期合并FsImage和EditLog，生成新的FsImage，并清空EditLog，从而解决上述问题。 ### 2. Checkpoint执行流程 Checkpoint由Secondary NameNode（或Standby NameNode在高可用HA模式下）触发并执行。以下是详细步骤： #### 步骤1：触发条件 - **时间间隔**：默认每隔1小时（由`dfs.namenode.checkpoint.period`配置，单位秒）。 - **EditLog大小**：当EditLog达到一定大小（默认64MB，由`dfs.namenode.checkpoint.txns`配置）时也会触发。 #### 步骤2：Secondary NameNode请求Checkpoint 1. Secondary NameNode向Active NameNode发送HTTP请求，触发Checkpoint。 2. Active NameNode停止使用当前的EditLog文件（如`edits_inprogress_001`），并创建一个新的EditLog文件（如`edits_inprogress_002`）用于记录后续操作。 #### 步骤3：获取FsImage和EditLog - Secondary NameNode通过HTTP GET从NameNode下载： - 最新的FsImage文件（如`fsimage_0000000001`）。 - 待合并的EditLog文件（如`edits_001-002`）。 #### 步骤4：合并操作 - Secondary NameNode将FsImage加载到内存，并逐条重放EditLog中的操作，生成一个新的元数据快照。 - 合并完成后生成一个新的FsImage文件（如`fsimage.ckpt_0000000002`）。 #### 步骤5：上传新FsImage - Secondary NameNode将新生成的FsImage上传回Active NameNode。 - Active NameNode将接收到的FsImage重命名（如`fsimage_0000000002`），替换旧的FsImage。 #### 步骤6：清理旧文件 - 删除已合并的EditLog文件（如`edits_001-002`）。 ### 3. 高可用（HA）模式下的变化 在HA架构中（Hadoop 2.0+）： - **没有Secondary NameNode**，由Standby NameNode执行Checkpoint。 - Standby NameNode定期从共享存储（如JournalNode）读取EditLog，合并生成新FsImage后上传回共享存储。 - 触发机制相同（时间或EditLog大小）。 ### 4. 关键配置参数 | 参数名 | 默认值 | 说明 | |--------|--------|------| | `dfs.namenode.checkpoint.period` | 3600秒（1小时） | 两次Checkpoint的时间间隔 | | `dfs.namenode.checkpoint.txns` | 100万次操作 | 触发Checkpoint的EditLog操作次数阈值 | | `dfs.namenode.checkpoint.max-retries` | 3 | 合并失败最大重试次数 | ### 5. Checkpoint对系统的影响 - **优点**： - 缩短NameNode启动时间（只需加载最新的FsImage和少量EditLog）。 - 减少EditLog磁盘占用。 - **缺点**： - 合并过程消耗大量CPU和内存，可能短暂影响集群性能（建议在低峰期执行）。 ### 6. 手动触发Checkpoint 管理员可通过命令强制触发： ```bash hdfs dfsadmin -saveNamespace ``` ### 7. 安全模式与Checkpoint - NameNode启动时自动进入安全模式（只读状态），此时会执行一次Checkpoint（如果FsImage已过期）[^3]。 - 安全模式退出条件之一：DataNode上报的数据块达到总副本数的99.9%（可配置）。 --- ### 流程图表示Checkpoint过程 ```mermaid sequenceDiagram participant A as Active NameNode participant S as Secondary/Standby NN participant J as JournalNode (HA) Note over A: 持续写入EditLog S->>A: 1. 触发Checkpoint请求 A->>A: 2. 滚动EditLog (创建新文件) A->>S: 3. 发送FsImage和EditLog S->>S: 4. 合并FsImage+EditLog → 新FsImage S->>A: 5. 上传新FsImage A->>A: 6. 替换旧FsImage，清理EditLog Note over J: (HA模式) EditLog共享存储 ``` > 提示：Checkpoint是HDFS元数据管理的核心机制，合理配置周期可平衡系统性能与恢复效率[^1][^2]。 --- §§相关问题§§ 1. 如何优化Checkpoint频率以减少对集群性能的影响？ 2. HA模式下Standby NameNode执行Checkpoint失败如何处理？ 3. FsImage和EditLog的存储结构是怎样的？ 4. Checkpoint过程中NameNode宕机会导致什么后果？</think>### Hadoop Checkpoint 流程详解 Hadoop 的 **Checkpoint 机制**是 HDFS 的核心功能，用于管理 NameNode 的元数据（Metadata），防止 EditLog 文件过大，提高 NameNode 的恢复速度和系统稳定性。以下是完整流程解析： --- #### 一、核心组件作用 | 组件 | 作用 | |------------------|----------------------------------------------------------------------| | **FsImage** | 完整的文件系统元数据快照（存储文件/目录结构、权限、数据块映射关系） | | **EditLog** | 记录自上次 FsImage 后所有元数据变更操作（追加写入） | | **NameNode** | 主节点，管理元数据并响应客户端请求 | | **Secondary NN** | 辅助节点（非 HA 模式），负责触发和执行 Checkpoint | | **JournalNode** | 高可用（HA）模式下共享 EditLog 的存储节点 | --- #### 二、Checkpoint 完整流程（非 HA 模式） ```mermaid sequenceDiagram participant NameNode participant SecondaryNN participant Disk Note over NameNode: 持续运行中 NameNode->>Disk: 实时写入EditLog (edits_inprogress_xxx) SecondaryNN->>NameNode: 周期性触发Checkpoint请求 Note right of SecondaryNN: 触发条件：<br/>1. 时间间隔(默认1小时)<br/>2. EditLog大小(默认64MB) NameNode->>Disk: 滚动EditLog：<br/>- 关闭当前edits_inprogress<br/>- 创建新edits_inprogress文件 NameNode->>SecondaryNN: 发送FsImage + 待合并的EditLog SecondaryNN->>SecondaryNN: 合并操作：<br/>1. 加载FsImage到内存<br/>2. 重放EditLog所有操作<br/>3. 生成新FsImage.ckpt SecondaryNN->>NameNode: 回传新FsImage.ckpt NameNode->>Disk: 重命名FsImage.ckpt → 正式FsImage NameNode->>Disk: 删除已合并的旧EditLog ``` ##### 关键步骤详解： 1. **触发条件** - 时间驱动：`dfs.namenode.checkpoint.period`（默认 3600 秒） - 操作数驱动：`dfs.namenode.checkpoint.txns`（默认 100 万次操作） 2. **EditLog 滚动** NameNode 停止写入当前 EditLog，创建新文件继续记录变更。 3. **元数据合并** SecondaryNN 执行： ```python new_fsimage = load_fsimage(old_fsimage) for operation in edit_log: apply_operation(new_fsimage, operation) # 重放所有操作 save_fsimage(new_fsimage) # 生成 fsimage.ckpt_<txid> ``` 4. **原子替换** 新 FsImage 通过重命名（`fsimage.ckpt` → `fsimage_<end-txid>`）完成替换，确保数据一致性。 --- #### 三、HA 模式下的变化 高可用模式下（无 SecondaryNN）： 1. **Standby NameNode** 替代 SecondaryNN 执行 Checkpoint 2. **共享存储**：EditLog 通过 JournalNode 集群共享 3. 合并流程： ```mermaid graph LR A[Active NN] -->|写入| B(JournalNode集群) C[Standby NN] -->|读取| B C -->|合并| D[生成新FsImage] D -->|上传| E[共享存储] ``` --- #### 四、核心配置参数 | 参数 | 默认值 | 作用 | |-------------------------------------|------------|-------------------------------| | `dfs.namenode.checkpoint.period` | 3600 秒 | Checkpoint 触发时间间隔 | | `dfs.namenode.checkpoint.txns` | 1000000 | 触发 Checkpoint 的操作次数阈值 | | `dfs.namenode.num.checkpoints.retained` | 2 | 保留的历史 FsImage 数量 | | `dfs.namenode.num.extra.edits.retained` | 1000000 | 保留的额外 EditLog 操作数 | --- #### 五、Checkpoint 的重要性 1. **故障恢复加速** NameNode 重启时只需加载最新 FsImage + 少量新 EditLog（无需重放全部历史操作）[^1]。 2. **防止 EditLog 膨胀** 避免单个 EditLog 文件过大导致磁盘空间不足或 IO 性能下降。 3. **元数据一致性** 通过定期快照确保元数据状态可回溯（保留多个历史 FsImage）[^2]。 4. **安全模式关联** NameNode 启动时自动进入安全模式（只读状态），此时会强制执行 Checkpoint 确保元数据完整[^3]。 --- #### 六、运维命令 1. **手动触发 Checkpoint**： ```bash hdfs dfsadmin -saveNamespace ``` 2. **检查合并状态**： ```bash hdfs haadmin -getServiceState nn1 # 查看NameNode角色 hdfs oiv -p XML -i fsimage_000000000025 | head # 解析FsImage内容 ``` > ⚠️ **注意**：Checkpoint 过程会消耗大量 CPU 和内存，建议在低负载时段执行。 ---
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值