1、MapReduced的工作流程
输入分片（inputsplit）：在进行map计算之前，mapreduce会根据输入文件计算输入分片（input split），每个输入分片（input split）针对一个map任务；存储的并非数据本身，而是一个分片长度和一个记录数据的位置的数组，输入分片（input split）往往和hdfs的block（块）关系很密切
map阶段：程序员编写好的map函数了，因此map函数效率相对好控制，而且一般map操作都是本地化操作也就是在数据存储节点上进行；
combiner阶段：combiner阶段是程序员可以选择的，combiner其实也是一种reduce操作，因此我们看见WordCount类里是用reduce进行加载的
shuffle阶段：将map的输出作为reduce的输入的过程就是shuffle了
reduce阶段：和map函数一样也是程序员编写的，最终结果是存储在hdfs上的。
2、MR的架构
1、简介：
MapReduce是一个软件框架，基于该框架能够容易地编写应用程序，这些应用程序能够运行在由上千个商用机器组成的大集群上，并以一种可靠的，具有容错能力的方式并行地处理上TB级别的海量数据集
2、4个对象：
客户端：编写mapreduce程序，配置作业，提交作业，这就是程序员完成的工作；
JobTracker：初始化作业，分配作业，与TaskTracker通信，协调整个作业的执行；
TaskTracker：保持与JobTracker的通信，在分配的数据片段上执行Map或Reduce任务，TaskTracker和JobTracker的不同有个 很重要的方面，就是在执行任务时候TaskTracker可以有n多个，JobTracker则只会有一个
Hdfs：保存作业的数据、配置信息等等，最后的结果也是保存在hdfs上面
3、mysql和mongodb的区别
mongodb与mysql命令对比 传统的关系数据库一般由数据库（database）、表（table）、记录（record）三个层次概念组成，MongoDB是由数据库（database）、集合（collection）、文档对象（document）三个层次组成。MongoDB对于关系型数据库里的表，但是集合中没有列、行和关系概念，这体现了模式自由的特点。
二者最大的区别就是MongoDB是非关系型数据库，mySQL是关系型数据库，那么在选型的时候，很大程度上就需要由业务来决定倾向性。MongoDB没有表、行、列等等的概念，相对更灵活，限制更少一些。
MongoDB可以更方便的处理流式数据。
MongoDB的索引放在内存中，能够提升随机读写的性能。
MongoDB对数据间的事务关系支持比较弱。
MongoDB自带一个分布式文件系统，可以很方便地部署到服务器机群上。
MongoDB支持单集合分片，可以很好的解决单表过大的问题。
4、Secondary NameNode:它究竟有什么作用？
参考文章：https://blog.csdn.net/xh16319/article/details/31375197
5、什么是负载均衡
负载均衡 建立在现有网络结构之上，它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。
负载均衡，英文名称为Load Balance，其意思就是分摊到多个操作单元上进行执行，例如Web服务器、FTP服务器、企业关键应用服务器和其它关键任务服务器等，从而共同完成工作任务。
6、Kafka 使用 Zookeeper 做什么？
kafka使用ZooKeeper用于管理、协调代理。每个Kafka代理通过Zookeeper协调其他Kafka代理。当Kafka系统中新增了代理或某个代理失效时，Zookeeper服务将通知生产者和消费者。生产者与消费者据此开始与其他代理协调工作。Zookeeper在Kakfa中扮演的角色：Kafka将元数据信息保存在Zookeeper中，但是发送给Topic本身的数据是不会发到Zk上的
kafka使用zookeeper来实现动态的集群扩展，不需要更改客户端（producer和consumer）的配置。broker会在zookeeper注册并保持相关的元数据（topic，partition信息等）更新。
而客户端会在zookeeper上注册相关的watcher。一旦zookeeper发生变化，客户端能及时感知并作出相应调整。这样就保证了添加或去除broker时，各broker间仍能自动实现负载均衡。这里的客户端指的是Kafka的消息生产端(Producer)和消息消费端(Consumer)
Broker端使用zookeeper来注册broker信息,以及监测partitionleader存活性.
Consumer端使用zookeeper用来注册consumer信息,其中包括consumer消费的partition列表等,同时也用来发现broker列表,并和partitionleader建立socket连接,并获取消息.
Zookeer和Producer没有建立关系，只和Brokers、Consumers建立关系以实现负载均衡，即同一个ConsumerGroup中的Consumers可以实现负载均衡（因为Producer是瞬态的，可以发送后关闭，无需直接等待）
7、Zookeeper可以干什么
Zookeeper是一个分布式协调服务。这样我们就可以利用Zookeeper来协调多个分布式进程之间的活动。比如在一个分布式环境中，为了提高可靠性，我们的集群的每台服务器上都部署着同样的服务。但是，一件事情如果集群中的每个服务器都进行的话，那相互之间就要协调，编程起来将非常复杂。而如果我们只让一个服务进行操作，那又存在单点。通常还有一种做法就是使用分布式锁，在某个时刻只让一个服务去干活，当这台服务出问题的时候锁释放，立即fail over到另外的服务。这在很多分布式系统中都是这么做，这种设计有一个更好听的名字叫Leader Election(leader选举)。比如HBase的Master就是采用这种机制。但要注意的是分布式锁跟同一个进程的锁还是有区别的，所以使用的时候要比同一个进程里的锁更谨慎的使用。
https://blog.csdn.net/weixin_35353187/article/details/82351970
8、SQL事物
8.1、事务概念
事务是一种机制、是一种操作序列，它包含了一组数据库操作命令，这组命令要么全部执行，要么全部不执行。因此事务是一个不可分割的工作逻辑单元。在数据库系统上执行并发操作时事务是作为最小的控制单元来使用的。这特别适用于多用户同时操作的数据通信系统。例如：订票、银行、保险公司以及证券交易系统等。
8.2、事务属性
事务4大属性：
1 原子性(Atomicity):事务是一个完整的操作。
2 一致性（Consistency）：当事务完成时，数据必须处于一致状态。
3 隔离性(Isolation):对数据进行修改的所有并发事务是彼此隔离的。
4 持久性(Durability):事务完成后，它对于系统的影响是永久性的。xin_35353187/article/details/82351970
9、Hbase 读写流程？
9.1、读数据流程：
1、客户端首先会根据配置文件中zookeeper地址连接zookeeper，并读取/<hbase-rootdir>/meta-region-server节点信息，该节点信息存储HBase元数据（hbase:meta）表所在的RegionServer地址以及访问端口等信息。用户可以通过zookeeper命令(get /<hbase-rootdir>/meta-region-server)查看该节点信息。
2、根据hbase:meta所在RegionServer的访问信息，客户端会将该元数据表加载到本地并进行缓存。然后在表中确定待检索rowkey所在的RegionServer信息。
3、根据数据所在RegionServer的访问信息，客户端会向该RegionServer发送真正的数据读取请求。
9.2、写入数据流程较复杂，参考链接：
http://bbs.edu360.cn/thread-5530-1-1.html
10、Hive 数据倾斜问题？
数据倾斜 解决原则就是将数据量大key打散，分到不同的分区再重新 处理一遍
Hive group的时候 指定组合 key，
11、Spark运行的四种模式是什么？ 都有什么特点，你们用哪一种？？
本地单机模式: 本地单机模式下，所有的Spark进程均运行于同一个JVM中，并行处理则通过多线程来实现。在默认情况下，单机模式启动与本地系统的CPU核心数目相同的线程。如果要设置并行的级别，则以local[N]的格式来指定一个master变量，N表示要使用的线程数目。
集群单机模式(Standalone): Spark集群由两类程序构成：一个驱动程序(Driver)和多个执行程序(Excutor)。本地模式时所有的处理都运行在同一个JVM内，在集群模式时通常运行在多个不同的节点上。
基于YARN：Hadoop关联形成集群计算和资源调度框架。(使用较多)
我们使用的是Spark On Yarn。
12、Hive、Hbase、mysql区别
参考：https://blog.csdn.net/vipyeshuai/article/details/50847281
13、java设计模式
参考：https://www.cnblogs.com/bingo1717/p/7745556.html
14、什么是死锁和如何解决死锁
参考：9https://blog.csdn.net/dt_zhangshuo/article/details/53334030