面试过程中经常被问道的问题记录

以下是面试过程当中遇到的一些问题，现在发布出来，大家可以作为一个参考，可以试着先做一做，稍后提供答案。
1、如何实现hadoop的安全机制。
2、在使用hadoop或者是spark中遇到过哪些问题，是如何处理解决的。
3、hadoop的调度策略的实现，你们使用的是那种策略，为什么。
4、hadoop和spark使用场景。
5、hdfs和hbase各自使用场景。
6、hbase的rowkey设计，影响hbase的性能有哪些。
7、storm中如何实现统计uv的不重复。
8、redis分布式实现原理。如何实现读写分离，在这个过程当中使用了哪些算法，有什么好处。
9、spark如何保证宕机迅速恢复。
10、hadoop中两个大表实现join的操作，简单描述。

也可以和我交流。

stark_summer · 发表于 2015-1-15 12:58:51

楼主还是给下答案吧大家一起学习下

langke93 · 发表于 2015-1-15 13:54:28

本帖最后由 langke93 于 2015-1-15 14:06 编辑
这里面的每一个题目都可以成文章

对于hadoop安全机制一直是比较弱的，它只能防止好人犯错误，不能防止坏人干坏事。
对于安全机制hadoop也一致在改进，并且12年有专门的团队来做这个事情。
安全机制主要分为两种：
1.认证(authentication)
2.授权(authorization)

这是总体的情况，目前就说说hadoop2.0的。

1. Hadoop 2.0认证机制

在Hadoop中，Client与NameNode和Client与ResourceManager之间初次通信均采用了Kerberos进行身份认证，之后便换用Delegation Token以较小开销，而DataNode与NameNode和NodeManager与ResourceManager之间的认证始终采用Kerberos机制，默认情况下，Kerberos认证机制是关闭的，管理员可通过将参数hadoop.security.authentication设为“kerberos”（默认值为“simple”）启动它。接下来重点分析Hadoop中Token的工作原理以及实现。

Hadoop中Token的定义在org.apache.hadoop.security.token.Token中，每类Token存在一个唯一TokenIdentifier标识，Token主要由下表列出的几个字段组成。

2. Hadoop 2.0授权机制

Hadoop YARN的授权机制是通过访问控制列表（ACL）实现的，按照授权实体，可分为队列访问控制列表、应用程序访问控制列表和服务访问控制列表，下面分别对其进行介绍。

在正式介绍YARN授权机制之前，先要了解HDFS的POSIX风格的文件访问控制机制，这与当前Unix的一致，即将权限授予对象分为用户、同组用户和其他用户，且可单独为每类对象设置一个文件的读、写和可执行权限。此外，用户和用户组的关系是插拔式的，默认情况下共用Unix/Linux下的用户与用户组对应关系，这与YARN是一致的。

详细如下：

1. Hadoop 2.0认证机制

在Hadoop中，Client与NameNode和Client与ResourceManager之间初次通信均采用了Kerberos进行身份认证，之后便换用Delegation Token以较小开销，而DataNode与NameNode和NodeManager与ResourceManager之间的认证始终采用Kerberos机制，默认情况下，Kerberos认证机制是关闭的，管理员可通过将参数hadoop.security.authentication设为“kerberos”（默认值为“simple”）启动它。接下来重点分析Hadoop中Token的工作原理以及实现。

Hadoop中Token的定义在org.apache.hadoop.security.token.Token中，每类Token存在一个唯一TokenIdentifier标识，Token主要由下表列出的几个字段组成。

下面重点介绍YARN中的各类Token及其作用，有兴趣的读者可自行了解HDFS中Token的种类及其作用。

(1) ResourceManager Delegation Token

ResourceManager Delegation Token是ResourceManager授权令牌，持有该令牌的应用程序及其发起的任务可以安全地与ResourceManager交互，比如持有该令牌的MapReduce作业可以在Task中再次向ResourceManager提交一个或者多个作业，进而形成一个MapReduce工作流，Hadoop生态系统中的工作流引擎Oozie正是采用了该策略。该令牌由ResourceManager中的组件RMDelegationTokenSecretManager管理和维护。

(2) YARN Application Token

Application Token用于保证ApplicationMaster与ResourceManager之间的通信安全。该Token的密钥（masterKey）由ResourceManager传递给NodeManager，并保存到ApplicationMaster Container的私有目录下。当NodeManager启动ApplicationMaster时，所有的Token将被加载到ApplicationMaster的UGI中（NodeManager通过环境变量HADOOP_TOKEN_FILE_LOCATION将Token所在目录传递给UGI，这样UGI可以直接从文件中读取Token信息，所有其他Token的传递过程也是一样的），以在与ResourceManager通信时进行安全认证，需要注意的是，该Token的生命周期与ApplicationMaster实例一致。该Token由ResourceManager中的AMRMTokenSecretManager管理和维护。

