大数据知识点学习

第一章：Linux和Shell

1、Linux常用高级命令

1）查看内存：top

2)查看磁盘存储：df -h

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

4)查看进程：ps -aux 或者 ps -ef

5)查看端口号：netstat -tunlp|grep 3306

6）查看比较高的磁盘读写程序：iotop -o

7)查看系统运行市场以及平均负载：uptime

8）查看防火墙状态：systemctl status firewalld
2、Shell常用工具
1）awk、sed、cut、sort
2）Shell中提交一个脚本，进程号不知道，但是需要kill掉这个进程，所需命令：
ssh $i “ps -ef|grep 进程名|grep -v grep|awk ‘{print $2}’ |xargs kill”
3)shell 中单引号、双引号、反引号的区别：
单引号，不取变量值；双引号，取变量值；反引号，执行引号中的命令；双引号嵌套单引号，去变量值；单引号内嵌套双引号，不取变量值。

第二章：Hadoop

1、Hadoop常用端口号：

	hadoop2.x	hadoop3.x
访问HDFS端口号	50070	9870
访问MR执行情况端口号	8088	8088
访问历史日志	19888	19888
客户端访问集群端口号	9000	8020
2、Hadoop配置文件
Hadoop2.x	core-site.xml	yarn-site.xml
–	–	–
hadoop3.x	core-site.xml	yarn-site.xml
3、Hadoop的简单安装
1）jdk安装
2）配置SSH免密登录
3）配置hadoop核心配置文件
4）格式化namenode
4、HDFS读写流程
1）HDFS读数据流程

1.客户端向namenode请求下载文件
2.namenode返回文件的元数据给客户端
3.客户端向datanode请求下载第一块文件
4.datanode返回给客户端第一块文件
5.客户端向datanode请求下载第二块文件
6.datanode返回给客户端第二块文件
![在这里插入图片描述](https://img-blog.csdnimg.cn/f6c90a57c1af4316a88c182e1a629ee2.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA5pyJ6K-t5b-G6K-t,size_20,color_FFFFFF,t_70,g_se,x_16)
2）HDFS写流程
1.客户端向namenode请求上传数据
2.namenode向客户端响应可以上传数据
3.客户端向namenode请求上传文件的datanode节点
4.namenode向客户端返回允许上传的datanode节点信息
5.客户端向datanode请求建立连接
6.datanode向副本所在节点请求建立连接
7.副本节点向datanode响应成功
8.客户端开始向datanode传输数据
9.传输完毕，客户端向namenodo响应传输数据完成
![在这里插入图片描述](https://img-blog.csdnimg.cn/79f72aec2bc0474b9d1798a94281939f.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA5pyJ6K-t5b-G6K-t,size_20,color_FFFFFF,t_70,g_se,x_16)

5、HDFS小文件处理
1）会有什么影响
（1）存储层面：一个小文件，就会在namenode存储150字节左右的元数据，占用namenode的存储空间。
（2）计算层面：每个小文件都会起到一个MapTask,占用了大量计算资源。
2）怎么解决
（1）采用har归档方式，将小文件归档
（2）采用CombinTextInputFormat读取文件数据
（3）开启jvm重用（没有小文件，不要开启jvm重用，因为会一直占用使用到的task卡槽，直到任务完成才会释放）
jvm重用可以使得jvm实例在同一个job中重新使用n次，n的值可以在hadoop的mapred-site.xml文件中进行配置。通常在10-20之间。
6、shuffle及优化
1）mapreduce详细工作流程
1.待处理文本
2.客户端submit前，获取待处理数据的信息，然后根据参数配置，形成一个任务分配的规划。
3.客户端提前配置信息到yarn rm
4.mr appmaster计算出maptask的数量
5.默认使用TextInputFormat读取文件中的数据
6.进行map运算
7.向环形缓冲区写数据（左边元数据，右边数据）
8.然后进行分区排序
9.达到80%进行反向溢写，写到磁盘
10.然后再进行归并排序
11.合并小文件
12.所有的maptask完成后，启动响应数量的reducetask，并告知reducetask处理数据范围（数据分区
13.下载数据到reducetask的本地磁盘，合并文件，归并排序
14.一次读取一组
15.分组
16.默认TextOutputFormat


2）优化
（1）map阶段：
1.增大环形缓冲区的大小
2.增大环形缓冲区的比例
3.减少对溢写文件的merge次数（一次多merge几个文件）
4.不影响实际业务的前提下，采用combiner提前合并，减少IO
（2）reduce阶段：
1.合理设置map和reduce的个数
2.设置map和reduce共存
3.合理设置map和reduce的内存大小
4.规避使用reduce
5.增加reduce去map拉取数据的并行度（在执行hivesql时候，可以通过参数设置maptask和reducetask的个数）
（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= ，，比如集群规模为8台时，此参数设置为41。可通过简单的python代码计算该值，代码百度。
7、yarn的工作机制
1）mr程序提交到客户端所在的节点
2）客户端向RM申请applicationid
3)RM返回applicationid和资源提交路径hdfs://…/applicationid
4）客户端提交资源到hdfs://…/applicationid
5)资源提交完毕，客户端申请运行mr appmaster资源
6）RM将用户的请求初始化为一个task放到公平调度器里面
7）nodemanager领取到task，创建容器，
8）下载资源到本地
9）mr appmaster向RM申请运行maptask的资源
10）RM将请求转为一个task放到公平调度器里面
11）nodemanager领取到task,创建容器，初始化maptask
12)发送程序启动脚本到maptask节点
13）mr appmaster申请运行reducetask的节点
14) reduce向map领取对应分区的数据

