大数据实习生的面试总结

      不一样的公司面试内容不一样，有的注重基础知识有的注重项目，对实习生，也就是应届生，更多的是基础

由于没有什么工做经验，项目不少也不怎么样，因此也就问的少。下面是个人一点面试经验

我面试次数很少，多是运气比较好，几家就有了一个很满意的。一共面过两次大数据职位

一次java，一次商务智能，数据分析的。

       第一次就是大数据的，数据平台开发，小公司，没有笔试，就是拿着简历上的项目问。由于是本身

作的，不是公司的项目，因此有不少问题，具体问了什么就不详说了，须要注意的是本身项目的一些

架构问题，是否合理，是否本身很清楚，或者说本身能很清楚的描述出来，本身画出架构图。问了一些

知识点的问题，好比sparkRDD，spark和hive的区别，spark的鲁棒性，推荐系统的冷启动问题，这么监控

推荐系统是准确的，怎么实时的监控，就是系统已经发布上线了，怎么知道推荐是有效的。此类问题。

解答：SparkRDD五大特性，

RDD是SparkCore的核心，底层操做的就是RDD

RDD也就是弹性分布式数据集，虽然是数据集可是却不能存储数据，只是存放的一段代码逻辑

五大特性：

一、 RDD是由一系列partition组成

二、 RDD的算子做用在partition上

三、 RDD之间有依赖关系

四、 分区器做用在kv格式的RDD上

五、 partition对外提供最佳的计算位置，利于数据处理的本地化

弹性也就是容错性，RDD有依赖关系，能够根据前面的RDD计算出后面的RDD

RDD中的partition个数可多可少

分布式是RDD中的partition是分布在多个节点上

 这大概就是关于RDD的介绍

Spark和hive的区别其实就是Spark和MR的区别，我也简单总结一下，

一、Spark能够基于内存计算，MR基于磁盘迭代处理数据

二、Spark中有DAG有向无环图来切分stage的执行前后顺序

三、MapReduce只有map和reduce。spark中各类算子

四、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

数据库优化是一个都会问的问题

因为时间缘由下次更新，很快