(3) YARN NodeManager Token

ApplicationMaster与NodeManager通信时，需出示NodeManager Token以表明ApplicationMaster自身的合法性。该Token是由ResourceManager通过RPC函数ApplcationMasterProtocol#allocate的应答中发送给ApplicationMaster的，它的密钥是各个NodeManager向ResourceManager注册（ResourceTracker#registerNodeManager）和发送心跳信息（ResourceTracker#nodeHeartbeat）时领取的。ApplicationMaster通过ContainerManagementProtocol协议与NodeManager通信时，需要出示该Token。该Token由ResourceManager中的NMTokenSecretManagerInRM管理和维护。

(4) YARN Container Token

ApplicationMaster与NodeManager通信启动Container时，需出示Container Token以表明Container的合法性。该Token是由ResourceManager通过RPC函数ApplcationMasterProtocol#allocate的应答存放到Container中发送给ApplicationMaster的，它的密钥是各个NodeManager向ResourceManager注册和发送心跳信息时领取的。ApplicationMaster通过RPC函数ContainerManagementProtocol#startContainer与NodeManager通信启动Container时，需要出示相应的Container Token。该Token由ResourceManager中的RMContainerTokenSecretManager管理和维护。

(5) YARN Localizer Token

Localizer Token用于保证ContainerLocalizer与NodeManager之间的通信安全。ContainerLocalizer负责在任务运行之前从HDFS上下载各类所需的文件资源，以构建一个本地执行环境，在文件下载过程中，ContainerLocalizer通过RPC协议LocalizationProtocol不断向NodeManager汇报状态信息。

(6) MapReduce Client Token

MapReduce Client Token用于保证MapReduce JobClient与MapReduce Application Master之间的通信安全。它由ResourceManager在作业提交时创建，并通过RPC函数ApplicationClientProtocol#getApplicationReport发送给JobClient。该Token由ResourceManager中的ClientToAMTokenSecretManagerInRM管理和维护。

(7) MapReduce Job Token

MapReduce Job Token用于保证MapReduce的各个Task（包括Map Task和Reduce Task）与MapReduce Application Master之间的通信安全。它由ApplicationMaster创建，通过RPC函数ContainerManagementProtocol#startContainer传递给NodeManager，并由NodeManager写入Container的私有目录中，以在任务启动时加载到UGI中，从而使得任务可以安全地通过RPC协议TaskUmbilicalProtocol与ApplicationMaster通信。

(8) MapReduce Shuffle Secret

MapReduce Shuffle Secret用于保证运行在各个NodeManager上的ShuffleHandler（内部封装了一个Netty Server）与Reduce Task之间的通信安全，即只有同一个作业的Reduce Task才允许读取该作业Map Task产生的中间结果，该安全机制是借助Job Token完成的。

2. Hadoop 2.0授权机制

Hadoop YARN的授权机制是通过访问控制列表（ACL）实现的，按照授权实体，可分为队列访问控制列表、应用程序访问控制列表和服务访问控制列表，下面分别对其进行介绍。

在正式介绍YARN授权机制之前，先要了解HDFS的POSIX风格的文件访问控制机制，这与当前Unix的一致，即将权限授予对象分为用户、同组用户和其他用户，且可单独为每类对象设置一个文件的读、写和可执行权限。此外，用户和用户组的关系是插拔式的，默认情况下共用Unix/Linux下的用户与用户组对应关系，这与YARN是一致的。

(1) 队列访问控制列表

为了方便管理集群中的用户，YARN将用户/用户组分成若干队列，并可指定每个用户/用户组所属的队列。通常而言，每个队列包含两种权限：提交应用程序权限和管理应用程序权限（比如杀死任意应用程序），这些是通过配置文件etc/hadoop/mapred-queue-acls.xml设置的。

(2) 应用程序访问控制列表

应用程序访问控制机制的设置方法是在客户端设置为每类ApplicationAccessType（目前只有VIEW_APP和MODIFY_APP两种类型）设置对应的用户列表，这些信息传递到ResourceManager端后，由它维护和使用。通常而言，为了用户使用方便，应用程序可对外提供一些特殊的可直接设置的参数（而不是通过API设置），以MapReduce作业为例，用户可以通过参数mapreduce.job.acl-view-job和mapreduce.job.acl-modify-job为每个作业单独设置查看和修改权限。需要注意的是，默认情况下，作业拥有者和超级用户（可配置）拥有以上两种权限且不可以修改。

