那些让人眼前一亮的大数据面试题

一代大数据的处理方案

• linux 常见的shell编程

chmod 777 xx.sh
service iptables start|stop|restart|status
chkconfig 服务名 on|off
ps -aux|grep kill -9 ps -aux |grep 进程名字|awk '{print $1}'
用户变量：~/.bashrc|.bash_profile 系统变量 /etc/profile source 配置文件
编译安装./configure && make|make install
touch/mkdir/rm/cp/mv/vi
scp -R|r(递归拷贝) 文件名 用户名@主机地址：路径
ssh 用户名@目标主机 ssh免密码认证:ssh -keygen -t rsa ssh -copy -id目标主机
网卡略
工具 winscp SecureCRT Xshell X-term nodepad++

• HDFS的分布式文件存储 块存储、元数据

为什么在第一次启动Hdfs 的时候需要namenode格式化？
因为hdfs是基于块存储 namenode必须去保存整个文件系统的元数据（块信息），这些信息时持久化在fsimage中的。Hdfs在启动的时候Namenode会尝试去加载fsimage文件，恢复上一次关机状态（恢复你元数据），当第一次构建Hdfs的时候因为系统中没有元数据，所以需要第一次启动的时候需要格式化，就是为了构建fsimage

阐述一下Namenode的启动过程，并解释SecondaryNameNode的作用？
当启动HDFS的时候，系统会首先启动Namenode,Namenode服务会去加载本地的fsimage元数据 edits操作日志文件，并且将这俩个文件在内存中进行合并，合并完成后会更新一个新的edits文件，同时刷新fsimage（Namenode处于安全模式 不接受写请求），需要注意该过程仅仅是在Namenode启动过程中执行一次，一旦Namenode进入状态，Namenode就不在更新fsimage，只是更新内存中的数据，同时在edits记录内存修改日志，这就导致HDFS长期出于工作过程中产生庞大的eidts文件，如果不加干预，下一次启动Namenode的时候会花费大量的时候去合并edits和fsimage文件导致启动缓慢，为了解决单机中的Namenode启动缓慢，一般会开启SecondaryNamenode辅助Namenode完成eidts和fsimage的合并。

NameNode死了SecondaryNameNode不替代，后宫不参政

HDFS常规服务解释
NameNode：存储元数据-单机内存、管理所有的Datanode，负责Block的create、Delete、replication指令发放
DataNode：存储块信息、响应client端的读写块请求、执行来自Namenode的命令，向Namenode汇报自身状态
SecondaryNameNode:辅助Namenode完成eidts和fsimage文件的合并

HDFS HA
journalnode:负责同步namenode中的操作日志信息，并且整理fsimage，替代了SecondaryNamenode
DFSZKFailoverController|zkfc:监测Namenode的健康状况，起到哨兵的作用，一旦AcitveNamenode宕机，standby Namenode会切换
Rack Aware：机架意识，通过配置机架，可以帮助NameNode|ResourceManager 更好的管理DataNode|NodeManger（大规模的集群）

注意：目前为止HA只支持俩个NameNode节点间的相互备份，存储的容量仍然是单机，如果需要构建超大规模的HDFS集群，目前可以考虑Federation（联邦） 就是对NameNode再做分区了。

• MapReduce

1. job的任务计算流程11步骤
   
   详情见我博客 https://blog.csdn.net/zax_java/article/details/96903282

2. job封装的6大步骤

写一个mapper extends Mapper 写一个reducer extends Reducer

1. 构建job
2. 设置输入输出格式 job.setInputFormatClass(TextInputFormat.class)
3. 设置数据的读入和写出的路径（写出路径必须不存在 由程序创建）
4. 设置mapper和reducer逻辑
5. 对shuffle格式的k-v说明 对output的输出格式说明（这里还可以设置分区数 combiner reduce个数等） job.setMapOutputKeyClass(Text.class) job.setOutputKeyClass(Text.class)
6. job提交

如何书写Mapper和Reducer

mapper端的输入k-v由输入格式inputformat决定 输出k-v k必须实现序列化(要溢写) 实现comparable接口 v必须实现writable
Reducer端输入的 k-v必须和map端的输出保持一致，输出端的k-v由输出格式决定（outputformat 中的record writer）

任务的发布形式

1. 打jar包 再jobsubmitter中添加 job.setJarByClass(XXX.class) hadoop jar xxx.jar 全类名job.setMapOutputKeyClass(Text.class) job.setOutputKeyClass(Text.class)job.setMapOutputKeyClass(Text.class) job.setOutputKeyClass(Text.class)
2. 跨平台提交(引入配置文件 addSource)
3. 本地运行

3. 任务提交的源码剖析

job.watforComplate
   submit
   		JobSubmitter(DFSClient,YarnRunner)
    		submitJobInternal
    			checkSpecs(job); //检查输出目录是否存在 
    			//tmp/hadoop-yarn/staging/root/.staging
    			Path jobStagingArea = JobSubmissionFiles.getStagingDir(cluster, conf);
    			JobID jobId = this.submitClient.getNewJobID();//获取任务Job_ID
    			Path submitJobDir = new Path(jobStagingArea, jobId.toString());//构建资源提交目录
				this.copyAndConfigureFiles(job, submitJobDir);//拷贝代码片段
                int maps = this.writeSplits(job, submitJobDir);//上传切片信息
                this.writeConf(conf, submitJobFile);//生成job.xml
                this.submitClient.submitJob(jobId, submitJobDir.toString(), job.getCredentials());//任务提交

