最近经历的一些大数据（Spark/Hadoop）面试题

jasonbetter 2017-06-07

展开全文

公司A：

1.讲讲你做的过的项目。项目里有哪些难点重点注意点呢？
2.讲讲多线程吧，要是你，你怎么实现一个线程池呢？
3.讲一下Mapreduce或者hdfs的原理和机制。map读取数据分片。
4.shuffle 是什么？怎么调优？
5.项目用什么语言写？ Scala？ Scala的特点？和Java的区别？
6.理论基础怎么样，比如数据结构，里面的快速排序，或者，树？讲一讲你了解的树的知识？
7.数学怎么样呢？
8.讲一下数据库，SQl ，左外连接，原理，实现？
9.还了解过数据的什么知识？数据库引擎？
10.Hadoop的机架怎么配置的？
11.Hbase的设计有什么心得？
12.Hbase的操作是用的什么API还是什么工具？
13.对调度怎么理解.? 用什么工具吗？
14.用kettle 这种工具还是自己写程序？你们公司是怎么做的？
15.你们数据中心开发周期是多长？
16.你们hbase里面是存一些什么数据。

二面。三个人。

1.讲讲你做的项目。
2.平时对多线程这方面是怎么处理呢？异步是怎么思考呢？遇到的一些锁啊，是怎么做的呢？比如两个人同时操作一样东西。怎么做的呢？一些并发操作设计到一些变量怎么做的呢？
3.你们用的最多是 http协议吧？有没有特殊的头呢？讲讲你对tcp/ip的理解？
4.有没有用过Zookeeper呢？ Zookeeper的适用场景是什么？ HA 状态维护分布式锁全局配置文件管理操作Zookeeper是用的什么？

Spark方面：

5.spark开发分两个方面？哪两个方面呢？
6.比如一个读取hdfs上的文件，然后count有多少行的操作，你可以说说过程吗。那这个count是在内存中，还是磁盘中计算的呢？磁盘中。
7.spark和Mapreduce快？为什么快呢？快在哪里呢？ 1.内存迭代。2.RDD设计。 3,算子的设计。
8.spark sql又为什么比hive快呢？
10.RDD的数据结构是怎么样的？ Partition数组。 dependence
11.hadoop的生态呢。说说你的认识。 hdfs底层存储 hbase 数据库 hive数据仓库 Zookeeper分布式锁 spark大数据分析

公司B：

1.Spark工作的一个流程。

提交任务。 
QQ图片20161019131411.png
用户提交一个任务。 入口是从sc开始的。 sc会去创建一个taskScheduler。根据不同的提交模式， 会根据相应的taskchedulerImpl进行任务调度。
同时会去创建Scheduler和DAGScheduler。DAGScheduler 会根据RDD的宽依赖或者窄依赖，进行阶段的划分。划分好后放入taskset中，交给taskscheduler 。
appclient会到master上注册。首先会去判断数据本地化，尽量选最好的本地化模式去执行。
打散 Executor选择相应的Executor去执行。ExecutorRunner会去创建CoarseGrainerExecutorBackend进程。 通过线程池的方式去执行任务。

反向：
Executor向 SchedulerBackend反向注册

Spark On Yarn模式下。 driver负责计算调度。appmaster 负责资源的申请。

2.Hbase的PUT的一个过程。
3.RDD算子里操作一个外部map比如往里面put数据。然后算子外再遍历map。有什么问题吗。
4.shuffle的过程。调优。
5.5个partition里面分布有12345678910.用算子求最大值或者和。不能用广播变量和累加器。或者sortbykey.
6.大表和小表join.
7.知道spark怎么读hbase吗？spark on hbase.。华为的。
8.做过hbase的二级索引吗？
9.sort shuffle的优点？
10.stage怎么划分的？宽依赖窄依赖是什么？

公司W：

1.讲讲你做过的项目(一个整体思路)
2.问问大概情况。公司里集群规模。hbase数据量。数据规模。
3.然后挑选数据工厂开始详细问。问hbase.。加闲聊。
4.问二次排序是什么。topn是什么。二次排序要继承什么接口？
5.计算的数据怎么来的。
6.kakfadirect是什么，。为什么要用这个，有什么优点？。和其他的有什么区别。

http://blog.csdn.net/erfucun/article/details/52275369

  /**
   * Create an input stream that directly pulls messages from Kafka Brokers
   * without using any receiver. This stream can guarantee that each message
   * from Kafka is included in transformations exactly once (see points below).
   *
   * Points to note:
   *  - No receivers: This stream does not use any receiver. It directly queries Kafka
   *  - Offsets: This does not use Zookeeper to store offsets. The consumed offsets are tracked
   *    by the stream itself. For interoperability with Kafka monitoring tools that depend on
   *    Zookeeper, you have to update Kafka/Zookeeper yourself from the streaming application.
   *    You can access the offsets used in each batch from the generated RDDs (see
   *    [[org.apache.spark.streaming.kafka.HasOffsetRanges]]).
   *  - Failure Recovery: To recover from driver failures, you have to enable checkpointing
   *    in the [[StreamingContext]]. The information on consumed offset can be
   *    recovered from the checkpoint. See the programming guide for details (constraints, etc.).
   *  - End-to-end semantics: This stream ensures that every records is effectively received and
   *    transformed exactly once, but gives no guarantees on whether the transformed data are
   *    outputted exactly once. For end-to-end exactly-once semantics, you have to either ensure
   *    that the output operation is idempotent, or use transactions to output records atomically.
   *    See the programming guide for more details.
   *
   * @param ssc StreamingContext object
   * @param kafkaParams Kafka <a href="http://kafka./documentation.html#configuration">
   *    configuration parameters</a>. Requires "metadata.broker.list" or "bootstrap.servers"
   *    to be set with Kafka broker(s) (NOT zookeeper servers) specified in
   *    host1:port1,host2:port2 form.
   * @param fromOffsets Per-topic/partition Kafka offsets defining the (inclusive)
   *    starting point of the stream
   * @param messageHandler Function for translating each message and metadata into the desired type
   */