(3) 服务访问控制列表

服务访问控制是Hadoop提供的最原始的授权机制，它用于确保只有那些经过授权的客户端才能访问对应的服务。比如可通过为ApplicationClientProtocol协议设置访问控制列表以指定哪些用户可以向集群中提交应用程序。

服务访问控制是通过控制各个服务之间的通信协议实现的，它通常发生在其他访问控制机制之前，比如文件权限检查、队列权限检查等。

更多内容：

Hadoop 2.0中用户安全模仿机制实现原理介绍

Hadoop 2.0 (YARN)中的安全机制介绍

Hadoop安全机制介绍

Hadoop架构：集群的安全性保证

了解Hadoop Kerberos安全机制

hadoop安全性需不断加强

Hadoop架构：集群的安全性保证

Hadoop安全访问控制开源组件:Apache Sentry 1.4版本介绍及下载

langke93 · 发表于 2015-1-15 14:09:15

后面待会再做，希望给楼主交流，咱们都有所提高。

xpy888 · 发表于 2015-1-15 14:29:41

1、如何实现hadoop的安全机制。
1.1 共享hadoop集群:
      a: 管理人员把开发人员分成了若干个队列，每个队列有一定的资源，每个用户及用户组只能使用某个队列中指定资源。
      b: HDFS上有各种数据，公用的，私有的，加密的。不用的用户可以访问不同的数据。
1.2 HDFS安全机制
      client获取namenode的初始访问认证( 使用kerberos )后，会获取一个delegation token，这个token可以作为接下来访问HDFS或提交作业的认证。同样，读取block也是一样的。
1.3 mapreduce安全机制
      所有关于作业的提交或者作业运行状态的追踪均是采用带有Kerberos认证的RPC实现的。授权用户提交作业时，JobTracker会为之生成一个delegation token，该token将被作为job的一部分存储到HDFS上并通过RPC分发给各个TaskTracker，一旦job运行结束，该token失效。
1.4 DistributedCache是安全的。
      DistribuedCache分别两种，一种是shared，可以被所有作业共享，而private的只能被该用户的作业共享。
1.5 RPC安全机制
      在Hadoop RP中添加了权限认证授权机制。当用户调用RPC时，用户的login name会通过RPC头部传递给RPC，之后RPC使用Simple Authentication and Security Layer（SASL）确定一个权限协议（支持Kerberos和DIGEST-MD5两种），完成RPC授权。
2、在使用hadoop或者是spark中遇到过哪些问题，是如何处理解决的。
2.1 数据倾斜。
      出现这种情况：多数是由于代码的质量写的不够健壮。查看日志：发现问题。
2.2 spark-出现OOM
      小数据量的情况可以cache，数据量大的情况必须考虑内存使用。
3、hadoop的调度策略的实现，你们使用的是那种策略，为什么。
   3.1 默认情况下hadoop使用的FIFO, 先进先出的调度策略。按照作业的优先级来处理。
   3.2 计算能力调度器( Capacity Scheduler ) 支持多个队列，每个队列可配置一定的资源量，每个队列采用FIFO, 为了防止同一个用户的作业独占资源，那么调度器会对同一个用户提交的作业所占资源进行限定，首先按以下策略选择一个合适队列：计算每个队列中正在运行的任务数与其应该分得的计算资源之间的比值，选择一个该比值最小的队列；然后按以下策略选择该队列中一个作业：按照作业优先级和提交时间顺序选择，同时考虑用户资源量限制和内存限制。
   3.3 公平调度器( Fair Scheduler )  支持多队列多用户，每个队列中的资源量可以配置，同一队列中的作业公平共享队列中所有资源。
   3.4 异构集群的调度器LATE
   3.5 实时作业的调度器Deadline Scheduler和Constraint-based Scheduler
4、hadoop和spark使用场景。
Hadoop/MapReduce和Spark最适合的都是做离线型的数据分析，但Hadoop特别适合是单次分析的数据量“很大”的情景，而Spark则适用于数据量不是很大的情景。
4.1 一般情况下，对于中小互联网和企业级的大数据应用而言，单次分析的数量都不会“很大”，因此可以优先考虑使用Spark。
4.2  业务通常认为Spark更适用于机器学习之类的“迭代式”应用,80GB的压缩数据（解压后超过200GB），10个节点的集群规模，跑类似“sum+group-by”的应用，MapReduce花了5分钟，而spark只需要2分钟。
5、hdfs和hbase各自使用场景。

