做侵权网站用哪里的服务器稳,郑州小程序网站开发,什么是网络营销环境的外部因素,工程建设网站策划方案文章目录 hadoop简单基础面试题1. 请说下 HDFS 读写流程2. HDFS 在读取文件的时候#xff0c;如果其中一个块突然损坏了怎么办3. HDFS 在上传文件的时候#xff0c;如果其中一个 DataNode 突然挂掉了怎么办4. NameNode 在启动的时候会做哪些操作5.Secondary NameNode 了解吗如果其中一个块突然损坏了怎么办3. HDFS 在上传文件的时候如果其中一个 DataNode 突然挂掉了怎么办4. NameNode 在启动的时候会做哪些操作5.Secondary NameNode 了解吗它的工作机制是怎样的6. Secondary NameNode 不能恢复 NameNode 的全部数据那如何保证NameNode 数据存储安全7. 在 NameNode HA 中会出现脑裂问题吗怎么解决脑裂8. 小文件过多会有什么危害如何避免9. 请说下 HDFS 的组织架构10. 请说下 MR 中 Map Task 的工作机制 hadoop简单基础面试题
1. 请说下 HDFS 读写流程
HDFS 写流程
Client 客户端发送上传请求通过 RPC 与 NameNode 建立通信NameNode检查该用户是否有上传权限以及上传的文件是否在 HDFS 对应的目录下重名如果这两者有任意一个不满足则直接报错如果两者都满足则返回给客户端一个可以上传的信息Client 根据文件的大小进行切分默认 128M 一块切分完成之后给NameNode 发送请求第一个 block 块上传到哪些服务器上NameNode 收到请求之后根据网络拓扑和机架感知以及副本机制进行文件分配返回可用的 DataNode 的地址
注Hadoop 在设计时考虑到数据的安全与高效, 数据文件默认在 HDFS 上存放三份, 存储策略为本地一份同机架内其它某一节点上一份, 不同机架的某一节点上一份。
客户端收到地址之后与服务器地址列表中的一个节点如 A 进行通信本质上就是 RPC 调用建立 pipelineA 收到请求后会继续调用 BB 在调用C将整个 pipeline 建立完成逐级返回 ClientClient 开始向 A 上发送第一个 block先从磁盘读取数据然后放到本地内 存缓存以 packet数据包64kb为单位A 收到一个 packet 就会发 送给 B然后 B 发送给 CA 每传完一个 packet 就会放入一个应答队列等待 应答数据被分割成一个个的 packet 数据包在 pipeline 上依次传输在 pipeline 反向传输中逐个发送 ack命令正确应答最终由 pipeline中第一个 DataNode 节点 A 将 pipelineack 发送给 Client当一个block传输完成之后, Client再次请求NameNode上传第二个blockNameNode 重新选择三台 DataNode 给 Client。
HDFS 读流程
Client 向 NameNode 发送 RPC 请求。请求文件 block 的位置NameNode 收到请求之后会检查用户权限以及是否有这个文件如果都符 合则会视情况返回部分或全部的 block 列表对于每个 blockNameNode都会返回含有该 block 副本的 DataNode 地址这些返回的 DataNode 地址会按照集群拓扑结构得出 DataNode 与客户端的距离然后进行排序排 序两个规则网络拓扑结构中距离 Client 近的排靠前心跳机制中超时汇报的 DataNode 状态为 STALE这样的排靠后Client 选取排序靠前的 DataNode 来读取 block如果客户端本身就是 DataNode,那么将从本地直接获取数据(短路读取特性)底层上本质是建立 Socket StreamFSDataInputStream重复的调用父类 DataInputStream 的 read 方法直到这个块上的数据读取完毕当读完列表的 block 后若文件读取还没有结束客户端会继续向NameNode 获取下一批的 block 列表读取完一个 block 都会进行 checksum 验证如果读取 DataNode 时出现错误客户端会通知 NameNode然后再从下一个拥有该 block 副本的DataNode 继续读read 方法是并行的读取 block 信息不是一块一块的读取NameNode 只是 返回 Client 请求包含块的 DataNode 地址并不是返回请求块的数据最终读取来所有的 block 会合并成一个完整的最终文件
2. HDFS 在读取文件的时候如果其中一个块突然损坏了怎么办
客户端读取完 DataNode 上的块之后会进行 checksum 验证也就是把客户端读取到本地的块与 HDFS 上的原始块进行校验如果发现校验结果不一致客户端会通知 NameNode然后再从下一个拥有该 block 副本的 DataNode 继续读。
3. HDFS 在上传文件的时候如果其中一个 DataNode 突然挂掉了怎么办
客户端上传文件时与 DataNode 建立 pipeline 管道管道的正方向是客户端向DataNode 发送的数据包管道反向是 DataNode 向客户端发送 ack 确认也就是正确接收到数据包之后发送一个已确认接收到的应答。当 DataNode 突然挂掉了客户端接收不到这个 DataNode 发送的 ack 确认客户端会通知 NameNodeNameNode 检查该块的副本与规定的不符NameNode 会通知DataNode 去复制副本并将挂掉的 DataNode 作下线处理不再让它参与文件上传与下载。
4. NameNode 在启动的时候会做哪些操作
NameNode 数据存储在内存和本地磁盘本地磁盘数据存储在 fsimage 镜像文件和 edits 编辑日志文件。
首次启动 NameNode 格式化文件系统为了生成 fsimage 镜像文件 启动 NameNode 读取 fsimage 文件将文件内容加载进内存等待 DataNade 注册与发送 block report 启动 DataNode 向 NameNode 注册 发送 block report 检查 fsimage 中记录的块的数量和 block report 中的块的总数是否相同 对文件系统进行操作创建目录上传文件删除文件等
此时内存中已经有文件系统改变的信息但是磁盘中没有文件系统改变的信息此时会将这些改变信息写入 edits 文件中edits 文件中存储的是文件系统元数据改变的信息。
第二次启动 NameNode
读取 fsimage 和 edits 文件将 fsimage 和 edits 文件合并成新的 fsimage 文件创建新的 edits 文件内容开始为空启动 DataNode。
5.Secondary NameNode 了解吗它的工作机制是怎样的
Secondary NameNode 是合并 NameNode 的 edit logs 到 fsimage 文件中
它的具体工作机制 Secondary NameNode 询问 NameNode 是否需要 checkpoint。直接带回NameNode 是否检查结果 Secondary NameNode 请求执行 checkpoint NameNode 滚动正在写的 edits 日志 将滚动前的编辑日志和镜像文件拷贝到 Secondary NameNode Secondary NameNode 加载编辑日志和镜像文件到内存并合并 生成新的镜像文件 fsimage.chkpoint 拷贝 fsimage.chkpoint 到 NameNode NameNode 将 fsimage.chkpoint 重新命名成 fsimage 所以如果 NameNode 中的元数据丢失是可以从 Secondary NameNode 恢复一部分元数据信息的但不是全部因为 NameNode 正在写的 edits 日志还没有拷贝到Secondary NameNode这部分恢复不了。
6. Secondary NameNode 不能恢复 NameNode 的全部数据那如何保证NameNode 数据存储安全
这个问题就要说 NameNode 的高可用了即 NameNode HA。一个 NameNode 有单点故障的问题那就配置双 NameNode配置有两个关键点一是必须要保证这两个 NameNode 的元数据信息必须要同步的二是一个 NameNode 挂掉之后另一个要立马补上。
元数据信息同步在 HA 方案中采用的是“共享存储”。每次写文件时需要将日志同步写入共享存储这个步骤成功才能认定写文件成功。然后备份节点定期从共享存储同步日志以便进行主备切换。监控 NameNode 状态采用 zookeeper两个 NameNode 节点的状态存放在zookeeper 中另外两个 NameNode 节点分别有一个进程监控程序实施读取 zookeeper 中有 NameNode 的状态来判断当前的 NameNode 是不是已经 down 机。如果 Standby 的 NameNode 节点的 ZKFC 发现主节点已经挂掉那么就会强制给原本的 Active NameNode 节点发送强制关闭请求之后将备用的 NameNode 设置为 Active。
如果面试官再问 HA 中的 共享存储 是怎么实现的知道吗
可以进行解释下NameNode 共享存储方案有很多比如 Linux HA, VMware FT, QJM等目前社区已经把由 Clouderea 公司实现的基于 QJMQuorum Journal Manager的方案合并到 HDFS 的 trunk 之中并且作为默认的共享存储实现。基于 QJM 的共享存储系统主要用于保存 EditLog并不保存 FSImage 文件。FSImage文件还是在 NameNode 的本地磁盘上。QJM 共享存储的基本思想来自于 Paxos 算法采用多个称为 JournalNode 的节点组成的 JournalNode 集群来存储 EditLog。每个 JournalNode 保存同样的 EditLog 副本。每次 NameNode 写 EditLog 的时候除了向本地磁盘写入 EditLog 之外也会并行地向 JournalNode 集群之中的每一个 JournalNode 发送写请求只要大多数的JournalNode 节点返回成功就认为向 JournalNode 集群写入 EditLog 成功。如果有2N1 台 JournalNode那么根据大多数的原则最多可以容忍有 N 台 JournalNode节点挂掉。
7. 在 NameNode HA 中会出现脑裂问题吗怎么解决脑裂
假设 NameNode1 当前为 Active 状态NameNode2 当前为 Standby 状态。如果某一时刻 NameNode1 对应的 ZKFailoverController 进程发生了“假死”现象那么Zookeeper 服务端会认为 NameNode1 挂掉了根据前面的主备切换逻辑NameNode2会替代 NameNode1 进入 Active 状态。但是此时 NameNode1 可能仍然处于 Active
状态正常运行这样 NameNode1 和 NameNode2 都处于 Active 状态都可以对外
提供服务。这种情况称为脑裂。
脑裂对于 NameNode 这类对数据一致性要求非常高的系统来说是灾难性的数据会发生错乱且无法恢复。zookeeper 社区对这种问题的解决方法叫做 fencing中文翻译为隔离也就是想办法把旧的 Active NameNode 隔离起来使它不能正常对外提供服务。
在进行 fencing 的时候会执行以下的操作
首先尝试调用这个旧 Active NameNode 的 HAServiceProtocol RPC 接口 的 transitionToStandby 方法看能不能把它转换为 Standby 状态。如果 transitionToStandby 方法调用失败那么就执行 Hadoop 配置文 件之中预定义的隔离措施Hadoop 目前主要提供两种隔离措施通常会选择 sshfence
sshfence通过 SSH 登录到目标机器上执行命令 fuser 将对应的进程杀死
shellfence执行一个用户自定义的 shell 脚本来将对应的进程
隔离。
8. 小文件过多会有什么危害如何避免
Hadoop 上大量 HDFS 元数据信息存储在 NameNode 内存中,因此过多的小文件必定会压垮 NameNode 的内存。
每个元数据对象约占 150byte所以如果有 1 千万个小文件每个文件占用一个block则 NameNode 大约需要 2G 空间。如果存储 1 亿个文件则 NameNode 需要20G 空间。
显而易见的解决这个问题的方法就是合并小文件,可以选择在客户端上传时执行一定的策略先合并,或者是使用 Hadoop 的 CombineFileInputFormatK,V实现小文件的合并。
9. 请说下 HDFS 的组织架构 Client客户端切分文件。文件上传 HDFS 的时候Client 将文件切分成一个一个的 Block然后进行存储与 NameNode 交互获取文件的位置信息与 DataNode 交互读取或者写入数据。Client 提供一些命令来管理 HDFS比如启动关闭 HDFS、访问 HDFS目录及内容等 NameNode名称节点也称主节点存储数据的元数据信息不存储具体 的数据管理 HDFS 的名称空间管理数据块Block映射信息 配置副本策略处理客户端读写请求 DataNode数据节点也称从节点。NameNode 下达命令DataNode 执行实际的操作存储实际的数据块 执行数据块的读/写操作 Secondary NameNode并非 NameNode 的热备。当 NameNode 挂掉的时候它并不能马上替换 NameNode 并提供服务辅助 NameNode分担其工作量 定期合并 Fsimage 和 Edits并推送给 NameNode 在紧急情况下可辅助恢复 NameNode
10. 请说下 MR 中 Map Task 的工作机制
简单概述
inputFile 通过 split 被切割为多个 split 文件通过 Record 按行读取内容给map自己写的处理逻辑的方法 数据被 map 处理完之后交给 OutputCollect收集器对其结果key进行分区默认使用的hashPartitioner然后写入buffer每个 map task 都有一个内存缓冲区环形缓冲区存放着 map 的输出结果当缓冲区快满的时候需要将缓冲区的数据以一个临时文件的方式溢写到磁盘当整个 map task 结束后再对磁盘中这个 maptask 产生的所有临时文件做合并生成最终的正式输出文件然后等待 reduce task 的拉取。
详细步骤
读取数据组件 InputFormat (默认 TextInputFormat) 会通过getSplits 方法对输入目录中的文件进行逻辑切片规划得到 block有多少个 block 就对应启动多少个 MapTask。将输入文件切分为 block 之后由 RecordReader 对象 (默认是LineRecordReader) 进行读取以 \n 作为分隔符, 读取一行数据, 返回keyvalue Key 表示每行首字符偏移值Value 表示这一行文本内容。读取 block 返回 key,value, 进入用户自己继承的 Mapper 类中执行用户重写的 map 函数RecordReader 读取一行这里调用一次。Mapper 逻辑结束之后将 Mapper 的每条结果通过 context.write 进行collect 数据收集。在 collect 中会先对其进行分区处理默认使用HashPartitioner。接下来会将数据写入内存内存中这片区域叫做环形缓冲区(默认 100M) 缓冲区的作用是 批量收集 Mapper 结果减少磁盘 IO 的影响。我们的 Key/Value 对以及 Partition 的结果都会被写入缓冲区。当然写入之前 Key 与 Value 值都会被序列化成字节数组。当环形缓冲区的数据达到溢写比列(默认 0.8)也就是 80M 时溢写线程启动需要对这 80MB 空间内的 Key 做排序 (Sort)。排序是 MapReduce模型默认的行为这里的排序也是对序列化的字节做的排序。合并溢写文件每次溢写会在磁盘上生成一个临时文件 (写之前判断是否有 Combiner)如果 Mapper 的输出结果真的很大有多次这样的溢写发生磁盘上相应的就会有多个临时文件存在。当整个数据处理结束之后开 始对磁盘中的临时文件进行 Merge 合并因为最终的文件只有一个写入磁盘并且为这个文件提供了一个索引文件以记录每个 reduce 对应数据的偏移量。
11. 请说下 MR 中 Reduce Task 的工作机制
简单描述 Reduce 大致分为 copy、sort、reduce 三个阶段重点在前两个阶段。copy 阶段包含一个 eventFetcher 来获取已完成的 map 列表由 Fetcher 线程去 copy 数据在此过程中会启动两个 merge 线程分别为 inMemoryMerger和 onDiskMerger分别将内存中的数据 merge 到磁盘和将磁盘中的数据进行 merge。待数据 copy 完成之后copy 阶段就完成了。 开始进行 sort 阶段sort 阶段主要是执行 finalMerge 操作纯粹的 sort 阶段完成之后就是 reduce 阶段调用用户定义的 reduce 函数进行处理。
详细步骤 Copy 阶段简单地拉取数据。Reduce 进程启动一些数据 copy 线程 (Fetcher)通过 HTTP 方式请求 maptask 获取属于自己的文件map task 的分区会标识每个 map task 属于哪个 reduce task 默认 reduce task 的标识从 0 开始。 Merge 阶段在远程拷贝数据的同时ReduceTask 启动了两个后台线程对内存和磁盘上的文件进行合并以防止内存使用过多或磁盘上文件过多。merge 有三种形式内存到内存内存到磁盘磁盘到磁盘。默认情况下第一种形式不启用。当内存中的数据量到达一定阈值就直接启动内存到磁盘的 merge。与 map 端类似这也是溢写的过程这个过程中如果你设置有 Combiner也是会启用的然后在磁盘中生成了众多的溢写文件。内存到磁盘的 merge 方式一直在运行直到没有 map 端的数据时才结束然后启动第三种磁盘到磁盘的 merge 方式生成最终的文件。 合并排序把分散的数据合并成一个大的数据后还会再对合并后的数据排序。 对排序后的键值对调用 reduce 方法键相等的键值对调用一次 reduce 方 法每次调用会产生零个或者多个键值对最后把这些输出的键值对写入到 HDFS 文件中。
12. 请说下 MR 中 Shuffle 阶段
shuffle 阶段分为四个步骤依次为分区排序规约分组其中前三个步骤在 map 阶段完成最后一个步骤在 reduce 阶段完成。shuffle 是 Mapreduce 的核心它分布在 Mapreduce 的 map 阶段和 reduce阶段。一般把从 Map 产生输出开始到 Reduce 取得数据作为输入之前的过程称作 shuffle。 Collect 阶段将 MapTask 的结果输出到默认大小为 100M 的环形缓冲区 保存的是 key/valuePartition 分区信息等。 Spill 阶段当内存中的数据量达到一定的阀值的时候就会将数据写入本地磁盘在将数据写入磁盘之前需要对数据进行一次排序的操作如果配置了combiner还会将有相同分区号和 key 的数据进行排序。 MapTask 阶段的 Merge把所有溢出的临时文件进行一次合并操作以确保一个 MapTask 最终只产生一个中间数据文件。 Copy 阶段ReduceTask 启动 Fetcher 线程到已经完成 MapTask 的节点上复制一份属于自己的数据这些数据默认会保存在内存的缓冲区中当内存的缓冲区达到一定的阀值的时候就会将数据写到磁盘之上。 ReduceTask 阶段的 Merge在 ReduceTask 远程复制数据的同时会在后 台开启两个线程对内存到本地的数据文件进行合并操作。 Sort 阶段在对数据进行合并的同时会进行排序操作由于 MapTask 阶 段已经对数据进行了局部的排序ReduceTask 只需保证 Copy 的数据的最终整体有效性即可。Shuffle 中的缓冲区大小会影响到 mapreduce 程序的执行效率原则上说缓冲区越大磁盘 io 的次数越少执行速度就越快。缓冲区的大小可以通过参数调整, 参数mapreduce.task.io.sort.mb 默认 100M
13. Shuffle 阶段的数据压缩机制了解吗
在 shuffle 阶段可以看到数据通过大量的拷贝从 map 阶段输出的数据都要通过网络拷贝发送到 reduce 阶段这一过程中涉及到大量的网络 IO如果数据能够进行压缩那么数据的发送量就会少得多。
hadoop 当中支持的压缩算法gzip、bzip2、LZO、LZ4、Snappy这几种压缩算法综合压缩和解压缩的速率谷歌的 Snappy 是最优的一般都选择 Snappy 压缩。谷歌出品必属精品。
14. 在写 MR 时什么情况下可以使用规约
规约combiner是不能够影响任务的运行结果的局部汇总适用于求和类不适用于求平均值如果 reduce 的输入参数类型和输出参数的类型是一样的则规约的类可以使用 reduce 类只需要在驱动类中指明规约的类即可。
15. YARN 集群的架构和工作原理知道多少
YARN 的基本设计思想是将 MapReduce V1 中的 JobTracker 拆分为两个独立的服 务ResourceManager 和 ApplicationMaster。 ResourceManager 负责整个系统的资源管理和分配ApplicationMaster 负责单个应用程序的的管理。 ResourceManager RM 是一个全局的资源管理器负责整个系统的资源管 理和分配它主要由两个部分组成调度器Scheduler和应用程序管理器Application Manager。调度器根据容量、队列等限制条件将系统中的资源分配给正在运行的应用程序在保证容量、公平性和服务等级的前提下优化集群资源利用率让所有的资源都被充分利用应用程序管理器负责管理整个系统中的所有的应用程序包括应用程序的提交、与调度器协商资源以启动 ApplicationMaster、监控ApplicationMaster 运行状态并在失败时重启它。 ApplicationMaster 用户提交的一个应用程序会对应于一个 ApplicationMaster它的主要功能有 与 RM 调度器协商以获得资源资源以 Container 表示。 将得到的任务进一步分配给内部的任务。 与 NM 通信以启动/停止任务。 监控所有的内部任务状态并在任务运行失败的时候重新为任务申请资源以重启任务。 NodeManager NodeManager 是每个节点上的资源和任务管理器一方面它会定期地向 RM 汇报本节点上的资源使用情况和各个 Container 的运行状态另一方面他接收并处理来自 AM 的 Container 启动和停止请求。 Container Container 是 YARN 中的资源抽象封装了各种资源。一个应用程序会分配一个 Container这个应用程序只能使用这个 Container 中描述的资源。不同于 MapReduceV1 中槽位 slot 的资源封装Container 是一个动态资源的划分单位更能充分利用资源。
16. YARN 的任务提交流程是怎样的
当 jobclient 向 YARN 提交一个应用程序后YARN 将分两个阶段运行这个应用程 序一是启动 ApplicationMaster;第二个阶段是由 ApplicationMaster 创建应用程序为它申请资源监控运行直到结束。 具体步骤如下: 用户向 YARN 提交一个应用程序并指定 ApplicationMaster 程序、启动 ApplicationMaster 的命令、用户程序。 RM 为这个应用程序分配第一个 Container并与之对应的 NM 通讯要求它在这个 Container 中启动应用程序 ApplicationMaster。 ApplicationMaster 向 RM 注册然后拆分为内部各个子任务为各个内部任务申请资源并监控这些任务的运行直到结束。 AM 采用轮询的方式向 RM 申请和领取资源。 RM 为 AM 分配资源以 Container 形式返回。 AM 申请到资源后便与之对应的 NM 通讯要求 NM 启动任务。 NodeManager 为任务设置好运行环境将任务启动命令写到一个脚本中并通过运行这个脚本启动任务。 各个任务向 AM 汇报自己的状态和进度以便当任务失败时可以重启任务。 应用程序完成后ApplicationMaster 向 ResourceManager 注销并关闭自己。
17. YARN 的资源调度三种模型了解吗
在 Yarn 中有三种调度器可以选择FIFO Scheduler Capacity SchedulerFair Scheduler。Apache 版本的 hadoop 默认使用的是 Capacity Scheduler 调度方式。CDH 版本的默认使用的是 Fair Scheduler 调度方式
FIFO Scheduler先来先服务
FIFO Scheduler 把应用按提交的顺序排成一个队列这是一个先进先出队列在进行资源分配的时候先给队列中最头上的应用进行分配资源待最头上的应用需求满足后再给下一个分配以此类推。 FIFO Scheduler 是最简单也是最容易理解的调度器也不需要任何配置但它并不适用于共享集群。大的应用可能会占用所有集群资源这就导致其它应用被阻塞比如有个大任务在执行占用了全部的资源再提交一个小任务则此小任务会一直被阻塞。
Capacity Scheduler能力调度器
对于 Capacity 调度器有一个专门的队列用来运行小任务但是为小任务专门设置一个队列会预先占用一定的集群资源这就导致大任务的执行时间会落后于使用 FIFO 调度器时的时间。
Fair Scheduler公平调度器
在 Fair 调度器中我们不需要预先占用一定的系统资源Fair 调度器会为所有运行的 job 动态的调整系统资源。 比如当第一个大 job 提交时只有这一个 job 在运行此时它获得了所有集群资源当第二个小任务提交后Fair 调度器会分配一半资源给这个小任务让这两个任务公平的共享集群资源。
需要注意的是在 Fair 调度器中从第二个任务提交到获得资源会有一定的延迟因为它需要等待第一个任务释放占用的 Container。小任务执行完成之后也会释放自己占用的资源大任务又获得了全部的系统资源。最终的效果就是 Fair调度器即得到了高的资源利用率又能保证小任务及时完成。
