不同的公司面试内容不同，有的注重基础知识有的注重项目，对实习生，也就是应届生，更多的是基础
因为没有什么工作经验，项目很多也不怎么样，所以也就问的少。下面是我的一点面试经验
我面试次数不多，可能是运气比较好，几家就有了一个很满意的。一共面过两次大数据职位
一次java，一次商务智能，数据分析的。
第一次就是大数据的，数据平台开发，小公司，没有笔试，就是拿着简历上的项目问。因为是自己
做的，不是公司的项目，所以有很多问题，具体问了什么就不详说了，需要注意的是自己项目的一些
架构问题，是否合理，是否自己很清楚，或者说自己能很清楚的描述出来，自己画出架构图。问了一些
知识点的问题，比如sparkRDD，spark和hive的区别，spark的鲁棒性，推荐系统的冷启动问题，这么监控
推荐系统是准确的，怎么实时的监控，就是系统已经发布上线了，怎么知道推荐是有效的。此类问题。
解答：SparkRDD五大特性，
RDD是SparkCore的核心，底层操作的就是RDD
RDD也就是弹性分布式数据集，虽然是数据集但是却不能存储数据，只是存放的一段代码逻辑
五大特性：
1、 RDD是由一系列partition组成
2、 RDD的算子作用在partition上
3、 RDD之间有依赖关系
4、 分区器作用在kv格式的RDD上
5、 partition对外提供最佳的计算位置，利于数据处理的本地化
弹性也就是容错性，RDD有依赖关系，可以根据前面的RDD计算出后面的RDD
RDD中的partition个数可多可少
分布式是RDD中的partition是分布在多个节点上
这大概就是关于RDD的介绍
Spark和hive的区别其实就是Spark和MR的区别，我也简单总结一下，
1、Spark可以基于内存计算，MR基于磁盘迭代处理数据
2、Spark中有DAG有向无环图来切分stage的执行先后顺序
3、MapReduce只有map和reduce。spark中各种算子
4、Spark是粗粒度资源申请，MapReduce是细粒度资源申请
简单的总结了一些
对于Spark的鲁棒性，也可以说就是稳定性，找了很多资料，按照我的理解
和RDD的血统，也就是依赖有关，对于推荐系统的冷启动问题有些博客也详细介绍过
我就简单总结一下简要说明一下
冷启动问题）
冷启动一般分为三种
用户冷启动，就是如何给新用户做个性化推荐
物品冷启动，如何将新的物品推荐给可能会对它感兴趣的用户
系统冷启动，如何在一个新开发的网站上做个性化推荐系统
方案一：提供非个性化的推荐，给新用户推荐热门排行，等用户数据收集到一定程度之后再切换
为个性化推荐系统
方案二：利用用户的注册信息，
获取用户的注册信息，
根据用户的注册信息对用户分类
给用户推荐他所属分类中用户喜欢的物品
方案三：选择合适的物品启动用户的兴趣
就是在用户登录的时候对一些物品做一些兴趣测试和
反馈。根据这些反馈信息得到用户感兴趣的物品
方案四：对于新的物品的个性化推荐
两种协同过滤算法，基于用户的协同过滤，和基于物品的协同过滤
UserCF的核心思想是给用户推荐和他兴趣相似的其他用户喜欢的物品
可以考虑利用物品的内容信息，将新物品先投放给曾经喜欢过和它内容相似的其他物品的用户
ItemCF的核心思想是：给用户推荐和其过去感兴趣的物品相似的物品
基本思路就是将物品转换成关键词向量，通过计算向量之间的相似度（例如计算余弦相似度），得到物品的相关程度。
方案五：对于新的系统，采用专家标注，进行人为的进行物品特征标注，然后计算物品之间的相似度，关联度
至于怎么监控就不知道了。
以上是第一家大数据面试，不过他们公司并没有环境，哈哈
第二家，公司还挺大，环境不错。同样没有笔试。一共面了两轮，一天，本来是还有最后一轮boss的，不过boss没时间
两轮面试的问题我就一起说吧
hashmap原理：这一部分可以自己找找，什么哈希表，哈希冲突，数组，链表，红黑树等等
抽象类和接口的应用场景区别，在设计模式的
kafka怎么保证数据不丢失，重复消费这么解决，为什么会发生，发生在什么地方等等，数据库优化
1.生产者数据的不丢失
kafka的ack机制：在kafka发送数据的时候，每次发送消息都会有一个确认反馈机制，确保消息正常的能够被收到，其中状态有0,1，-1。
- 如果是同步模式：ack机制能够保证数据的不丢失，如果ack设置为0，风险很大，一般不建议设置为0。即使设置为1，也会随着leader宕机丢失数据。
producer.type=sync
request.required.acks=1
- 如果是异步模式：也会考虑ack的状态，除此之外，异步模式下的有个buffer，通过buffer来进行控制数据的发送，有两个值来进行控制，时间阈值与消息的数量阈值，如果buffer满了数据还没有发送出去，有个选项是配置是否立即清空buffer。可以设置为-1，永久阻塞，也就数据不再生产。
- 异步模式下，即使设置为-1。也可能因为程序员的不科学操作，操作数据丢失，比如kill -9，但这是特别的例外情况。
结论：producer有丢数据的可能，但是可以通过配置保证消息的不丢失
2.消费者数据的不丢失
通过offset commit 来保证数据的不丢失，kafka自己记录了每次消费的offset数值，下次继续消费的时候，会接着上次的offset进行消费。
而offset的信息在kafka0.8版本之前保存在zookeeper中，在0.8版本之后保存到topic中，即使消费者在运行过程中挂掉了，再次启动的时候会找到offset的值，找到之前消费消息的位置，接着消费，由于offset的信息写入的时候并不是每条消息消费完成后都写入的，所以这种情况有可能会造成重复消费，但是不会丢失消息。
唯一例外的情况是，我们在程序中给原本做不同功能的两个consumer组设置KafkaSpoutConfig.bulider.setGroupid的时候设置成了一样的groupid，这种情况会导致这两个组共享同一份数据，就会产生组A消费partition1，partition2中的消息，组B消费partition3的消息，这样每个组消费的消息都会丢失，都是不完整的。 为了保证每个组都独享一份消息数据，groupid一定不要重复才行。
2.kafka集群中的broker的数据不丢失
每个broker中的partition我们一般都会设置有replication（副本）的个数，生产者写入的时候首先根据分发策略（有partition按partition，有key按key，都没有轮询）写入到leader中，follower（副本）再跟leader同步数据，这样有了备份，也可以保证消息数据的不丢失。
这是从别人博客上找到的
数据重复消费出来在那些地方，
底层根本原因：已经消费了数据，但是offset没提交。
原因1：强行kill线程，导致消费后的数据，offset没有提交。
原因2：设置offset为自动提交，关闭kafka时，如果在close之前，调用 consumer.unsubscribe() 则有可能部分offset没提交，下次重启会重复消费。会导致部分offset没提交，下次启动时会重复消费。
原因3（重复消费最常见的原因）：消费后的数据，当offset还没有提交时，partition就断开连接。比如，通常会遇到消费的数据，处理很耗时，导致超过了Kafka的session timeout时间（0.10.x版本默认是30秒），那么就会re-blance重平衡，此时有一定几率offset没提交，会导致重平衡后重复消费。
原因4：当消费者重新分配partition的时候，可能出现从头开始消费的情况，导致重发问题。
原因5：当消费者消费的速度很慢的时候，可能在一个session周期内还未完成，导致心跳机制检测报告出问题。
kafka怎么保证副本有三份或者所有副本都保存成功了，或者失败之后怎么办
kafka生成数据，有了一个副本之后，是不是就可以消费了
一个分区可以有多个副本，这些副本保存在不同的broker上。每个分区的副本中都会有一个作为Leader。当一个broker失败时，Leader在这台broker上的分区都会变得不可用，kafka会自动移除Leader，再其他副本中选一个作为新的Leader。
kafka创建副本的2种模式——同步复制和异步复制
Kafka动态维护了一个同步状态的副本的集合（a set of In-Sync Replicas），简称ISR，在这个集合中的节点都是和leader保持高度一致的，任何一条消息只有被这个集合中的每个节点读取并追加到日志中，才会向外部通知说“这个消息已经被提交”。
只有当消息被所有的副本加入到日志中时，才算是“committed”，只有committed的消息才会发送给consumer，这样就不用担心一旦leader down掉了消息会丢失。
消息从leader复制到follower, 我们可以通过决定Producer是否等待消息被提交的通知(ack)来区分同步复制和异步复制。同步复制流程：
1.producer联系zk识别leader
2.向leader发送消息
3.leadr收到消息写入到本地log
4.follower从leader pull消息
5.follower向本地写入log
6.follower向leader发送ack消息
7.leader收到所有follower的ack消息
8.leader向producer回传ack
异步复制流程：
和同步复制的区别在于，leader写入本地log之后，
直接向client回传ack消息，不需要等待所有follower复制完成。
kafka支持副本模式，那么其中一个Broker里的挂掉，一个新的leader就能通过ISR机制推选出来，继续处理读写请求。
4.3 kafka判断一个broker节点是否存活，依据2个条件：
1.节点必须可以维护和ZooKeeper的连接，Zookeeper通过心跳机制检查每个节点的连接
2. 如果节点是个follower,他必须能及时的同步leader的写操作，延时不能太久。Leader会追踪所有“同步中”的节点，一旦一个down掉了，或是卡住了，或是延时太久，leader就会把它移除
hive执行一个SQL，有where，有groupby，order，执行过程，有多少reduce，只要有order by最后都只有一个reduce
数据库优化是一个都会问的问题