8、yarn调度器
1）Hadoop调度器重要分为三类：
FIFO 、Capacity Scheduler（容量调度器）和Fair Sceduler（公平调度器）。
Apache默认的资源调度器是容量调度器；
CDH默认的资源调度器是公平调度器。
2）区别：
FIFO调度器：支持单队列 、先进先出 生产环境不会用。
容量调度器：支持多队列，保证先进入的任务优先执行。
公平调度器：支持多队列，保证每个任务公平享有队列资源。 资源不够时可以按照缺额分配。
9、Hadoop宕机
1）如果MR造成系统宕机。此时要控制Yarn同时运行的任务数，和每个任务申请的最大内存。调整参数：yarn.scheduler.maximum-allocation-mb（单个任务可申请的最多物理内存量，默认是8192MB）
2）如果写入文件过快造成NameNode宕机。那么调高Kafka的存储大小，控制从Kafka到HDFS的写入速度。例如，可以调整Flume每批次拉取数据量的大小参数batchsize。
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

第三章 Zookeeper

1、选举机制
半数机制：2n+1，安装奇数台
10台服务器：3台
20台服务器：5台
100台服务器：11台
台数多，好处：提高可靠性；坏处：影响通信延时
2、常用命令
create、get、ls、delete
3、CAP法则，Zookeeper符合了这个法则的哪两个
CAP法则：强一致性、高可用性、分区容错性；
Zookeeper符合强一致性、高可用性！

第四章 Flume

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事务
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里面处理
优势：只处理一次，轻度处理；劣势：影响性能，不适合做实时推荐这种对实时要求比较高的场景。
3、Flume选择器
Replicating：默认选择器。功能：将数据发往下一级所有通道
Multiplexing：选择性发往指定通道。
4、Flume监控器
1）采用Ganglia监控器，监控到Flume尝试提交的次数远远大于最终成功的次数，说明Flume运行比较差。
2）解决办法？
（1）自身：增加内存flume-env.sh 4-6g
-Xmx与-Xms最好设置一致，减少内存抖动带来的性能影响，如果设置不一致容易导致频繁fullgc。
（2）增加服务器台数
搞活动 618 =》增加服务器=》用完在退出
日志服务器配置：8-16g内存、磁盘8T
5、Flume采集数据会丢失吗?（防止数据丢失的机制）
如果是FileChannel不会，Channel存储可以存储在File中，数据传输自身有事务。
如果是MemoryChannel有可能丢。

第五章 Kafka

