剑指大数据面试：

剑指大数据面试：

linux相关常考的内容：

1. grep 对内容的检索：

   检索文件内容：“内容” 文件名

   grep “oop” pk* | grep “spark”

   管道符：| 多个指令连接起来，前一个指令的结果作为下一个指令的输入

   进程检索：ps -ef | grep zookeeper | grep -v “grep”

   -v 去掉grep 行

2. awk对内容的统计（默认分割符 Tab）

   ​ 获取列：awk ‘{print $1, $2}’ emp.txt
   ​ 获取行：awk ‘$18888’ emp.txt
   ​ 取出行&标题：awk '$18888 || NR==1’’ emp.txt
   ​ 指定分隔符：awk -F “,” ‘{print $1}’ sales.csv

3. sed对内容的替换：

   sed -i ‘s/需要替换内容/替换内容/’ 文件名

   sed
   替换文本：sed -i ‘s/String/val/’ test.txt
   替换分号：sed -i ‘s/;/ /’ test.txt
   全局替换：sed -i ‘s/Hadoop/hadoop/g’ test.txt 默认值替换一个， 最后加g,全部替换

   grep + awk 使用场景：
   监控FineBi进程是否关闭，重启进程

小文件

HDFS架构

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-zMtJTP7Q-1638119378730)(C:\Users\76437\AppData\Roaming\Typora\typora-user-images\image-20211129000027381.png)]

​ NameNode

​ DataNode

​ SecondNameNOde

概念：

​ Client
​ NN
​ 一个, Single Point of Failure ==> HA
​ metadata 元数据信息：谁创建 权限是什么 文件对应block的信息（几个块，在哪个位置）
​ DN
​ 多个
​ 存储数据
​ 和NN之间是有心跳的
​ Block
​ File存入HDFS，是按照block进行拆分 默认-128M
​ 容错：副本机制（replication）
​ Rack
​ 机架
​ HDFS读写流程

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-CJm1fVCl-1638119378731)(C:\Users\76437\AppData\Roaming\Typora\typora-user-images\image-20211129000512751.png)]

1）blocksize=128/64/256?
2)几副本：都是配置在hdfs的配置文件中的
副本：pipline方式传递给其他DataNode
Block1: 128M、Block2: 200 -128M
图解
写的流程：hadoop fs -put /test.txt /spark/file.txt

​ 写流程的理解：client告诉client我的文件有多大，namenode 分为几个block, 写在哪几个Dn上

读的流程：hadoop fs -text /spark/file.txt

读流程理解：client 读哪个文件， NN 返回目录信息，那几个blk1：在哪， blk2在哪

HA（高可用）

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-JooK3DcT-1638119378732)(C:\Users\76437\AppData\Roaming\Typora\typora-user-images\image-20211129000813374.png)]

HDFS HA实现
主和备
zookeeper 资源管理
Yarn HA

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-M3Gpg5jM-1638119378733)(C:\Users\76437\AppData\Roaming\Typora\typora-user-images\image-20211129000904393.png)]

RM HA
配置了HA， 但是主挂了，备起不来
SLA服务等级协议（简称：SLA，全称：service level agreement）如何保证？ 99.99% 99.95% 99.9% 怎么保证
NN HA
也有这个问题：
原因：小文件的问题

小文件是什么

小文件定义：

明显小于Block size的文件 80% 129M： 128M +1M

Hadoop中的目录、文件、blk都会以元数据的方式存储下来的，200字节（byte）上下

为什么会有小文件

​ spark处理 task决定文件多少，不可避免会产生，可规避

小文件给Hadoop集群带来的瓶颈问题

	1) 磁盘IO
	2)  task启动销毁的开销
	3) 资源有限

怎么解决小文件问题：

• JVM重用
• har归档
• 较少切片数

SQL on Hadoop

散记：单级分区/多级分区/静态分区/动态分区

业界常用sql on hadoop框架概述

​ hadoop生态
​ hive: sql ==>对应的sql转换成执行引擎的作业：MapReduce/spark/Tez
​ Impala: 提供足够的内存，对接hive，速度很快
​ presto： JD

​ 能对接多种数据源
​ 能从异构数据源查数据 hive/kafka
​ Drill:跨数据源连接
​ Phoenix: 利用sql查询 =》HBase(rowKey)
​ spark
​ norikra
​ MetaStore： 存储元数据信息，框架之间是共享元数据信息
​ Hive on Spark:Hive社区
​ Spark SQL: Spark社区

行式存储 vs 列式存储

常用调优策略宏观角度分析

架构层调优

分表

​ 架构： flume==>HDFS==>spark ETL ==> Spark Sql （大宽表）==SQL ==>Spark SQL/NoSQL（统计分析结果：供可视化展示）
​ 前提：

