大数据面试题总结

1.Spark运行原理

1. 启动一个driver进程 ，用于控制整个流程
2. 当任务提交，首先会去向资源管理器–yarn,申请Executor资源，
3. 根据sparkContext获取运行环境，然后Driver会从程序倒着构建成DAG图，在将按照宽窄依赖减DAG图分解成stage，然后将Taskset发送给Task Scheduler 会将task 分给每一个stage ,最后将task发送给executor执行，执行之后在释放资源

2.MapReduce的shuffle原理：
最开始的split切片进入Map阶段，数据最先进入环形内存缓冲区（80%为阈值），然后会根据reduce个数分区，然后对每个分区的数据对key排序，然后会进行一个合并，合并就是为了减少网络I/O，使数据尽量减少网络传输的数据量，期间会经过多次的排序和合并，最后发送给reduce阶段。Reduce会接受各个map传过来的数据，再次进行合并和排序，最后当达到内存70%时，就会写入磁盘

3.kafka怎么保证数据不丢失 （ack机制）

1. Kafka 中有多个broker 每个broker包含多个topic 每个topic 中有多个partition（消息队列） 每个partition中有多个replication备份 类似与hdfs中的备份机制

2. Producer 端保证数据不丢失：ack机制 三种状态（0 1 -1）
   0：不管接受没有接受数据，都发送下一条数据
   1：只要leader确认接收到消息，才发送下一条数据
   -1：只要follwer确认接收到消息，才发送下一条数据

3. Consumer 端保证数据不丢失：offset 偏移量，它是存放在zookeeper中保证数据不重复 不丢失。Enable.auto.commit=true 开启自动提交（false关闭自动提交），一般是关闭，避免数据的丢失。

4. Flume 保证数据的不丢失

5. put 事务（source–>channel）
   流程： 首先把数据拉取到putList
   然后docommit 提交 到channel
   如果提交失败 dorollback 事务回滚

6. take事务（channel–>sink）
   流程： 首先把数据拉取到takeList
   然后docommit 提交 到sink
   如果提交失败 dorollback 事务回滚
   Sink如果成功发送到目的地，才会删除channel中的数据，
   Channel的两种缓冲形式，memory channel 和file channel.

7. hbase读写机制
   读：
   （1） 客户端通过zookeeper以及root表和meta表找到目标数据所在的regionserver
   （2）联系regionserver查询目标数据
   （3）regionserver定位到目标数据所在的region，发出查询请求
   （4）region先在memstore中查找，命中则返回
   （5）如果在memstore中找不到，则在storefile中扫描
   写：
   （1）client向region server提交写请求
   （2）region server找到目标region
   （3）region检查数据是否与schema（表结构）一致
   （4）如果客户端没有指定版本，则获取当前系统时间作为数据版本
   （5）将更新写入WAL log
   （6）将更新写入Memstore
   （7）判断Memstore的是否需要flush为StoreFile文件。

6.sql优化?

1. 大表join小表时，小表放在前面
2. 用索引提高效率
3. 尽量早过滤数据，减少每个阶段的数据量
4. 查询分区表要加分区
5. 尽量减少子查询，使用关联查询（left join,right join,inner join）替代
6. 使用表的别名(Alias)：
7. 用IN来替换OR
8. SELECT子句中避免使用 ‘ *’
9. 建表的时候能使用数字类型的字段就使用数字类型,数字类型的字段作为条件查询比字符串的快
10. 那些可以过滤掉最大数量记录的条件必须写在WHERE子句的最末尾

7.Hbase的rowkey设计 （时间戳+用户id）
1.设计原则：rouwkey长度不超过16个字节，最好加上时间戳，按天分表，提高查询效率
2.高位做散列（最好两字节做散列，四个字节存时间）
3.在rowkey加盐 （类如在rowkey前拼接字符串–UUID）
4.hash打散 （假设rowKey原本是自增长的long型，可以将rowkey转为hash再转为 bytes，加上本身id 转为bytes,组成rowkey）
5.反转/倒序
1)Rowkey长度原则 Rowkey 是一个二进制码流，长度最好不要超过16 个字节。
2)RowKey的唯一原则必须在设计上保证其唯一性
3)Rowkey的排序原则HBase的Rowkey是按照ASCII有序设计的
4)Rowkey的散列原则 容易出现热点问题，比如时间戳的递增
1.Reverse反转 比如手机号的前几位一样,反转之后就解决了热点问题但是牺牲了Rowkey的有序性
Salt加盐 Salting是将每一个Rowkey加一个前缀就是随机字符

9.hbase的热点问题