1、kafka架构
生产者、Broker、消费者、ZK；
注意：Zookeeper中保存Broker id和消费者offsets等信息，但是没有生产者信息。


2、kafka的机器数量=2*（峰值生产速度副本数/100）+1
3、副本数设定
一般我们设置成2个或3个，很多企业设置为2个。
副本的优势：提高可靠性；副本劣势：增加了网络IO传输
4、Kafka压测
Kafka官方自带压力测试脚本（kafka-consumer-perf-test.sh、kafka-producer-perf-test.sh）。Kafka压测时，可以查看到哪个地方出现了瓶颈（CPU，内存，网络IO）。一般都是网络IO达到瓶颈。
5 Kafka日志保存时间
默认保存7天；生产环境建议3天
6、Kafka中数据量计算
每天总数据量100g，每天产生1亿条日志， 10000万/24/60/60=1150条/每秒钟
平均每秒钟：1150条
低谷每秒钟：50条
高峰每秒钟：1150条（2-20倍）=2300条-23000条
每条日志大小：0.5k-2k（取1k）
每秒多少数据量：2.0M - 20MB
7 Kafka的硬盘大小
每天的数据量100g * 2个副本 * 3天 / 70%
8、Kafka监控
公司自己开发的监控器；
开源的监控器：KafkaManager、KafkaMonitor、KafkaEagle
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个
10、多少个Topic
通常情况：多少个日志类型就多少个Topic。也有对日志类型进行合并的。
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中。
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进行排序，最后按照轮询的方式发给每一个消费线程。
13、Kafka挂掉
1）Flume记录
2）日志有记录
3）短期没事
14、Kafka丢不丢数据
Ack = 0，相当于异步发送，消息发送完毕即offset增加，继续生产。
Ack = 1，leader收到leader replica 对一个消息的接受ack才增加offset，然后继续生产。
Ack = -1，leader收到所有replica 对一个消息的接受ack才增加offset，然后继续生产。
15、Kafka数据重复
幂等性 + ack-1 + 事务
Kafka数据重复，可以再下一级：SparkStreaming、redis或者Hive中dwd层去重，去重的手段：分组、按照id开窗只取第一个值；
16、Kafka消息数据积压，Kafka消费能力不足怎么处理？
1）如果是Kafka消费能力不足，则可以考虑增加Topic的分区数，并且同时提升消费组的消费者数量，消费者数 = 分区数。（两者缺一不可）
2）如果是下游的数据处理不及时：提高每批次拉取的数量。批次拉取数据过少（拉取数据/处理时间 < 生产速度），使处理的数据小于生产的数据，也会造成数据积压。
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 gzip snappy lz4
#默认发送不进行压缩，推荐配置一种适合的压缩算法，可以大幅度的减缓网络压力和Broker的存储压力。
3）Kafka内存调整（kafka-server-start.sh）
默认内存1个G，生产环境尽量不要超过6个G。
export KAFKA_HEAP_OPTS=“-Xms4g -Xmx4g”
18、Kafka高效读写数据
1）Kafka本身是分布式集群，同时采用分区技术，并发度高。
2）顺序写磁盘
Kafka的producer生产数据，要写入到log文件中，写的过程是一直追加到文件末端，为顺序写。官网有数据表明，同样的磁盘，顺序写能到600M/s，而随机写只有100K/s。
3）零复制技术

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之间数据同步失败。
20、Kafka过期数据清理
保证数据没有被引用（没人消费他）
日志清理保存的策略只有delete和compact两种
log.cleanup.policy = delete启用删除策略
log.cleanup.policy = compact启用压缩策略
https://www.jianshu.com/p/fa6adeae8eb5
21 Kafka可以按照时间消费数据
Map<TopicPartition, OffsetAndTimestamp> startOffsetMap = KafkaUtil.fetchOffsetsWithTimestamp(topic, sTime, kafkaProp);
22 Kafka消费者角度考虑是拉取数据还是推送数据
拉取数据（谁用谁拿）
23 Kafka中的数据是有序的吗
单分区内有序；多分区，分区与分区间无序；
扩展：
kafka producer发送消息的时候，可以指定key:

