大数据工程师面试题(七)

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

---

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都完成后作业结束。