1）行式
2）每分钟2亿条数据
3）500个作业访问这个大表

分表200个字段 玻璃出需要的字段 =》 50个字段
思路：将需要的东西剥离出来 ==> 再进行统计

分区表

​ 场景：系统用户日志： who done
​ 分区表：
​ RDBMS分表 ： access20190808
​ hive
​ spark/access/day=20190808/…
​ spark/access/day=20190809/…
​ spark/access/day=20190810/…
​ 单级分区/多级分区
​ 静态分区/动态分区
​ 思路：现将数据限定在一定的范围，再进行搜索
​ 分区：创建、添加、重命名
​ partion
​ create table logs (ts int, line string)
​ partitioned by (df string, country string)
​ row format delimited fields terminated by ‘\t’
​ lines terminated by ‘\n’;

充分利用中间结果

​ select a,b,c from xx where …;
​ select a,c from xxx;
​ select a,d from xxx;
​

​ create table xx_temp as select a,b,c,d from xxx where …;
​

​ select a,b,c from xxx_tmp;
​ select a,c from xxx_tmp;
​ select a,d from xxx_tmp;
​ 降I/O负载提升提升作业性能
​ 处理场景：一份中间结果集，会被后续很对查询用到，建立临时表

压缩

压缩概述：

使用压缩算法来“减少”数据的过程。compress

​ 解压缩：将压缩后的数据转换成原始的数据过程。decompressed
​ 优缺点：
​ 优点：减少磁盘空间/disk I/O
​ 缺点：
​ flume 压缩： snappy
​ 使用场景：
​ 数仓
​ ods层
​ dwd层
​ dws层
​ ap层

压缩选型

​ lossless（无损）
​ lossy（有损）
​ compression format
​ gzip DEFLATE .gz
​ bzip2 bzip2 .bz2
​ LZO LZO .lzo
​ Snappy(tool: N/A) Snappy .snappy
​ 压缩在大数据中的使用场景：
​ 1）输入数据
​ 输入：考虑分片
​ 压缩是否支持分片
​ LZO
​ snappy
​ 2）中间数据
​ 中间：块
​ 3）输出数据
​ 输出：压缩比
​ 压缩比
反比于
压缩/解压速度
通过配置：hadoop/spark解压缩

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Lv3umexX-1638119378735)(C:\Users\76437\AppData\Roaming\Typora\typora-user-images\image-20211129002411920.png)]

压缩整合hadoop的使用

core-site.xml

<property>
<name>io.compression.codecs</name>
  <value>
   org.apache.hadoop.io.compress.GzipCodec,
   org.apache.hadoop.io.compress.DefaultCodec,
   org.apache.hadoop.io.compress.Bzip2Codec,
  </value>
</property>

判断是否支持：./hadoop checknative

mapred-site.xml

<property>
   <name>mapreduce.output.fileoutputformat.compress</name>
<value>true</value>
</property>
					<property>
    <name>mapreduce.output.fileoutputformat.compress.codec</name>
<value>org.apache.hadoop.io.compress.BZip2Codec</value>
</property>

压缩整合hive的使用

hadoop fs -du -s -h hdfs://hadoop000:8020/user/hive/warehouse/interview.db/page_views --查看文件大小
set hive.exec.compress.output=true; --开启压缩
set mapreduce.output.fileoutputformat.compress.codec=org.apache.hadoop.io.compress.BZip2Codec; --参数与hadoop配置文件里的参数公用，设置哪种压缩
desc formatted page_view_bzip2; --查看数据的位置

压缩的作业

1、hive：snappy、lzo（支持split,不支持split）的压缩比
2、spark来整合bzip2的使用

语法层调优

order by 和 sort by

order by
严格模式:需要限制行数
非严格模式
要谨慎使用
sort by:只能保证每个partion内部是有序的
set mapred.reduce.tasks=3; --设置reduce的数量
insert overwrite to local directory ‘/home/hadoop/hive/hive_tmp/sort’ select * from emp sort by deptno desc;

distribute by 和 cluster by

distribute by: 按照指定的字段把数据分散到不同的reduce里面去
示例：
一份日志数据，把xx相同的写到一个文件里，并按照yy排序

cluster by:
按照指定字段分发/降序

控制输出(reduce/partition/task)的数量

​ 1）reduce数量很大
​ 可能导致小文件
​ 2）reduce数量很少
​ 可能导致跑不出来
​ hive参数：
​ hive.exec.reduceers.bytes.per.reducer=150000000（默认为1GB）
​ 控制每个redcude处理的大小
​ hive.exec.reducers.max（默认为999）
​ 负数会使用最大数量
​ 计算公式：
​ reduce的数量：N = min(参数2， 总输入数据量/参数1)
​ spark参数：
​ spark：hive.reducer=spark.sql.partition(200)