整理总结：
首先一点需要明白：Hbase是基于HDFS来存储的。
HDFS：
  1、一次性写入，多次读取。
  2、保证数据的一致性。
  3、主要是可以部署在许多廉价机器中，通过多副本提高可靠性，提供了容错和恢复机制。
Hbase：
  1、瞬间写入量很大，数据库不好支撑或需要很高成本支撑的场景。
  2、数据需要长久保存，且量会持久增长到比较大的场景
  3、hbase不适用与有join，多级索引，表关系复杂的数据模型
  4、大数据量（100s TB级数据）且有快速随机访问的需求。
   如：淘宝的交易历史记录。数据量巨大无容置疑，面向普通用户的请求必然要即时响应。
  5、容量的优雅扩展
大数据的驱使，动态扩展系统容量的必须的。例如：webPage DB。
  6、业务场景简单，不需要关系数据库中很多特性（例如交叉列、交叉表，事务，连接等等）
  7、优化方面：合理设计rowkey。因为hbase的查
6、hbase的rowkey设计，影响hbase的性能有哪些。
由于使用hbase不多，hbase的rowkey的设计就不多说了，哪位大神使用过，做一下补充。

1 hbase.hregion.max.filesize应该设置多少合适。
  默认是256，HStoreFile的最大值。如果任何一个Column Family（或者说HStore）的HStoreFiles的大小超过这个值，那么，其所属的HRegion就会Split成两个。
  众所周知hbase中数据一开始会写入memstore，当memstore满64MB以后，会flush到disk上而成为storefile。当storefile数量超过3时，会启动compaction过程将它们合并为一个storefile。这个过程中会删除一些timestamp过期的数据，比如update的数据。而当合并后的storefile大小大于hfile默认最大值时，会触发split动作，将它切分成两个region。
2、autoflush=false的影响
　　无论是官方还是很多blog都提倡为了提高hbase的写入速度而在应用代码中设置autoflush=false，然后lz认为在在线应用中应该谨慎进行该设置原因如下：

　　2.1、autoflush=false的原理是当客户端提交delete或put请求时，将该请求在客户端缓存，直到数据超过2M(hbase.client.write.buffer决定)或用户执行了hbase.flushcommits()时才向regionserver提交请求。因此即使htable.put()执行返回成功，也并非说明请求真的成功了。假如还没有达到该缓存而client崩溃，该部分数据将由于未发送到regionserver而丢失。这对于零容忍的在线服务是不可接受的。

　　2.2、autoflush=true虽然会让写入速度下降2-3倍，但是对于很多在线应用来说这都是必须打开的，也正是hbase为什么让它默认值为true的原因。当该值为true时，每次请求都会发往regionserver,而regionserver接收到请求后第一件事就是写hlog，因此对io的要求是非常高的，为了提高hbase的写入速度，应该尽可能高地提高io吞吐量，比如增加磁盘、使用raid卡、减少replication因子数等。
从性能的角度谈table中family和qualifier的设置
3、对于传统关系型数据库中的一张table，在业务转换到hbase上建模时，从性能的角度应该如何设置family和qualifier呢？
　　最极端的，①每一列都设置成一个family，②一个表仅有一个family，所有列都是其中的一个qualifier，那么有什么区别呢？
　　从读的方面考虑：
　　family越多，那么获取每一个cell数据的优势越明显，因为io和网络都减少了。
　　如果只有一个family，那么每一次读都会读取当前rowkey的所有数据，网络和io上会有一些损失。
　　当然如果要获取的是固定的几列数据，那么把这几列写到一个family中比分别设置family要更好，因为只需一次请求就能拿回所有数据。
　　从写的角度考虑：

　　首先，内存方面来说，对于一个Region，会为每一个表的每一个Family分配一个Store，而每一个Store，都会分配一个MemStore，所以更多的family会消耗更多的内存。
　　其次，从flush和compaction方面说，目前版本的hbase，在flush和compaction都是以region为单位的，也就是说当一个family达到flush条件时，该region的所有family所属的memstore都会flush一次，即使memstore中只有很少的数据也会触发flush而生成小文件。这样就增加了compaction发生的机率，而compaction也是以region为单位的，这样就很容易发生compaction风暴从而降低系统的整体吞吐量。
　　第三，从split方面考虑，由于hfile是以family为单位的，因此对于多个family来说，数据被分散到了更多的hfile中，减小了split发生的机率。这是把双刃剑。更少的split会导致该region的体积比较大，由于balance是以region的数目而不是大小为单位来进行的，因此可能会导致balance失效。而从好的方面来说，更少的split会让系统提供更加稳定的在线服务。而坏处我们可以通过在请求的低谷时间进行人工的split和balance来避免掉。
因此对于写比较多的系统，如果是离线应该，我们尽量只用一个family好了，但如果是在线应用，那还是应该根据应用的情况合理地分配family
7、storm中如何实现统计uv的不重复。

