大数据面试常见问题解答

    大数据（big data），一般来说是指无法在可承受的时间范围内用常规软件工具进行捕捉、管理和处理的数据集合。本文汇总了大数据面试中常见的问题及解答方案，供大家参考：

创新互联-专业网站定制、快速模板网站建设、高性价比茶陵网站开发、企业建站全套包干低至880元,成熟完善的模板库,直接使用。一站式茶陵网站制作公司更省心,省钱,快速模板网站建设找我们，业务覆盖茶陵地区。费用合理售后完善，十年实体公司更值得信赖。

1、Spark能否取代Hadoop？

答： Hadoop包含了Common,HDFS,YARN及MapReduce，Spark从来没说要取代Hadoop，最多也就是取代掉MapReduce。事实上现在Hadoop已经发展成为一个生态系统，并且Hadoop生态系统也接受更多优秀的框架进来，如Spark (Spark可以和HDFS无缝结合，并且可以很好的跑在YARN上).。 另一方面，Spark除了跟Hadoop生态结合外，也得到了其它一些框架的支持如ElasticSearch及Cassandra等等。 所以Hadoop生态并不是使用Spark的先决条件，尽管Spark非常好的融入了Hadoop生态。

2、谈谈Flink，跟Spark比较下？

答： 首先作为Spark在国内的布道者，我必须承认，我非常早的就关注了Flink : ) 目前Flink在欧洲的知名度还是可以的。 Flink跟Spark一样，都是希望做一体化的计算引擎(批处理，流处理，机器学习，图计算等)，并且他们都能很好的融入Hadoop生态(如跟HDFS无缝结合，及支持YARN作为调度框架等)。 咋一看两者略相似，但其实他们走的路子还是不太一样的，在Spark推出之际，就强调了“内存计算”，而Flink走的其实是类似MPP的路子。另一方面，Flink宣称能真正意义上做到实时计算，而Spark只能做micro batch。不过Flink支持的增量迭代还是挺有意思的，它能在迭代过程中只去处理那些变化的数据，事实上迭代到后面的时候，Flink只需要处理一小部分子集而已。不过以上都不是我最初关注Flink的原因，我当初关注Flink的原因是它对内存管理方面有着独到之处。 Flink一开始就决定自己做内存管理，它把heap分为三个部分: Network buffers, Memory Manager pool及Remaing heap，具体不展开了，有兴趣的可以字节去查看下相关资料。当然Spark也使出了杀手锏: project tungsten , 俗称钨丝计划，除了做自己的内存管理，也会做其它非常强悍的优化。这些优化将在1.4, 1.5, 1.6三个版本中体现。 哦，最后提一下，Spark只支持DAG，而Flink是支持cyclic的。 这个话题就先到这，后期很可能会来篇专门的文章。

3、谈谈你对HBase及Cassandra的看法？

答：首先，一些国内的工程师对Cassandra有着莫名其妙的误解，以为当年Facebook“抛弃”它，它就不行了，对此只能先呵呵。 我个人其实用HBase比较多，但是过去的一段时间，并没有用HBase(最多也就一年多前作为OpenTSDB的后端跑了下)。 HBase和Cassandra在很多地方还是很相似的。一、都是面向列的存储；二、都会先写到Log中，然后进入内存中的存储结构, 最后刷盘，甚至所用数据结构都差不多：LSM。简单来讲，从HBase的角度就是 Data到HLog到Memstor到StoreFile(HFile)；从Cassandra的角度就是Data到CommitLog到memtable到sstable。 三、略，太多了。 那我们还是看看不一样的地方吧，HBase需要ZK支持，Cassandra自给自足；HBase需要有Master，Cassandra需要有seed nodes； HBase要从ZK获取信息，Cassandra使用gossip来通信；HBase底层要有HDFS支持，Cassandra不用；HBase原生不支持二级索引，Cassandra支持；HBase老早就有coprocessor，Cassandra木有......不一一列了吧。 最大不同点还是HBase本质上还是一个中心化的组织(peer-to-peer)，而Cassandra是去中心化的，我可能会更偏向后者。 目前很难说孰优孰劣，你的选型你做主 : )

4、分布式消息队列在流处理系统中是十分重要的，你选择的消息队列是哪个？能否简述下原因？

答：毫无疑问 Kafka! 最多前面加个Flume。 任何选型的原因，都源自你的需求是什么。 Fast,Scalable,Durable是我的需求，Kafka完美满足。稍微讲些细节，好多想必大家也都知道。 Kafka将数据写到磁盘，实际上都会写到OS的page cache里， 而读的时候又用sendfile非常高效的将数据传输到NIC。Kafka的扩展性也非常好，只要增加broker即可。Kafka的逻辑也非常清晰，可以将不同业务逻辑的数据写进不同到topic，而topic又可以切分成若干个partition来并行处理，并且Kafka0.9后，zk只需要被broker所使用，consumer并不再需要使用zk来记录offset，大大降低zk的压力，同时也从侧面降低了scale的压力。Kafka也有比较友好的删除策略。可以直接按照max age或者max size自动删除，也可以按照key进行compact，基本上都能满足需求。另一方面，Kafka的社区非常活跃，并且现在几乎所有流行的(流式)计算框架都支持Kafka，如Spark Streaming，Storm等。对了，有个叫camus的工具定期可以将Kafka里的数据搬到HDFS上，已经推荐一些小伙伴用过。 还是那句话，看需求，且能hold住。