这个key的作用是为消息选择存储分区，key可以为空，当指定key且不为空的时候，Kafka是根据key的hash值与分区数取模来决定数据存储到那个分区。

有序解决方案：同一张表的数据 放到 同一个 分区
=> ProducerRecord里传入key，会根据key取hash算出分区号
=> key使用表名，如果有库名，拼接上库名

第六章 Hive

1 Hive的架构
Hive元数据默认存储在derby数据库，不支持多客户端访问，所以将元数据存储在MySQl，支持多客户端访问。

1、用户提交查询任务给Driver
2、sql解析器，解析成语法树
3、物理编译器
4、优化器
5、执行器
6、mapreduce

1、hive语句的书写顺序：（从前往后）
(1)select
(2)from
(3)join on
(4) where
(5)group by
(6)having
(7)distribute by/cluster by
(8) sort by
(9) order by
(10) limit
(11) union(去重不排序)/union all（不去重不排序）

2、hive语句的执行顺序：
(1)from
(2)on
(3)join
(4)where
(5)group by
(6)having
(7)select
(8)distinct
(9)distribute by /cluster by
(10)sort by
(11) order by
(12) limit
(13) union /union all
2 Hive和数据库比较
Hive 和数据库除了拥有类似的查询语言，再无类似之处。
1）数据存储位置
Hive 存储在 HDFS 。数据库将数据保存在块设备或者本地文件系统中。
2）数据更新
Hive中不建议对数据的改写。而数据库中的数据通常是需要经常进行修改的，
3）执行延迟
Hive 执行延迟较高。数据库的执行延迟较低。当然，这个是有条件的，即数据规模较小，当数据规模大到超过数据库的处理能力的时候，Hive的并行计算显然能体现出优势。
4）数据规模
Hive支持很大规模的数据计算；数据库可以支持的数据规模较小。
3 内部表和外部表
元数据、原始数据
1）删除数据时：
内部表：元数据、原始数据，全删除
外部表：元数据 只删除
2）在公司生产环境下，什么时候创建内部表，什么时候创建外部表？
在公司中绝大多数场景都是外部表。
自己使用的临时表，才会创建内部表；
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用的多。
5 系统函数
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的值。
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打印日志，出错或者数据异常，方便调试。
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类型。
8 Hive优化
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数。
需要提醒的是，直接调整mapred.map.tasks这个参数是没有效果的。
https://www.cnblogs.com/swordfall/p/11037539.html
6）合理设置Reduce数
Reduce个数并不是越多越好
（1）过多的启动和初始化Reduce也会消耗时间和资源；
（2）另外，有多少个Reduce，就会有多少个输出文件，如果生成了很多个小文件，那么如果这些小文件作为下一个任务的输入，则也会出现小文件过多的问题；
在设置Reduce个数的时候也需要考虑这两个原则：处理大数据量利用合适的Reduce数；使单个Reduce任务处理数据量大小要合适；
7）小文件如何产生的？
（1）动态分区插入数据，产生大量的小文件，从而导致map数量剧增；
（2）reduce数量越多，小文件也越多（reduce的个数和输出文件是对应的）；
（3）数据源本身就包含大量的小文件。
8）小文件解决方案
（1）在Map执行前合并小文件，减少Map数：CombineHiveInputFormat具有对小文件进行合并的功能（系统默认的格式）。HiveInputFormat没有对小文件合并功能。
（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
（3）开启JVM重用
set mapreduce.job.jvm.numtasks=10
9）开启map端combiner（不影响最终业务逻辑）
set hive.map.aggr=true；
10）压缩（选择快的）
设置map端输出、中间结果压缩。（不完全是解决数据倾斜的问题，但是减少了IO读写和网络传输，能提高很多效率）
set hive.exec.compress.intermediate=true --启用中间数据压缩
set mapreduce.map.output.compress=true --启用最终数据压缩
set mapreduce.map.outout.compress.codec=…; --设置压缩方式
11）采用tez引擎或者spark引擎
9 Hive解决数据倾斜方法
1）数据倾斜长啥样？


