转载自: 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更灵活。
(1)Java篇
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越来越稳定,越来越向生产环境使用发展。 |
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"; |
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都完成后作业结束。 |