大数据工程师面试题--7

转载自：https://blog.csdn.net/u011682879/article/details/55803847

---

9. 面试问题:

1.从前到后从你教育背景(学过哪些课)到各个项目你负责的模块,问的很细(本以为他是物理学博士,但是所有的技术都懂)
2.hadoop 的 namenode 宕机,怎么解决
先分析宕机后的损失，宕机后直接导致client无法访问，内存中的元数据丢失，但是硬盘中的元数据应该还存在，如果只是节点挂了，
重启即可，如果是机器挂了，重启机器后看节点是否能重启，不能重启就要找到原因修复了。但是最终的解决方案应该是在设计集群的初期
就考虑到这个问题，做namenode的HA。
3.一个datanode 宕机,怎么一个流程恢复
Datanode宕机了后，如果是短暂的宕机，可以实现写好脚本监控，将它启动起来。如果是长时间宕机了，那么datanode上的数据应该已经
被备份到其他机器了，那这台datanode就是一台新的datanode了，删除他的所有数据文件和状态文件，重新启动。
4.Hbase 的特性,以及你怎么去设计 rowkey 和 columnFamily ,怎么去建一个table
因为hbase是列式数据库，列非表schema的一部分，所以在设计初期只需要考虑rowkey 和 columnFamily即可，rowkey有位置相关性，所以
如果数据是练习查询的，最好对同类数据加一个前缀，而每个columnFamily实际上在底层是一个文件，那么文件越小，查询越快，所以讲经
常一起查询的列设计到一个列簇，但是列簇不宜过多。
5.Redis,传统数据库,hbase,hive 每个之间的区别(问的非常细)
Redis是缓存，围绕着内存和缓存说
Hbase是列式数据库，存在hdfs上，围绕着数据量来说
Hive是数据仓库，是用来分析数据的，不是增删改查数据的。
6.公司之后倾向用spark 开发,你会么(就用java代码去写)
会，spark使用scala开发的，在scala中可以随意使用jdk的类库，可以用java开发，但是最好用原生的scala开发，兼容性好，scala更灵活。

10. 面试问题:

1.笔试: java基础(基本全忘,做的很烂,复习大数据连单例都忘了怎么写)
复习java面试宝典
2.开始介绍项目,直接用大数据项目介绍,项目经理也懂大数据
3.Mapreduce 一些流程,经过哪些步骤
Map—combiner—partition—sort—copy—sort—grouping—reduce
4.说下对hadoop 的一些理解,包括哪些组件
详谈hadoop的应用，包括的组件分为三类，分别说明hdfs，yarn，mapreduce
5.详细讲解下你流式实时计算的项目部署以及收集的结果情况
讲解storm集群的部署方案，项目的大小，使用的worker数，数据收集在hbase或者hdfs，好处是什么
6.你的数据库是不是很大么,有没有分表,分区,你是怎么实现的
数据库的分表在设计初期是按照月份进行拆分的，不同的月份查询不同的表。分区没弄过。
7.开始问java的一些东西(从各种框架原理到各种复杂SQL)
8.多线程,并发,垃圾回收机制,数据结构(问这些,基本觉得看你是不是高级程序员了)
多线程要知道操作方式，线程安全的锁，并且要知道lock锁
垃圾回收机制需要详细了解（见云笔记），主要从内存划分，垃圾回收主要的工作区域，垃圾回收器的种类，各有什么优缺点，
用在哪里合适。
数据结构基本的要知道，复杂的参考相关的书籍。

11. 面试问题:

