【无标题】

尚硅谷大数据技术之高频面试题
（作者：尚硅谷大数据研发部）

版本：V8.0.9
目录
第1章 项目涉及技术 11
1.1 Linux&Shell 11
1.1.1 Linux常用高级命令 11
1.1.2 Shell常用工具及写过的脚本 12
1.1.3 Shell中提交了一个脚本，进程号已经不知道了，但是需要kill掉这个进程，怎么操作? 12
1.1.4 Shell中单引号和双引号区别 12
1.2 Hadoop 13
1.2.1 Hadoop常用端口号 13
1.2.2 Hadoop配置文件以及简单的Hadoop集群搭建 13
1.2.3 HDFS读流程和写流程 13
1.2.4 HDFS小文件处理 14
1.2.5 Shuffle及优化 14
1.2.6 Yarn工作机制 17
1.2.7 Yarn调度器 17
1.2.8 项目经验之基准测试 18
1.2.9 Hadoop宕机 18
1.2.10 Hadoop解决数据倾斜方法 18
1.2.11 集群资源分配参数（项目中遇到的问题） 19
1.3 Zookeeper 19
1.3.1 选举机制 19
1.3.2 常用命令 20
1.3.3 Paxos算法（扩展） 20
1.3.4 讲一讲什么是CAP法则？Zookeeper符合了这个法则的哪两个？（扩展） 20
1.4 Flume 20
1.4.1 Flume组成，Put事务，Take事务 20
1.4.2 Flume拦截器 22
1.4.3 Flume Channel选择器 23
1.4.4 Flume监控器 23
1.4.5 Flume采集数据会丢失吗?（防止数据丢失的机制） 23
1.5 Kafka 23
1.5.1 Kafka架构 23
1.5.2 Kafka的机器数量 24
1.5.3 副本数设定 24
1.5.4 Kafka压测 25
1.5.5 Kafka日志保存时间 25
1.5.6 Kafka中数据量计算 25
1.5.7 Kafka的硬盘大小 25
1.5.8 Kafka监控 25
1.5.9 Kakfa分区数 25
1.5.10 多少个Topic 26
1.5.11 Kafka的ISR副本同步队列 26
1.5.12 Kafka分区分配策略 26
1.5.13 Kafka挂掉 26
1.5.14 Kafka丢不丢数据 27
1.5.15 Kafka数据重复 27
1.5.16 Kafka消息数据积压，Kafka消费能力不足怎么处理？ 27
1.5.17 Kafka参数优化 27
1.5.18 Kafka高效读写数据 28
1.5.19 Kafka单条日志传输大小 28
1.5.20 Kafka过期数据清理 28
1.5.21 Kafka可以按照时间消费数据 29
1.5.22 Kafka消费者角度考虑是拉取数据还是推送数据 29
1.5.23 Kafka中的数据是有序的吗 29
1.6 Hive 29
1.6.1 Hive的架构 29
1.6.2 Hive和数据库比较 29
1.6.3 内部表和外部表 30
1.6.4 4个By区别 30
1.6.5 系统函数 30
1.6.6 自定义UDF、UDTF函数 31
1.6.7 窗口函数 31
1.6.8 Hive优化 31
1.6.9 Hive解决数据倾斜方法 33
1.6.10 Hive里边字段的分隔符用的什么？为什么用\t？有遇到过字段里边有\t的情况吗，怎么处理的？ 35
1.6.11 Tez引擎优点？ 36
1.6.12 MySQL元数据备份 36
1.6.13 Union与Union all区别 37
1.7 Sqoop 37
1.7.1 Sqoop参数 37
1.7.2 Sqoop导入导出Null存储一致性问题 38
1.7.3 Sqoop数据导出一致性问题 38
1.7.4 Sqoop底层运行的任务是什么 38
1.7.5 Sqoop一天导入多少数据 38
1.7.6 Sqoop数据导出的时候一次执行多长时间 38
1.7.7 Sqoop在导入数据的时候数据倾斜 39
1.7.8 Sqoop数据导出Parquet（项目中遇到的问题） 39
1.8 Azkaban 39
1.8.1 每天集群运行多少指标? 39
1.8.2 任务挂了怎么办？ 39
1.9 HBase 40
1.9.1 HBase存储结构 40
1.9.2 RowKey设计原则 40
1.9.3 RowKey如何设计 40
1.9.4 Phoenix二级索引（讲原理） 40
1.10 Scala 41
1.10.1 开发环境 41
1.10.2 变量和数据类型 41
1.10.3 流程控制 41
1.10.4 函数式编程 41
1.10.5 面向对象 41
1.10.6 集合 41
1.10.7 模式匹配 41
1.10.8 异常 41
1.10.9 隐式转换 41
1.10.10 泛型 41
1.11 Spark Core & SQL 41
1.11.1 Spark有几种部署方式？请分别简要论述 41
1.11.2 Spark任务使用什么进行提交，JavaEE界面还是脚本 42
1.11.3 Spark提交作业参数（重点） 42
1.11.4 简述Spark的架构与作业提交流程（画图讲解，注明各个部分的作用）（重点） 43
1.11.5 如何理解Spark中的血统概念（RDD）（笔试重点） 43
1.11.6 简述Spark的宽窄依赖，以及Spark如何划分stage，每个stage又根据什么决定task个数? （笔试重点） 44
1.11.7 请列举Spark的transformation算子（不少于8个），并简述功能（重点） 44
1.11.8 请列举Spark的action算子（不少于6个），并简述功能（重点） 45
1.11.9 请列举会引起Shuffle过程的Spark算子，并简述功能。 45
1.11.10 简述Spark的两种核心Shuffle（HashShuffle与SortShuffle）的工作流程（包括未优化的HashShuffle、优化的HashShuffle、普通的SortShuffle与bypass的SortShuffle）（重点） 45
1.11.11 Spark常用算子reduceByKey与groupByKey的区别，哪一种更具优势？（重点） 47
1.11.12 Repartition和Coalesce关系与区别 48
1.11.13 分别简述Spark中的缓存机制（cache和persist）与checkpoint机制，并指出两者的区别与联系 48
1.11.14 简述Spark中共享变量（广播变量和累加器）的基本原理与用途。（重点） 48
1.11.15 当Spark涉及到数据库的操作时，如何减少Spark运行中的数据库连接数？ 49
1.11.16 如何使用Spark实现TopN的获取（描述思路或使用伪代码）（重点） 49
1.11.17 京东：调优之前与调优之后性能的详细对比（例如调整map个数，map个数之前多少、之后多少，有什么提升） 49
1.11.18 简述SparkSQL中RDD、DataFrame、DataSet三者的区别与联系? （笔试重点） 49
1.11.19 append和overwrite的区别 51
1.11.20 coalesce和repartition的区别 51
1.11.21 cache缓存级别 51
1.11.22 释放缓存和缓存 51
1.11.23 Spark Shuffle默认并行度 51
1.11.24 kryo序列化 51
1.11.25 创建临时表和全局临时表 51
1.11.26 BroadCast join 广播join 51
1.11.27 控制Spark reduce缓存 调优shuffle 52
1.11.28 注册UDF函数 52
1.11.29 SparkSQL中join操作与left join操作的区别？ 52
1.12 Spark Streaming 52
1.12.1 Spark Streaming第一次运行不丢失数据 52
1.12.2 Spark Streaming精准一次消费 52
1.12.3 Spark Streaming控制每秒消费数据的速度 52
1.12.4 Spark Streaming背压机制 53
1.12.5 Spark Streaming 一个stage耗时 53
1.12.6 Spark Streaming 优雅关闭 53
1.12.7 Spark Streaming 默认分区个数 53
1.12.8 SparkStreaming有哪几种方式消费Kafka中的数据，它们之间的区别是什么？ 53
1.12.9 简述SparkStreaming窗口函数的原理（重点） 54
1.13 数据倾斜 55
1.13.1 数据倾斜表现 55
1.13.2 数据倾斜产生原因 55
1.13.3 解决数据倾斜思路 57
1.13.4 定位导致数据倾斜代码 58
1.13.5 查看导致数据倾斜的key分布情况 60
1.13.6 Spark 数据倾斜的解决方案 60
1.13.7 Spark数据倾斜处理小结 78
1.14 Flink 78
1.14.1 简单介绍一下 Flink 78
1.14.2 Flink跟Spark Streaming的区别 79
1.14.3 Flink集群有哪些角色？各自有什么作用？ 80
1.14.4 公司怎么提交的实时任务，有多少 Job Manager？ 80
1.14.5 Flink的并行度了解吗？Flink的并行度设置是怎样的？ 81
1.14.6 Flink的Checkpoint 存在哪里 81
1.14.7 Flink的三种时间语义 81
1.14.8 说说Flink中的窗口 81
1.14.9 Exactly-Once的保证 82
1.14.10 说一下Flink状态机制 83
1.14.11 Flink 中的Watermark机制 83
1.14.12 Flink分布式快照的原理是什么 83
1.14.13 介绍一下Flink的CEP机制 84
1.14.14 Flink CEP 编程中当状态没有到达的时候会将数据保存在哪里？ 84
第2章 项目架构 85
2.1 提高自信 85
2.2 数仓概念 86
2.3 系统数据流程设计 86
2.4 框架版本选型 86
2.5 服务器选型 88
2.6 集群规模 89
2.7 人员配置参考 90
2.7.1 整体架构 90
2.7.2 你们部门的职级等级，晋升规则 90
2.7.3 人员配置参考 90
第3章 数仓分层 91
3.1 数据仓库建模（绝对重点） 91
3.1.1 建模工具是什么？ 91
3.1.2 ODS层 91
3.1.3 DWD层 91
3.1.4 DWS层 93
3.1.5 DWT层 94
3.1.6 ADS层 94
3.2 ODS层做了哪些事？ 94
3.3 DWD层做了哪些事？ 94
3.3.1 数据清洗 94
3.3.2 清洗的手段 95
3.3.3 清洗掉多少数据算合理 95
3.3.4 脱敏 95
3.3.5 维度退化 95
3.3.6 压缩LZO 95
3.3.7 列式存储parquet 95
3.4 DWS层做了哪些事？ 95
3.4.1 DWS层有3-5张宽表（处理100-200个指标 70%以上的需求） 95
3.4.2 哪个宽表最宽？大概有多少个字段？ 95
3.4.3 具体用户行为宽表字段名称 95
3.5 ADS层分析过哪些指标 97
3.5.1 分析过的指标（一分钟至少说出30个指标） 97
3.5.2 留转G复活指标 97
3.5.3 哪个商品卖的好？ 98
3.6 ADS层手写指标 98
3.6.1 如何分析用户活跃？ 98
3.6.2 如何分析用户新增？vivo 98
3.6.3 如何分析用户1天留存？ 98
3.6.4 如何分析沉默用户？ 98
3.6.5 如何分析本周回流用户？ 99
3.6.6 如何分析流失用户？ 99
3.6.7 如何分析最近连续3周活跃用户数？ 99
3.6.8 如何分析最近七天内连续三天活跃用户数？ 99
3.7 分析过最难的指标 100
3.7.1 最近连续3周活跃用户 100
3.7.2 最近7天连续3天活跃用户数 100
3.7.3 运费分摊 100
第4章 生产经验—业务 101
4.1 电商常识 101
4.1.1 SKU和SPU 101
4.1.2 订单表跟订单详情表区别？ 101
4.2 埋点行为数据基本格式(基本字段) 101
4.2.1 页面 101
4.2.2 事件 103
4.2.3 曝光 103
4.2.4 启动 104
4.2.5 错误 105
4.2.6 埋点数据日志格式 105
4.3 电商业务流程 107
4.4 维度表和事实表（重点） 107
4.4.1 维度表 107
4.4.2 事实表 107
4.5 同步策略（重点） 108
4.6 关系型数据库范式理论 108
4.7 数据模型 109
4.8 拉链表（重点） 109
4.9 即席查询数据仓库 110
4.10 数据仓库每天跑多少张表，大概什么时候运行，运行多久？ 110
4.11 活动的话，数据量会增加多少？怎么解决？ 110
4.12 并发峰值多少？大概哪个时间点？ 111
4.13 数仓中使用的哪种文件存储格式 111
4.14 哪张表最费时间，有没有优化 111
4.15 用什么工具做权限管理 111
4.16 数仓当中数据多久删除一次 111
第5章 生产经验–测试上线相关 111
5.1 测试相关 111
5.1.1 公司有多少台测试服务器？ 111
5.1.2 测试环境什么样？ 111
5.1.3 测试数据哪来的？ 111
5.1.4 如何保证写的sql正确性 111
5.1.5 测试之后如何上线？ 112
5.2 项目实际工作流程 112
5.3 项目中实现一个需求大概多长时间 113
5.4 项目在3年内迭代次数，每一个项目具体是如何迭代的。公司版本迭代多久一次，迭代到哪个版本 114
5.5 项目开发中每天做什么事 114
5.6 实时项目数据计算 114
5.6.1 跑实时任务，怎么分配内存和CPU资源 114
5.6.2 跑实时任务，每天数据量多少？ 114
第6章 生产经验—技术 115
6.1 可视化报表工具 115
6.2 集群监控工具 115
6.3 项目中遇到的问题怎么解决的（重点*****） 115
6.4 Linux+Shell+Hadoop+ZK+Flume+kafka+Hive+Sqoop+Azkaban那些事 116
第7章 生产经验—热点问题 116
7.1 元数据管理（Atlas血缘系统） 116
7.2 数据质量监控（Griffin） 117
7.2.1 监控原则 117
7.2.2 数据质量实现 118
7.3 权限管理（Ranger） 118
7.4 数据治理 118
7.5 数据中台 119
7.5.1 什么是中台？ 119
7.5.2 传统项目痛点 120
7.5.3 各家中台 120
7.5.4 中台具体划分 121
7.5.5 中台使用场景 122
7.6 数据湖 122
7.7 埋点 123
7.8 电商运营经验 124
7.8.1 电商8类基本指标 124
7.8.2 直播指标 127
第8章 手写代码 131
8.1 基本算法 131
8.1.1 冒泡排序 131
8.1.2 二分查找 133
8.1.3 快排 135
8.1.4 归并 136
8.1.5 二叉树之Scala实现 137
8.2 开发代码 141
8.2.1 手写Spark-WordCount 141
8.3 手写HQL 142
8.3.1 手写HQL 第1题 142
8.3.2 手写HQL 第2题 143
8.3.3 手写HQL 第3题 145
8.3.4 手写HQL 第4题 146
8.3.5 手写HQL 第5题 147
8.3.6 手写HQL 第6题 151
8.3.7 手写HQL 第7题 152
8.3.8 手写SQL 第8题 153
8.3.9 手写HQL 第9题 154
8.3.10 手写HQL 第10题 156
8.3.11 手写HQL 第11题 159
第9章 JavaSE 164
9.1 HashMap底层源码，数据结构 164
9.2 Java自带哪几种线程池？ 167
9.3 HashMap和HashTable区别 168
9.4 TreeSet和HashSet区别 169
9.5 String buffer和String build区别 169
9.6 Final、Finally、Finalize 169
9.7 ==和Equals区别 170
第10章 Redis 170
10.1 缓存穿透、缓存雪崩、缓存击穿 170
10.2 哨兵模式 171
10.3 数据类型 171
10.4 持久化 171
11.5 悲观锁 172
11.6 乐观锁 172
第11章 MySql 172
11.1 MyISAM与InnoDB的区别 172
11.2 索引优化 172
11.3 b-tree和b+tree的区别 173
11.4 redis是单线程的，为什么那么快 173
11.5 MySQL的事务 173
第12章 JVM 175
12.1 JVM内存分哪几个区，每个区的作用是什么? 175
12.2 Java类加载过程? 176
12.3 java中垃圾收集的方法有哪些? 177
12.4 如何判断一个对象是否存活?(或者GC对象的判定方法) 177
12.5 什么是类加载器，类加载器有哪些? 178
12.6 简述Java内存分配与回收策略以及Minor GC和Major GC（full GC） 178
第13章 JUC 179
13.1 Synchronized与Lock的区别 179
13.2 Runnable和Callable的区别 179
13.3 什么是分布式锁 179
13.4 什么是分布式事务 179
第14章 面试说明 179
14.1 面试过程最关键的是什么？ 179
14.2 面试时该怎么说？ 179
14.3 面试技巧 180
14.3.1 六个常见问题 180
14.3.2 两个注意事项 181
14.3.3 自我介绍（控制在4分半以内，不超过5分钟） 181
第15章 LeetCode题目精选 181
15.1 两数之和 181
15.1.1 问题描述 181
15.1.2 参考答案 182
15.2 爬楼梯 182
15.2.1 问题描述 182
15.2.2 参考答案 183
15.3 翻转二叉树 183
15.3.1 问题描述 184
15.3.2 参考答案 184
15.4 反转链表 185
15.4.1 问题描述 185
15.4.2 参考答案 185
15.5 LRU缓存机制 186
15.5.1 问题描述 186
15.5.2 参考答案 186
15.6 最长回文子串 188
15.6.1 问题描述 188
15.6.2 参考答案 188
15.7 有效的括号 189
15.7.1 问题描述 189
15.7.2 参考答案 190
15.8 数组中的第K个最大元素 192
15.8.1 问题描述 192
15.8.2 参考答案 193
15.9 实现 Trie (前缀树) 195
15.9.1 问题描述 195
15.9.2 参考答案 195
15.10 编辑距离 197
15.10.1 问题描述 197
15.10.2 参考答案 198

