尚大数据技术之高频面试题9.0.5

  尚硅谷大数据技术之高频面试题   版本：V9.0.5 目录 第 1 章 核心技术...........................................................................................................................10 1.1 Linux&Shell......................................................................................................................10 1.1.1 Linux 常用高级命令 .............................................................................................10 1.1.2 Shell 常用工具及写过的脚本...............................................................................10 1.1.3 Shell 中单引号和双引号区别............................................................................... 11 1.2 Hadoop.............................................................................................................................. 11 1.2.1 Hadoop 常用端口号.............................................................................................. 11 1.2.2 Hadoop 配置文件..................................................................................................12 1.2.3 HDFS 读流程和写流程.........................................................................................12 1.2.4 HDFS 小文件处理.................................................................................................13 1.2.5 HDFS 的 NameNode 内存 ....................................................................................13 1.2.6 纠删码原理...........................................................................................................13 1.2.7 异构存储（冷热数据分离）...............................................................................14 1.2.8 Shuffle 及优化.......................................................................................................15 1.2.9 Yarn 工作机制 .......................................................................................................16 1.2.10 Yarn 调度器 .........................................................................................................16 1.2.11 HDFS 块大小.......................................................................................................17 1.2.12 Hadoop 脑裂原因及解决办法？ ........................................................................18 1.3 Zookeeper .........................................................................................................................18 1.3.1 常用命令...............................................................................................................18 1.3.2 选举机制...............................................................................................................18 1.3.3 Paxos 算法和 ZAB 协议 .......................................................................................19 1.3.4 Zookeeper 符合法则中哪两个？..........................................................................20 1.3.5 Zookeeper 脑裂......................................................................................................20 1.3.6 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.4.6 Flume 如何提高吞吐量.........................................................................................23 1.5 Kafka.................................................................................................................................23 1.5.1 Kafka 架构.............................................................................................................23 1.5.2 Kafka 生产端分区分配策略.................................................................................25 1.5.3 Kafka 丢不丢数据.................................................................................................26 1.5.4 Kafka 的 ISR 副本同步队列.................................................................................27 1.5.5 Kafka 数据重复.....................................................................................................27 1.5.6 Kafka 如何保证数据有序 or 怎么解决乱序........................................................29 1.5.7 Kafka 分区 Leader 选举规则................................................................................30 1.5.8 Kafka 中 AR 的顺序 .............................................................................................30 1.5.9 Kafka 日志保存时间.............................................................................................31 1.5.10 Kafka 过期数据清理...........................................................................................31 1.5.11 Kafka 为什么能高效读写数据 ...........................................................................32 1.5.12 自动创建主题.....................................................................................................33 1.5.13 副本数设定.........................................................................................................34 1.5.14 Kakfa 分区数.......................................................................................................34 1.5.15 Kafka 增加分区...................................................................................................34 1.5.16 Kafka 中多少个 Topic .........................................................................................35 1.5.17 Kafka 消费者是拉取数据还是推送数据 ...........................................................35 1.5.18 Kafka 消费端分区分配策略...............................................................................35 1.5.19 消费者再平衡的条件.........................................................................................36 1.5.20 指定 Offset 消费.................................................................................................37 1.5.21 指定时间消费.....................................................................................................37 1.5.22 Kafka 监控...........................................................................................................37 1.5.23 Kafka 数据积压...................................................................................................37 1.5.24 如何提升吞吐量.................................................................................................39 1.5.25 Kafka 中数据量计算...........................................................................................39 1.5.26 Kafka 的机器数量...............................................................................................39 1.5.27 Kafka 如何压测？...............................................................................................40 1.5.28 磁盘选择.............................................................................................................42 1.5.29 内存选择.............................................................................................................42 1.5.30 CPU 选择.............................................................................................................43 1 尚硅谷大数据技术之高频面试题 ————————————————————————————— 1.5.31 网络选择.............................................................................................................44 1.5.32 Kafka 挂掉...........................................................................................................44 1.5.33 服役新节点退役旧节点.....................................................................................44 1.5.34 Kafka 单条日志传输大小...................................................................................44 1.5.35 Kafka 参数优化...................................................................................................45 1.6 Hive...................................................................................................................................46 1.6.1 Hive 的架构...........................................................................................................46 1.6.2 HQL 转换为 MR 流程 ..........................................................................................46 1.6.3 Hive 和数据库比较...............................................................................................47 1.6.4 内部表和外部表...................................................................................................48 1.6.5 4 个 By 区别..........................................................................................................48 1.6.6 系统函数...............................................................................................................48 1.6.7 自定义 UDF、UDTF 函数 ..................................................................................49 1.6.8 窗口函数...............................................................................................................50 1.6.9 Hive 优化...............................................................................................................52 1.6.10 Hive 解决数据倾斜方法.....................................................................................58 1.6.11 Hive 的数据中含有字段的分隔符怎么处理？ .................................................63 1.6.12 MySQL 元数据备份............................................................................................63 1.6.13 如何创建二级分区表？.....................................................................................64 1.6.14 Union 与 Union all 区别......................................................................................64 1.7 Datax.................................................................................................................................65 1.7.1 DataX 与 Sqoop 区别............................................................................................65 1.7.2 速度控制...............................................................................................................65 1.7.3 内存调整...............................................................................................................66 1.7.4 空值处理...............................................................................................................66 1.7.5 配置文件生成脚本...............................................................................................67 1.7.6 DataX 一天导入多少数据 ....................................................................................67 1.7.7 Datax 如何实现增量同步 .....................................................................................67 1.8 Maxwell ............................................................................................................................67 1.8.1 Maxwell 与 Canal、FlinkCDC 的对比.................................................................67 1.8.2 Maxwell 好处 ........................................................................................................68 1.8.3 Maxwell 底层原理.................................................................................................68 1.8.4 全量同步速度如何...............................................................................................68 1.8.5 Maxwell 数据重复问题.........................................................................................68 1.9 DolphinScheduler 调度器.................................................................................................68 2 尚硅谷大数据技术之高频面试题 ————————————————————————————— 1.9.1 每天集群运行多少指标? .....................................................................................69 1.9.2 任务挂了怎么办？...............................................................................................69 1.10 Spark Core & SQL..........................................................................................................69 1.10.1 Spark 运行模式 ...................................................................................................69 1.10.2 Spark 常用端口号 ...............................................................................................69 1.10.3 RDD 五大属性 ....................................................................................................70 1.10.4 RDD 弹性体现在哪里 ........................................................................................70 1.10.5 Spark 的转换算子（8 个）.................................................................................70 1.10.6 Spark 的行动算子（5 个）.................................................................................71 1.10.7 map 和 mapPartitions 区别..................................................................................72 1.10.8 Repartition 和 Coalesce 区别 ..............................................................................72 1.10.9 reduceByKey 与 groupByKey 的区别 ................................................................72 1.10.10 Spark 中的血缘 .................................................................................................72 1.10.11 Spark 任务的划分..............................................................................................72 1.10.12 Spark 广播变量 .................................................................................................73 1.10.13 SparkSQL 中 RDD、DataFrame、DataSet 三者的转换 .................................74 1.10.14 Hive on Spark 和 Spark on Hive 区别...............................................................74 1.10.15 Spark 内核源码（重点） .................................................................................74 1.10.16 Spark 统一内存模型 .........................................................................................78 1.10.17 Spark 为什么比 MR 快？ .................................................................................79 1.10.18 Spark Shuffle 和 Hadoop Shuffle 区别？..........................................................79 1.10.19 Spark 提交作业参数（重点）..........................................................................80 1.10.20 Spark 任务使用什么进行提交，JavaEE 界面还是脚本.................................80 1.10.21 请列举会引起 Shuffle 过程的 Spark 算子，并简述功能。..........................80 1.10.22 Spark 操作数据库时，如何减少 Spark 运行中的数据库连接数？...............81 1.10.23 Spark 数据倾斜 .................................................................................................81 1.11 Spark Streaming ..............................................................................................................81 1.11.1 Spark Streaming 第一次运行不丢失数据 ..........................................................81 1.11.2 Spark Streaming 精准一次消费 ..........................................................................81 1.11.3 Spark Streaming 控制每秒消费数据的速度 ......................................................81 1.11.4 Spark Streaming 背压机制 ..................................................................................81 1.11.5 Spark Streaming 一个 stage 耗时........................................................................81 1.11.6 Spark Streaming 优雅关闭 ..................................................................................81 1.11.7 Spark Streaming 默认分区个数 ..........................................................................82 1.11.8 SparkStreaming 有哪几种方式消费 Kafka 中的数据，它们之间的区别是什么？ 3 尚硅谷大数据技术之高频面试题 ————————————————————————————— .........................................................................................................................................82 1.11.9 简述 SparkStreaming 窗口函数的原理（重点） .............................................82 1.12 Flink ................................................................................................................................83 1.12.1 Flink 基础架构组成？ ........................................................................................83 1.12.2 Flink 和 Spark Streaming 的区别...................................................................83 1.12.3 Flink 核心概念 ....................................................................................................84 1.12.4 你们公司 Flink 任务提交模式？ Flink 部署多少台机器？ ...........................84 1.12.5 Flink 任务的并行度是怎样设置的？资源一般如何配置？.............................85 1.12.6 Flink 的三种时间语义 ........................................................................................85 1.12.7 你对 Watermark 的认识.....................................................................................85 1.12.8 Watermark 多并行度下的传递、生成原理 .......................................................85 1.12.9 Flink 怎么处理乱序和迟到数据？ ....................................................................86 1.12.10 说说 Flink 中的窗口（分类、生命周期、触发、划分）.............................86 1.12.11 Flink 的 keyby 怎么实现的分区？分区、分组的区别是什么？...................87 1.12.12 Flink 的 Interval Join 的实现原理？Join 不上的怎么办？.............................87 1.12.13 介绍一下 Flink 的状态编程、状态机制？.....................................................88 1.12.14 实时项目当中有没有遇到大状态，如何调优？...........................................88 1.12.15 Flink 如何实现端到端一致性?.........................................................................88 1.12.16 Flink 分布式快照的原理是什么 ......................................................................89 1.12.17 Checkpoint 的参数怎么设置的？ ....................................................................89 1.12.18 介绍一下 Flink 的 CEP 机制，匹配不上的数据怎么办？ ...........................90 1.12.19 Flink SQL 的工作机制？..................................................................................90 1.12.20 FlinkSQL 怎么对 SQL 语句进行优化的？ .....................................................91 1.12.21 Flink 提交流程、内存模型（重点） ..............................................................93 1.12.22 Flink 反压产生原因&定位&解决（重点） ....................................................94 1.12.23 Flink 数据倾斜定位、分析、解决（重点）...................................................95 1.12.24 Flink 常见的维表 Join 方案..............................................................................96 1.12.25 FlinkCDC 锁表问题..........................................................................................96 1.13 HBase..............................................................................................................................96 1.13.1 HBase 存储结构..................................................................................................96 1.13.2 HBase 的写流程..................................................................................................98 1.13.3 HBase 的读流程..................................................................................................98 1.13.4 HBase 的刷写策略..............................................................................................99 1.13.5 Region 的切分.....................................................................................................99 1.13.6 HBase 的合并......................................................................................................99 4 尚硅谷大数据技术之高频面试题 ————————————————————————————— 1.13.7 RowKey 设计原则.............................................................................................100 1.13.8 RowKey 如何设计.............................................................................................100 1.13.9 HBase 二级索引原理........................................................................................101 1.14 Clickhouse.....................................................................................................................101 1.14.1 Clickhouse 的优势.............................................................................................101 1.14.2 Clickhouse 的引擎.............................................................................................102 1.14.3 Flink 写入 Clickhouse 怎么保证一致性？.......................................................102 1.14.4 Clickhouse 存储多少数据？几张表？.............................................................102 1.14.5 Clickhouse 使用本地表还是分布式表.............................................................102 1.14.6 Clickhouse 的物化视图.....................................................................................103 1.14.7 Clickhouse 连接 ZK 频繁超时解决办法..........................................................103 1.14.8 Clickhouse 的优化.............................................................................................103 1.14.9 Clickhouse 的新特性 Projection .......................................................................104 1.14.10 Cilckhouse 的索引、底层存储.......................................................................104 1.15 可视化报表工具..........................................................................................................105 1.16 Doris..............................................................................................................................106 1.17 Sqoop ............................................................................................................................106 1.18 Azkaban.........................................................................................................................107 1.19 JavaSE...........................................................................................................................108 1.19.1 什么是多线程&多线程的优点........................................................................108 1.19.2 如何创建多线程...............................................................................................108 1.19.3 如何创建线程池...............................................................................................108 1.19.4 ThreadPoolExecutor 构造函数参数解析..........................................................108 1.19.5 列举线程安全的 Map 集合..............................................................................109 1.19.6 StringBuffer 和 StringBuilder 的区别...............................................................109 1.19.7 ArrayList 和 LinkedList 的区别........................................................................109 1.19.8 HashMap 和 HashTable 的区别 ........................................................................109 1.19.9 HashMap 的底层原理 .......................................................................................109 1.19.10 HashMap 里面放 100 条数据，初始化应该是多少...................................... 111 1.20 MySQL ......................................................................................................................... 111 1.20.1 MyISAM 与 InnoDB 的区别 ............................................................................ 111 1.20.2 MySQL 四种索引.............................................................................................. 112 1.20.3 MySQL 的事务.................................................................................................. 112 1.20.4 MySQL 事务隔离级别...................................................................................... 113 1.20.5 MyISAM 与 InnoDB 对比 ................................................................................ 113 5 尚硅谷大数据技术之高频面试题 ————————————————————————————— 1.20.6 B 树和 B+树对比.............................................................................................. 113 1.21 Redis ............................................................................................................................. 114 1.21.1 Redis 缓存穿透、缓存雪崩、缓存击穿..........................................................114 1.21.2 Redis 哨兵模式.................................................................................................. 115 1.21.3 Redis 数据类型.................................................................................................. 115 1.21.4 热数据通过什么样的方式导入 Redis.............................................................115 1.21.5 Redis 的存储模式 RDB，AOF......................................................................... 115 1.21.6 Redis 存储的是 k-v 类型，为什么还会有 Hash？ .........................................116 1.21.7 Redis 和 HBase 的数据不一致问题................................................................. 116 1.22 JVM............................................................................................................................... 117 1.23 Hudi............................................................................................................................... 117 1.23.1 目前有哪些开源的数据湖组件....................................................................... 117 1.23.2 Hudi 有什么优势............................................................................................... 117 1.23.3 Hudi 表类型有哪些........................................................................................... 117 1.23.4 数据读取方式................................................................................................... 118 第 2 章 离线数仓项目................................................................................................................. 118 2.1 提高自信........................................................................................................................ 118 2.2 为什么做这个项目........................................................................................................ 119 2.3 数仓概念........................................................................................................................ 119 2.4 项目架构........................................................................................................................ 119 2.5 框架版本选型................................................................................................................120 2.6 服务器选型....................................................................................................................121 2.7 集群规模........................................................................................................................122 2.8 人员配置参考................................................................................................................123 2.8.1 整体架构.............................................................................................................123 2.8.2 人员配置参考.....................................................................................................123 2.8.3 你的的职级等级及晋升规则.............................................................................124 2.9 从 0-1 搭建项目，你需要做什么？.............................................................................125 2.10 数仓建模准备..............................................................................................................126 2.11 数仓建模......................................................................................................................128 2.12 数仓每层做了哪些事..................................................................................................131 2.13 数据量..........................................................................................................................133 2.14 项目中遇到哪些问题？（******）..........................................................................133 2.15 离线---业务..................................................................................................................134 2.15.1 SKU 和 SPU ......................................................................................................134 6 尚硅谷大数据技术之高频面试题 ————————————————————————————— 2.15.2 订单表跟订单详情表区别？...........................................................................134 2.15.3 上卷和下钻.......................................................................................................134 2.15.4 TOB 和 ToC 解释..............................................................................................135 2.15.5 流转 G 复活指标..............................................................................................135 2.15.6 活动的话，数据量会增加多少？怎么解决？...............................................135 2.15.7 哪个商品卖的好？...........................................................................................135 2.15.8 数据仓库每天跑多少张表，大概什么时候运行，运行多久？...................135 2.15.9 哪张表数据量最大...........................................................................................136 2.15.10 哪张表最费时间，有没有优化.....................................................................136 2.15.11 并发峰值多少？大概哪个时间点？.............................................................137 2.15.12 分析过最难的指标.........................................................................................137 2.15.13 数仓中使用的哪种文件存储格式.................................................................137 2.15.14 数仓当中数据多久删除一次.........................................................................137 2.16 埋点..............................................................................................................................138 第 3 章 实时数仓项目.................................................................................................................139 3.1 为什么做这个项目........................................................................................................139 3.2 项目架构........................................................................................................................139 3.3 框架版本选型................................................................................................................139 3.4 服务器选型....................................................................................................................140 3.5 集群规模........................................................................................................................140 3.6 项目建模........................................................................................................................140 3.7 数据量............................................................................................................................142 3.8 项目中遇到哪些问题？................................................................................................143 3.9 实时---业务....................................................................................................................143 3.9.1 数据采集到 ODS 层...........................................................................................143 3.9.2 ODS 层.................................................................................................................144 3.9.3 DWD+DIM 层.....................................................................................................144 3.9.4 DWS 层................................................................................................................145 3.9.5 ADS 层.................................................................................................................147 第 4 章 用户画像项目.................................................................................................................148 4.1 画像系统主要做了哪些事............................................................................................148 4.2 项目整体架构................................................................................................................148 4.3 讲一下标签计算的调度过程........................................................................................149 4.4 整个标签的批处理过程................................................................................................149 4.5 你们的画像平台有哪些功能 ？..................................................................................149 7 尚硅谷大数据技术之高频面试题 ————————————————————————————— 4.6 是否做过 Web 应用开发，实现了什么功能...............................................................149 4.7 画像平台的上下游.........................................................................................................150 4.8 BitMap 原理，及为什么可以提高性能........................................................................150 第 5 章 数据湖项目.....................................................................................................................150 5.1 数据湖与数据仓库对比................................................................................................150 5.2 为什么做这个项目........................................................................................................150 5.3 项目架构........................................................................................................................151 5.4 业务................................................................................................................................151 5.5 优化 or 遇到的问题怎么解决 ......................................................................................151 第 6 章 测试&上线流程..............................................................................................................151 6.1 测试相关........................................................................................................................151 6.1.1 公司有多少台测试服务器？.............................................................................151 6.1.2 测试服务器配置？.............................................................................................152 6.1.3 测试数据哪来的？.............................................................................................152 6.1.4 如何保证写的 SQL 正确性（重点） ...............................................................152 6.1.5 测试之后如何上线？.........................................................................................152 6.1.6 A/B 测试了解 ......................................................................................................152 6.2 项目实际工作流程........................................................................................................154 6.3 项目中实现一个需求大概多长时间............................................................................156 6.4 项目当前版本号是多少？多久升级一次版本............................................................156 6.5 项目开发中每天做什么事............................................................................................156 第 7 章 数据治理.........................................................................................................................157 7.1 元数据管理....................................................................................................................157 7.2 数据质量监控................................................................................................................158 7.2.1 监控原则.............................................................................................................158 7.2.2 数据质量实现.....................................................................................................159 7.3 权限管理（Ranger）....................................................................................................159 7.4 数据治理........................................................................................................................160 第 8 章 中台.................................................................................................................................162 8.1 什么是中台？................................................................................................................163 8.2 各家中台........................................................................................................................164 8.3 中台具体划分................................................................................................................164 8.4 中台使用场景................................................................................................................165 8.5 中台的痛点....................................................................................................................166 第 9 章 算法题（LeetCode）.....................................................................................................166 8 尚硅谷大数据技术之高频面试题 ————————————————————————————— 9.1 时间复杂度、空间复杂度理解....................................................................................166 9.2 常见算法求解思想........................................................................................................166 9.3 基本算法........................................................................................................................167 9.3.1 冒泡排序.............................................................................................................167 9.3.2 快速排序.............................................................................................................167 9.3.3 归并排序.............................................................................................................168 9.3.4 遍历二叉树.........................................................................................................169 9.3.5 二分查找.............................................................................................................169 9.4 小青蛙跳台阶................................................................................................................170 9.5 最长回文子串................................................................................................................170 9.6 数字字符转化成 IP .......................................................................................................170 第 10 章 场景题...........................................................................................................................171 10.1 手写 Flink 的 UV ........................................................................................................171 10.2 Flink 的分组 TopN .......................................................................................................171 10.3 Spark 的分组 TopN ......................................................................................................171 10.4 如何快速从 40 亿条数据中快速判断，数据 123 是否存在....................................171 10.5 给你 100G 数据，1G 内存，如何排序？.................................................................171 10.6 公平调度器容器集中在同一个服务器上？..............................................................171 10.7 匹马赛跑，1 个赛道，每次 5 匹进行比赛，无法对每次比赛计时，但知道每次比赛 结果的先后顺序，最少赛多少次可以找出前三名？.......................................................171 10.8 给定一个点、一条线、一个三角形、一个有向无环图，请用 java 面向对象的思想 进行建模...............................................................................................................................172 第 11 章 HQL 场景题..................................................................................................................172 第 12 章 面试说明.......................................................................................................................172 12.1 面试过程最关键的是什么？......................................................................................172 12.2 面试时该怎么说？......................................................................................................172 12.3 面试技巧......................................................................................................................172 12.3.1 六个常见问题...................................................................................................172 12.3.2 两个注意事项...................................................................................................173 12.3.3 自我介绍...........................................................................................................173 9 尚硅谷大数据技术之高频面试题 ————————————————————————————— 10 第 1 章 核心技术 1.1 Linux&Shell 1.1.1 Linux 常用高级命令 序号 命令 命令解释 1 top 实时显示系统中各个进程的资源占用状况（CPU、内存和 执行时间） 2 jmap -heap 进程号 查看某个进程内存 3 free -m 查看系统内存使用情况 4 ps -ef 查看进程 5 netstat -tunlp | grep 端口号 查看端口占用情况 6 du -sh 路径* 查看路径下的磁盘使用情况 例如：$ du -sh /opt/* 7 df -h 查看磁盘存储情况 1.1.2 Shell 常用工具及写过的脚本 1）awk、sed、cut、sort 2）用 Shell 写过哪些脚本 （1）集群启动，分发脚本 #!/bin/bash case $1 in "start") for i in hadoop102 hadoop103 hadoop104 do ssh $i "绝对路径" done ;; "stop") ;; esac （2）数仓层级内部的导入：ods->dwd->dws ->ads ①#!/bin/bash ②定义变量 APP=gmall ③获取时间 传入 按照传入时间 尚硅谷大数据技术之高频面试题 ————————————————————————————— 11 不传 T+1 ④sql=" 先按照当前天 写 sql => 遇到时间 $do_date 遇到表 {$APP}. 自定义函数 UDF UDTF {$APP}. " ⑤执行 sql 1.1.3 Shell 中单引号和双引号区别 1）在/home/atguigu/bin 创建一个 test.sh 文件 [atguigu@hadoop102 bin]$ vim test.sh 在文件中添加如下内容 #!/bin/bash do_date=$1 echo '$do_date' echo "$do_date" echo "'$do_date'" echo '"$do_date"' echo `date` 2）查看执行结果 [atguigu@hadoop102 bin]$ test.sh 2022-02-10 $do_date 2022-02-10 '2022-02-10' "$do_date" 2022 年 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 尚硅谷大数据技术之高频面试题 ————————————————————————————— 12 1.2.2 Hadoop 配置文件 配置文件： 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 1.2.3 HDFS 读流程和写流程 1 请求下载文件/user/atguigu/ss.avi 2 返回目标文件的元数据 NameNode 元数据 DataNode1 DataNode2 DataNode3 ss.avi 0-128m 200m 3 请求读数据blk_1 4 传输数据 7 blk_1 HDFS的读数据流程 /user/atguigu/ss.avi {[blk_1,blk_2],[blk_1,blk_2],[blk_1,blk_2]} 7 blk_2 5 请求读数据blk_2 6 传输数据 7 blk_2 7 blk_1 7 blk_2 7 blk_1 客户端 Distributed FileSystem FSDataInpu tStream HDFS client create read close 1 向NameNode请求上传文件/user/atguigu/ss.avi 2 响应可以上传文件 3 请求上传第一个Block（0-128M），请返回DataNode 4返回dn1，dn2，dn3节点，表示采用这三个节点存储数据 NameNode 客户端 元数据 DataNode1 DataNode2 DataNode3 ss.avi 0-128m 200m 5 请求建立Block传输通道 Bytebuffer Bytebuffer Bytebuffer 6 dn1应答成功 6 dn3应答成功 6 dn2应答成功 5 请求建立通道 5 请求建立通道 7 传输数据 Packet（64k） packet（chunk512byte+chunksum4byte） 7 blk_1 7 blk_1 7 blk_1 HDFS的写数据流程 8 传输数据完成 Distributed FileSystem FSDataOu tputStream HDFS client create write close 检查目录树是否可以创建文件 2.1检查权限； 2.2检查目录结构（目录是否存在） 副本存储节点选择 4.1本地节点 4.2其他机架一个节点 4.3 其他机架另一个节点 注意：HDFS 写入流程时候，某台 dataNode 挂掉如何运行？ 当 DataNode 突然挂掉了，客户端接收不到这个 DataNode 发送的 ack 确认，客户端会通 知 NameNode，NameNode 检查并确认该块的副本与规定的不符，NameNode 会通知闲置的 尚硅谷大数据技术之高频面试题 ————————————————————————————— 13 DataNode 去复制副本，并将挂掉的 DataNode 作下线处理。等挂掉的 DataNode 节点恢复后, 删除该节点中曾经拷贝的不完整副本数据。 1.2.4 HDFS 小文件处理 1）会有什么影响 （1）存储层面 1 个文件块，占用 namenode 多大内存 150 字节 128G 能存储多少文件块？ 128 g* 1024m*1024kb*1024byte/150 字节 = 9.1 亿文 件块 （2）计算层面 每个小文件都会起到一个 MapTask，1 个 MapTask 默认内存 1G。浪费资源。 2）怎么解决 （1）采用 har 归档方式，将小文件归档 （2）采用 CombineTextInputFormat （3）自己写一个 MR 程序将产生的小文件合并成一个大文件。如果是 Hive 或者 Spark 有 merge 功能自动帮助我们合并。 （4）有小文件场景开启 JVM 重用；如果没有小文件，不要开启 JVM 重用，因为会一 直占用使用到的 Task 卡槽，直到任务完成才释放。 JVM 重用可以使得 JVM 实例在同一个 job 中重新使用 N 次，N 的值可以在 Hadoop 的 mapred-site.xml 文件中进行配置。通常在 10-20 之间。 <property> <name>mapreduce.job.jvm.numtasks</name> <value>10</value> <description>How many tasks to run per jvm,if set to -1 ,there is no limit</description> </property> 1.2.5 HDFS 的 NameNode 内存 1）Hadoop2.x 系列，配置 NameNode 默认 2000m 2）Hadoop3.x 系列，配置 NameNode 内存是动态分配的 NameNode 内存最小值 1G，每增加 100 万个文件 block，增加 1G 内存。 1.2.6 纠删码原理 CPU 资源换取存储空间。 尚硅谷大数据技术之高频面试题 ————————————————————————————— 14 HDFS 默认情况下，一个文件有 3 个副本，这样提高了数据的可靠性，但也带来了 2 倍 的冗余开销。Hadoop3.x 引入了纠删码，采用计算的方式，可以节省约 50％左右的存储空间。 1.2.7 异构存储（冷热数据分离） 期望经常使用的数据存储在固态硬盘或者内存镜像硬盘；不经常使用的历史数据存储在 老旧的破旧硬盘。 RAM_DISK：（内存镜像文件系统） SSD：（SSD固态硬盘） DISK：（普通磁盘，在HDFS中，如果没有主动声明数据目录存储类型默认都是DISK） ARCHIVE：（没有特指哪种存储介质，主要的指的是计算能力比较弱而存储密度比较高的存储介质，用来解决数据量的 容量扩增的问题，一般用于归档） 1）关于存储类型 2）关于存储策略 策略ID 策略名称 副本分布 15 Lazy_Persist RAM_DISK:1，DISK:n-1 12 All_SSD SSD:n 10 One_SSD SSD:1，DISK:n-1 7 Hot(default) DISK:n 5 Warm DSIK:1，ARCHIVE:n-1 2 Cold ARCHIVE:n 说明：从Lazy_Persist到Cold，分别代表了设备的访问速度从快到慢 一个副本保存在内存RAM_DISK中，其余副本保存在磁盘中。 所有副本都保存在SSD中。 一个副本保存在SSD中，其余副本保存在磁盘中。 Hot：所有副本保存在磁盘中，这也是默认的存储策略。 一个副本保存在磁盘上，其余副本保存在归档存储上。 所有副本都保存在归档存储上。 存储类型和存储策略 尚硅谷大数据技术之高频面试题 ————————————————————————————— 15 1.2.8 Shuffle 及优化 MapReduce优化（上） Map1方法 分区1 分区2 写入<k,v>数据 第一次溢出 排序 第二次溢出 Combiner Combiner 归并排序 归并排序 合并 Combiner为可选流程 压缩 写磁盘 分区1 分区2 分区1 排序 分区2 排序 排序 分区1 排序 分区2 排序 分区1 合并 分区2 合并 分区1 合并 分区2 合并 分区1 归并 分区2 归并 分区1 压缩 分区2 压缩 分区1 输出 分区2 输出 分区1 合并 分区2 合并 combiner 分区 分区 kvindex bufindex <k,v> kvmeta spill.index Spill.out spill.index Spill.out 默认100M 80%,后反向 环形缓冲区 2）减少溢写的次数 mapreduce.task.io.sort.mb Shuffle的环形缓冲区大小，默认100m，可以提高到200m mapreduce.map.sort.spill.percent 环形缓冲区溢出的阈值，默认80% ，可以提高的90% 9）异常重试 mapreduce.map.maxattempts每个Map Task最大重试次数，一旦重试 次数超过该值，则认为Map Task运行失败，默认值：4。根据机器 性能适当提高。 1）自定义分区，减少数据倾斜; 定义类，实现Partitioner接口，重写getPartition方法 4）在不影响业务结果的前提条件下可以提前采用Combiner job.setCombinerClass(xxxReducer.class); 5）为了减少磁盘IO，可以采用Snappy或者LZO压缩 conf.setBoolean("mapreduce.map.output.compress", true); conf.setClass("mapreduce.map.output.compress.codec", SnappyCodec.class,CompressionCodec.class); 3）增加每次Merge合并次数 mapreduce.task.io.sort.factor默认10，可以提高到20 6）mapreduce.map.memory.mb 默认MapTask内存上限1024MB。 可以根据128m数据对应1G内存原则提高该内存。 8）mapreduce.map.cpu.vcores 默认MapTask的CPU核数1。计算密集型任 务可以增加CPU核数 7）mapreduce.map.java.opts：控制MapTask堆内存大小。（如果内存不够， 报：java.lang.OutOfMemoryError） MapReduce优化（下） 分区1 输出 分区2 输出 分区1 输出 分区2 输出 分区1 输出 分区1 输出 内存缓冲 磁盘 数据 内存不够溢出到磁盘 归并 排序 分组 Reduce方法 对每个map来的 数据归并排序 按照相同key分组 Map2方法 输出数据 Map1方法 输出数据 Reduce1处理流程 拷贝 拷贝 4）mapreduce.reduce.memory.mb 默认ReduceTask内存上限1024MB， 根据128m数据对应1G内存原则，适当提高内存到4-6G 6）mapreduce.reduce.cpu.vcores默认ReduceTask的CPU核数1个。可 以提高到2-4个 1）mapreduce.reduce.shuffle.parallelcopies每个Reduce去Map 中拉取数据的并行数，默认值是5。可以提高到10。 3）mapreduce.reduce.shuffle.merge.percent Buffer中的数据达到多少比例 开始写入磁盘，默认值0.66。可以提高到0.75 2）mapreduce.reduce.shuffle.input.buffer.percent Buffer大小占Reduce可用内存的比例，默认值0.7。可以提高到0.8 7）mapreduce.reduce.maxattempts每个Reduce Task最大重试次数， 一旦重试次数超过该值，则认为Map Task运行失败，默认值：4。 9）mapreduce.task.timeout如果一个Task在一定时间内没有任何进入， 即不会读取新的数据，也没有输出数据，则认为该Task处于Block状态， 可能是卡住了，也许永远会卡住，为了防止因为用户程序永远Block住 不退出，则强制设置了一个该超时时间（单位毫秒），默认是600000 （10分钟）。如果你的程序对每条输入数据的处理时间过长，建议将 该参数调大。 8）mapreduce.job.reduce.slowstart.completedmaps当MapTask完成的比 例达到该值后才会为ReduceTask申请资源。默认是0.05。 10）如果可以不用Reduce，尽可能不用 5）mapreduce.reduce.java.opts：控制ReduceTask堆内存大小。（如果内 存不够，报：java.lang.OutOfMemoryError） 尚硅谷大数据技术之高频面试题 ————————————————————————————— 16 1.2.9 Yarn 工作机制 YARN工作机制 0 Mr程序提交到客 户端所在的节点 /home/atguigu/wc.jar main(){ job. waitForCompletion(); } YarnRunner 1 申请一个Application 2 Application资源提交路径 hdfs://…./.staging以及 application_id 4 资源提交完毕，申请运行mrAppMaster 3 提交job运 行所需资源 ResourceManager 5 将用户的请求初始化成一个Task FIFO调度队列 Capacity NodeManager Container cpu+ram MRAppmaster Job.split Job.xml wc.jar hdfs://…./.staging/application_id 这些文件在 job.submit() 后生成 NodeManager Container cpu+ram+jar MapTask 6 领取到 Task任务 7 创建容器 Container 8 下载job资 源到本地 9 申请运行 MapTask容器 NodeManager Container cpu+ram+jar MapTask 10 领取到任 务，创建容器 11 发送程 序启动脚本 YarnChild YarnChild 0 1 0 1 14 程序运行完后， MR会向RM注销自己 12 向RM申请2个 容器，运行 ReduceTask程序 Container YarnChild ReduceTask0 13 Reduce向 Map获取相应 分区的数据 NodeManager Container YarnChild ReduceTask1 NodeManager YARN生产环境核心参数 client client Resource Manager NodeManager Container NodeManager Container NodeManager App Mstr App Mstr Container Container Container MapTask ReduceTask Container ReduceTask MapTask yarn.resourcemanager.scheduler.class 配置调度器，默认容量 yarn.resourcemanager.scheduler.client.thread-count ResourceManager处理调度器请求的线程数量，默认50 1）ResourceManager相关 调度器 yarn.scheduler.minimum-allocation-mb 容器最最小内存，默认1G yarn.scheduler.maximum-allocation-mb 容器最最大内存，默认8G yarn.scheduler.minimum-allocation-vcores 容器最小CPU核数，默认1个 yarn.scheduler.maximum-allocation-vcores 容器最大CPU核数，默认4个 yarn.nodemanager.resource.detect-hardware-capabilities 是否让yarn自己检测硬件进行配置，默认false yarn.nodemanager.resource.count-logical-processors-as-cores 是否将虚拟核数当作CPU核数，默认false yarn.nodemanager.resource.pcores-vcores-multiplier 虚拟核数和物理核数乘数，例如：4核8线程，该 参数就应设为2，默认1.0 yarn.nodemanager.pmem-check-enabled 是否开启物理内存检查限制container，默认打开 yarn.nodemanager.vmem-check-enabled 是否开启虚拟内存检查限制container，默认打开 yarn.nodemanager.vmem-pmem-ratio 虚拟内存物理内存比例，默认2.1 yarn.nodemanager.resource.memory-mb NodeManager使用内存，默认8G yarn.nodemanager.resource.system-reserved-memory-mb NodeManager为系统保留多少内存 以上二个参数配置一个即可 yarn.nodemanager.resource.cpu-vcores NodeManager使用CPU核数，默认8个 3）Container相关 2）NodeManager相关 1.2.10 Yarn 调度器 1）Hadoop 调度器重要分为三类 FIFO 、Capacity Scheduler（容量调度器）和 Fair Sceduler（公平调度器）。 Apache 默认的资源调度器是容量调度器。 CDH 默认的资源调度器是公平调度器。 2）区别 FIFO 调度器：支持单队列 、先进先出 生产环境不会用。 尚硅谷大数据技术之高频面试题 ————————————————————————————— 容量调度器：支持多队列。队列资源分配，优先选择资源占用率最低的队列分配资源； 作业资源分配，按照作业的优先级和提交时间顺序分配资源；容器资源分配，本地原则（同 一节点/同一机架/不同节点不同机架）。 公平调度器：支持多队列，保证每个任务公平享有队列资源。资源不够时可以按照缺额 分配。 3）在生产环境下怎么选择？ 大厂：如果对并发度要求比较高，选择公平，要求服务器性能必须 OK。 中小公司，集群服务器资源不太充裕选择容量。 4）在生产环境怎么创建队列？ （1）调度器默认就 1 个 default 队列，不能满足生产要求。 （2）按照部门：业务部门 1、业务部门 2。 （3）按照业务模块：登录注册、购物车、下单。 5）创建多队列的好处？ （1）因为担心员工不小心，写递归死循环代码，把所有资源全部耗尽。 （2）实现任务的降级使用，特殊时期保证重要的任务队列资源充足。 业务部门 1（重要）=》业务部门 2（比较重要）=》下单（一般）=》购物车（一般）=》 登录注册（次要） 1.2.11 HDFS 块大小 1）块大小 1.x 64m 2.x 3.x 128m 本地 32m 企业 128m 256m 512m 2）块大小决定因素 磁盘读写速度 普通的机械硬盘 100m/s => 128m 固态硬盘普通的 300m/s => 256m 内存镜像 500-600m/s => 512m 17 尚硅谷大数据技术之高频面试题 ————————————————————————————— 18 1.2.12 Hadoop 脑裂原因及解决办法？ 1）出现脑裂的原因 Leader 出现故障，系统开始改朝换代，当 Follower 完成全部工作并且成为 Leader 后， 原 Leader 又复活了（它的故障可能是暂时断开或系统暂时变慢，不能及时响应，但其 NameNode 进程还在），并且由于某种原因它对应的 ZKFC 并没有把它设置为 Standby，所以 原 Leader 还认为自己是 Leader，客户端向它发出的请求仍会响应，于是脑裂就发生了。 2）Hadoop 通常不会出现脑裂。 如果出现脑裂，意味着多个 Namenode 数据不一致，此时只能选择保留其中一个的数据。 例如：现在有三台 Namenode，分别为 nn1、nn2、nn3，出现脑裂，想要保留 nn1 的数据， 步骤为： （1）关闭 nn2 和 nn3 （2）在 nn2 和 nn3 节点重新执行数据同步命令：hdfs namenode -bootstrapStandby （3）重新启动 nn2 和 nn3 1.3 Zookeeper 1.3.1 常用命令 ls、get、create、delete、deleteall 1.3.2 选举机制 半数机制（过半机制）：2n + 1，安装奇数台。 10 台服务器：3 台。 20 台服务器：5 台。 100 台服务器：11 台。 台数多，好处：提高可靠性；坏处：影响通信延时。 尚硅谷大数据技术之高频面试题 ————————————————————————————— 19 Zookeeper选举机制——第一次启动 Server1 myid=1 Server2 myid=2 Server3 myid=3 Server4 myid=4 Server5 myid=5 follower follower leader follower follower Client Client Zookeeper Service 每次写操作都有 事务id（zxid） （1）服务器1启动，发起一次选举。服务器1投自己一票。此时服务器1票数一票，不够半数以上（3票），选举无法完成，服务器1状态保持为 LOOKING； （2）服务器2启动，再发起一次选举。服务器1和2分别投自己一票并交换选票信息：此时服务器1发现服务器2的myid比自己目前投票推举的（服务器1） 大，更改选票为推举服务器2。此时服务器1票数0票，服务器2票数2票，没有半数以上结果，选举无法完成，服务器1，2状态保持LOOKING （3）服务器3启动，发起一次选举。此时服务器1和2都会更改选票为服务器3。此次投票结果：服务器1为0票，服务器2为0票，服务器3为3票。此时服 务器3的票数已经超过半数，服务器3当选Leader。服务器1，2更改状态为FOLLOWING，服务器3更改状态为LEADING； LOOKING LOOKING 1 1 2 0 3 0 （4）服务器4启动，发起一次选举。此时服务器1，2，3已经不是LOOKING状态，不会更改选票信息。交换选票信息结果：服务器3为3票，服务器4为 1票。此时服务器4服从多数，更改选票信息为服务器3，并更改状态为FOLLOWING； （5）服务器5启动，同4一样当小弟。 SID：服务器ID。用来唯一标识一台 ZooKeeper集群中的机器，每台机器不能重 复，和myid一致。 ZXID：事务ID。ZXID是一个事务ID，用来 标识一次服务器状态的变更。在某一时刻， 集群中的每台机器的ZXID值不一定完全一 致，这和ZooKeeper服务器对于客户端“更 新请求”的处理逻辑有关。 Epoch：每个Leader任期的代号。没有 Leader时同一轮投票过程中的逻辑时钟值是 相同的。每投完一次票这个数据就会增加 Zookeeper选举机制——非第一次启动 Server1 myid=1 Server2 myid=2 Server3 myid=3 Server4 myid=4 Server5 myid=5 follower follower leader follower follower Client Client Zookeeper Service 每次写操作都有 事务id（zxid） （1）当ZooKeeper集群中的一台服务器出现以下两种情况之一时，就会开始进入Leader选举： SID：服务器ID。用来唯一标识一台 ZooKeeper集群中的机器，每台机器不能重 复，和myid一致。 ZXID：事务ID。ZXID是一个事务ID，用来 标识一次服务器状态的变更。在某一时刻， 集群中的每台机器的ZXID值不一定完全一 致，这和ZooKeeper服务器对于客户端“更 新请求”的处理逻辑有关。 Epoch：每个Leader任期的代号。没有 Leader时同一轮投票过程中的逻辑时钟值是 相同的。每投完一次票这个数据就会增加 • 服务器初始化启动。 • 服务器运行期间无法和Leader保持连接。 （2）而当一台机器进入Leader选举流程时，当前集群也可能会处于以下两种状态： • 集群中本来就已经存在一个Leader。 对于第一种已经存在Leader的情况，机器试图去选举Leader时，会被告知当前服务器的Leader信息，对于该机器来说，仅仅需要和Leader机器建立连 接，并进行状态同步即可。 • 集群中确实不存在Leader。 假设ZooKeeper由5台服务器组成，SID分别为1、2、3、4、5，ZXID分别为8、8、8、7、7，并且此时SID为3的服务器是Leader。某一时刻， 3和5服务器出现故障，因此开始进行Leader选举。 （EPOCH，ZXID，SID ） SID为1、2、4的机器投票情况： （1，8，1） （1，8，2） （1，7，4） （EPOCH，ZXID，SID ） （EPOCH，ZXID，SID ） 选举Leader规则： ①EPOCH大的直接胜出 ②EPOCH相同，事务id大的胜出 ③事务id相同，服务器id大的胜出 1.3.3 Paxos 算法和 ZAB 协议 1）Paxos 算法 Paxos 算法：一种基于消息传递且具有高度容错特性的一致性算法。 Paxos 算法解决的问题：就是如何快速正确的在一个分布式系统中对某个数据值达成一 致，并且保证不论发生任何异常，都不会破坏整个系统的一致性。 Paxos 算法缺陷：在网络复杂的情况下，一个应用 Paxos 算法的分布式系统，可能很久 无法收敛，甚至陷入活锁的情况。 2）Zab 协议 Zab 借鉴了 Paxos 算法，是特别为 Zookeeper 设计的支持崩溃恢复的原子广播协议。基 尚硅谷大数据技术之高频面试题 ————————————————————————————— 20 于该协议，Zookeeper 设计为只有一台客户端（Leader）负责处理外部的写事务请求，然后 Leader 客户端将数据同步到其他 Follower 节点。即 Zookeeper 只有一个 Leader 可以发起提 案。 注意：暂时先不用看。如果后期准备面今日头条，需要认真准备，其他公司几乎都不问。 关注尚硅谷教育公众号回复大数据。 找 Zookeeper 视频。 1.3.4 Zookeeper 符合法则中哪两个？ CAP理论告诉我们，一个分布式系统不可能同时满足以下三种 CAP理论  一致性（C:Consistency）  可用性（A:Available）  分区容错性（P:Partition Tolerance） 这三个基本需求，最多只能同时满足其中的两项，因为P是必须的，因此往往选择就在CP或者AP中。 1）一致性（C:Consistency） 在分布式环境中，一致性是指数据在多个副本之间是否能够保持数据一致的特性。在一致性的需求下，当一个系统在数 据一致的状态下执行更新操作后，应该保证系统的数据仍然处于一致的状态。 2）可用性（A:Available） 可用性是指系统提供的服务必须一直处于可用的状态，对于用户的每一个操作请求总是能够在有限的时间内返回结果。 3）分区容错性（P:Partition Tolerance） 分布式系统在遇到任何网络分区故障的时候，仍然需要能够保证对外提供满足一致性和可用性的服务，除非是整个网络 环境都发生了故障。 ZooKeeper保证的是CP （1）ZooKeeper不能保证每次服务请求的可用性。（注：在极端环境下，ZooKeeper可能会丢弃一些请求，消费者程序需要 重新请求才能获得结果）。所以说，ZooKeeper不能保证服务可用性。 （2）进行Leader选举时集群都是不可用。 1.3.5 Zookeeper 脑裂 Zookeeper 采用过半选举机制，防止了脑裂。 1.3.6 Zookeeper 用来干嘛了 （1）作为 HA 的协调者：如 HDFS 的 HA、YARN 的 HA。 （2）被组件依赖：如 Kafka、HBase、CK。 1.4 Flume 1.4.1 Flume 组成，Put 事务，Take 事务 1）Taildir Source （1）断点续传、多目录 （2）taildir 底层原理 尚硅谷大数据技术之高频面试题 ————————————————————————————— 21 Flume TailDirSource Channel TailDir Source putList Queue positionFile 1.读取一批数 据(batchSize) 2.doPut： 放到putList 3.doCommit: 放到Queue 4.数据成功到达Channel 则更新positionFile 7.不更新PositionFile 从上次位置重新读取 6.数据未成功到达Channel doRollback: 清空putList 5.读取下一批数据 （3）Taildir 挂了怎么办？ 不会丢数：断点续传 重复数据：有可能 （4）存在的问题及解决方案 ①问题： 新文件判断条件 = iNode 值 + 绝对路径（包含文件名） 日志框架凌晨修改了文件名称=》导致会再次重读一次昨天产生的数据 ②解决： 方案一：建议生成的文件名称为带日期的。同时配置日志生成框架为不更名的； 方案二：修改 TairDirSource 源码，只按照 iNode 值去确定文件 修改源码视频地址： https://www.bilibili.com/video/BV1wf4y1G7EQ?p=14&vd_source=891aa1a36311 1d4914eb12ace2e039af 2）file channel /memory channel/kafka channel （1）File Channel 数据存储于磁盘，优势：可靠性高；劣势：传输速度低 默认容量：100 万个 event 注意：FileChannel 可以通过配置 dataDirs 指向多个路径，每个路径对应不同的硬盘，增 大 Flume 吞吐量。 尚硅谷大数据技术之高频面试题 ————————————————————————————— 22 （2）Memory Channel 数据存储于内存，优势：传输速度快；劣势：可靠性差 默认容量：100 个 event （3）Kafka Channel 数据存储于 Kafka，基于磁盘； 优势：可靠性高； 传输速度快 Kafka Channel 大于 Memory Channel + Kafka Sink 原因省去了 Sink 阶段 （4）生产环境如何选择  如果下一级是 Kafka，优先选择 Kafka Channel。  如果是金融、对钱要求准确的公司，选择 File Channel。  如果就是普通的日志，通常可以选择 Memory Channel。 每天丢几百万数据 pb 级 亿万富翁，掉 1 块钱会捡？ 3）HDFS Sink （1）时间（半个小时） or 大小 128m 且 设置 Event 个数等于 0，该值默认 10 具体参数：hdfs.rollInterval=1800，hdfs.rollSize=134217728 且 hdfs.rollCount=0 4）事务  Source 到 Channel 是 Put 事务  Channel 到 Sink 是 Take 事务 1.4.2 Flume 拦截器 1）拦截器注意事项 （1）时间戳拦截器：主要是解决零点漂移问题 2）自定义拦截器步骤 （1）实现 Interceptor （2）重写四个方法  initialize 初始化  public Event intercept(Event event) 处理单个 Event  public List<Event> intercept(List<Event> events) 处理多个 Event，在这个方法中调 尚硅谷大数据技术之高频面试题 ————————————————————————————— 23 用 Event intercept(Event event)  close 方法 （3）静态内部类，实现 Interceptor.Builder 3）拦截器可以不用吗？ 时间戳拦截器建议使用。如果不用需要采用延迟 15-20 分钟处理数据的方式，比较麻烦。 1.4.3 Flume Channel 选择器 Replicating：默认选择器。功能：将数据发往下一级所有通道。 Multiplexing：选择性发往指定通道。 1.4.4 Flume 监控器 1）采用 Ganglia 监控器，监控到 Flume 尝试提交的次数远远大于最终成功的次数，说明 Flume 运行比较差。主要是内存不够导致的。 2）解决办法？ （1）自身：默认内存是 20m，考虑增加 flume 内存，在 flume-env.sh 配置文件中修改 flume 内存为 4-6g （2）找朋友：增加服务器台数 搞活动 618 =》增加服务器 =》用完在退出 日志服务器配置：8-16g 内存、磁盘 8T 1.4.5 Flume 采集数据会丢失吗?  如果是 kafka channel 或者 FileChannel 不会丢失数据，数据存储可以存储在磁盘中。  如果是 MemoryChannel 有可能丢。 1.4.6 Flume 如何提高吞吐量  调整 taildir source 的 batchSize 大小可以控制吞吐量，默认大小 100 个 Event。  吞吐量的瓶颈一般是网络带宽。 1.5 Kafka 1.5.1 Kafka 架构 生产者、Broker、消费者、Zookeeper。 注意：Zookeeper 中保存 Broker id 和 controller 等信息，但是没有生产者信息。 尚硅谷大数据技术之高频面试题 ————————————————————————————— 24 Broker1 Producer Interceptors 拦截器 Serializer 序列化器 Partitioner 分区器 send(ProducerRecord) RecordAccumulator （默认32m） Sender (读取数据) Kafka Producer 生产者 main线程 sender线程 Kafka 集群 发送流程 Deque Deque Deque ProducerBatch （默认16k） • batch.size：只有数据积累到batch.size之后，sender才会发送数据。默认16k • linger.ms：如果数据迟迟未达到batch.size，sender等待linger.ms设置的时间 到了之后就会发送数据。单位ms，默认值是0ms，表示没有延迟。 Selector 分区1 分区2 分区3 Broker2 分区1 分区2 分区3 发送 应答acks： 达到 batch.size或 linger.ms 外部数据 NetworkClient Request 2 Request 2 InFlightRequests，默认每个 broker节点最多缓存5个请求 Request 1 Request 1 成功？ 重试？ 失败 是 是 Request 1 Request 1 清理 retries • 0：生产者发送过来的数据，不需要等数据落盘应答。 • 1：生产者发送过来的数据，Leader收到数据后应答。 • -1（all）：生产者发送过来的数据，Leader和ISR队列 里面的所有节点收齐数据后应答。-1和all等价。 。。。 。。。 broker0 Kafka cluster TopicA - Partition0 Follower broker1 broker2 TopicA-Partition0 Follower TopicA-Partition0 Leader Zookeeper /brokers/ids/ /brokers/topics/first/partitions/0/state "leader": ,"isr":[ ] Kafka Producer 1）broker启动 后在zk中注册 Kafka Broker总体工作流程 1 Controller Controller Controller controller [ ] 0,1,2 “brokerid”:0 1, 0 ,2 Controller 1 2）controller谁先注册，谁 说了算 1 发送消息 应答消息 2 L O g Segment （1G） Segment (1G) .log文件 .index文件 3）由选举出来的Controller 监听brokers节点变化 4）Controller决定Leader选举 9）获取ISR 11）更新Leader及ISR 8）Controller监听到节点变化 5）Controller将节点信息 上传到ZK 10）选举新的Leader（在 isr中存活为前提，按照 AR中排在前面的优先） 6）其他contorller从zk同 步相关信息 TopicA - Partition0 Leader 选举规则：在isr中存活为前提，按 照 AR中排在前面的优先。例如 ar[1,0,2], isr [1，0，2]，那么leader 就会按照1，0，2的顺序轮询 7）假设Broker1中 Leader挂了 1 1 0 AR：Kafka分区中 的所有副本统称 尚硅谷大数据技术之高频面试题 ————————————————————————————— 25 broker0 Kafka cluster Producer TopicA-Partition0 TopicA-Partition1 broker1 broker2 TopicA-Partition2 消费者组初始化流程 数据100T Consumer Consumer Consumer group Leader Leader Leader coordinator coordinator coordinator 1、coordinator：辅助实现消费者组的初始化和分区的分配。 coordinator节点选择 = groupid的hashcode值 % 50（ __consumer_offsets的分区数量） 例如：hash(groupid)% 50 = 1，那么__consumer_offsets 主题的1号分区的Leader，在哪个broker上，就选择这个节点的coordinator作为这 个消费者组的老大。消费者组下的所有的消费者提交offset的时候就往这个分区去提交offset。 1）每个consumer都 发送JoinGroup请求 2）选出一个 consumer作为leader Leader 3）把要消费的topic情况 发送给leader 消费者 4）leader会负 责制定消费方案 5）把消费方案发给coordinator 6）Coordinator就把消费方 案下发给各个consumer 7）每个消费者都会和coordinator保持心跳（默认3s），一旦超时 （session.timeout.ms=45s），该消费者会被移除，并触发再平衡； 或者消费者处理消息的时间过长（max.poll.interval.ms5分钟），也 会触发再平衡 __consumer_off sets-partition0 fsets __consumer_of -partition1 __consumer_off sets-partition2 消费者组详细消费流程 broker0 Kafka cluster TopicA -Partition0 TopicA -Partition1 broker1 broker2 TopicA -Partition2 Consumer Consumer Consumer group Leader Leader Leader ConsumerNetworkClient sendFetches 发送消费请求 send completedFetches （queue） onSuccess completed Fetch completed Fetch 。。。 FetchedRecords 从队列中抓取数据 Interceptors （拦截器） 处理数据 parseRecord （反序列化） Consumer Fetch.max.bytes每批次最 大抓取大小，默认50m Max.poll.records一次 拉取数据返回消息的 最大条数，默认500条 Fetch.min.bytes每批次最 小抓取大小，默认1字节 fetch.max.wait.ms一批数据最小值 未达到的超时时间，默认500ms 1.5.2 Kafka 生产端分区分配策略 Kafka 官方为我们实现了三种 Partitioner（分区器），分别是 DefaultPartitioner（当未指定 分区器时候所使用的默认分区器）、UniformStickyPartitioner、RoundRobinPartitioner。 （1）DefaultPartitioner 默认分区器 下图说明了默认分区器的分区分配策略： 尚硅谷大数据技术之高频面试题 ————————————————————————————— 26 public ProducerRecord(String topic, Integer partition, Long timestamp, K key, V value, Iterable<Header> headers) { ... ... } public ProducerRecord(String topic, Integer partition, Long timestamp, K key, V value) { ... ... } public ProducerRecord(String topic, Integer partition, K key, V value, Iterable<Header> headers) { ... ... } public ProducerRecord(String topic, Integer partition, K key, V value) { ... ... } public ProducerRecord(String topic, K key, V value) { ... ... } public ProducerRecord(String topic, V value) { ... ... } 在IDEA中全局查找（ctrl +n）ProducerRecord类，在类中可以看到如下构造方法： （1）指明partition的情况下，直 接将指明的值作为partition值； 例如partition=0，所有数据写入 分区0 （2）没有指明partition值但有key的情况下，将key的hash值与topic的 partition数进行取余得到partition值； 例如：key1的hash值=5， key2的hash值=6 ，topic的partition数=2，那 么key1 对应的value1写入1号分区，key2对应的value2写入0号分区。 （3）既没有partition值又没有key值的情况下，Kafka采用Sticky Partition（黏性分区器），会随机选择一个分区，并尽可能一直 使用该分区，待该分区的batch已满或者已完成，Kafka再随机一个分区进行使用（和上一次的分区不同）。 例如：第一次随机选择0号分区，等0号分区当前批次满了（默认16k）或者linger.ms设置的时间到， Kafka再随机一个分区 进行使用。此时分以下三种情况：①可用分区<1 ；那么选择分区的逻辑是在所有分区中随机选择。②可用分区=1； 那么直接选 择这个分区。③可用分区>1 ; 那么在所有可用分区中随机选择。 Kafka 原则 （2）UniformStickyPartitioner 纯粹的粘性分区器 1）如果指定了分区号，则会按照指定的分区号进行分配 2）若没有指定分区好，，则使用粘性分区器 （3）RoundRobinPartitioner 轮询分区器 1）如果在消息中指定了分区则使用指定分区。 2）如果未指定分区，都会将消息轮询每个分区，将数据平均分配到每个分区中。 （4）自定义分区器 自定义分区策略：可以通过实现 org.apache.kafka.clients.producer.Partitioner 接口，重写 partition 方法来达到自定义分区效果。 例如我们想要实现随机分配，只需要以下代码： List<PartitionInfo> partitions = cluster.partitionsForTopic(topic); return ThreadLocalRandom.current().nextInt(partitions.size()); 先计算出该主题总的分区数，然后随机地返回一个小于它的正整数。 本质上看随机策略也是力求将数据均匀地打散到各个分区，但从实际表现来看，它要逊 于轮询策略，所以如果追求数据的均匀分布，还是使用轮询策略比较好。事实上，随机策略 是老版本生产者使用的分区策略，在新版本中已经改为轮询了。 在项目中，如果希望把 mysql 中某张表的数据发送到一个分区。可以以表名为 key 进行 发送。 1.5.3 Kafka 丢不丢数据 1）Producer 角度 尚硅谷大数据技术之高频面试题 ————————————————————————————— 27 acks=0，生产者发送过来数据就不管了，可靠性差，效率高； acks=1，生产者发送过来数据 Leader 应答，可靠性中等，效率中等； acks=-1，生产者发送过来数据 Leader 和 ISR 队列里面所有 Follwer 应答，可靠性高， 效率低； 在生产环境中，acks=0 很少使用；acks=1，一般用于传输普通日志，允许丢个别数据； acks=-1，一般用于传输和钱相关的数据，对可靠性要求比较高的场景。 2）Broker 角度 副本数大于等于 2。 min.insync.replicas 大于等于 2。 1.5.4 Kafka 的 ISR 副本同步队列 ISR（In-Sync Replicas），副本同步队列。如果 Follower 长时间未向 Leader 发送通信请 求或同步数据，则该 Follower 将被踢出 ISR。该时间阈值由 replica.lag.time.max.ms 参数设 定，默认 30s。 任意一个维度超过阈值都会把 Follower 剔除出 ISR，存入 OSR（Outof-Sync Replicas） 列表，新加入的 Follower 也会先存放在 OSR 中。 Kafka 分区中的所有副本统称为 AR = ISR + OSR 1.5.5 Kafka 数据重复 去重 = 幂等性 + 事务 1）幂等性原理 尚硅谷大数据技术之高频面试题 ————————————————————————————— 28 幂等性原理 Kafka cluster TopicA-Partition0 broker1 TopicA-Partition1 Producer1 Pid=1000 broker0 Sequence=0 PID=1000 Value=Hello Sequence=1 PID=1000 Value=world Sequence=0 PID=1000 Value=atguigu Sequence=1 PID=1000 Value=kafka Sequence=1 PID=1000 Value=world 幂等性就是指Producer不论向Broker发送多少次重复数据，Broker端都只会持久化一条，保证了不重复。 精确一次（Exactly Once） = 幂等性 + 至少一次（ ack=-1 + 分区副本数>=2 + ISR最小副本数量>=2） 。 world Hello kafka atguigu 重复数据的判断标准：具有<PID, Partition, SeqNumber>相同主键的消息提交时，Broker只会持久化一条。其 中PID是Kafka每次重启都会分配一个新的；Partition 表示分区号；Sequence Number是单调自增的。 所以幂等性只能保证的是在单分区单会话内不重复。 2）幂等性配置参数 参数名称 描述 enable.idempotence 是否开启幂等性，默认 true，表示开启幂等性。 max.in.flight.requests.per.connection 1.0.X 版本前，需设置为 1，1.0.X 之后，小于等于 5 retries 失败重试次数，需要大于 0 acks 需要设置为 all 3）Kafka 的事务一共有如下 5 个 API // 1 初始化事务 void initTransactions(); // 2 开启事务 void beginTransaction() throws ProducerFencedException; // 3 在事务内提交已经消费的偏移量（主要用于消费者） void sendOffsetsToTransaction(Map<TopicPartition, OffsetAndMetadata> offsets, String consumerGroupId) throws ProducerFencedException; // 4 提交事务 void commitTransaction() throws ProducerFencedException; // 5 放弃事务（类似于回滚事务的操作） void abortTransaction() throws ProducerFencedException; 4）总结 （1）生产者角度  acks 设置为-1 （acks=-1）。  幂等性（enable.idempotence = true） + 事务 。 尚硅谷大数据技术之高频面试题 ————————————————————————————— 29 （2）broker 服务端角度  分区副本大于等于 2 （--replication-factor 2）。  ISR 里应答的最小副本数量大于等于 2 （min.insync.replicas = 2）。 （3）消费者  事务 + 手动提交 offset （enable.auto.commit = false）。  消费者输出的目的地必须支持事务（MySQL、Kafka）。 1.5.6 Kafka 如何保证数据有序 or 怎么解决乱序 1）Kafka 最多只保证单分区内的消息是有序的，所以如果要保证业务全局严格有序，就要 设置 Topic 为单分区。 生产经验——如何保证数据有序 Producer Kafka cluster broker0 broker1 broker2 TopicA-partition0-leader TopicA-partition1-leader TopicA-partition2-leader 0 1 2 3 4 5 0 1 2 3 0 1 2 3 4 Consumer 单分区内，可保证数据有序，但也不是绝对 的。例如，某批次的数据发送失败后，进行了 重试，就可能出现后边的批次先于它到达的情 况。 2）如何保证单分区内数据有序？ 尚硅谷大数据技术之高频面试题 ————————————————————————————— 30 生产经验——如何保证单分区数据有序 方案一： 禁止重试，需设置以下参数 设置retries等于0 说明：数据出现乱序的根本原因是，失败重试，关闭重试，则可保证数据是有序的。但是这样做，可能会 导致数据的丢失。 方案二： 启用幂等，需设置以下参数 设置enable.idempotence=true，启用幂等 设置max.in.flight.requests.per.connection，1.0.X版本前，需设置为1，1.0.X之后，小于等于5 设置retries，保证其大于0 设置acks，保证其为all 注：幂等机制保证数据有序的原理如下： Request 生产经验——如何保证数据有序 Producer Broker-0 最近一次写入P0分区的batch的SeqNum：p0-9 batch-9 batch-8 batch-7 batch-6 ...... batch-10 Request batch-11 2.Response 3.对Record Accumulator中P0 分区队列中的batch重新排序 4.当前批次的SeqNum比最新的SeqNum大2， 证明顺序发生混乱，拒绝写入 1.发生故障， 导致写入失败 6.对Record Accumulator中P0分 区队列中的batch重新排序 5.Response Request batch-10 7.重新发送 1.5.7 Kafka 分区 Leader 选举规则 在 ISR 中存活为前提，按照 AR 中排在前面的优先。例如 AR[1,0,2]，ISR [1，0，2]，那 么 Leader 就会按照 1，0，2 的顺序轮询。 1.5.8 Kafka 中 AR 的顺序 如果 Kafka 服务器只有 4 个节点，那么设置 Kafka 的分区数大于服务器台数，在 Kafka 底层如何分配存储副本呢？ 1）创建 16 分区，3 个副本 尚硅谷大数据技术之高频面试题 ————————————————————————————— 31 （1）创建一个新的 Topic，名称为 second。 [atguigu@hadoop102 kafka]$ bin/kafka-topics.sh --bootstrap-server hadoop102:9092 --create --partitions 16 --replication-factor 3 -- topic second （2）查看分区和副本情况。 [atguigu@hadoop102 kafka]$ bin/kafka-topics.sh --bootstrap-server hadoop102:9092 --describe --topic second Topic: second4 Partition: 0 Leader: 0 Replicas: 0,1,2 Isr: 0,1,2 Topic: second4 Partition: 1 Leader: 1 Replicas: 1,2,3 Isr: 1,2,3 Topic: second4 Partition: 2 Leader: 2 Replicas: 2,3,0 Isr: 2,3,0 Topic: second4 Partition: 3 Leader: 3 Replicas: 3,0,1 Isr: 3,0,1 Topic: second4 Partition: 4 Leader: 0 Replicas: 0,2,3 Isr: 0,2,3 Topic: second4 Partition: 5 Leader: 1 Replicas: 1,3,0 Isr: 1,3,0 Topic: second4 Partition: 6 Leader: 2 Replicas: 2,0,1 Isr: 2,0,1 Topic: second4 Partition: 7 Leader: 3 Replicas: 3,1,2 Isr: 3,1,2 Topic: second4 Partition: 8 Leader: 0 Replicas: 0,3,1 Isr: 0,3,1 Topic: second4 Partition: 9 Leader: 1 Replicas: 1,0,2 Isr: 1,0,2 Topic: second4 Partition: 10 Leader: 2 Replicas: 2,1,3 Isr: 2,1,3 Topic: second4 Partition: 11 Leader: 3 Replicas: 3,2,0 Isr: 3,2,0 Topic: second4 Partition: 12 Leader: 0 Replicas: 0,1,2 Isr: 0,1,2 Topic: second4 Partition: 13 Leader: 1 Replicas: 1,2,3 Isr: 1,2,3 Topic: second4 Partition: 14 Leader: 2 Replicas: 2,3,0 Isr: 2,3,0 Topic: second4 Partition: 15 Leader: 3 Replicas: 3,0,1 Isr: 3,0,1 分区副本分配 broker0 broker1 broker2 broker3 L F F L F F L F F L F F L F F L F F L F F L F F L F F L F F L F F L F F 1.5.9 Kafka 日志保存时间 默认保存 7 天；生产环境建议 3 天。 1.5.10 Kafka 过期数据清理 日志清理的策略只有 delete 和 compact 两种。 尚硅谷大数据技术之高频面试题 ————————————————————————————— 1）delete 日志删除：将过期数据删除  log.cleanup.policy = delete ，所有数据启用删除策略 （1）基于时间：默认打开。以 segment 中所有记录中的最大时间戳作为该文件时间戳。 （2）基于大小：默认关闭。超过设置的所有日志总大小，删除最早的 segment。 log.retention.bytes，默认等于-1，表示无穷大。 思考：如果一个 segment 中有一部分数据过期，一部分没有过期，怎么处理？ 2）compact 日志压缩 1.5.11 Kafka 为什么能高效读写数据 1）Kafka 本身是分布式集群，可以采用分区技术，并行度高 2）读数据采用稀疏索引，可以快速定位要消费的数据 3）顺序写磁盘 Kafka 的 producer 生产数据，要写入到 log 文件中，写的过程是一直追加到文件末端， 为顺序写。官网有数据表明，同样的磁盘，顺序写能到 600M/s，而随机写只有 100K/s。这 与磁盘的机械机构有关，顺序写之所以快，是因为其省去了大量磁头寻址的时间。 32 尚硅谷大数据技术之高频面试题 ————————————————————————————— 33 4）页缓存 + 零拷贝技术 kafka Application Cache kernel space Page Cache 页缓存 Socket Cache 网卡（NIC） File 页缓存 + 零拷贝技术 零拷贝：Kafka的数据加工处理操作交由Kafka生产者和Kafka消费者处理。Kafka Broker应用层不关心存储的数据，所以就不用 走应用层，传输效率高。 生产者 消费者 非零拷贝工作流程（假设） kafka kernel space Page Cache 页缓存 网卡（NIC） File 生产者 消费者 零拷贝工作流程（实际） PageCache页缓存：Kafka重度依赖底层操作系统提供的PageCache功能。当上层有写操作时，操作系统只是将数据写入 PageCache。当读操作发生时，先从PageCache中查找，如果找不到，再去磁盘中读取。实际上PageCache是把尽可能多的空闲内存 都当做了磁盘缓存来使用。 1.5.12 自动创建主题 如果 Broker 端配置参数 auto.create.topics.enable 设置为 true（默认值是 true），那么当生 产者向一个未创建的主题发送消息时，会自动创建一个分区数为 num.partitions（默认值为 1）、副本因子为 default.replication.factor（默认值为 1）的主题。除此之外，当一个消费者开 始从未知主题中读取消息时，或者当任意一个客户端向未知主题发送元数据请求时，都会自 动创建一个相应主题。这种创建主题的方式是非预期的，增加了主题管理和维护的难度。生 产环境建议将该参数设置为 false。 （1）向一个没有提前创建 five 主题发送数据 [atguigu@hadoop102 kafka]$ bin/kafka-console-producer.sh -- bootstrap-server hadoop102:9092 --topic five >hello world 尚硅谷大数据技术之高频面试题 ————————————————————————————— （2）查看 five 主题的详情 [atguigu@hadoop102 kafka]$ bin/kafka-topics.sh --bootstrap-server hadoop102:9092 --describe --topic five 1.5.13 副本数设定 一般我们设置成 2 个或 3 个，很多企业设置为 2 个。 副本的优势：提高可靠性；副本劣势：增加了网络 IO 传输。 1.5.14 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 分区 分区数一般设置为：3-10 个 分区数不是越多越好，也不是越少越好，需要搭建完集群，进行压测，再灵活调整分区 个数。 1.5.15 Kafka 增加分区 1）可以通过命令行的方式增加分区，但是分区数只能增加，不能减少。 2）为什么分区数只能增加，不能减少？ （1）按照 Kafka 现有的代码逻辑而言，此功能完全可以实现，不过也会使得代码的复 杂度急剧增大。 （2）实现此功能需要考虑的因素很多，比如删除掉的分区中的消息该作何处理？  如果随着分区一起消失则消息的可靠性得不到保障；  如果需要保留则又需要考虑如何保留，直接存储到现有分区的尾部，消息的时间戳 就不会递增，如此对于 Spark、Flink 这类需要消息时间戳（事件时间）的组件将会受到影响；  如果分散插入到现有的分区中，那么在消息量很大的时候，内部的数据复制会占用 很大的资源，而且在复制期间，此主题的可用性又如何得到保障？  同时，顺序性问题、事务性问题、以及分区和副本的状态机切换问题都是不得不面 对的。 34 尚硅谷大数据技术之高频面试题 ————————————————————————————— 35 （3）反观这个功能的收益点却是很低，如果真的需要实现此类的功能，完全可以重新 创建一个分区数较小的主题，然后将现有主题中的消息按照既定的逻辑复制过去即可。 1.5.16 Kafka 中多少个 Topic ODS 层：2 个 DWD 层：20 个 1.5.17 Kafka 消费者是拉取数据还是推送数据 拉取数据。 1.5.18 Kafka 消费端分区分配策略 Kafka cluster Partition-0 broker-0 Partition-1 broker-1 Partition-2 broker-2 Partition-3 broker-3 Partition-4 broker-4 Partition-5 broker-5 Partition-6 broker-6 Consumer2 Consumer1 Consumer0 Range 是对每个 topic 而言的。 首先对同一个 topic 里面的分区按照序号进行排序，并 对消费者按照字母顺序进行排序。 假如现在有 7 个分区，3 个消费者，排序后的分区将会 是0,1,2,3,4,5,6；消费者排序完之后将会是C0,C1,C2。 例如，7/3 = 2 余 1 ，除不尽，那么 消费者 C0 便会多 消费 1 个分区。 8/3=2余2，除不尽，那么C0和C1分别多 消费一个。 通过 partitions数/consumer数 来决定每个消费者应该 消费几个分区。如果除不尽，那么前面几个消费者将会多 消费 1 个分区。 分区分配策略之Range 注意：如果只是针对 1 个 topic 而言，C0消费者多消费1 个分区影响不是很大。但是如果有 N 多个 topic，那么针对每 个 topic，消费者 C0都将多消费 1 个分区，topic越多，C0消 费的分区会比其他消费者明显多消费 N 个分区。 容易产生数据倾斜！ 0，1，2 3，4 5，6 Kafka cluster Partition-0 broker-0 Partition-1 broker-1 Partition-2 broker-2 Partition-3 broker-3 Partition-4 broker-4 Partition-5 broker-5 Partition-6 broker-6 Consumer3 Consumer2 Consumer1 分区分配策略之RoundRobin RoundRobin 针对集群中所有Topic而言。 RoundRobin 轮询分区策略，是把所有的 partition 和所有的 consumer 都列出来，然后按照 hashcode 进行排序，最后 通过轮询算法来分配 partition 给到各个消费者。 0，3，6 1，4 2，5 尚硅谷大数据技术之高频面试题 ————————————————————————————— 36 粘性分区： 该分区分配算法是最复杂的一种，可以通过 partition.assignment.strategy 参数去设置， 从 0.11 版本开始引入，目的就是在执行新分配时，尽量在上一次分配结果上少做调整，其 主要实现了以下 2 个目标： （1）Topic Partition 的分配要尽量均衡。 （2）当 Rebalance 发生时，尽量与上一次分配结果保持一致。 注意：当两个目标发生冲突的时候，优先保证第一个目标，这样可以使分配更加均匀， 其中第一个目标是 3 种分配策略都尽量去尝试完成的，而第二个目标才是该算法的精髓所 在。 1.5.19 消费者再平衡的条件 1）Rebalance 的触发条件有三种 （1）当 Consumer Group 组成员数量发生变化（主动加入、主动离组或者故障下线等）。 （2）当订阅主题的数量或者分区发生变化。 broker0 Kafka cluster Producer TopicA-Partition0 TopicA-Partition1 broker1 broker2 TopicA-Partition2 消费者组初始化流程 数据100T Consumer Consumer Consumer group Leader Leader Leader coordinator coordinator coordinator 1、coordinator：辅助实现消费者组的初始化和分区的分配。 coordinator节点选择 = groupid的hashcode值 % 50（ __consumer_offsets的分区数量） 例如： groupid的hashcode值 = 1，1% 50 = 1，那么__consumer_offsets 主题的1号分区，在哪个broker上，就选择这个节点的coordinator 作为这个消费者组的老大。消费者组下的所有的消费者提交offset的时候就往这个分区去提交offset。 1）每个consumer都 发送JoinGroup请求 2）选出一个 consumer作为leader Leader 3）把要消费的topic情况 发送给leader 消费者 4）leader会负 责制定消费方案 5）把消费方案发给coordinator 6）Coordinator就把消费方 案下发给各个consumer 7）每个消费者都会和coordinator保持心跳（默认3s），一旦超时 （session.timeout.ms=45s），该消费者会被移除，并触发再平衡； 或者消费者处理消息的时间过长（max.poll.interval.ms5分钟），也 会触发再平衡 __consumer_off sets-partition0 fsets __consumer_of -partition1 __consumer_off sets-partition2 2）消费者故障下线的情况 参数名称 描述 session.timeout.ms Kafka 消费者和 coordinator 之间连接超时时间，默认 45s。超过 该值，该消费者被移除，消费者组执行再平衡。 max.poll.interval.ms 消费者处理消息的最大时长，默认是 5 分钟。超过该值，该消 尚硅谷大数据技术之高频面试题 ————————————————————————————— 费者被移除，消费者组执行再平衡。 3）主动加入消费者组 在现有集中增加消费者，也会触发 Kafka 再平衡。注意，如果下游是 Flink，Flink 会自 己维护 offset，不会触发 Kafka 再平衡。 1.5.20 指定 Offset 消费 可以在任意 offset 处消费数据。 kafkaConsumer.seek(topic, 1000); 1.5.21 指定时间消费 可以通过时间来消费数据。 HashMap<TopicPartition, Long> timestampToSearch = new HashMap<>(); timestampToSearch.put(topicPartition, System.currentTimeMillis() - 1 * 24 * 3600 * 1000); kafkaConsumer.offsetsForTimes(timestampToSearch); 1.5.22 Kafka 监控 公司自己开发的监控器。 开源的监控器：KafkaManager、KafkaMonitor、KafkaEagle。 1.5.23 Kafka 数据积压 1）发现数据积压 通过 Kafka 的监控器 Eagle，可以看到消费 lag，就是积压情况： 2）解决 （1）消费者消费能力不足 ① 可以考虑增加 Topic 的分区数，并且同时提升消费组的消费者数量，消费者数 = 分 37 尚硅谷大数据技术之高频面试题 ————————————————————————————— 38 区数。（两者缺一不可）。 增加分区数； [atguigu@hadoop102 kafka]$ bin/kafka-topics.sh --bootstrap-server hadoop102:9092 --alter --topic first --partitions 3 ② 提高每批次拉取的数量，提高单个消费者的消费能力。 参数名称 描述 fetch.max.bytes 默认 Default: 52428800（50 m）。消费者获取服务器端一批消息最大 的字节数。如果服务器端一批次的数据大于该值（50m）仍然可以拉 取回来这批数据，因此，这不是一个绝对最大值。一批次的大小受 message.max.bytes （broker config）or max.message.bytes （topic config）影响。 max.poll.records 一次 poll 拉取数据返回消息的最大条数，默认是 500 条 （2）消费者处理能力不行 ①消费者，调整 fetch.max.bytes 大小，默认是 50m。 ②消费者，调整 max.poll.records 大小，默认是 500 条。 如果下游是 Spark、Flink 等计算引擎，消费到数据之后还要进行计算分析处理，当处理 能力跟不上消费能力时，会导致背压的出现，从而使消费的速率下降。 需要对计算性能进行调优（看 Spark、Flink 优化）。 （3）消息积压后如何处理 某时刻，突然开始积压消息且持续上涨。这种情况下需要你在短时间内找到消息积压的 原因，迅速解决问题。 导致消息积压突然增加，只有两种：发送变快了或者消费变慢了。 假如赶上大促或者抢购时，短时间内不太可能优化消费端的代码来提升消费性能，此时 唯一的办法是通过扩容消费端的实例数来提升总体的消费能力。如果短时间内没有足够的服 务器资源进行扩容，只能降级一些不重要的业务，减少发送方发送的数据量，最低限度让系 统还能正常运转，保证重要业务服务正常。 假如通过内部监控到消费变慢了，需要你检查消费实例，分析一下是什么原因导致消费 变慢？ ①优先查看日志是否有大量的消费错误。 ②此时如果没有错误的话，可以通过打印堆栈信息，看一下你的消费线程卡在哪里「触 尚硅谷大数据技术之高频面试题 ————————————————————————————— 发死锁或者卡在某些等待资源」。 1.5.24 如何提升吞吐量 如何提升吞吐量？ 1）提升生产吞吐量 （1）buffer.memory：发送消息的缓冲区大小，默认值是 32m，可以增加到 64m。 （2）batch.size：默认是 16k。如果 batch 设置太小，会导致频繁网络请求，吞吐量下降； 如果 batch 太大，会导致一条消息需要等待很久才能被发送出去，增加网络延时。 （3）linger.ms，这个值默认是 0，意思就是消息必须立即被发送。一般设置一个 5-100 毫秒。如果 linger.ms 设置的太小，会导致频繁网络请求，吞吐量下降；如果 linger.ms 太长， 会导致一条消息需要等待很久才能被发送出去，增加网络延时。 （4）compression.type：默认是 none，不压缩，但是也可以使用 lz4 压缩，效率还是不 错的，压缩之后可以减小数据量，提升吞吐量，但是会加大 producer 端的 CPU 开销。 2）增加分区 3）消费者提高吞吐量 （1）调整 fetch.max.bytes 大小，默认是 50m。 （2）调整 max.poll.records 大小，默认是 500 条。 1.5.25 Kafka 中数据量计算 每天总数据量 100g，每天产生 1 亿条日志，10000 万/24/60/60=1150 条/每秒钟 平均每秒钟：1150 条 低谷每秒钟：50 条 高峰每秒钟：1150 条 *（2-20 倍）= 2300 条 - 23000 条 每条日志大小：0.5k - 2k（取 1k） 每秒多少数据量：2.0M - 20MB 1.5.26 Kafka 的机器数量 Kafka 集群机器的数量取决于：生产者和消费者实际的吞吐量，以及单台服务器的吞吐 量（包括磁盘和网络）。下面介绍一个简单使用的估算模型：  假定生产者写入的速度为：W（MB/s）  写入的 Topic 的副本数为：R 39 尚硅谷大数据技术之高频面试题 ————————————————————————————— 40  同一 Topic 的消费者组的个数为：C 因为副本同步以及多个消费者组都会占用整个集群的吞吐量，综合考虑后，可得到如下 结论：  总的数据写入速度应为 W*R（考虑副本同步）  总的数据读取速度应为 W*（R-1+C）（考虑副本同步和多个消费者组） 所以可得到以下结论：  磁盘的总吞吐量为 W*R+ W*（R-1+C）  网络的写吞吐量为 W*R  读吞吐量为 W*（R-1+C） 需要注意的是，Kafka 充分利用了 PageCache 缓存生产者写入的数据，所以读数据（包 括费者和副本同步）时，不一定发生磁盘 IO。所以实际情况下，磁盘的总吞吐量一定是小 于 W*R+ W*（R-1+C）的，此处按最坏的情况进行估算。 假如单个服务器的配置如下： 网卡：全双工千兆网卡（可提供 125M/s 的读写速率） 磁盘：机械硬盘（可提供 300M/s 的读写速率） 若 W=100M/s，R=2，C=1，则可得到  磁盘的总吞吐量为 W*R+ W*（R-1+C）=400M/s  网络的写吞吐量为 W*R=200M/s  读吞吐量为 W*（R-1+C）=200M/s 所以可计算出至少需要两台节点，考虑到网络协议的开销（除了发送实际数据，还会有 一些其他信息，例如 ACK 等），通常可将计算结果成 2。 所以需要的节点数为：2~4。 1.5.27 Kafka 如何压测？ 用 Kafka 官方自带的脚本，对 Kafka 进行压测。  生产者压测：kafka-producer-perf-test.sh  消费者压测：kafka-consumer-perf-test.sh 1）Kafka Producer 压力测试 （1）创建一个 test Topic，设置为 3 个分区 3 个副本 [atguigu@hadoop102 kafka]$ bin/kafka-topics.sh --bootstrap-server hadoop102:9092 --create --replication-factor 3 --partitions 3 -- topic test 尚硅谷大数据技术之高频面试题 ————————————————————————————— 41 （2）在/opt/module/kafka/bin 目录下面有这两个文件。我们来测试一下 [atguigu@hadoop105 kafka]$ bin/kafka-producer-perf-test.sh -- topic test --record-size 1024 --num-records 1000000 --throughput 10000 --producer-props bootstrap.servers=hadoop102:9092,hadoop103:9092,hadoop104:9092 batch.size=16384 linger.ms=0 参数说明：  record-size 是一条信息有多大，单位是字节，本次测试设置为 1k。  num-records 是总共发送多少条信息，本次测试设置为 100 万条。  throughput 是每秒多少条信息，设成-1，表示不限流，尽可能快的生产数据，可测 出生产者最大吞吐量。本次实验设置为每秒钟 1 万条。  producer-props 后面可以配置生产者相关参数，batch.size 配置为 16k。 输出结果： ap.servers=hadoop102:9092,hadoop103:9092,hadoop104:9092 batch.size=16384 linger.ms=0 37021 records sent, 7401.2 records/sec (7.23 MB/sec), 1136.0 ms avg latency, 1453.0 ms max latency. 。。。 。。。 33570 records sent, 6714.0 records/sec (6.56 MB/sec), 4549.0 ms avg latency, 5049.0 ms max latency. 1000000 records sent, 9180.713158 records/sec (8.97 MB/sec), 1894.78 ms avg latency, 5049.00 ms max latency, 1335 ms 50th, 4128 ms 95th, 4719 ms 99th, 5030 ms 99.9th. （3）调整 batch.size 大小 （4）调整 linger.ms 时间 （5）调整压缩方式 （6）调整缓存大小 2）Kafka Consumer 压力测试 （1）修改/opt/module/kafka/config/consumer.properties 文件中的一次拉取条数为 500 max.poll.records=500 （2）消费 100 万条日志进行压测 [atguigu@hadoop105 kafka]$ bin/kafka-consumer-perf-test.sh -- bootstrap-server hadoop102:9092,hadoop103:9092,hadoop104:9092 -- topic test --messages 1000000 --consumer.config config/consumer.properties 参数说明：  --bootstrap-server 指定 Kafka 集群地址  --topic 指定 topic 的名称  --messages 总共要消费的消息个数。本次实验 100 万条。 尚硅谷大数据技术之高频面试题 ————————————————————————————— 42 输出结果： start.time, end.time, data.consumed.in.MB, MB.sec, data.consumed.in.nMsg, nMsg.sec, rebalance.time.ms, fetch.time.ms, fetch.MB.sec, fetch.nMsg.sec 2022-01-20 09:58:26:171, 2022-01-20 09:58:33:321, 977.0166, 136.6457, 1000465, 139925.1748, 415, 6735, 145.0656, 148547.1418 （3）一次拉取条数为 2000 （4）调整 fetch.max.bytes 大小为 100m 1.5.28 磁盘选择 kafka 底层主要是顺序写，固态硬盘和机械硬盘的顺序写速度差不多。 建议选择普通的机械硬盘。 每天总数据量：1 亿条 * 1k ≈ 100g 100g * 副本 2 * 保存时间 3 天 / 0.7 ≈ 1T 建议三台服务器硬盘总大小，大于等于 1T。 1.5.29 内存选择 Kafka 内存组成：堆内存 + 页缓存 1）Kafka 堆内存建议每个节点：10g ~ 15g 在 kafka-server-start.sh 中修改 if [ "x$KAFKA_HEAP_OPTS" = "x" ]; then export KAFKA_HEAP_OPTS="-Xmx10G -Xms10G" fi （1）查看 Kafka 进程号 [atguigu@hadoop102 kafka]$ jps 2321 Kafka 5255 Jps 1931 QuorumPeerMain （2）根据 Kafka 进程号，查看 Kafka 的 GC 情况 [atguigu@hadoop102 kafka]$ jstat -gc 2321 1s 10 S0C S1C S0U S1U EC EU OC OU MC MU CCSC CCSU YGC YGCT FGC FGCT GCT 0.0 7168.0 0.0 7168.0 103424.0 60416.0 1986560.0 148433.5 52092.0 46656.1 6780.0 6202.2 13 0.531 0 0.000 0.531 0.0 7168.0 0.0 7168.0 103424.0 60416.0 1986560.0 148433.5 52092.0 46656.1 6780.0 6202.2 13 0.531 0 0.000 0.531 0.0 7168.0 0.0 7168.0 103424.0 60416.0 1986560.0 148433.5 52092.0 46656.1 6780.0 6202.2 13 0.531 0 0.000 0.531 0.0 7168.0 0.0 7168.0 103424.0 60416.0 1986560.0 148433.5 52092.0 46656.1 6780.0 6202.2 13 0.531 0 0.000 0.531 0.0 7168.0 0.0 7168.0 103424.0 60416.0 1986560.0 148433.5 52092.0 46656.1 6780.0 6202.2 13 0.531 0 0.000 0.531 0.0 7168.0 0.0 7168.0 103424.0 61440.0 1986560.0 148433.5 52092.0 46656.1 6780.0 6202.2 13 0.531 0 0.000 0.531 0.0 7168.0 0.0 7168.0 103424.0 61440.0 1986560.0 148433.5 52092.0 46656.1 6780.0 6202.2 13 0.531 0 0.000 0.531 0.0 7168.0 0.0 7168.0 103424.0 61440.0 1986560.0 148433.5 52092.0 46656.1 6780.0 6202.2 13 0.531 0 0.000 0.531 0.0 7168.0 0.0 7168.0 103424.0 61440.0 1986560.0 148433.5 52092.0 46656.1 6780.0 6202.2 13 0.531 0 0.000 0.531 0.0 7168.0 0.0 7168.0 103424.0 61440.0 1986560.0 148433.5 52092.0 46656.1 6780.0 6202.2 13 0.531 0 0.000 0.531 参数说明： YGC：年轻代垃圾回收次数； 尚硅谷大数据技术之高频面试题 ————————————————————————————— 43 （3）根据 Kafka 进程号，查看 Kafka 的堆内存 [atguigu@hadoop102 kafka]$ jmap -heap 2321 … … Heap Usage: G1 Heap: regions = 2048 capacity = 2147483648 (2048.0MB) used = 246367744 (234.95458984375MB) free = 1901115904 (1813.04541015625MB) 11.472392082214355% used 2）页缓存： 页缓存是 Linux 系统服务器的内存。我们只需要保证 1 个 segment（1g）中 25%的数据 在内存中就好。 每个节点页缓存大小 =（分区数 * 1g * 25%）/ 节点数。例如 10 个分区，页缓存大小 =（10 * 1g * 25%）/ 3 ≈ 1g 建议服务器内存大于等于 11G。 1.5.30 CPU 选择 1）默认配置 num.io.threads = 8 负责写磁盘的线程数。 num.replica.fetchers = 1 副本拉取线程数。 num.network.threads = 3 数据传输线程数。 2）建议配置 此外还有后台的一些其他线程，比如清理数据线程，Controller 负责感知和管控整个集 群的线程等等，这样算，每个 Broker 都会有上百个线程存在。根据经验，4 核 CPU 处理几 十个线程在高峰期会打满，8 核勉强够用，而且再考虑到集群上还要运行其他的服务，所以 部署 Kafka 的服务器一般建议在 16 核以上可以应对一两百个线程的工作，如果条件允许， 给到 24 核甚至 32 核就更好。 num.io.threads = 16 负责写磁盘的线程数。 num.replica.fetchers = 2 副本拉取线程数。 num.network.threads = 6 数据传输线程数。 服务器建议购买 32 核 CPU 尚硅谷大数据技术之高频面试题 ————————————————————————————— 44 1.5.31 网络选择 网络带宽 = 峰值吞吐量 ≈ 20MB/s ，选择千兆网卡即可。 100Mbps 单位是 bit；10M/s 单位是 byte ; 1byte = 8bit，100Mbps/8 = 12.5M/s。 一般百兆的网卡（100Mbps）、千兆的网卡（1000Mbps）、万兆的网卡（10000Mbps）。 一般百兆的网卡（100Mbps）、千兆的网卡（1000Mbps）、万兆的网卡（10000Mbps）。 100Mbps 单位是 bit；10M/s 单位是 byte ; 1byte = 8bit，100Mbps/8 = 12.5M/s。 通常选用千兆或者是万兆网卡。 1.5.32 Kafka 挂掉 在生产环境中，如果某个 Kafka 节点挂掉。 正常处理办法： （1）先看日志，尝试重新启动一下，如果能启动正常，那直接解决。 （2）如果重启不行，检查内存、CPU、网络带宽。调优=》调优不行增加资源 （3）如果将 Kafka 整个节点误删除，如果副本数大于等于 2，可以按照服役新节点的 方式重新服役一个新节点，并执行负载均衡。 1.5.33 服役新节点退役旧节点 可以通过 bin/kafka-reassign-partitions.sh 脚本服役和退役节点。 1.5.34 Kafka 单条日志传输大小 Kafka 对于消息体的大小默认为单条最大值是 1M 但是在我们应用场景中，常常会出现 一条消息大于 1M，如果不对 Kafka 进行配置。则会出现生产者无法将消息推送到 Kafka 或 消费者无法去消费 Kafka 里面的数据，这时我们就要对 Kafka 进行以下配置：server.properties 参数名称 描述 message.max.bytes 默认 1m，Broker 端接收每个批次消息最大值。 max.request.size 默认 1m，生产者发往 Broker 每个请求消息最大值。针对 Topic 级别设置消息体的大小。 replica.fetch.max.bytes 默认 1m，副本同步数据，每个批次消息最大值。 fetch.max.bytes 默认 Default: 52428800（50 m）。消费者获取服务器端一批消息 尚硅谷大数据技术之高频面试题 ————————————————————————————— 45 最大的字节数。如果服务器端一批次的数据大于该值（50m）仍 然可以拉取回来这批数据，因此，这不是一个绝对最大值。一 批次的大小受 message.max.bytes （ broker config ） or max.message.bytes （topic config）影响。 1.5.35 Kafka 参数优化 重点调优参数： （1）buffer.memory 32m （2）batch.size：16k （3）linger.ms 默认 0 调整 5-100ms （4）compression.type 采用压缩 snappy （5）消费者端调整 fetch.max.bytes 大小，默认是 50m。 （6）消费者端调整 max.poll.records 大小，默认是 500 条。 （7）单条日志大小：message.max.bytes、max.request.size、replica.fetch.max.bytes 适 当调整 2-10m （8）Kafka 堆内存建议每个节点：10g ~ 15g 在 kafka-server-start.sh 中修改 if [ "x$KAFKA_HEAP_OPTS" = "x" ]; then export KAFKA_HEAP_OPTS="-Xmx10G -Xms10G" fi （9）增加 CPU 核数 num.io.threads = 8 负责写磁盘的线程数 num.replica.fetchers = 1 副本拉取线程数 num.network.threads = 3 数据传输线程数 （10）日志保存时间 log.retention.hours 3 天 （11）副本数，调整为 2 尚硅谷大数据技术之高频面试题 ————————————————————————————— 46 1.6 Hive 1.6.1 Hive 的架构 Hadoop HDFS id atguigu atguigu MapReduce Yarn Hive Driver 1.用户创建table，create table … HDFS id atguigu 2 还有Tez / Spark等计算引擎 Meta store （默认 derby数 据库。 推荐 MySQL 数据库） 2.Metastor e中记录对 应表的路径 3.映射表关系 4. 用户根据业务需求编写相应的HQL语句 SQLParser 解析器 Logical Plan Gen 逻辑计划生成器 Logical Optimizer 逻辑优化器 Physical Optimizer 物理优化器 6.返回计算结果 Hive架构原理 Physical Plan Gen 物理计划生成器 Execution 执行器 Hive Client CLI JDBC/ODBC HiveServer2 将HQL语言中常用的操作（select，where， group等）用MapReduce写成很多模板 Semantic Analyzer 语义分析器 1.6.2 HQL 转换为 MR 流程 TOK_QUERY TOK_INSERT TOK_FROM TOK_DESTINATION TOK_SELECT TOK_TABNAME 抽象语法树 查询语句 select count(*) from test group by id; test TOK_DIR TOK_TMP_FILE TOK_SELEXPR TOK_FUNCTIONSTAR count TOK_GROUPBY TOK_TABLE_OR_COL id 抽象语法树 尚硅谷大数据技术之高频面试题 ————————————————————————————— 47 TableScan Select Operator Group By Operator Reduce Output Operator Group By Operator Select Operator File Output Operator 逻辑计划与物理计划 抽象语法树 逻 辑 计 划 及 其 优 化 Map Reduce Task Reduce Operator Tree Map Operator Tree TableScan Select Operator Group By Operator Reduce Output Operator Group By Operator Select Operator File Output Operator 物 理 计 划 及 其 优 化 （1）解析器（SQLParser）：将 SQL 字符串转换成抽象语法树（AST） （2）语义分析器（Semantic Analyzer）：将 AST 进一步抽象为 QueryBlock（可以理解为 一个子查询划分成一个 QueryBlock） （2）逻辑计划生成器（Logical Plan Gen）：由 QueryBlock 生成逻辑计划 （3）逻辑优化器（Logical Optimizer）：对逻辑计划进行优化 （4）物理计划生成器（Physical Plan Gen）：根据优化后的逻辑计划生成物理计划 （5）物理优化器（Physical Optimizer）：对物理计划进行优化 （6）执行器（Execution）：执行该计划，得到查询结果并返回给客户端 1.6.3 Hive 和数据库比较 Hive 和数据库除了拥有类似的查询语言，再无类似之处。 1）数据存储位置 Hive 存储在 HDFS 。数据库将数据保存在块设备或者本地文件系统中。 2）数据更新 Hive 中不建议对数据的改写。而数据库中的数据通常是需要经常进行修改的。 3）执行延迟 Hive 执行延迟较高。数据库的执行延迟较低。当然，这个是有条件的，即数据规模较小， 当数据规模大到超过数据库的处理能力的时候，Hive 的并行计算显然能体现出优势。 4）数据规模 尚硅谷大数据技术之高频面试题 ————————————————————————————— Hive 支持很大规模的数据计算；数据库可以支持的数据规模较小。 1.6.4 内部表和外部表 元数据、原始数据 1）删除数据时： 内部表：元数据、原始数据，全删除 外部表：元数据 只删除 2）在公司生产环境下，什么时候创建内部表，什么时候创建外部表？ 在公司中绝大多数场景都是外部表。 自己使用的临时表，才会创建内部表； 1.6.5 4 个 By 区别 （1）Order By：全局排序，只有一个 Reducer，通常配合 limit 使用，用于计算 TopN 或 者 BottomN。需要注意的是在有 limit N 时，每个 Mapper 都只会输出各自的前 N 行数据， 此时 Reducer 的压力不会太大，但是没有 Limit N 时，所有数据均会进入到一个 Reducer 中， 会导致其压力过大。因此一般会禁用 Order By 不带 Limit。 （2）Sort By：其语法和 Order By 相似，其能够保证每个 Reducer 的数据是有序的。 （3）Distrbute By：类似 MR 中 Partition，进行分区，结合 Sort By 使用。 （4） Cluster By：当 Distribute by 和 Sorts by 字段相同时，可以使用 Cluster by 方式。 Cluster by 兼具 Distribute by 和 Sort by 的功能。但是排序只能是升序排序，不能指定排序规 则为 ASC 或者 DESC。 1.6.6 系统函数 1）数值函数 （1）round：四舍五入；（2）ceil：向上取整；（3）floor：向下取整 2）字符串函数 （1）substring：截取字符串；（2）replace：替换；（3）regexp_replace：正则替换 （4）regexp：正则匹配；（5）repeat：重复字符串；（6）split：字符串切割 （7）nvl：替换 null 值；（8）concat：拼接字符串； （9）concat_ws：以指定分隔符拼接字符串或者字符串数组； （10）get_json_object：解析 JSON 字符串 48 尚硅谷大数据技术之高频面试题 ————————————————————————————— 3）日期函数 （1）unix_timestamp：返回当前或指定时间的时间戳 （2）from_unixtime：转化 UNIX 时间戳（从 1970-01-01 00:00:00 UTC 到指定时间的 秒数）到当前时区的时间格式 （3）current_date：当前日期 （4）current_timestamp：当前的日期加时间，并且精确的毫秒 （5）month：获取日期中的月；（6）day：获取日期中的日 （7）datediff：两个日期相差的天数（结束日期减去开始日期的天数） （8）date_add：日期加天数；（9）date_sub：日期减天数 （10）date_format：将标准日期解析成指定格式字符串 4）流程控制函数 （1）case when：条件判断函数 （2）if：条件判断，类似于 Java 中三元运算符 5）集合函数 （1）array：声明 array 集合 （2）map：创建 map 集合 （3）named_struct：声明 struct 的属性和值 （4）size：集合中元素的个数 （5）map_keys：返回 map 中的 key （6）map_values：返回 map 中的 value （7）array_contains：判断 array 中是否包含某个元素 （8）sort_array：将 array 中的元素排序 6）聚合函数 （1）collect_list：收集并形成 list 集合，结果不去重 （2）collect_set：收集并形成 set 集合，结果去重 1.6.7 自定义 UDF、UDTF 函数 1）在项目中是否自定义过 UDF、UDTF 函数，以及用他们处理了什么问题，及自定义步骤？ （1）目前项目中逻辑不是特别复杂就没有用自定义 UDF 和 UDTF （2）自定义 UDF：继承 G..UDF，重写核心方法 evaluate 49 尚硅谷大数据技术之高频面试题 ————————————————————————————— 50 （3）自定义 UDTF：继承自 GenericUDTF，重写 3 个方法：initialize（自定义输出的列 名和类型），process（将结果返回 forward（result）），close 2）企业中一般什么场景下使用 UDF/UDTF？ （1）因为自定义函数，可以将自定函数内部任意计算过程打印输出，方便调试。 （2）引入第三方 jar 包时，也需要。 1.6.8 窗口函数 一般在场景题中出现手写：分组 TopN、行转列、列转行。 窗口函数(window functions) 1 2 3 4 5 6 7 窗口函数，能为每行数据划分一个窗口，然后对窗 口范围内的数据进行计算，最后将计算结果返回给该行 数据。 定义 1 1&2 2&3 3&4 4&5 5&6 6&7 按照功能，常用窗口可划分为如下几类：聚合函数、跨行取值函数、排名函数。 1）聚合函数 max：最大值。 min：最小值。 sum：求和。 avg：平均值。 count：计数。 2）跨行取值函数 （1）lead 和 lag 尚硅谷大数据技术之高频面试题 ————————————————————————————— 51 select order_id, user_id, order_date, amount, lag(order_date,1, '1970-01-01') over (partition by user_id order by order_date) last_date, lead(order_date,1, '9999-12-31') over (partition by user_id order by order_date) next_date from order_info; 窗口函数(window functions) 常用窗口函数——lead和lag 功能：获取当前行的上/下边某行、某个字段的值。 order_id user_id order_date amount 1 1001 2022-01-01 10 2 1001 2022-01-02 20 3 1001 2022-01-03 10 4 1002 2022-01-04 30 5 1002 2022-01-05 40 6 1002 2022-01-06 20 语法： order_id user_id order_date amount last_date next_date 1 1001 2022-01-01 10 1970-01-01 2022-01-02 2 1001 2022-01-02 20 2022-01-01 2022-01-03 3 1001 2022-01-03 10 2022-01-02 9999-12-31 4 1002 2022-01-04 30 1970-01-01 2022-01-05 5 1002 2022-01-05 40 2022-01-05 2022-01-06 6 1002 2022-01-06 20 2022-01-06 9999-12-31 字段名 偏移量 默认值 思考：该查询语句 的结果是什么？ 注：lag 和 lead 函数不支持自定义窗口。 （2）first_value 和 last_value select order_id, user_id, order_date, amount, first_value(order_date,false) over (partition by user_id order by order_date) first_date, last_value(order_date,false) over (partition by user_id order by order_date) last_date from order_info; 窗口函数(window functions) 常用窗口函数——first_value和last_value 功能：获取窗口内某一列的第一个值/最后一个值 order_id user_id order_date amount 1 1001 2022-01-01 10 2 1001 2022-01-02 20 3 1001 2022-01-03 10 4 1002 2022-01-04 30 5 1002 2022-01-05 40 6 1002 2022-01-06 20 语法： order_id user_id order_date amount first_date last_date 1 1001 2022-01-01 10 2022-01-01 2022-01-03 2 1001 2022-01-02 20 2022-01-01 2022-01-03 3 1001 2022-01-03 10 2022-01-01 2022-01-03 4 1002 2022-01-04 30 2022-01-04 2022-01-06 5 1002 2022-01-05 40 2022-01-04 2022-01-06 6 1002 2022-01-06 20 2022-01-04 2022-01-06 字段名 是否跳过null 思考：该查询语句 的结果是什么？ 3）排名函数 尚硅谷大数据技术之高频面试题 ————————————————————————————— 52 select stu_id, course, score, rank() over(partition by course order by score desc) rk, dense_rank() over(partition by course order by score desc) dense_rk, row_number() over(partition by course order by score desc) rn from score_info; 窗口函数(window functions) 常用窗口函数——rank、dense_rank、row_number 功能：计算排名 stu_id course score 1 语文 99 2 语文 98 3 语文 95 4 数学 100 5 数学 100 6 数学 99 语法： stu_id course score rk dense_rk rn 1 语文 99 1 1 1 2 语文 98 2 2 2 3 语文 95 3 3 3 4 数学 100 1 1 1 5 数学 100 1 1 2 6 数学 99 3 2 3   注：rank 、dense_rank、row_number 不支持自定义窗口。 1.6.9 Hive 优化 1.6.9.1 分组聚合 一个分组聚合的查询语句，默认是通过一个 MapReduce Job 完成的。Map 端负责读取数 据，并按照分组字段分区，通过 Shuffle，将数据发往 Reduce 端，各组数据在 Reduce 端完 成最终的聚合运算。 分组聚合的优化主要围绕着减少 Shuffle 数据量进行，具体做法是 map-side 聚合。所谓 map-side 聚合，就是在 map 端维护一个 Hash Table，利用其完成部分的聚合，然后将部分聚 合的结果，按照分组字段分区，发送至 Reduce 端，完成最终的聚合。 map-side聚合原理 Map Reduce Map Task Hash Table （部分聚合） Map Task Reduce Task Hash Table （部分聚合） Reduce Task HDFS HDFS table result 最终聚合 最终聚合 Shuffle 分区字段为 group by字段 尚硅谷大数据技术之高频面试题 ————————————————————————————— 53 相关参数如下： -- 启用 map-side 聚合，默认是 true set hive.map.aggr=true; --用于检测源表数据是否适合进行 map-side 聚合。检测的方法是：先对若干条数据进行 map-side 聚合，若聚合后的条数和聚合前的条数比值小于该值，则认为该表适合进行 map side 聚合；否则，认为该表数据不适合进行 map-side 聚合，后续数据便不再进行 map side 聚合。 set hive.map.aggr.hash.min.reduction=0.5; - -用于检测源表是否适合 map-side 聚合的条数。 set hive.groupby.mapaggr.checkinterval=100000; --map-side 聚合所用的 hash table，占用 map task 堆内存的最大比例，若超出该 值，则会对 hash table 进行一次 flush。 set hive.map.aggr.hash.force.flush.memory.threshold=0.9; 1.6.9.2 Map Join Hive 中默认最稳定的 Join 算法是 Common Join。其通过一个 MapReduce Job 完成一个 Join 操作。Map 端负责读取 Join 操作所需表的数据，并按照关联字段进行分区，通过 Shuffle， 将其发送到 Reduce 端，相同 key 的数据在 Reduce 端完成最终的 Join 操作。 优化 Join 的最为常用的手段就是 Map Join，其可通过两个只有 Map 阶段的 Job 完成一 个 join 操作。第一个 Job 会读取小表数据，将其制作为 Hash Table，并上传至 Hadoop 分 布式缓存（本质上是上传至 HDFS）。第二个 Job 会先从分布式缓存中读取小表数据，并缓 存在 Map Task 的内存中，然后扫描大表数据，这样在 map 端即可完成关联操作。 注：由于 Map Join 需要缓存整个小标的数据，故只适用于大表 Join 小表的场景。 Distributed Cach （HDFS） Map Join原理 Map 1 Map Task 制作Hash Table HDFS small table big table Hash Table Map 2 Map Task 缓存Hash Table Map Task 缓存Hash Table 拉取小表数据并缓存 扫描大表数据并完成Join操作 相关参数如下： 尚硅谷大数据技术之高频面试题 ————————————————————————————— 54 -- 启动 Map Join 自动转换 set hive.auto.convert.join=true; -- 开启无条件转 Map Join set hive.auto.convert.join.noconditionaltask=true; --无条件转 Map Join 小表阈值，默认值 10M，推荐设置为 Map Task 总内存的三分之一 到二分之一 set hive.auto.convert.join.noconditionaltask.size=10000000; 1.6.9.3 SMB Map Join 上节提到，Map Join 只适用于大表 Join 小表的场景。若想提高大表 Join 大表的计算效 率，可使用 Sort Merge Bucket Map Join。 需要注意的是 SMB Map Join 有如下要求： （1）参与 Join 的表均为分桶表，且分桶字段为 Join 的关联字段。 （2）两表分桶数呈倍数关系。 （3）数据在分桶内是按关联字段有序的。 SMB Join 的核心原理如下：只要保证了上述三点要求的前两点，就能保证参与 Join 的 两张表的分桶之间具有明确的关联关系，因此就可以在两表的分桶间进行 Join 操作了。 Bucket对应关系 Table A Table B Bucket A-0 Bucket A-1 Bucket A-2 Bucket A-3 Bucket B-0 Bucket B-1 若能保证第三点，也就是参与 Join 的数据是有序的，这样就能使用数据库中常用的 Join 算法之一——Sort Merge Join 了，Merge Join 原理如下： 尚硅谷大数据技术之高频面试题 ————————————————————————————— 55 Sort Merge Join原理 order_detail order_id user_id product_id total_amount 1001 1 10 25.20 1002 2 11 33.10 1003 2 12 45.10 1004 3 13 44.90 1005 3 14 33.02 1006 4 15 100.10 user_info user_id gender name 1 男 张三 2 女 李四 3 女 王五 4 男 赵六 5 女 小红 order_id user_id product_id total_amount user_id gender name 1006 4 15 100.10 1004 3 13 44.90 1005 3 14 33.02 1002 2 11 33.10 1003 2 12 45.10 1001 1 10 25.20 4 男 赵六 3 女 王五 3 女 王五 2 女 李四 2 女 李四 1 男 张三 join on order_detail.user_id=user_info.user_id 在满足了上述三点要求之后，就能使用 SMB Map Join 了。 Sort Merge Bucket Map Join Map HDFS 表A 表B Map Task A-bucket-1 B-bucket-1 Map Task A-bucket-0 B-bucket-0 sort merge join sort merge join A-bucket-0 A-bucket-1 B-bucket-1 B-bucket-0 由于 SMB Map Join 无需构建 Hash Table 也无需缓存小表数据，故其对内存要求很低。 适用于大表 Join 大表的场景。 1.6.9.4 Reduce 并行度 Reduce 端的并行度，也就是 Reduce 个数，可由用户自己指定，也可由 Hive 自行根据 该 MR Job 输入的文件大小进行估算。 Reduce 端的并行度的相关参数如下： -- 指定 Reduce 端并行度，默认值为 -1，表示用户未指定 set mapreduce.job.reduces; 尚硅谷大数据技术之高频面试题 ————————————————————————————— 56 -- Reduce 端并行度最大值 set hive.exec.reducers.max; -- 单个 Reduce Task 计算的数据量，用于估算 Reduce 并行度 set hive.exec.reducers.bytes.per.reducer; Reduce 端并行度的确定逻辑如下： 若指定参数 mapreduce.job.reduces 的值为一个非负整数，则 Reduce 并行度为指定 值。否则，Hive 自行估算 Reduce 并行度，估算逻辑如下： 假设 Job 输入的文件大小为 totalInputBytes 参数 hive.exec.reducers.bytes.per.reducer 的值为 bytesPerReducer。 参数 hive.exec.reducers.max 的值为 maxReducers。 则 Reduce 端的并行度为： min (