storm主要是通过Transactional topology，确保每次tuple只被处理一次。给每个tuple按顺序加一个id，在处理过程中，将成功处理的tuple id和计算保存在数据库当中，但是这种机制使得系统一次只能处理一个tuple，无法实现分布式计算。
我们要保证一个batch只被处理一次，机制和上一节类似。只不过数据库中存储的是batch id。batch的中间计算结果先存在局部变量中，当一个batch中的所有tuple都被处理完之后，判断batch id，如果跟数据库中的id不同，则将中间计算结果更新到数据库中。
Storm提供的Transactional Topology将batch计算分为process和commit两个阶段。Process阶段可以同时处理多个batch，不用保证顺序性；commit阶段保证batch的强顺序性，并且一次只能处理一个batch，第1个batch成功提交之前，第2个batch不能被提交。这样就保证多线程情况下值能处理一个batch。
8、redis分布式实现原理。如何实现读写分离，在这个过程当中使用了哪些算法，有什么好处。

memcache只能说是简单的kv内存数据结构,而redis支持的数据类型比较丰富。Redis在3.0以后实现集群机制。目前Redis实现集群的方法主要是采用一致性哈稀分片（Shard），将不同的key分配到不同的redis server上，达到横向扩展的目的。
使用了一致性哈稀进行分片，那么不同的key分布到不同的Redis-Server上，当我们需要扩容时，需要增加机器到分片列表中，这时候会使得同样的key算出来落到跟原来不同的机器上，这样如果要取某一个值，会出现取不到的情况，对于这种情况，Redis的提出了一种名为Pre-Sharding的方式：
使用了redis的集群模式：存在以下几个问题
A：扩容问题：
Pre-Sharding方法是将每一个台物理机上，运行多个不同断口的Redis实例，假如有三个物理机，每个物理机运行三个Redis实际，那么我们的分片列表中实际有9个Redis实例，当我们需要扩容时，增加一台物理机，步骤如下：
1、在新的物理机上运行Redis-Server；
2、该Redis-Server从属于(slaveof)分片列表中的某一Redis-Server（假设叫RedisA）；
3、等主从复制(Replication)完成后，将客户端分片列表中RedisA的IP和端口改为新物理机上Redis-Server的IP和端口；
4、停止RedisA.
B: 单点故障问题
  将一个Redis-Server转移到了另外一台上。Prd-Sharding实际上是一种在线扩容的办法，但还是很依赖Redis本身的复制功能的，如果主库快照数据文件过大，这个复制的过程也会很久，同时会给主库带来压力。

9、spark如何保证宕机迅速恢复。

了解了RDD，那么这个问题就迎刃而解了
RDD的好处
RDD只能从持久存储或通过Transformations操作产生，相比于分布式共享内存（DSM）可以更高效实现容错，对于丢失部分数据分区只需根据它的lineage就可重新计算出来，而不需要做特定的Checkpoint。
RDD的不变性，可以实现类Hadoop MapReduce的推测式执行。
RDD的数据分区特性，可以通过数据的本地性来提高性能，这与Hadoop MapReduce是一样的。
RDD都是可序列化的，在内存不足时可自动降级为磁盘存储，把RDD存储于磁盘上，这时性能会有大的下降但不会差于现在的MapReduce。
RDD的存储与分区
用户可以选择不同的存储级别存储RDD以便重用。
当前RDD默认是存储于内存，但当内存不足时，RDD会spill到disk。
RDD在需要进行分区把数据分布于集群中时会根据每条记录Key进行分区（如Hash 分区），以此保证两个数据集在Join时能高效。
RDD的内部表示
在RDD的内部实现中每个RDD都可以使用5个方面的特性来表示：
分区列表（数据块列表）
计算每个分片的函数（根据父RDD计算出此RDD）
对父RDD的依赖列表
对key-value RDD的Partitioner【可选】
每个数据分片的预定义地址列表(如HDFS上的数据块的地址)【可选】
10、hadoop中两个大表实现join的操作，简单描述。
这个简单了。
10.1 map读取两个表，分别标示一下，然后context输出。reduce做笛卡尔积。
10.2 map之前setup时先DistributeCache，然后map阶段扫描大表。