第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
sed
sed是一种流编辑器，它一次处理一行内容。处理时，把当前处理的行存储在临时缓冲区中，称为“模式空间”，接着用sed命令处理缓冲区中的内容，处理完成后，把缓冲区的内容送往屏幕。接着处理下一行，这样不断重复，直到文件末尾。文件内容并没有改变，除非你使用重定向存储输出。

2）用Shell写过哪些脚本
（1）集群启动，分发脚本
（2）数仓与MySQL的导入导出
（3）数仓层级内部的导入：ods->dwd->dws->dwt->ads
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/atguigu/bin创建一个test.sh文件
[atguigu@hadoop102 bin]$ vim test.sh
在文件中添加如下内容
#!/bin/bash
do_date=$1

echo ‘$d{o}_{d}at{e}^{\prime }echo"$do_date"
echo “'$d{o}_{d}at{e}^{\prime }"ech{o}^{\prime }"$do_date”’
echo date
2）查看执行结果
[atguigu@hadoop102 bin]$ test.sh 2019-02-10
$d{o}_{d}ate2019-02-10^{\prime }2019-02-10^{\prime }"$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.4 HDFS小文件处理
1）会有什么影响
（1）存储层面：
1个文件块，占用namenode多大内存150字节
1亿个小文件150字节
1个文件块 * 150字节
128G能存储多少文件块？ 128 * 10241024*1024byte/150字节 = 9亿文件块
（2）计算层面：
每个小文件都会起到一个MapTask，占用了大量计算资源
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 HDFS的NameNode内存
1）Hadoop2.x系列，配置NameNode默认2000m
2）Hadoop3.x系列，配置NameNode内存是动态分配的
NameNode内存最小值1G，每增加100万个block，增加1G内存。
1.2.6 NameNode心跳并发配置

