大数据面试题

如何实现 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 阶段扫描大表。