1.MapReduce解决缺值问题？
一张非常宽，且数据量大的表，被分割成若干个hdfs上的小文件，其中有一个字段，是自增的（但分布的文件中的这个字段值是乱序的），举个栗子，比如:1,2,3。现在并不知道究竟是哪几个值缺失，请你用MapReduce的方式将那些缺失的值找到？
其实这是MapReduce的典型应用场景之一——缺值查找。整体的一个思路是，先将这些乱序的值排好序，然后又因为表非常宽，可以单独建立与这张宽表一一对应的那个字段的列，然后再用MapReduce处理那个列就OK了。
2.集群规模有限，但之前的那个文件足够大，如何解决？（不能调整集群的规模）
从集群角度出发，通过如下的机器配置与Map/Reduce的slots转换：
估量出该有限规模集群一次最合理的发起Map/Reduce数，再估量出这种量数的Map/Reduce大致对应多少批量的文件，以这个批量为单元，将该文件进行split。
3.Spark的三种部署方式？
4.如果Spark用的和Mapreduce的计算资源同是yarn，发现资源不够用了话，在Spark
中的哪里进行配置，使之资源分配合理？
5.LVS的配置相关命令？
6.Hadoop的各角色的职能？
7.Hadoop的checkpoint的作用？
8.HBase的双主如何配置？
最近LVS看多了，我傻不拉几的答了个LVS。其实目前的HBase双主是依靠于Hadoop的HA的，你可以通过./hbase-daemon.sh start master命令在RegionServer上启动一个master。。。
HBase HA高可用集群搭建及HBase Shell简单使用
9.HBase即便拥有双主的高可靠配置，存在hdfs上的数据丢失怎么办？
经过查找资料发现，对于那些意外丢失的数据，业内确实有一种系统的方案：
10.HBase模糊查询，是什么？如何做到？
11.Hadoop的 高可靠性，如何保证？
首先，当然是要搭建好一个基本的HA，Hadoop1存在namenode单点故障，Hadoop2中通过journalnode以及DFSfailovercontroller、NFS等一系列机制保证了集群的HA
其次，肯定要对集群的一个瓶颈甚至预警信号实现一个预判，这样才能防患于未然：
最后，当悲惨的事实出现在了我们眼前，与其抱怨不如做一些实质性的补救措施：
当然，功能上得到了技术的保障后，在性能上，我们是不是可以进一步的优化以服务于生产呢？
12.如何保证HBase的稳定性以及高可靠性？从部署、容灾、以及网络方面说说你的看法？
部署方面，肯定是HA部署无疑，容灾的话肯定要对数据意外丢失的情况建立一整套的快速且行之有效的方案，比如先fixhdfs，再fixtable，最后fixmetadata，实在不行，再执行repair，在已有可能性上做到最大的抢救，对于单个集群规模过大的情况，尝试分多个集群。网络方面：定期巡检，关键性指标实时监控。