企业经验：dfs.namenode.handler.count=，比如集群规模（DataNode台数）为3台时，此参数设置为21。可通过简单的python代码计算该值，代码如下。
1.2.7 纠删码原理
CPU资源换存储空间。

1.2.8 异构存储（冷热数据分离）

1.2.9 Shuffle及优化
1、Shuffle过程

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文件中配置多目录（多磁盘）
1.2.10 Yarn工作机制

1.2.11 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.12 项目经验之基准测试
搭建完Hadoop集群后需要对HDFS读写性能和MR计算能力测试。测试jar包在hadoop的share文件夹下。
集群总吞吐量 = 带宽*集群节点个数/副本数
例如：100m/s * 10台/ 3= 333m/s
注意：如果测试数据在本地，那副本数-1。因为这个副本不占集群吞吐量。如果数据在集群外，向该集群上传，需要占用带宽。本公式就不用减1。
1.2.13 Hadoop宕机
1）如果MR造成系统宕机。此时要控制Yarn同时运行的任务数，和每个任务申请的最大内存。调整参数：yarn.scheduler.maximum-allocation-mb（单个任务可申请的最多物理内存量，默认是8192MB）
2）如果写入文件过快造成NameNode宕机。那么调高Kafka的存储大小，控制从Kafka到HDFS的写入速度。例如，可以调整Flume每批次拉取数据量的大小参数batchsize。
1.2.14 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.3 Zookeeper
1.3.1 选举机制
半数机制：2n+1，安装奇数台
10台服务器：3台
20台服务器：5台
100台服务器：11台
台数多，好处：提高可靠性；坏处：影响通信延时
1.3.2 常用命令
ls、get、create、delete
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选择器
Replicating：默认选择器。功能：将数据发往下一级所有通道
Multiplexing：选择性发往指定通道。
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
1.5.1 Kafka架构
生产者、Broker、消费者、ZK；
注意：Zookeeper中保存Broker id和消费者offsets等信息，但是没有生产者信息。

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 gzip snappy lz4
#默认发送不进行压缩，推荐配置一种适合的压缩算法，可以大幅度的减缓网络压力和Broker的存储压力。
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）零复制技术

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<TopicPartition, OffsetAndTimestamp> startOffsetMap = KafkaUtil.fetchOffsetsWithTimestamp(topic, sTime, kafkaProp);
1.5.22 Kafka消费者角度考虑是拉取数据还是推送数据
拉取数据
1.5.23 Kafka中的数据是有序的吗
单分区内有序；多分区，分区与分区间无序；
扩展：
kafka producer发送消息的时候，可以指定key:

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