1.BI小组的3个年轻学生一起技术面试(一个是南开博士）
2.数据量多少,集群规模多大,型号
一般中型的电商或者互联网企业，日志量每天在200-500M左右，集群规模在30-50台左右，机器一般为dell的2000左右的服务器，型号不定
大型的互联网公司据网上资料显示，日志量在GP-PB不等，集群规模在500-4000不等，甚至更多，机器型号不确定。
3.项目,mapreduce
介绍整个mapreduce项目流程，数据采集—数据聚合—数据分析—数据展示等
4.实时流式计算框架,几个人,多长时间,细节问题,包括讲flume ,kafka ,storm 的各个的组件组成,你负责那一块,如果需要你搭建你可以
完成么?
5.你觉得spark 可以完全替代hadoop 么?

12. 面试问题:

1.一些传统的hadoop 问题,mapreduce 他就问shuffle 阶段,你怎么理解的
Shuffle意义在于将不同map处理后的数据进行合理分配，让reduce处理，从而产生了排序、分区。
2.Mapreduce 的 map 数量 和 reduce 数量 怎么确定 ,怎么配置
Map无法配置，reduce随便配置
3.唯一难住我的是他说实时计算,storm 如果碰上了复杂逻辑,需要算很长的时间,你怎么去优化
拆分复杂的业务到多个bolt中，这样可以利用bolt的tree将速度提升
4.Hive 你们用的是外部表还是内部表,有没有写过UDF(当然吹自己写过了),hive 的版本
外部表，udf，udaf等，hive版本为1.0
5.Hadoop 的版本
如果是1.0版本就说1.2，如果是2.0版本，就说2.6或者2.7
1.2为官方稳定版本，2.7为官方稳定版本。
Apache Hadoop 2.7.1于美国时间2015年07月06日正式发布，本版本属于稳定版本，是自Hadoop 2.6.0以来又一个稳定版，同时也是
Hadoop 2.7.x版本线的第一个稳定版本，也是 2.7版本线的维护版本，变化不大，主要是修复了一些比较严重的Bug
6.实时流式计算的结果内容有哪些,你们需要统计出来么(我就说highchart展示)
简单介绍日志监控、风控等结果内容，统计出来显示在报表或者邮件中。
7.开始问java相关,包括luecne,solr(倒排索引的原理),框架呀,redis呀

13. 京东商城 - 大数据

（1）Java篇
1、JVM，GC（算法，新生代，老年代），JVM结构
2、hashcode，hashMap，list，hashSet，equals（结构原理），A extends B（类的加载顺序）
1.父类静态代码块；
2.子类静态代码块；
3.父类非静态代码块；
4.父类构造函数；
5.子类非静态代码块；
6.子类构造函数；
3、多线程，主线程，次线程，唤醒，睡眠
略
4、常见算法：冒泡算法，排序算法，二分查找，时间复杂度
略
（2）Flume篇
1、数据怎么采集到Kafka，实现方式
使用官方提供的flumeKafka插件，插件的实现方式是自定义了flume的sink，将数据从channle中取出，通过kafka的producer写入到kafka中，
可以自定义分区等。
2、flume管道内存，flume宕机了数据丢失怎么解决
1、Flume的channel分为很多种，可以将数据写入到文件
2、防止非首个agent宕机的方法数可以做集群或者主备
3、flume配置方式，flume集群（问的很详细）
Flume的配置围绕着source、channel、sink叙述，flume的集群是做在agent上的，而非机器上。
4、flume不采集Nginx日志，通过Logger4j采集日志，优缺点是什么？
优点：Nginx的日志格式是固定的，但是缺少sessionid，通过logger4j采集的日志是带有sessionid的，而session可以通过redis共享，
保证了集群日志中的同一session落到不同的tomcat时，sessionId还是一样的，而且logger4j的方式比较稳定，不会宕机。
缺点：不够灵活，logger4j的方式和项目结合过于紧密，而flume的方式比较灵活，拔插式比较好，不会影响项目性能。
5、flume和kafka采集日志区别，采集日志时中间停了，怎么记录之前的日志。
Flume采集日志是通过流的方式直接将日志收集到存储层，而kafka试讲日志缓存在kafka集群，待后期可以采集到存储层。
Flume采集中间停了，可以采用文件的方式记录之前的日志，而kafka是采用offset的方式记录之前的日志。
（3）Kafka篇
1、容错机制
分区备份，存在主备partition
2、同一topic不同partition分区
？？？？
3、kafka数据流向
Producer leader partition follower partition(半数以上) consumer
4、kafka+spark-streaming结合丢数据怎么解决？

spark streaming从1.2开始提供了数据的零丢失，想享受这个特性，需要满足如下条件：

1. 数据输入需要可靠的sources和可靠的receivers

2. 应用metadata必须通过应用driver checkpoint

3. WAL（write ahead log）

1.1. 可靠的sources和receivers

spark streaming可以通过多种方式作为数据sources（包括kafka），输入数据通过receivers接收，通过replication存储于spark中（为了faultolerance，默认复制到两个spark executors），如果数据复制完成，receivers可以知道（例如kafka中更新offsets到zookeeper中）。这样当receivers在接收数据过程中crash掉，不会有数据丢失，receivers没有复制的数据，当receiver恢复后重新接收。

 

1.2. metadata checkpoint

可靠的sources和receivers，可以使数据在receivers失败后恢复，然而在driver失败后恢复是比较复杂的，一种方法是通过checkpoint metadata到HDFS或者S3。metadata包括：

· configuration

· code

· 一些排队等待处理但没有完成的RDD（仅仅是metadata，而不是data）



这样当driver失败时，可以通过metadata checkpoint，重构应用程序并知道执行到那个地方。

1.3. 数据可能丢失的场景

可靠的sources和receivers，以及metadata checkpoint也不可以保证数据的不丢失，例如：

· 两个executor得到计算数据，并保存在他们的内存中

· receivers知道数据已经输入

· executors开始计算数据

· driver突然失败

· driver失败，那么executors都会被kill掉

· 因为executor被kill掉，那么他们内存中得数据都会丢失，但是这些数据不再被处理

· executor中的数据不可恢复

1.4. WAL

为了避免上面情景的出现，spark streaming 1.2引入了WAL。所有接收的数据通过receivers写入HDFS或者S3中checkpoint目录，这样当driver失败后，executor中数据丢失后，可以通过checkpoint恢复。

1.5. At-Least-Once

尽管WAL可以保证数据零丢失，但是不能保证exactly-once，例如下面场景：

· Receivers接收完数据并保存到HDFS或S3

· 在更新offset前，receivers失败了



· Spark Streaming以为数据接收成功，但是Kafka以为数据没有接收成功，因为offset没有更新到zookeeper

· 随后receiver恢复了

· 从WAL可以读取的数据重新消费一次，因为使用的kafka High-Level消费API，从zookeeper中保存的offsets开始消费

1.6. WAL的缺点

通过上面描述，WAL有两个缺点：

· 降低了receivers的性能，因为数据还要存储到HDFS等分布式文件系统

· 对于一些resources，可能存在重复的数据，比如Kafka，在Kafka中存在一份数据，在Spark Streaming也存在一份（以WAL的形式存储在hadoop API兼容的文件系统中）

1.7. Kafka direct API

为了WAL的性能损失和exactly-once，spark streaming1.3中使用Kafka direct API。非常巧妙，Spark driver计算下个batch的offsets，指导executor消费对应的topics和partitions。消费Kafka消息，就像消费文件系统文件一样。

 

1. 不再需要kafka receivers，executor直接通过Kafka API消费数据

2. WAL不再需要，如果从失败恢复，可以重新消费

3. exactly-once得到了保证，不会再从WAL中重复读取数据

1.8. 总结

主要说的是spark streaming通过各种方式来保证数据不丢失，并保证exactly-once，每个版本都是spark streaming越来越稳定，越来越向生产环境使用发展。

5、kafka中存储目录data/dir…topic1和topic2怎么存储的，存储结构，data…目录下有多少个分区，每个分区的存储格式是什么样的？

• 1、topic是按照“主题名-分区”存储的
• 2、分区个数由配置文件决定
• 3、每个分区下最重要的两个文件是0000000000.log和000000.index，0000000.log以默认1G大小回滚。
  （4）Hive篇
  1、hive partition分区
  分区表，动态分区
  2、insert into 和 override write区别？
  insert into：将某一张表中的数据写到另一张表中
  override write：覆盖之前的内容。
  3、假如一个分区的数据主部错误怎么通过hivesql删除hdfs
  alter table ptable drop partition (daytime=‘20140911’,city=‘bj’);
  元数据，数据文件都删除，但目录daytime= 20140911还在
  （5）Storm篇
  1、开发流程，容错机制
  开发流程：
  1、写主类（设计spout和bolt的分发机制）
  2、写spout收集数据
  3、写bolt处理数据，根据数据量和业务的复杂程度，设计并行度。
  容错机制：采用ack和fail进行容错，失败的数据重新发送。
  2、storm和spark-streaming：为什么用storm不同spark-streaming
  3、mr和spark区别，怎么理解spark-rdd
  Mr是文件方式的分布式计算框架，是将中间结果和最终结果记录在文件中，map和reduce的数据分发也是在文件中。
  spark是内存迭代式的计算框架，计算的中间结果可以缓存内存，也可以缓存硬盘，但是不是每一步计算都需要缓存的。
  Spark-rdd是一个数据的分区记录集合………………
  4、sqoop命令

sqoop import --connect jdbc:mysql://192.168.56.204:3306/sqoop --username hive --password hive --table jobinfo --target-dir /sqoop/test7 --inline-lob-limit 16777216 --fields-terminated-by '\t' -m 2

sqoop create-hive-table --connect jdbc:mysql://192.168.56.204:3306/sqoop --table jobinfo --username hive --password hive --hive-table sqtest --fields-terminated-by "\t" --lines-terminated-by "\n";

（6）Redis篇
1、基本操作，存储格式
略
（7）Mysql篇
1、mysql集群的分布式事务
京东自主开发分布式MYSQL集群系统
2、mysql性能优化（数据方面）
数据的分表、分库、分区
（6）Hadoop篇
1、hadoop HA 两个namenode和zk之间的通信，zk的选举机制？
HA是通过先后获取zk的锁决定谁是主
Zk的选举机制，涉及到全新机群的选主和数据恢复的选主
2、mr运行机制

3、yarn流程

• 1. 用户向YARN 中提交应用程序， 其中包括ApplicationMaster 程序、启动ApplicationMaster 的命令、用户程序等。
• 2. ResourceManager 为该应用程序分配第一个Container， 并与对应的NodeManager 通信，要求它在这个Container 中启动应用程序
     的ApplicationMaster。
• 3. ApplicationMaster 首先向ResourceManager 注册， 这样用户可以直接通过ResourceManage 查看应用程序的运行状态，然后它将
     为各个任务申请资源，并监控它的运行状态，直到运行结束，即重复步骤4~7。
• 4. ApplicationMaster 采用轮询的方式通过RPC 协议向ResourceManager 申请和领取资源。
• 5. 一旦ApplicationMaster 申请到资源后，便与对应的NodeManager 通信，要求它启动任务。
• 6. NodeManager 为任务设置好运行环境（包括环境变量、JAR 包、二进制程序等）后，将任务启动命令写到一个脚本中，并通过运行
     该脚本启动任务。
• 7. 各个任务通过某个RPC 协议向ApplicationMaster 汇报自己的状态和进度，以让ApplicationMaster 随时掌握各个任务的运行状态，
     从而可以在任务失败时重新启动任务。在应用程序运行过程中，用户可随时通过RPC 向ApplicationMaster 查询应用程序的当前运行状态。
• 8. 应用程序运行完成后，ApplicationMaster 向ResourceManager 注销并关闭自己。

（7）Hbase
1、涉及到概念，文档

（8）Spark篇
1、spark原理

Spark应用转换流程

• 1、 spark应用提交后，经历了一系列的转换，最后成为task在每个节点上执行

• 2、 RDD的Action算子触发Job的提交，生成RDD DAG

• 3、 由DAGScheduler将RDD DAG转化为Stage DAG，每个Stage中产生相应的Task集合

• 4、 TaskScheduler将任务分发到Executor执行

• 5、 每个任务对应相应的一个数据块，只用用户定义的函数处理数据块

Driver运行在Worker上

   通过org.apache.spark.deploy.Client类执行作业，作业运行命令如下：

 

作业执行流程描述：

1、客户端提交作业给Master

2、Master让一个Worker启动Driver，即SchedulerBackend。Worker创建一个DriverRunner线程，DriverRunner启动SchedulerBackend进程。

3、另外Master还会让其余Worker启动Exeuctor，即ExecutorBackend。Worker创建一个ExecutorRunner线程，ExecutorRunner会启动ExecutorBackend进程。

4、ExecutorBackend启动后会向Driver的SchedulerBackend注册。SchedulerBackend进程中包含DAGScheduler，它会根据用户程序，生成执行计划，并调度执行。对于每个stage的task，都会被存放到TaskScheduler中，ExecutorBackend向SchedulerBackend汇报的时候把TaskScheduler中的task调度到ExecutorBackend执行。

5、所有stage都完成后作业结束。

Driver运行在客户端

作业执行流程描述：

1、客户端启动后直接运行用户程序，启动Driver相关的工作：DAGScheduler和BlockManagerMaster等。

2、客户端的Driver向Master注册。

3、Master还会让Worker启动Exeuctor。Worker创建一个ExecutorRunner线程，ExecutorRunner会启动ExecutorBackend进程。

4、ExecutorBackend启动后会向Driver的SchedulerBackend注册。Driver的DAGScheduler解析作业并生成相应的Stage，每个Stage包含的Task通过TaskScheduler分配给Executor执行。

5、所有stage都完成后作业结束。