大数据面试题2 ---一般有用

面试题总结:

    1. 分布式文件系统(Distributed File System)是指文件系统管理的物理存储资源不一定直接连接在本地节点上,而是通过计算机网络与节点相连。分布式文件系统的设计基于客户机/服务器模式。

      [优点]

      支持超大文件 超大文件在这里指的是几百M,几百GB,甚至几TB大小的文件。

      检测和快速应对硬件故障在集群的环境中,硬件故障是常见的问题。因为有上千台服务器连接在一起,这样会导致高故障率。因此故障检测和自动恢复是hdfs文件系统的一个设计目标

      流式数据访问应用程序能以流的形式访问数据集。主要的是数据的吞吐量,而不是访问速度

      简化的一致性模型 大部分hdfs操作文件时,需要一次写入,多次读取。在hdfs中,一个文件一旦经过创建、写入、关闭后,一般就不需要修改了。这样简单的一致性模型,有利于提高吞吐量。

      [缺点]

      低延迟数据访问如和用户进行交互的应用,需要数据在毫秒或秒的范围内得到响应。由于hadoop针对高数据吞吐量做了优化,牺牲了获取数据的延迟,所以对于低延迟来说,不适合用hadoop来做。

      大量的小文件Hdfs支持超大的文件,是通过数据分布在数据节点,数据的元数据保存在名字节点上。名字节点的内存大小,决定了hdfs文件系统可保存的文件数量。虽然现在的系统内存都比较大,但大量的小文件还是会影响名字节点的性能。

      多用户写入文件、修改文件Hdfs的文件只能有一次写入,不支持写入,也不支持修改。只有这样数据的吞吐量才能大。

      不支持超强的事务没有像关系型数据库那样,对事务有强有力的支持。
      详情查看:https://www.cnblogs.com/sxt-zkys/archive/2017/07/24/7229857.html

    2. Gangila不仅可以进行监控,也可以进行告警。(正确)
        Ganglia是UC Berkeley发起的一个开源集群监视项目,设计用于测量数以千计的节点Ganglia的核心包含gmond、gmetad以及一个Web前端。主要是用来监控系统性能,如:cpu 、mem、硬盘利用率, I/O负载、网络流量情况等,通过曲线很容易见到每个节点的工作状态,对合理调整、分配系统资源,提高系统整体性能起到重要作用。ganglia 作为一款最常用的 Linux 环境中的监控软件,它擅长的的是从节点中按照用户的需求以较低的代价采集数据但是 ganglia 在预警以及发生事件后通知用户上并不擅长。最新的 ganglia 已经有了部分这方面的功能。
        Nagios是一款开源的免费网络监视工具能有效监控Windows、Linux和Unix的主机状态,交换机路由器等网络设备,打印机等。在系统或服务状态异常时发出邮件或短信报警第一时间通知网站运维人员,在状态恢复后发出正常的邮件或短信通知。
        通过将 Ganglia 和 Nagios 组合起来,把 Ganglia 采集的数据作为 Nagios 的数据源,然后利用 Nagios 来发送预警通知,可以 完美的实现一整套监控管理的系统。 具体可以查看 完美集群监控组合 ganglia 和 nagios。
      ps.云计算管理三大利器:Nagios、Ganglia和Splunk


    3. Block Size是不可以修改的。(错误)-----它是可以被修改的
      Hadoop的基础配置问件事hadoop-default.xml,默认建立一个job的时候会建立job的configuration,首先读入的是hadoop-default.xml的配置,然后再读hadoop-site.xml的配置(这个文件初始的时候配置为空),hadoop-site.xml中主要配置需要覆盖的hadoop-default.xml的系统级配置。具体配置可以参考下
      <property>
      <name>dfs.block.size</name>//block的大小,单位字节,后面会提到用处,必须是512的倍数,因为采用crc做文件完整性校验,默认配置512是checksum的最小单元
      <value>5120000</value>
      </property>

       ps.循环冗余校验(Cyclic Redundancy Check, CRC)是一种根据网络数据包或电脑文件等数据产生简短固定位数校验码的一种散列函数,主要用来检测或校验数据传输或者保存后可能出现的错误。它是利用除法及余数的原理来作错误侦测的

    4. Nagios(监视的系统)不可以监控hadoop集群,因为它不提供hadoop支持。(错误)
      nagios是集群监控工具,而且是云计算三大利器之一

    5. 如果namenode意外终止,secondarynamenode会接替他是集群继续工作。(错误) 
      secondarynamenode是帮助恢复,而不是替代,如何恢复,可以查看hadoop根据secondarynamenode恢复namenode。在高可用集群中,一个namenode(active)死亡后,
    6. ZKFC(zookeeper控制器)仲裁将另一个standby-namenode启动,转换成active状态,集群继续正常工作。


    7.  
    8. Hadoop支持数据的随机读写。(错误)
      lucene是支持随机读写的,而hdfs只支持随机读。但是Hbase可以来补救。Hbase提供随机读写来解决Hadoop不能处理的问题。HBase 自底层设计开始即聚焦于各种可伸缩性问题:表可以很―高‖,有数十亿个数据行;也可以很―宽‖,有数百万个列;水平分区并在上千个普通商用机节 点上自动复制。表的模式是物理存储的直接反映,使系统有可能提高高效的数据结构的序列化、存储和检索。
      ps.Lucene是一套用于全文检索和搜寻的开源程式库,由Apache软件基金会支持和提供。Lucene提供了一个简单却强大的应用程式接口,能够做全文索引和搜寻。在Java开发环境里Lucene是一个成熟的免费开源工具。就其本身而言,Lucene是当前以及最近几年最受欢迎的免费Java信息检索程序库。人们经常提到信息检索程序库,虽然与搜索引擎有关,但不应该将信息检索程序库与搜索引擎相混淆。

    9. namenode负责管理metadata,client端每次读写请求,都会从磁盘中读取或则会写入 metadata 信息并反馈client 端。(错误)
      NameNode 不需要从磁盘读取 metadata,所有数据都在内存中,硬盘上的只是序列化的结果,只有每次namenode 启动的时候才会读取。

      1)文件写入Client 向 NameNode 发起文件写入的请求。NameNode 根据文件大小和文件块配置情况,返回给 Client 它所管理部分 DataNode 的信息。Client 将文件划分为多个 Block,根据 DataNode 的地址信息,按顺序写入到每一个 DataNode 块中。

      2)文件读取Client 向 NameNode 发起文件读取的请求。NameNode 返回文件存储的 DataNode 的信息Client 读取文件信息。 
      ps.http://www.makaidong.com/%E5%8D%9A%E5%AE%A2%E5%9B%AD%E6%8E%92%E8%A1%8C/9053.shtml

    10. datanode通过长连接与namenode保持通信。(正确)【答案有分歧,根据自己理解回答即可】  

      长连接:Client 方与Server 方先建立通讯连接,连接建立后不断开,然后再进行报文发送和接收。这种方式下由于通讯连接一直存在,此种方式常用于点对点通讯。

      短连接:Client 方与Server 每进行一次报文收发交易时才进行通讯连接,交易完毕后立即断开连接。此种方式常用于一点对多点通讯,比如多个Client 连接一个Server。

    11.  


    12. hadoop dfsadmin -report可以用来查询集群的状况,可以快速定位出各个节点,HDFS的容量和使用量,以及每个节点的硬盘使用情况。当然这个也可以通过50070端口进行查看,但是这个命令更有利于我们利用脚本来监控dfs的使用状况

    13. Hadoop默认调度器策略为FIFO。(正确)【first input first output】
      FIFO是先入先出队列,是一种传统的按序执行的方法。

       

    14.  Hadoop集群三种作业调度算法介绍
      Hadoop集群中有三种作业调度算法,分别为FIFO,公平调度算法和计算能力调度算法。
      先来先服务算法FIFO:FIFO比较简单,hadoop中只有一个作业队列,被提交的作业按照先后顺序在作业队列中排队,新来的作业插入到队尾。一个作业运行完后,总是从队首取下一个作业运行。这种调度策略的优点是简单、易于实现,同时也减轻了jobtracker的负担。但是它的缺点也是显然的,它对所有的作业都一视同仁,没有考虑到作业的紧迫程度,另外对小作业的运行不利。
      公平调度算法:
      这种策略在系统中配置了任务槽,一个任务槽可以运行一个task任务,这些任务就是一个大的作业被切分后的小作业。当一个用户提交多个作业时,每个作业可以分配到一定的任务槽以执行task任务(这里的任务槽可以理解为可以运行一个map任务或reduce任务)。如果把整个hadoop集群作业调度跟操作系统的作业调度相比,第一种FIFO就相当于操作系统中早期的单道批处理系统,系统中每个时刻只有一道作业在运行,而公平调度相当于多道批处理系统,它实现了同一个时刻多道作业同时运行。由于linux是多用户的,若有多个用户同时提交多个作业会怎样?在这种策略中给每个用户分配一个作业池,然后给每个作业池设置一个最小共享槽个数,什么是最小共享槽个数呢?先要理解一个最小什么意思,最小是指只要这个作业池需要,调度器应该确保能够满足这个作业池的最小任务槽数的需求,但是如何才能确保在它需要的时候就有空的任务槽,一种方法是固定分配一定数量的槽给作业池不动,这个数量至少是最小任务槽值,这样只要在作业池需要的时候就分配给它就行了,但是这样在这个作业池没有用到这么多任务槽的时候会造成浪费,这种策略实际上是这样做的,当作业池的需求没有达到最小任务槽数时,名义上是自己的剩余的任务槽会被分给其他有需要的作业池,当一个作业池需要申请任务槽的时候若系统中没有了,这时候不会去抢占别人的(也不知道抢谁的啊),只要当前一个空的任务槽释放会被立即分配给这个作业池。

      在一个用户的作业池内,多个作业如何分配槽这个可以自行选择了,如FIFO。所以这种调度策略分为两级:

      第一级,在池间分配槽,在多用户的情况下,每个用户分配一个作业池。
      第二级,在作业池内,每个用户可以使用不同的调度策略。

       计算能力调度:计算能力调度和公平调度有点类似,公平调度策略是以作业池为单位分配任务槽,而计算能力调度是以队列为单位分配tasktracker(集群中一个节点),这种调度策略配置了多个队列,每个队列配置了最小额度的tasktracker数量,同公平调度策略类似,当一个队列有空闲的tasktracker时,调度器会将空闲的分配给其他的队列,当有空闲的tasktracker时,由于这时候可能有多个队列没有得到最小额度的tasktracker而又在申请新的,空闲的tasktracker会被优先分配到最饥饿的队列中去,如何衡量饥饿程度呢?可以通过计算队列中正在运行的任务数与其分得的计算资源之间的比值是否最低来判断的,越低说明饥饿程度越高。

      计算能力调度策略是以队列的方式组织作业的,所以一个用户的作业可能在多个队列中,如果不对用户做一定的限制,很可能出现在多个用户之间出现严重不公平的现象。所以在选中新作业运行时候,还需要考虑作业所属的用户是否超过了资源的限制,如果超过,作业不会被选中。

      对于在同一个队列中,这种策略使用的是基于优先级的FIFO策略,但是不会抢占。

    15.  

posted @ 2020-09-16 12:24  十一vs十一  阅读(180)  评论(0编辑  收藏  举报