4. InputFormat和OutputFormat的源码剖析

TextInputFormat
切面大小应该是0~140.8（128*1.1） split和你的快block的大小并不相等 所以MapReduce不擅长处理小文件，小文件过多 切面过多 你的进程就多 yarnchild多 就多占用一个G

TableInputFormat
根据你这张表中的region 未来就有多少个输入分片

Hdoop提供了小文件的解决方案
TextCombineInputFormat
前提是你小文件的格式必须是一致的

6. Shuffle源码剖析（分析、排序、序列化、combiner、map端压缩）
   

注意:combiner 虽好但不通用 输入和输出格式必须一致 例如除法不能用combiner
但是压缩可以通用

• Hbase

7. Hbase列存储特点 优势
   

磁盘利用率100%-支持稀疏 有就存 没有不存
可以大幅度提升io的利用率 把相似的数据归入一个列 独立的索引

8. Hbase和Hdfs的本质区别

都没关系，是俩种不同的东西

Hbase能达到什么级别?
数十亿行百万列数千版本=TB/PB 亚秒|毫秒 延迟 对海量数据的随机读写
目前还没有任何一个开源数据库可以达到这个延迟

9. Hmaster和Hregionserver、zookeeper关系
   *宏观架构
   
   Hregionserver内部架构（Block Cache、Region、WAL）

Region的内部结构（store、Memstore、StoreFile、compact）Region的分裂策略

RowKey设计

尽可能的把查询条件写在rowkey中
格式必须固定 不允许使用uuid这样查询效率太低了
MapReduce On Hbase*

• Hive-ETL工具 Sqoop

10. Hive和数据库的区别
11. Hive SQL的执行 HQL->MapReduce Hive的运行原理
    

Hive中的表分类：

• 管理表
• 外部表
• 分区表

• Zookeeper 分布式协调服务

12. zookeeper中常见的特性-持久性节点(数据永久保存)、临时节点（回话关闭丢失 临时节点不允许创建子节点）、临时序列节点（分布式锁 临时 有序）、持久序列节点 节点监测（watch）
13. 基于Zookeeper分布式锁的开发 CuratorFrameWorker (连接zookeeper client的jar包)
    详情见curator 分布式锁的博客

curator 连接zookeeper的client工具
curator.apache.org
锁定虚拟机间的线程
分布式锁就是一个临时序列节点 ReadWriteLock 写写互斥 读写互斥 读读并行

redis分布式锁和zookeeper分布式锁的区别？
redis的锁是无序的

除了这些锁 数据库还有行级锁
select 语句中的for updata 悲观锁和乐观锁
悲观锁：所有的操作都加锁 效率低下
乐观锁：在修改这条数据的时候先拿他的时间戳 我修改数据的时候如果我拿的时间戳和以前的不一致 说明有人改了 我们就放弃这次更新

分布式锁
跨虚拟机锁定线程

• Kafka

14. 消息队列（架构、offset、序列化、组消费策略、事务（幂等性））

幂等：多次操作最终影响等价于一次操作。
什么时候用到幂等：当生产者没有接受到指定书目的acks，生产者会根据用户配置retries次数重发数据，这样有可能导致数据的重复写入，为了解决这个问题开启幂等。

15. Kafka Streaming的流处理（架构、特点、窗口）

特点：topology是在分区内部执行 不存在任务间的shuffle，shuffle是通过将数据写回kafka内部的reparationtopic中，过滤一遍达到shuffle的目的
kafka分区的状态独立管理 通过kafka分区的Compact机制 将状态存储在changelog中

KTable:表示分区的装态，底层使用changelog实现
KStream：普通的topic

• Storm 实时流处理
  

16. 并行度分析
    

Task实际是Spout和Blot的实例。默认情况下一个线程只运行一个Task（一个线程中只有一个Spout或者Bolt）

是不是worker越多越好? storm博客中有

17. 可靠性分析（Acker、Tuple Tree）At Least Once机制

18. 状态管理

对比kafka storm spark状态的管理
流计算过程中的背压 storm中设置最大的处理kafka的数量 spark Streaming中设置微批的大小

19. Trident （常规算子）

20. Trident Exaxctly Once(事务，非透明化的事务) State管理

state的状态的管理 Exactly once
trident 分为事务和非透明化的事务
相同之处在于保证状态更新的严格有序
不同之处在于非透明化事务 事务id不变的前提之下 同一个批次的tuple可以不同

21. Storm-2.0 Stream API

窗口的分类 滑动 滚动 session window

processor time | event time (water maker)
strom 2.0之后对象可以自动序列化 在此之前想要处理对象 需要注册
storm中的3046 和kafka集成之后如果kafka中没有数据启不了
2.0的API 在19年6月份发布 对at least once语义做了一次升级

例如流计算对用户画像的统计什么的较为方便

• Flume 1.7.0 分布式日志采集

22. 常规组件 source(Avro可以和logback集成) （spoolDir采集静态文本目录）（taildirSource动态采集） channel（memory、file、jdbc） sink（Avro HDFS Kafka）、拦截器（时间戳、正则过滤、正则抽取）、通道选择器（复制、分流）、SinkProcessor负责分组（负载均衡、failover）

23. 和log4j、logback整合
    github上有开源的logback项目
24. 日志分流的设计