1. 热点现象： 某个小的时段内，对HBase的读写请求集中到极少数的Region上，导致这些Region所在的RegionServer处理请求量骤增，负载量明显偏大，而其他的RegionServer明显空闲；
2. 出现的原因： 主要是因为Hbase表设计时，rowKey设计不合理造成的；
3. 解决办法： Rowkey的随机散列+创表预分区

10.hadoop数据倾斜总结 （mapreduce,hdfs）
原因
1)、key分布不均匀
2)、业务数据本身的特性
3)、建表时考虑不周
4)、某些SQL语句本身就有数据倾斜
解决办法

1. 设置分区 在map阶段对key进行一次的小合并,把数据倾斜阶段提前到ETL工程中，做一下预处理
2. 增加reduce个数
3. 使用Sample算子进行随机抽样

12.Kafka结合Spark-streaming 的两种连接方式(AWL与直连)

1. 连接的方式有两种 awl 和 直连

2. 公司中用直连的方式比较多

3. 区别:
   Awl :（createStream）自动维护偏移量 有接收者 PUSH推送数据
   调用的Kafka高级API
   直连:（createDirectStream）手动维护偏移量 没有接收者 PULL拉取数据
   kafka低级API

4. Redis的两种持久化方式 RDB和AOF两种方式
   Rdb(默认)以一段时间的快照的方式进行持久化 速度快 性能高 安全性低
   Aof以日志的方式持久化,速度慢 性能低 安全性高

5. kafka为什么速度快

1. Kafka速度的秘诀在于，它把所有的消息都变成一个批量的文件，并且进行合理的批量压缩，减少网络IO损耗，
2. 通过map提高I/O速度，写入数据的时候由于单个Partion是末尾添加所以速度最优读取数据的时候配合sendfile直接暴力输出。
3. 零拷贝技术，可以有效的减少上下文切换和拷贝次数。
4. 顺序写磁盘的性能是随机写入的性能的6000倍的提升，媲美内存随机访问的性能，磁盘不再是瓶颈点。

15. ES的9200与9300区别

9200是http协议，对外提供服务
9300是TCP协议，jar之间，集群互相访问的端口

16. 维度建模三种模式
    星型模式（由一个事实表和一组维表成）
    雪花模式 (由一个事实表对应多个维度表，多个维度表可以对应多个维度表)
    星座模式（可以由多个事实表对应对个维度表）

17. hadoop集群提交命令
    hadoop jar xxx.jar input out

18. Spark集群提交命令
    spark-submit
    –class sea.LinuxHive
    –master spark://pengdahai1:7077
    –executor-memory 1g
    –total-executor-cores 2
    /root/spark.jar

19. Spark如何处理不能被序列化的对象?
    封装成 object

20.sqoop提交命令
sqoop import
–connect jdbc:mysql://192.168.xxx.xxx:3316/testdb
–username root
–password 123456
–query “select order_id, name from order_table where $CONDITIONS”
–target-dir /user/root/orders_all \
–split-by order_id
-m 6
–incremental append
–check-column order_id
–last-value 5201314

21、Storm与Spark、Hadoop、Flink四种框架对比

1. Hadoop适合于离线的批量数据处理适用于对实时性要求极低的场景
2. Storm适合于实时流数据处理，低延迟，高吞吐，亚秒级别
3. Spark是内存分布式计算框架，试图吞并Hadoop的Map-Reduce批处理框架和Storm的流处理框架，但是Spark已经做得很不错了，批处理方面性能优于Map-Reduce，但是流处理目前还是弱于Storm
4. Spark相对于MapReduce来说内存快100倍,磁盘快10倍
5. Flink设计原理是和spark的不一样,spark设计原理批处理, Flink是真正意义上的流式处理,时效性方面 :flink优于spark flink是毫秒级的 spark 是秒级

总的来说,spark和flink两个都支持窗口和算子，减少了不少的编程时间
flink相比于storm和spark，flink支持乱序和延迟时间（在实际场景中，这个功能很牛逼），
对于spark而言他的优势就是机器学习，如果我们的场景中对实时要求不高可以考虑spark，但是如果是要求很高就考虑使用flink
没有谁强谁弱,只有谁更适合

20. 请描述如何解决 Hbase中 region太小和 region太大带来的结果。

Region过大会发生多次 compaction,将数据读遍并写一遍到hdfs上,占用io, region过小会造成多次split, region会下线,影响访问服务,调整 hbase. heregion. max filesize为256m。

21. hadoop的机架感知(或者说是扩普)
    数据块会优先储存在namenode机架近的机器上