执行计划

explain select xxx from table;
explain extended select xxx from table;
可查看抽象语法树
输出三个部分：
抽象系统查询语法树
dependencies between of the different stages of the plan
description of each of the stages

普通Join深度部析

​ MapReduce实现思路
​ 1）Mapper读取a表，Mapper去读取b表
​ 2）数据结构(a.id, a.) (b.id, b.)
​ 3）shuffle 相同的key分发到相同的reducer里面去
​ 4）在reducer端完成真正的join操作
​ reduce join = shuffle join

map join 深度部析

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ZIq8BE3P-1638119378737)(C:\Users\76437\AppData\Roaming\Typora\typora-user-images\image-20211129003353593.png)]

使用方式：

​ 1、set hive.auto.convert.join=true
​ 2、/+mapjoin(a,b)/
​ 3、/*+ STREAMTABLE(a) */

select  /*+ STREAMTABLE(a) */  a.val, b.val, c.val from a 
join b on (a.key = b.key) 
JOIN c ON (c.key = b.key1)；
a表被视为大表

多大算小表：

hive.smalltable.filesize(0.7.0)
or
hive.mapjoin.smalltable.filesize(0.8.1)

mapjoin:

​ 1）把小表加载缓存中
​ 2）通过mapper去读取大表的数据
​ 3）在读取大表数据的记录是和缓存中的小表数据直接进行对比
​ 4）join上就ok
​ HashTable Files >> Distributed Cache

运行调优

推测执行

应用场景：
现象:
长尾作业：一个job有100个reducer,其中99个很快运行完，只有最后一个话费很长的执行时间。那么这个job的运行时长是取决于最慢的一个task
原因：

资源不够型：
1)集群中NM/机器的负载时不一样
2）集群中机器的配置不同
处理数据太多：
3）数据倾斜（推测执行也解决不了）
设置参数
set hive.mapred.reduce.task.speculative.execution;

并行执行

条件：
1个到多个stage，stage的之间没有依赖
参数：
set hive.exec.parallel=true;
set hive.exec.parallel.thread.number=8;(默认8) 8/16/32…
场景：
moving files to inseret targets during multi-insert.
很多框架有相同的参数

JVM重用

参数
set mapred.job.reuse.jvm.num.tasks
maptask/reducetask 其实都是以进程的方式运行的，那么有多少个task就会启动多少个jvm；
当task运行完之后改jvm就会被销毁；
jvm启动和销毁时需要资源的开销
每个jvm可以执行多个task

spark调优篇

算子的合理选择

map vs mapPartion

1rdd = 100 partion ,1 pariton = 1w元素
map
map是对RDD中的每个元素作用上一个函数
mapPartion
mapPartion是将函数作用到partion上的时候
1、map是一个元素用完就释放
2、资源一个partion用完后才释放，partions 少的时候 出现oom > 调整partion数量（sc.parallelize(students, 10)）

foreach vs foreachPartition

用法和map/mapPartition是非常类似的，只不过是action和transformation的区别。写数据可一定要使用xxxPartion，action算子会启动一个job

groupByKey vs reduceByKey

reduceByKey
会先在map端做一个本地的聚合，然后将聚合的数据进行shuffle操作
map-side预聚合
aggregateByKey
groupByKey
是将所有的数据进行shuffle操作
图解：[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-0BJjgrsZ-1638119378738)(C:\Users\76437\AppData\Roaming\Typora\typora-user-images\image-20211129004505772.png)]

collect