2）怎么产生的数据倾斜？
（1）不同数据类型关联产生数据倾斜
情形：比如用户表中user_id字段为int，log表中user_id字段string类型。当按照user_id进行两个表的Join操作时。
解决方式：把数字类型转换成字符串类型
select * from users a
left outer join logs b
on a.usr_id = cast(b.user_id as string)
bug记录：https://www.jianshu.com/p/2181e00d74dc
（2）控制空值分布
在生产环境经常会用大量空值数据进入到一个reduce中去，导致数据倾斜。
解决办法：
自定义分区，将为空的key转变为字符串加随机数或纯随机数，将因空值而造成倾斜的数据分不到多个Reducer。
注意：对于异常值如果不需要的话，最好是提前在where条件里过滤掉，这样可以使计算量大大减少
3）解决数据倾斜的方法？
（1）group by
注：group by 优于distinct group
解决方式：采用sum() group by的方式来替换count(distinct)完成计算。
（2）mapjoin
（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中随机分布到各个节点完成。
（4）设置多个reduce个数
10 Hive里边字段的分隔符用的什么？为什么用\t？有遇到过字段里边有\t的情况吗，怎么处理的？
hive 默认的字段分隔符为ascii码的控制符\001（^A）,建表的时候用fields terminated by ‘\001’。注意：如果采用\t或者\001等为分隔符，需要要求前端埋点和javaEE后台传递过来的数据必须不能出现该分隔符，通过代码规范约束。一旦传输过来的数据含有分隔符，需要在前一级数据中转义或者替换（ETL）。
可以设置参数（导入HDFS同样有效）：
–hive-drop-import-delims 导入到hive时删除 \n, \r, \001
–hive-delims-replacement 导入到hive时用自定义的字符替换掉 \n, \r, \001
字段包含分隔符存在的问题：

添加参数的效果：
在Hive表里的体现：

11 Tez引擎优点？
Tez可以将多个有依赖的作业转换为一个作业，这样只需写一次HDFS，且中间节点较少，从而大大提升作业的计算性能。
Mr/tez/spark区别：
Mr引擎：多job串联，基于磁盘，落盘的地方比较多。虽然慢，但一定能跑出结果。一般处理，周、月、年指标。
Spark引擎：虽然在Shuffle过程中也落盘，但是并不是所有算子都需要Shuffle，尤其是多算子过程，中间过程不落盘 DAG有向无环图。 兼顾了可靠性和效率。一般处理天指标。
Tez引擎：完全基于内存。 注意：如果数据量特别大，慎重使用。容易OOM。一般用于快速出结果，数据量比较小的场景。

13 Union与Union all区别
1）union会将联合的结果集去重，效率较union all差
2）union all不会对结果集去重，所以效率高

第七章 HBase

1、HBase存储架构

Hbase是由Client、Zookeeper、HMaster、HRegionServer、HRegin、Store(mem store 、StoreFile、HFile)、HDFS.
1）Client
Client包含了访问Hbase的接口，另外Client还维护了对应的cache来加速Hbase的访问，比如cache的.META.元数据的信息。
2）Zookeeper
HBase通过Zookeeper来做master的高可用、RegionServer的监控、元数据的入口以及集群配置的维护等工作。具体工作如下：
通过Zoopkeeper来保证集群中只有1个master在运行，如果master异常，会通过竞争机制产生新的master提供服务
通过Zoopkeeper来监控RegionServer的状态，当RegionSevrer有异常的时候，通过回调的形式通知Master RegionServer上下线的信息
通过Zoopkeeper存储元数据的统一入口地址

