第六题：大数据面试题-分布式相关（阿里）
问：说说三种分布式锁？
答：
- 基于数据库实现分布式锁：（性能较差，锁表的风险，非阻塞，失败需要轮询耗CPU）
- 悲观锁
利用select … where … for update 排他锁
注意: 其他附加功能与实现基本一致，这里需要注意的是“where name=lock ”，name字段必须要走索引，否则会锁表。有些情况下，比如表不大，mysql优化器会不走这个索引，导致锁表问题。
- 乐观锁
所谓乐观锁与悲观锁最大区别在于基于CAS思想，是不具有互斥性，不会产生锁等待而消耗资源，操作过程中认为不存在并发冲突，只有update version失败后才能觉察到。我们的抢购、秒杀就是用了这种实现以防止超卖。
乐观锁是通过增加递增的版本号字段实现的。
- 基于缓存（Redis等）实现分布式锁：（过期时间不好控制，非阻塞，失败需要轮询耗CPU）
- 获取锁的时候，使用setnx加锁，并使用expire命令为锁添加一个超时时间，超过该时间则自动释放锁，锁的value值为一个随机生成的UUID，通过此在释放锁的时候进行判断。
- 获取锁的时候还设置一个获取的超时时间，若超过这个时间则放弃获取锁。
- 释放锁的时候，通过UUID判断是不是该锁，若是该锁，则执行delete进行锁释放。
- 基于Zookeeper实现分布式锁：（高可用、可重入、阻塞锁）
大致思想：每个客户端对某个功能加锁时，在zookeeper上的与该功能对应的指定节点的目录下，⽣生成⼀个唯一的瞬时有序节点。判断是否获取锁的方式很简单，只需要判断有序节点中序号最小的一个。当释放锁的时候，只需将这个瞬时节点删除即可。同时，其可以避免服务宕机导致的锁无法释放，⽽而产生的死锁问题。
- 优点：锁安全性高，zk可持久化，且能实时监听获取锁的客户端状态。一旦客户端宕机，则瞬时节点随之消失，zk因⽽而能第一时间释放锁。这也省去了用分布式缓存实现锁的过程中需要加入超时时间判断的这一逻辑。
- 缺点：性能开销⽐比较高。因为其需要动态产生、销毁瞬时节点来实现锁功能。所以不太适合直接提供给高并发的场景使用。
- 实现：可以直接采用zookeeper第三方库curator即可方便地实现分布式锁。
- 适用场景：对可靠性要求非常高，且并发程度不高的场景下使用。如核心数据的定时全量/增量同步等。
第七题：大数据面试题-Hadoop、Spark相关（京东金融）
问：Hadoop 和 Spark 的相同点和不同点？
答：
Hadoop底层使用MapReduce计算架构，只有map和reduce两种操作，表达能力比较欠缺，而且在MR过程中会重复的读写hdfs，造成大量的磁盘io读写操作，所以适合高时延环境下批处理计算的应用；
Spark是基于内存的分布式计算架构，提供更加丰富的数据集操作类型，主要分成转化操作和行动操作，包括map、reduce、filter、flatmap、groupbykey、reducebykey、union和join等，数据分析更加快速，所以适合低时延环境下计算的应用；
spark与hadoop最大的区别在于迭代式计算模型。基于mapreduce框架的Hadoop主要分为map和reduce两个阶段，两个阶段完了就结束了，所以在一个job里面能做的处理很有限；spark计算模型是基于内存的迭代式计算模型，可以分为n个阶段，根据用户编写的RDD算子和程序，在处理完一个阶段后可以继续往下处理很多个阶段，而不只是两个阶段。所以spark相较于mapreduce，计算模型更加灵活，可以提供更强大的功能。
但是spark也有劣势，由于spark基于内存进行计算，虽然开发容易，但是真正面对大数据的时候，在没有进行调优的情况下，可能会出现各种各样的问题，比如OOM内存溢出等情况，导致spark程序可能无法运行起来，而mapreduce虽然运行缓慢，但是至少可以慢慢运行完。
第八题：大数据面试题-Yarn相关（特斯拉）
问：一个应用程序是如何在 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注销并关闭自己。
第九题：大数据面试题-数据质量相关（蚂蚁金服）
问：数据质量怎么监控？
答：
如一张表的记录数在一个已知的范围内，或者上下浮动不会超过某个阈值：
- SQL结果：var 数据量 = select count（*）from 表 where 时间等过滤条件
- 报警触发条件设置：如果数据量不在[数值下限, 数值上限]， 则触发报警
- 同比增加：如果((本周的数据量 -上周的数据量)/上周的数据量*100)不在 [比例下线，比例上限]，则触发报警
- 环比增加：如果((今天的数据量 - 昨天的数据量)/昨天的数据量*100)不在 [比例下线，比例上限]，则触发报警
- 报警触发条件设置一定要有。如果没有配置的阈值，不能做监控
日活、周活、月活、留存（日周月）、转化率（日、周、月）GMV（日、周、月）
复购率（日周月）
单表空值检测
某个字段为空的记录数在一个范围内，或者占总量的百分比在某个阈值范围内
- 目标字段：选择要监控的字段，不能选“无”
- SQL结果：var 异常数据量 = select count(*) from 表 where 目标字段 is null
- 单次检测：如果(异常数据量)不在[数值下限, 数值上限]，则触发报警
单表重复值检测
一个或多个字段是否满足某些规则
- 目标字段：第一步先正常统计条数；select count(*) form 表；
- 第二步，去重统计；select count(*) from 表 group by 某个字段
- 第一步的值和第二步的值做减法，看是否在上下线阀值之内
- 单次检测：如果(异常数据量)不在[数值下限, 数值上限]， 则触发报警
跨表数据量对比
主要针对同步流程，监控两张表的数据量是否一致
- SQL结果：count(本表) - count(关联表)
- 阈值配置与“空值检测”相同
第十题：大数据面试题-海量数据相关（百度）
问：在海量日志数据中，提取出某日访问百度次数最多的那个IP
答：这类问题都归为求Top K的问题，解决方法都差不多。
将这一天访问百度的日志的IP取出来，逐个写入到一个大文件中。注意到IP是32位的，最多有个2^32个IP。同样可以采用映射的方法，比如模1000，把整个大文件映射为1000个小文件，再找出每个小文中出现频率最大的IP（可以采用 HashMap 进行频率统计，然后再找出频率最大的几个）及相应的频率。然后再在这1000个最大的IP中找出那个频率最大的IP，即为所求。
算法思想：分而治之+Hash
- IP地址最多有2^32=4G种取值情况，所以不能完全加载到内存中处理；
- 可以考虑采用分而治之的思想，按照IP地址的Hash(IP) % 1024值，把海量IP日志分别存储到1024个
小文件中，这样每个小文件最多包含4MB个IP地址； 这里解释一下为什么用Hash(IP) % 1024值，如果不用，而直接分类的话，可能会出现这样一种情况，就是有个IP在每个小文件中都存在，而且这个IP并不一定在那个小文件中是数量最多的，那么最终可能选择的结果会有问题，所以这里用了Hash(IP)%1024值，这样的话，通过计算IP的Hash值，相同IP肯定会放到一个文件中，当然了不同的IP的Hash值也可能相同，就存在一个小文件中。
- 对于每一个小文件，可以构建一个IP为key，出现的次数为value的HashMap，同时记录当前出现次数最多的那个IP地址；
- 可以得到1024个小文件中的出现次数最多的那个IP，再依据常规的排序算法得出总体上出现次数最多的IP。