收集全部数据，返回一个数组，所有的数据加载到driver端的内存里——》OOM
rdd.collect()
rdd.collect().take(n) 替换
rdd.saeAsTextFile(“hdfs://…”) 存储到hdfs上

coalesce vs repartition

colaesce
默认多到少
没有shuffle
底层会调用repartion
repartion
少到多

cache vs persist

持久化数据
cache 底层调用 persist
checkpoint：

需要手动指定存储目录：sc.setCheckPointDir(’…/’)
一个RDD缓存并checkpoint后，如果一旦发现缓存丢失，就会优先查看checkpoint数据存不存在，如果有，就会使用checkpoint数据，而不用重新计算
会多一个Job
示例：
实际生产中checkpoint 与cache一起用rdd.checkpoint()、rdd.cache()

序列化方式的合理选择

​ 序列化作用：
​ 涉及磁盘IO、网络IO
​ java序列化
​ 默认序列化
​ java.io.Serializable
​ 能序列化任何类
​ kryo序列化
​ 更加紧凑（占内存小点）
​ 不是支持所有的类，需要事先注册好类（注：不注册也能用但是可能没什么效果）
conf.set(“spark.serializer”,“org.apache.spark.serializer.kryoSerializer”)
示例：

val conf = new SparkConf().setMaster(..).setAppName(...)
conf.registerKryoClassers(Array(classof(MyClass1], classof[MyClass2]))
val sc = new SparkContext(conf)

流处理数据Sink到目的地的N中错误操作部析

​ Sink数据到MySQL
​ 基础环境准备
​ 功能开发及性能调优
​ 方式一：
​ 直接foreach
​ 方式二：
​ foreachPartition
​ 方式三：
​ 连接池
​ 序列化异常
​ 高性能写结果数据

如何保证流处理过程的零数据丢失

​ spark Streaming整合Kafka概述
​ spark Streaming整合kafka的两种方式：
​ kafka producer ==>kafka ==> Spark Streaming ==> wc ==>print
​ direct
​ recive

何如基于spark定制外部数据源

spark 常见的面试题

spark on yarn 两种方式的区别以及工作流程
yarn-cluster
yarn-client
spark内存管理
spark作业资源的设置情况
executor个数
memory
core
driver
shuffer机制
DataFrame、DataSet、RDD的区别以及编程
数据倾斜
RDD
Spark作业流程：
count 后续干了什么事情
spark中隐式转换的作用：
结合scala来学习
spark和MP的区别
spark规模
spark OOM如何解决
ThriftServer如何实现HA
kafka整合spark offset的管理
park、storm、Flink的区别
你在使用spark过程中遇到过哪些问题？你是如何解决的？亮点你在哪？
合理的算子选择
Catalyst的流程

数据倾斜

数据倾斜产生的原因及现象

对于大数据来说，数据量大并不可怕，可怕的是数据倾斜（当资源够的时候）
原因：
数据分布不均匀(key)不均匀 ==》 造成大量数据的集中在某个点上，造成热点问题
现象：
查看方式：
spark: ui 对应job/stage/task–查看task处理的数据量
1）大部分的task都非常快速处理完成，只有极少数的task处理的非常慢（有些场景下：虽然说极少数的task处理的较慢，但是最终还是能扣OK的）
2)spark/Hive作业运行的好好的，突然发生OOM，作业很大可能就挂了
a) 手工的去干预，去处理Low
b)遇到数据倾斜的场景要具备自适应的能力 high

shuffle:

hive
join 条件
group by 条件
count(distinct )
spark
sortByKey
groupByKey
reduceByKey
join
宽依赖-窄依赖
MapReduce中的Shuffle
图解：[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-A48Z1PPh-1638119378739)(C:\Users\76437\AppData\Roaming\Typora\typora-user-images\image-20211129005422537.png)]

什么是shuffle

在shuffle的时候，必须将各个节点相同key拉取到某一个节点进行task的处理
比如：join、group by。 如果某个key对应的数据量非常大，那么必然这个Key对应的数据进行处理的时候就会产生数据倾斜。

Spark中的Shuffle

spark中的依赖
窄依赖:
1对1/多对1
一个父RDD的partition至多被子RDD的partition使用一次
宽依赖:一个父RDD的partition会被子RDD的partition使用多次，有shuffle,遇到shuffle,原来的stage就会被拆分
窄依赖可以parallel执行

spark shuffle:

hash:
原来有hash
sort:
钨丝：
成本很高的操作：
disk I/O, data serialization, network I/O
网络传输 --》 需要数据序列化 --》 需要读取数据
图解：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-f9sK9BeF-1638119378740)(C:\Users\76437\AppData\Roaming\Typora\typora-user-images\image-20211129005714754.png)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-5woGPXBm-1638119378741)(C:\Users\76437\AppData\Roaming\Typora\typora-user-images\image-20211129005723242.png)]

userid 存在很多Null

数据倾斜的场景

group by

select deptno, count(1) from emp e group by e.deptno;(10,value)
(10,value)
(20,value)
(30,value)
相同的deptno分发到一个reduce上面去，然后再reduce里面完成count操作

join
根据on的条件来组织数据
select a., b. from a join b on a.id = b.id;
a: (id, a.)
b: (id, b.)
按照id做shuffle,相同的id分发到一个reduce上面去，然后再reduce完成join操作
count(distinct xxx )
底层原理思考： 是不是可以使用group by 完成 ==》 可能数据倾斜
如何解决？
如何解决？ ===》 key分发不均匀导致 ==》 打散
join: mapjoin
能不能打散
大小表
两大表
group by:
如何打散
添加随机数
explain join: expression