3）Hmaster
master节点的主要职责如下：
为RegionServer分配Region
维护整个集群的负载均衡
维护集群的元数据信息
发现失效的Region，并将失效的Region分配到正常的RegionServer上
当RegionSever失效的时候，协调对应Hlog的拆分
4）HregionServer
HregionServer直接对接用户的读写请求，是真正的“干活”的节点。它的功能概括如下：
管理master为其分配的Region
处理来自客户端的读写请求
负责和底层HDFS的交互，存储数据到HDFS
负责Region变大以后的拆分
负责Storefile的合并工作
5）HDFS
HDFS为Hbase提供最终的底层数据存储服务，同时为HBase提供高可用（Hlog存储在HDFS）的支持，具体功能概括如下：
提供元数据和表数据的底层分布式存储服务
数据多副本，保证的高可靠和高可用性
6) Write-Ahead logs
HBase的修改记录，当对HBase读写数据的时候，数据不是直接写进磁盘，它会在内存中保留一段时间（时间以及数据量阈值可以设定）。但把数据保存在内存中可能有更高的概率引起数据丢失，为了解决这个问题，数据会先写在一个叫做Write-Ahead logfile的文件中，然后再写入内存中。所以在系统出现故障的时候，数据可以通过这个日志文件重建。
7) Region
Hbase表的分片，HBase表会根据RowKey值被切分成不同的region存储在RegionServer中，在一个RegionServer中可以有多个不同的region。
8) Store
HFile存储在Store中，一个Store对应HBase表中的一个列族。
9) MemStore
顾名思义，就是内存存储，位于内存中，用来保存当前的数据操作，所以当数据保存在WAL中之后，RegsionServer会在内存中存储键值对。
10) HFile
这是在磁盘上保存原始数据的实际的物理文件，是实际的存储文件。StoreFile是以Hfile的形式存储在HDFS的。
（LRUCache）
2 RowKey设计原则
1）rowkey长度原则
2）rowkey散列原则
3）rowkey唯一原则
3 RowKey如何设计
1）生成随机数、hash、散列值
2）字符串反转
4、 HBase读流程

1）Client先访问zookeeper，从zk读取meta表读取region的位置，然后读取meta表中的数据。meta中又存储了用户表的region信息；
2）根据namespace、表名和rowkey在meta表中找到对应的region信息；
3）找到这个region对应的regionserver；
4）查找对应的region；
5）先从MemStore找数据，如果没有，再到BlockCache里面读；
6）BlockCache还没有，再到StoreFile上读(为了读取的效率)；
7）如果是从StoreFile里面读取的数据，不是直接返回给客户端，而是先写入BlockCache（方便下次读取），再返回给客户端。

第八章 Spark

1 Spark解决什么问题
Hadoop主要解决，海量数据的存储和海量数据的分析计算。
Spark主要解决海量数据的分析计算。
2 Spark为什么会有自己的资源调度器
Hadoop的Yarn框架比Spark框架诞生的晚，所以Spark自己也设计了一套资源调度框架。
3 Spark运行模式
1）Local：运行在一台机器上。 测试用。
2）Standalone：是Spark自身的一个调度系统。 对集群性能要求非常高时用。国内很少使用。
3）Yarn：采用Hadoop的资源调度器。 国内大量使用。
4）Mesos：国内很少使用。
4 Spark常用端口号
1）4040 spark-shell任务端口
2）7077 内部通讯端口。 类比Hadoop的8020/9000
3）8080 查看任务执行情况端口。 类比Hadoop的8088
4）18080 历史服务器。类比Hadoop的19888
注意：由于Spark只负责计算，所有并没有Hadoop中存储数据的端口50070
5 简述Spark的架构与作业提交流程
1.脚本启动执行，解析参数，创建客户端，提交任务信息到RM
2.RM启动Applicationmaster
3.AM根据参数，启动Driver，并初始化SparkContext
4.AM向RM注册AM，并申请资源
5.RM返回可用资源
6.启动Executor
7.向Driver注册Executor
8.Driver向executor响应注册成功
9.创建Executor执行对象
10.向Driver告知Executor启动成功。

6 Spark任务使用什么进行提交，JavaEE界面还是脚本
JavavEE界面
7 Spark提交作业参数
spark-submit -- master local[16] --driver-cores 2 --driver-memeory 8g --executor-cores 10 --executor-memeory 8g --class PackageName.ClassName XXXX.jar --name "spark job name" inputpath outputpath
8 RDD的五大属性

