尧图网站建设 
0 .关于HadoopHadoop由三部分组成分别是HDFS、YARN、MapReduce。Hadoop中包含两个集群架构分别是HDFS集群和YARN集群。0.1 关于HDFS英文全称Hadoop Distributed File System中文全称Hadoop 分布式文件系统HDFS主要负责海量数据的分布式存储HDFS集群是主从架构HDFS集群主要由NameNode、SecondaryNameNode、StandByNameNode(HA高可用环境)、DataNode四个角色组成。组件简称角色存储内容NameNodeNN主节点元数据目录、权限、块信息SecondaryNameNodeSNN辅助节点合并 fsimageedits非热备StandbyNameNodeStandby NNHA 高可用架构下的备用主节点实时同步 Active NN 的内存元数据、操作日志edits与 Active NN 共享 QJM 集群的编辑日志不存储真实业务数据DataNodeDN从节点真实数据 Block 数据块NameNode(NN)HDFS 主节点只保存元数据 (metadata)。元数据包含三类信息文件和目录的名字、权限、所有者、修改时间文件被切分成哪些数据块Block每个块存放在哪些 DataNode 主机上块位置信息两大核心文件fsimage 镜像文件HDFS 文件系统完整元数据快照保存目录树、文件属性、块列表磁盘上的持久镜像启动时加载到内存edits 编辑日志所有对 HDFS 的增删改操作创建文件、删除、重命名,CRU先写 edits 日志相当于操作日志类似数据库的 redo log工作流程客户端修改 HDFS(CRU)→NameNode 先写 edits 日志落盘 → 更新内存元数据,fsimage 不会实时更新。NN工作原理图SecondaryNameNode(SNN)⚠️ 不是 NameNode 的备份不能做高可用故障切换定期合并 fsimage edits生成新 fsimage防止 edits 日志无限膨胀。SNN 会拉取 NN 的 fsimage 和 edits合并后传回 NameNode。旧版本 HDFSNN 宕机只能依靠 SNN 的合并镜像恢复会丢失 edits 中未合并的操作。SNN工作原理图StandbyNameNode(Standby NN)Standby NN是 HDFS‑HA高可用架构中的组件Hadoop2.0 引入用来解决旧版 NameNode 单点故障问题。HA 架构双 NameNodeActiveNameNode活跃 NN StandbyNameNode备用 NNStandby NN热备主节点不对外提供客户端读写服务只做待命。Active NN对外处理所有客户端请求。当 Active NN 宕机Standby NN 可以快速切换升级为 Active接管整个 HDFS 集群实现故障转移。✅重点区分StandbyNameNode(Standby NN)和 SecondaryNameNode (SNN) 完全不同SNN冷备定时合并镜像不能接管集群HA 环境下直接废弃不再使用 SNN。Standby NN实时热备可以升级为主节点接管集群。HDFS HA架构图客户端请求↓Active NameNode(对外服务)↓(写edits日志)JournalNode集群QJM共享edits↓(读edits回放日志)Standby NameNode待命热备DataNode →同时上报块报告→ Active NN、Standby NNZookeeper ZKFC(ZKFailoverController进程监控、选举、故障自动切换✅正常运行阶段1.客户端请求发送到 Active NameNode。2.Active NameNode 处理元数据变更把 edits 日志写入 JournalNode 集群多数 JN 写入成功才算生效。3.Standby NN 持续读取 JournalNode 上的 edits 日志在自己内存回放元数据时刻和 Active 保持一致。4.所有 DataNode 同时向 Active、Standby 上报块信息。5.Standby NN 自己周期性执行 checkpoint生成 fsimage 镜像不再需要 SecondaryNameNode。⚠️故障切换流程Active 宕机1.ZKFC 检测本机 Active NameNode异常断开Zookeeper会话释放zk 锁。2.Standby 的 ZKFC 抢占 Zookeeper 锁。3.Standby NN 确认读完 JournalNode 全部 edits 日志保证元数据完整。4.Standby 切换升级为Active NameNode对外提供服务集群继续工作。图中各组件说明: 架构组成ActiveNameNode StandbyNameNode JournalNode (JN 集群) Zookeeper ZKFC DataNode Active NameNode活跃主节点处理客户端所有读写请求。 Standby NameNode备用主节点不对外服务实时同步元数据等待故障切换。 JournalNode (JN奇数台一般 3 个)QJM 共享存储保存 edits 编辑日志。Active 把操作日志写入 JN 集群Standby 持续读取 JN 的 edits 日志在本机内存回放实现元数据实时同步。 ZKFCZKFailoverController每个 NameNode 配套一个 ZKFC 进程监控 NN 健康和 Zookeeper 交互负责主备选举、故障自动切换。 Zookeeper 集群实现锁选举保存故障状态。谁拿到 zk 临时节点锁谁成为 Active。 DataNode同时向 Active、Standby 上报 Block‑report 块报告两个 NN 内存都有完整块位置信息。 QJM 全称Quorum Journal Manager 中文仲裁日志管理器 工作逻辑: Active NameNode活跃 NN产生元数据变更把 edits 日志写入全部 JournalNode 集群半数以上 JN 写入成功才算写成功quorum 仲裁机制。 Standby NameNode备用 NN持续读取 JournalNode 上的 edits 日志在本机内存回放实现元数据实时同步。DataNode(DN)HDFS 的从节点Slave集群中实际存储数据的节点。HDFS 文件会被切分成固定大小 Block默认 128M真正的文件数据保存在 DataNode 磁盘NameNode 只存元数据不存真实数据。执行客户端读写请求客户端直接和 DataNode 交互读写数据。向 NameNode 上报信息心跳 (heartbeat)周期性上报心跳告诉 NN 自己还活着超时收不到心跳NN 判定 DN 死亡。块报告 (block report)上报本机上保存的所有 Block 块信息。维护数据副本HDFS 默认副本数 3DN 之间做副本复制DN 宕机后NN 检测到副本不足会在其他存活 DN 上自动补副本。HA 架构下DataNode 会同时向 Active NameNode 和 Standby NameNode 上报心跳与块报告。DataNode磁盘存储内容Block 数据块真实的文件二进制数据。Block 元数据文件记录块数据的校验和用于检测数据是否损坏。生成戳可以理解成数据块的“版本号”⚠️DataNode 不保存文件目录、权限这些元数据只管一块块的原始数据。✅读文件1.客户端向 NameNode 获取文件的块位置。2.客户端直接连接 DataNode 读取 Block 数据不再经过 NameNode。✅写文件1.NameNode 分配块返回一组 DataNode 列表。2.客户端把数据写入第一个 DN流水线复制传给下一个 DN完成多副本保存。数据全程不走 NameNode。✅Datanode 的失效处理1.DataNode 长时间不发送心跳 → NameNode 判定该 DN 死亡。2.NameNode 检测到此 DN 上的数据副本变少。3.NameNode 触发副本重建在其他健康 DataNode 复制块保证副本数量达标。0.2 关于YARNYARN Yet Another Resource Negotiator中文资源协调器是 Hadoop2.0 引入的资源调度框架。作用把 Hadoop1.0 中 JobTracker 的两大职责拆分资源管理 任务调度。Hadoop1.0MapReduce v1JobTracker 一身二职资源调度 运行任务存在单点瓶颈。Hadoop2.0YARN 作为通用资源管理器不只支持 MapReduce还能运行 Spark、Flink、Hive 等计算框架。YARN 的四大核心组件包括ResourceManagerRM资源管理器、NodeManagerNM节点管理器、ApplicationMasterAM应用程序管理器、Container容器。组件简称角色部署位置ResourceManagerRM集群资源总调度主节点集群一台HA 双机NodeManagerNM单机资源管理所有服务器节点ApplicationMasterAM单个应用管理者动态启动在 Container 中Container—资源最小隔离单元由 NodeManager 创建ResourceManagerRM资源管理器✅ 整个YARN集群的主节点全局老大管理整个集群所有服务器资源CPU、内存接收客户端提交的应用程序Application分配资源调度启动 ApplicationMaster监控所有 NodeManager内置调度器Scheduler,负责资源分配RM地位日志示意图从图中日志可以直观的看到mapreduce示例程序提交后,ResourceManager是第一个接到请求的。RM 单点问题可以开启 RM HA主备 ResourceManager。NodeManagerNM节点管理器✅单个节点的“管理员”管理本机服务器资源内存、CPU定时向 RM 发送心跳接收 RM 指令启动 / 停止容器Container监控本机运行任务的资源占用负责日志收集ApplicationMasterAM应用程序管理器✅ 每个应用程序单独启动一个 AM任务专属AM是应用的“项目负责人”向 RM 申请运行任务需要的资源和 NM 通信启动 Container 运行任务监控本应用所有任务运行状态任务失败时向 RM 申请资源重试重点一个任务对应一个 AMAM 本身也运行在 Container 中。Container容器✅ YARN 资源分配的最小单位封装资源内存、CPU所有任务AM、MapTask、ReduceTask都运行在 Container 里面Container 本质是进程资源隔离不是 Docker 容器YARN 完整运行流程客户端向 ResourceManager 提交任务RM 接收请求通过调度器分配一台 NodeManagerRM 命令该 NM 启动一个 Container运行 ApplicationMasterAMAM 启动后向 RM 注册AM 向 RM 申请运行 Task 所需的一批 Container 资源RM 调度资源AM 和对应 NodeManager 通信NM 启动多个 Container运行具体任务Map/Reduce任务运行完毕AM 向 RM 注销释放资源。客户端↓提交任务ResourceManager(RM)↓分配资源启动AMNodeManager → 启动Container运行ApplicationMaster↓AM向RM申请更多资源↓RM分配资源 → 多个NodeManager启动Container执行Task任务执行完成 → 释放资源YARN 三大调度器Scheduler✅ Scheduler 是 RM 内部模块只负责资源分配不监控任务。FIFO 调度器先进先出简单任务排队执行生产几乎不用。容量调度器 Capacity SchedulerApache 默认划分多个队列每个队列分配一定资源多用户共享集群。公平调度器 Fair SchedulerCDH 默认动态调整资源长期运行下各个任务公平占用资源。YARN HAResourceManager 高可用两个 RMActive RM对外提供服务、Standby RM备用使用 Zookeeper 实现故障自动切换使用 ZK 存储应用状态故障切换后任务不丢失。YARN工作流程图1、解决hive元数据存储在MySQL中中文乱码的情况因为MySQL默认编码是Latin1– 1. 修改字段注释的编码– 解决DESCRIBE 表时列的中文注释显示乱码ALTER TABLE hive_metastore.COLUMNS_V2 MODIFY COLUMN COMMENT VARCHAR(256) CHARACTER SET utf8;– 2. 修改表级参数的编码– 解决表的中文注释、或者自定义的中文属性显示乱码ALTER TABLE hive_metastore.TABLE_PARAMS MODIFY COLUMN PARAM_VALUE VARCHAR(4000) CHARACTER SET utf8;– 3. 修改分区参数的编码– 解决分区的中文描述显示乱码ALTER TABLE hive_metastore.PARTITION_PARAMS MODIFY COLUMN PARAM_VALUE VARCHAR(4000) CHARACTER SET utf8;– 4. 修改分区键注释的编码ALTER TABLE hive_metastore.PARTITION_KEYS MODIFY COLUMN PKEY_COMMENT VARCHAR(4000) CHARACTER SET utf8;– 5. 修改索引参数的编码ALTER TABLE hive_metastore.INDEX_PARAMS MODIFY COLUMN PARAM_VALUE VARCHAR(4000) CHARACTER SET utf8;HIVE SQL1.Hive SQL_DML_load 加载数据LOAD DATA LOCAL INPATH /home/hadoop/file/archer.txt INTO TABLE itheima.t_archer;这里需要注意的是这个LOCAL本地指的是hiveserver2服务器端所在的物理服务器我这里把metastore.service运行在master(172.16.34.150)的9820端口上把hiveserver2.service运行在slave2(172.16.34.151)的10000端口上所以我这里用beeline运行的LOCAL就指的是slave2当然这跟我在Slave2上用beeline客户端连接hiveserver2.service无关换句话说如果我此刻在slave1上用beeline客户端连接hiveserver2.serevice那么LOCAL依然指的是Slave2服务器。注hiveserver2是cs架构有服务器端和客户端。 学习大数据开发
0 .关于HadoopHadoop由三部分组成分别是HDFS、YARN、MapReduce。Hadoop中包含两个集群架构分别是HDFS集群和YARN集群。0.1 关于HDFS英文全称Hadoop Distributed File System中文全称Hadoop 分布式文件系统HDFS主要负责海量数据的分布式存储HDFS集群是主从架构HDFS集群主要由NameNode、SecondaryNameNode、StandByNameNode(HA高可用环境)、DataNode四个角色组成。组件简称角色存储内容NameNodeNN主节点元数据目录、权限、块信息SecondaryNameNodeSNN辅助节点合并 fsimageedits非热备StandbyNameNodeStandby NNHA 高可用架构下的备用主节点实时同步 Active NN 的内存元数据、操作日志edits与 Active NN 共享 QJM 集群的编辑日志不存储真实业务数据DataNodeDN从节点真实数据 Block 数据块NameNode(NN)HDFS 主节点只保存元数据 (metadata)。元数据包含三类信息文件和目录的名字、权限、所有者、修改时间文件被切分成哪些数据块Block每个块存放在哪些 DataNode 主机上块位置信息两大核心文件fsimage 镜像文件HDFS 文件系统完整元数据快照保存目录树、文件属性、块列表磁盘上的持久镜像启动时加载到内存edits 编辑日志所有对 HDFS 的增删改操作创建文件、删除、重命名,CRU先写 edits 日志相当于操作日志类似数据库的 redo log工作流程客户端修改 HDFS(CRU)→NameNode 先写 edits 日志落盘 → 更新内存元数据,fsimage 不会实时更新。NN工作原理图SecondaryNameNode(SNN)⚠️ 不是 NameNode 的备份不能做高可用故障切换定期合并 fsimage edits生成新 fsimage防止 edits 日志无限膨胀。SNN 会拉取 NN 的 fsimage 和 edits合并后传回 NameNode。旧版本 HDFSNN 宕机只能依靠 SNN 的合并镜像恢复会丢失 edits 中未合并的操作。SNN工作原理图StandbyNameNode(Standby NN)Standby NN是 HDFS‑HA高可用架构中的组件Hadoop2.0 引入用来解决旧版 NameNode 单点故障问题。HA 架构双 NameNodeActiveNameNode活跃 NN StandbyNameNode备用 NNStandby NN热备主节点不对外提供客户端读写服务只做待命。Active NN对外处理所有客户端请求。当 Active NN 宕机Standby NN 可以快速切换升级为 Active接管整个 HDFS 集群实现故障转移。✅重点区分StandbyNameNode(Standby NN)和 SecondaryNameNode (SNN) 完全不同SNN冷备定时合并镜像不能接管集群HA 环境下直接废弃不再使用 SNN。Standby NN实时热备可以升级为主节点接管集群。HDFS HA架构图客户端请求↓Active NameNode(对外服务)↓(写edits日志)JournalNode集群QJM共享edits↓(读edits回放日志)Standby NameNode待命热备DataNode →同时上报块报告→ Active NN、Standby NNZookeeper ZKFC(ZKFailoverController进程监控、选举、故障自动切换✅正常运行阶段1.客户端请求发送到 Active NameNode。2.Active NameNode 处理元数据变更把 edits 日志写入 JournalNode 集群多数 JN 写入成功才算生效。3.Standby NN 持续读取 JournalNode 上的 edits 日志在自己内存回放元数据时刻和 Active 保持一致。4.所有 DataNode 同时向 Active、Standby 上报块信息。5.Standby NN 自己周期性执行 checkpoint生成 fsimage 镜像不再需要 SecondaryNameNode。⚠️故障切换流程Active 宕机1.ZKFC 检测本机 Active NameNode异常断开Zookeeper会话释放zk 锁。2.Standby 的 ZKFC 抢占 Zookeeper 锁。3.Standby NN 确认读完 JournalNode 全部 edits 日志保证元数据完整。4.Standby 切换升级为Active NameNode对外提供服务集群继续工作。图中各组件说明: 架构组成ActiveNameNode StandbyNameNode JournalNode (JN 集群) Zookeeper ZKFC DataNode Active NameNode活跃主节点处理客户端所有读写请求。 Standby NameNode备用主节点不对外服务实时同步元数据等待故障切换。 JournalNode (JN奇数台一般 3 个)QJM 共享存储保存 edits 编辑日志。Active 把操作日志写入 JN 集群Standby 持续读取 JN 的 edits 日志在本机内存回放实现元数据实时同步。 ZKFCZKFailoverController每个 NameNode 配套一个 ZKFC 进程监控 NN 健康和 Zookeeper 交互负责主备选举、故障自动切换。 Zookeeper 集群实现锁选举保存故障状态。谁拿到 zk 临时节点锁谁成为 Active。 DataNode同时向 Active、Standby 上报 Block‑report 块报告两个 NN 内存都有完整块位置信息。 QJM 全称Quorum Journal Manager 中文仲裁日志管理器 工作逻辑: Active NameNode活跃 NN产生元数据变更把 edits 日志写入全部 JournalNode 集群半数以上 JN 写入成功才算写成功quorum 仲裁机制。 Standby NameNode备用 NN持续读取 JournalNode 上的 edits 日志在本机内存回放实现元数据实时同步。DataNode(DN)HDFS 的从节点Slave集群中实际存储数据的节点。HDFS 文件会被切分成固定大小 Block默认 128M真正的文件数据保存在 DataNode 磁盘NameNode 只存元数据不存真实数据。执行客户端读写请求客户端直接和 DataNode 交互读写数据。向 NameNode 上报信息心跳 (heartbeat)周期性上报心跳告诉 NN 自己还活着超时收不到心跳NN 判定 DN 死亡。块报告 (block report)上报本机上保存的所有 Block 块信息。维护数据副本HDFS 默认副本数 3DN 之间做副本复制DN 宕机后NN 检测到副本不足会在其他存活 DN 上自动补副本。HA 架构下DataNode 会同时向 Active NameNode 和 Standby NameNode 上报心跳与块报告。DataNode磁盘存储内容Block 数据块真实的文件二进制数据。Block 元数据文件记录块数据的校验和用于检测数据是否损坏。生成戳可以理解成数据块的“版本号”⚠️DataNode 不保存文件目录、权限这些元数据只管一块块的原始数据。✅读文件1.客户端向 NameNode 获取文件的块位置。2.客户端直接连接 DataNode 读取 Block 数据不再经过 NameNode。✅写文件1.NameNode 分配块返回一组 DataNode 列表。2.客户端把数据写入第一个 DN流水线复制传给下一个 DN完成多副本保存。数据全程不走 NameNode。✅Datanode 的失效处理1.DataNode 长时间不发送心跳 → NameNode 判定该 DN 死亡。2.NameNode 检测到此 DN 上的数据副本变少。3.NameNode 触发副本重建在其他健康 DataNode 复制块保证副本数量达标。0.2 关于YARNYARN Yet Another Resource Negotiator中文资源协调器是 Hadoop2.0 引入的资源调度框架。作用把 Hadoop1.0 中 JobTracker 的两大职责拆分资源管理 任务调度。Hadoop1.0MapReduce v1JobTracker 一身二职资源调度 运行任务存在单点瓶颈。Hadoop2.0YARN 作为通用资源管理器不只支持 MapReduce还能运行 Spark、Flink、Hive 等计算框架。YARN 的四大核心组件包括ResourceManagerRM资源管理器、NodeManagerNM节点管理器、ApplicationMasterAM应用程序管理器、Container容器。组件简称角色部署位置ResourceManagerRM集群资源总调度主节点集群一台HA 双机NodeManagerNM单机资源管理所有服务器节点ApplicationMasterAM单个应用管理者动态启动在 Container 中Container—资源最小隔离单元由 NodeManager 创建ResourceManagerRM资源管理器✅ 整个YARN集群的主节点全局老大管理整个集群所有服务器资源CPU、内存接收客户端提交的应用程序Application分配资源调度启动 ApplicationMaster监控所有 NodeManager内置调度器Scheduler,负责资源分配RM地位日志示意图从图中日志可以直观的看到mapreduce示例程序提交后,ResourceManager是第一个接到请求的。RM 单点问题可以开启 RM HA主备 ResourceManager。NodeManagerNM节点管理器✅单个节点的“管理员”管理本机服务器资源内存、CPU定时向 RM 发送心跳接收 RM 指令启动 / 停止容器Container监控本机运行任务的资源占用负责日志收集ApplicationMasterAM应用程序管理器✅ 每个应用程序单独启动一个 AM任务专属AM是应用的“项目负责人”向 RM 申请运行任务需要的资源和 NM 通信启动 Container 运行任务监控本应用所有任务运行状态任务失败时向 RM 申请资源重试重点一个任务对应一个 AMAM 本身也运行在 Container 中。Container容器✅ YARN 资源分配的最小单位封装资源内存、CPU所有任务AM、MapTask、ReduceTask都运行在 Container 里面Container 本质是进程资源隔离不是 Docker 容器YARN 完整运行流程客户端向 ResourceManager 提交任务RM 接收请求通过调度器分配一台 NodeManagerRM 命令该 NM 启动一个 Container运行 ApplicationMasterAMAM 启动后向 RM 注册AM 向 RM 申请运行 Task 所需的一批 Container 资源RM 调度资源AM 和对应 NodeManager 通信NM 启动多个 Container运行具体任务Map/Reduce任务运行完毕AM 向 RM 注销释放资源。客户端↓提交任务ResourceManager(RM)↓分配资源启动AMNodeManager → 启动Container运行ApplicationMaster↓AM向RM申请更多资源↓RM分配资源 → 多个NodeManager启动Container执行Task任务执行完成 → 释放资源YARN 三大调度器Scheduler✅ Scheduler 是 RM 内部模块只负责资源分配不监控任务。FIFO 调度器先进先出简单任务排队执行生产几乎不用。容量调度器 Capacity SchedulerApache 默认划分多个队列每个队列分配一定资源多用户共享集群。公平调度器 Fair SchedulerCDH 默认动态调整资源长期运行下各个任务公平占用资源。YARN HAResourceManager 高可用两个 RMActive RM对外提供服务、Standby RM备用使用 Zookeeper 实现故障自动切换使用 ZK 存储应用状态故障切换后任务不丢失。YARN工作流程图1、解决hive元数据存储在MySQL中中文乱码的情况因为MySQL默认编码是Latin1– 1. 修改字段注释的编码– 解决DESCRIBE 表时列的中文注释显示乱码ALTER TABLE hive_metastore.COLUMNS_V2 MODIFY COLUMN COMMENT VARCHAR(256) CHARACTER SET utf8;– 2. 修改表级参数的编码– 解决表的中文注释、或者自定义的中文属性显示乱码ALTER TABLE hive_metastore.TABLE_PARAMS MODIFY COLUMN PARAM_VALUE VARCHAR(4000) CHARACTER SET utf8;– 3. 修改分区参数的编码– 解决分区的中文描述显示乱码ALTER TABLE hive_metastore.PARTITION_PARAMS MODIFY COLUMN PARAM_VALUE VARCHAR(4000) CHARACTER SET utf8;– 4. 修改分区键注释的编码ALTER TABLE hive_metastore.PARTITION_KEYS MODIFY COLUMN PKEY_COMMENT VARCHAR(4000) CHARACTER SET utf8;– 5. 修改索引参数的编码ALTER TABLE hive_metastore.INDEX_PARAMS MODIFY COLUMN PARAM_VALUE VARCHAR(4000) CHARACTER SET utf8;HIVE SQL1.Hive SQL_DML_load 加载数据LOAD DATA LOCAL INPATH /home/hadoop/file/archer.txt INTO TABLE itheima.t_archer;这里需要注意的是这个LOCAL本地指的是hiveserver2服务器端所在的物理服务器我这里把metastore.service运行在master(172.16.34.150)的9820端口上把hiveserver2.service运行在slave2(172.16.34.151)的10000端口上所以我这里用beeline运行的LOCAL就指的是slave2当然这跟我在Slave2上用beeline客户端连接hiveserver2.service无关换句话说如果我此刻在slave1上用beeline客户端连接hiveserver2.serevice那么LOCAL依然指的是Slave2服务器。注hiveserver2是cs架构有服务器端和客户端。