5、 你对Tachyon的看法如何？

答：我是非常早就试用了Tachyon，注意，是试用！ 现在已经有商业公司TachyonNexus为其保驾护航了。哦，对了，先说明下，Tachyon是用Java写的，并不是用Scala写的。我本人对Tachyon的前景非常看好，说了半天好像还没说Tachyon是个什么玩意儿。Tachyon是分布式内存文件系统，随着内存越来越廉价，只要Tachyon本身质量过硬，显然不愁用户。稍微简单谈下Tachyon的原理及特点吧，作为基于内存的文件系统，那显然要非常激进的使用内存了，那这时候就会有人担心了，node挂了内存里数据丢失怎么办，这个其实不用担心，在Tachyon下面一般还会有一层underlying filesystem，大多数情况下是HDFS，当然也支持其它一些文件系统, Tachyon定期会把数据checkpoint到underlying filesystem里。事实上Tachyon也有Journal(p_w_picpath + edit)的概念，非常有意思的是，Tachyon把Spark里lineage的理念搬了过来，依靠lineage做文件恢复。前面说到，现在出来一个framework，不跟Hadoop生态结合是很难混的，所以Tachyon也非常友好的实现了HDFS的接口，因此MapReduce及Spark，包括Flink都可以在几乎不改动代码的情况下使用Tachyon。Tachyon另一个出色的点是支持table，用户可以把查询密度高的column放进Tachyon，以此提高查询效率。再补充几个Tachyon可以解决的case：Spark的不同job间共享数据；不同框架间共享数据；避免Spark由于blockmanager挂掉后cache全丢失；解决内存重复使用的问题，等。 这个问题就此打住，不展开了。(以上内容转载自：ChinaScala)

6、有10个文件，每个文件1G，每个文件的每一行存放的都是用户的query，每个文件的query都可能重复。要求你按照query的频度排序。

方案1： 

1）顺序读取10个文件，按照hash(query)%10的结果将query写入到另外10个文件（记为 ）中。这样新生成的文件每个的大小大约也1G（假设hash函数是随机的）。 

  2）找一台内存在2G左右的机器，依次对 用hash_map(query, query_count)来统计每个query出现的次数。利用快速/堆/归并排序按照出现次数进行排序。将排序好的query和对应的query_cout输出到文件中。这样得到了10个排好序的文件（记为 ）。 

3）对 这10个文件进行归并排序（内排序与外排序相结合）。

　方案2： 

一般query的总量是有限的，只是重复的次数比较多而已，可能对于所有的query，一次性就可以加入到内存了。这样，我们就可以采用trie树/hash_map等直接来统计每个query出现的次数，然后按出现次数做快速/堆/归并排序就可以了。 

方案3： 

与方案1类似，但在做完hash，分成多个文件后，可以交给多个文件来处理，采用分布式的架构来处理（比如MapReduce），最后再进行合并。 

7、 有一个1G大小的一个文件，里面每一行是一个词，词的大小不超过16字节，内存限制大小是1M。返回频数最高的100个词。 

方案：顺序读文件中，对于每个词x，取 ，然后按照该值存到5000个小文件（记为 ）中。这样每个文件大概是200k左右。如果其中的有的文件超过了1M大小，还可以按照类似的方法继续往下分，知道分解得到的小文件的大小都不超过1M。对每个小文件，统计每个文件中出现的词以及相应的频率（可以采用trie树/hash_map等），并取出出现频率最大的100个词（可以用含100个结点的最小堆），并把100词及相应的频率存入文件，这样又得到了5000个文件。下一步就是把这5000个文件进行归并（类似与归并排序）的过程了。 

8、海量日志数据，提取出某日访问百度次数最多的那个IP。 

方案：首先是这一天，并且是访问百度的日志中的IP取出来，逐个写入到一个大文件中。注意到IP是32位的，最多有 个IP。同样可以采用映射的方法，比如模1000，把整个大文件映射为1000个小文件，再找出每个小文中出现频率最大的IP（可以采用hash_map进行频率统计，然后再找出频率最大的几个）及相应的频率。然后再在这1000个最大的IP中，找出那个频率最大的IP，即为所求。 

9、在2.5亿个整数中找出不重复的整数，内存不足以容纳这2.5亿个整数。 

方案1：采用2-Bitmap（每个数分配2bit，00表示不存在，01表示出现一次，10表示多次，11无意义）进行，共需内存 内存，还可以接受。然后扫描这2.5亿个整数，查看Bitmap中相对应位，如果是00变01，01变10，10保持不变。所描完事后，查看bitmap，把对应位是01的整数输出即可。 

方案2：也可采用上题类似的方法，进行划分小文件的方法。然后在小文件中找出不重复的整数，并排序。然后再进行归并，注意去除重复的元素。

10、怎么在海量数据中找出重复次数最多的一个？ 

方案：先做hash，然后求模映射为小文件，求出每个小文件中重复次数最多的一个，并记录重复次数。然后找出上一步求出的数据中重复次数最多的一个就是所求（具体参考前面的题）。