有序解决方案：同一张表的数据 放到 同一个 分区
=> ProducerRecord里传入key，会根据key取hash算出分区号
=> key使用表名，如果有库名，拼接上库名
1.6 Hive
1.6.1 Hive的架构
Hive元数据默认存储在derby数据库，不支持多客户端访问，所以将元数据存储在MySQl，支持多客户端访问。

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 系统函数
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打印日志，出错或者数据异常，方便调试。
引入第三方jar包时，也需要。
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
1.6.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引擎
1.6.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个数
1.6.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表里的体现：

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
首先修改库的基字符集和数据库排序规则

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

确保这几个参数的value值为utf8mb4 如果不是使用set命令修改
如：set character_set_server = utf8mb4;
1.6.13 Union与Union all区别
1）union会将联合的结果集去重，效率较union all差
2）union all不会对结果集去重，所以效率高
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 KaTeX parse error: Undefined control sequence: \t at position 1203: …terminated-by "\̲t̲" --export-dir …{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:10开始执行，Sqoop任务一般情况20-30分钟的都有。取决于数据量（11.11，6.18等活动在1个小时左右）。
1.7.7 Sqoop在导入数据的时候数据倾斜
Sqoop参数撇嘴： split-by：按照自增主键来切分表的工作单元。
num-mappers：启动N个map来并行导入数据，默认4个；
1.7.8 Sqoop数据导出Parquet（项目中遇到的问题）
Ads层数据用Sqoop往MySql中导入数据的时候，如果用了orc（Parquet）不能导入，需转化成text格式
（1）创建临时表，把Parquet中表数据导入到临时表，把临时表导出到目标表用于可视化
（2）ads层建表的时候就不要建Parquet表
1.8 Azkaban
1.8.1 每天集群运行多少指标?
每天跑100多个指标，有活动时跑200个左右。
1.8.2 任务挂了怎么办？
1）运行成功或者失败都会发邮件、发钉钉、集成自动打电话（项目中遇到的问题）
2）最主要的解决方案就是重新跑。
3）报警网站http://www.onealert.com/
1.9 HBase
1.9.1 HBase存储结构

1.9.2 RowKey设计原则
1）rowkey长度原则
2）rowkey散列原则
3）rowkey唯一原则
1.9.3 RowKey如何设计
1）生成随机数、hash、散列值
2）字符串反转
1.9.4 Phoenix二级索引（讲原理）

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解决什么问题
回顾：Hadoop主要解决，海量数据的存储和海量数据的分析计算。
Spark主要解决海量数据的分析计算。
1.11.2 Spark为什么会有自己的资源调度器
Hadoop的Yarn框架比Spark框架诞生的晚，所以Spark自己也设计了一套资源调度框架。
1.11.3 Spark运行模式
1）Local：运行在一台机器上。 测试用。
2）Standalone：是Spark自身的一个调度系统。 对集群性能要求非常高时用。国内很少使用。
3）Yarn：采用Hadoop的资源调度器。 国内大量使用。
4）Mesos：国内很少使用。
1.11.4 Spark常用端口号
1）4040 spark-shell任务端口
2）7077 内部通讯端口。 类比Hadoop的8020/9000
3）8080 查看任务执行情况端口。 类比Hadoop的8088
4）18080 历史服务器。类比Hadoop的19888
注意：由于Spark只负责计算，所有并没有Hadoop中存储数据的端口50070
1.11.5 简述Spark的架构与作业提交流程（画图讲解，注明各个部分的作用）（重点）

1.11.6 Spark任务使用什么进行提交，JavaEE界面还是脚本
Shell脚本。
1.11.7 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.8 RDD五大属性

1.11.9 Spark的transformation算子（不少于8个）（重点）
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
1.11.10 Spark的action算子（不少于6个）（重点）
（1）reduce
（2）collect
（3）count
（4）first
（5）take
（6）takeOrdered
（7）aggregate
（8）fold
（9）countByKey
（10）save
（11）foreach
1.11.11 map和mapPartitions区别
1）map：每次处理一条数据
2）mapPartitions：每次处理一个分区数据
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 reduceByKey与groupByKey的区别
reduceByKey：具有预聚合操作
groupByKey：没有预聚合
在不影响业务逻辑的前提下，优先采用reduceByKey。
1.11.14 reduceByKey、foldByKey、aggregateByKey、combineByKey区别
ReduceByKey 没有初始值 分区内和分区间逻辑相同
foldByKey 有初始值 分区内和分区间逻辑相同
aggregateByKey 有初始值 分区内和分区间逻辑可以不同
combineByKey 初始值可以变化结构 分区内和分区间逻辑不同
1.11.15 Kryo序列化
Kryo序列化比Java序列化更快更紧凑，但Spark默认的序列化是Java序列化并不是Spark序列化，因为Spark并不支持所有序列化类型，而且每次使用都必须进行注册。注册只针对于RDD。在DataFrames和DataSet当中自动实现了Kryo序列化。
1.11.16 Spark中的血缘（笔试重点）
宽依赖和窄依赖。有Shuffle的是宽依赖。
1.11.17 Spark任务的划分
（1）Application：初始化一个SparkContext即生成一个Application；
（2）Job：一个Action算子就会生成一个Job；
（3）Stage：Stage等于宽依赖的个数加1；
（4）Task：一个Stage阶段中，最后一个RDD的分区个数就是Task的个数。

1.11.18 cache缓存级别
DataFrame的cache默认采用 MEMORY_AND_DISK
RDD 的cache默认方式采用MEMORY_ONLY
1.11.19 释放缓存和缓存
缓存：(1)dataFrame.cache (2)sparkSession.catalog.cacheTable(“tableName”)
释放缓存：(1)dataFrame.unpersist (2)sparkSession.catalog.uncacheTable(“tableName”)
1.11.20 缓存和检查点区别
1）Cache缓存只是将数据保存起来，不切断血缘依赖。Checkpoint检查点切断血缘依赖。
2）Cache缓存的数据通常存储在磁盘、内存等地方，可靠性低。Checkpoint的数据通常存储在HDFS等容错、高可用的文件系统，可靠性高。
3）建议对checkpoint()的RDD使用Cache缓存，这样checkpoint的job只需从Cache缓存中读取数据即可，否则需要再从头计算一次RDD。
1.11.21 Spark分区
1）默认采用Hash分区
缺点：可能导致每个分区中数据量的不均匀，极端情况下会导致某些分区拥有RDD的全部数据。
2）Ranger分区
要求RDD中的KEY类型必须可以排序。
3）自定义分区
根据需求，自定义分区。
1.11.22 Spark累加器

1.11.23 Spark广播变量

1.11.24 SparkSQL中RDD、DataFrame、DataSet三者的转换 （笔试重点）

1.11.25 请列举会引起Shuffle过程的Spark算子，并简述功能。
reduceBykey：
groupByKey：
…ByKey:

1.11.26 当Spark涉及到数据库的操作时，如何减少Spark运行中的数据库连接数？
使用foreachPartition代替foreach，在foreachPartition内获取数据库的连接。
1.11.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的排序算子进行排序
1.11.28 京东：调优之前与调优之后性能的详细对比（例如调整map个数，map个数之前多少、之后多少，有什么提升）
这里举个例子。比如我们有几百个文件，会有几百个map出现，读取之后进行join操作，会非常的慢。这个时候我们可以进行coalesce操作，比如240个map，我们合成60个map，也就是窄依赖。这样再shuffle，过程产生的文件数会大大减少。提高join的时间性能。
1.11.29 Spark Shuffle默认并行度
参数spark.sql.shuffle.partitions 决定 默认并行度200
1.11.30 控制Spark reduce缓存 调优shuffle
spark.reducer.maxSizeInFilght 此参数为reduce task能够拉取多少数据量的一个参数默认48MB，当集群资源足够时，增大此参数可减少reduce拉取数据量的次数，从而达到优化shuffle的效果，一般调大为96MB,，资源够大可继续往上调。

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

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中的数据倾斜表现：
有一个多几个Reduce卡住，卡在99.99%，一直不能结束。
各种container报错OOM
异常的Reducer读写的数据量极大，至少远远超过其它正常的Reducer
伴随着数据倾斜，会出现任务被kill等各种诡异的表现。
2）hive中数据倾斜
一般都发生在Sql中group by和join on上，而且和数据逻辑绑定比较深。
3）Spark中的数据倾斜
Spark中的数据倾斜，包括Spark Streaming和Spark Sql，表现主要有下面几种：
Executor lost，OOM，Shuffle过程出错；
Driver OOM；
单个Executor执行时间特别久，整体任务卡在某个阶段不能结束；
正常运行的任务突然失败；
1.13.2 数据倾斜产生原因
我们以Spark和Hive的使用场景为例。
他们在做数据运算的时候会涉及到，count distinct、group by、join on等操作，这些都会触发Shuffle动作。一旦触发Shuffle，所有相同key的值就会被拉到一个或几个Reducer节点上，容易发生单点计算问题，导致数据倾斜。
一般来说，数据倾斜原因有以下几方面：
1）key分布不均匀；

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）从业务和数据上解决数据倾斜
很多数据倾斜都是在数据的使用上造成的。我们举几个场景，并分别给出它们的解决方案。
有损的方法：找到异常数据，比如ip为0的数据，过滤掉
无损的方法：对分布不均匀的数据，单独计算
先对key做一层hash，先将数据随机打散让它的并行度变大，再汇集
数据预处理
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的执行时间都会变短了。具体原理如下图所示。

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<String, Long> randomPrefixRdd = rdd.mapToPair(
new PairFunction<Tuple2<Long,Long>, String, Long>() {
private static final long serialVersionUID = 1L;
@Override
public Tuple2<String, Long> call(Tuple2<Long, Long> tuple)
throws Exception {
Random random = new Random();
int prefix = random.nextInt(10);
return new Tuple2<String, Long>(prefix + “_” + tuple._1, tuple._2);
}
});

// 第二步，对打上随机前缀的key进行局部聚合。
JavaPairRDD<String, Long> localAggrRdd = randomPrefixRdd.reduceByKey(
new Function2<Long, Long, Long>() {
private static final long serialVersionUID = 1L;
@Override
public Long call(Long v1, Long v2) throws Exception {
return v1 + v2;
}
});

// 第三步，去除RDD中每个key的随机前缀。
JavaPairRDD<Long, Long> removedRandomPrefixRdd = localAggrRdd.mapToPair(
new PairFunction<Tuple2<String,Long>, Long, Long>() {
private static final long serialVersionUID = 1L;
@Override
public Tuple2<Long, Long> call(Tuple2<String, Long> tuple)
throws Exception {
long originalKey = Long.valueOf(tuple.1.split("")[1]);
return new Tuple2<Long, Long>(originalKey, tuple._2);
}
});

// 第四步，对去除了随机前缀的RDD进行全局聚合。
JavaPairRDD<Long, Long> globalAggrRdd = removedRandomPrefixRdd.reduceByKey(
new Function2<Long, Long, Long>() {
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处理数据量过多的问题。接着去除掉随机前缀，再次进行全局聚合，就可以得到最终的结果。具体原理见下图。

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<Tuple2<Long, Row>> rdd1Data = rdd1.collect()
// 然后使用Spark的广播功能，将小RDD的数据转换成广播变量，这样每个Executor就只有一份RDD的数据。
// 可以尽可能节省内存空间，并且减少网络传输性能开销。
final Broadcast<List<Tuple2<Long, Row>>> rdd1DataBroadcast = sc.broadcast(rdd1Data);

// 对另外一个RDD执行map类操作，而不再是join类操作。
JavaPairRDD<String, Tuple2<String, Row>> joinedRdd = rdd2.mapToPair(
new PairFunction<Tuple2<Long,String>, String, Tuple2<String, Row>>() {
private static final long serialVersionUID = 1L;
@Override
public Tuple2<String, Tuple2<String, Row>> call(Tuple2<Long, String> tuple)
throws Exception {
// 在算子函数中，通过广播变量，获取到本地Executor中的rdd1数据。
List<Tuple2<Long, Row>> rdd1Data = rdd1DataBroadcast.value();
// 可以将rdd1的数据转换为一个Map，便于后面进行join操作。
Map<Long, Row> rdd1DataMap = new HashMap<Long, Row>();
for(Tuple2<Long, Row> 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<String, String>(key, new Tuple2<String, Row>(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操作，也就不会发生数据倾斜。具体原理如下图所示。

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<Long, String> sampledRDD = rdd1.sample(false, 0.1);

// 对样本数据RDD统计出每个key的出现次数，并按出现次数降序排序。
// 对降序排序后的数据，取出top 1或者top 100的数据，也就是key最多的前n个数据。
// 具体取出多少个数据量最多的key，由大家自己决定，我们这里就取1个作为示范。

// 每行数据变为<key,1>
JavaPairRDD<Long, Long> mappedSampledRDD = sampledRDD.mapToPair(
new PairFunction<Tuple2<Long,String>, Long, Long>() {
private static final long serialVersionUID = 1L;
@Override
public Tuple2<Long, Long> call(Tuple2<Long, String> tuple)
throws Exception {
return new Tuple2<Long, Long>(tuple._1, 1L);
}
});

// 按key累加行数
JavaPairRDD<Long, Long> countedSampledRDD = mappedSampledRDD.reduceByKey(
new Function2<Long, Long, Long>() {
private static final long serialVersionUID = 1L;
@Override
public Long call(Long v1, Long v2) throws Exception {
return v1 + v2;
}
});

// 反转key和value,变为<value,key>
JavaPairRDD<Long, Long> reversedSampledRDD = countedSampledRDD.mapToPair(
new PairFunction<Tuple2<Long,Long>, Long, Long>() {
private static final long serialVersionUID = 1L;
@Override
public Tuple2<Long, Long> call(Tuple2<Long, Long> tuple)
throws Exception {
return new Tuple2<Long, Long>(tuple._2, tuple._1);
}
});

// 以行数排序key，取最多行数的key
final Long skewedUserid = reversedSampledRDD.sortByKey(false).take(1).get(0)._2;

// 从rdd1中分拆出导致数据倾斜的key，形成独立的RDD。
JavaPairRDD<Long, String> skewedRDD = rdd1.filter(
new Function<Tuple2<Long,String>, Boolean>() {
private static final long serialVersionUID = 1L;
@Override
public Boolean call(Tuple2<Long, String> tuple) throws Exception {
return tuple._1.equals(skewedUserid);
}
});

// 从rdd1中分拆出不导致数据倾斜的普通key，形成独立的RDD。
JavaPairRDD<Long, String> commonRDD = rdd1.filter(
new Function<Tuple2<Long,String>, Boolean>() {
private static final long serialVersionUID = 1L;
@Override
public Boolean call(Tuple2<Long, String> tuple) throws Exception {
return !tuple._1.equals(skewedUserid);
}
});

// rdd2，就是那个所有key的分布相对较为均匀的rdd。
// 这里将rdd2中，前面获取到的key对应的数据，过滤出来，分拆成单独的rdd，并对rdd中的数据使用flatMap算子都扩容100倍。
// 对扩容的每条数据，都打上0～100的前缀。
JavaPairRDD<String, Row> skewedRdd2 = rdd2.filter(
new Function<Tuple2<Long,Row>, Boolean>() {
private static final long serialVersionUID = 1L;
@Override
public Boolean call(Tuple2<Long, Row> tuple) throws Exception {
return tuple.1.equals(skewedUserid);
}
}).flatMapToPair(new PairFlatMapFunction<Tuple2<Long,Row>, String, Row>() {
private static final long serialVersionUID = 1L;
@Override
public Iterable<Tuple2<String, Row>> call(
Tuple2<Long, Row> tuple) throws Exception {
Random random = new Random();
List<Tuple2<String, Row>> list = new ArrayList<Tuple2<String, Row>>();
for(int i = 0; i < 100; i++) {
list.add(new Tuple2<String, Row>(i + "" + tuple._1, tuple._2));
}
return list;
}

    });

// 将rdd1中分拆出来的导致倾斜的key的独立rdd，每条数据都打上100以内的随机前缀。
// 然后将这个rdd1中分拆出来的独立rdd，与上面rdd2中分拆出来的独立rdd，进行join。
JavaPairRDD<Long, Tuple2<String, Row>> joinedRDD1 = skewedRDD.mapToPair(
new PairFunction<Tuple2<Long,String>, String, String>() {
private static final long serialVersionUID = 1L;
@Override
public Tuple2<String, String> call(Tuple2<Long, String> tuple)
throws Exception {
Random random = new Random();
int prefix = random.nextInt(100);
return new Tuple2<String, String>(prefix + “_” + tuple._1, tuple._2);
}
})
.join(skewedUserid2infoRDD)
.mapToPair(new PairFunction<Tuple2<String,Tuple2<String,Row>>, Long, Tuple2<String, Row>>() {
private static final long serialVersionUID = 1L;
@Override
public Tuple2<Long, Tuple2<String, Row>> call(
Tuple2<String, Tuple2<String, Row>> tuple)
throws Exception {
long key = Long.valueOf(tuple.1.split("")[1]);
return new Tuple2<Long, Tuple2<String, Row>>(key, tuple._2);
}
});

// 将rdd1中分拆出来的包含普通key的独立rdd，直接与rdd2进行join。
JavaPairRDD<Long, Tuple2<String, Row>> joinedRDD2 = commonRDD.join(rdd2);

// 将倾斜key join后的结果与普通key join后的结果，uinon起来。
// 就是最终的join结果。
JavaPairRDD<Long, Tuple2<String, Row>> joinedRDD = joinedRDD1.union(joinedRDD2);
1.13.6.6.3 方案实现原理
对于join导致的数据倾斜，如果只是某几个key导致了倾斜，可以将少数几个key分拆成独立RDD，并附加随机前缀打散成n份去进行join，此时这几个key对应的数据就不会集中在少数几个task上，而是分散到多个task进行join了。具体原理见下图。

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<String, Row> expandedRDD = rdd1.flatMapToPair(
new PairFlatMapFunction<Tuple2<Long,Row>, String, Row>() {
private static final long serialVersionUID = 1L;
@Override
public Iterable<Tuple2<String, Row>> call(Tuple2<Long, Row> tuple)
throws Exception {
List<Tuple2<String, Row>> list = new ArrayList<Tuple2<String, Row>>();
for(int i = 0; i < 100; i++) {
list.add(new Tuple2<String, Row>(0 + “_” + tuple._1, tuple._2));
}
return list;
}
});

// 其次，将另一个有数据倾斜key的RDD，每条数据都打上100以内的随机前缀。
JavaPairRDD<String, String> mappedRDD = rdd2.mapToPair(
new PairFunction<Tuple2<Long,String>, String, String>() {
private static final long serialVersionUID = 1L;
@Override
public Tuple2<String, String> call(Tuple2<Long, String> tuple)
throws Exception {
Random random = new Random();
int prefix = random.nextInt(100);
return new Tuple2<String, String>(prefix + “_” + tuple._1, tuple._2);
}
});

// 将两个处理后的RDD进行join即可。
JavaPairRDD<String, Tuple2<String, Row>> 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数据倾斜处理小结

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及多种图计算算法实现。
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程序在运行时主要有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.4 公司怎么提交的实时任务，有多少Job Manager？
1）我们使用yarn session模式提交任务；另一种方式是每次提交都会创建一个新的Flink 集群，为每一个job提供资源，任务之间互相独立，互不影响，方便管理。任务执行完成之后创建的集群也会消失。线上命令脚本如下：
bin/yarn-session.sh -n 7 -s 8 -jm 3072 -tm 32768 -qu root.. -nm - -d
其中申请7个 taskManager，每个 8 核，每个 taskmanager 有 32768M 内存。
2）集群默认只有一个 Job Manager。但为了防止单点故障，我们配置了高可用。对于standlone模式，我们公司一般配置一个主 Job Manager，两个备用 Job Manager，然后结合 ZooKeeper 的使用，来达到高可用；对于yarn模式，yarn在Job Mananger故障会自动进行重启，所以只需要一个，我们配置的最大重启次数是10次。
1.14.5 Flink的并行度了解吗？Flink的并行度设置是怎样的？
Flink中的任务被分为多个并行任务来执行，其中每个并行的实例处理一部分数据。这些并行实例的数量被称为并行度。我们在实际生产环境中可以从四个不同层面设置并行度：
操作算子层面(Operator Level)
执行环境层面(Execution Environment Level)
客户端层面(Client Level)
系统层面(System Level)
需要注意的优先级：算子层面>环境层面>客户端层面>系统层面。
1.14.6 Flink的Checkpoint 存在哪里
可以是内存，文件系统，或者 RocksDB。
1.14.7 Flink的三种时间语义
Event Time：是事件创建的时间。它通常由事件中的时间戳描述，例如采集的日志数据中，每一条日志都会记录自己的生成时间，Flink通过时间戳分配器访问事件时间戳。
Ingestion Time：是数据进入Flink的时间。
Processing Time：是每一个执行基于时间操作的算子的本地系统时间，与机器相关，默认的时间属性就是Processing Time。
1.14.8 说说Flink中的窗口
来一张官网经典的图：

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.9 Exactly-Once的保证
下级存储支持事务：Flink可以通过实现两阶段提交和状态保存来实现端到端的一致性语义。 分为以下几个步骤：
1）开始事务（beginTransaction）创建一个临时文件夹，来写把数据写入到这个文件夹里面
2）预提交（preCommit）将内存中缓存的数据写入文件并关闭
3）正式提交（commit）将之前写完的临时文件放入目标目录下。这代表着最终的数据会有一些延迟
4）丢弃（abort）丢弃临时文件
5）若失败发生在预提交成功后，正式提交前。可以根据状态来提交预提交的数据，也可删除预提交的数据。
下级存储不支持事务：
具体实现是幂等写入，需要下级存储具有幂等性写入特性。
1.14.10 说一下Flink状态机制
Flink在做计算的过程中经常需要存储中间状态，来避免数据丢失和状态恢复。选择的状态存储策略不同，会影响状态持久化如何和 checkpoint 交互。
Flink提供了三种状态存储方式：MemoryStateBackend、FsStateBackend、RocksDBStateBackend。
1.14.11 Flink 中的Watermark机制
Watermark 是一种衡量 Event Time 进展的机制，可以设定延迟触发
Watermark 是用于处理乱序事件的，而正确的处理乱序事件，通常用Watermark 机制结合 window 来实现；
数据流中的 Watermark 用于表示 timestamp 小于 Watermark 的数据，都已经到达了，因此，window 的执行也是由 Watermark 触发的。
1.14.12 Flink分布式快照的原理是什么
Flink的容错机制的核心部分是制作分布式数据流和操作算子状态的一致性快照。 这些快照充当一致性checkpoint，系统可以在发生故障时回滚。 Flink用于制作这些快照的机制在“分布式数据流的轻量级异步快照”中进行了描述。 它受到分布式快照的标准Chandy-Lamport算法的启发，专门针对Flink的执行模型而定制。

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.14.13 介绍一下Flink的CEP机制
CEP全称为Complex Event Processing，复杂事件处理
Flink CEP是在 Flink 中实现的复杂事件处理（CEP）库
CEP 允许在无休止的事件流中检测事件模式，让我们有机会掌握数据中重要的部分
一个或多个由简单事件构成的事件流通过一定的规则匹配，然后输出用户想得到的数据 —— 满足规则的复杂事件
1.14.14 Flink CEP 编程中当状态没有到达的时候会将数据保存在哪里？
在流式处理中，CEP 当然是要支持 EventTime 的，那么相对应的也要支持数据的迟到现象，也就是watermark的处理逻辑。CEP对未匹配成功的事件序列的处理，和迟到数据是类似的。在 Flink CEP的处理逻辑中，状态没有满足的和迟到的数据，都会存储在一个Map数据结构中，也就是说，如果我们限定判断事件序列的时长为5分钟，那么内存中就会存储5分钟的数据，这在我看来，也是对内存的极大损伤之一。