1. 一组分片（Partition），即数据集的基本组成单位。对于RDD来说，每个分片都会被一个计算任务处理，并决定并行计算的粒度。用户可以在创建RDD时指定RDD的分片个数，如果没有指定，那么就会采用默认值。默认值就是程序所分配到的CPU Core的数目。

2. 一个计算每个分区的函数。Spark中RDD的计算是以分片为单位的，每个RDD都会实现compute函数以达到这个目的。compute函数会对迭代器进行复合，不需要保存每次计算的结果。

3. RDD之间的依赖关系。RDD的每次转换都会生成一个新的RDD，所以RDD之间就会形成类似于流水线一样的前后依赖关系。在部分分区数据丢失时，Spark可以通过这个依赖关系重新计算丢失的分区数据，而不是对RDD的所有分区进行重新计算。

4. 一个Partitioner，即RDD的分片函数。当前Spark中实现了两种类型的分片函数，一个是基于哈希的HashPartitioner，另外一个是基于范围的RangePartitioner。只有对于于key-value的RDD，才会有Partitioner，非key-value的RDD的Parititioner的值是None。Partitioner函数不但决定了RDD本身的分片数量，也决定了parent RDD Shuffle输出时的分片数量。

5. 一个列表，存储存取每个Partition的优先位置（preferred location）。对于一个HDFS文件来说，这个列表保存的就是每个Partition所在的块的位置。按照“移动数据不如移动计算”的理念，Spark在进行任务调度的时候，会尽可能地将计算任务分配到其所要处理数据块的存储位置。
   9 Spark的transformation算子
   1）单Value
   （1）map
   （2）mapPartitions
   （3）mapPartitionsWithIndex
   （4）flatMap
   （5）glom
   （6）groupBy
   （7）filter
   （8）sample
   （9）distinct
   （10）coalesce
   （11）repartition
   （12）sortBy
   （13）pipe
   2）双vlaue
   （1）intersection
   （2）union
   （3）subtract
   （4）zip
   3）Key-Value
   （1）partitionBy
   （2）reduceByKey
   （3）groupByKey
   （4）aggregateByKey
   （5）foldByKey
   （6）combineByKey
   （7）sortByKey
   （8）mapValues
   （9）join
   （10）cogroup
   10 Spark的action算子
   （1）reduce：
   （2）collect:
   （3）count
   （4）first：
   （5）take：
   （6）takeOrdered
   （7）aggregate：
   （8）fold
   （9）countByKey：
   （10）save
   （11）foreach：
   11 map和mapPartitions区别
   1）map：每次处理一条数据
   2）mapPartitions：每次处理一个分区数据
   12 Repartition和Coalesce区别
   1）关系：
   两者都是用来改变RDD的partition数量的，repartition底层调用的就是coalesce方法：coalesce(numPartitions, shuffle = true)
   2）区别：
   repartition一定会发生shuffle，coalesce根据传入的参数来判断是否发生shuffle
   一般情况下增大rdd的partition数量使用repartition，减少partition数量时使用coalesce
   13 reduceByKey与groupByKey的区别
   reduceByKey：具有预聚合操作
   groupByKey：没有预聚合
   在不影响业务逻辑的前提下，优先采用reduceByKey。
   14 reduceByKey、foldByKey、aggregateByKey、combineByKey区别
   ReduceByKey 没有初始值 分区内和分区间逻辑相同
   foldByKey 有初始值 分区内和分区间逻辑可以相同
   aggregateByKey 有初始值 分区内和分区间逻辑可以不同
   combineByKey 初始可以变化结构 分区内和分区间逻辑不同
   15 Kryo序列化
   Kryo序列化比Java序列化更快更紧凑，但Spark默认的序列化是Java序列化并不是Spark序列化，因为Spark并不支持所有序列化类型，而且每次使用都必须进行注册。注册只针对于RDD。在DataFrames和DataSet当中自动实现了Kryo序列化。
   16 Spark中的血缘
   宽依赖和窄依赖。有Shuffle的是宽依赖。
   17 Spark任务的划分
   （1）Application：初始化一个SparkContext即生成一个Application；
   （2）Job：一个Action算子就会生成一个Job；
   （3）Stage：Stage等于宽依赖的个数加1；
   （4）Task：一个Stage阶段中，最后一个RDD的分区个数就是Task的个数。
   
   18 cache缓存级别
   DataFrame的cache默认采用 MEMORY_AND_DISK
   RDD 的cache默认方式采用MEMORY_ONLY
   19 释放缓存和缓存
   缓存：(1)dataFrame.cache (2)sparkSession.catalog.cacheTable(“tableName”)
   释放缓存：(1)dataFrame.unpersist (2)sparkSession.catalog.uncacheTable(“tableName”)
   20 缓存和检查点区别
   1）Cache缓存只是将数据保存起来，不切断血缘依赖。Checkpoint检查点切断血缘依赖。
   2）Cache缓存的数据通常存储在磁盘、内存等地方，可靠性低。Checkpoint的数据通常存储在HDFS等容错、高可用的文件系统，可靠性高。
   3）建议对checkpoint()的RDD使用Cache缓存，这样checkpoint的job只需从Cache缓存中读取数据即可，否则需要再从头计算一次RDD。
   21 Spark分区
   1）默认采用Hash分区
   缺点：可能导致每个分区中数据量的不均匀，极端情况下会导致某些分区拥有RDD的全部数据。
   2）Ranger分区：
   要求RDD中的KEY类型必须可以排序。
   3）自定义分区
   根据需求，自定义分区。
   22 Spark累加器
   
   23 Spark广播变量
   
   24 SparkSQL中RDD、DataFrame、DataSet三者的转换
   
   25 请列举会引起Shuffle过程的Spark算子
   reduceBykey：
   groupByKey：
   …ByKey:
   26 当Spark涉及到数据库的操作时，如何减少Spark运行中的数据库连接数？
   使用foreachPartition代替foreach，在foreachPartition内获取数据库的连接。
   27 如何使用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的排序算子进行排序

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

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

