x我有辣条跟我走。
x我有辣条跟我走。

大数据技术之高频面试题

转载请注明来源！

第一章

  1. 项目涉及技术

1.1 Linux&Shell

1.1.1 Linux常用高级命令

序号

命令

命令解释

1

top

查看内存

2

df -h

查看磁盘存储情况

3

iotop

查看磁盘IO读写(yum install iotop安装）

4

iotop -o

直接查看比较高的磁盘读写程序

5

netstat -tunlp | grep 端口号

查看端口占用情况

6

uptime

查看报告系统运行时长及平均负载

7

ps -aux

查看进程

1.1.2 Shell常用工具及写过的脚本

1）awk、sed、cut、sort

2）用Shell写过哪些脚本

（1）集群启动，分发脚本

（2）数仓与mysql的导入导出

（3）数仓层级内部的导入

1.1.3 Shell中提交了一个脚本，进程号已经不知道了，但是需要kill掉这个进程，怎么操作?

ssh $i "ps -ef | grep file-flume-kafka | grep -v grep |awk '{print \$2}' | xargs kill"

1.1.4 Shell中单引号和双引号区别

1）在/home/hadoop/bin创建一个test.sh文件

[hadoop@bigdata02 bin]$ vim test.sh

在文件中添加如下内容

#!/bin/bash

do_date=$1

 

echo '$do_date'

echo "$do_date"

echo "'$do_date'"

echo '"$do_date"'

echo `date`

2）查看执行结果

[hadoop@bigdata02 bin]$ test.sh 2019-02-10

$do_date

2019-02-10

'2019-02-10'

"$do_date"

2019年 05月 02日 星期四 21:02:08 CST

3）总结：

（1）单引号不取变量值

（2）双引号取变量值

（3）反引号`，执行引号中命令

（4）双引号内部嵌套单引号，取出变量值

（5）单引号内部嵌套双引号，不取出变量值

 

 

1.2 Hadoop

1.2.1 Hadoop常用端口号

 

hadoop2.x

Hadoop3.x

访问HDFS端口

50070   

9870

访问MR执行情况端口

8088    

8088    

历史服务器

19888  

19888  

客户端访问集群端口

9000

8020

1.2.2 Hadoop配置文件以及简单的Hadoop集群搭建

（1）配置文件：

Hadoop2.x core-site.xml、hdfs-site.xml、mapred-site.xml、yarn-site.xml   slaves

Hadoop3.x core-site.xml、hdfs-site.xml、mapred-site.xml、yarn-site.xml   workers

（2）简单的集群搭建过程：

JDK安装

配置SSH免密登录

配置hadoop核心文件: 

格式化namenode

1.2.3 HDFS读流程和写流程

大数据技术之高频面试题_第1张图片

大数据技术之高频面试题_第2张图片

 

 

1.2.4 HDFS小文件处理

1）会有什么影响

（1）1个文件块，占用namenode多大内存150字节

1亿个小文件*150字节

1 个文件块 * 150字节

128G能存储多少文件块？   128 * 1024*1024*1024byte/150字节 = 9亿文件块

2）怎么解决

（1）采用har归档方式，将小文件归档

（2）采用CombineTextInputFormat

（3）有小文件场景开启JVM重用；如果没有小文件，不要开启JVM重用，因为会一直占用使用到的task卡槽，直到任务完成才释放。

JVM重用可以使得JVM实例在同一个job中重新使用N次，N的值可以在Hadoop的mapred-site.xml文件中进行配置。通常在10-20之间

    mapreduce.job.jvm.numtasks

    10

    How many tasks to run per jvm,if set to -1 ,there is  no limit

  

1.2.5 Shuffle及优化

1、Shuffle过程

大数据技术之高频面试题_第3张图片

大数据技术之高频面试题_第4张图片

 

 

2、优化

1）Map阶段

（1）增大环形缓冲区大小。由100m扩大到200m

（2）增大环形缓冲区溢写的比例。由80%扩大到90%

（3）减少对溢写文件的merge次数。（10个文件，一次20个merge）

（4）不影响实际业务的前提下，采用Combiner提前合并，减少 I/O。

2）Reduce阶段

（1）合理设置Map和Reduce数：两个都不能设置太少，也不能设置太多。太少，会导致Task等待，延长处理时间；太多，会导致 Map、Reduce任务间竞争资源，造成处理超时等错误。

（2）设置Map、Reduce共存：调整slowstart.completedmaps参数，使Map运行到一定程度后，Reduce也开始运行，减少Reduce的等待时间。

（3）规避使用Reduce，因为Reduce在用于连接数据集的时候将会产生大量的网络消耗。

（4）增加每个Reduce去Map中拿数据的并行数

（5）集群性能可以的前提下，增大Reduce端存储数据内存的大小。

3）IO传输

采用数据压缩的方式，减少网络IO的的时间。安装Snappy和LZOP压缩编码器。

压缩：

（1）map输入端主要考虑数据量大小和切片，支持切片的有Bzip2、LZO。注意：LZO要想支持切片必须创建索引；

（2）map输出端主要考虑速度，速度快的snappy、LZO；

（3）reduce输出端主要看具体需求，例如作为下一个mr输入需要考虑切片，永久保存考虑压缩率比较大的gzip。

4）整体

（1）NodeManager默认内存8G，需要根据服务器实际配置灵活调整，例如128G内存，配置为100G内存左右，yarn.nodemanager.resource.memory-mb。

（2）单任务默认内存8G，需要根据该任务的数据量灵活调整，例如128m数据，配置1G内存，yarn.scheduler.maximum-allocation-mb。

（3）mapreduce.map.memory.mb ：控制分配给MapTask内存上限，如果超过会kill掉进程（报：Container is running beyond physical memory limits. Current usage:565MB of512MB physical memory used；Killing Container）。默认内存大小为1G，如果数据量是128m，正常不需要调整内存；如果数据量大于128m，可以增加MapTask内存，最大可以增加到4-5g。

（4）mapreduce.reduce.memory.mb：控制分配给ReduceTask内存上限。默认内存大小为1G，如果数据量是128m，正常不需要调整内存；如果数据量大于128m，可以增加ReduceTask内存大小为4-5g。

（5）mapreduce.map.java.opts：控制MapTask堆内存大小。（如果内存不够，报：java.lang.OutOfMemoryError）

（6）mapreduce.reduce.java.opts：控制ReduceTask堆内存大小。（如果内存不够，报：java.lang.OutOfMemoryError）

（7）可以增加MapTask的CPU核数，增加ReduceTask的CPU核数

（8）增加每个Container的CPU核数和内存大小

（9）在hdfs-site.xml文件中配置多目录

（10）NameNode有一个工作线程池，用来处理不同DataNode的并发心跳以及客户端并发的元数据操作。dfs.namenode.handler.count=20 * log2(Cluster Size)，比如集群规模为10台时，此参数设置为60。

1.2.6 Yarn工作机制

大数据技术之高频面试题_第5张图片

1.2.7 Yarn调度器

1）Hadoop调度器重要分为三类：

FIFO 、Capacity Scheduler（容量调度器）和Fair Sceduler（公平调度器）。

Apache默认的资源调度器是容量调度器；

CDH默认的资源调度器是公平调度器。

2）区别：

FIFO调度器：支持单队列 、先进先出   生产环境不会用。

容量调度器：支持多队列，保证先进入的任务优先执行。

公平调度器：支持多队列，保证每个任务公平享有队列资源。

3）在生产环境下怎么选择？

     大厂：如果对并发度要求比较高，选择公平，要求服务器性能必须OK；

     中小公司，集群服务器资源不太充裕选择容量。

4）在生产环境怎么创建队列？

（1）调度器默认就1个default队列，不能满足生产要求。

    （2）按照框架：hive /spark/ flink 每个框架的任务放入指定的队列（企业用的不是特别多）

（3）按照业务模块：登录注册、购物车、下单、业务部门1、业务部门2

5）创建多队列的好处？

（1）因为担心员工不小心，写递归死循环代码，把所有资源全部耗尽。

（2）实现任务的降级使用，特殊时期保证重要的任务队列资源充足。

业务部门1（重要）=》业务部门2（比较重要）=》下单（一般）=》购物车（一般）=》登录注册（次要）

1.2.8 项目经验之基准测试

搭建完Hadoop集群后需要对HDFS读写性能和MR计算能力测试。测试jar包在hadoop的share文件夹下。

1.2.9 Hadoop宕机

1）如果MR造成系统宕机。此时要控制Yarn同时运行的任务数，和每个任务申请的最大内存。调整参数：yarn.scheduler.maximum-allocation-mb（单个任务可申请的最多物理内存量，默认是8192MB）

2）如果写入文件过快造成NameNode宕机。那么调高Kafka的存储大小，控制从Kafka到HDFS的写入速度。例如，可以调整Flume每批次拉取数据量的大小参数batchsize。。

1.2.10 Hadoop解决数据倾斜方法

1）提前在map进行combine，减少传输的数据量

在Mapper加上combiner相当于提前进行reduce，即把一个Mapper中的相同key进行了聚合，减少shuffle过程中传输的数据量，以及Reducer端的计算量。

如果导致数据倾斜的key大量分布在不同的mapper的时候，这种方法就不是很有效了。

2）导致数据倾斜的key 大量分布在不同的mapper

（1）局部聚合加全局聚合。

第一次在map阶段对那些导致了数据倾斜的key 加上1到n的随机前缀，这样本来相同的key 也会被分到多个Reducer中进行局部聚合，数量就会大大降低。

第二次mapreduce，去掉key的随机前缀，进行全局聚合。

思想：二次mr，第一次将key随机散列到不同reducer进行处理达到负载均衡目的。第二次再根据去掉key的随机前缀，按原key进行reduce处理。

这个方法进行两次mapreduce，性能稍差。

（2）增加Reducer，提升并行度
JobConf.setNumReduceTasks(int)

（3）实现自定义分区

根据数据分布情况，自定义散列函数，将key均匀分配到不同Reducer

1.2.11 集群资源分配参数（项目中遇到的问题）

集群有30台机器，跑mr任务的时候发现5个map任务全都分配到了同一台机器上，这个可能是由于什么原因导致的吗？

解决方案：yarn.scheduler.fair.assignmultiple 这个参数 默认是开的，需要关掉

https://blog.csdn.net/leone911/article/details/51605172

 

 

1.3 Zookeeper

1.3.1 选举机制

半数机制：2n+1，安装奇数台

10台服务器：3台

20台服务器：5台

100台服务器：11台

台数多，好处：提高可靠性；坏处：影响通信延时

1.3.2 常用命令

ls、get、create

1.3.3 Paxos算法（扩展）

注意：暂时先不用看。如果后期准备面今日头条，需要认真准备，其他公司几乎都不问。

Paxos算法一种基于消息传递且具有高度容错特性的一致性算法。

分布式系统中的节点通信存在两种模型：共享内存（Shared memory）和消息传递（Messages passing）。基于消息传递通信模型的分布式系统，不可避免的会发生以下错误：进程可能会慢、被杀死或者重启，消息可能会延迟、丢失、重复，在基础Paxos场景中，先不考虑可能出现消息篡改即拜占庭错误的情况。Paxos算法解决的问题是在一个可能发生上述异常的分布式系统中如何就某个值达成一致，保证不论发生以上任何异常，都不会破坏决议的一致性。

1.3.4 讲一讲什么是CAP法则？Zookeeper符合了这个法则的哪两个？（扩展）

CAP法则：强一致性、高可用性、分区容错性；

Zookeeper符合强一致性、高可用性！

 

1.4 Flume

1.4.1 Flume组成，Put事务，Take事务

1）taildir source

（1）断点续传、多目录

    （2）哪个flume版本产生的？Apache1.7、CDH1.6

（3）没有断点续传功能时怎么做的？ 自定义

（4）taildir挂了怎么办？

     不会丢数：断点续传

     重复数据：

（5）怎么处理重复数据？

     不处理：生产环境通常不处理，因为会影响传输效率

     处理

         自身：在taildirsource里面增加自定义事务

         找兄弟：下一级处理（hive dwd sparkstreaming flink布隆）、去重手段（groupby、开窗取窗口第一条、redis）

（6）taildir source 是否支持递归遍历文件夹读取文件？

     不支持。  自定义  递归遍历文件夹 +读取文件

2）file channel /memory channel/kafka channel  

（1）file channel

          数据存储于磁盘，优势：可靠性高；劣势：传输速度低

          默认容量：100万event

注意：FileChannel可以通过配置dataDirs指向多个路径，每个路径对应不同的硬盘，增大Flume吞吐量。

（2）memory channel

          数据存储于内存，优势：传输速度快；劣势：可靠性差

          默认容量：100个event

（3）kafka channel

          数据存储于Kafka，基于磁盘；

          优势：可靠性高；

          传输速度快 kafka channel》memory channel+kafka sink  原因省去了sink阶段

（4）kafka channel哪个版本产生的？

          flume1.6 版本产生=》并没有火；因为有bug

          topic-start 数据内容

          topic-event 数据内容    ture  和false 很遗憾，都不起作用。

          增加了额外清洗的工作量。

          flume1.7解决了这个问题，开始火了。

（5）生产环境如何选择

          如果下一级是kafka，优先选择kafka channel

          如果是金融、对钱要求准确的公司，选择file channel

          如果就是普通的日志，通常可以选择memory channel

          每天丢几百万数据   pb级   亿万富翁，掉1块钱会捡？

3）HDFS sink    

     （1）时间(1小时-2小时) or 大小128m、event个数（0禁止）

具体参数：hdfs.rollInterval=3600，hdfs.rollSize=134217728，hdfs.rollCount =0

4）事务

Source到Channel是Put事务

Channel到Sink是Take事务

1.4.2 Flume拦截器

1）拦截器注意事项

项目中自定义了：ETL拦截器。

采用两个拦截器的优缺点：优点，模块化开发和可移植性；缺点，性能会低一些

2）自定义拦截器步骤

（1）实现 Interceptor

（2）重写四个方法

  • initialize 初始化
  • public Event intercept(Event event) 处理单个Event
  • public List intercept(List events) 处理多个Event，在这个方法中调用Event intercept(Event event)
  • close 方法

（3）静态内部类，实现Interceptor.Builder

3）拦截器可以不用吗？

     可以不用；需要在下一级hive的dwd层和sparksteaming里面处理

     优势：只处理一次，轻度处理；劣势：影响性能，不适合做实时推荐这种对实时要求比较高的场景。

1.4.3 Flume Channel选择器

大数据技术之高频面试题_第6张图片 

 

1.4.4 Flume监控器

1）采用Ganglia监控器，监控到flume尝试提交的次数远远大于最终成功的次数，说明flume运行比较差。

2）解决办法？

（1）自身：增加内存flume-env.sh   4-6g

-Xmx与-Xms最好设置一致，减少内存抖动带来的性能影响，如果设置不一致容易导致频繁fullgc。

（2）找朋友：增加服务器台数

搞活动 618  =》增加服务器=》用完在退出

日志服务器配置：8-16g内存、磁盘8T

1.4.5 Flume采集数据会丢失吗?（防止数据丢失的机制）

如果是FileChannel不会，Channel存储可以存储在File中，数据传输自身有事务。

如果是MemoryChannel有可能丢。

1.5 Kafka

https://www.jianshu.com/p/2b4ca1fae5d8

1.5.1 Kafka架构

生产者、Broker、消费者、ZK

注意：Zookeeper中保存Broker id和消费者offsets等信息，但是没有生产者信息。

大数据技术之高频面试题_第7张图片

大数据技术之高频面试题_第8张图片

 

 

1.5.2 Kafka的机器数量

Kafka机器数量=2*（峰值生产速度*副本数/100）+ 1

1.5.3 副本数设定

一般我们设置成2个或3个，很多企业设置为2个。

副本的优势：提高可靠性；副本劣势：增加了网络IO传输

1.5.4 Kafka压测

Kafka官方自带压力测试脚本（kafka-consumer-perf-test.sh、kafka-producer-perf-test.sh）。Kafka压测时，可以查看到哪个地方出现了瓶颈（CPU，内存，网络IO）。一般都是网络IO达到瓶颈。

1.5.5 Kafka日志保存时间

默认保存7天；生产环境建议3天

1.5.6 Kafka中数据量计算

每天总数据量100g，每天产生1亿条日志， 10000万/24/60/60=1150条/每秒钟

平均每秒钟：1150条

低谷每秒钟：50条

高峰每秒钟：1150条*（2-20倍）=2300条-23000条

每条日志大小：0.5k-2k（取1k）

每秒多少数据量：2.0M-20MB

1.5.7 Kafka的硬盘大小

每天的数据量100g*2个副本*3天/70%

1.5.8 Kafka监控

公司自己开发的监控器；

开源的监控器：KafkaManager、KafkaMonitor、KafkaEagle

1.5.9 Kakfa分区数

1）创建一个只有1个分区的topic

2）测试这个topic的producer吞吐量和consumer吞吐量。 

3）假设他们的值分别是Tp和Tc，单位可以是MB/s。

4）然后假设总的目标吞吐量是Tt，那么分区数=Tt / min（Tp，Tc）

例如：producer吞吐量=20m/s；consumer吞吐量=50m/s，期望吞吐量100m/s；

分区数=100 / 20 =5分区

https://blog.csdn.net/weixin_42641909/article/details/89294698

分区数一般设置为：3-10个

1.5.10 多少个Topic

通常情况：多少个日志类型就多少个Topic。也有对日志类型进行合并的。

1.5.11 Kafka的ISR副本同步队列

ISR（In-Sync Replicas），副本同步队列。ISR中包括Leader和Follower。如果Leader进程挂掉，会在ISR队列中选择一个服务作为新的Leader。有replica.lag.max.messages（延迟条数）和replica.lag.time.max.ms（延迟时间）两个参数决定一台服务是否可以加入ISR副本队列，在0.10版本移除了replica.lag.max.messages参数，防止服务频繁的进去队列。

任意一个维度超过阈值都会把Follower剔除出ISR，存入OSR（Outof-Sync Replicas）列表，新加入的Follower也会先存放在OSR中。

1.5.12 Kafka分区分配策略

在 Kafka内部存在两种默认的分区分配策略：Range和 RoundRobin。

Range是默认策略。Range是对每个Topic而言的（即一个Topic一个Topic分），首先对同一个Topic里面的分区按照序号进行排序，并对消费者按照字母顺序进行排序。然后用Partitions分区的个数除以消费者线程的总数来决定每个消费者线程消费几个分区。如果除不尽，那么前面几个消费者线程将会多消费一个分区。

例如：我们有10个分区，两个消费者（C1，C2），3个消费者线程，10 / 3 = 3而且除不尽。

C1-0 将消费 0, 1, 2, 3 分区

C2-0 将消费 4, 5, 6 分区

C2-1 将消费 7, 8, 9 分区

第一步：将所有主题分区组成TopicAndPartition列表，然后对TopicAndPartition列表按照hashCode进行排序，最后按照轮询的方式发给每一个消费线程。

1.5.13 Kafka挂掉

1）Flume记录

2）日志有记录

3）短期没事

1.5.14 Kafka丢不丢数据

Ack=0，相当于异步发送，消息发送完毕即offset增加，继续生产。

Ack=1，leader收到leader replica 对一个消息的接受ack才增加offset，然后继续生产。

Ack=-1，leader收到所有replica 对一个消息的接受ack才增加offset，然后继续生产。

1.5.15 Kafka数据重复

幂等性+ack-1+事务

Kafka数据重复，可以再下一级：SparkStreaming、redis或者hive中dwd层去重，去重的手段：分组、按照id开窗只取第一个值；

1.5.16 Kafka消息数据积压，Kafka消费能力不足怎么处理？ 

1）如果是Kafka消费能力不足，则可以考虑增加Topic的分区数，并且同时提升消费组的消费者数量，消费者数=分区数。（两者缺一不可）

2）如果是下游的数据处理不及时：提高每批次拉取的数量。批次拉取数据过少（拉取数据/处理时间<生产速度），使处理的数据小于生产的数据，也会造成数据积压。

1.5.17 Kafka参数优化

1）Broker参数配置（server.properties）

1、日志保留策略配置

# 保留三天，也可以更短 （log.cleaner.delete.retention.ms）

log.retention.hours=72

 

2、Replica相关配置

default.replication.factor:1 默认副本1个

 

3、网络通信延时

replica.socket.timeout.ms:30000 #当集群之间网络不稳定时,调大该参数

replica.lag.time.max.ms= 600000# 如果网络不好,或者kafka集群压力较大,会出现副本丢失,然后会频繁复制副本,导致集群压力更大,此时可以调大该参数

2）Producer优化（producer.properties）

compression.type:none

#默认发送不进行压缩，推荐配置一种适合的压缩算法，可以大幅度的减缓网络压力和Broker的存储压力。

GZIP、Snappy和LZ4。从2.1.0开始，kafka正式支持Zstandard算法(简写zstd)。它是Facebook开源的一个压缩算法，能够提供超高的压缩比。对于kafka测试而言，在吞吐方面：LZ4>Snappy> zstd、GZIP；在压缩比方面：zstd>lz4>gzip>snappy。具体到物理资源，使用snappy算法占用的网络带宽资源最多，zstd最少，这是合理的，毕竟zstd就是要提供超高的压缩比；在CPU使用率方面，各个算法表现得差不多，只是在压缩时snappy使用的CPU较多一些，而在解压缩时gzip算法则可能使用更多的CPU。

3）Kafka内存调整（kafka-server-start.sh）

默认内存1个G，生产环境尽量不要超过6个G。

export KAFKA_HEAP_OPTS="-Xms4g -Xmx4g"

1.5.18 Kafka高效读写数据

1）Kafka本身是分布式集群，同时采用分区技术，并发度高。

2）顺序写磁盘

Kafka的producer生产数据，要写入到log文件中，写的过程是一直追加到文件末端，为顺序写。官网有数据表明，同样的磁盘，顺序写能到600M/s，而随机写只有100K/s。

3）零复制技术

大数据技术之高频面试题_第9张图片

大数据技术之高频面试题_第10张图片

 

1.5.19 Kafka单条日志传输大小

kafka对于消息体的大小默认为单条最大值是1M但是在我们应用场景中, 常常会出现一条消息大于1M，如果不对kafka进行配置。则会出现生产者无法将消息推送到kafka或消费者无法去消费kafka里面的数据, 这时我们就要对kafka进行以下配置：server.properties

replica.fetch.max.bytes: 1048576  broker可复制的消息的最大字节数, 默认为1M

message.max.bytes: 1000012   kafka 会接收单个消息size的最大限制， 默认为1M左右

注意：message.max.bytes必须小于等于replica.fetch.max.bytes，否则就会导致replica之间数据同步失败。

1.5.20 Kafka过期数据清理

保证数据没有被引用（没人消费他）

日志清理保存的策略只有delete和compact两种

log.cleanup.policy=delete启用删除策略

log.cleanup.policy=compact启用压缩策略

https://www.jianshu.com/p/fa6adeae8eb5

1.5.21 Kafka可以按照时间消费数据

Map startOffsetMap = KafkaUtil.fetchOffsetsWithTimestamp(topic, sTime, kafkaProp);

1.5.22 Kafka消费者角度考虑是拉取数据还是推送数据

拉取数据

1.5.23 Kafka中的数据是有序的吗

单分区内有序；多分区，分区与分区间无序；

 

1.6 Hive

补充

1.6.1 Hive的架构

大数据技术之高频面试题_第11张图片

 

1．用户接口：Client

CLI（command-line interface）、JDBC/ODBC(jdbc访问hive)、WEBUI（浏览器访问hive）

2．元数据：Metastore

元数据包括：表名、表所属的数据库（默认是default）、表的拥有者、列/分区字段、表的类型（是否是外部表）、表的数据所在目录等；

默认存储在自带的derby数据库中，推荐使用MySQL存储Metastore

3．Hadoop

使用HDFS进行存储，使用MapReduce进行计算。

4．驱动器：Driver

（1）解析器（SQL Parser）：将SQL字符串转换成抽象语法树AST，这一步一般都用第三方工具库完成，比如antlr；对AST进行语法分析，比如表是否存在、字段是否存在、SQL语义是否有误。

（2）编译器（Physical Plan）：将AST编译生成逻辑执行计划。

（3）优化器（Query Optimizer）：对逻辑执行计划进行优化。

（4）执行器（Execution）：把逻辑执行计划转换成可以运行的物理计划。对于Hive来说，就是MR。

大数据技术之高频面试题_第12张图片

 

Hive通过给用户提供的一系列交互接口，接收到用户的指令(SQL)，使用自己的Driver，结合元数据(MetaStore)，将这些指令翻译成MapReduce，提交到Hadoop中执行，最后，将执行返回的结果输出到用户交互接口。

 

1.6.2 Hive和数据库比较

Hive 和数据库除了拥有类似的查询语言，再无类似之处。

1）数据存储位置

Hive 存储在 HDFS 。数据库将数据保存在块设备或者本地文件系统中。

2）数据更新

Hive中不建议对数据的改写。而数据库中的数据通常是需要经常进行修改的，

3）执行延迟

Hive 执行延迟较高。数据库的执行延迟较低。当然，这个是有条件的，即数据规模较小，当数据规模大到超过数据库的处理能力的时候，Hive的并行计算显然能体现出优势。

4）数据规模

Hive支持很大规模的数据计算；数据库可以支持的数据规模较小。

1.6.3 内部表和外部表

元数据、原始数据

1）删除数据时：

内部表：元数据、原始数据，全删除

外部表：元数据 只删除

2）在公司生产环境下，什么时候创建内部表，什么时候创建外部表？

在公司中绝大多数场景都是外部表。

自己使用的临时表，才会创建内部表；

1.6.4 4个By区别

1）Order By：全局排序，只有一个Reducer；

2）Sort By：分区内有序；

3）Distrbute By：类似MR中Partition，进行分区，结合sort by使用。

4） Cluster By：当Distribute by和Sorts by字段相同时，可以使用Cluster by方式。Cluster by除了具有Distribute by的功能外还兼具Sort by的功能。但是排序只能是升序排序，不能指定排序规则为ASC或者DESC。

在生产环境中Order By用的比较少，容易导致OOM。

在生产环境中Sort By+ Distrbute By用的多。

1.6.5 系统函数（记20个）

1）date_add、date_sub函数（加减日期）

2）next_day函数（周指标相关）

3）date_format函数（根据格式整理日期）

4）last_day函数（求当月最后一天日期）

5）collect_set函数

6）get_json_object解析json函数

7）NVL（表达式1，表达式2）

如果表达式1为空值，NVL返回值为表达式2的值，否则返回表达式1的值。

1.6.6 自定义UDF、UDTF函数

1）在项目中是否自定义过UDF、UDTF函数，以及用他们处理了什么问题，及自定义步骤？

（1）用UDF函数解析公共字段；用UDTF函数解析事件字段。

（2）自定义UDF：继承UDF，重写evaluate方法

（3）自定义UDTF：继承自GenericUDTF，重写3个方法：initialize(自定义输出的列名和类型)，process（将结果返回forward(result)），close

2）为什么要自定义UDF/UDTF？

因为自定义函数，可以自己埋点Log打印日志，出错或者数据异常，方便调试。

1.6.7 窗口函数

1）Rank

（1）RANK() 排序相同时会重复，总数不会变

（2）DENSE_RANK() 排序相同时会重复，总数会减少

（3）ROW_NUMBER() 会根据顺序计算

2） OVER()：指定分析函数工作的数据窗口大小，这个数据窗口大小可能会随着行的变而变化

（1）CURRENT ROW：当前行

（2）n PRECEDING：往前n行数据

（3） n FOLLOWING：往后n行数据

（4）UNBOUNDED：起点，UNBOUNDED PRECEDING 表示从前面的起点， UNBOUNDED FOLLOWING表示到后面的终点

（5） LAG(col,n)：往前第n行数据

（6）LEAD(col,n)：往后第n行数据

（7） NTILE(n)：把有序分区中的行分发到指定数据的组中，各个组有编号，编号从1开始，对于每一行，NTILE返回此行所属的组的编号。注意：n必须为int类型。

3）手写TopN

https://www.cnblogs.com/liuwchao/articles/11535282.html

 

1.6.8 Hive优化

https://www.cnblogs.com/swordfall/p/11037539.html

1）MapJoin

如果不指定MapJoin或者不符合MapJoin的条件，那么Hive解析器会将Join操作转换成Common Join，即：在Reduce阶段完成join。容易发生数据倾斜。可以用MapJoin把小表全部加载到内存在map端进行join，避免reducer处理。默认是打开的，不要关闭。

2）行列过滤

列处理：在SELECT中，只拿需要的列，如果有，尽量使用分区过滤，少用SELECT *。

行处理：在分区剪裁中，当使用外关联时，如果将副表的过滤条件写在Where后面，那么就会先全表关联，之后再过滤。 

3）列式存储

4）采用分区技术  

5）合理设置Map数

mapred.min.split.size: 指的是数据的最小分割单元大小；min的默认值是1B

mapred.max.split.size: 指的是数据的最大分割单元大小；max的默认值是256MB

通过调整max可以起到调整map数的作用，减小max可以增加map数，增大max可以减少map数。 max(0,min(块大小，Long的最大值))  

需要提醒的是，直接调整mapred.map.tasks这个参数是没有效果的。

如果设置：

org.apache.hadoop.hive.ql.io.HiveInputFormat  上述参数是有效果的

6）合理设置Reduce数

Reduce个数并不是越多越好

（1）过多的启动和初始化Reduce也会消耗时间和资源；

（2）另外，有多少个Reduce，就会有多少个输出文件，如果生成了很多个小文件，那么如果这些小文件作为下一个任务的输入，则也会出现小文件过多的问题；

在设置Reduce个数的时候也需要考虑这两个原则：处理大数据量利用合适的Reduce数；使单个Reduce任务处理数据量大小要合适；

7）小文件如何产生的？

（1）动态分区插入数据，产生大量的小文件，从而导致map数量剧增；

（2）reduce数量越多，小文件也越多（reduce的个数和输出文件是对应的）；

（3）数据源本身就包含大量的小文件。

8）小文件解决方案

https://blog.csdn.net/shudaqi2010/article/details/90342417

（1）在Map执行前合并小文件，减少Map数：CombineHiveInputFormat具有对小文件进行合并的功能（系统默认的格式）。HiveInputFormat没有对小文件合并功能。

set hive.input.format=org.apache.hadoop.hive.al.io.CombineHiveInputFormat

（2）merge

// 输出合并小文件

SET hive.merge.mapfiles = true; -- 默认true，在map-only任务结束时合并小文件

SET hive.merge.mapredfiles = true; -- 默认false，在map-reduce任务结束时合并小文件

SET hive.merge.size.per.task = 268435456; -- 默认256M

SET hive.merge.smallfiles.avgsize = 16777216; -- 当输出文件的平均大小小于16m该值时，启动一个独立的map-reduce任务进行文件merge

  1. 开启JVM重用

JVM重用是Hadoop调优参数的内容，其对Hive的性能具有非常大的影响，特别是对于很难避免小文件的场景或task特别多的场景，这类场景大多数执行时间都很短。

Hadoop的默认配置通常是使用派生JVM来执行map和Reduce任务的。这时JVM的启动过程可能会造成相当大的开销，尤其是执行的job包含有成百上千task任务的情况。JVM重用可以使得JVM实例在同一个job中重新使用N次。N的值可以在Hadoop的mapred-site.xml文件中进行配置。通常在10-20之间，具体多少需要根据具体业务场景测试得出。默认值是1

 

  mapreduce.job.jvm.numtasks

 

  10

  How many tasks to run per jvm. If set to -1, there is no limit.

 

 

这个功能的缺点是，开启JVM重用将一直占用使用到的task插槽，以便进行重用，直到任务完成后才能释放。如果某个“不平衡的”job中有某几个reduce task执行的时间要比其他Reduce task消耗的时间多的多的话，那么保留的插槽就会一直空闲着却无法被其他的job使用，直到所有的task都结束了才会释放。

set mapreduce.job.jvm.numtasks=10

9）开启map端combiner（不影响最终业务逻辑）

set hive.map.aggr=true；

  1. 压缩（选择快的）

关于压缩：

https://blog.csdn.net/qq262593421/article/details/101685223

设置map端输出、中间结果压缩。（不完全是解决数据倾斜的问题，但是减少了IO读写和网络传输，能提高很多效率）

set hive.exec.compress.intermediate=true --启用中间数据压缩

set mapreduce.map.output.compress=true --启用最终数据压缩

set mapreduce.map.outout.compress.codec=…; --设置压缩方式  snappy

  1. 采用tez引擎或者spark引擎

tez 和 spark都是基于内存，速度比mr都要快，mr更稳定。

  1. 数据量特别大，不在乎时间，mr更合理，清洗很多mr
  2. 数据量不大，需要很快出结果，简单计算，用tez，临时的需求
  3. 数据比较大，对时效有一定要求，报表，spark

1.6.9 Hive解决数据倾斜方法

https://blog.csdn.net/ccorg/article/details/60147863

1）数据倾斜长啥样？

大数据技术之高频面试题_第13张图片

 

2）怎么产生的数据倾斜？

（1）不同数据类型关联产生数据倾斜  

情形：比如用户表中user_id字段为int，log表中user_id字段既有string类型也有int类型。当按照user_id进行两个表的Join操作时。

后果：处理此特殊值的reduce耗时；只有一个reduce任务。默认的Hash操作会按int型的id来进行分配，这样会导致所有string类型id的记录都分配到一个Reducer中。

解决方式：把数字类型转换成字符串类型

select * from users a

left outer join logs b

on a.usr_id = cast(b.user_id as string)

（2）控制空值分布

在生产环境经常会用大量空值数据进入到一个reduce中去，导致数据倾斜。

解决办法：

自定义分区，将为空的key转变为字符串加随机数或纯随机数，将因空值而造成倾斜的数据分不到多个Reducer。

注意：对于异常值如果不需要的话，最好是提前在where条件里过滤掉，这样可以使计算量大大减少

 最常见的数据倾斜是场景是key分布不均，个别的key特别多，其他key比较少

3）解决数据倾斜的方法？

（1）group by

如果需要做过滤distinct，假设可以用group by能够实现一样的效果，用group by

注：group by 优于distinct group

解决方式：采用sum() group by的方式来替换count(distinct )完成计算。

（2）mapjoin，没有shuffle，没有倾斜。

（3）开启数据倾斜时负载均衡

set hive.groupby.skewindata=true;

思想：就是先随机分发并处理，再按照key group by来分发处理。

操作：当选项设定为true，生成的查询计划会有两个MRJob。

第一个MRJob中，Map的输出结果集合会随机分布到Reduce中，每个Reduce做部分聚合操作，并输出结果，这样处理的结果是相同的GroupBy Key有可能被分发到不同的Reduce中，从而达到负载均衡的目的；

第二个MRJob再根据预处理的数据结果按照GroupBy Key分布到Reduce中（这个过程可以保证相同的原始GroupBy Key被分布到同一个Reduce中），最后完成最终的聚合操作。

点评：它使计算变成了两个mapreduce，先在第一个中在shuffle过程partition时随机给 key打标记，使每个key随机均匀分布到各个reduce上计算，但是这样只能完成部分计算，因为相同key没有分配到相同reduce上。

所以需要第二次的mapreduce，这次就回归正常shuffle，但是数据分布不均匀的问题在第一次mapreduce已经有了很大的改善，因此基本解决数据倾斜。因为大量计算已经在第一次mr中随机分布到各个节点完成。

1.6.10 Hive里边字段的分隔符用的什么？为什么用\t？有遇到过字段里边有\t的情况吗，怎么处理的？ 

hive 默认的字段分隔符为ascii码的控制符\001（^A）,建表的时候用fields terminated by '\001'。注意：如果采用\t或者\001等为分隔符，需要要求前端埋点和javaEE后台传递过来的数据必须不能出现该分隔符，通过代码规范约束。一旦传输过来的数据含有分隔符，需要在前一级数据中转义或者替换（ETL）。

1.6.11 Tez引擎优点？

Tez可以将多个有依赖的作业转换为一个作业，这样只需写一次HDFS，且中间节点较少，从而大大提升作业的计算性能。

Mr/tez/spark区别：

Mr引擎：多job串联，基于磁盘，落盘的地方比较多。虽然慢，但一定能跑出结果。一般处理，周、月、年指标。

Spark引擎：虽然在Shuffle过程中也落盘，但是并不是所有算子都需要Shuffle，尤其是多算子过程，中间过程不落盘  DAG有向无环图。 兼顾了可靠性和效率。一般处理天指标。

Tez引擎：完全基于内存。  注意：如果数据量特别大，慎重使用。容易OOM。一般用于快速出结果，数据量比较小的场景。

1.6.12 MySQL元数据备份

1）MySQL之元数据备份（项目中遇到的问题）

元数据备份（重点，如数据损坏，可能整个集群无法运行，至少要保证每日零点之后备份到其它服务器两个复本）

 Keepalived或者用mycat

2）MySQL utf8超过字节数问题

MySQL的utf8编码最多存储3个字节，当数据中存在表情号、特色符号时会占用超过3个字节数的字节，那么会出现错误 Incorrect string value: '\xF0\x9F\x91\x91\xE5\xB0...'

解决办法：将utf8修改为utf8mb4

首先修改库的基字符集和数据库排序规则

大数据技术之高频面试题_第14张图片

 

再使用 SHOW VARIABLES LIKE '%char%'; 命令查看参数

大数据技术之高频面试题_第15张图片

 

确保这几个参数的value值为utf8mb4 如果不是使用set命令修改

如：set character_set_server = utf8mb4;

1.6.13 Union与Union all区别

1）union会将联合的结果集去重，效率较union all差

2）union all不会对结果集去重，所以效率高

1.6.14 hive的sql是如何转化为mapreduce？

了解了MapReduce实现SQL基本操作之后，我们来看看Hive是如何将SQL转化为MapReduce任务的，整个编译过程分为六个阶段：

  1. Antlr定义SQL的语法规则，完成SQL词法，语法解析，将SQL转化为抽象语法树AST Tree （做语法解析，语法检查，转化为ast tree）
  1. 遍历AST Tree，抽象出查询的基本组成单元QueryBlock
  2. 遍历QueryBlock，翻译为执行操作树OperatorTree  
  3. 逻辑层优化器进行OperatorTree变换，合并不必要的ReduceSinkOperator，减少shuffle数据量，把逻辑计划进行优化，得到优化后的逻辑计划
  4. 遍历OperatorTree，翻译为MapReduce任务，得到物理计划

物理层优化器进行MapReduce任务的变换，生成最终的执行计划

 

 

1.7 Sqoop

1.7.1 Sqoop参数

/opt/module/sqoop/bin/sqoop import \

--connect \

--username \

--password \

--target-dir \

--delete-target-dir \

--num-mappers \

--fields-terminated-by   \

--query   "$2" ' and $CONDITIONS;'

1.7.2 Sqoop导入导出Null存储一致性问题

Hive中的Null在底层是以“\N”来存储，而MySQL中的Null在底层就是Null，为了保证数据两端的一致性。在导出数据时采用--input-null-string和--input-null-non-string两个参数。导入数据时采用--null-string和--null-non-string。

1.7.3 Sqoop数据导出一致性问题

场景1：如Sqoop在导出到Mysql时，使用4个Map任务，过程中有2个任务失败，那此时MySQL中存储了另外两个Map任务导入的数据，此时老板正好看到了这个报表数据。而开发工程师发现任务失败后，会调试问题并最终将全部数据正确的导入MySQL，那后面老板再次看报表数据，发现本次看到的数据与之前的不一致，这在生产环境是不允许的。

官网：http://sqoop.apache.org/docs/1.4.6/SqoopUserGuide.html

Since Sqoop breaks down export process into multiple transactions, it is possible that a failed export job may result in partial data being committed to the database. This can further lead to subsequent jobs failing due to insert collisions in some cases, or lead to duplicated data in others. You can overcome this problem by specifying a staging table via the --staging-table option which acts as an auxiliary table that is used to stage exported data. The staged data is finally moved to the destination table in a single transaction.

–staging-table方式

sqoop export --connect jdbc:mysql://192.168.137.10:3306/user_behavior --username root --password 123456 --table app_cource_study_report --columns watch_video_cnt,complete_video_cnt,dt --fields-terminated-by "\t" --export-dir "/user/hive/warehouse/tmp.db/app_cource_study_analysis_${day}" --staging-table app_cource_study_report_tmp --clear-staging-table --input-null-string '\N'

1.7.4 Sqoop底层运行的任务是什么

只有Map阶段，没有Reduce阶段的任务。默认是4个MapTask。

1.7.5 Sqoop一天导入多少数据

100万日活=》10万订单，1人10条，每天1g左右业务数据

Sqoop每天将1G的数据量导入到数仓。

1.7.6 Sqoop数据导出的时候一次执行多长时间

每天晚上00:30开始执行，Sqoop任务一般情况40 -50分钟的都有。取决于数据量（11:11，6:18等活动在1个小时左右）。

1.7.7 Sqoop在导入数据的时候数据倾斜

https://blog.csdn.net/lizhiguo18/article/details/103969906

Sqoop 抽数的并行化主要涉及到两个参数：num-mappers：启动N个map来并行导入数据，默认4个；split-by：按照某一列来切分表的工作单元。

通过ROWNUM() 生成一个严格均匀分布的字段，然后指定为分割字段

1.7.8 Sqoop数据导出Parquet（项目中遇到的问题）

Ads层数据用Sqoop往MySql中导入数据的时候，如果用了orc（Parquet）不能导入，需转化成text格式

（1）创建临时表，把Parquet中表数据导入到临时表，把临时表导出到目标表用于可视化

（2）Sqoop里面有参数，可以直接把Parquet转换为text

（3）ads层建表的时候就不要建Parquet表

1.8 Azkaban 

1.8.1 每天集群运行多少指标?

每天跑100多个指标，有活动时跑200个左右。

1.8.2 任务挂了怎么办？

运行成功或者失败都会发邮件、发钉钉、集成自动打电话（项目中遇到的问题）

最主要的解决方案就是重新跑。

 

 

1.9 HBase

1.9.1 HBase存储结构

大数据技术之高频面试题_第16张图片

 

1.9.2 RowKey设计原则

1）rowkey长度原则

2）rowkey散列原则

3）rowkey唯一原则

1.9.3 RowKey如何设计

1）生成随机数、hash、散列值

2）字符串反转

1.10 Scala

1.10.1 开发环境

要求掌握必要的scala开发环境搭建技能。

1.10.2 变量和数据类型

掌握var和val的区别

掌握数值类型（Byte、Short、Int、Long、Float、Double、Char）之间的转换关系

1.10.3 流程控制

掌握if-else、for、while等必要的流程控制结构，掌握如何实现break、continue的功能。

1.10.4 函数式编程

掌握高阶函数、匿名函数、函数柯里化、函数参数以及函数至简原则。

1.10.5 面向对象

掌握Scala与Java继承方面的区别、单例对象（伴生对象）、特质的用法及功能。

1.10.6 集合

掌握常用集合的使用、集合常用的计算函数。

1.10.7 模式匹配

掌握模式匹配的用法

1.10.8 异常

掌握异常常用操作即可

1.10.9 隐式转换

掌握隐式方法、隐式参数、隐式类，以及隐式解析机制

1.10.10 泛型

掌握泛型语法

 

1.11 Spark Core & SQL

1.11.1 Spark有几种部署方式？请分别简要论述

1）Local:运行在一台机器上，通常是练手或者测试环境。

2）Standalone:构建一个基于Mster+Slaves的资源调度集群，Spark任务提交给Master运行。是Spark自身的一个调度系统。

3）Yarn: Spark客户端直接连接Yarn，不需要额外构建Spark集群。有yarn-client和yarn-cluster两种模式，主要区别在于：Driver程序的运行节点。

4）Mesos：国内大环境比较少用。

1.11.2 Spark任务使用什么进行提交，JavaEE界面还是脚本

Shell 脚本。

1.11.3 Spark提交作业参数（重点）

参考答案：

https://blog.csdn.net/gamer_gyt/article/details/79135118

1）在提交任务时的几个重要参数

executor-cores —— 每个executor使用的内核数，默认为1，官方建议2-5个，我们企业是4个

num-executors —— 启动executors的数量，默认为2

executor-memory —— executor内存大小，默认1G

driver-cores —— driver使用内核数，默认为1

driver-memory —— driver内存大小，默认512M

2）边给一个提交任务的样式

spark-submit \

  --master local[5]  \

  --driver-cores 2   \

  --driver-memory 8g \

  --executor-cores 4 \

  --num-executors 10 \

  --executor-memory 8g \

  --class PackageName.ClassName XXXX.jar \

  --name "Spark Job Name" \

  InputPath      \

  OutputPath

1.11.4 简述Spark的架构与作业提交流程（画图讲解，注明各个部分的作用）（重点）

 

大数据技术之高频面试题_第17张图片

 

大数据技术之高频面试题_第18张图片

 

 

1.11.5 如何理解Spark中的血统概念（RDD）（笔试重点）

RDD在Lineage依赖方面分为两种Narrow Dependencies与Wide Dependencies用来解决数据容错时的高效性以及划分任务时候起到重要作用。

1.11.6 简述Spark的宽窄依赖，以及Spark如何划分stage，每个stage又根据什么决定task个数? （笔试重点）

Stage：根据RDD之间的依赖关系的不同将Job划分成不同的Stage，遇到一个宽依赖则划分一个Stage。

Task：Stage是一个TaskSet，将Stage根据分区数划分成一个个的Task。

1.11.7 请列举Spark的transformation算子（不少于8个），并简述功能（重点）

1）map（func）：返回一个新的RDD，该RDD由每一个输入元素经过func函数转换后组成.

2）mapPartitions(func)：类似于map，但独立地在RDD的每一个分片上运行，因此在类型为T的RD上运行时，func的函数类型必须是Iterator[T] => Iterator[U]。假设有N个元素，有M个分区，那么map的函数的将被调用N次,而mapPartitions被调用M次,一个函数一次处理所有分区。

3）reduceByKey（func，[numTask]）：在一个(K,V)的RDD上调用，返回一个(K,V)的RDD，使用定的reduce函数，将相同key的值聚合到一起，reduce任务的个数可以通过第二个可选的参数来设置。

4）aggregateByKey (zeroValue:U,[partitioner: Partitioner]) (seqOp: (U, V) => U,combOp: (U, U) => U: 在kv对的RDD中，，按key将value进行分组合并，合并时，将每个value和初始值作为seq函数的参数，进行计算，返回的结果作为一个新的kv对，然后再将结果按照key进行合并，最后将每个分组的value传递给combine函数进行计算（先将前两个value进行计算，将返回结果和下一个value传给combine函数，以此类推），将key与计算结果作为一个新的kv对输出。

 5）combineByKey(createCombiner: V=>C, mergeValue: (C, V) =>C, mergeCombiners: (C, C) =>C):

对相同K，把V合并成一个集合。

1.createCombiner: combineByKey() 会遍历分区中的所有元素，因此每个元素的键要么还没有遇到过，要么就和之前的某个元素的键相同。如果这是一个新的元素,combineByKey()会使用一个叫作createCombiner()的函数来创建那个键对应的累加器的初始值

2.mergeValue: 如果这是一个在处理当前分区之前已经遇到的键，它会使用mergeValue()方法将该键的累加器对应的当前值与这个新的值进行合并

3.mergeCombiners: 由于每个分区都是独立处理的， 因此对于同一个键可以有多个累加器。如果有两个或者更多的分区都有对应同一个键的累加器， 就需要使用用户提供的 mergeCombiners() 方法将各个分区的结果进行合并。

…

根据自身情况选择比较熟悉的算子加以介绍。

1.11.8 请列举Spark的action算子（不少于6个），并简述功能（重点）

1）reduce：

2）collect:

3）first：

4）take：

5）aggregate：

6）countByKey：

7）foreach：

8）saveAsTextFile：

1.11.9 请列举会引起Shuffle过程的Spark算子，并简述功能。

reduceBykey：

groupByKey：

…ByKey:

1.11.10 简述Spark的两种核心Shuffle（HashShuffle与SortShuffle）的工作流程（包括未优化的HashShuffle、优化的HashShuffle、普通的SortShuffle与bypass的SortShuffle）（重点）

未经优化的HashShuffle：

大数据技术之高频面试题_第19张图片

 

优化后的Shuffle：

大数据技术之高频面试题_第20张图片

 

普通的SortShuffle：

大数据技术之高频面试题_第21张图片

当 shuffle read task 的 数 量 小 于 等 于 spark.shuffle.sort。

bypassMergeThreshold 参数的值时（默认为 200），就会启用 bypass 机制。

大数据技术之高频面试题_第22张图片

 

1.11.11 Spark常用算子reduceByKey与groupByKey的区别，哪一种更具优势？（重点）

reduceByKey：按照key进行聚合，在shuffle之前有combine（预聚合）操作，返回结果是RDD[k,v]。

groupByKey：按照key进行分组，直接进行shuffle。

开发指导：reduceByKey比groupByKey，建议使用。但是需要注意是否会影响业务逻辑。

1.11.12 Repartition和Coalesce关系与区别

1）关系：

两者都是用来改变RDD的partition数量的，repartition底层调用的就是coalesce方法：coalesce(numPartitions, shuffle = true)

2）区别：

repartition一定会发生shuffle，coalesce根据传入的参数来判断是否发生shuffle

一般情况下增大rdd的partition数量使用repartition，减少partition数量时使用coalesce

1.11.13 分别简述Spark中的缓存机制（cache和persist）与checkpoint机制，并指出两者的区别与联系

都是做RDD持久化的

cache:内存，不会截断血缘关系，使用计算过程中的数据缓存。

checkpoint：磁盘，截断血缘关系，在ck之前必须没有任何任务提交才会生效，ck过程会额外提交一次任务。

1.11.14 简述Spark中共享变量（广播变量和累加器）的基本原理与用途。（重点）

累加器（accumulator）是Spark中提供的一种分布式的变量机制，其原理类似于mapreduce，即分布式的改变，然后聚合这些改变。累加器的一个常见用途是在调试时对作业执行过程中的事件进行计数。而广播变量用来高效分发较大的对象。

共享变量出现的原因：

通常在向 Spark 传递函数时，比如使用 map() 函数或者用 filter() 传条件时，可以使用驱动器程序中定义的变量，但是集群中运行的每个任务都会得到这些变量的一份新的副本，更新这些副本的值也不会影响驱动器中的对应变量。

Spark的两个共享变量，累加器与广播变量，分别为结果聚合与广播这两种常见的通信模式突破了这一限制。

1.11.15 当Spark涉及到数据库的操作时，如何减少Spark运行中的数据库连接数？

使用foreachPartition代替foreach，在foreachPartition内获取数据库的连接。

1.11.16 如何使用Spark实现TopN的获取（描述思路或使用伪代码）（重点）

方法1：

（1）按照key对数据进行聚合（groupByKey）

（2）将value转换为数组，利用scala的sortBy或者sortWith进行排序（mapValues）数据量太大，会OOM。

方法2：

（1）取出所有的key

（2）对key进行迭代，每次取出一个key利用spark的排序算子进行排序

方法3：

（1）自定义分区器，按照key进行分区，使不同的key进到不同的分区

（2）对每个分区运用spark的排序算子进行排序

1.11.17 京东：调优之前与调优之后性能的详细对比（例如调整map个数，map个数之前多少、之后多少，有什么提升）

这里举个例子。比如我们有几百个文件，会有几百个map出现，读取之后进行join操作，会非常的慢。这个时候我们可以进行coalesce操作，比如240个map，我们合成60个map，也就是窄依赖。这样再shuffle，过程产生的文件数会大大减少。提高join的时间性能。

1.11.18 简述SparkSQL中RDD、DataFrame、DataSet三者的区别与联系? （笔试重点）

1）RDD

优点:

编译时类型安全 

编译时就能检查出类型错误

面向对象的编程风格 

直接通过类名点的方式来操作数据

缺点:

序列化和反序列化的性能开销 

无论是集群间的通信, 还是IO操作都需要对对象的结构和数据进行序列化和反序列化。

GC的性能开销，频繁的创建和销毁对象, 势必会增加GC

2）DataFrame

DataFrame引入了schema和off-heap

schema : RDD每一行的数据, 结构都是一样的，这个结构就存储在schema中。 Spark通过schema就能够读懂数据, 因此在通信和IO时就只需要序列化和反序列化数据, 而结构的部分就可以省略了。

3）DataSet

DataSet结合了RDD和DataFrame的优点，并带来的一个新的概念Encoder。

当序列化数据时，Encoder产生字节码与off-heap进行交互，能够达到按需访问数据的效果，而不用反序列化整个对象。Spark还没有提供自定义Encoder的API，但是未来会加入。

三者之间的转换：

大数据技术之高频面试题_第23张图片

 

1.11.19 append和overwrite的区别

 append在原有分区上进行追加，overwrite在原有分区上进行全量刷新

1.11.20 coalesce和repartition的区别

 coalesce和repartition都用于改变分区，coalesce用于缩小分区且不会进行shuffle，repartition用于增大分区（提供并行度）会进行shuffle,在spark中减少文件个数会使用coalesce来减少分区来到这个目的。但是如果数据量过大，分区数过少会出现OOM所以coalesce缩小分区个数也需合理

1.11.21 cache缓存级别

DataFrame的cache默认采用 MEMORY_AND_DISK 这和RDD 的默认方式不一样RDD cache 默认采用MEMORY_ONLY

1.11.22 释放缓存和缓存

 缓存：(1)dataFrame.cache  (2)sparkSession.catalog.cacheTable(“tableName”)

 释放缓存：(1)dataFrame.unpersist  (2)sparkSession.catalog.uncacheTable(“tableName”)

1.11.23 Spark Shuffle默认并行度

参数spark.sql.shuffle.partitions 决定 默认并行度200

1.11.24 kryo序列化

kryo序列化比java序列化更快更紧凑，但spark默认的序列化是java序列化并不是spark序列化，因为spark并不支持所有序列化类型，而且每次使用都必须进行注册。注册只针对于RDD。在DataFrames和DataSet当中自动实现了kryo序列化。

1.11.25 创建临时表和全局临时表

DataFrame.createTempView() 创建普通临时表

DataFrame.createGlobalTempView()   DataFrame.createOrReplaceTempView() 创建全局临时表

1.11.26 BroadCast join 广播join

原理：先将小表数据查询出来聚合到driver端，再广播到各个executor端，使表与表join时

进行本地join，避免进行网络传输产生shuffle。

使用场景：大表join小表 只能广播小表

1.11.27 控制Spark reduce缓存 调优shuffle

spark.reducer.maxSizeInFilght  此参数为reduce task能够拉取多少数据量的一个参数默认48MB，当集群资源足够时，增大此参数可减少reduce拉取数据量的次数，从而达到优化shuffle的效果，一般调大为96MB,资源够大可继续往上跳。

 

spark.shuffle.file.buffer  此参数为每个shuffle文件输出流的内存缓冲区大小，调大此参数可以减少在创建shuffle文件时进行磁盘搜索和系统调用的次数，默认参数为32k 一般调大为64k。

1.11.28 注册UDF函数

SparkSession.udf.register 方法进行注册

1.11.29 SparkSQL中join操作与left join操作的区别？

join和sql中的inner join操作很相似，返回结果是前面一个集合和后面一个集合中匹配成功的，过滤掉关联不上的。

leftJoin类似于SQL中的左外关联left outer join，返回结果以第一个RDD为主，关联不上的记录为空。

部分场景下可以使用left semi join替代left join：

因为 left semi join 是 in(keySet) 的关系，遇到右表重复记录，左表会跳过,性能更高，而 left join 则会一直遍历。但是left semi join 中最后 select 的结果中只许出现左表中的列名，因为右表只有 join key 参与关联计算了

1.11.30 sparkSQL写的sql是如何转化为rdd的？

1. 语法解析，生成未解析的逻辑计划

2. 得到解析后的逻辑计划，得到多条执行路径

3.优化器选择一条最优的逻辑计划

4.把逻辑转化为物理计划，翻译为算子

5.运行的spark底层，得到job，生成dag，切分stage，划分taskSet

1.12 Spark Streaming

1.12.1 Spark Streaming第一次运行不丢失数据

kafka参数 auto.offset.reset 参数设置成earliest 从最初始偏移量开始消费数据

1.12.2 Spark Streaming精准一次消费

  1. 手动维护偏移量
  2. 处理完业务数据后，再进行提交偏移量操作

极端情况下，如在提交偏移量时断网或停电会造成spark程序第二次启动时重复消费问题，所以在涉及到金额或精确性非常高的场景会使用事物保证精准一次消费

1.12.3 Spark Streaming控制每秒消费数据的速度

通过spark.streaming.kafka.maxRatePerPartition参数来设置Spark Streaming从kafka分区每秒拉取的条数

1.12.4 Spark Streaming背压机制

把spark.streaming.backpressure.enabled 参数设置为ture,开启背压机制后Spark Streaming会根据延迟动态去kafka消费数据,上限由spark.streaming.kafka.maxRatePerPartition参数控制，所以两个参数一般会一起使用

1.12.5 Spark Streaming 一个stage耗时

Spark Streaming stage耗时由最慢的task决定,所以数据倾斜时某个task运行慢会导致整个Spark Streaming都运行非常慢。

1.12.6 Spark Streaming 优雅关闭

把spark.streaming.stopGracefullyOnShutdown参数设置成ture,Spark会在JVM关闭时正常关闭StreamingContext,而不是立马关闭

Kill 命令：yarn application -kill     后面跟 applicationid

1.12.7 Spark Streaming 默认分区个数

Spark Streaming默认分区个数与所对接的kafka topic分区个数一致，Spark Streaming里一般不会使用repartition算子增大分区，因为repartition会进行shuffle增加耗时

1.12.8 SparkStreaming有哪几种方式消费Kafka中的数据，它们之间的区别是什么？ 

一、基于Receiver的方式

这种方式使用Receiver来获取数据。Receiver是使用Kafka的高层次Consumer API来实现的。receiver从Kafka中获取的数据都是存储在Spark Executor的内存中的（如果突然数据暴增，大量batch堆积，很容易出现内存溢出的问题），然后Spark Streaming启动的job会去处理那些数据。

然而，在默认的配置下，这种方式可能会因为底层的失败而丢失数据。如果要启用高可靠机制，让数据零丢失，就必须启用Spark Streaming的预写日志机制（Write Ahead Log，WAL）。该机制会同步地将接收到的Kafka数据写入分布式文件系统（比如HDFS）上的预写日志中。所以，即使底层节点出现了失败，也可以使用预写日志中的数据进行恢复。

二、基于Direct的方式

这种新的不基于Receiver的直接方式，是在Spark 1.3中引入的，从而能够确保更加健壮的机制。替代掉使用Receiver来接收数据后，这种方式会周期性地查询Kafka，来获得每个topic+partition的最新的offset，从而定义每个batch的offset的范围。当处理数据的job启动时，就会使用Kafka的简单consumer api来获取Kafka指定offset范围的数据。

优点如下： 

简化并行读取：如果要读取多个partition，不需要创建多个输入DStream然后对它们进行union操作。Spark会创建跟Kafka partition一样多的RDD partition，并且会并行从Kafka中读取数据。所以在Kafka partition和RDD partition之间，有一个一对一的映射关系。

高性能：如果要保证零数据丢失，在基于receiver的方式中，需要开启WAL机制。这种方式其实效率低下，因为数据实际上被复制了两份，Kafka自己本身就有高可靠的机制，会对数据复制一份，而这里又会复制一份到WAL中。而基于direct的方式，不依赖Receiver，不需要开启WAL机制，只要Kafka中作了数据的复制，那么就可以通过Kafka的副本进行恢复。

一次且仅一次的事务机制。

三、对比：

基于receiver的方式，是使用Kafka的高阶API来在ZooKeeper中保存消费过的offset的。这是消费Kafka数据的传统方式。这种方式配合着WAL机制可以保证数据零丢失的高可靠性，但是却无法保证数据被处理一次且仅一次，可能会处理两次。因为Spark和ZooKeeper之间可能是不同步的。

基于direct的方式，使用kafka的简单api，Spark Streaming自己就负责追踪消费的offset，并保存在checkpoint中。Spark自己一定是同步的，因此可以保证数据是消费一次且仅消费一次。

在实际生产环境中大都用Direct方式

1.12.9 简述SparkStreaming窗口函数的原理（重点）

 窗口函数就是在原来定义的SparkStreaming计算批次大小的基础上再次进行封装，每次计算多个批次的数据，同时还需要传递一个滑动步长的参数，用来设置当次计算任务完成之后下一次从什么地方开始计算。

图中time1就是SparkStreaming计算批次大小，虚线框以及实线大框就是窗口的大小，必须为批次的整数倍。虚线框到大实线框的距离（相隔多少批次），就是滑动步长。

1.13 数据倾斜

公司一：总用户量1000万，5台64G内存的服务器。

公司二：总用户量10亿，1000台64G内存的服务器。

1.公司一的数据分析师在做join的时候发生了数据倾斜，会导致有几百万用户的相关数据集中到了一台服务器上，几百万的用户数据，说大也不大，正常字段量的数据的话64G还是能轻松处理掉的。

2.公司二的数据分析师在做join的时候也发生了数据倾斜，可能会有1个亿的用户相关数据集中到了一台机器上了（相信我，这很常见）。这时候一台机器就很难搞定了，最后会很难算出结果。

1.13.1 数据倾斜表现

1）hadoop中的数据倾斜表现：

  1. 有一个多几个Reduce卡住，卡在99.99%，一直不能结束。
  2. 各种container报错OOM
  3. 异常的Reducer读写的数据量极大，至少远远超过其它正常的Reducer
  4. 伴随着数据倾斜，会出现任务被kill等各种诡异的表现。

2）hive中数据倾斜

一般都发生在Sql中group by和join on上，而且和数据逻辑绑定比较深。

3）Spark中的数据倾斜

Spark中的数据倾斜，包括Spark Streaming和Spark Sql，表现主要有下面几种：

  1. Executor lost，OOM，Shuffle过程出错；
  2. Driver OOM；
  3. 单个Executor执行时间特别久，整体任务卡在某个阶段不能结束；
  4. 正常运行的任务突然失败；

1.13.2 数据倾斜产生原因

我们以Spark和Hive的使用场景为例。

他们在做数据运算的时候会涉及到，count distinct、group by、join on等操作，这些都会触发Shuffle动作。一旦触发Shuffle，所有相同key的值就会被拉到一个或几个Reducer节点上，容易发生单点计算问题，导致数据倾斜。

一般来说，数据倾斜原因有以下几方面：

1）key分布不均匀；

大数据技术之高频面试题_第24张图片

 

2）建表时考虑不周

我们举一个例子，就说数据默认值的设计吧，假设我们有两张表：

user（用户信息表）：userid，register_ip

ip（IP表）：ip，register_user_cnt

这可能是两个不同的人开发的数据表。如果我们的数据规范不太完善的话，会出现一种情况：

user表中的register_ip字段，如果获取不到这个信息，我们默认为null；

但是在ip表中，我们在统计这个值的时候，为了方便，我们把获取不到ip的用户，统一认为他们的ip为0。

两边其实都没有错的，但是一旦我们做关联了，这个任务会在做关联的阶段，也就是sql的on的阶段卡死。

3）业务数据激增

比如订单场景，我们在某一天在北京和上海两个城市多了强力的推广，结果可能是这两个城市的订单量增长了10000%，其余城市的数据量不变。

然后我们要统计不同城市的订单情况，这样，一做group操作，可能直接就数据倾斜了。

1.13.3 解决数据倾斜思路

很多数据倾斜的问题，都可以用和平台无关的方式解决，比如更好的数据预处理，异常值的过滤等。因此，解决数据倾斜的重点在于对数据设计和业务的理解，这两个搞清楚了，数据倾斜就解决了大部分了。

1）业务逻辑

我们从业务逻辑的层面上来优化数据倾斜，比如上面的两个城市做推广活动导致那两个城市数据量激增的例子，我们可以单独对这两个城市来做count，单独做时可用两次MR，第一次打散计算，第二次再最终聚合计算。完成后和其它城市做整合。

2）程序层面

比如说在Hive中，经常遇到count(distinct)操作，这样会导致最终只有一个Reduce任务。

我们可以先group by，再在外面包一层count，就可以了。比如计算按用户名去重后的总用户量：

（1）优化前 只有一个reduce，先去重再count负担比较大：

select name,count(distinct name)from user;

（2）优化后

// 设置该任务的每个job的reducer个数为3个。Hive默认-1，自动推断。

set mapred.reduce.tasks=3;

// 启动两个job，一个负责子查询(可以有多个reduce)，另一个负责count(1)：

select count(1) from (select name from user group by name) tmp;

3）调参方面

Hadoop和Spark都自带了很多的参数和机制来调节数据倾斜，合理利用它们就能解决大部分问题。

4）从业务和数据上解决数据倾斜

很多数据倾斜都是在数据的使用上造成的。我们举几个场景，并分别给出它们的解决方案。

  1. 有损的方法：找到异常数据，比如ip为0的数据，过滤掉
  2. 无损的方法：对分布不均匀的数据，单独计算
  3. 先对key做一层hash，先将数据随机打散让它的并行度变大，再汇集
  4. 数据预处理

1.13.4 定位导致数据倾斜代码

Spark数据倾斜只会发生在shuffle过程中。

这里给大家罗列一些常用的并且可能会触发shuffle操作的算子：distinct、groupByKey、reduceByKey、aggregateByKey、join、cogroup、repartition等。

出现数据倾斜时，可能就是你的代码中使用了这些算子中的某一个所导致的。

1.13.4.1 某个task执行特别慢的情况

首先要看的，就是数据倾斜发生在第几个stage中：

如果是用yarn-client模式提交，那么在提交的机器本地是直接可以看到log，可以在log中找到当前运行到了第几个stage；

如果是用yarn-cluster模式提交，则可以通过Spark Web UI来查看当前运行到了第几个stage。

此外，无论是使用yarn-client模式还是yarn-cluster模式，我们都可以在Spark Web UI上深入看一下当前这个stage各个task分配的数据量，从而进一步确定是不是task分配的数据不均匀导致了数据倾斜。

看task运行时间和数据量

task运行时间

比如下图中，倒数第三列显示了每个task的运行时间。明显可以看到，有的task运行特别快，只需要几秒钟就可以运行完；而有的task运行特别慢，需要几分钟才能运行完，此时单从运行时间上看就已经能够确定发生数据倾斜了。

task数据量

此外，倒数第一列显示了每个task处理的数据量，明显可以看到，运行时间特别短的task只需要处理几百KB的数据即可，而运行时间特别长的task需要处理几千KB的数据，处理的数据量差了10倍。此时更加能够确定是发生了数据倾斜。

推断倾斜代码

知道数据倾斜发生在哪一个stage之后，接着我们就需要根据stage划分原理，推算出来发生倾斜的那个stage对应代码中的哪一部分，这部分代码中肯定会有一个shuffle类算子。

精准推算stage与代码的对应关系，需要对Spark的源码有深入的理解，这里我们可以介绍一个相对简单实用的推算方法：只要看到Spark代码中出现了一个shuffle类算子或者是Spark SQL的SQL语句中出现了会导致shuffle的语句（比如group by语句），那么就可以判定，以那个地方为界限划分出了前后两个stage。

这里我们就以如下单词计数来举例。

val conf = new SparkConf()val sc = new SparkContext(conf)val lines = sc.textFile("hdfs://...")val words = lines.flatMap(_.split(" "))val pairs = words.map((_, 1))val wordCounts = pairs.reduceByKey(_ + _)wordCounts.collect().foreach(println(_))

在整个代码中只有一个reduceByKey是会发生shuffle的算子，也就是说这个算子为界限划分出了前后两个stage：

stage0，主要是执行从textFile到map操作，以及shuffle write操作（对pairs RDD中的数据进行分区操作，每个task处理的数据中，相同的key会写入同一个磁盘文件内）。

stage1，主要是执行从reduceByKey到collect操作，以及stage1的各个task一开始运行，就会首先执行shuffle read操作（会从stage0的各个task所在节点拉取属于自己处理的那些key，然后对同一个key进行全局性的聚合或join等操作，在这里就是对key的value值进行累加）

stage1在执行完reduceByKey算子之后，就计算出了最终的wordCounts RDD，然后会执行collect算子，将所有数据拉取到Driver上，供我们遍历和打印输出。

123456789

通过对单词计数程序的分析，希望能够让大家了解最基本的stage划分的原理，以及stage划分后shuffle操作是如何在两个stage的边界处执行的。然后我们就知道如何快速定位出发生数据倾斜的stage对应代码的哪一个部分了。

比如我们在Spark Web UI或者本地log中发现，stage1的某几个task执行得特别慢，判定stage1出现了数据倾斜，那么就可以回到代码中，定位出stage1主要包括了reduceByKey这个shuffle类算子，此时基本就可以确定是是该算子导致了数据倾斜问题。

此时，如果某个单词出现了100万次，其他单词才出现10次，那么stage1的某个task就要处理100万数据，整个stage的速度就会被这个task拖慢。

1.13.4.2 某个task莫名其妙内存溢出的情况

这种情况下去定位出问题的代码就比较容易了。我们建议直接看yarn-client模式下本地log的异常栈，或者是通过YARN查看yarn-cluster模式下的log中的异常栈。一般来说，通过异常栈信息就可以定位到你的代码中哪一行发生了内存溢出。然后在那行代码附近找找，一般也会有shuffle类算子，此时很可能就是这个算子导致了数据倾斜。

但是大家要注意的是，不能单纯靠偶然的内存溢出就判定发生了数据倾斜。因为自己编写的代码的bug，以及偶然出现的数据异常，也可能会导致内存溢出。因此还是要按照上面所讲的方法，通过Spark Web UI查看报错的那个stage的各个task的运行时间以及分配的数据量，才能确定是否是由于数据倾斜才导致了这次内存溢出。

1.13.5 查看导致数据倾斜的key分布情况

先对pairs采样10%的样本数据，然后使用countByKey算子统计出每个key出现的次数，最后在客户端遍历和打印样本数据中各个key的出现次数。

val sampledPairs = pairs.sample(false, 0.1)

val sampledWordCounts = sampledPairs.countByKey()

sampledWordCounts.foreach(println(_))

1.13.6 Spark 数据倾斜的解决方案

1.13.6.1 使用Hive ETL预处理数据

1.13.6.1.1 适用场景

导致数据倾斜的是Hive表。如果该Hive表中的数据本身很不均匀（比如某个key对应了100万数据，其他key才对应了10条数据），而且业务场景需要频繁使用Spark对Hive表执行某个分析操作，那么比较适合使用这种技术方案。

1.13.6.1.2 实现思路

此时可以评估一下，是否可以通过Hive来进行数据预处理（即通过Hive ETL预先对数据按照key进行聚合，或者是预先和其他表进行join），然后在Spark作业中针对的数据源就不是原来的Hive表了，而是预处理后的Hive表。此时由于数据已经预先进行过聚合或join操作了，那么在Spark作业中也就不需要使用原先的shuffle类算子执行这类操作了。

1.13.6.1.3 方案实现原理

这种方案从根源上解决了数据倾斜，因为彻底避免了在Spark中执行shuffle类算子，那么肯定就不会有数据倾斜的问题了。但是这里也要提醒一下大家，这种方式属于治标不治本。因为毕竟数据本身就存在分布不均匀的问题，所以Hive ETL中进行group by或者join等shuffle操作时，还是会出现数据倾斜，导致Hive ETL的速度很慢。我们只是把数据倾斜的发生提前到了Hive ETL中，避免Spark程序发生数据倾斜而已。

1.13.6.1.4 方案优缺点

优点：实现起来简单便捷，效果还非常好，完全规避掉了数据倾斜，Spark作业的性能会大幅度提升。

缺点：治标不治本，Hive ETL中还是会发生数据倾斜。

1.13.6.1.5 方案实践经验

在一些Java系统与Spark结合使用的项目中，会出现Java代码频繁调用Spark作业的场景，而且对Spark作业的执行性能要求很高，就比较适合使用这种方案。将数据倾斜提前到上游的Hive ETL，每天仅执行一次，只有那一次是比较慢的，而之后每次Java调用Spark作业时，执行速度都会很快，能够提供更好的用户体验。

1.13.6.1.6 项目实践经验

在美团·点评的交互式用户行为分析系统中使用了这种方案，该系统主要是允许用户通过Java Web系统提交数据分析统计任务，后端通过Java提交Spark作业进行数据分析统计。要求Spark作业速度必须要快，尽量在10分钟以内，否则速度太慢，用户体验会很差。所以我们将有些Spark作业的shuffle操作提前到了Hive ETL中，从而让Spark直接使用预处理的Hive中间表，尽可能地减少Spark的shuffle操作，大幅度提升了性能，将部分作业的性能提升了6倍以上。

1.13.6.2 过滤少数导致倾斜的key

1.13.6.2.1 方案适用场景

如果发现导致倾斜的key就少数几个，而且对计算本身的影响并不大的话，那么很适合使用这种方案。比如99%的key就对应10条数据，但是只有一个key对应了100万数据，从而导致了数据倾斜。

1.13.6.2.2 方案实现思路

如果我们判断那少数几个数据量特别多的key，对作业的执行和计算结果不是特别重要的话，那么干脆就直接过滤掉那少数几个key。

比如，在Spark SQL中可以使用where子句过滤掉这些key或者在Spark Core中对RDD执行filter算子过滤掉这些key。

如果需要每次作业执行时，动态判定哪些key的数据量最多然后再进行过滤，那么可以使用sample算子对RDD进行采样，然后计算出每个key的数量，取数据量最多的key过滤掉即可。

1.13.6.2.3 方案实现原理

将导致数据倾斜的key给过滤掉之后，这些key就不会参与计算了，自然不可能产生数据倾斜。

1.13.6.2.4 方案优缺点

优点：实现简单，而且效果也很好，可以完全规避掉数据倾斜。

缺点：适用场景不多，大多数情况下，导致倾斜的key还是很多的，并不是只有少数几个。

1.13.6.2.5 方案实践经验

在项目中我们也采用过这种方案解决数据倾斜。有一次发现某一天Spark作业在运行的时候突然OOM了，追查之后发现，是Hive表中的某一个key在那天数据异常，导致数据量暴增。因此就采取每次执行前先进行采样，计算出样本中数据量最大的几个key之后，直接在程序中将那些key给过滤掉。

1.13.6.3 提高shuffle操作的并行度

1.13.6.3.1 方案适用场景

如果我们必须要对数据倾斜迎难而上，那么建议优先使用这种方案，因为这是处理数据倾斜最简单的一种方案。

1.13.6.3.2 方案实现思路

在对RDD执行shuffle算子时，给shuffle算子传入一个参数，比如reduceByKey(1000)，该参数就设置了这个shuffle算子执行时shuffle read task的数量，即spark.sql.shuffle.partitions，该参数代表了shuffle read task的并行度，默认是200，对于很多场景来说都有点过小。

1.13.6.3.3 方案实现原理

增加shuffle read task的数量，可以让原本分配给一个task的多个key分配给多个task，从而让每个task处理比原来更少的数据。举例来说，如果原本有5个key，每个key对应10条数据，这5个key都是分配给一个task的，那么这个task就要处理50条数据。

而增加了shuffle read task以后，每个task就分配到一个key，即每个task就处理10条数据，那么自然每个task的执行时间都会变短了。具体原理如下图所示。

大数据技术之高频面试题_第25张图片

 

1.13.6.3.4 方案优缺点

优点：实现起来比较简单，可以有效缓解和减轻数据倾斜的影响。

缺点：只是缓解了数据倾斜而已，没有彻底根除问题，根据实践经验来看，其效果有限。

1.13.6.3.5 方案实践经验

该方案通常无法彻底解决数据倾斜，因为如果出现一些极端情况，比如某个key对应的数据量有100万，那么无论你的task数量增加到多少，这个对应着100万数据的key肯定还是会分配到一个task中去处理，因此注定还是会发生数据倾斜的。所以这种方案只能说是在发现数据倾斜时尝试使用的第一种手段，尝试去用最简单的方法缓解数据倾斜而已，或者是和其他方案结合起来使用。

1.13.6.4 两阶段聚合（局部聚合+全局聚合）

1.13.6.4.1 方案适用场景

对RDD执行reduceByKey等聚合类shuffle算子或者在Spark SQL中使用group by语句进行分组聚合时，比较适用这种方案。

1.13.6.4.2 方案实现思

路

这个方案的核心实现思路就是进行两阶段聚合：

第一次是局部聚合，先给每个key都打上一个随机数，比如10以内的随机数，此时原先一样的key就变成不一样的了，比如(hello, 1) (hello, 1) (hello, 1) (hello, 1)，就会变成(1_hello, 1) (1_hello, 1) (2_hello, 1) (2_hello, 1)。

接着对打上随机数后的数据，执行reduceByKey等聚合操作，进行局部聚合，那么局部聚合结果，就会变成了(1_hello, 2) (2_hello, 2)。

然后将各个key的前缀给去掉，就会变成(hello,2)(hello,2)，再次进行全局聚合操作，就可以得到最终结果了，比如(hello, 4)。

示例代码如下：

// 第一步，给RDD中的每个key都打上一个随机前缀。
JavaPairRDD randomPrefixRdd = rdd.mapToPair(
        new PairFunction, String, Long>() {
            private static final long serialVersionUID = 1L;
            @Override
            public Tuple2 call(Tuple2 tuple)
                    throws Exception {
                Random random = new Random();
                int prefix = random.nextInt(10);
                return new Tuple2(prefix + "_" + tuple._1, tuple._2);
            }
        });
  
// 第二步，对打上随机前缀的key进行局部聚合。
JavaPairRDD localAggrRdd = randomPrefixRdd.reduceByKey(
        new Function2() {
            private static final long serialVersionUID = 1L;
            @Override
            public Long call(Long v1, Long v2) throws Exception {
                return v1 + v2;
            }
        });
  
// 第三步，去除RDD中每个key的随机前缀。
JavaPairRDD removedRandomPrefixRdd = localAggrRdd.mapToPair(
        new PairFunction, Long, Long>() {
            private static final long serialVersionUID = 1L;
            @Override
            public Tuple2 call(Tuple2 tuple)
                    throws Exception {
                long originalKey = Long.valueOf(tuple._1.split("_")[1]);
                return new Tuple2(originalKey, tuple._2);
            }
        });
  
// 第四步，对去除了随机前缀的RDD进行全局聚合。
JavaPairRDD globalAggrRdd = removedRandomPrefixRdd.reduceByKey(
        new Function2() {
            private static final long serialVersionUID = 1L;
            @Override
            public Long call(Long v1, Long v2) throws Exception {
                return v1 + v2;
            }
        });

1.13.6.4.3 方案实现原理

将原本相同的key通过附加随机前缀的方式，变成多个不同的key，就可以让原本被一个task处理的数据分散到多个task上去做局部聚合，进而解决单个task处理数据量过多的问题。接着去除掉随机前缀，再次进行全局聚合，就可以得到最终的结果。具体原理见下图。

大数据技术之高频面试题_第26张图片

 

1.13.6.4.4 方案优缺点

优点
对于聚合类的shuffle操作导致的数据倾斜，效果是非常不错的。通常都可以解决掉数据倾斜，或者至少是大幅度缓解数据倾斜，将Spark作业的性能提升数倍以上。

缺点
仅仅适用于聚合类的shuffle操作，适用范围相对较窄。如果是join类的shuffle操作，还得用其他的解决方案。

1.13.6.5 将reduce join转为map join

1.13.6.5.1 方案适用场景

在对RDD使用join类操作，或者是在Spark SQL中使用join语句时，而且join操作中的一个RDD或表的数据量比较小（比如几百M或者一两G），比较适用此方案。

1.13.6.5.2 方案实现思路

不使用join算子进行连接操作，而使用Broadcast变量与map类算子实现join操作，进而完全规避掉shuffle类的操作，彻底避免数据倾斜的发生和出现。将较小RDD中的数据直接通过collect算子拉取到Driver端的内存中来，然后对其创建一个Broadcast变量，广播给其他Executor节点；

接着对另外一个RDD执行map类算子，在算子函数内，从Broadcast变量中获取较小RDD的全量数据，与当前RDD的每一条数据按照连接key进行比对，如果连接key相同的话，那么就将两个RDD的数据用你需要的方式连接起来。

示例如下：

// 首先将数据量比较小的RDD的数据，collect到Driver中来。
List> rdd1Data = rdd1.collect()
// 然后使用Spark的广播功能，将小RDD的数据转换成广播变量，这样每个Executor就只有一份RDD的数据。
// 可以尽可能节省内存空间，并且减少网络传输性能开销。
final Broadcast>> rdd1DataBroadcast = sc.broadcast(rdd1Data);
  
// 对另外一个RDD执行map类操作，而不再是join类操作。
JavaPairRDD> joinedRdd = rdd2.mapToPair(
        new PairFunction, String, Tuple2>() {
            private static final long serialVersionUID = 1L;
            @Override
            public Tuple2> call(Tuple2 tuple)
                    throws Exception {
                // 在算子函数中，通过广播变量，获取到本地Executor中的rdd1数据。
                List> rdd1Data = rdd1DataBroadcast.value();
                // 可以将rdd1的数据转换为一个Map，便于后面进行join操作。
                Map rdd1DataMap = new HashMap();
                for(Tuple2 data : rdd1Data) {
                    rdd1DataMap.put(data._1, data._2);
                }
                // 获取当前RDD数据的key以及value。
                String key = tuple._1;
                String value = tuple._2;
                // 从rdd1数据Map中，根据key获取到可以join到的数据。
                Row rdd1Value = rdd1DataMap.get(key);
                return new Tuple2(key, new Tuple2(value, rdd1Value));
            }
        });
  
// 这里得提示一下。
// 上面的做法，仅仅适用于rdd1中的key没有重复，全部是唯一的场景。
// 如果rdd1中有多个相同的key，那么就得用flatMap类的操作，在进行join的时候不能用map，而是得遍历rdd1所有数据进行join。
// rdd2中每条数据都可能会返回多条join后的数据。

1.13.6.5.3 方案实现原理

普通的join是会走shuffle过程的，而一旦shuffle，就相当于会将相同key的数据拉取到一个shuffle read task中再进行join，此时就是reduce join。

但是如果一个RDD是比较小的，则可以采用广播小RDD全量数据+map算子来实现与join同样的效果，也就是map join，此时就不会发生shuffle操作，也就不会发生数据倾斜。具体原理如下图所示。

大数据技术之高频面试题_第27张图片

 

1.13.6.5.4 方案优缺点

优点：对join操作导致的数据倾斜，效果非常好，因为根本就不会发生shuffle，也就根本不会发生数据倾斜。

缺点：适用场景较少，因为这个方案只适用于一个大表和一个小表的情况。毕竟我们需要将小表进行广播，此时会比较消耗内存资源，driver和每个Executor内存中都会驻留一份小RDD的全量数据。如果我们广播出去的RDD数据比较大，比如10G以上，那么就可能发生内存溢出了。因此并不适合两个都是大表的情况。

1.13.6.6 采样倾斜key并分拆join操作

1.13.6.6.1 方案适用场景

两个RDD/Hive表进行join的时候，如果数据量都比较大，无法采用“解决方案五”，那么此时可以看一下两个RDD/Hive表中的key分布情况。

如果出现数据倾斜，是因为其中某一个RDD/Hive表中的少数几个key的数据量过大，而另一个RDD/Hive表中的所有key都分布比较均匀，那么采用这个解决方案是比较合适的。

1.13.6.6.2 方案实现思路

对包含少数几个数据量过大的key的那个RDD，通过sample算子采样出一份样本来，然后统计一下每个key的数量，计算出来数据量最大的是哪几个key。

然后将这几个key对应的数据从原来的RDD中拆分出来，形成一个单独的RDD，并给每个key都打上n以内的随机数作为前缀；

而不会导致倾斜的大部分key形成另外一个RDD。

接着将需要join的另一个RDD，也过滤出来那几个倾斜key对应的数据并形成一个单独的RDD，将每条数据膨胀成n条数据，这n条数据都按顺序附加一个0~n的前缀；

不会导致倾斜的大部分key也形成另外一个RDD。

再将附加了随机前缀的独立RDD与另一个膨胀n倍的独立RDD进行join，此时就可以将原先相同的key打散成n份，分散到多个task中去进行join了。

而另外两个普通的RDD就照常join即可。

最后将两次join的结果使用union算子合并起来即可，就是最终的join结果。

示例如下：

// 首先从包含了少数几个导致数据倾斜key的rdd1中，采样10%的样本数据。
JavaPairRDD sampledRDD = rdd1.sample(false, 0.1);
  
// 对样本数据RDD统计出每个key的出现次数，并按出现次数降序排序。
// 对降序排序后的数据，取出top 1或者top 100的数据，也就是key最多的前n个数据。
// 具体取出多少个数据量最多的key，由大家自己决定，我们这里就取1个作为示范。

// 每行数据变为
JavaPairRDD mappedSampledRDD = sampledRDD.mapToPair(
        new PairFunction, Long, Long>() {
            private static final long serialVersionUID = 1L;
            @Override
            public Tuple2 call(Tuple2 tuple)
                    throws Exception {
                return new Tuple2(tuple._1, 1L);
            }
        });
        
// 按key累加行数
JavaPairRDD countedSampledRDD = mappedSampledRDD.reduceByKey(
        new Function2() {
            private static final long serialVersionUID = 1L;
            @Override
            public Long call(Long v1, Long v2) throws Exception {
                return v1 + v2;
            }
        });
        
// 反转key和value,变为
JavaPairRDD reversedSampledRDD = countedSampledRDD.mapToPair(
        new PairFunction, Long, Long>() {
            private static final long serialVersionUID = 1L;
            @Override
            public Tuple2 call(Tuple2 tuple)
                    throws Exception {
                return new Tuple2(tuple._2, tuple._1);
            }
        });

// 以行数排序key，取最多行数的key
final Long skewedUserid = reversedSampledRDD.sortByKey(false).take(1).get(0)._2;
  
// 从rdd1中分拆出导致数据倾斜的key，形成独立的RDD。
JavaPairRDD skewedRDD = rdd1.filter(
        new Function, Boolean>() {
            private static final long serialVersionUID = 1L;
            @Override
            public Boolean call(Tuple2 tuple) throws Exception {
                return tuple._1.equals(skewedUserid);
            }
        });
        
// 从rdd1中分拆出不导致数据倾斜的普通key，形成独立的RDD。
JavaPairRDD commonRDD = rdd1.filter(
        new Function, Boolean>() {
            private static final long serialVersionUID = 1L;
            @Override
            public Boolean call(Tuple2 tuple) throws Exception {
                return !tuple._1.equals(skewedUserid);
            }
        });
  
// rdd2，就是那个所有key的分布相对较为均匀的rdd。
// 这里将rdd2中，前面获取到的key对应的数据，过滤出来，分拆成单独的rdd，并对rdd中的数据使用flatMap算子都扩容100倍。
// 对扩容的每条数据，都打上0～100的前缀。
JavaPairRDD skewedRdd2 = rdd2.filter(
         new Function, Boolean>() {
            private static final long serialVersionUID = 1L;
            @Override
            public Boolean call(Tuple2 tuple) throws Exception {
                return tuple._1.equals(skewedUserid);
            }
        }).flatMapToPair(new PairFlatMapFunction, String, Row>() {
            private static final long serialVersionUID = 1L;
            @Override
            public Iterable> call(
                    Tuple2 tuple) throws Exception {
                Random random = new Random();
                List> list = new ArrayList>();
                for(int i = 0; i < 100; i++) {
                    list.add(new Tuple2(i + "_" + tuple._1, tuple._2));
                }
                return list;
            }
              
        });
 
// 将rdd1中分拆出来的导致倾斜的key的独立rdd，每条数据都打上100以内的随机前缀。
// 然后将这个rdd1中分拆出来的独立rdd，与上面rdd2中分拆出来的独立rdd，进行join。
JavaPairRDD> joinedRDD1 = skewedRDD.mapToPair(
        new PairFunction, String, String>() {
            private static final long serialVersionUID = 1L;
            @Override
            public Tuple2 call(Tuple2 tuple)
                    throws Exception {
                Random random = new Random();
                int prefix = random.nextInt(100);
                return new Tuple2(prefix + "_" + tuple._1, tuple._2);
            }
        })
        .join(skewedUserid2infoRDD)
        .mapToPair(new PairFunction>, Long, Tuple2>() {
                        private static final long serialVersionUID = 1L;
                        @Override
                        public Tuple2> call(
                            Tuple2> tuple)
                            throws Exception {
                            long key = Long.valueOf(tuple._1.split("_")[1]);
                            return new Tuple2>(key, tuple._2);
                        }
                    });
 
// 将rdd1中分拆出来的包含普通key的独立rdd，直接与rdd2进行join。
JavaPairRDD> joinedRDD2 = commonRDD.join(rdd2);
 
// 将倾斜key join后的结果与普通key join后的结果，uinon起来。
// 就是最终的join结果。
JavaPairRDD> joinedRDD = joinedRDD1.union(joinedRDD2);

1.13.6.6.3 方案实现原理

对于join导致的数据倾斜，如果只是某几个key导致了倾斜，可以将少数几个key分拆成独立RDD，并附加随机前缀打散成n份去进行join，此时这几个key对应的数据就不会集中在少数几个task上，而是分散到多个task进行join了。具体原理见下图。

大数据技术之高频面试题_第28张图片

 

1.13.6.6.4 方案优缺点

优点：对于join导致的数据倾斜，如果只是某几个key导致了倾斜，采用该方式可以用最有效的方式打散key进行join。而且只需要针对少数倾斜key对应的数据进行扩容n倍，不需要对全量数据进行扩容。避免了占用过多内存。

缺点：如果导致倾斜的key特别多的话，比如成千上万个key都导致数据倾斜，那么这种方式也不适合。

1.13.6.7 使用随机前缀和扩容RDD进行join

1.13.6.7.1 方案适用场景

如果在进行join操作时，RDD中有大量的key导致数据倾斜，那么进行分拆key也没什么意义，此时就只能使用最后一种方案来解决问题了。

1.13.6.7.2 方案实现思路

该方案的实现思路基本和“解决方案六”类似，首先查看RDD/Hive表中的数据分布情况，找到那个造成数据倾斜的RDD/Hive表，比如有多个key都对应了超过1万条数据。

然后将该RDD的每条数据都打上一个n以内的随机前缀。

同时对另外一个正常的RDD进行扩容，将每条数据都扩容成n条数据，扩容出来的每条数据都依次打上一个0~n的前缀。

最后将两个处理后的RDD进行join即可。

示例代码如下：

// 首先将其中一个key分布相对较为均匀的RDD膨胀100倍。
JavaPairRDD expandedRDD = rdd1.flatMapToPair(
        new PairFlatMapFunction, String, Row>() {
            private static final long serialVersionUID = 1L;
            @Override
            public Iterable> call(Tuple2 tuple)
                    throws Exception {
                List> list = new ArrayList>();
                for(int i = 0; i < 100; i++) {
                    list.add(new Tuple2(0 + "_" + tuple._1, tuple._2));
                }
                return list;
            }
        });
  
// 其次，将另一个有数据倾斜key的RDD，每条数据都打上100以内的随机前缀。
JavaPairRDD mappedRDD = rdd2.mapToPair(
        new PairFunction, String, String>() {
            private static final long serialVersionUID = 1L;
            @Override
            public Tuple2 call(Tuple2 tuple)
                    throws Exception {
                Random random = new Random();
                int prefix = random.nextInt(100);
                return new Tuple2(prefix + "_" + tuple._1, tuple._2);
            }
        });
  
// 将两个处理后的RDD进行join即可。
JavaPairRDD> joinedRDD = mappedRDD.join(expandedRDD);

1.13.6.7.3 方案实现原理

将原先一样的key通过附加随机前缀变成不一样的key，然后就可以将这些处理后的“不同key”分散到多个task中去处理，而不是让一个task处理大量的相同key。

该方案与“解决方案六”的不同之处就在于，上一种方案是尽量只对少数倾斜key对应的数据进行特殊处理，由于处理过程需要扩容RDD，因此上一种方案扩容RDD后对内存的占用并不大；

而这一种方案是针对有大量倾斜key的情况，没法将部分key拆分出来进行单独处理，因此只能对整个RDD进行数据扩容，对内存资源要求很高。

1.13.6.7.4 方案优缺点

优点：对join类型的数据倾斜基本都可以处理，而且效果也相对比较显著，性能提升效果非常不错。

缺点：该方案更多的是缓解数据倾斜，而不是彻底避免数据倾斜。而且需要对整个RDD进行扩容，对内存资源要求很高。

1.13.6.7.5 方案实践经验

曾经开发一个数据需求的时候，发现一个join导致了数据倾斜。优化之前，作业的执行时间大约是60分钟左右；使用该方案优化之后，执行时间缩短到10分钟左右，性能提升了6倍。

1.13.6.8 多种方案组合使用

在实践中发现，很多情况下，如果只是处理较为简单的数据倾斜场景，那么使用上述方案中的某一种基本就可以解决。但是如果要处理一个较为复杂的数据倾斜场景，那么可能需要将多种方案组合起来使用。

比如说，我们针对出现了多个数据倾斜环节的Spark作业，可以先运用解决方案一HiveETL预处理和过滤少数导致倾斜的k，预处理一部分数据，并过滤一部分数据来缓解；

其次可以对某些shuffle操作提升并行度，优化其性能；

最后还可以针对不同的聚合或join操作，选择一种方案来优化其性能。

大家需要对这些方案的思路和原理都透彻理解之后，在实践中根据各种不同的情况，灵活运用多种方案，来解决自己的数据倾斜问题。

1.13.7 Spark数据倾斜处理小结

大数据技术之高频面试题_第29张图片

 

 

1.14 Flink基础

1.14.1 简单介绍一下 Flink

Flink 是一个框架和分布式处理引擎，用于对无界和有界数据流进行有状态计算。并且 Flink 提供了数据分布、容错机制以及资源管理等核心功能。Flink提供了诸多高抽象层的API以便用户编写分布式任务：

DataSet API， 对静态数据进行批处理操作，将静态数据抽象成分布式的数据集，用户可以方便地使用Flink提供的各种操作符对分布式数据集进行处理，支持Java、Scala和Python。

DataStream API，对数据流进行流处理操作，将流式的数据抽象成分布式的数据流，用户可以方便地对分布式数据流进行各种操作，支持Java和Scala。

Table API，对结构化数据进行查询操作，将结构化数据抽象成关系表，并通过类SQL的DSL对关系表进行各种查询操作，支持Java和Scala。

此外，Flink 还针对特定的应用领域提供了领域库，例如： Flink ML，Flink 的机器学习库，提供了机器学习Pipelines API并实现了多种机器学习算法。 Gelly，Flink 的图计算库，提供了图计算的相关API及多种图计算算法实现。根据官网的介绍，Flink 的特性包含：

1.14.2 Flink相比传统的Spark Streaming区别?

这个问题是一个非常宏观的问题，因为两个框架的不同点非常之多。但是在面试时有非常重要的一点一定要回答出来：Flink 是标准的实时处理引擎，基于事件驱动。而 Spark Streaming 是微批（Micro-Batch）的模型。

下面我们就分几个方面介绍两个框架的主要区别：

1. 架构模型Spark Streaming 在运行时的主要角色包括：Master、Worker、Driver、Executor，Flink 在运行时主要包含：Jobmanager、Taskmanager和Slot。

2. 任务调度Spark Streaming 连续不断的生成微小的数据批次，构建有向无环图DAG，Spark Streaming 会依次创建 DStreamGraph、JobGenerator、JobScheduler。Flink 根据用户提交的代码生成 StreamGraph，经过优化生成 JobGraph，然后提交给 JobManager进行处理，JobManager 会根据 JobGraph 生成 ExecutionGraph，ExecutionGraph 是 Flink 调度最核心的数据结构，JobManager 根据 ExecutionGraph 对 Job 进行调度。

3. 时间机制Spark Streaming 支持的时间机制有限，只支持处理时间。 Flink 支持了流处理程序在时间上的三个定义：处理时间、事件时间、注入时间。同时也支持 watermark 机制来处理滞后数据。

4. 容错机制对于 Spark Streaming 任务，我们可以设置 checkpoint，然后假如发生故障并重启，我们可以从上次 checkpoint 之处恢复，但是这个行为只能使得数据不丢失，可能会重复处理，不能做到恰好一次处理语义。Flink 则使用两阶段提交协议来解决这个问题。

1.14.3 Flink的组件栈有哪些？

根据 Flink 官网描述，Flink 是一个分层架构的系统，每一层所包含的组件都提供了特定的抽象，用来服务于上层组件。

 大数据技术之高频面试题_第30张图片

自下而上，每一层分别代表：Deploy 层：该层主要涉及了Flink的部署模式，在上图中我们可以看出，Flink 支持包括local、Standalone、Cluster、Cloud等多种部署模式。Runtime 层：Runtime层提供了支持 Flink 计算的核心实现，比如：支持分布式 Stream 处理、JobGraph到ExecutionGraph的映射、调度等等，为上层API层提供基础服务。API层：API 层主要实现了面向流（Stream）处理和批（Batch）处理API，其中面向流处理对应DataStream API，面向批处理对应DataSet API，后续版本，Flink有计划将DataStream和DataSet API进行统一。Libraries层：该层称为Flink应用框架层，根据API层的划分，在API层之上构建的满足特定应用的实现计算框架，也分别对应于面向流处理和面向批处理两类。面向流处理支持：CEP（复杂事件处理）、基于SQL-like的操作（基于Table的关系操作）；面向批处理支持：FlinkML（机器学习库）、Gelly（图处理）。

1.14.4 Flink 的运行必须依赖 Hadoop组件吗？

Flink可以完全独立于Hadoop，在不依赖Hadoop组件下运行。但是做为大数据的基础设施，Hadoop体系是任何大数据框架都绕不过去的。Flink可以集成众多Hadooop 组件，例如Yarn、Hbase、HDFS等等。例如，Flink可以和Yarn集成做资源调度，也可以读写HDFS，或者利用HDFS做检查点。

1.14.5 你们的Flink集群规模多大？

大家注意，这个问题看起来是问你实际应用中的Flink集群规模，其实还隐藏着另一个问题：Flink可以支持多少节点的集群规模？在回答这个问题时候，可以将自己生产环节中的集群规模、节点、内存情况说明，同时说明部署模式（一般是Flink on Yarn），除此之外，用户也可以同时在小集群（少于5个节点）和拥有 TB 级别状态的上千个节点上运行 Flink 任务。

1.14.6 Flink的基础编程模型了解吗？

大数据技术之高频面试题_第31张图片

 

上图是来自Flink官网的运行流程图。通过上图我们可以得知，Flink 程序的基本构建是数据输入来自一个 Source，Source 代表数据的输入端，经过 Transformation 进行转换，然后在一个或者多个Sink接收器中结束。数据流（stream）就是一组永远不会停止的数据记录流，而转换（transformation）是将一个或多个流作为输入，并生成一个或多个输出流的操作。执行时，Flink程序映射到 streaming dataflows，由流（streams）和转换操作（transformation operators）组成。

1.14.7 Flink集群有哪些角色？各自有什么作用？

大数据技术之高频面试题_第32张图片

 

Flink 程序在运行时主要有 TaskManager，JobManager，Client三种角色。其中JobManager扮演着集群中的管理者Master的角色，它是整个集群的协调者，负责接收Flink Job，协调检查点，Failover 故障恢复等，同时管理Flink集群中从节点TaskManager。TaskManager是实际负责执行计算的Worker，在其上执行Flink Job的一组Task，每个TaskManager负责管理其所在节点上的资源信息，如内存、磁盘、网络，在启动的时候将资源的状态向JobManager汇报。Client是Flink程序提交的客户端，当用户提交一个Flink程序时，会首先创建一个Client，该Client首先会对用户提交的Flink程序进行预处理，并提交到Flink集群中处理，所以Client需要从用户提交的Flink程序配置中获取JobManager的地址，并建立到JobManager的连接，将Flink Job提交给JobManager。

1.14.8 说说 Flink 资源管理中 Task Slot 的概念

大数据技术之高频面试题_第33张图片

 

在Flink架构角色中我们提到，TaskManager是实际负责执行计算的Worker，TaskManager 是一个 JVM 进程，并会以独立的线程来执行一个task或多个subtask。为了控制一个 TaskManager 能接受多少个 task，Flink 提出了 Task Slot 的概念。简单的说，TaskManager会将自己节点上管理的资源分为不同的Slot：固定大小的资源子集。这样就避免了不同Job的Task互相竞争内存资源，但是需要主要的是，Slot只会做内存的隔离。没有做CPU的隔离。

1.14.9 说说 Flink 的常用算子？

Flink 最常用的常用算子包括：Map：DataStream → DataStream，输入一个参数产生一个参数，map的功能是对输入的参数进行转换操作。Filter：过滤掉指定条件的数据。KeyBy：按照指定的key进行分组。Reduce：用来进行结果汇总合并。Window：窗口函数，根据某些特性将每个key的数据进行分组（例如：在5s内到达的数据）

1.14.10 说说你知道的Flink分区策略？

什么要搞懂什么是分区策略。分区策略是用来决定数据如何发送至下游。目前 Flink 支持了8中分区策略的实现。

 

上图是整个Flink实现的分区策略继承图：GlobalPartitioner 数据会被分发到下游算子的第一个实例中进行处理。ShufflePartitioner 数据会被随机分发到下游算子的每一个实例中进行处理。RebalancePartitioner 数据会被循环发送到下游的每一个实例中进行处理。RescalePartitioner 这种分区器会根据上下游算子的并行度，循环的方式输出到下游算子的每个实例。这里有点难以理解，假设上游并行度为2，编号为A和B。下游并行度为4，编号为1，2，3，4。那么A则把数据循环发送给1和2，B则把数据循环发送给3和4。假设上游并行度为4，编号为A，B，C，D。下游并行度为2，编号为1，2。那么A和B则把数据发送给1，C和D则把数据发送给2。BroadcastPartitioner 广播分区会将上游数据输出到下游算子的每个实例中。适合于大数据集和小数据集做Jion的场景。ForwardPartitioner ForwardPartitioner 用于将记录输出到下游本地的算子实例。它要求上下游算子并行度一样。简单的说，ForwardPartitioner用来做数据的控制台打印。KeyGroupStreamPartitioner Hash分区器。会将数据按 Key 的 Hash 值输出到下游算子实例中。CustomPartitionerWrapper 用户自定义分区器。需要用户自己实现Partitioner接口，来定义自己的分区逻辑。例如：

static classCustomPartitionerimplementsPartitioner {
      @Override
      publicintpartition(String key, int numPartitions) {
          switch (key){
              case "1":
                  return 1;
              case "2":
                  return 2;
              case "3":
                  return 3;
              default:
                  return 4;
          }
      }
  }

1.14.11 Flink的并行度了解吗？Flink的并行度设置是怎样的？

Flink中的任务被分为多个并行任务来执行，其中每个并行的实例处理一部分数据。这些并行实例的数量被称为并行度。我们在实际生产环境中可以从四个不同层面设置并行度：

操作算子层面(Operator Level)

执行环境层面(Execution Environment Level)

客户端层面(Client Level)

系统层面(System Level)

需要注意的优先级：算子层面>环境层面>客户端层面>系统层面。

1.14.12 Flink的Slot和parallelism有什么区别？

官网上十分经典的图：

大数据技术之高频面试题_第34张图片

 

slot是指taskmanager的并发执行能力，假设我们将 taskmanager.numberOfTaskSlots 配置为3 那么每一个 taskmanager 中分配3个 TaskSlot, 3个 taskmanager 一共有9个TaskSlot。

 

大数据技术之高频面试题_第35张图片

parallelism是指taskmanager实际使用的并发能力。假设我们把 parallelism.default 设置为1，那么9个 TaskSlot 只能用1个，有8个空闲。

1.14.13 Flink有没有重启策略？说说有哪几种？

Flink 实现了多种重启策略。

固定延迟重启策略（Fixed Delay Restart Strategy）

故障率重启策略（Failure Rate Restart Strategy）

没有重启策略（No Restart Strategy）

Fallback重启策略（Fallback Restart Strategy）

1.14.14 用过Flink中的分布式缓存吗？如何使用？

Flink实现的分布式缓存和Hadoop有异曲同工之妙。目的是在本地读取文件，并把他放在 taskmanager 节点中，防止task重复拉取。

val env = ExecutionEnvironment.getExecutionEnvironment

// register a file from HDFS
env.registerCachedFile("hdfs:///path/to/your/file", "hdfsFile")

// register a local executable file (script, executable, ...)
env.registerCachedFile("file:///path/to/exec/file", "localExecFile", true)

// define your program and execute
...
val input: DataSet[String] = ...
val result: DataSet[Integer] = input.map(new MyMapper())
...
env.execute()

1.14.15 说说Flink中的广播变量，使用时需要注意什么？

我们知道Flink是并行的，计算过程可能不在一个 Slot 中进行，那么有一种情况即：当我们需要访问同一份数据。那么Flink中的广播变量就是为了解决这种情况。我们可以把广播变量理解为是一个公共的共享变量，我们可以把一个dataset 数据集广播出去，然后不同的task在节点上都能够获取到，这个数据在每个节点上只会存在一份。

1.14.16 说说Flink中的窗口？

来一张官网经典的图：

大数据技术之高频面试题_第36张图片

 

Flink 支持两种划分窗口的方式，按照time和count。如果根据时间划分窗口，那么它就是一个time-window 如果根据数据划分窗口，那么它就是一个count-window。flink支持窗口的两个重要属性（size和interval）如果size=interval,那么就会形成tumbling-window(无重叠数据) 如果size>interval,那么就会形成sliding-window(有重叠数据) 如果size< interval, 那么这种窗口将会丢失数据。比如每5秒钟，统计过去3秒的通过路口汽车的数据，将会漏掉2秒钟的数据。通过组合可以得出四种基本窗口：

time-tumbling-window 无重叠数据的时间窗口，设置方式举例：timeWindow(Time.seconds(5))

time-sliding-window 有重叠数据的时间窗口，设置方式举例：timeWindow(Time.seconds(5), Time.seconds(3))

count-tumbling-window无重叠数据的数量窗口，设置方式举例：countWindow(5)

count-sliding-window 有重叠数据的数量窗口，设置方式举例：countWindow(5,3)

1.14.17 说说Flink中的状态存储？

Flink在做计算的过程中经常需要存储中间状态，来避免数据丢失和状态恢复。选择的状态存储策略不同，会影响状态持久化如何和 checkpoint 交互。Flink提供了三种状态存储方式：MemoryStateBackend、FsStateBackend、RocksDBStateBackend。

1.14.18 Flink中的时间有哪几类

Flink 中的时间和其他流式计算系统的时间一样分为三类：事件时间，摄入时间，处理时间三种。如果以 EventTime 为基准来定义时间窗口将形成EventTimeWindow,要求消息本身就应该携带EventTime。如果以 IngesingtTime 为基准来定义时间窗口将形成 IngestingTimeWindow,以 source 的systemTime为准。如果以 ProcessingTime 基准来定义时间窗口将形成 ProcessingTimeWindow，以 operator 的systemTime 为准。

1.14.19 Flink 中水印是什么概念，起到什么作用？

Watermark 是 Apache Flink 为了处理 EventTime 窗口计算提出的一种机制, 本质上是一种时间戳。 一般来讲Watermark经常和Window一起被用来处理乱序事件。

1.14.20 Flink Table & SQL 熟悉吗？TableEnvironment这个类有什么作用

TableEnvironment是Table API和SQL集成的核心概念。这个类主要用来：

在内部catalog中注册表

注册外部catalog

执行SQL查询

注册用户定义（标量，表或聚合）函数

将DataStream或DataSet转换为表

持有对ExecutionEnvironment或StreamExecutionEnvironment的引用

1.14.21 Flink SQL的实现原理是什么？是如何实现 SQL 解析的呢？

首先大家要知道 Flink 的SQL解析是基于Apache Calcite这个开源框架。

 

基于此，一次完整的SQL解析过程如下：

用户使用对外提供Stream SQL的语法开发业务应用

用calcite对StreamSQL进行语法检验，语法检验通过后，转换成calcite的逻辑树节点；最终形成calcite的逻辑计划

采用Flink自定义的优化规则和calcite火山模型、启发式模型共同对逻辑树进行优化，生成最优的Flink物理计划

对物理计划采用janino codegen生成代码，生成用低阶API DataStream 描述的流应用，提交到Flink平台执行

1.15 Flink中级

1.15.1 Flink是如何支持批流一体的？

大数据技术之高频面试题_第37张图片

 

本道面试题考察的其实就是一句话：Flink的开发者认为批处理是流处理的一种特殊情况。批处理是有限的流处理。Flink 使用一个引擎支持了DataSet API 和 DataStream API。

1.15.2 Flink是如何做到高效的数据交换的？

在一个Flink Job中，数据需要在不同的task中进行交换，整个数据交换是有 TaskManager 负责的，TaskManager 的网络组件首先从缓冲buffer中收集records，然后再发送。Records 并不是一个一个被发送的，二是积累一个批次再发送，batch 技术可以更加高效的利用网络资源。

1.15.3 Flink是如何做容错的？

Flink 实现容错主要靠强大的CheckPoint机制和State机制。Checkpoint 负责定时制作分布式快照、对程序中的状态进行备份；State 用来存储计算过程中的中间状态。

1.15.4 Flink 分布式快照的原理是什么？

Flink的分布式快照是根据Chandy-Lamport算法量身定做的。简单来说就是持续创建分布式数据流及其状态的一致快照。

大数据技术之高频面试题_第38张图片

 

核心思想是在 input source 端插入 barrier，控制 barrier 的同步来实现 snapshot 的备份和 exactly-once 语义。

1.15.5 Flink是如何保证Exactly-once语义的？

Flink通过实现两阶段提交和状态保存来实现端到端的一致性语义。 分为以下几个步骤：

开始事务（beginTransaction）创建一个临时文件夹，来写把数据写入到这个文件夹里面

预提交（preCommit）将内存中缓存的数据写入文件并关闭

正式提交（commit）将之前写完的临时文件放入目标目录下。这代表着最终的数据会有一些延迟

丢弃（abort）丢弃临时文件

若失败发生在预提交成功后，正式提交前。可以根据状态来提交预提交的数据，也可删除预提交的数据。

1.15.6 Flink 的 kafka 连接器有什么特别的地方？

Flink源码中有一个独立的connector模块，所有的其他connector都依赖于此模块，Flink 在1.9版本发布的全新kafka连接器，摒弃了之前连接不同版本的kafka集群需要依赖不同版本的connector这种做法，只需要依赖一个connector即可。

1.15.7 说说 Flink的内存管理是如何做的?

Flink 并不是将大量对象存在堆上，而是将对象都序列化到一个预分配的内存块上。此外，Flink大量的使用了堆外内存。如果需要处理的数据超出了内存限制，则会将部分数据存储到硬盘上。Flink 为了直接操作二进制数据实现了自己的序列化框架。理论上Flink的内存管理分为三部分：

Network Buffers：这个是在TaskManager启动的时候分配的，这是一组用于缓存网络数据的内存，每个块是32K，默认分配2048个，可以通过“taskmanager.network.numberOfBuffers”修改

Memory Manage pool：大量的Memory Segment块，用于运行时的算法（Sort/Join/Shuffle等），这部分启动的时候就会分配。下面这段代码，根据配置文件中的各种参数来计算内存的分配方法。（heap or off-heap，这个放到下节谈），内存的分配支持预分配和lazy load，默认懒加载的方式。

User Code，这部分是除了Memory Manager之外的内存用于User code和TaskManager本身的数据结构。

1.15.8 说说 Flink的序列化如何做的?

Java本身自带的序列化和反序列化的功能，但是辅助信息占用空间比较大，在序列化对象时记录了过多的类信息。Apache Flink摒弃了Java原生的序列化方法，以独特的方式处理数据类型和序列化，包含自己的类型描述符，泛型类型提取和类型序列化框架。TypeInformation 是所有类型描述符的基类。它揭示了该类型的一些基本属性，并且可以生成序列化器。TypeInformation 支持以下几种类型：

BasicTypeInfo: 任意Java 基本类型或 String 类型

BasicArrayTypeInfo: 任意Java基本类型数组或 String 数组

WritableTypeInfo: 任意 Hadoop Writable 接口的实现类

TupleTypeInfo: 任意的 Flink Tuple 类型(支持Tuple1 to Tuple25)。Flink tuples 是固定长度固定类型的Java Tuple实现

CaseClassTypeInfo: 任意的 Scala CaseClass(包括 Scala tuples)

PojoTypeInfo: 任意的 POJO (Java or Scala)，例如，Java对象的所有成员变量，要么是 public 修饰符定义，要么有 getter/setter 方法

GenericTypeInfo: 任意无法匹配之前几种类型的类

针对前六种类型数据集，Flink皆可以自动生成对应的TypeSerializer，能非常高效地对数据集进行序列化和反序列化。

1.15.9 Flink中的Window出现了数据倾斜，你有什么解决办法？

window产生数据倾斜指的是数据在不同的窗口内堆积的数据量相差过多。本质上产生这种情况的原因是数据源头发送的数据量速度不同导致的。出现这种情况一般通过两种方式来解决：

在数据进入窗口前做预聚合

重新设计窗口聚合的key

1.15.10 Flink中在使用聚合函数 GroupBy、Distinct、KeyBy 等函数时出现数据热点该如何解决？

数据倾斜和数据热点是所有大数据框架绕不过去的问题。处理这类问题主要从3个方面入手：

在业务上规避这类问题

例如一个假设订单场景，北京和上海两个城市订单量增长几十倍，其余城市的数据量不变。这时候我们在进行聚合的时候，北京和上海就会出现数据堆积，我们可以单独数据北京和上海的数据。

Key的设计上

把热key进行拆分，比如上个例子中的北京和上海，可以把北京和上海按照地区进行拆分聚合。

参数设置

Flink 1.9.0 SQL(Blink Planner) 性能优化中一项重要的改进就是升级了微批模型，即 MiniBatch。原理是缓存一定的数据后再触发处理，以减少对State的访问，从而提升吞吐和减少数据的输出量。

1.15.11 Flink任务延迟高，想解决这个问题，你会如何入手？

在Flink的后台任务管理中，我们可以看到Flink的哪个算子和task出现了反压。最主要的手段是资源调优和算子调优。资源调优即是对作业中的Operator的并发数（parallelism）、CPU（core）、堆内存（heap_memory）等参数进行调优。作业参数调优包括：并行度的设置，State的设置，checkpoint的设置。

1.15.12 Flink是如何处理反压的？

Flink 内部是基于 producer-consumer 模型来进行消息传递的，Flink的反压设计也是基于这个模型。Flink 使用了高效有界的分布式阻塞队列，就像 Java 通用的阻塞队列（BlockingQueue）一样。下游消费者消费变慢，上游就会受到阻塞。

1.15.13 Flink的反压和Strom有哪些不同？

Storm 是通过监控 Bolt 中的接收队列负载情况，如果超过高水位值就会将反压信息写到 Zookeeper ，Zookeeper 上的 watch 会通知该拓扑的所有 Worker 都进入反压状态，最后 Spout 停止发送 tuple。Flink中的反压使用了高效有界的分布式阻塞队列，下游消费变慢会导致发送端阻塞。二者最大的区别是Flink是逐级反压，而Storm是直接从源头降速。

1.15.14 Operator Chains（算子链）这个概念你了解吗？

为了更高效地分布式执行，Flink会尽可能地将operator的subtask链接（chain）在一起形成task。每个task在一个线程中执行。将operators链接成task是非常有效的优化：它能减少线程之间的切换，减少消息的序列化/反序列化，减少数据在缓冲区的交换，减少了延迟的同时提高整体的吞吐量。这就是我们所说的算子链。

1.15.15 Flink什么情况下才会把Operator chain在一起形成算子链？

两个operator chain在一起的的条件：

上下游的并行度一致

下游节点的入度为1 （也就是说下游节点没有来自其他节点的输入）

上下游节点都在同一个 slot group 中（下面会解释 slot group）

下游节点的 chain 策略为 ALWAYS（可以与上下游链接，map、flatmap、filter等默认是ALWAYS）

上游节点的 chain 策略为 ALWAYS 或 HEAD（只能与下游链接，不能与上游链接，Source默认是HEAD）

两个节点间数据分区方式是 forward（参考理解数据流的分区）

用户没有禁用 chain

1.15.16 说说Flink1.9的新特性？

支持hive读写，支持UDF

Flink SQL TopN和GroupBy等优化

Checkpoint跟savepoint针对实际业务场景做了优化

Flink state查询

1.15.17 消费kafka数据的时候，如何处理脏数据？

可以在处理前加一个fliter算子，将不符合规则的数据过滤出去。

1.16 Flink高级

1.16.1 Flink Job的提交流程 

用户提交的Flink Job会被转化成一个DAG任务运行，分别是：StreamGraph、JobGraph、ExecutionGraph，Flink中JobManager与TaskManager，JobManager与Client的交互是基于Akka工具包的，是通过消息驱动。整个Flink Job的提交还包含着ActorSystem的创建，JobManager的启动，TaskManager的启动和注册。

1.16.2 Flink所谓"三层图"结构是哪几个"图"？

一个Flink任务的DAG生成计算图大致经历以下三个过程：

StreamGraph 最接近代码所表达的逻辑层面的计算拓扑结构，按照用户代码的执行顺序向StreamExecutionEnvironment添加StreamTransformation构成流式图。

JobGraph 从StreamGraph生成，将可以串联合并的节点进行合并，设置节点之间的边，安排资源共享slot槽位和放置相关联的节点，上传任务所需的文件，设置检查点配置等。相当于经过部分初始化和优化处理的任务图。

ExecutionGraph 由JobGraph转换而来，包含了任务具体执行所需的内容，是最贴近底层实现的执行图。

1.16.3 JobManger在集群中扮演了什么角色？

JobManager 负责整个 Flink 集群任务的调度以及资源的管理，从客户端中获取提交的应用，然后根据集群中 TaskManager 上 TaskSlot 的使用情况，为提交的应用分配相应的 TaskSlot 资源并命令 TaskManager 启动从客户端中获取的应用。JobManager 相当于整个集群的 Master 节点，且整个集群有且只有一个活跃的 JobManager ，负责整个集群的任务管理和资源管理。JobManager 和 TaskManager 之间通过 Actor System 进行通信，获取任务执行的情况并通过 Actor System 将应用的任务执行情况发送给客户端。同时在任务执行的过程中，Flink JobManager 会触发 Checkpoint 操作，每个 TaskManager 节点 收到 Checkpoint 触发指令后，完成 Checkpoint 操作，所有的 Checkpoint 协调过程都是在 Fink JobManager 中完成。当任务完成后，Flink 会将任务执行的信息反馈给客户端，并且释放掉 TaskManager 中的资源以供下一次提交任务使用。

1.16.4 JobManger在集群启动过程中起到什么作用？

JobManager的职责主要是接收Flink作业，调度Task，收集作业状态和管理TaskManager。它包含一个Actor，并且做如下操作：

RegisterTaskManager: 它由想要注册到JobManager的TaskManager发送。注册成功会通过AcknowledgeRegistration消息进行Ack。

SubmitJob: 由提交作业到系统的Client发送。提交的信息是JobGraph形式的作业描述信息。

CancelJob: 请求取消指定id的作业。成功会返回CancellationSuccess，否则返回CancellationFailure。

UpdateTaskExecutionState: 由TaskManager发送，用来更新执行节点(ExecutionVertex)的状态。成功则返回true，否则返回false。

RequestNextInputSplit: TaskManager上的Task请求下一个输入split，成功则返回NextInputSplit，否则返回null。

JobStatusChanged： 它意味着作业的状态(RUNNING, CANCELING, FINISHED,等)发生变化。这个消息由ExecutionGraph发送。

1.16.5 TaskManager在集群中扮演了什么角色？

TaskManager 相当于整个集群的 Slave 节点，负责具体的任务执行和对应任务在每个节点上的资源申请和管理。客户端通过将编写好的 Flink 应用编译打包，提交到 JobManager，然后 JobManager 会根据已注册在 JobManager 中 TaskManager 的资源情况，将任务分配给有资源的 TaskManager节点，然后启动并运行任务。TaskManager 从 JobManager 接收需要部署的任务，然后使用 Slot 资源启动 Task，建立数据接入的网络连接，接收数据并开始数据处理。同时 TaskManager 之间的数据交互都是通过数据流的方式进行的。可以看出，Flink 的任务运行其实是采用多线程的方式，这和 MapReduce 多 JVM 进行的方式有很大的区别，Flink 能够极大提高 CPU 使用效率，在多个任务和 Task 之间通过 TaskSlot 方式共享系统资源，每个 TaskManager 中通过管理多个 TaskSlot 资源池进行对资源进行有效管理。

1.16.6 TaskManager在集群启动过程中起到什么作用？

TaskManager的启动流程较为简单： 启动类：org.apache.flink.runtime.taskmanager.TaskManager 核心启动方法 ： selectNetworkInterfaceAndRunTaskManager 启动后直接向JobManager注册自己，注册完成后，进行部分模块的初始化。

1.16.7 Flink 计算资源的调度是如何实现的？

TaskManager中最细粒度的资源是Task slot，代表了一个固定大小的资源子集，每个TaskManager会将其所占有的资源平分给它的slot。

通过调整 task slot 的数量，用户可以定义task之间是如何相互隔离的。每个 TaskManager 有一个slot，也就意味着每个task运行在独立的 JVM 中。每个 TaskManager 有多个slot的话，也就是说多个task运行在同一个JVM中。

而在同一个JVM进程中的task，可以共享TCP连接（基于多路复用）和心跳消息，可以减少数据的网络传输，也能共享一些数据结构，一定程度上减少了每个task的消耗。 每个slot可以接受单个task，也可以接受多个连续task组成的pipeline，如下图所示，FlatMap函数占用一个taskslot，而key Agg函数和sink函数共用一个taskslot：

大数据技术之高频面试题_第39张图片

 

1.16.8 简述Flink的数据抽象及数据交换过程？

Flink 为了避免JVM的固有缺陷例如java对象存储密度低，FGC影响吞吐和响应等，实现了自主管理内存。MemorySegment就是Flink的内存抽象。默认情况下，一个MemorySegment可以被看做是一个32kb大的内存块的抽象。这块内存既可以是JVM里的一个byte[]，也可以是堆外内存（DirectByteBuffer）。在MemorySegment这个抽象之上，Flink在数据从operator内的数据对象在向TaskManager上转移，预备被发给下个节点的过程中，使用的抽象或者说内存对象是Buffer。对接从Java对象转为Buffer的中间对象是另一个抽象StreamRecord。

1.16.9 Flink 中的分布式快照机制是如何实现的？

Flink的容错机制的核心部分是制作分布式数据流和操作算子状态的一致性快照。 这些快照充当一致性checkpoint，系统可以在发生故障时回滚。 Flink用于制作这些快照的机制在“分布式数据流的轻量级异步快照”中进行了描述。 它受到分布式快照的标准Chandy-Lamport算法的启发，专门针对Flink的执行模型而定制。

大数据技术之高频面试题_第40张图片

 

barriers在数据流源处被注入并行数据流中。快照n的barriers被插入的位置（我们称之为Sn）是快照所包含的数据在数据源中最大位置。例如，在Apache Kafka中，此位置将是分区中最后一条记录的偏移量。 将该位置Sn报告给checkpoint协调器（Flink的JobManager）。然后barriers向下游流动。当一个中间操作算子从其所有输入流中收到快照n的barriers时，它会为快照n发出barriers进入其所有输出流中。 一旦sink操作算子（流式DAG的末端）从其所有输入流接收到barriers n，它就向checkpoint协调器确认快照n完成。在所有sink确认快照后，意味快照着已完成。一旦完成快照n，job将永远不再向数据源请求Sn之前的记录，因为此时这些记录（及其后续记录）将已经通过整个数据流拓扑，也即是已经被处理结束。

1.16.10 简单说说FlinkSQL的是如何实现的？

Flink 将 SQL 校验、SQL 解析以及 SQL 优化交给了Apache Calcite。Calcite 在其他很多开源项目里也都应用到了，譬如 Apache Hive, Apache Drill, Apache Kylin, Cascading。Calcite 在新的架构中处于核心的地位，如下图所示。

大数据技术之高频面试题_第41张图片

 

构建抽象语法树的事情交给了 Calcite 去做。SQL query 会经过 Calcite 解析器转变成 SQL 节点树，通过验证后构建成 Calcite 的抽象语法树（也就是图中的 Logical Plan）。另一边，Table API 上的调用会构建成 Table API 的抽象语法树，并通过 Calcite 提供的 RelBuilder 转变成 Calcite 的抽象语法树。然后依次被转换成逻辑执行计划和物理执行计划。在提交任务后会分发到各个 TaskManager 中运行，在运行时会使用 Janino 编译器编译代码后运行。

 

第2章 项目架构

2.1 提高自信

云上数据仓库解决方案：https://www.aliyun.com/solution/datavexpo/datawarehouse

 

大数据技术之高频面试题_第42张图片

 

大数据技术之高频面试题_第43张图片

2.2 数仓概念

数据仓库的输入数据源和输出系统分别是什么？

输入系统：埋点产生的用户行为数据、JavaEE后台产生的业务数据、个别公司有爬虫数据。

输出系统：报表系统、用户画像系统、推荐系统

2.3 系统数据流程设计

大数据技术之高频面试题_第44张图片

 

2.4 框架版本选型

1）Apache：运维麻烦，组件间兼容性需要自己调研。（一般大厂使用，技术实力雄厚，有专业的运维人员）

2）CDH6.3.2：国内使用最多的版本，但 CM不开源，但其实对中、小公司使用来说没有影响（建议使用）10000美金一个节点   CDP7.0

3）HDP：开源，可以进行二次开发，但是没有CDH稳定，国内使用较少

大数据技术之高频面试题_第45张图片

 

2.5 服务器选型

服务器使用物理机还是云主机？

1）机器成本考虑：

（1）物理机：以128G内存，20核物理CPU，40线程，8THDD和2TSSD硬盘，单台报价4W出头，惠普品牌。一般物理机寿命5年左右。

（2）云主机，以阿里云为例，差不多相同配置，每年5W

2）运维成本考虑：

（1）物理机：需要有专业的运维人员（1万*13个月）、电费（商业用户）、安装空调

（2）云主机：很多运维工作都由阿里云已经完成，运维相对较轻松

3）企业选择

（1）金融有钱公司和阿里没有直接冲突的公司选择阿里云（上海）

（2）中小公司、为了融资上市，选择阿里云，拉倒融资后买物理机。

（3）有长期打算，资金比较足，选择物理机。

2.6 集群规模

大数据技术之高频面试题_第46张图片

 

20核物理CPU  40线程  * 7 = 280线程

内存128g * 7台 = 896g

128m =》1g内存    =》87g数据 、700g内存

根据数据规模大家集群

1

2

3

4

5

6

7

8

9

10

nn

nn

dn

dn

dn

dn

dn

dn

dn

dn

 

 

rm

rm

nm

nm

nm

nm

nm

nm

 

 

nm

nm

 

 

 

 

 

 

 

 

 

 

 

 

 

zk

zk

zk

 

 

 

 

 

 

 

kafka

kafka

kafka

 

 

 

 

 

 

 

Flume

Flume

flume

 

 

Hbase

Hbase

Hbase

 

 

 

 

 

hive

hive

 

 

 

 

 

 

 

 

mysql

mysql

 

 

 

 

 

 

 

 

spark

spark

 

 

 

 

 

 

 

 

 

 

 

 

 

ES

ES

 

 

 

2.7 人员配置参考

2.7.1 整体架构

属于研发部/技术部/数据部，我们属于大数据组，其他还有后端项目组，前端组、测试组、UI组等。其他的还有产品部、运营部、人事部、财务部、行政部等。

大数据开发工程师=>大数据组组长=》项目经理=>部门经理=》技术总监CTO

2.7.2 你们部门的职级等级，晋升规则

职级就分初级，中级，高级。晋升规则不一定，看公司效益和职位空缺。

京东：T1、T2应届生；T3 14k左右   T4 18K左右  T5  24k-28k左右

阿里：p5、p6、p7、p8

2.7.3 人员配置参考

小型公司（3人左右）：组长1人，剩余组员无明确分工，并且可能兼顾javaEE和前端。

中小型公司（3~6人左右）：组长1人，离线2人左右，实时1人左右（离线一般多于实时），组长兼顾和javaEE、前端。

中型公司（5~10人左右）：组长1人，离线3~5人左右（离线处理、数仓），实时2人左右，组长和技术大牛兼顾和javaEE、前端。

中大型公司（10~20人左右）：组长1人，离线5~10人（离线处理、数仓），实时5人左右，JavaEE1人左右（负责对接JavaEE业务），前端1人（有或者没有人单独负责前端）。（发展比较良好的中大型公司可能大数据部门已经细化拆分，分成多个大数据组，分别负责不同业务）

上面只是参考配置，因为公司之间差异很大，例如ofo大数据部门只有5个人左右，因此根据所选公司规模确定一个合理范围，在面试前必须将这个人员配置考虑清楚，回答时要非常确定。

IOS多少人 安卓多少人 前端多少人  JavaEE多少人  测试多少人

（IOS、安卓） 1-2个人   前端1-3个人； JavaEE一般是大数据的1-1.5倍，测试：有的有，有的没有。1个左右。  产品经理1个、产品助理1-2个，运营1-3个

公司划分：

0-50 小公司

50-500 中等

500-1000 大公司

1000以上 大厂 领军的存在

你写项目，肯定是有一家公司的，公司的基本信息你得了解清楚，包括（老板是谁，业务，盈利情况，规模，地点，通勤，部门，这个组多少人....），该如何查，百度，天眼查之类的公司....

说话的时候，一定非常自信（给人的感觉我做过，我能搞定），不要很冲，基本的礼仪，不要过度吹捧，最好的平等，不要胆怯，不要猥琐...

 

 

第3章 数仓分层

3.1 ODS层做了哪些事？

1）保持数据原貌，不做任何修改

2）压缩采用LZO，压缩比是100g数据压缩完10g左右。

3）创建分区表

3.2 DWD层做了哪些事？

3.2.1 数据清洗

（1）空值去除

（2）过滤核心字段无意义的数据，比如订单表中订单id为null，支付表中支付id为空

（3）将用户行为宽表和业务表进行数据一致性处理

select case when a is null then b else a end as JZR,

    ...

from A

3.2.2 清洗的手段

Sql、mr、rdd、kettle、Python（项目中采用sql进行清除）

3.2.3 清洗掉多少数据算合理

1万条数据清洗掉1条。

3.2.4 脱敏

对手机号、身份证号等敏感数据脱敏

3.2.5 维度退化

对业务数据传过来的表进行维度退化和降维。（商品一级二级三级、省市县、年月日）

针对业务数据，做维度建模....

3.2.6 压缩LZO

3.2.7 列式存储parquet

3.3 DWS层做了哪些事？

3.3.1 DWS层有3-5张宽表（处理100-200个指标   70%以上的需求）

具体宽表名称：用户行为宽表，用户购买商品明细行为宽表，商品宽表，购物车宽表，物流宽表、登录注册、售后等。

3.3.2 哪个宽表最宽？大概有多少个字段？

最宽的是用户行为宽表。大概有60-100个字段

3.3.3 具体用户行为宽表字段名称

评论、打赏、收藏、关注--商品、关注--人、点赞、分享、好价爆料、文章发布、活跃、签到、补签卡、幸运屋、礼品、金币、电商点击、gmv

CREATE TABLE `app_usr_interact`(

  `stat_dt` date COMMENT '互动日期',

  `user_id` string COMMENT '用户id',

  `nickname` string COMMENT '用户昵称',

  `register_date` string COMMENT '注册日期',

  `register_from` string COMMENT '注册来源',

  `remark` string COMMENT '细分渠道',

  `province` string COMMENT '注册省份',

  `pl_cnt` bigint COMMENT '评论次数',

  `ds_cnt` bigint COMMENT '打赏次数',

  `sc_add` bigint COMMENT '添加收藏',

  `sc_cancel` bigint COMMENT '取消收藏',

  `gzg_add` bigint COMMENT '关注商品',

  `gzg_cancel` bigint COMMENT '取消关注商品',

  `gzp_add` bigint COMMENT '关注人',

  `gzp_cancel` bigint COMMENT '取消关注人',

  `buzhi_cnt` bigint COMMENT '点不值次数',

  `zhi_cnt` bigint COMMENT '点值次数',

  `zan_cnt` bigint COMMENT '点赞次数',

  `share_cnts` bigint COMMENT '分享次数',

  `bl_cnt` bigint COMMENT '爆料数',

  `fb_cnt` bigint COMMENT '好价发布数',

  `online_cnt` bigint COMMENT '活跃次数',

  `checkin_cnt` bigint COMMENT '签到次数',

  `fix_checkin` bigint COMMENT '补签次数',

  `house_point` bigint COMMENT '幸运屋金币抽奖次数',

  `house_gold` bigint COMMENT '幸运屋积分抽奖次数',

  `pack_cnt` bigint COMMENT '礼品兑换次数',

  `gold_add` bigint COMMENT '获取金币',

  `gold_cancel` bigint COMMENT '支出金币',

  `surplus_gold` bigint COMMENT '剩余金币',

  `event` bigint COMMENT '电商点击次数',

  `gmv_amount` bigint COMMENT 'gmv',

  `gmv_sales` bigint COMMENT '订单数')

PARTITIONED BY (  `dt` string)

3.4 ADS层分析过哪些指标

3.4.1 分析过的指标（一分钟至少说出30个指标）

日活、月活、周活、留存、留存率、新增（日、周、年）、转化率、流失、回流、七天内连续3天登录（点赞、收藏、评价、购买、加购、下单、活动）、连续3周（月）登录、GMV、复购率、复购率排行、点赞、评论、收藏、领优惠价人数、使用优惠价、沉默、值不值得买、退款人数、退款率  topn  热门商品

    产品经理最关心的：留转G复活

大数据技术之高频面试题_第47张图片

 

3.4.2 留转G复活指标

（1）活跃

日活：100万 ；月活：是日活的2-3倍  300万

总注册的用户多少？1000万-3000万之间

（2）GMV

GMV：每天 10万订单 （50 – 100元） 500万-1000万

10%-20%  100万-200万（人员：程序员）

（3）复购率

某日常商品复购；（手纸、面膜、牙膏）10%-20%

    电脑、显示器、手表  1%

（4）转化率(漏斗模型)

     商品详情  =》  加购物车  =》下单   =》  支付

       5%-10%          60-70%     90%-95%  

（5）留存率

     1/2/3、周留存、月留存

     搞活动：  10-20%

3.4.3 哪个商品卖的好？

面膜、手纸，每天销售5000个

3.5 ADS层手写指标

3.5.1 如何分析用户活跃？

在启动日志中统计不同设备id出现次数。

3.5.2 如何分析用户新增？vivo

用活跃用户表 left join 用户新增表，用户新增表中mid为空的即为用户新增。

3.5.3 如何分析用户1天留存？

留存用户=前一天新增 join 今天活跃

用户留存率=留存用户/前一天新增

3.5.4 如何分析沉默用户？

(登录时间为7天前,且只出现过一次)

按照设备id对日活表分组，登录次数为1，且是在一周前登录。

3.5.5 如何分析本周回流用户？

本周活跃left join本周新增 left join上周活跃，且本周新增id和上周活跃id都为null

3.5.6 如何分析流失用户？

(登录时间为7天前)

按照设备id对日活表分组，且七天内没有登录过。

3.5.7 如何分析最近连续3周活跃用户数？

按照设备id对周活进行分组，统计次数大于3次。

3.5.8 如何分析最近七天内连续三天活跃用户数？

1）查询出最近7天的活跃用户，并对用户活跃日期进行排名

2）计算用户活跃日期及排名之间的差值

3）对同用户及差值分组，统计差值个数

4）将差值相同个数大于等于3的数据取出，然后去重(去的是什么重???)，即为连续3天及以上活跃的用户

7天连续收藏、点赞、购买、加购、付款、浏览、商品点击、退货

1个月连续7天

连续两周：

3.6 分析过最难的指标

3.6.1 最近连续3周活跃用户

大数据技术之高频面试题_第48张图片

 

3.6.2 最近7天连续3天活跃用户数

大数据技术之高频面试题_第49张图片

 

3.7 数据仓库建模（绝对重点）

3.7.1 建模工具是什么？

PowerDesigner/SQLYog/EZDML

3.7.2 ODS层

（1）保持数据原貌不做任何修改，起到备份数据的作用。

（2）数据采用压缩，减少磁盘存储空间（例如：原始数据100G，可以压缩到10G左右）

（3）创建分区表，防止后续的全表扫描

3.7.3 DWD层

DWD层需构建维度模型，一般采用星型模型，呈现的状态一般为星座模型。

维度建模一般按照以下四个步骤：

选择业务过程→声明粒度→确认维度→确认事实

（1）选择业务过程

在业务系统中，如果业务表过多，挑选我们感兴趣的业务线，比如下单业务，支付业务，退款业务，物流业务，一条业务线对应一张事实表。如果小公司业务表比较少，建议选择所有业务线。

（2）声明粒度

数据粒度指数据仓库的数据中保存数据的细化程度或综合程度的级别。

声明粒度意味着精确定义事实表中的一行数据表示什么，应该尽可能选择最小粒度，以此来应各种各样的需求。

典型的粒度声明如下：

订单当中的每个商品项作为下单事实表中的一行，粒度为每次

每周的订单次数作为一行，粒度为每周。

每月的订单次数作为一行，粒度为每月。

如果在DWD层粒度就是每周或者每月，那么后续就没有办法统计细粒度的指标了。所有建议采用最小粒度。

（3）确定维度

维度的主要作用是描述业务是事实，主要表示的是“谁，何处，何时”等信息。例如：时间维度、用户维度、地区维度等常见维度。

（4）确定事实

此处的“事实”一词，指的是业务中的度量值，例如订单金额、下单次数等。

在DWD层，以业务过程为建模驱动，基于每个具体业务过程的特点，构建最细粒度的明细层事实表。事实表可做适当的宽表化处理。

通过以上步骤，结合本数仓的业务事实，得出业务总线矩阵表如下表所示。业务总线矩阵的原则，主要是根据维度表和事实表之间的关系，如果两者有关联则使用√标记。

表  业务总线矩阵表

 

时间

用户

地区

商品

优惠券

活动

编码

度量值

订单

√

√

√

 

 

√

 

件数/金额

订单详情

√

 

√

√

 

 

 

件数/金额

支付

√

 

√

 

 

 

 

次数/金额

加购

√

√

 

√

 

 

 

件数/金额

收藏

√

√

 

√

 

 

 

个数

评价

√

√

 

√

 

 

 

个数

退款

√

√

 

√

 

 

 

件数/金额

优惠券领用

√

√

 

 

√

 

 

个数

 

根据维度建模中的星型模型思想，将维度进行退化。例如下图所示：地区表和省份表退化为地区维度表，商品表、品类表、spu表、商品三级分类、商品二级分类、商品一级分类表退化为商品维度表，活动信息表和活动规则表退化为活动维度表。

大数据技术之高频面试题_第50张图片

 

至此，数仓的维度建模已经完毕，DWS、DWT和ADS和维度建模已经没有关系了。

DWS和DWT都是建宽表，宽表都是按照主题去建。主题相当于观察问题的角度。对应着维度表。

3.7.4 DWS层

DWS层统计各个主题对象的当天行为，服务于DWT层的主题宽表。如图所示，DWS层的宽表字段，是站在不同维度的视角去看事实表，重点关注事实表的度量值，通过与之关联的事实表，获得不同的事实表的度量值。

 

3.7.5 DWT层

以分析的主题对象为建模驱动，基于上层的应用和产品的指标需求，构建主题对象的全量宽表。

DWT层主题宽表都记录什么字段？

如图所示，每个维度关联的不同事实表度量值以及首次、末次时间、累积至今的度量值、累积某个时间段的度量值。

大数据技术之高频面试题_第51张图片

 

3.7.6 ADS层

分别对设备主题、会员主题、商品主题和营销主题进行指标分析，其中营销主题是用户主题和商品主题的跨主题分析案例

 

第4章 生产经验—业务

4.1 电商常识

4.1.1 SKU和SPU

SKU：一台银色、128G内存的、支持联通网络的iPhoneX

SPU：iPhoneX

Tm_id：品牌Id苹果，包括IPHONE，耳机，mac等

4.1.2 订单表跟订单详情表区别？

订单表的订单状态会变化，订单详情表不会，因为没有订单状态。

订单表记录user_id，订单id订单编号，订单的总金额order_status，支付方式，订单状态等。

订单详情表记录user_id，商品sku_id ,具体的商品信息（商品名称sku_name，价格order_price，数量sku_num）

4.2 埋点行为数据基本格式(基本字段)

我们要收集和分析的数据主要包括页面数据、事件数据、曝光数据、启动数据和错误数据。

4.2.1 页面

页面数据主要记录一个页面的用户访问情况，包括访问时间、停留时间、页面路径等信息。

大数据技术之高频面试题_第52张图片

 

所有页面id如下

home("首页"),

category("分类页"),

discovery("发现页"),

top_n("热门排行"),

favor("收藏页"),

search("搜索页"),

good_list("商品列表页"),

good_detail("商品详情"),

good_spec("商品规格"),

comment("评价"),

comment_done("评价完成"),

comment_list("评价列表"),

cart("购物车"),

trade("下单结算"),

payment("支付页面"),

payment_done("支付完成"),

orders_all("全部订单"),

orders_unpaid("订单待支付"),

orders_undelivered("订单待发货"),

orders_unreceipted("订单待收货"),

orders_wait_comment("订单待评价"),

mine("我的"),

activity("活动"),

login("登录"),

register("注册");

所有页面对象类型如下：

sku_id("商品skuId"),

keyword("搜索关键词"),

sku_ids("多个商品skuId"),

activity_id("活动id"),

coupon_id("购物券id");

所有来源类型如下：

promotion("商品推广"),

recommend("算法推荐商品"),

query("查询结果商品"),

activity("促销活动");

4.2.2 事件

事件数据主要记录应用内一个具体操作行为，包括操作类型、操作对象、操作对象描述等信息。

大数据技术之高频面试题_第53张图片

 

所有动作类型如下：

favor_add("添加收藏"),

favor_canel("取消收藏"),

cart_add("添加购物车"),

cart_remove("删除购物车"),

cart_add_num("增加购物车商品数量"),

cart_minus_num("减少购物车商品数量"),

trade_add_address("增加收货地址"),

get_coupon("领取优惠券");

注：对于下单、支付等业务数据，可从业务数据库获取。

所有动作目标类型如下：

sku_id("商品"),

coupon_id("购物券");

4.2.3 曝光

曝光数据主要记录页面所曝光的内容，包括曝光对象，曝光类型等信息。

大数据技术之高频面试题_第54张图片

 

所有曝光类型如下：

promotion("商品推广"),
recommend("算法推荐商品"),
query("查询结果商品"),
activity("促销活动");

所有曝光对象类型如下：

sku_id("商品skuId"),

activity_id("活动id");

4.2.4 启动

启动数据记录应用的启动信息。

大数据技术之高频面试题_第55张图片

 

所有启动入口类型如下：

icon("图标"),
notification("通知"),
install("安装后启动");

4.2.5 错误

错误数据记录应用使用过程中的错误信息，包括错误编号及错误信息。

4.2.6 埋点数据日志格式

我们的日志结构大致可分为两类，一是普通页面埋点日志，二是启动日志。

普通页面日志结构如下，每条日志包含了，当前页面的页面信息，所有事件（动作）、所有曝光信息以及错误信息。除此之外，还包含了一系列公共信息，包括设备信息，地理位置，应用信息等，即下边的common字段。

{

  "common": {                  -- 公共信息

    "ar": "230000",              -- 地区编码

    "ba": "iPhone",              -- 手机品牌

    "ch": "Appstore",            -- 渠道

    "md": "iPhone 8",            -- 手机型号

    "mid": "YXfhjAYH6As2z9Iq", -- 设备id

    "os": "iOS 13.2.9",          -- 操作系统

    "uid": "485",                 -- 会员id

    "vc": "v2.1.134"             -- app版本号

  },

"actions": [                     --动作(事件)  

    {

      "action_id": "favor_add",   --动作id

      "item": "3",                   --目标id

      "item_type": "sku_id",       --目标类型

      "ts": 1585744376605           --动作时间戳

    }

  ]，

  "displays": [

    {

      "displayType": "query",        -- 曝光类型

      "item": "3",                     -- 曝光对象id

      "item_type": "sku_id",         -- 曝光对象类型

      "order": 1                        --出现顺序

    },

    {

      "displayType": "promotion",

      "item": "6",

      "item_type": "sku_id",

      "order": 2

    },

    {

      "displayType": "promotion",

      "item": "9",

      "item_type": "sku_id",

      "order": 3

    },

    {

      "displayType": "recommend",

      "item": "6",

      "item_type": "sku_id",

      "order": 4

    },

    {

      "displayType": "query ",

      "item": "6",

      "item_type": "sku_id",

      "order": 5

    }

  ],

  "page": {                       --页面信息

    "during_time": 7648,        -- 持续时间毫秒

    "item": "3",                  -- 目标id

    "item_type": "sku_id",      -- 目标类型

    "last_page_id": "login",    -- 上页类型

    "page_id": "good_detail",   -- 页面ID

    "sourceType": "promotion"   -- 来源类型

  },

"err":{                     --错误

"error_code": "1234",      --错误码

    "msg": "***********"       --错误信息

},

  "ts": 1585744374423  --跳入时间戳

}

启动日志结构相对简单，主要包含公共信息，启动信息和错误信息。

{

  "common": {

    "ar": "370000",

    "ba": "Honor",

    "ch": "wandoujia",

    "md": "Honor 20s",

    "mid": "eQF5boERMJFOujcp",

    "os": "Android 11.0",

    "uid": "76",

    "vc": "v2.1.134"

  },

  "start": {   

    "entry": "icon",         --icon手机图标  notice 通知   install 安装后启动

    "loading_time": 18803,  --启动加载时间

    "open_ad_id": 7,        --广告页ID

    "open_ad_ms": 3449,    -- 广告总共播放时间

    "open_ad_skip_ms": 1989   --  用户跳过广告时点

  },

"err":{                     --错误

"error_code": "1234",      --错误码

    "msg": "***********"       --错误信息

},

  "ts": 1585744304000

}

4.3 电商业务流程

1）记住表与表之间的关系

2）每个表记住2-3个字段

大数据技术之高频面试题_第56张图片

 

4.4 维度表和事实表（重点）

4.4.1 维度表

维度表：一般是对事实的描述信息。每一张维表对应现实世界中的一个对象或者概念。    例如：用户、商品、日期、地区等。

4.4.2 事实表

事实表中的每行数据代表一个业务事件（下单、支付、退款、评价等）。“事实”这个术语表示的是业务事件的度量值（可统计次数、个数、件数、金额等），例如，订单事件中的下单金额。

每一个事实表的行包括：具有可加性的数值型的度量值、与维表相连接的外键、通常具有两个和两个以上的外键、外键之间表示维表之间多对多的关系。

1）事务型事实表

以每个事务或事件为单位，例如一个销售订单记录，一笔支付记录等，作为事实表里的一行数据。一旦事务被提交，事实表数据被插入，数据就不再进行更改，其更新方式为增量更新。  

2）周期型快照事实表

周期型快照事实表中不会保留所有数据，只保留固定时间间隔的数据，例如每天或者每月的销售额，或每月的账户余额等。

3）累积型快照事实表

累计快照事实表用于跟踪业务事实的变化。例如，数据仓库中可能需要累积或者存储订单从下订单开始，到订单商品被打包、运输、和签收的各个业务阶段的时间点数据来跟踪订单声明周期的进展情况。当这个业务过程进行时，事实表的记录也要不断更新。

订单id

用户id

下单时间

打包时间

发货时间

签收时间

订单金额

 

 

3-8

3-8

3-9

3-10

 

4.5 同步策略（重点）

大数据技术之高频面试题_第57张图片

 

实体表，维度表统称维度表，每日全量或者每月（更长时间）全量

事务型事实表：每日增量

周期性事实表：拉链表

4.6 关系型数据库范式理论

1NF：属性不可再分割（例如不能存在5台电脑的属性，坏处：表都没法用）

2NF：不能存在部分函数依赖（例如主键（学号+课名）-->成绩，姓名，但学号--》姓名，所以姓名部分依赖于主键（学号+课名），所以要去除，坏处：数据冗余）

3NF：不能存在传递函数依赖（学号--》宿舍种类--》价钱，坏处：数据冗余和增删异常）

MySQL关系模型：关系模型主要应用与OLTP系统中，为了保证数据的一致性以及避免冗余，所以大部分业务系统的表都是遵循第三范式的。

Hive 维度模型：维度模型主要应用于OLAP系统中，因为关系模型虽然冗余少，

但是在大规模数据，跨表分析统计查询过程中，会造成多表关联，这会大大降低执行效率。

所以HIVE把相关各种表整理成两种：事实表和维度表两种。所有维度表围绕着事实表进行解释。

4.7 数据模型

雪花模型、星型模型和星座模型

（在维度建模的基础上又分为三种模型：星型模型、雪花模型、星座模型。）

星型模型（一级维度表），雪花（多级维度），星座模型（星型模型+多个事实表）

4.8 拉链表（重点）

拉链表处理的业务场景：主要处理缓慢变化维的业务场景。（用户表、订单表）

大数据技术之高频面试题_第58张图片

 

4.9 即席查询数据仓库

 

大数据技术之高频面试题_第59张图片

 

Kylin:  T+1

Impala:  CDH

Presto:  Apache版本框架

4.10 数据仓库每天跑多少张表，大概什么时候运行，运行多久？

基本一个项目建一个库，表格个数为初始的原始数据表格加上统计结果表格的总数。（一般70-100张表格）

用户行为11张；业务数据27张表 =》ods 38 =》dwd=>32张=》dws 6张宽表=>ads=》30张 =》106张

每天0：30开始运行。=》sqoop  40-50分钟：1点20：=》 5-6个小时运行完指标

所有离线数据报表控制在8小时之内

大数据实时处理部分控制在5分钟之内。（分钟级别、秒级别）

如果是实时推荐系统，需要秒级响应

4.11 活动的话，数据量会增加多少？怎么解决？

日活增加50%，GMV增加多少。（留转G复活）情人节，促销手纸。

集群资源都留有预量。11.11，6.18，数据量过大，提前动态增加服务器。

4.12 并发峰值多少？大概哪个时间点？ 

高峰期晚上7-8点。Kafka里面20m/s   2万/s  并发峰值在1-2万人

4.13 数仓中使用的哪种文件存储格式

常用的包括：textFile，rcFile，ORC，Parquet，一般企业里使用ORC或者Parquet，因为是列式存储，且压缩比非常高，所以相比于textFile，查询速度快，占用硬盘空间少

4.14 哪张表最费时间，有没有优化

用户行为宽表，数据量过大。数据倾斜的相关优化手段。（hadoop、hive、spark）

4.15 用什么工具做权限管理

Ranger或Sentry  （用户认证kerberos（张三、李四、王五）=>表级别权限（张三、李四）、字段级别权限（李四））

 

第5章 生产经验--测试上线相关

5.1 测试相关

5.1.1 公司有多少台测试服务器？

测试服务器一般三台

5.1.2 测试环境什么样？

有钱的公司和生产环境电脑配置一样。

一般公司测试环境的配置是生产的一半（内存和磁盘可以减半）

5.1.3 测试数据哪来的？

一部分自己写Java程序自己造（更灵活），一部分从生产环境上取一部分（更真实）。

5.1.4 如何保证写的sql正确性

需要造一些特定的测试数据，测试。

从生产环境抓取一部分数据，数据有多少你是知道的，运算完毕应该符合你的预期。

离线数据和实时数据分析的结果比较。（日活1万  实时10100），倾向取离线。

先在mysql的业务库里面把结果计算出来；在给你在ads层计算的结果进行比较；

5.1.5 测试之后如何上线？

大公司：上线的时候，将脚本打包，提交git。先发邮件抄送经理和总监，运维。运维负责上线。

小公司：跟项目经理说一下，项目经理技术把关，项目经理通过了就可以上线了。风险意识。

5.2 项目实际工作流程

以下是活跃用户需求的整体开发流程。

第1步：确定指标的业务口径  

由产品经理主导，找到提出该指标的运营负责人沟通。首先要问清楚指标是怎么定义的，比如活跃用户是指启动过APP的用户。设备id 还是用户id。

邮件/需求文档-》不要口头

第2步：需求评审

由产品经理主导设计原型，对于活跃主题，我们最终要展示的是最近n天的活跃用户数变化趋势 ，效果如下图所示。此处大数据开发工程师、后端开发工程师、前端开发工程师一同参与，一起说明整个功能的价值和详细的操作流程，确保大家理解的一致。

大数据技术之高频面试题_第60张图片

 

第3步：大数据开发

大数据开发工程师，通过数据同步的工具如Flume、Sqoop等将数据同步到ODS层，然后就是一层一层的通过SQL计算到DWD、DWS层，最后形成可为应用直接服务的数据填充到ADS层。

第4步：后端开发

后端工程师负责，为大数据工程师提供业务数据接口；

同时还负责读取ADS层分析后，写入MySQL中的数据。

第5步：前端开发

前端工程师负责，前端埋点。

对分析后的结果数据进行可视化展示。

第6步：联调

此时数据开发工程师、前端开发工程师、后端开发工程师都要参与进来。此时会要求大数据开发工程师基于历史的数据执行计算任务，大数据开发工程师承担数据准确性的校验。前后端解决用户操作的相关BUG保证不出现低级的问题完成自测。

第7步：测试

测试工程师对整个大数据系统进行测试。测试的手段包括，边界值、等价类等。

提交测试异常的软件有：禅道、bugzila（测试人员记录测试问题1.0，输入是什么，结果是什么，跟预期不一样->需要开发人员解释，是一个bug，下一个版本解决1.1->测试人员再测试。测试1.1ok->测试经理关闭bug）  

1.2.3

1重大项目升级

2核心模块的变化

3普通变化

第8步：上线

运维工程师会配合我们的前后端开发工程师更新最新的版本到服务器。此时产品经理要找到该指标的负责人长期跟进指标的准确性。重要的指标还要每过一个周期内部再次验证，从而保证数据的准确性。

5.3 项目中实现一个需求大概多长时间

刚入职第一个需求大概需要7天左右。

对业务熟悉后，平均一天一个需求。

影响时间的因素：测试服务器购买获取环境准备、对业务熟悉、开会讨论需求、表的权限申请、测试等。新员工培训（公司规章制度、代码规范）

5.4 项目在3年内迭代次数，每一个项目具体是如何迭代的。公司版本迭代多久一次，迭代到哪个版本

瀑布式开发、敏捷开发

差不多一个月会迭代一次。每月都有节日（元旦、春节、情人节、3.8妇女节、端午节、618、国庆、中秋、1111/6.1/5.1、生日、周末）新产品、新区域

就产品或我们提出优化需求，然后评估时间。每周我们都会开会做下周计划和本周总结。（日报、周报、月报、季度报、年报）需求1周的时间，周三一定完成。周四周五（帮同事写代码、自己学习工作额外的技术）

有时候也会去预研一些新技术。Flink  hudi

5.1.2

5是大版本号：必须是重大升级

1：一般是核心模块变动

2：一般版本变化

5.5 项目开发中每天做什么事

 

1）新需求（活动、优化、新产品、新市场）。

2）故障分析：数仓的任何步骤出现问题，需要查看问题，比如日活，月活下降或快速上升等。

3）新技术的预言（比如flink、数仓建模、数据质量、元数据管理）

4）晨会-》10做操-》讨论中午吃什么-》12点出去吃1点-》睡到2点-》3点茶歇水果-》晚上吃啥-》吃加班餐-》开会-》晚上6点吃饭-》7点开始干活-10点-》11点

5.6 实时项目数据计算

5.6.1 跑实时任务，怎么分配内存和CPU资源

128m数据对应1g内存

1个Kafka分区对应1个CPU

5.6.2 跑实时任务，每天数据量多少？

用户行为：实时任务用到了用户行为多少张表（10g）  

业务数据：实时任务用到了业务数据多少张表(34m)  

活动、风控、销售、流量

 

 

第6章 生产经验—技术

6.1 可视化报表工具

Echarts（百度开源）、kibana（开源）、Tableau（功能强大的收费软件）、Superset（功能一般免费）、QuickBI（阿里云收费的离线）、DataV（阿里云收费的实时）

6.2 集群监控工具

Zabbix+ Grafana

6.3 项目中遇到的问题怎么解决的（重点*****）

Shell 中flume停止脚本

 

Hadoop宕机

Hadoop解决数据倾斜方法

集群资源分配参数（项目中遇到的问题）

HDFS小文件处理

Hadoop优化

 

Flume挂掉

Flume优化

 

Kafka挂掉

Kafka丢失

Kafka数据重复

Kafka消息数据积压

Kafka优化

Kafka单条日志传输大小

 

自定义UDF、UDTF函数

Hive优化

Hive解决数据倾斜方法

7天内连续3次活跃

 

Sqoop空值、一致性、数据倾斜

 

Azkaban任务挂了怎么办？

Azkaban故障报警

 

Spark数据倾斜

Spark优化

SparkStreaming精确一次性消费

6.4 Linux+Shell+Hadoop+ZK+Flume+kafka+Hive+Sqoop+Azkaban那些事

大数据技术之高频面试题_第61张图片

 

 

 

 

第7章 生产经验—热点问题

7.1 元数据管理（Atlas血缘系统）

依赖关系能够做到：表级别和字段级别

用处：作业执行失败，评估他的影响范围。 主要用于表比较多的公司。

版本问题：

0.84版本：2019-06-21

2.0版本：2019-05-13

框架版本：

Apache   0.84    2.0

CDH  2.0    

7.2 数据质量监控（Griffin）

7.2.1 为什么要做数据质量监控（2019年下半年）

1)数据不一致

企业早期没有进行统一规划设计，大部分信息系统是逐步迭代建设的，系统建设时间长短各异，各系统数据标准也不同。企业业务系统更关注业务层面，各个业务系统均有不同的侧重点，各类数据的属性信息设置和要求不统一。

2)数据不完整

由于企业没有统一的录入工具和数据出口，业务系统不需要的信息就不录，造成同样的数据在不同的系统有不同的属性信息，数据完整性无法得到保障。

3)数据不合规

没有统一的数据管理平台和数据源头，数据全生命周期管理不完整，同时企业各信息系统的数据录入环节过于简单且手工参与较多，就数据本身而言，缺少是否重复、合法、对错等校验环节，导致各个信息系统的数据不够准确，格式混乱，各类数据难以集成和统一，没有质量控制导致海量数据因质量过低而难以被利用，且没有相应的数据管理流程。

4)数据不可控

企业各单位和部门关注数据的角度不一样，缺少一个组织从全局的视角对数据进行管理，导致无法建立统一的数据管理标准、流程等，相应的数据管理制度、办法等无法得到落实。同时，企业基础数据质量考核体系也尚未建立，无法保障一系列数据标准、规范、制度、流程得到长效执行。

5)数据冗余

各个信息系统针对数据的标准规范不一、编码规则不一、校验标准不一，且部分业务系统针对数据的验证标准严重缺失，造成了企业顶层视角的数据出现“一物多码”、“一码多物”等现象。

7.2.2 建设方法

大数据技术之高频面试题_第62张图片

 

质量监管平台建设，主要包含如下8大流程步骤：

质量需求：发现数据问题；信息提报、收集需求；检核规则的需求等；

提炼规则：梳理规则指标、确定有效指标、检核指标准确度和衡量标准；

规则库构建：检核对象配置、调度配置、规则配置、检核范围确认、检核标准确定等；

执行检核：调度配置、调度执行、检核代码；

问题检核：检核问题展示、分类、质量分析、质量严重等级分类等；

分析报告：数据质量报告、质量问题趋势分析，影响度分析，解决方案达成共识；

落实处理：方案落实执行、跟踪管理、解决方案Review及标准化提炼；

知识库体系形成：知识经验总结、标准方案沉淀、知识库体系建设。

7.2.3 监控指标

1）单表数据量监控

一张表的记录数在一个已知的范围内，或者上下浮动不会超过某个阈值

    1. SQL结果：var 数据量 = select count（*）from 表 where 时间等过滤条件
    2. 报警触发条件设置：如果数据量不在[数值下限, 数值上限]， 则触发报警
    3. 同比增加：如果((本周的数据量 - 上周的数据量)/上周的数据量*100)不在 [比例下线，比例上限]，则触发报警
    4. 环比增加：如果((今天的数据量 - 昨天的数据量)/昨天的数据量*100)不在 [比例下线，比例上限]，则触发报警
    5. 报警触发条件设置一定要有。如果没有配置的阈值，不能做监控

日活、周活、月活、留存（日周月）、转化率（日、周、月）GMV（日、周、月）

复购率（日周月）  30%

2）单表空值检测

某个字段为空的记录数在一个范围内，或者占总量的百分比在某个阈值范围内

    1. 目标字段：选择要监控的字段，不能选“无”
    2. SQL结果：var 异常数据量 = select count(*) from 表 where 目标字段 is null
    3. 单次检测：如果(异常数据量)不在[数值下限, 数值上限]，则触发报警

3）单表重复值检测

一个或多个字段是否满足某些规则

    1. 目标字段：第一步先正常统计条数；select count(*) form 表；
    2. 第二步，去重统计；select count(*) from 表 group by 某个字段
    3. 第一步的值和第二步不的值做减法，看是否在上下线阀值之内
    4. 单次检测：如果(异常数据量)不在[数值下限, 数值上限]， 则触发报警

4）单表值域检测

一个或多个字段没有重复记录

    1. 目标字段：选择要监控的字段，支持多选
    2. 检测规则：填写“目标字段”要满足的条件。其中$1表示第一个目标字段，$2表示第二个目标字段，以此类推。上图中的“检测规则”经过渲染后变为“delivery_fee = delivery_fee_base+delivery_fee_extra”
    3. 阈值配置与“空值检测”相同

5）跨表数据量对比

主要针对同步流程，监控两张表的数据量是否一致

    1. SQL结果：count(本表) - count(关联表)
    2. 阈值配置与“空值检测”相同

7.3 数据治理

包括：数据质量管理、元数据管理、权限管理（ranger sentry）。

CDH cloudmanager-》sentry； HDP  ambari=>ranger

数据治理是一个复杂的系统工程，涉及到企业和单位多个领域，既要做好顶层设计，又要解决好统一标准、统一流程、统一管理体系等问题，同时也要解决好数据采集、数据清洗、数据对接和应用集成等相关问题。

数据治理实施要点主要包含数据规划、制定数据标准、整理数据、搭建数据管理工具、构建运维体系及推广贯标六大部分，其中数据规划是纲领、制定数据标准是基础、整理数据是过程、搭建数据管理工具是技术手段、构建运维体系是前提，推广贯标是持续保障。

 

大数据技术之高频面试题_第63张图片

7.4 数据中台

https://mp.weixin.qq.com/s/nXI0nSSOneteIClA7dming

7.4.1 什么是中台？

在传统IT企业，项目的物理结构是什么样的呢？无论项目内部的如何复杂，都可分为“前台”和“后台”这两部分。

什么是前台？

首先，这里所说的“前台”和“前端”并不是一回事。所谓前台即包括各种和用户直接交互的界面，比如web页面，手机app；也包括服务端各种实时响应用户请求的业务逻辑，比如商品查询、订单系统等等。

什么是后台？

后台并不直接面向用户，而是面向运营人员的配置管理系统，比如商品管理、物流管理、结算管理。后台为前台提供了一些简单的配置。

大数据技术之高频面试题_第64张图片

 

7.4.2 传统项目痛点

痛点：重复造轮子。

大数据技术之高频面试题_第65张图片

 

7.4.3 各家中台

1）SuperCell公司

大数据技术之高频面试题_第66张图片

 

2）阿里巴巴提出了“大中台，小前台”的战略

大数据技术之高频面试题_第67张图片

 

3）华为提出了“平台炮火支撑精兵作战”的战略

大数据技术之高频面试题_第68张图片

 

7.4.4 中台具体划分

1）业务中台

大数据技术之高频面试题_第69张图片

 

2）技术中台

大数据技术之高频面试题_第70张图片

 

3）数据中台

大数据技术之高频面试题_第71张图片

 

4）算法中台

大数据技术之高频面试题_第72张图片

 

7.4.5 中台使用场景

1）从0到1的阶段，没有必要搭建中台。

从0到1的创业型公司，首要目的是生存下去，以最快的速度打造出产品，证明自身的市场价值。

这个时候，让项目野蛮生长才是最好的选择。如果不慌不忙地先去搭建中台，恐怕中台还没搭建好，公司早就饿死了。

2）从1到N的阶段，适合搭建中台。

当企业有了一定规模，产品得到了市场的认可，这时候公司的首要目的不再是活下去，而是活的更好。

这个时候，趁着项目复杂度还不是特别高，可以考虑把各项目的通用部分下沉，组建中台，以方便后续新项目的尝试和旧项目的迭代。

3）从N到N+1的阶段，搭建中台势在必行。

当企业已经有了很大的规模，各种产品、服务、部门错综复杂，这时候做架构调整会比较痛苦。

但是长痛不如短痛，为了项目的长期发展，还是需要尽早调整架构，实现平台化，以免日后越来越难以维护。

7.5 数据湖

数据湖（Data Lake）是一个存储企业的各种各样原始数据的大型仓库，其中的数据可供存取、处理、分析及传输。

目前，Hadoop是最常用的部署数据湖的技术，所以很多人会觉得数据湖就是Hadoop集群。数据湖是一个概念，而Hadoop是用于实现这个概念的技术。

大数据技术之高频面试题_第73张图片

 

数据仓库

数据湖

主要处理历史的、结构化的数据，而且这些数据必须与数据仓库事先定义的模型吻合。

能处理所有类型的数据，如结构化数据，非结构化数据，半结构化数据等，数据的类型依赖于数据源系统的原始数据格式。非结构化数据（语音、图片、视频等）

数据仓库分析的指标都是产品经理提前规定好的。按需分析数据。（日活、新增、留存、转化率）

根据海量的数据，挖掘出规律，反应给运营部门。

拥有非常强的计算能力用于处理数据。

数据挖掘

7.6 埋点

免费的埋点：上课演示

收费的埋点：神策 https://mp.weixin.qq.com/s/Xp3-alWF4XHvKDP9rNWCoQ

目前主流的埋点方式，有代码埋点（前端/后端）、可视化埋点、全埋点三种。

代码埋点是通过调用埋点SDK函数，在需要埋点的业务逻辑功能位置调用接口，上报埋点数据。例如，我们对页面中的某个按钮埋点后，当这个按钮被点击时，可以在这个按钮对应的 OnClick 函数里面调用SDK提供的数据发送接口，来发送数据。

可视化埋点只需要研发人员集成采集 SDK，不需要写埋点代码，业务人员就可以通过访问分析平台的“圈选”功能，来“圈”出需要对用户行为进行捕捉的控件，并对该事件进行命名。圈选完毕后，这些配置会同步到各个用户的终端上，由采集 SDK 按照圈选的配置自动进行用户行为数据的采集和发送。

全埋点是通过在产品中嵌入SDK，前端自动采集页面上的全部用户行为事件，上报埋点数据，相当于做了一个统一的埋点。然后再通过界面配置哪些数据需要在系统里面进行分析。

7.7 电商运营经验

7.7.1 电商8类基本指标

大数据技术之高频面试题_第74张图片

大数据技术之高频面试题_第75张图片

大数据技术之高频面试题_第76张图片

大数据技术之高频面试题_第77张图片

大数据技术之高频面试题_第78张图片

大数据技术之高频面试题_第79张图片

大数据技术之高频面试题_第80张图片

 

 

 

 

 

 

 

 

8）市场竞争指标：主要分析市场份额以及网站排名，进一步进行调整

大数据技术之高频面试题_第81张图片

 

7.7.2 直播指标

 

大数据技术之高频面试题_第82张图片

大数据技术之高频面试题_第83张图片

 

 

 

大数据技术之高频面试题_第84张图片

大数据技术之高频面试题_第85张图片

大数据技术之高频面试题_第86张图片

大数据技术之高频面试题_第87张图片

 

 

你可能感兴趣的:(大数据阶段-知识点总结)

  • Golang语言基础知识点总结 最帅猪猪侠 golang开发语言后端
    Golang语言基础知识点小总结1.go语言有两大类型：值类型：数值类型，bool，string，数组，struct结构体变量直接存储值，内存通常在栈中分配,修改值,不会对源对象产生影响引用类型：指针，slice切片，管道chan，map，interface变量存储的是一个地址，这个地址对应的空间才真正存储数据值，内存通常在堆上分配，当没有任何变量引用这个地址时，该地址对应的数据空间就成为一个垃圾
  • html知识点总结 软件技术NINI html笔记html前端
    HTML（HyperTextMarkupLanguage）总结可以从其定义、基本结构、常用标签以及网页开发工具等多个方面进行阐述。一、HTML定义HTML是一种超文本标记语言，它不是一种编程语言，而是一种用于描述网页内容的标记语言。HTML文档由HTML标签和文本内容组成，这些标签告诉浏览器如何显示页面上的内容。HTML的发展始于1990年，由Web之父TimBerners-Lee发布，并随着互联
  • 瑞吉外卖和苍穹外卖项目重难点、易错点和涉及到的技术的总结归纳 勒布朗张婧仪 javaintellij-ideaspringboot
    本文是对瑞吉外卖和苍穹外卖项目的总结，会对课程里的代码和涉及到的技术进行讲解，重点归纳难点以及易错点。（前面是对项目的介绍，可以直接略过看第四点和第五点的知识点总结）瑞吉外卖和苍穹外卖的大部分功能都是重合的，建议大家先看瑞吉外卖，再看苍穹外卖独有的知识点。因为瑞吉外卖是从项目最开始构建的，讲解的比较全，苍穹外卖主要是多了许多功能，可以直接上线使用。视频链接：瑞吉外卖苍穹外卖一.项目介绍本项目是专门
  • 【Java程序设计竞赛常用知识点总结】 -LightChaser- Javajava
    文章目录1数据类型2控制台的输入与输出2.1Scanner类2.2格式化输出2.3快读快写类3Math类4Calendar类5split()函数7switch语句8进制转换1数据类型Java是一门强类型语言，这就意味着我们在编程时，每一个变量都需要声明指定的类型。在Java中，有8种原始的数据类型，分为4类，分别是整型、浮点型、字符型以及布尔型。具体来说：整型（4种）：byte、int、short
  • golang---知识点总结2 Stride Max Zz golanggogolang
    golang时间格式化格式化输出时间：packagemainimport("fmt""time")funcmain(){//未格式化fmt.Println(time.Now().Unix())//只取年fmt.Println(time.Now().Format("2006"))//只取月fmt.Println(time.Now().Format("01"))//所有全部格式化输出fmt.Print
  • 开始切换到 Kotlin: 谷歌工程师给初学者的知识点总结 谷歌开发者
    image在2019年的I/O大会上，我们曾宣布Kotlin将会是Android应用开发的首选语言，但是，部分开发者们反馈仍不清楚如何切换到Kotlin，如果团队中没有人熟悉Kotlin，一开始直接使用Kotlin进行项目开发还是会令人生畏。在AndroidStudioProfiler团队内部，我们是通过几个步骤克服了这个问题，第一步是要求所有的单元测试使用Kotlin编写。这么做有效避免了我们犯
  • JavaWeb知识点总结 weixin_30294295 数据库javajson
    》一：创建Web项目项目说明：1、javaResources：java源文件2、WebContent:网页内容html、css、js、jsp、资源、配置文件等HTML:HyperTextMarkupLanguage超文本标记语言作用：标记描述网页内容语法规则：1、不区分大小写2、固定标签3、标签成对出现，单标签4、标签可以嵌套使用5、属性的值必须使用双引号HTML中属性，一般不建议使用属性名称固定
  • 心理学知识点总结（3） 恋你如初心
    第十一章人际交往心理1．有效人机沟通的条件：a沟通双方对交流的信息的理解越一致越好；b沟通双方都要有交往的愿望和兴趣，否则就成了一厢情愿，难以持续进行；c双方要有一定的沟通能力与技巧；d要选用适当的信息通道来传送信息；e要重视选择性注意对沟通的影响，为了引起对方注意，我们传递的信息要尽量符合其需要和兴趣；f沟通要有及时的信息反映；g沟通过程没有受到主客观不良因素的干扰，保证信息真实可靠。2．人际沟
  • 2019-02-08驾考知识点总结 loucx
    高速公路两条车道左侧车道最低速度为100三条车道左侧最低速度为110上午军英姑父来了，我和爸去大爷家吃了顿饭。最近发现新英雄夏侯惇挺好玩的，今天沉迷于王者荣耀无法自拔，打了一整天中间抽空看了看驾考知识点，感觉最近这几天就要考试了，抓紧时间复习，明天上完坟，应该就没什么事了，到时候整理递归的题目。
  • react知识点总结 c三只布朗熊 react.jsnode.jsjavascript
    1.创建react项目1）打开gitbush2）查找文件夹，用cd（即：cd'文件夹名'）3）输入npxcreate-react-app'文件名'4）提交到gitee仓库命令是：gitadd--allgitcommit-m'注释'gitpush5）查找创建的react项目的文件夹(即：cd'文件名')6）输入yarneject或npmruneject会出现config和script文件7）安装sa
  • LeetCode 剑指 Offer II 093. 最长斐波那契数列 大涛小先生 LeetCode解题报告leetcode算法动态规划
    LeetCode剑指OfferII093.最长斐波那契数列文章目录LeetCode剑指OfferII093.最长斐波那契数列题目描述一、解题关键词二、解题报告1.思路分析2.时间复杂度3.代码示例2.知识点总结相同题目题目描述如果序列X_1,X_2,…,X_n满足下列条件，就说它是斐波那契式的：n>=3对于所有i+2<=n，都有X_i+X_{i+1}=X_{i+2}给定一个严格递增的正整数数组形成
  • G 211 第五组 小组会议纪要 181010 e9b6eca5c0ee
    日期：2018年10月10日8:00-9:00pm地点：Zoom参会人员：组员：01张媛，02徐冰洁，03周蔚文Garry，04吴优Nicky，06吴荧Tina，07汪小英Doreen，08张丽Lisa教练：关平Linda主持：张媛记录：张媛会议内容：-组员学习易效能知识点总结1.A4纸工作法,每日3只青蛙2.梦想版制作3.100讲一定要听，可以加快速度4.关于加入读书会5.微信文章收藏在印象笔记
  • 山东大学大数据管理与分析知识点总结 weixin_51565263 云计算大数据mapreduce数据仓库
    大数据概述大数据(bigdata)，或称巨量资料，指的是需要新处理模式才能具有更强的决策力、洞察发现力和流程优化能力的海量、高增长率和多样化的信息资产大数据指不用随机分析法（抽样调查）这样的捷径，而采用所有数据进行分析处理大数据四个本质特征大量化（volume），快速化（velocity），多样化（variety），价值化（value）；四个VVolume—数量大：数据每两年就增长一倍（大数据摩尔
  • c++ const & constexpr c++98 c++11 c++14 Nick_Zhang_123 c++c++
    文章目录c++const和constexpr知识点总结一、const1.const修饰变量修饰普通变量(常量）修饰指针类型修饰引用类型2.const修饰函数const修饰函数参数const修饰函数返回值const修饰成员函数（this指针）3.const修饰对象4.常量数组，常量指针数组，常量引用数组二、constexpr1.constexpr特性和const之间的差异2.constexpr在c+
  • PPT-个人简历 Quincy丶Wang
    知识点总结：字体是传递情感的重要手段！字体选择方法：找字网：不知道选择什么样的字体，在网站上预览选择。求字网：有字，但是不知道是什么字体，选择截图上传，网站分析。
  • C语言-----知识点总结 平头哥在等你 c语言开发语言
    《C语言程序设计》教学基本知识点第一章C语言基本知识1.C源程序的框架尽管各个C源程序的功能千变万化，但框架是不变的，主要有：编译预处理、主函数()、函数n()等，主函数的位置不一定在最前面，可以在程序的中部或后面，主函数的名字固定为main。2.C语言源程序的书写规则：(1)C源程序是由一个主函数和若干个其它函数组成的。(2)函数名后必须有小括号，函数体放在大括号内。(3)C程序必须用小写字母书
  • C++并发编程之线程异步std::promise知识点总结 给大佬递杯卡布奇诺 C/C++c++
    1、std::promise介绍std::promise是一个模板类，其对象可保存T类型的值，该值可以被另外一个线程读取，也就是说可以通过异步的方式读取该值。在定义std::promise时，它是和std::future配合进行使用的，最常用的方式是std::future=std::promise::get_future()。在另外一个线程中通过std::future::get()成员函数得到线程
  • LINUX考试知识点总结 平头哥在等你 linux运维服务器
    一．填空题1.文件权限—rwxrwxrwx文件类型usergroupotherdrwxrwxrwx文件夹2.文件编辑器的基本操作w保存q退出q！强制退出3.文件链接命令软链接：ln-s目标链接名硬链接：ln4.创建文件/文件夹touchmkdir5.文件不同对比命令diff6.显示文本catlessmore7.删除命令rmrmdir删除非空文件夹rm-f强制删除rmdir-r递归删除非空文件夹rm
  • 案例分析篇02：软件架构设计考点之特定领域软件架构、架构评估、架构视图（2024年软考高级系统架构设计师冲刺知识点总结） 随风浪仔 系统架构设计师计算机软考案例分析知识点高频考点软件架构设计架构评估方法4+1视图
    专栏系列文章推荐：2024高级系统架构设计师备考资料（高频考点&真题&经验）https://blog.csdn.net/seeker1994/category_12593400.html【历年案例分析真题考点汇总】与【专栏文章案例分析高频考点目录】（2024年软考高级系统架构设计师冲刺知识点总结-案例分析篇-先导篇）案例分析篇08：We
  • 案例分析篇12：可靠性设计考点（2024年软考高级系统架构设计师冲刺知识点总结系列文章） 随风浪仔 可靠性设计系统架构设计师计算机软考历年真题高频考点案例分析篇
    专栏系列文章推荐：2024高级系统架构设计师备考资料（高频考点&真题&经验）https://blog.csdn.net/seeker1994/category_12593400.html【历年案例分析真题考点汇总】与【专栏文章案例分析高频考点目录】（2024年软考高级系统架构设计师冲刺知识点总结-案例分析篇-先导篇）
  • 案例分析篇16：软件开发模型考点（2024年软考高级系统架构设计师冲刺知识点总结系列文章） 随风浪仔 系统架构
    专栏系列文章推荐：2024高级系统架构设计师备考资料（高频考点&真题&经验）https://blog.csdn.net/seeker1994/category_12593400.html【历年案例分析真题考点汇总】与【专栏文章案例分析高频考点目录】（2024年软考高级系统架构设计师冲刺知识点总结-案例分析篇-先导篇）
  • 案例分析篇07：数据库设计相关28个考点（23~28）（2024年软考高级系统架构设计师冲刺知识点总结系列文章） 随风浪仔 数据库设计计算机软考系统架构设计师历年真题高频考点案例分析题
    专栏系列文章推荐：2024高级系统架构设计师备考资料（高频考点&真题&经验）https://blog.csdn.net/seeker1994/category_12593400.html【历年案例分析真题考点汇总】与【专栏文章案例分析高频考点目录】（2024年软考高级系统架构设计师冲刺知识点总结-案例分析篇-先导篇）
  • MySQL——知识点总结（持续更新中） 人若少年要风流 MySQLmysqllinuxcentos运维数据库
    知识点汇总MySQL——在线、离线安装MySQL-5.7.14MySQL——使用docker镜像拉取MySQLMySQL——通用二进制安装MySQL-5.7.14MySQL——源码安装MySQL-5.7.14MySQL——修改密码及密码强度规则MySQL——表查询基本语句MySQL——单表查询（素材+习题）MySQL——多表查询（素材+习题）MySQL——备份恢复练习，mysqldump的使用My
  • ES入门知识点总结 帅气的梧桐述 Elasticsearchelasticsearches倒排索引搜索引擎
    目录倒排索引倒排索引Elasticsearch的倒排索引是一种数据结构，用于加快基于文本的搜索操作。它的主要优势在于能够快速找到包含特定单词的文档。倒排索引的构建过程如下：文档分词：将文档内容分割成单独的词（或者更小的词元，如果是中文的话是分词）。创建词典：创建一个包含所有不重复词的列表，也称为词典。创建排序列表：对于词典中的每个词，创建一个排序列表，列出所有包含该词的文档ID。倒排索引的理解可以
  • C++知识点总结(15)：选择排序、插入排序 AICodeThunder C++知识点总结c++排序算法算法
    文章目录一、选择排序1.概念2.伪代码3.程序4.例题第k大的数二、元素插入1.伪代码2.程序三、插入排序1.概念2.伪代码3.程序4.例题洛谷P1152四、分析一、选择排序1.概念下标12345最小值原始43521/第一次135241第二次125342第三次123543第四次123454完成12345/选择排序从待排序的区间中找到最小元素的位置，并将该元素与该区间的第一个元素交换位置。这样通过n
  • C++知识点总结(16)：结构体排序 AICodeThunder C++知识点总结c++排序算法算法
    课程大纲一、常见排序方法1.桶排序2.冒泡排序3.选择排序4.插入排序二、结构体排序1.融入实际2.认识结构体2.1概念2.2框架2.2.1存储2.2.2输入输出2.2.3结构体数组2.2.4例题2.2.4.1结构体读写2.2.4.2结构体交换三、sort函数1.使用方法2.固定格式四、结构体和sort函数1.成绩排名2.NOIP09年真题洛谷P1068一、常见排序方法我们以下面的序列为例，看一看
  • 【深度学习】使用tensorflow实现VGG19网络 杨得江-君临天下wyj 网络协议网络
    【深度学习】使用tensorflow实现VGG19网络本文章向大家介绍【深度学习】使用tensorflow实现VGG19网络，主要内容包括其使用实例、应用技巧、基本知识点总结和需要注意事项，具有一定的参考价值，需要的朋友可以参考一下。VGG网络与AlexNet类似，也是一种CNN，VGG在2014年的ILSVRClocalizationandclassification两个问题上分别取得了第一名和
  • 收藏 数据结构链表的知识点总结 极客代码 玩转C语言c语言数据结构
    数据结构链表知识点总结1.链表的基本概念-链表是一种线性数据结构，由一系列节点（或元素）组成。-每个节点包含两部分：数据域和指针域（或称为链接）。-指针域存储指向下一个节点的地址，形成链表的逻辑顺序。2.链表的类型-单链表：每个节点只有一个指针，指向下一个节点。-双向链表：每个节点有两个指针，一个指向前一个节点，一个指向后一个节点。-循环链表：单链表或双向链表的最后一个节点的指针指向头节点，形成一
  • 高中化学知识点总结归纳，一轮复习必备！ 爱学习的花花
    高二的同学们，马上要进入高三全面总复习了。你是否对自己的总复习有一个明确的目标，是否给自己制定好了详细的学习规划了呢？就化学这一学科来说，知识点非常多，同学们在一轮复习时，一定要整理好学习笔记，把书读“厚”。如果同学们自己不擅长整理学习笔记，不妨看看今天我给大家分享的这份【高中化学知识点总结归纳】，由清北学霸精心整理，逐本教材、逐个章节，为同学详细总结了一轮复习阶段必须要掌握的化学知识点，打印版共
  • 生信学习小组Day7笔记--苏剑请 苏剑清
    今日收获大致了解了第一到三代的测序历史、原理和特点深入了解了二代测序的过程，虽然还没能完全看懂以上知识点总结归纳于下面两图（以下知识点均为生信星球公众号提供）：生信Day7笔记1.png生信Day7笔记2.png心得1.7天的学习进入了尾声，其实生信的学习远远还没有结束，昨天老师教了如何下载R包小抄和根据R包小抄进行学习，日后将会是我学习R语言的重要指南。2.了解了测序的大致原理和过程，不过盯了三
  • java工厂模式 3213213333332132 java抽象工厂
    工厂模式有 1、工厂方法 2、抽象工厂方法。 下面我的实现是抽象工厂方法, 给所有具体的产品类定一个通用的接口。 package 工厂模式; /** * 航天飞行接口 * * @Description * @author FuJianyong * 2015-7-14下午02:42:05 */ public interface SpaceF
  • nginx频率限制+python测试 ronin47 nginx 频率 python
           部分内容参考：http://www.abc3210.com/2013/web_04/82.shtml 首先说一下遇到这个问题是因为网站被攻击，阿里云报警，想到要限制一下访问频率，而不是限制ip（限制ip的方案稍后给出）。nginx连接资源被吃空返回状态码是502，添加本方案限制后返回599，与正常状态码区别开。步骤如下：
  • java线程和线程池的使用 dyy_gusi ThreadPoolthreadRunnabletimer
    java线程和线程池 一、创建多线程的方式     java多线程很常见，如何使用多线程，如何创建线程，java中有两种方式，第一种是让自己的类实现Runnable接口，第二种是让自己的类继承Thread类。其实Thread类自己也是实现了Runnable接口。具体使用实例如下： 1、通过实现Runnable接口方式 1 2
  • Linux 171815164 linux
    ubuntu kernel http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.1.2-unstable/ 安卓sdk代理 mirrors.neusoft.edu.cn        80 输入法和jdk sudo apt-get install fcitx su
  • Tomcat JDBC Connection Pool g21121 Connection
           Tomcat7 抛弃了以往的DBCP 采用了新的Tomcat Jdbc Pool 作为数据库连接组件，事实上DBCP已经被Hibernate 所抛弃，因为他存在很多问题，诸如：更新缓慢，bug较多，编译问题，代码复杂等等。        Tomcat Jdbc P
  • 敲代码的一点想法 永夜-极光 java随笔感想
                  入门学习java编程已经半年了,一路敲代码下来,现在也才1w+行代码量,也就菜鸟水准吧,但是在整个学习过程中,我一直在想,为什么很多培训老师,网上的文章都是要我们背一些代码?比如学习Arraylist的时候,教师就让我们先参考源代码写一遍,然
  • jvm指令集 程序员是怎么炼成的 jvm 指令集
    转自：http://blog.csdn.net/hudashi/article/details/7062675#comments       将值推送至栈顶时 const ldc  push   load指令 const系列 该系列命令主要负责把简单的数值类型送到栈顶。(从常量池或者局部变量push到栈顶时均使用) 0x02 &nbs
  • Oracle字符集的查看查询和Oracle字符集的设置修改 aijuans oracle
    本文主要讨论以下几个部分：如何查看查询oracle字符集、 修改设置字符集以及常见的oracle utf8字符集和oracle exp 字符集问题。 一、什么是Oracle字符集 Oracle字符集是一个字节数据的解释的符号集合,有大小之分,有相互的包容关系。ORACLE 支持国家语言的体系结构允许你使用本地化语言来存储，处理，检索数据。它使数据库工具，错误消息，排序次序，日期，时间，货
  • png在Ie6下透明度处理方法 antonyup_2006 css浏览器FirebugIE
    由于之前到深圳现场支撑上线，当时为了解决个控件下载，我机器上的IE8老报个错，不得以把ie8卸载掉，换个Ie6,问题解决了，今天出差回来，用ie6登入另一个正在开发的系统，遇到了Png图片的问题，当然升级到ie8(ie8自带的开发人员工具调试前端页面JS之类的还是比较方便的，和FireBug一样，呵呵)，这个问题就解决了，但稍微做了下这个问题的处理。 我们知道PNG是图像文件存储格式，查询资
  • 表查询常用命令高级查询方法(二) 百合不是茶 oracle分页查询分组查询联合查询
    ----------------------------------------------------分组查询 group by    having   --平均工资和最高工资   select avg(sal)平均工资,max(sal)  from emp ;  --每个部门的平均工资和最高工资
  • uploadify3.1版本参数使用详解 bijian1013 JavaScriptuploadify3.1
    使用：     绑定的界面元素<input id='gallery'type='file'/>$("#gallery").uploadify({设置参数，参数如下}); 设置的属性： id: jQuery(this).attr('id'),//绑定的input的ID langFile: 'http://ww
  • 精通Oracle10编程SQL(17)使用ORACLE系统包 bijian1013 oracle数据库plsql
    /* *使用ORACLE系统包 */ --1.DBMS_OUTPUT --ENABLE:用于激活过程PUT,PUT_LINE,NEW_LINE,GET_LINE和GET_LINES的调用 --语法：DBMS_OUTPUT.enable(buffer_size in integer default 20000); --DISABLE:用于禁止对过程PUT,PUT_LINE,NEW
  • 【JVM一】JVM垃圾回收日志 bit1129 垃圾回收
    将JVM垃圾回收的日志记录下来，对于分析垃圾回收的运行状态，进而调整内存分配(年轻代，老年代，永久代的内存分配)等是很有意义的。JVM与垃圾回收日志相关的参数包括： -XX:+PrintGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -Xloggc -XX:+PrintGC 通
  • Toast使用 白糖_ toast
    Android中的Toast是一种简易的消息提示框，toast提示框不能被用户点击，toast会根据用户设置的显示时间后自动消失。     创建Toast 两个方法创建Toast makeText(Context context, int resId, int duration)     参数：context是toast显示在
  • angular.identity boyitech AngularJSAngularJS API
    angular.identiy 描述: 返回它第一参数的函数. 此函数多用于函数是编程. 使用方法: angular.identity(value); 参数详解: Param Type Details value * to be returned. 返回值: 传入的value 实例代码: <!DOCTYPE HTML>
  • java-两整数相除，求循环节 bylijinnan java
    import java.util.ArrayList; import java.util.List; public class CircleDigitsInDivision { /** * 题目：求循环节，若整除则返回NULL，否则返回char*指向循环节。先写思路。函数原型：char*get_circle_digits(unsigned k,unsigned j)
  • Java 日期 周 年 Chen.H javaC++cC#
    /** * java日期操作(月末、周末等的日期操作) * * @author * */ public class DateUtil { /** */ /** * 取得某天相加(减)後的那一天 * * @param date * @param num *
  • [高考与专业]欢迎广大高中毕业生加入自动控制与计算机应用专业 comsci 计算机
          不知道现在的高校还设置这个宽口径专业没有,自动控制与计算机应用专业,我就是这个专业毕业的,这个专业的课程非常多,既要学习自动控制方面的课程,也要学习计算机专业的课程,对数学也要求比较高.....如果有这个专业,欢迎大家报考...毕业出来之后,就业的途径非常广.....      以后
  • 分层查询（Hierarchical Queries） daizj oracle递归查询层次查询
    Hierarchical Queries If a table contains hierarchical data, then you can select rows in a hierarchical order using the hierarchical query clause: hierarchical_query_clause::= start with condi
  • 数据迁移 daysinsun 数据迁移
    最近公司在重构一个医疗系统，原来的系统是两个.Net系统，现需要重构到java中。数据库分别为SQL Server和Mysql，现需要将数据库统一为Hana数据库，发现了几个问题，但最后通过努力都解决了。 1、原本通过Hana的数据迁移工具把数据是可以迁移过去的，在MySQl里面的字段为TEXT类型的到Hana里面就存储不了了，最后不得不更改为clob。 2、在数据插入的时候有些字段特别长
  • C语言学习二进制的表示示例 dcj3sjt126com cbasic
    进制的表示示例 # include <stdio.h> int main(void) { int i = 0x32C; printf("i = %d\n", i); /* printf的用法 %d表示以十进制输出 %x或%X表示以十六进制的输出 %o表示以八进制输出 */ return 0; }
  • NsTimer 和 UITableViewCell 之间的控制 dcj3sjt126com ios
    情况是这样的: 一个UITableView, 每个Cell的内容是我自定义的 viewA viewA上面有很多的动画, 我需要添加NSTimer来做动画, 由于TableView的复用机制, 我添加的动画会不断开启, 没有停止, 动画会执行越来越多.   解决办法: 在配置cell的时候开始动画, 然后在cell结束显示的时候停止动画   查找cell结束显示的代理
  • MySql中case when then 的使用 fanxiaolong casewhenthenend
    select "主键", "项目编号", "项目名称","项目创建时间", "项目状态","部门名称","创建人" union (select pp.id as "主键", pp.project_number as &
  • Ehcache（01）——简介、基本操作 234390216 cacheehcache简介CacheManagercrud
    Ehcache简介 目录 1       CacheManager 1.1      构造方法构建 1.2      静态方法构建 2       Cache 2.1&
  • 最容易懂的javascript闭包学习入门 jackyrong JavaScript
    http://www.ruanyifeng.com/blog/2009/08/learning_javascript_closures.html 闭包（closure）是Javascript语言的一个难点，也是它的特色，很多高级应用都要依靠闭包实现。 下面就是我的学习笔记，对于Javascript初学者应该是很有用的。 一、变量的作用域 要理解闭包，首先必须理解Javascript特殊
  • 提升网站转化率的四步优化方案 php教程分享 数据结构PHP数据挖掘Google活动
    网站开发完成后,我们在进行网站优化最关键的问题就是如何提高整体的转化率，这也是营销策略里最最重要的方面之一，并且也是网站综合运营实例的结果。文中分享了四大优化策略：调查、研究、优化、评估，这四大策略可以很好地帮助用户设计出高效的优化方案。 PHP开发的网站优化一个网站最关键和棘手的是，如何提高整体的转化率，这是任何营销策略里最重要的方面之一，而提升网站转化率是网站综合运营实力的结果。今天，我就分
  • web开发里什么是HTML5的WebSocket？ naruto1990 Webhtml5浏览器socket
    当前火起来的HTML5语言里面，很多学者们都还没有完全了解这语言的效果情况，我最喜欢的Web开发技术就是正迅速变得流行的 WebSocket API。WebSocket 提供了一个受欢迎的技术，以替代我们过去几年一直在用的Ajax技术。这个新的API提供了一个方法，从客户端使用简单的语法有效地推动消息到服务器。让我们看一看6个HTML5教程介绍里 的 WebSocket API：它可用于客户端、服
  • Socket初步编程——简单实现群聊 Everyday都不同 socket网络编程初步认识
    初次接触到socket网络编程，也参考了网络上众前辈的文章。尝试自己也写了一下，记录下过程吧：   服务端：（接收客户端消息并把它们打印出来）   public class SocketServer { private List<Socket> socketList = new ArrayList<Socket>(); public s
  • 面试：Hashtable与HashMap的区别（结合线程） toknowme
    昨天去了某钱公司面试，面试过程中被问道 Hashtable与HashMap的区别？当时就是回答了一点，Hashtable是线程安全的，HashMap是线程不安全的，说白了，就是Hashtable是的同步的，HashMap不是同步的，需要额外的处理一下。   今天就动手写了一个例子，直接看代码吧 package com.learn.lesson001; import java
  • MVC设计模式的总结 xp9802 设计模式mvc框架IOC
    随着Web应用的商业逻辑包含逐渐复杂的公式分析计算、决策支持等，使客户机越 来越不堪重负，因此将系统的商业分离出来。单独形成一部分，这样三层结构产生了。 其中‘层’是逻辑上的划分。 三层体系结构是将整个系统划分为如图2.1所示的结构[3] （1）表现层（Presentation layer）：包含表示代码、用户交互GUI、数据验证。 该层用于向客户端用户提供GUI交互，它允许用户
按字母分类： ABCDEFGHIJKLMNOPQRSTUVWXYZ其他