LOADING

缓存加载中...

BIGdata

2025/7/10

HDFS

架构

client<->namenode(active)<->namenode(standby)

其中namenode一个对应多个datanode,每个datanode中三个数据的block(128MB，大文件拆成等大的这种块),一般一个数据会复制成三个block放在不同节点来保证可用。

block

  • 如果要调block大小：块小：寻址时间长，并发高。块小：并发低。
  • block存放策略：1.与client相同节点（最近）2.与副本1不同的机架。3.与2同机架的不同节点上。（权衡性能与安全）。

meta存储

datanode会通过心跳机制(每3s)上报meta信息，如果没有传来心跳则触发容灾。

磁盘中持久化的内容：edits和fsimage.

  • edits:节点变动的日志（ckpt之后）。
  • fsimage:某ckpt时节点内存中元数据的状态镜像。
    持久化过程：
    (1.x)类似于数据库在ckpt时的合并机制。
    (2.x)实现了HA(高可用)。依靠分布式共识Paxos,弄一堆journalnode,实现QuorumJournalManager(共享存储系统)，这样fsimage写本地，edit并发写到journalnode保证容灾。定期同步edit进入standby，合并再上传active的namenode.

读写

写：

  1. Client向Namenode发送写请求。
  2. namenode检查目录并鉴权。
  3. namenode允许上传。
  4. client内将file拆分成block。
  5. client请求上传block。
  6. namenode给数据分配datanode。
  7. namenode向client返回datanode。
  8. client与datanode建立传输连接(pipeline形式)。
    8.1 datanode之间建立pipeline。
  9. client向datanode发送数据packet。
    9.1最后一个datanode成功持久化以后逐级向上返回成功信息。
  10. 写入成功，在namenode生成元数据。

读：


client发送请求，namenode返回datanode列表(namenode进行过排序，网络拓扑找最近的)，client连接datanode并拉取。

安全模式

HDFS变成只读状态。

  • 触发条件：block的上报率小于阈值。

  • 离开安全模式：上报达到阈值(默认0.999)。

  • 常见原因：
    namenode重启
    namenode磁盘空间不足
    block上报低于阈值
    datanode无法正常启动
    在日志中严重异常
    用户强制关机

  • 排查
    找到datanode不能启动原因，重启
    清理namenode磁盘

高可用

劣势：
namenode内存受限。解决：联邦(federation机制)。
namenode单点故障。解决：HA

zookeepeer：启动多个进程(failovercontroller)，协调服务监控namenode实现HA。

操作命令

shell(运维)

hadoop fs <args>可操作任何文件系统

URL:单个hdfs可以用简写，多个用全写hdfs://nameservice/parent/child ，配置文件有基本信息

restAPI

跨平台。
IP+端口+指定操作目录，PUT/GET/DELETE

运维管理

core-site.xmlhadoop全局配置
hdfs-site.xmlhdfs局部配置

<configuration>
  <property>
    这里是相关配置！
  </property>
</configuration>

环境变量:hadoop-env.sh。
distcp分布式拷贝（并发，转换为mapreduce任务）

yarn,分布式资源管理系统

hadoop1.x中，HDFS存储，mapreduce做计算和资源管理。

解决的问题：通用！

架构


主从，资源管理和任务调度分离。

三种角色：ResourceManager主,NodeManager从，ApplicationMaster.

两种管理：

  1. 管理具体的作业实例(作业解析/资源申请/任务调度)。任务！
  2. 管理节点资源和容器生命周期，并封装进程相关资源，运行具体任务。资源！

task比job粒度更细。

zookeeper帮助yarn的节点选举，实现HA。

调度策略

三种

  1. FIFO
    策略：所有任务放入一个queue,先进的任务先得到资源，排在后面的任务等待。
    缺点：无法交叉运行，紧急任务无法插队，不灵活，资源利用率低。
  2. 容量
    提前预算，预算指导下分享集群资源。
    策略：集群资源有多个队列分享，每个队列预设资源分配比例，资源优先给“实际资源/预算资源”比值最低的队列。队列内部FIFO。
    层次化（子队列用父队列）/容量保证/弹性分配/动态管理/访问权限控制/多租户
  3. 公平
    策略：多队列公平共享，评分方式动态分配资源。队列内部FIFO或者Fair(default)。
    资源抢占：终止其他队列任务，使其让出所占资源，资源分配给占用资源量少于最小资源量限制的队列。
    队列权重：队列中有任务等待，且集群中有空闲资源时，每个队列可以根据权重获得不同比例空闲资源。

队列划分：根队列root，其余子队列继承以.连接。

运维监控

杀死：yarn application -list找到pid再-kill，ctrlC不能终止。

mapreduce

批处理，分布式计算。

Map映射（得到中间部分的结果，处理成(k,v)形式），-shuffle（慢，主要是节点间合并->M传输R->R节点缓存->分组排序）->Reduce合并化简。

shuffle阶段：

  • 适用：数据统计/搜索引擎索引构建/复杂数据分析算法实现/海量数据。
  • 不适用：OLAP/流计算(mr是静态的)/DAG(作业互相依赖)。

作业运行：参考yarn

spark

统一计算框架：流批、交互、ml

有on yarn运行模式。

RDD

ResilientDistributeDataset弹性分布式数据集。

分布在集群中只读对象集合，多个partition组成，转换操作构造，失效后自动重构(弹性)，存储在内存或磁盘中。

计算时，RDD构成DAG图。

两种操作：

  1. transformation：将scala集合或者hadoop的输入数据构造成新RDD,或者已有RDD转换成新RDD。惰性执行：只记录转换，不计算。
  2. action：真正触发计算，RDD得到值出来。

依赖：

  1. 窄依赖：1对1的RDD转换。map/filter/union
  2. 宽依赖：多对1。xxByKey
    宽依赖要走shuffle,付出代价比窄依赖高很多。

local/standalone/yarn(client交互调试/cluster生产环境)模式

作业解析监控：
Driver中：生成逻辑查询计划，物理查询计划，任务调度。
Executor：任务执行。