29 Spark内核源码
1）yarnCluster模式提交流程

2）Spark通讯架构

3）stage任务划分

4）task任务调度执行

5）hashshuffle流程

6）优化后的hashshuffle

7)sortshuffle流程

8）bypassshuffle

第九章 SparkStreaming

1 Spark Streaming第一次运行不丢失数据
kafka参数 auto.offset.reset 参数设置成earliest 从最初始偏移量开始消费数据
2 Spark Streaming精准一次消费

1. 手动维护偏移量
2. 处理完业务数据后，再进行提交偏移量操作
   极端情况下，如在提交偏移量时断网或停电会造成spark程序第二次启动时重复消费问题，所以在涉及到金额或精确性非常高的场景会使用事物保证精准一次消费
   3 Spark Streaming控制每秒消费数据的速度
   通过spark.streaming.kafka.maxRatePerPartition参数来设置Spark Streaming从kafka分区每秒拉取的条数
   4 Spark Streaming背压机制
   把spark.streaming.backpressure.enabled 参数设置为ture,开启背压机制后Spark Streaming会根据延迟动态去kafka消费数据,上限由spark.streaming.kafka.maxRatePerPartition参数控制，所以两个参数一般会一起使用
   5 Spark Streaming 一个stage耗时
   Spark Streaming stage耗时由最慢的task决定,所以数据倾斜时某个task运行慢会导致整个Spark Streaming都运行非常慢。

6 Spark Streaming 优雅关闭
把spark.streaming.stopGracefullyOnShutdown参数设置成ture,Spark会在JVM关闭时正常关闭StreamingContext,而不是立马关闭
Kill 命令：yarn application -kill 后面跟 applicationid
7 Spark Streaming 默认分区个数
Spark Streaming默认分区个数与所对接的kafka topic分区个数一致，Spark Streaming里一般不会使用repartition算子增大分区，因为repartition会进行shuffle增加耗时
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方式
9 简述SparkStreaming窗口函数的原理
窗口函数就是在原来定义的SparkStreaming计算批次大小的基础上再次进行封装，每次计算多个批次的数据，同时还需要传递一个滑动步长的参数，用来设置当次计算任务完成之后下一次从什么地方开始计算。