1. 如何从大量的 URL 中找出相同的 URL？ 给定 a、b 两个文件，各存放 50 亿个 URL，每个 URL 各占 64B，内存限制是 4G。请找出 a、b 两个文件共同的 URL。 每个 URL 占 64B，那么 50 亿个 URL占用的空间大小约为 320GB。 由…

一千个读者眼中有一千个哈姆雷特，一千名 大数据 程序员心目中就有一千套 大数据面试题。本文就是笔者认为可以用来面试大数据 程序员的面试题。 这套题的题目跟公司和业务都没有关系，而且也并不代表笔者本人可以把这些题回答得非常好，笔者只是将一部分觉得比较好的题从收集的面试题里面抽出来…

1、集群的最主要瓶颈 磁盘IO 2、Hadoop运行模式 单机版、伪分布式模式、完全分布式模式 3、HDFS写流程 1）client 客户端发送上传请求，通过 RPC 与 namenode 建立通信，

大数据工程师是近几年异常火爆的职位，市场需求旺盛，众多互联网公司都打出了高薪招聘的广告，本文整理了网络上部分技术人员分享的各大互联网公司大数据类(Hadoop、Spark等)面试题以及面试时需要注意的一些问题，希望对各位技术人员有所帮助。 分享之前我还是要推荐下我自己创建的大数…

前言 随着 5G 时代的到来，大数据人工智能产业链又一次迎来了井喷式的爆发，随着岗位需求的不断增加，越来越多的人选择大数据课程，但是没有真正从事大数据工作的人面对企业面试有种无从下手的感觉，面对面试说

「Offer 驾到，掘友接招！我正在参与2022春招系列活动-经验复盘，点击查看 活动详情 题目来源 作者：是锅粥 链接：https://www.nowcoder.com/discuss/745950

1、HAnamenode 是如何工作的? ZKFailoverController主要职责 1）健康监测：周期性的向它监控的NN发送健康探测命令，从而来确定某个NameNode是否处于健康状态，如果机

本文整理了互联网大厂数据开发、数据分析、数仓等数据相关岗位面试过程中经常出现的SQL面试题，并给出了参考答案。涉及了炸裂函数、开窗函数、聚合函数开窗、在线直播人数等 以及这两年各大厂面疯了各种连续问题

1. hadoop 架构 Hadoop2.0版本，引入了Yarn。核心：HDFS+Yarn+Mapreduce Yarn是资源调度框架。能够细粒度的管理和调度任务。此外，还能够支持其他的计算框架，比如spark等。 Namenode：也叫名称节点，是HDFS的守护程序（一个核心…

六、描述HBase 中scan 和get 的功能以及实现的异同？七、hbase如何导入数据？八、hbase 的存储结构？九、解释下 hbase 实时查询的原理十、详细描述 HBase 中一个 cell 的结构？十一、简述 HBase 中 compact 用途是什么，什么时候触发，...

1. 通常来说，Spark与MapReduce相比，Spark运行效率更高。请说明效率更高来源于Spark内置的哪些机制？ spark是借鉴了Mapreduce,并在其基础上发展起来的，继承了其分布式

1、Flink怎么做压力测试和监控？ 参考答案：我们一般碰到的压力来自以下几个方面： （1）产生数据流的速度如果过快，而下游的算子消费不过来的话，会产生背压。背压的监控可以使用FlinkWebUI(l

Redis熟不熟，介绍下它有几种数据类型？我回答了8种，面试官说只有5种，后来在网上搜了搜，版本也很多。 手撕代码第一道是力扣原题：169. 多数元素 手撕代码第二道如何实现最小栈（也是力扣原题155. 最小栈），可能时间有限，没有让手写，说一下思路。 自我介绍之后，就全程几乎…

local 本地，通常是测试的时候用。 standalone，Spark 自己模拟作为一个调度系统，任务提交给 Master。 SparkonYarn 交给Yarn来进行资源调度，有 yarn-clu

​ 目录 HDFS文件写入和读取流程 HDFS组成架构 介绍下HDFS，说下HDFS优缺点，以及使用场景 HDFS作用 HDFS的容错机制 HDFS的存储机制 HDFS的副本机制 HDFS的常见数据格

什么是数据湖 数据湖（Data Lake）是一个大型数据存储和处理系统， 它能够存储各种类型和格式的数据，包括结构化数据、半结构化数据和非结构化数据。以下是关于数据湖的详细解释： 定义与特点 数据存储

​ 1、介绍下YARN 2、YARN有几个模块 3、YARN工作机制 4、YARN有什么优势，能解决什么问题? 5、YARN容错机制 6、YARN高可用 7、YARN调度器 8、YARN中Contai

分享大数据常见的面试题 一、mr的shuffle流程 说到mr的Shuffle，那么首先要明确shuffle属于哪个阶段。shuffle就是从Map端输出到Reduce输入的整个过程，这个过程广义上称

介绍下Flume  Flume架构  Flume有哪些Source  说下Flume事务机制  介绍下Flume采集数据的原理？底层实现？  Flume如何保证数据的可靠性  Flume传输数据时如何

介绍一下Mysql和Hivesql的区别？ 一方面，可以从底层原理出发回答，例如： 查询语言不同： Hive是hql语言，Mysql是sql语句； 存储位置不同： Hive是建立在 Hadoop 之上

Spark解决什么问题 二 Spark为什么会有自己的资源调度器 三 Spark运行模式 四 Spark常用端口号 五 Spark提交作业参数 六 Spark的transformation算子

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

Spark是一个围绕速度、易用性和复杂分析构建的大数据处理框架，Spark提供了一个全面、统一的框架用于管理各种有着不同性质(文本数据、图表数据等)的数据集和数据源(批量数据或实时的流数据)的大数据处理的需求。成为大数据核心技术之一，自然也成为了众多企业面试的核心专业问题，小编…

Spark系列面试题 Spark面试题（一） Spark面试题（二） Spark面试题（三） Spark面试题（四） Spark面试题（五）——数据倾斜调优 Spark面试题（六）——Spark资源调

微信搜索公众号：知了小巷公众号后台回复“资料”两个字，有大数据神秘学习大礼包！1.Spark的几种部署模式及其特点SparkSubmit#prepareSubmitEnvironment本地模式Spa

## Spark系列面试题 - [Spark面试题（一）](https://www.ikeguang.com/?p=1922) - [Spark面试题（二）](https://www.ikeguang

Spark是一种由Scala语言开发的快速、通用、可扩展的大数据分析引擎。Spark Core中提供了Spark最基础与最核心

1）本地模式   Spark不一定非要跑在hadoop集群，可以在本地，起多个线程的方式来指定。将Spark应用以多线程的方式直接运行在本地，一般都是为了方便调试，本地模式分三类   local：只启动一个executor   local[k]:启动k个executor   lo...

Spark的任务执行流程 https://wenku.baidu.com/view/9bf37bd07f1cfad6195f312b3169a4517723e513.html Spark总体架构和运行

简单介绍一下 Flink   Flink 是一个框架和分布式处理引擎，用于对无界和有界数据流进行有状态计算。并且 Flink 提供了数据分布、容错机制以及资源管理等核心功能。Flink提供了诸多高抽

概述2019年是大数据实时计算领域最不平凡的一年，2019年1月阿里巴巴Blink（内部的Flink分支版本）开源，大数据领域一夜间从Spark独步天下走向了两强争霸的时代。Flink因为其天然的流式

有没有去面试的时候被问到Flink的面试题你答不上来，为什么那？，菜吗？ 不是。原因是你接触的面试题太少了，那我今天就根据不同的群体来给大家你分享。 好今天的Flink的题目就分享到这里，背过上面的那些题目害怕面试官提问？信自己，努力和汗水总会能得到回报的。我是大数据老哥，我们…

相信小伙伴们对于Flink一定不会感到陌生，作为连续三年蝉联第一，荣膺全球最活跃的 Apache 开源项目，Flink在中国的热度也一直是居高不下。近几年，在社区的推动下，Flink 技术栈在越来越多的公司开始得到应用，因此在大数据的求职招聘中，对于Flink的着重考察也变得越…

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

1，简单介绍一下 Flink Flink 是一个框架和分布式处理引擎，用于对无界和有界数据流进行有状态计算。并且 Flink 提供了数据分布、容错机制以及资源管理等核心功能。Flink提供了诸多高抽象

Flink中的执行图一般是可以分为四类，按照生成顺序分别为：StreamGraph-> JobGraph-> ExecutionGraph->物理执行图。顾名思义，这里代表的是我们编写的流程序图。通过Stream API生成，这是执行图的最原始拓扑数据结构。StreamGraph...

16. Flink中有哪些窗口？ Flink 支持两种划分窗口的方式，按照time和count。如果根据时间划分窗口，那么它就是一个time-window 如果根据数据划分窗口，那么它就是一个coun

1 Flink的并行度了解吗？Flink的并行度设置是怎样的？ Flink中的任务被分为多个并行任务来执行，其中每个并行的实例处理一部分数据。这些并行实例的数量被称为并行度。我们在实际生产环境中可以从

1. 如何从大量的 URL 中找出相同的 URL？ 给定 a、b 两个文件，各存放 50 亿个 URL，每个 URL 各占 64B，内存限制是 4G。请找出 a、b 两个文件共同的 URL。 每个 URL 占 64B，那么 50 亿个 URL占用的空间大小约为 320GB。 由…

一千个读者眼中有一千个哈姆雷特，一千名 大数据 程序员心目中就有一千套 大数据面试题。本文就是笔者认为可以用来面试大数据 程序员的面试题。 这套题的题目跟公司和业务都没有关系，而且也并不代表笔者本人可以把这些题回答得非常好，笔者只是将一部分觉得比较好的题从收集的面试题里面抽出来…

1、集群的最主要瓶颈 磁盘IO 2、Hadoop运行模式 单机版、伪分布式模式、完全分布式模式 3、HDFS写流程 1）client 客户端发送上传请求，通过 RPC 与 namenode 建立通信，

大数据工程师是近几年异常火爆的职位，市场需求旺盛，众多互联网公司都打出了高薪招聘的广告，本文整理了网络上部分技术人员分享的各大互联网公司大数据类(Hadoop、Spark等)面试题以及面试时需要注意的一些问题，希望对各位技术人员有所帮助。 分享之前我还是要推荐下我自己创建的大数…

前言 随着 5G 时代的到来，大数据人工智能产业链又一次迎来了井喷式的爆发，随着岗位需求的不断增加，越来越多的人选择大数据课程，但是没有真正从事大数据工作的人面对企业面试有种无从下手的感觉，面对面试说

「Offer 驾到，掘友接招！我正在参与2022春招系列活动-经验复盘，点击查看 活动详情 题目来源 作者：是锅粥 链接：https://www.nowcoder.com/discuss/745950

1、HAnamenode 是如何工作的? ZKFailoverController主要职责 1）健康监测：周期性的向它监控的NN发送健康探测命令，从而来确定某个NameNode是否处于健康状态，如果机

本文整理了互联网大厂数据开发、数据分析、数仓等数据相关岗位面试过程中经常出现的SQL面试题，并给出了参考答案。涉及了炸裂函数、开窗函数、聚合函数开窗、在线直播人数等 以及这两年各大厂面疯了各种连续问题

1. hadoop 架构 Hadoop2.0版本，引入了Yarn。核心：HDFS+Yarn+Mapreduce Yarn是资源调度框架。能够细粒度的管理和调度任务。此外，还能够支持其他的计算框架，比如spark等。 Namenode：也叫名称节点，是HDFS的守护程序（一个核心…

六、描述HBase 中scan 和get 的功能以及实现的异同？七、hbase如何导入数据？八、hbase 的存储结构？九、解释下 hbase 实时查询的原理十、详细描述 HBase 中一个 cell 的结构？十一、简述 HBase 中 compact 用途是什么，什么时候触发，...

1. 通常来说，Spark与MapReduce相比，Spark运行效率更高。请说明效率更高来源于Spark内置的哪些机制？ spark是借鉴了Mapreduce,并在其基础上发展起来的，继承了其分布式

1、Flink怎么做压力测试和监控？ 参考答案：我们一般碰到的压力来自以下几个方面： （1）产生数据流的速度如果过快，而下游的算子消费不过来的话，会产生背压。背压的监控可以使用FlinkWebUI(l

Redis熟不熟，介绍下它有几种数据类型？我回答了8种，面试官说只有5种，后来在网上搜了搜，版本也很多。 手撕代码第一道是力扣原题：169. 多数元素 手撕代码第二道如何实现最小栈（也是力扣原题155. 最小栈），可能时间有限，没有让手写，说一下思路。 自我介绍之后，就全程几乎…

local 本地，通常是测试的时候用。 standalone，Spark 自己模拟作为一个调度系统，任务提交给 Master。 SparkonYarn 交给Yarn来进行资源调度，有 yarn-clu

​ 目录 HDFS文件写入和读取流程 HDFS组成架构 介绍下HDFS，说下HDFS优缺点，以及使用场景 HDFS作用 HDFS的容错机制 HDFS的存储机制 HDFS的副本机制 HDFS的常见数据格

什么是数据湖 数据湖（Data Lake）是一个大型数据存储和处理系统， 它能够存储各种类型和格式的数据，包括结构化数据、半结构化数据和非结构化数据。以下是关于数据湖的详细解释： 定义与特点 数据存储

​ 1、介绍下YARN 2、YARN有几个模块 3、YARN工作机制 4、YARN有什么优势，能解决什么问题? 5、YARN容错机制 6、YARN高可用 7、YARN调度器 8、YARN中Contai

分享大数据常见的面试题 一、mr的shuffle流程 说到mr的Shuffle，那么首先要明确shuffle属于哪个阶段。shuffle就是从Map端输出到Reduce输入的整个过程，这个过程广义上称

介绍下Flume  Flume架构  Flume有哪些Source  说下Flume事务机制  介绍下Flume采集数据的原理？底层实现？  Flume如何保证数据的可靠性  Flume传输数据时如何

介绍一下Mysql和Hivesql的区别？ 一方面，可以从底层原理出发回答，例如： 查询语言不同： Hive是hql语言，Mysql是sql语句； 存储位置不同： Hive是建立在 Hadoop 之上

Spark解决什么问题 二 Spark为什么会有自己的资源调度器 三 Spark运行模式 四 Spark常用端口号 五 Spark提交作业参数 六 Spark的transformation算子

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

Spark是一个围绕速度、易用性和复杂分析构建的大数据处理框架，Spark提供了一个全面、统一的框架用于管理各种有着不同性质(文本数据、图表数据等)的数据集和数据源(批量数据或实时的流数据)的大数据处理的需求。成为大数据核心技术之一，自然也成为了众多企业面试的核心专业问题，小编…

Spark系列面试题 Spark面试题（一） Spark面试题（二） Spark面试题（三） Spark面试题（四） Spark面试题（五）——数据倾斜调优 Spark面试题（六）——Spark资源调

微信搜索公众号：知了小巷公众号后台回复“资料”两个字，有大数据神秘学习大礼包！1.Spark的几种部署模式及其特点SparkSubmit#prepareSubmitEnvironment本地模式Spa

## Spark系列面试题 - [Spark面试题（一）](https://www.ikeguang.com/?p=1922) - [Spark面试题（二）](https://www.ikeguang

Spark是一种由Scala语言开发的快速、通用、可扩展的大数据分析引擎。Spark Core中提供了Spark最基础与最核心

1）本地模式   Spark不一定非要跑在hadoop集群，可以在本地，起多个线程的方式来指定。将Spark应用以多线程的方式直接运行在本地，一般都是为了方便调试，本地模式分三类   local：只启动一个executor   local[k]:启动k个executor   lo...

Spark的任务执行流程 https://wenku.baidu.com/view/9bf37bd07f1cfad6195f312b3169a4517723e513.html Spark总体架构和运行

简单介绍一下 Flink   Flink 是一个框架和分布式处理引擎，用于对无界和有界数据流进行有状态计算。并且 Flink 提供了数据分布、容错机制以及资源管理等核心功能。Flink提供了诸多高抽

概述2019年是大数据实时计算领域最不平凡的一年，2019年1月阿里巴巴Blink（内部的Flink分支版本）开源，大数据领域一夜间从Spark独步天下走向了两强争霸的时代。Flink因为其天然的流式

有没有去面试的时候被问到Flink的面试题你答不上来，为什么那？，菜吗？ 不是。原因是你接触的面试题太少了，那我今天就根据不同的群体来给大家你分享。 好今天的Flink的题目就分享到这里，背过上面的那些题目害怕面试官提问？信自己，努力和汗水总会能得到回报的。我是大数据老哥，我们…

相信小伙伴们对于Flink一定不会感到陌生，作为连续三年蝉联第一，荣膺全球最活跃的 Apache 开源项目，Flink在中国的热度也一直是居高不下。近几年，在社区的推动下，Flink 技术栈在越来越多的公司开始得到应用，因此在大数据的求职招聘中，对于Flink的着重考察也变得越…

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

1，简单介绍一下 Flink Flink 是一个框架和分布式处理引擎，用于对无界和有界数据流进行有状态计算。并且 Flink 提供了数据分布、容错机制以及资源管理等核心功能。Flink提供了诸多高抽象

Flink中的执行图一般是可以分为四类，按照生成顺序分别为：StreamGraph-> JobGraph-> ExecutionGraph->物理执行图。顾名思义，这里代表的是我们编写的流程序图。通过Stream API生成，这是执行图的最原始拓扑数据结构。StreamGraph...

16. Flink中有哪些窗口？ Flink 支持两种划分窗口的方式，按照time和count。如果根据时间划分窗口，那么它就是一个time-window 如果根据数据划分窗口，那么它就是一个coun

1 Flink的并行度了解吗？Flink的并行度设置是怎样的？ Flink中的任务被分为多个并行任务来执行，其中每个并行的实例处理一部分数据。这些并行实例的数量被称为并行度。我们在实际生产环境中可以从

题目：小红书大数据开发面试 - 你对大数据有什么理解？

原文要点：大数据主要用于处理海量数据的技术工具。2012年开始火起来，Pig/Storm当时流行。政府对大数据大力支持上升到国家战略。目前步入后红海时代，对实时性要求更高，Spark/Flink很火。未来SQL化是趋势，物联网兴起带来更多数据。

---

🤖 AI解析：
答案/思路：大数据 = 海量数据处理技术体系。从离线批处理（Hadoop时代）到实时流处理（Spark/Flink时代），再到SQL化+湖仓一体的趋势。

📌 关键知识点：大数据发展历程（Hadoop→Spark→Flink）、实时计算趋势、SQL化发展方向、物联网数据增长

⚠️ 易错点：1) 不要只说数据量大，要讲技术栈演进；2) 需要区分离线/实时场景；3) 要结合业务场景说，不要纯理论

题目：小红书大数据面试 - Hadoop有哪些了解？优势和劣势？

原文要点：Hadoop是大数据基石，分为HDFS（存储）、MapReduce（计算）、Yarn（调度）。优势：海量离线存储、MR稳定容错、数据安全（NN HA）。劣势：处理慢（比Spark差20倍）、不支持多任务同时执行、基于磁盘而非内存。

---

🤖 AI解析：
答案/思路：Hadoop三核心组件分工明确。优势在于存储可靠+计算容错；劣势在于速度（磁盘IO瓶颈）和并发能力弱。NameNode HA通过双NN策略实现高可用。

📌 关键知识点：HDFS存储机制、MapReduce计算模型、YARN资源调度、NameNode HA、Hadoop3纠删码优化

⚠️ 易错点：1) Hadoop3的纠删码将3倍存储压缩到1.5倍，这是较新特性；2) 不要混淆YARN和ZooKeeper的角色；3) MapReduce稳定性好但速度差是核心矛盾

题目：小红书大数据面试 - 不同database的应用场景和特点？

原文要点：Hive-离线海量数仓、HBase-实时海量数仓、ClickHouse-实时海量数仓支持SQL、ES-全文检索引擎、MySQL-传统RDBMS。

---

🤖 AI解析：
答案/思路：按场景选数据库：离线分析用Hive，实时查询用ClickHouse，全文检索用ES，海量随机读写用HBase，业务事务用MySQL。

📌 关键知识点：OLAP vs OLTP、列式存储（ClickHouse/HBase）vs 行式存储（MySQL）、倒排索引（ES）、数仓分层（Hive离线/ClickHouse实时）

⚠️ 易错点：1) HBase和ClickHouse都做实时但场景不同：HBase适合随机读写，CK适合聚合分析；2) Hive底层可切换Tez/Spark引擎不是只有MR；3) ES不只做搜索也能做分析

题目：小红书大数据面试 - Spark Shuffle原理，Hash Shuffle和Sort Shuffle的区别？

---

🤖 AI解析：
答案/思路：Hash Shuffle（1.2前）：每个Mapper为每个Reducer生成一个文件，小文件数=M*R，海量文件导致IO压力。Sort Shuffle（1.2+）：Mapper端先排序再写，引入Index文件，文件数=2*M，大幅减少。Tungsten Sort进一步优化为序列化排序。

📌 关键知识点：宽依赖vs窄依赖、Shuffle划分Stage边界、Hash Shuffle小文件问题、Sort Shuffle排序+索引机制、UnsafeShuffle/Tungsten优化

⚠️ 易错点：1) Hash Shuffle的Consolidated版本将文件数降为Core*R而非M*R；2) Sort Shuffle在数据量小于spark.shuffle.sort.bypassMergeThreshold时走Bypass机制不排序；3) 不要只说Spark比Hadoop快因为内存计算，Shuffle优化也是关键

题目：小红书大数据面试 - Hadoop和Spark的区别和优劣？

---

🤖 AI解析：
答案/思路：核心区别是计算模型：Hadoop MR每步写磁盘（Map→Shuffle→Reduce），Spark DAG内存管道减少IO。Spark快但需要更多内存资源，MR慢但稳定容错好。

📌 关键知识点：DAG执行模型vs MR线性模型、内存计算vs磁盘计算、迭代计算优势（ML/图计算）、RDD血缘线容错、资源需求差异

⚠️ 易错点：1) Spark并非全内存，Shuffle仍会写磁盘；2) MR的稳定性优势在小集群不明显；3) Spark Streaming是微批次不是真正流处理，Flink才是

题目：小红书大数据面试 - Spark分Stage的原则是什么？

---

🤖 AI解析：
答案/思路：Spark按宽依赖切分Stage。从后往前遍历DAG，遇到宽依赖就断开形成新Stage，窄依赖的算子Pipeline在同一个Stage内执行。

📌 关键知识点：宽依赖（Shuffle Dependency）vs窄依赖（Narrow Dependency）、Stage划分算法、Pipeline执行、groupByKey/map/filter的依赖类型

⚠️ 易错点：1) map/filter是窄依赖但coalesce(numPartitions, shuffle=true)会强制Shuffle变宽依赖；2) 宽依赖不是不好，是Stage边界的自然划分；3) 分Stage是从最后RDD逆向遍历

题目：小红书/拼多多等大厂Flink面试 - Flink架构是怎样的？集群有哪些角色？

原文要点：Flink架构以分布式流处理为核心，核心组件包括JobManager、TaskManager和Client。JobManager是Master角色，负责接收Job、协调Checkpoint、Failover恢复。TaskManager是Worker角色，执行Task。Client提交Flink程序。

---

🤖 AI解析：
答案/思路：Flink主从架构：JobManager（调度+容错+协调）、TaskManager（执行+心跳+资源汇报）、Client（预处理+提交）。YARN模式下Client提交后可断开，Standalone模式需ZK做HA。

📌 关键知识点：主从模型、Checkpoint协调、Failover机制、TaskSlot资源隔离、YARN/Standalone/K8s部署模式

⚠️ 易错点：1) YARN模式下JobManager故障由YARN自动重启，不需要额外HA配置；2) TaskSlot和Parallelism不是一回事，一个Slot可运行多个TaskChain；3) Client不是集群运行时组件

题目：小红书大数据面试 - Flink如何实现Exactly-Once语义？

---

🤖 AI解析：
答案/思路：Flink Exactly-Once依赖两层保障：1) 内部：Checkpoint机制（Chandy-Lamport分布式快照算法），定期对全部算子状态做快照，故障时从最近Checkpoint恢复；2) 外部：Sink端支持两阶段提交（2PC）或幂等写入，确保外部系统数据一致。Kafka Source端配合Checkpoint提交offset。

📌 关键知识点：Chandy-Lamport算法、Checkpoint Barrier对齐、两阶段提交（2PC）、Kafka offset管理、幂等写入

⚠️ 易错点：1) Exactly-Once需要Source+内部+Sink三层配合，缺一不可；2) Checkpoint间隔太短影响吞吐，太长恢复慢；3) Barrier对齐模式 vs 未对齐模式的取舍

题目：小红书大数据面试 - Flink和Spark Streaming有什么区别？

---

🤖 AI解析：
答案/思路：核心区别是处理模型：Flink是真正的流处理（事件驱动，逐条处理），Spark Streaming是微批次流处理（DStream=RDD序列，按batch间隔切批）。Flink延迟更低（毫秒级），Spark Streaming延迟取决于batch间隔（秒级）。Flink支持事件时间+Watermark处理乱序数据，Spark Streaming主要用处理时间。

📌 关键知识点：流处理vs微批次、事件时间vs处理时间、Watermark机制、State管理差异、Checkpoint机制对比

⚠️ 易错点：1) Spark Structured Streaming已引入事件时间和Watermark，不要只说Spark不支持事件时间；2) Flink的批处理模式（BATCH execution mode）也支持了；3) 两者的容错机制本质不同：Flink是分布式快照，Spark是RDD血缘追踪+Checkpoint

题目：大厂Flink面试 - Flink的Checkpoint存在哪里？

原文要点：Checkpoint可存储在内存、文件系统（HDFS/NFS）或RocksDB中。Checkpoint定期记录应用状态用于故障恢复。

---

🤖 AI解析：
答案/思路：三种存储后端：1) MemoryStateBackend（状态在JM内存，快照在JM内存，适合测试小状态）；2) FsStateBackend（状态在TM内存，快照写到文件系统，适合中等状态生产）；3) RocksDBStateBackend（状态在RocksDB本地磁盘，快照到文件系统，适合大状态生产场景）。

📌 关键知识点：StateBackend三种实现、RocksDB增量Checkpoint、State大小限制、异步快照vs同步快照

⚠️ 易错点：1) MemoryStateBackend默认单状态最大5MB且只存JM内存，生产禁用；2) RocksDB支持增量Checkpoint大幅减少IO；3) 开启增量Checkpoint需设置state.backend.incremental=true

题目：数据开发面试题 - Flink反压（Backpressure）问题的诊断与处理。生产环境中Flink实时ETL任务出现明显延迟，下游Kafka消费lag持续上涨。

---

🤖 AI解析：
答案/思路：反压诊断三步法：1) Flink Web UI看Backpressure指标（OK→LOW→HIGH）；2) 定位瓶颈算子（通常是Sink或重算子）；3) 分析根因（数据倾斜、GC、外部系统慢、并行度不足）。解决方案：增加并行度、优化数据倾斜（LocalAgg+GlobalAgg）、调整GC策略、异步IO写外部系统。

📌 关键知识点：反压传播机制、Web UI反压指标、数据倾斜处理（两阶段聚合）、异步IO、GC调优

⚠️ 易错点：1) 反压是Flink自保护机制不是bug，不要盲目调参；2) 数据倾斜时增加并行度无效，需先打散key；3) Sink端慢不要只加并行度，检查外部系统瓶颈

1. 如何从大量的 URL 中找出相同的 URL？ 给定 a、b 两个文件，各存放 50 亿个 URL，每个 URL 各占 64B，内存限制是 4G。请找出 a、b 两个文件共同的 URL。 每个 URL 占 64B，那么 50 亿个 URL占用的空间大小约为 320GB。 由…

一千个读者眼中有一千个哈姆雷特，一千名 大数据 程序员心目中就有一千套 大数据面试题。本文就是笔者认为可以用来面试大数据 程序员的面试题。 这套题的题目跟公司和业务都没有关系，而且也并不代表笔者本人可以把这些题回答得非常好，笔者只是将一部分觉得比较好的题从收集的面试题里面抽出来…

1、集群的最主要瓶颈 磁盘IO 2、Hadoop运行模式 单机版、伪分布式模式、完全分布式模式 3、HDFS写流程 1）client 客户端发送上传请求，通过 RPC 与 namenode 建立通信，

大数据工程师是近几年异常火爆的职位，市场需求旺盛，众多互联网公司都打出了高薪招聘的广告，本文整理了网络上部分技术人员分享的各大互联网公司大数据类(Hadoop、Spark等)面试题以及面试时需要注意的一些问题，希望对各位技术人员有所帮助。 分享之前我还是要推荐下我自己创建的大数…

前言 随着 5G 时代的到来，大数据人工智能产业链又一次迎来了井喷式的爆发，随着岗位需求的不断增加，越来越多的人选择大数据课程，但是没有真正从事大数据工作的人面对企业面试有种无从下手的感觉，面对面试说

「Offer 驾到，掘友接招！我正在参与2022春招系列活动-经验复盘，点击查看 活动详情 题目来源 作者：是锅粥 链接：https://www.nowcoder.com/discuss/745950

1、HAnamenode 是如何工作的? ZKFailoverController主要职责 1）健康监测：周期性的向它监控的NN发送健康探测命令，从而来确定某个NameNode是否处于健康状态，如果机

本文整理了互联网大厂数据开发、数据分析、数仓等数据相关岗位面试过程中经常出现的SQL面试题，并给出了参考答案。涉及了炸裂函数、开窗函数、聚合函数开窗、在线直播人数等 以及这两年各大厂面疯了各种连续问题

1. hadoop 架构 Hadoop2.0版本，引入了Yarn。核心：HDFS+Yarn+Mapreduce Yarn是资源调度框架。能够细粒度的管理和调度任务。此外，还能够支持其他的计算框架，比如spark等。 Namenode：也叫名称节点，是HDFS的守护程序（一个核心…

六、描述HBase 中scan 和get 的功能以及实现的异同？七、hbase如何导入数据？八、hbase 的存储结构？九、解释下 hbase 实时查询的原理十、详细描述 HBase 中一个 cell 的结构？十一、简述 HBase 中 compact 用途是什么，什么时候触发，...

1. 通常来说，Spark与MapReduce相比，Spark运行效率更高。请说明效率更高来源于Spark内置的哪些机制？ spark是借鉴了Mapreduce,并在其基础上发展起来的，继承了其分布式

1、Flink怎么做压力测试和监控？ 参考答案：我们一般碰到的压力来自以下几个方面： （1）产生数据流的速度如果过快，而下游的算子消费不过来的话，会产生背压。背压的监控可以使用FlinkWebUI(l

Redis熟不熟，介绍下它有几种数据类型？我回答了8种，面试官说只有5种，后来在网上搜了搜，版本也很多。 手撕代码第一道是力扣原题：169. 多数元素 手撕代码第二道如何实现最小栈（也是力扣原题155. 最小栈），可能时间有限，没有让手写，说一下思路。 自我介绍之后，就全程几乎…

local 本地，通常是测试的时候用。 standalone，Spark 自己模拟作为一个调度系统，任务提交给 Master。 SparkonYarn 交给Yarn来进行资源调度，有 yarn-clu

​ 目录 HDFS文件写入和读取流程 HDFS组成架构 介绍下HDFS，说下HDFS优缺点，以及使用场景 HDFS作用 HDFS的容错机制 HDFS的存储机制 HDFS的副本机制 HDFS的常见数据格

什么是数据湖 数据湖（Data Lake）是一个大型数据存储和处理系统， 它能够存储各种类型和格式的数据，包括结构化数据、半结构化数据和非结构化数据。以下是关于数据湖的详细解释： 定义与特点 数据存储

​ 1、介绍下YARN 2、YARN有几个模块 3、YARN工作机制 4、YARN有什么优势，能解决什么问题? 5、YARN容错机制 6、YARN高可用 7、YARN调度器 8、YARN中Contai

分享大数据常见的面试题 一、mr的shuffle流程 说到mr的Shuffle，那么首先要明确shuffle属于哪个阶段。shuffle就是从Map端输出到Reduce输入的整个过程，这个过程广义上称

介绍下Flume  Flume架构  Flume有哪些Source  说下Flume事务机制  介绍下Flume采集数据的原理？底层实现？  Flume如何保证数据的可靠性  Flume传输数据时如何

介绍一下Mysql和Hivesql的区别？ 一方面，可以从底层原理出发回答，例如： 查询语言不同： Hive是hql语言，Mysql是sql语句； 存储位置不同： Hive是建立在 Hadoop 之上

Spark解决什么问题 二 Spark为什么会有自己的资源调度器 三 Spark运行模式 四 Spark常用端口号 五 Spark提交作业参数 六 Spark的transformation算子

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

Spark是一个围绕速度、易用性和复杂分析构建的大数据处理框架，Spark提供了一个全面、统一的框架用于管理各种有着不同性质(文本数据、图表数据等)的数据集和数据源(批量数据或实时的流数据)的大数据处理的需求。成为大数据核心技术之一，自然也成为了众多企业面试的核心专业问题，小编…

Spark系列面试题 Spark面试题（一） Spark面试题（二） Spark面试题（三） Spark面试题（四） Spark面试题（五）——数据倾斜调优 Spark面试题（六）——Spark资源调

微信搜索公众号：知了小巷公众号后台回复“资料”两个字，有大数据神秘学习大礼包！1.Spark的几种部署模式及其特点SparkSubmit#prepareSubmitEnvironment本地模式Spa

## Spark系列面试题 - [Spark面试题（一）](https://www.ikeguang.com/?p=1922) - [Spark面试题（二）](https://www.ikeguang

Spark是一种由Scala语言开发的快速、通用、可扩展的大数据分析引擎。Spark Core中提供了Spark最基础与最核心

1）本地模式   Spark不一定非要跑在hadoop集群，可以在本地，起多个线程的方式来指定。将Spark应用以多线程的方式直接运行在本地，一般都是为了方便调试，本地模式分三类   local：只启动一个executor   local[k]:启动k个executor   lo...

Spark的任务执行流程 https://wenku.baidu.com/view/9bf37bd07f1cfad6195f312b3169a4517723e513.html Spark总体架构和运行

简单介绍一下 Flink   Flink 是一个框架和分布式处理引擎，用于对无界和有界数据流进行有状态计算。并且 Flink 提供了数据分布、容错机制以及资源管理等核心功能。Flink提供了诸多高抽

概述2019年是大数据实时计算领域最不平凡的一年，2019年1月阿里巴巴Blink（内部的Flink分支版本）开源，大数据领域一夜间从Spark独步天下走向了两强争霸的时代。Flink因为其天然的流式

有没有去面试的时候被问到Flink的面试题你答不上来，为什么那？，菜吗？ 不是。原因是你接触的面试题太少了，那我今天就根据不同的群体来给大家你分享。 好今天的Flink的题目就分享到这里，背过上面的那些题目害怕面试官提问？信自己，努力和汗水总会能得到回报的。我是大数据老哥，我们…

相信小伙伴们对于Flink一定不会感到陌生，作为连续三年蝉联第一，荣膺全球最活跃的 Apache 开源项目，Flink在中国的热度也一直是居高不下。近几年，在社区的推动下，Flink 技术栈在越来越多的公司开始得到应用，因此在大数据的求职招聘中，对于Flink的着重考察也变得越…

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

1，简单介绍一下 Flink Flink 是一个框架和分布式处理引擎，用于对无界和有界数据流进行有状态计算。并且 Flink 提供了数据分布、容错机制以及资源管理等核心功能。Flink提供了诸多高抽象

Flink中的执行图一般是可以分为四类，按照生成顺序分别为：StreamGraph-> JobGraph-> ExecutionGraph->物理执行图。顾名思义，这里代表的是我们编写的流程序图。通过Stream API生成，这是执行图的最原始拓扑数据结构。StreamGraph...

16. Flink中有哪些窗口？ Flink 支持两种划分窗口的方式，按照time和count。如果根据时间划分窗口，那么它就是一个time-window 如果根据数据划分窗口，那么它就是一个coun

1 Flink的并行度了解吗？Flink的并行度设置是怎样的？ Flink中的任务被分为多个并行任务来执行，其中每个并行的实例处理一部分数据。这些并行实例的数量被称为并行度。我们在实际生产环境中可以从

Flink如何实现端到端Exactly-Once语义？请详细阐述源端、计算端、Sink端三方协同的完整机制。这是2026年Flink面试的重中之重。

---

🤖 AI解析：
三方协同机制：①计算端——异步屏障快照(ABS)：基于Chandy-Lamport算法，JobManager发送Checkpoint Barrier，Source算子持久化状态后广播Barrier，下游算子对齐Barrier后持久化，所有Sink完成后Checkpoint完成；②源端——可重放数据源：Kafka的offset作为状态保存到Checkpoint，故障恢复时从最近Checkpoint恢复offset重放数据；③Sink端——两阶段提交(2PC)：预提交阶段收到Barrier后开启事务写入但不提交，元数据存Checkpoint；正式提交阶段Checkpoint全局完成后提交事务；回滚阶段Checkpoint失败则回滚事务。

Exactly-Once的本质：不是'数据只处理一次'，而是'重复处理不影响最终结果'——通过幂等/事务保证。

📌 关键知识点：端到端Exactly-Once=源端可重放+计算端Checkpoint+Sink端2PC，三者缺一不可；ABS算法的Barrier对齐保证快照全局一致性；2PC的预提交-正式提交-回滚三阶段
⚠️ 易错点：只讲Checkpoint不够——那只是计算端的一致性，源端和Sink端必须配合；2PC的Sink如果在预提交后、正式提交前崩溃，恢复后需能正确提交或回滚；Kafka的exactly-once需要事务型Producer

在订单支付场景中，面对峰值10万TPS的乱序数据，Watermark生成策略与乱序容忍度如何设计？迟到数据的完整处理方案是什么？

---

🤖 AI解析：
Watermark生成策略：采用固定乱序容忍度策略，Watermark=最大事件时间-容忍时长。容忍度设置：取P99延迟时长作为容忍度，保证99%数据正常处理。

迟到数据四层兜底方案：①第一层Watermark容错——设置合理容忍度，绝大多数乱序数据窗口计算前到达；②第二层允许延迟重新计算——窗口不立即销毁，继续接收迟到数据，每来一条重新触发计算更新结果；③第三层侧输出流兜底——超允许延迟的数据输出到侧输出流，不丢弃保留原始数据；④第四层离线批处理修正——凌晨用离线批处理重算前一天全量数据，修正实时计算偏差。

📌 关键知识点：Watermark本质是给乱序数据设定容错边界而非简单的'处理乱序'；四层兜底是生产环境标准方案；容忍度设太小丢数据，设太大延迟高
⚠️ 易错点：容忍度不能拍脑袋设——必须基于历史数据P99延迟；只设Watermark不设允许延迟=丢弃大量迟到数据；侧输出流的数据必须有人工处理流程否则会堆积

Flink中Slot和并行度的关系是什么？一个Slot中能运行多个Task吗？一个作业的总并行度受什么限制？这是面试中最容易踩坑的考点。

---

🤖 AI解析：
核心区别：Slot是TaskManager的静态资源配额——每个Slot对应TM的一部分内存(目前CPU不做隔离)，决定TM最多能同时运行多少个Task线程。并行度是算子的动态任务并发数——决定一个算子被拆分成多少个并行的Task执行。

关键关系：①一个Slot中可以运行多个属于同一个作业的Task线程(算子链优化后)；②一个作业的总并行度不能超过集群中可用的Slot总数；③Slot Sharing允许同一作业的不同算子的SubTask共享同一个Slot，提高资源利用率。

Operator Chain：将上下游可链接的算子合并到同一个Task中执行，避免序列化/反序列化和网络传输，大幅提升吞吐。链接条件：并行度一致+Forward分区+链化策略允许。

📌 关键知识点：Slot=静态资源配额，并行度=动态任务并发数；算子链是Flink最核心的性能优化手段；Slot Sharing提高资源利用率避免浪费
⚠️ 易错点：Slot≠并行度——一个Slot可运行多个Task(算子链)；并行度超过Slot总数会资源不足导致任务无法调度；断开算子链(disableChaining)需谨慎——只在性能瓶颈需单独监控时才断

Spark Structured Streaming的流表二元性是什么？如何实现流-流Join、流-批Join和流-维表Join？各自的适用场景和限制是什么？

---

🤖 AI解析：
流表二元性：无界流数据=持续增长的动态表，每条新数据=对表的一次INSERT，用统一SQL实现批处理与流处理。持续查询：引擎监听新数据到达，每次数据变更触发查询重新计算。

三种流式Join：①流-流Join：必须基于事件时间+Watermark限定Join时间范围避免状态膨胀(如下单+支付限定30分钟内)；②流-批Join：实时数据流与离线维度表关联，实现维度补全，支持静态批表定时刷新；③流-维表Join(Lookup Join)：实时查询外部存储的维表，支持缓存+异步IO提升性能。

Trigger策略：微批处理(默认，吞吐高)、连续处理(毫秒延迟但仅支持简单算子)、一次性处理(增量批处理)。

📌 关键知识点：流表二元性是Structured Streaming的核心创新——批流SQL统一；流-流Join必须限定时间范围否则状态无限膨胀；Lookup Join+异步IO是大维表关联的最佳实践
⚠️ 易错点：Structured Streaming的Watermark只能单调递增不支持回退，对迟到数据处理能力弱于Flink；连续处理模式不支持聚合/Join等复杂操作；流-流Join的时间范围设置过大会导致状态膨胀OOM

Flink CDC如何实现全量+增量一体化数据同步？与Canal/Debezium相比有什么核心优势？无锁全量读取的原理是什么？

---

🤖 AI解析：
Flink CDC原理：底层基于Debezium，分两阶段——①全量同步阶段：对DB表无锁读取，全量同步历史数据同时记录当前日志位点，不锁表不影响线上；②增量同步阶段：全量完成后自动切换，持续监听增量日志(Binlog/WAL)捕获增删改。

核心优势：①全量+增量一体化无需额外中间件；②无锁全量读取不影响线上DB；③直接接入Flink SQL支持实时清洗转换关联；④支持Exactly-Once保证数据不丢不重；⑤支持多库多表同步和分库分表合并。

无锁读取原理：基于MVCC快照读——在REPEATABLE READ隔离级别下做一致性快照读，保证全量读取期间看到的数据是一致性的，同时Binlog位点记录保证增量衔接不丢数据。

📌 关键知识点：Flink CDC=无锁全量+增量一体化，是实时数仓数据接入的标准方案；无锁读取基于MVCC快照读实现；与Canal相比省了中间件简化架构
⚠️ 易错点：无锁读取不是'没有锁'——依赖数据库的MVCC机制，需确认DB支持REPEATABLE READ；全量同步大表耗时较长期间增量数据会堆积在Binlog中需关注磁盘空间；CDC不支持DDL变更自动同步需手动处理

Spark Streaming(DStream)和Structured Streaming有什么核心差异？为什么行业内全面转向Structured Streaming？Receiver模式与Direct模式的区别是什么？

---

🤖 AI解析：
核心差异：①编程模型：DStream=RDD序列(底层RDD操作)，Structured Streaming=DataFrame/DataSet(基于Catalyst优化器)；②执行模型：DStream仅微批，Structured Streaming支持微批+连续处理+一次性处理；③流批统一：DStream无法与批处理共享代码，Structured Streaming的SQL批流统一；④优化器：DStream无优化器，Structured Streaming有Catalyst+Tungsten。

Receiver vs Direct模式：Receiver=高阶消费者API+Receiver线程+WAL(At-least-once，单点瓶颈)；Direct=低阶消费者API直接读Kafka分区(Exactly-once，并行度与分区数对应)。

行业趋势：Structured Streaming已成主流，DStream仅存量项目使用。

📌 关键知识点：Structured Streaming的核心优势=Catalyst优化器+流批统一SQL；Direct模式全面替代Receiver模式；流表二元性是Structed Streaming的理论基础
⚠️ 易错点：不要说DStream已废弃——仍有大量存量项目在运行面试会问；连续处理模式虽然延迟低但支持的算子极其有限不能当万能方案；Receiver模式的WAL机制有性能开销且不能保证Exactly-Once

Spark性能调优不能零散调参数，请给出系统化的调优方法论，包括资源调优、数据倾斜调优、内存调优、算子调优和存储调优五大维度。

---

🤖 AI解析：
五大维度系统调优：①资源调优——Executor内存/堆外内存比例、CPU核数(2-5个)、并行度(2-3倍CPU核数)、动态资源分配；②数据倾斜调优——reduceByKey替代groupByKey、Salting加盐打散、两阶段聚合、Broadcast Join小表、AQE自动优化(Spark3.0+)；③内存调优——堆内存/堆外内存合理分配(spark.memory.fraction=0.6)、Kryo序列化替代Java序列化(10倍压缩)、persist(StorageLevel.MEMORY_ONLY_SER)；④算子调优——mapPartitions替代map(减少GC)、coalesce替代repartition(减少Shuffle)、filter后repartition(避免数据倾斜)；⑤存储调优——列式存储Parquet/ORC、合理分区和分桶、数据压缩snappy/lz4。

AQE关键配置：spark.sql.adaptive.enabled=true、spark.sql.adaptive.shuffle.targetPostShuffleInputSize=64MB、spark.sql.adaptive.skewJoin.enabled=true。

📌 关键知识点：调优不是调参数而是系统化定位瓶颈；AQE是Spark3.0自动优化的利器；资源调优是第一步，数据倾斜调优是重点
⚠️ 易错点：不要一上来就加Executor——先看是不是数据倾斜导致少数Task慢；coalesce只能减分区不能增(会丢数据)；Kryo需要注册类否则性能提升有限

Flink支持Session/Per-Job/Application/Serverless四种部署模式，对比它们的核心特点、资源隔离性和适用场景。云原生场景下如何选择？

---

🤖 AI解析：
四种模式对比：①Session模式——集群常驻，所有作业共享资源(低隔离性，适合测试/短作业)；②Per-Job模式——每个作业独立集群，完成后销毁(高隔离性，但启动慢，已被Application模式替代)；③Application模式——每个应用对应一个集群，main()在JobManager执行(高隔离性，目前主流)；④Serverless模式——按需付费，自动弹性扩缩容(极高隔离性，适合峰谷波动大的云原生场景)。

云原生选择：生产环境→Application模式(资源隔离+启动较快)；云原生/K8s→Application+Serverless混合(常态用Application，峰值用Serverless弹性扩容)。

K8s部署关键：Operator管理Flink集群生命周期、Pod模板自定义资源配置、Ingress暴露WebUI/REST接口。

📌 关键知识点：Application模式是当前主流生产部署方式；Serverless模式是云原生趋势但成本需管控；Per-Job已被Application模式替代但面试仍会问
⚠️ 易错点：Session模式不能用于生产——作业间会互相影响(OOM/资源争抢)；Per-Job模式虽然隔离好但启动慢+资源浪费；Serverless模式冷启动延迟需预热处理

Flink三种状态后端(Memory/FsState/RocksDB)的对比与选型？RocksDB的核心优势是什么？如何优化RocksDB在大状态场景下的性能？

---

🤖 AI解析：
三种后端对比：①MemoryStateBackend——状态在TM堆内存，Checkpoint在JM堆内存(极高性能，极低可靠性，仅本地测试)；②FsStateBackend——状态在TM堆内存，Checkpoint持久化到HDFS/S3(高性能+高可靠，适合小状态生产作业)；③RocksDBStateBackend——状态在本地磁盘RocksDB，Checkpoint持久化到HDFS/S3+支持增量Checkpoint(中性能+极高可靠性，支持TB级大状态)。

RocksDB核心优势：①不受TM堆内存限制，支持TB级大状态；②增量Checkpoint只持久化差异，大幅降低IO开销；③LSM-Tree结构写入性能优异。

优化策略：①开启增量Checkpoint(checkpointing.incremental=true)；②调整RocksDB的block cache和write buffer大小；③使用Bloom Filter加速点查；④定期Compaction减少读放大；⑤状态TTL自动清理过期数据。

📌 关键知识点：RocksDB是唯一支持大状态的状态后端；增量Checkpoint是大状态场景的必备优化；状态TTL避免状态无限膨胀
⚠️ 易错点：FsStateBackend状态在堆内存——大状态会OOM，生产环境超过几GB就必须用RocksDB；RocksDB的读写经过磁盘IO，性能低于堆内存但远好于OOM崩溃；增量Checkpoint不是万能的——首次Checkpoint仍是全量

生产环境Flink实时ETL任务出现延迟，下游Kafka消费lag持续上涨，如何系统化诊断和解决背压问题？面试高频场景题。

---

🤖 AI解析：
诊断四步法：①Flink Web UI看BackPressure指标(红色=高反压，绿色=正常)；②看TaskManager日志是否有buffer耗尽/内存不足；③分析哪个算子是瓶颈——通常是聚合/Join/外部IO；④看数据流量是否有突增(业务峰值)。

解决六方案：①增大并行度分散负载(最直接)；②优化算子逻辑——预过滤减少数据量、减少状态访问；③调整网络buffer配置(taskmanager.network.memory)；④异步IO替代同步查询——Lookup Join用async=TRUE；⑤分区重平衡(rebalance/rescale)解决数据分布不均；⑥外部系统瓶颈——DB加索引/Kafka增加分区。

背压本质：自稳机制——下游慢时自动减缓上游速率防止崩溃，但持续反压意味着性能瓶颈需人工干预。

📌 关键知识点：背压是自稳机制不是bug——但持续反压=性能瓶颈需定位；Kafka lag是反压的外在信号；先定位瓶颈算子再对症下药
⚠️ 易错点：背压≠数据丢失——Flink的Checkpoint保证一致性；单纯增大并行度不一定有效——可能是下游DB扛不住；异步IO需注意超时和重试策略否则会引入新问题

什么是向量数据库？RAG架构如何设计？如何优化RAG的检索效果？这是2026年大数据面试新增的热门考点，AI+数据融合方向。

---

🤖 AI解析：
向量数据库：专门存储和查询向量数据的数据库，核心能力是相似性搜索——在海量向量中快速找到与查询向量最相似的K个。核心技术：①向量索引(IVF/HNSW/Annoy)；②向量压缩(PQ/SQ)；③分布式存储(水平扩展)；④混合查询(向量+标量)。

RAG架构设计：①文档处理→将文档分割成小块(512-1024 token)；②向量生成→嵌入模型将文档块转为向量；③向量存储→存入向量数据库(Milvus/Chroma)；④检索→用户查询→嵌入→相似性搜索→TopK文档块；⑤生成→文档块+查询→LLM生成回答。

优化策略：文档分割策略(按语义段落而非固定长度)、检索策略(Hybrid Search=向量+关键词)、重排序(Cross-encoder精排)、Chunk overlap(块间重叠避免信息截断)。

📌 关键知识点：向量数据库的核心是相似性搜索而非精确匹配；RAG是解决大模型幻觉和知识更新的最有效方法；HNSW索引是当前性能最好的向量索引算法
⚠️ 易错点：文档分割不能简单按字数切——会切断语义上下文；纯向量检索不够——需结合关键词检索(Hybrid Search)；嵌入模型的选择直接影响检索质量，需针对业务场景微调

请对比Lambda架构、Kappa架构和流批一体架构的优缺点、适用场景。为什么流批一体是终极形态？Flink+Paimon如何实现流批一体？

---

🤖 AI解析：
三大架构对比：①Lambda架构——批处理层(准确性)+实时层(低延迟)，需维护两套代码，逻辑不一致，开发运维成本高，适合对准确性要求极高的金融场景；②Kappa架构——'流是批的超集'，一套代码处理批和流，简化架构，但历史数据重放需重算整个Kafka，适合实时性优先的场景；③流批一体——Kappa的进一步发展，不仅代码统一，存储层也统一(Flink+Paimon)，是终极形态。

Flink+Paimon实现：Flink提供流批统一计算引擎(同一SQL处理流和批)，Paimon提供流批统一存储(LSM-Tree支持秒级实时写入+高效批量查询)，ACID事务保证流批数据一致性。

选择建议：新项目一律流批一体；存量Lambda架构逐步迁移；金融等对准确性要求极高的场景可保留Lambda。

📌 关键知识点：Lambda最大问题=两套代码逻辑不一致；Kappa最大问题=历史数据重放成本高；流批一体=Flink+Paimon代码+存储双统一；不是所有场景都要流批一体
⚠️ 易错点：流批一体不是万能药——某些场景Lambda更合适(如金融对准确性要求极高)；Kappa架构重放历史数据时Kafka存储成本很高；流批一体的Paimon目前生态不如Iceberg成熟

如何设计一个大模型数据管道？大模型数据处理与传统数据处理有什么不同？数据清洗去重的最佳实践是什么？2026年新增AI+数据融合考点。

---

🤖 AI解析：
大模型数据管道五层架构：①数据接入层——支持多种数据源(Web爬虫/API/数据库/文档)；②数据处理层——Spark/Flink分布式处理(TB/PB级)；③数据存储层——对象存储存原始+处理后数据；④数据标注层——标注工具和平台(人工+AI辅助标注)；⑤数据服务层——为大模型训练提供数据服务(分批加载+断点续训)。

与传统的差异：①数据量巨大(TB-PB级)；②数据类型多(文本/图片/音视频)；③质量要求高(低质量数据直接降低模型能力)；④标注需求大(监督微调需大量标注)。

清洗去重最佳实践：MinHash+LSH近似去重(千万级文档)、规则过滤(长度/语言/质量分数)、Perplexity过滤(用小模型打分筛低质量)、数据增强(同义词替换/回译)。

📌 关键知识点：大模型数据管道的核心挑战是数据质量而非数据量；MinHash+LSH是大规模去重的标准方案；Perplexity过滤是筛低质量数据的有效方法
⚠️ 易错点：不要用精确去重——PB级数据精确去重不可行，必须用近似去重；数据增强不能过度——过度增强会导致模型过拟合增强模式而非学真实分布；标注数据质量比数量更重要

如何设计一个完整的数据质量监控体系？数据质量的五个维度是什么？如何实现自动化数据质量检查？数据契约如何与数据质量监控结合？

---

🤖 AI解析：
五维质量体系：①准确性(数据正确反映现实)、②完整性(数据无缺失)、③一致性(跨系统数据一致)、④及时性(数据及时提供)、⑤唯一性(数据无重复)。

监控体系设计：①接入层——数据格式/Schema校验、源端数据量波动监控；②处理层——ETL任务成功率/延迟监控、中间表行数/空值率/枚举值校验；③服务层——指标异常检测(3σ/Isolation Forest)、数据血缘追踪。

自动化检查：Great Expectations/Deequ框架写检查规则→CI/CD集成→异常告警→自动修复(重跑/回填)→数据契约校验(源端Schema/SLA是否符合契约)。

从事后到事前：数据契约=事前约束(定义+检查)，监控体系=事中发现(检测+告警)，两者结合才能实现全链路数据质量保障。

📌 关键知识点：数据质量不是单一维度而是五维体系；自动化检查框架(Great Expectations/Deequ)是工程化基础；数据契约是事前预防，监控是事中发现，两者互补
⚠️ 易错点：只有监控没有修复=无效——告警了没人处理等于没监控；数据质量指标体系不是越多越好——聚焦核心字段和核心表；数据血缘是根因分析的基础，没有血缘监控就是空中楼阁

1. 如何从大量的 URL 中找出相同的 URL？ 给定 a、b 两个文件，各存放 50 亿个 URL，每个 URL 各占 64B，内存限制是 4G。请找出 a、b 两个文件共同的 URL。 每个 URL 占 64B，那么 50 亿个 URL占用的空间大小约为 320GB。 由…

一千个读者眼中有一千个哈姆雷特，一千名 大数据 程序员心目中就有一千套 大数据面试题。本文就是笔者认为可以用来面试大数据 程序员的面试题。 这套题的题目跟公司和业务都没有关系，而且也并不代表笔者本人可以把这些题回答得非常好，笔者只是将一部分觉得比较好的题从收集的面试题里面抽出来…

1、集群的最主要瓶颈 磁盘IO 2、Hadoop运行模式 单机版、伪分布式模式、完全分布式模式 3、HDFS写流程 1）client 客户端发送上传请求，通过 RPC 与 namenode 建立通信，

大数据工程师是近几年异常火爆的职位，市场需求旺盛，众多互联网公司都打出了高薪招聘的广告，本文整理了网络上部分技术人员分享的各大互联网公司大数据类(Hadoop、Spark等)面试题以及面试时需要注意的一些问题，希望对各位技术人员有所帮助。 分享之前我还是要推荐下我自己创建的大数…

前言 随着 5G 时代的到来，大数据人工智能产业链又一次迎来了井喷式的爆发，随着岗位需求的不断增加，越来越多的人选择大数据课程，但是没有真正从事大数据工作的人面对企业面试有种无从下手的感觉，面对面试说

「Offer 驾到，掘友接招！我正在参与2022春招系列活动-经验复盘，点击查看 活动详情 题目来源 作者：是锅粥 链接：https://www.nowcoder.com/discuss/745950

1、HAnamenode 是如何工作的? ZKFailoverController主要职责 1）健康监测：周期性的向它监控的NN发送健康探测命令，从而来确定某个NameNode是否处于健康状态，如果机

本文整理了互联网大厂数据开发、数据分析、数仓等数据相关岗位面试过程中经常出现的SQL面试题，并给出了参考答案。涉及了炸裂函数、开窗函数、聚合函数开窗、在线直播人数等 以及这两年各大厂面疯了各种连续问题

1. hadoop 架构 Hadoop2.0版本，引入了Yarn。核心：HDFS+Yarn+Mapreduce Yarn是资源调度框架。能够细粒度的管理和调度任务。此外，还能够支持其他的计算框架，比如spark等。 Namenode：也叫名称节点，是HDFS的守护程序（一个核心…

六、描述HBase 中scan 和get 的功能以及实现的异同？七、hbase如何导入数据？八、hbase 的存储结构？九、解释下 hbase 实时查询的原理十、详细描述 HBase 中一个 cell 的结构？十一、简述 HBase 中 compact 用途是什么，什么时候触发，...

1. 通常来说，Spark与MapReduce相比，Spark运行效率更高。请说明效率更高来源于Spark内置的哪些机制？ spark是借鉴了Mapreduce,并在其基础上发展起来的，继承了其分布式

1、Flink怎么做压力测试和监控？ 参考答案：我们一般碰到的压力来自以下几个方面： （1）产生数据流的速度如果过快，而下游的算子消费不过来的话，会产生背压。背压的监控可以使用FlinkWebUI(l

Redis熟不熟，介绍下它有几种数据类型？我回答了8种，面试官说只有5种，后来在网上搜了搜，版本也很多。 手撕代码第一道是力扣原题：169. 多数元素 手撕代码第二道如何实现最小栈（也是力扣原题155. 最小栈），可能时间有限，没有让手写，说一下思路。 自我介绍之后，就全程几乎…

local 本地，通常是测试的时候用。 standalone，Spark 自己模拟作为一个调度系统，任务提交给 Master。 SparkonYarn 交给Yarn来进行资源调度，有 yarn-clu

​ 目录 HDFS文件写入和读取流程 HDFS组成架构 介绍下HDFS，说下HDFS优缺点，以及使用场景 HDFS作用 HDFS的容错机制 HDFS的存储机制 HDFS的副本机制 HDFS的常见数据格

什么是数据湖 数据湖（Data Lake）是一个大型数据存储和处理系统， 它能够存储各种类型和格式的数据，包括结构化数据、半结构化数据和非结构化数据。以下是关于数据湖的详细解释： 定义与特点 数据存储

​ 1、介绍下YARN 2、YARN有几个模块 3、YARN工作机制 4、YARN有什么优势，能解决什么问题? 5、YARN容错机制 6、YARN高可用 7、YARN调度器 8、YARN中Contai

分享大数据常见的面试题 一、mr的shuffle流程 说到mr的Shuffle，那么首先要明确shuffle属于哪个阶段。shuffle就是从Map端输出到Reduce输入的整个过程，这个过程广义上称

介绍下Flume  Flume架构  Flume有哪些Source  说下Flume事务机制  介绍下Flume采集数据的原理？底层实现？  Flume如何保证数据的可靠性  Flume传输数据时如何

介绍一下Mysql和Hivesql的区别？ 一方面，可以从底层原理出发回答，例如： 查询语言不同： Hive是hql语言，Mysql是sql语句； 存储位置不同： Hive是建立在 Hadoop 之上

Spark解决什么问题 二 Spark为什么会有自己的资源调度器 三 Spark运行模式 四 Spark常用端口号 五 Spark提交作业参数 六 Spark的transformation算子

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

Spark是一个围绕速度、易用性和复杂分析构建的大数据处理框架，Spark提供了一个全面、统一的框架用于管理各种有着不同性质(文本数据、图表数据等)的数据集和数据源(批量数据或实时的流数据)的大数据处理的需求。成为大数据核心技术之一，自然也成为了众多企业面试的核心专业问题，小编…

Spark系列面试题 Spark面试题（一） Spark面试题（二） Spark面试题（三） Spark面试题（四） Spark面试题（五）——数据倾斜调优 Spark面试题（六）——Spark资源调

微信搜索公众号：知了小巷公众号后台回复“资料”两个字，有大数据神秘学习大礼包！1.Spark的几种部署模式及其特点SparkSubmit#prepareSubmitEnvironment本地模式Spa

## Spark系列面试题 - [Spark面试题（一）](https://www.ikeguang.com/?p=1922) - [Spark面试题（二）](https://www.ikeguang

Spark是一种由Scala语言开发的快速、通用、可扩展的大数据分析引擎。Spark Core中提供了Spark最基础与最核心

1）本地模式   Spark不一定非要跑在hadoop集群，可以在本地，起多个线程的方式来指定。将Spark应用以多线程的方式直接运行在本地，一般都是为了方便调试，本地模式分三类   local：只启动一个executor   local[k]:启动k个executor   lo...

Spark的任务执行流程 https://wenku.baidu.com/view/9bf37bd07f1cfad6195f312b3169a4517723e513.html Spark总体架构和运行

简单介绍一下 Flink   Flink 是一个框架和分布式处理引擎，用于对无界和有界数据流进行有状态计算。并且 Flink 提供了数据分布、容错机制以及资源管理等核心功能。Flink提供了诸多高抽

概述2019年是大数据实时计算领域最不平凡的一年，2019年1月阿里巴巴Blink（内部的Flink分支版本）开源，大数据领域一夜间从Spark独步天下走向了两强争霸的时代。Flink因为其天然的流式

有没有去面试的时候被问到Flink的面试题你答不上来，为什么那？，菜吗？ 不是。原因是你接触的面试题太少了，那我今天就根据不同的群体来给大家你分享。 好今天的Flink的题目就分享到这里，背过上面的那些题目害怕面试官提问？信自己，努力和汗水总会能得到回报的。我是大数据老哥，我们…

相信小伙伴们对于Flink一定不会感到陌生，作为连续三年蝉联第一，荣膺全球最活跃的 Apache 开源项目，Flink在中国的热度也一直是居高不下。近几年，在社区的推动下，Flink 技术栈在越来越多的公司开始得到应用，因此在大数据的求职招聘中，对于Flink的着重考察也变得越…

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

1，简单介绍一下 Flink Flink 是一个框架和分布式处理引擎，用于对无界和有界数据流进行有状态计算。并且 Flink 提供了数据分布、容错机制以及资源管理等核心功能。Flink提供了诸多高抽象

Flink中的执行图一般是可以分为四类，按照生成顺序分别为：StreamGraph-> JobGraph-> ExecutionGraph->物理执行图。顾名思义，这里代表的是我们编写的流程序图。通过Stream API生成，这是执行图的最原始拓扑数据结构。StreamGraph...

16. Flink中有哪些窗口？ Flink 支持两种划分窗口的方式，按照time和count。如果根据时间划分窗口，那么它就是一个time-window 如果根据数据划分窗口，那么它就是一个coun

1 Flink的并行度了解吗？Flink的并行度设置是怎样的？ Flink中的任务被分为多个并行任务来执行，其中每个并行的实例处理一部分数据。这些并行实例的数量被称为并行度。我们在实际生产环境中可以从

窄依赖：一个父RDD分区对应一个子RDD分区（如map,filter），或多个父RDD分区对应一个子RDD分区（如co-partitioned join）。
宽依赖：一个父RDD分区对应非全部子RDD分区（如groupByKey,reduceByKey），或一个父RDD分区对应全部子RDD分区（如未经协同划分的join）。

---

🤖 AI解析：
窄依赖：父RDD的每个分区最多被子RDD的一个分区使用（如map、filter、union）。
宽依赖：父RDD的每个分区被子RDD的多个分区使用，需要Shuffle（如groupByKey、reduceByKey、join）。
区分意义：窄依赖可以在一个Stage内流水线执行；宽依赖是Stage划分的边界，需要Shuffle。

📌 关键知识点：窄依赖=父子分区1:1或N:1、宽依赖=父子分区1:N、Stage划分依据
⚠️ 易错点：co-partitioned join是窄依赖（特殊情况）；未协同划分的join是宽依赖

讲解Spark Shuffle原理和特性？Shuffle write和Shuffle read过程做些什么？
Spark Shuffle经历了HashShuffle、SortShuffle的演进，目前默认使用SortShuffleManager。

---

🤖 AI解析：
Shuffle Write阶段：Map任务将数据按分区规则写入磁盘，每个Reduce分区对应一个数据文件。
Shuffle Read阶段：Reduce任务从Map端拉取属于自己分区的数据。
演进：HashShuffle（产生大量小文件）→ SortShuffle（排序后索引，减少文件数）→ Tungsten Sort（堆外内存序列化）。
优化：SortShuffle在满足条件时使用Bypass机制直接写不排序。

📌 关键知识点：Shuffle Write/Read两阶段、SortShuffleManager、Bypass机制、Tungsten优化
⚠️ 易错点：HashShuffle有未优化和优化版区别；Bypass触发条件是分区数<=200且无map端聚合

从HDFS中读取文件后创建RDD对象，DAGScheduler计算RDD之间的依赖关系形成DAG。
划分Stage的主要依据是当前计算因子的输入是否确定。整体思路：从后往前推，遇到宽依赖就断开划分为一个Stage；遇到窄依赖就将该RDD加入该Stage中。

---

🤖 AI解析：
Stage划分由DAGScheduler完成：从最后一个RDD开始向前遍历，遇到宽依赖（ShuffleDependency）就断开，生成新的Stage；窄依赖则合并到同一个Stage中。
ResultStage对应action算子，ShuffleMapStage对应shuffle依赖。
Stage内部任务可流水线执行，Stage之间需要Shuffle传输数据。

📌 关键知识点：从后往前遍历、宽依赖断开、窄依赖合并、DAGScheduler
⚠️ 易错点：Stage数量=宽依赖数量+1；一个Job至少一个Stage

RDD弹性体现在：自动进行内存和磁盘切换、基于lineage的高效容错、task失败会特定次数重试、
stage失败会自动重试且只计算失败分片、checkpoint和persist机制、数据调度弹性、数据分片的高度弹性（repartition）。
缺陷：惰性计算导致中间数据默认不保存，每次动作操作都会重复计算。

---

🤖 AI解析：
弹性体现在7个方面：
1. 自动内存/磁盘切换
2. 基于lineage的高效容错（不需完整复制）
3. Task失败自动重试
4. Stage失败自动重试（只算失败分片）
5. Checkpoint和Persist
6. 数据调度弹性（DAG/Task与资源管理无关）
7. 数据分片高度弹性（repartition）
缺陷：惰性计算导致中间数据默认不保存，重复计算开销大。

📌 关键知识点：Lineage血统容错、Checkpoint vs Persist、Task/Stage重试机制
⚠️ 易错点：Persist的MEMORY_ONLY在内存不足时直接丢弃分区（不溢写到磁盘），需用MEMORY_AND_DISK

reduceByKey性能更高，更适合大数据集。reduceByKey会在map端进行预聚合（combine），减少shuffle数据量；
groupByKey不会预聚合，所有数据直接shuffle到reduce端，导致网络IO和内存压力大。

---

🤖 AI解析：
reduceByKey性能更高。原因：reduceByKey在Shuffle前会在Map端进行预聚合(combine)，相同Key的数据先局部合并，大幅减少Shuffle数据量。
groupByKey不做Map端预聚合，所有数据直接Shuffle到Reduce端，网络IO和内存压力都更大。
在大数据集上，reduceByKey可以减少80%+的Shuffle数据量。

📌 关键知识点：Map端combine预聚合、Shuffle数据量差异、网络IO优化
⚠️ 易错点：groupByKey后紧跟reduce不算优化，必须用reduceByKey才能触发combine

Hive表关联查询时如何解决数据倾斜？倾斜原因：key分布不均匀、业务数据本身特性、建表时考虑不周、某些SQL语句本身就有数据倾斜。
解决方案：(1)参数调节：hive.map.aggr=true, hive.groupby.skewindata=true (2)SQL语句调节：选用join key分布最均匀的表作为驱动表；大小表Join使用map join；大表Join大表把空值key加随机数分散；count distinct大量相同特殊值时单独处理空值。

---

🤖 AI解析：
参数调节方案：
1. hive.map.aggr=true 开启Map端聚合
2. hive.groupby.skewindata=true 开启倾斜负载均衡（两个MR Job，第一个随机分布，第二个正确聚合）
SQL优化方案：
1. 大小表Join → Map Join（小表进内存）
2. 大表Join大表 → 空key加随机数分散 + 过滤异常key
3. Count Distinct → 先Group By再Count替换
4. 选用join key分布均匀的表做驱动表

📌 关键知识点：skewindata两阶段聚合、Map Join、空key随机化、count distinct优化
⚠️ 易错点：Map Join适合小表<25MB的场景；空key加随机数后JOIN结果需过滤掉空key的虚假关联

HiveSQL -> AST(抽象语法树) -> QB(查询块) -> OperatorTree(操作树) -> 优化后的操作树 -> MapReduce任务树 -> 优化后的MapReduce任务树。
SQL Parser用Antlr完成词法语法解析转AST；Semantic Analyzer遍历AST抽象出QueryBlock；Logical plan翻译为OperatorTree；优化器变换减少shuffle；Physical plan翻译为MapReduce任务。

---

🤖 AI解析：
完整转换链路：HiveSQL → AST(抽象语法树) → QB(查询块) → OperatorTree(操作树) → 优化后操作树 → MR任务树 → 优化后MR任务树。
1. SQL Parser: Antlr词法语法解析 → AST
2. Semantic Analyzer: 遍历AST → QueryBlock
3. Logical plan: 翻译 → OperatorTree
4. Logical optimizer: 合并ReduceSinkOperator减少shuffle
5. Physical plan: 翻译 → MR任务
6. Physical optimizer: 生成最终执行计划

📌 关键知识点：Antlr解析、AST→QB→OperatorTree→MR、逻辑优化vs物理优化
⚠️ 易错点：不是所有SQL都走MR（Fetch抓取优化）；Tez/Spark引擎走不同执行计划

创建内部表时，会将数据移动到数据仓库指向的路径；创建外部表仅记录数据所在路径，不移动数据。
删除表时，内部表的元数据和数据一起删除，外部表只删除元数据不删除数据。外部表更安全，数据组织更灵活，方便共享源数据。

---

🤖 AI解析：
创建时：内部表将数据移动到仓库路径（/user/hive/warehouse）；外部表只记录数据路径不移动。
删除时：内部表删除元数据+数据；外部表只删除元数据，数据保留。
外部表优势：更安全（误删表不丢数据）、灵活（数据可被多个表共享）、适合与其他系统共享数据。
生产建议：ODS层用外部表（原始数据不丢失），DWD/DWS层用内部表。

📌 关键知识点：数据移动vs路径记录、删除行为差异、生产分层建议
⚠️ 易错点：外部表LOCATION指定路径后DROP TABLE不会删数据，但数据可能被其他系统依赖

order by：全局排序，只有一个reducer，大规模数据时耗时。
sort by：非全局排序，数据进入reducer前完成排序。
distribute by：按指定字段将数据划分到不同reduce中。
cluster by：兼具distribute by和sort by的功能。

---

🤖 AI解析：
ORDER BY：全局排序，单个Reducer，保证全局有序但性能差（大数据集OOM风险）。
SORT BY：局部排序，每个Reducer内部有序，全局不保证有序。
DISTRIBUTE BY：按字段Hash分配到不同Reducer，控制数据分发。
CLUSTER BY = DISTRIBUTE BY + SORT BY（同一字段），即按某字段分发并排序。
注意：CLUSTER BY不能指定ASC/DESC，需用DISTRIBUTE BY + SORT BY替代。

📌 关键知识点：全局vs局部排序、分发控制、CLUSTER BY限制
⚠️ 易错点：ORDER BY只有一个Reducer，大数据集需加LIMIT；CLUSTER BY不能排序方向

TextFile：默认格式，行存储，不压缩，磁盘开销大，不支持split。
SequenceFile：二进制行存储，可分割可压缩，支持NONE/RECORD/BLOCK压缩。
RCFile：数据按行分块每块按列存储，结合行列存储优点，压缩比和查询响应较好。
ORCFile：RCFile改良版，按行分块按列存储，压缩快、快速列存取、效率比RCFile更高。

---

🤖 AI解析：
TextFile：默认行存储，不压缩，可读性强但性能最差，配合Gzip后不支持split。
SequenceFile：二进制行存储，可split可压缩，支持NONE/RECORD/BLOCK压缩。
RCFile：行列混合存储（按行分块、块内按列），压缩比和查询性能较好。
ORCFile：RCFile改良版，行列存储+轻量级索引+高效压缩，Hive推荐格式。
性能排序：ORCFile > RCFile > SequenceFile > TextFile
压缩比：ORCFile可达70%+压缩率

📌 关键知识点：行存储vs列存储、ORC索引和压缩、split支持
⚠️ 易错点：TextFile+Gzip不支持split是常见考点；ORCFile的stripe结构需了解

Flink的Checkpoint机制是容错核心，基于Chandy-Lamport算法的分布式快照。
JobManager定期发送Checkpoint Barrier到Source，Barrier随数据流流动，当所有算子都收到Barrier后完成一次快照。
状态后端将快照持久化到HDFS或RocksDB，故障时从最近完成的Checkpoint恢复。

---

🤖 AI解析：
基于Chandy-Lamport分布式快照算法：
1. JobManager定期向Source注入Checkpoint Barrier
2. Barrier随数据流向下游流动，将数据流切分为当前快照和下一次快照
3. 算子收到所有输入的Barrier后，将当前状态持久化到State Backend
4. 所有算子完成快照后，JobManager确认Checkpoint完成
5. 故障时从最近成功的Checkpoint恢复状态
状态后端：MemoryStateBackend（测试）、FsStateBackend（HDFS）、RocksDBStateBackend（大状态）

📌 关键知识点：Chandy-Lamport算法、Barrier注入与流动、State Backend选型、对齐vs非对齐
⚠️ 易错点：对齐Barrier可能导致反压；非对齐Checkpoint（Flink 1.11+）牺牲精确性换低延迟；RocksDB状态后端支持增量Checkpoint

Watermark是Flink处理事件时间乱序数据的机制。Watermark = 最大事件时间 - 允许迟到时间。
当Watermark超过窗口结束时间时，触发窗口计算。Watermark允许在一定范围内处理迟到数据。
如果数据迟到超过Watermark允许范围，可通过sideOutput将迟到数据收集到侧输出流。

---

🤖 AI解析：
Watermark是事件时间的进度指示器：
Watermark = 当前最大事件时间 - 允许迟到时间(maxOutOfOrderness)
作用：当Watermark超过窗口结束时间时触发窗口计算。
迟到数据处理：
1. 在允许范围内 → 正常处理
2. 超过Watermark但窗口未清理 → 可用allowedLateness设置允许延迟
3. 完全迟到 → sideOutput收集到侧输出流
生成方式：周期性(Periodic)和标点(Punctuated)

📌 关键知识点：事件时间vs处理时间、Watermark计算、窗口触发、迟到数据处理
⚠️ 易错点：Watermark不是全局单调递增的；多分区Watermark取最小值（木桶效应）

Keyed State：与Key绑定的状态，只能在KeyedStream上使用，每个Key有独立的状态副本。
包括ValueState、ListState、MapState、ReducingState、AggregatingState。
Operator State：与算子并行度绑定的状态，如Kafka Source的offset。支持ListState和UnionListState。

---

🤖 AI解析：
Keyed State：与Key绑定，每个Key独立状态副本，只能在KeyedStream使用。
类型：ValueState(单值)、ListState(列表)、MapState(映射)、ReducingState(聚合)、AggregatingState(聚合带输出)
Operator State：与算子并行度绑定，如Kafka Source的offset。
类型：ListState(均匀分布)、UnionListState(全量广播)
状态TTL：可设置过期时间自动清理，避免状态无限增长。

📌 关键知识点：Keyed State五种类型、Operator State两种分布方式、状态TTL
⚠️ 易错点：Operator State的UnionListState恢复时每个并行度都拿到全量数据需手动选择；ValueState需先调用update再value

Flink通过Checkpoint + 两阶段提交(2PC)实现端到端Exactly-Once。
内部：Checkpoint Barrier对齐保证状态一致性。
Sink端：开启两阶段提交，预提交(Pre-commit)成功后正式提交(Commit)，任一阶段失败则回滚。
Kafka Sink配合事务机制实现端到端Exactly-Once。

---

🤖 AI解析：
内部Exactly-Once：Checkpoint Barrier对齐保证算子状态一致性。
端到端Exactly-Once需要：
1. Source可重放（如Kafka offset可回退）
2. Checkpoint持久化状态
3. Sink两阶段提交(2PC)：
   - 预提交(Pre-commit)：Checkpoint完成时，Sink开启事务写入但不提交
   - 正式提交(Commit)：所有算子Checkpoint成功后提交事务
   - 回滚(Abort)：任一算子失败则回滚事务
Kafka 0.11+的事务特性支持Flink端到端Exactly-Once。

📌 关键知识点：两阶段提交、Kafka事务、Checkpoint与2PC配合
⚠️ 易错点：2PC在Sink端实现需实现TwoPhaseCommitSinkFunction；事务超时需合理配置

Flink是真正的流处理引擎，逐条处理；Spark Streaming是微批处理，按批次间隔处理。
一致性：Flink通过Checkpoint天然支持Exactly-once；Spark Streaming实现Exactly-once需额外配置。
乱序处理：Flink通过Watermark机制；Spark Streaming窗口基于处理时间。
延迟：Flink毫秒级；Spark Streaming秒级（取决于batch interval）。

---

🤖 AI解析：
处理模型：Flink是真正的流处理（逐条处理）；Spark Streaming是微批处理（DStream=RDD序列）。
延迟：Flink毫秒级；Spark Streaming秒级（取决于batchInterval）。
时间语义：Flink支持事件时间/处理时间/注入时间；Spark Streaming主要处理时间。
乱序处理：Flink有Watermark机制；Spark Streaming窗口基于处理时间。
状态管理：Flink原生支持Keyed/Operator State+TTL；Spark Streaming需外部维护。
容错：Flink Checkpoint；Spark Streaming WAL+Checkpoint。
Exactly-Once：Flink原生支持；Spark Streaming需额外配置。

📌 关键知识点：流vs微批、事件时间支持、状态管理、容错机制
⚠️ 易错点：Spark Structured Streaming已改进（支持事件时间、Watermark），但仍基于微批

## 题目描述

在Spark任务中，某partition的key数据量是其他key的1000倍，导致该partition执行时间远超其他partition。请给出至少3种解决方案，并分析每种方案的优缺点。

## 场景

```
Table A: 10亿行，user_id分布不均，user_id=0的行占5亿
Table B: 1000万行，均匀分布
SQL: SELECT A.* FROM A JOIN B ON A.user_id = B.user_id
```

## 参考答案

**方案1：加盐（Salting）**
- 对大表A的user_id=0随机加盐为0_1,0_2,...0_N
- 小表B对user_id=0扩容N倍，分别对应0_1,...0_N
- 优点：数据均匀分布，并行度提升
- 缺点：小表扩容增加内存，需修改业务逻辑

**方案2：两阶段聚合**
- 阶段1：局部聚合（加随机前缀group by）
- 阶段2：全局聚合（去掉前缀group by）
- 优点：不需要修改join逻辑
- 缺点：增加一轮shuffle

**方案3：广播小表**
- B表只有1000万，可以broadcast
- A不做shuffle，每个executor持有B的完整副本
- 优点：完全消除shuffle
- 缺点：仅适用于小表能放入内存的场景

**方案4：采样后单独处理**
- 先采样发现倾斜key
- 倾斜key单独处理（如与B表filter后join）
- 非倾斜key正常join
- 最后union
- 优点：不影响正常数据处理
- 缺点：逻辑复杂，需两次join

## 题目描述

Flink从Kafka消费数据，经过窗口聚合后写入MySQL，如何保证端到端Exactly-Once语义？请画出数据流并说明每个环节的一致性保障机制。

## 数据流

```
Kafka Source → Flink 窗口聚合 → MySQL Sink
```

## 参考答案

**1. Kafka Source端**
- Flink Kafka Consumer支持Exactly-Once，通过定期提交offset到Kafka
- offset提交与checkpoint绑定，只有checkpoint成功才提交offset
- 依赖：Kafka 0.11+的事务特性

**2. Flink内部**
- Checkpoint机制：Chandy-Lamport算法，周期性barrier对齐
- 算子状态随checkpoint保存到分布式存储（HDFS/S3）
- 重启时从最近一次成功checkpoint恢复

**3. MySQL Sink端**
- 两阶段提交（2PC）：
  - 预提交：在checkpoint barrier到达时，将事务标记为pre-commit
  - 正式提交：JobManager确认所有算子checkpoint成功后，通知sink提交事务
- 幂等写入：用业务主键做UPSERT，重复写入不会产生副作用

**4. 端到端保障条件**
- Source支持重置偏移量（Kafka支持）
- 内部计算依赖Checkpoint（Flink原生支持）
- Sink支持事务或幂等写入（2PC或UPSERT）

## 题目描述

设计一个Kafka消息不丢失的端到端方案，覆盖Producer、Broker、Consumer三个环节，并说明每个环节的配置参数和原理。

## 参考答案

**1. Producer端**
- 设置 acks=all（或acks=-1）：等待所有ISR副本确认
- 设置 retries>0：网络异常自动重试
- 设置 enable.idempotence=true：幂等生产，防止重试导致重复
- 设置 max.in.flight.requests.per.connection=5（幂等开启时自动设置）
- 使用回调callback确认发送成功

**2. Broker端**
- replication.factor>=3：至少3个副本
- min.insync.replicas=2：至少2个ISR副本确认写入
- unclean.leader.election.enable=false：禁止非ISR副本成为leader
- 这样即使1台broker宕机，数据仍可从ISR副本恢复

**3. Consumer端**
- 手动提交offset（enable.auto.commit=false）
- 业务处理完成后再提交offset
- 消费逻辑做幂等处理（防重复消费）
- 具体流程：poll → 处理业务 → 提交offset

**4. 极端场景**
- Broker全部宕机：依赖多机房副本/跨集群镜像（MirrorMaker）
- Consumer处理失败：不提交offset，重启后重新消费

## 题目描述

Hive SQL执行时某Reducer运行时间远超其他Reducer（数据倾斜），请给出排查步骤和至少4种优化方案。

## 场景

```sql
SELECT user_id, COUNT(*) AS cnt
FROM user_behavior_log
GROUP BY user_id;
```

user_id=0的行占60%（默认值/测试数据），导致一个Reducer处理大部分数据。

## 参考答案

**排查步骤：**
1. 查看YARN日志，找到运行时间最长的Reducer
2. 检查该Reducer处理的key分布
3. 确认倾斜key（如user_id=0）

**方案1：Map端聚合**
- 设置 hive.map.aggr=true（默认开启）
- 在Map端做局部聚合，减少Shuffle数据量

**方案2：Skew Join优化**
- 设置 hive.optimize.skewjoin=true
- 设置 hive.skewjoin.key=100000（超过10万行的key视为倾斜key）
- Hive自动将倾斜key的join走单独的Map任务

**方案3：加盐打散**
- 对倾斜key随机加盐：CONCAT(user_id, '_', FLOOR(RAND()*10))
- 先局部聚合，再去掉盐值全局聚合

**方案4：过滤无效数据**
- 如果user_id=0是默认值/脏数据，直接WHERE过滤
- WHERE user_id != 0

**方案5：增加Reducer数**
- set mapreduce.job.reduces=200
- 将倾斜数据分到更多Reducer
- 对轻度倾斜有效，重度倾斜效果有限

## 题目描述

电商平台用户维度表中，用户的会员等级会随时间变化（如从普通→银卡→金卡）。请设计数仓分层方案，并说明如何处理这种缓慢变化维（SCD Type 2）。

## 参考答案

**数仓分层：**
- ODS：原始日志（binlog同步，不加工）
- DWD：明细层（清洗+标准化，如user_id统一、时间格式化）
- DWS：汇总层（按主题聚合，如用户维度表）
- ADS：应用层（直接服务于报表/推荐）

**SCD Type 2实现：**
- 维度表增加 effective_start_date、effective_end_date、is_current 三个字段
- 每次属性变更时：关闭旧记录（end_date=变更日期，is_current=0），插入新记录（start_date=变更日期，is_current=1）

```sql
-- 维度表示例
user_id | level  | start_date | end_date   | is_current
1001    | 普通   | 2024-01-01 | 2024-03-15 | 0
1001    | 银卡   | 2024-03-15 | 2024-06-01 | 0
1001    | 金卡   | 2024-06-01 | 9999-12-31 | 1
```

**查询某时间点的维度：**
```sql
SELECT * FROM dim_user
WHERE user_id = 1001
  AND '2024-04-01' BETWEEN start_date AND end_date;
-- 返回：银卡
```

**查询当前维度：**
```sql
SELECT * FROM dim_user WHERE is_current = 1;
```

## 题目描述

公司需要建设实时数仓，请对比Lambda架构和Kappa架构的优缺点，并给出选型建议。

## 参考答案

**Lambda架构：**
- 批处理层（Hadoop/Spark）+ 实时层（Flink/Storm）+ 服务层
- 优点：批处理保证准确性，实时层保证低延迟
- 缺点：两套代码逻辑需维护一致性，运维成本高

**Kappa架构：**
- 只有一条实时流（Flink），通过回放Kafka历史数据实现重算
- 优点：一套代码，逻辑一致性好
- 缺点：全量回放耗时长，对Flink稳定性要求高

**选型建议：**
- 数据准确性要求极高（金融）→ Lambda
- 团队规模小、迭代快 → Kappa
- 实际中常混用：核心链路用Lambda，辅助分析用Kappa
- 趋势：Flink SQL + Hudi/Iceberg正在模糊两套架构的边界

## 题目描述

请设计一个电商用户画像标签系统，包含标签定义、数据流、存储选型和更新策略。

## 参考答案

**标签分类：**
1. 统计标签：消费金额、登录次数、购买品类数（从事实表聚合）
2. 规则标签：高价值用户（消费>1万）、活跃用户（7日内登录>3次）
3. 预测标签：流失概率、购买倾向（ML模型输出）

**数据流：**
```
用户行为日志 → Kafka → Flink实时计算 → HBase（实时标签）
                → Hive离线计算 → MySQL（全量标签）
```

**存储选型：**
- HBase：实时标签读写，支持rowkey快速查询
- Hive/ClickHouse：离线分析，复杂查询
- Redis：热门用户标签缓存，毫秒级响应
- MySQL：标签元数据+规则配置

**更新策略：**
- 实时标签：Flink消费Kafka实时更新
- 日标签：T+1离线批量计算覆盖
- 月标签：每月1号全量重算

**标签服务：**
- API层：根据user_id查标签，先查Redis→HBase→降级
- 标签组合：支持多标签AND/OR筛选，导出人群包

1. 如何从大量的 URL 中找出相同的 URL？ 给定 a、b 两个文件，各存放 50 亿个 URL，每个 URL 各占 64B，内存限制是 4G。请找出 a、b 两个文件共同的 URL。 每个 URL 占 64B，那么 50 亿个 URL占用的空间大小约为 320GB。 由…

一千个读者眼中有一千个哈姆雷特，一千名 大数据 程序员心目中就有一千套 大数据面试题。本文就是笔者认为可以用来面试大数据 程序员的面试题。 这套题的题目跟公司和业务都没有关系，而且也并不代表笔者本人可以把这些题回答得非常好，笔者只是将一部分觉得比较好的题从收集的面试题里面抽出来…

1、集群的最主要瓶颈 磁盘IO 2、Hadoop运行模式 单机版、伪分布式模式、完全分布式模式 3、HDFS写流程 1）client 客户端发送上传请求，通过 RPC 与 namenode 建立通信，

大数据工程师是近几年异常火爆的职位，市场需求旺盛，众多互联网公司都打出了高薪招聘的广告，本文整理了网络上部分技术人员分享的各大互联网公司大数据类(Hadoop、Spark等)面试题以及面试时需要注意的一些问题，希望对各位技术人员有所帮助。 分享之前我还是要推荐下我自己创建的大数…

前言 随着 5G 时代的到来，大数据人工智能产业链又一次迎来了井喷式的爆发，随着岗位需求的不断增加，越来越多的人选择大数据课程，但是没有真正从事大数据工作的人面对企业面试有种无从下手的感觉，面对面试说

「Offer 驾到，掘友接招！我正在参与2022春招系列活动-经验复盘，点击查看 活动详情 题目来源 作者：是锅粥 链接：https://www.nowcoder.com/discuss/745950

1、HAnamenode 是如何工作的? ZKFailoverController主要职责 1）健康监测：周期性的向它监控的NN发送健康探测命令，从而来确定某个NameNode是否处于健康状态，如果机

本文整理了互联网大厂数据开发、数据分析、数仓等数据相关岗位面试过程中经常出现的SQL面试题，并给出了参考答案。涉及了炸裂函数、开窗函数、聚合函数开窗、在线直播人数等 以及这两年各大厂面疯了各种连续问题

1. hadoop 架构 Hadoop2.0版本，引入了Yarn。核心：HDFS+Yarn+Mapreduce Yarn是资源调度框架。能够细粒度的管理和调度任务。此外，还能够支持其他的计算框架，比如spark等。 Namenode：也叫名称节点，是HDFS的守护程序（一个核心…

六、描述HBase 中scan 和get 的功能以及实现的异同？七、hbase如何导入数据？八、hbase 的存储结构？九、解释下 hbase 实时查询的原理十、详细描述 HBase 中一个 cell 的结构？十一、简述 HBase 中 compact 用途是什么，什么时候触发，...

1. 通常来说，Spark与MapReduce相比，Spark运行效率更高。请说明效率更高来源于Spark内置的哪些机制？ spark是借鉴了Mapreduce,并在其基础上发展起来的，继承了其分布式

1、Flink怎么做压力测试和监控？ 参考答案：我们一般碰到的压力来自以下几个方面： （1）产生数据流的速度如果过快，而下游的算子消费不过来的话，会产生背压。背压的监控可以使用FlinkWebUI(l

local 本地，通常是测试的时候用。 standalone，Spark 自己模拟作为一个调度系统，任务提交给 Master。 SparkonYarn 交给Yarn来进行资源调度，有 yarn-clu

​ 目录 HDFS文件写入和读取流程 HDFS组成架构 介绍下HDFS，说下HDFS优缺点，以及使用场景 HDFS作用 HDFS的容错机制 HDFS的存储机制 HDFS的副本机制 HDFS的常见数据格

什么是数据湖 数据湖（Data Lake）是一个大型数据存储和处理系统， 它能够存储各种类型和格式的数据，包括结构化数据、半结构化数据和非结构化数据。以下是关于数据湖的详细解释： 定义与特点 数据存储

​ 1、介绍下YARN 2、YARN有几个模块 3、YARN工作机制 4、YARN有什么优势，能解决什么问题? 5、YARN容错机制 6、YARN高可用 7、YARN调度器 8、YARN中Contai

分享大数据常见的面试题 一、mr的shuffle流程 说到mr的Shuffle，那么首先要明确shuffle属于哪个阶段。shuffle就是从Map端输出到Reduce输入的整个过程，这个过程广义上称

介绍下Flume  Flume架构  Flume有哪些Source  说下Flume事务机制  介绍下Flume采集数据的原理？底层实现？  Flume如何保证数据的可靠性  Flume传输数据时如何

介绍一下Mysql和Hivesql的区别？ 一方面，可以从底层原理出发回答，例如： 查询语言不同： Hive是hql语言，Mysql是sql语句； 存储位置不同： Hive是建立在 Hadoop 之上

一种特殊的线性表（数据元素首尾相接），特殊之处在于只允许在首部移除元素和在尾部追加元素。入队、出队。 3. 消息队列的分类 每个消息可以有多个消费者，彼此互不影响。比如我发布一个微博：关注我的人都能够看到。 4. Kafka的简介 5. Kafka的特点 基于分布式的扩展和容错…

Spark解决什么问题 二 Spark为什么会有自己的资源调度器 三 Spark运行模式 四 Spark常用端口号 五 Spark提交作业参数 六 Spark的transformation算子

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

Spark是一个围绕速度、易用性和复杂分析构建的大数据处理框架，Spark提供了一个全面、统一的框架用于管理各种有着不同性质(文本数据、图表数据等)的数据集和数据源(批量数据或实时的流数据)的大数据处理的需求。成为大数据核心技术之一，自然也成为了众多企业面试的核心专业问题，小编…

Spark系列面试题 Spark面试题（一） Spark面试题（二） Spark面试题（三） Spark面试题（四） Spark面试题（五）——数据倾斜调优 Spark面试题（六）——Spark资源调

微信搜索公众号：知了小巷公众号后台回复“资料”两个字，有大数据神秘学习大礼包！1.Spark的几种部署模式及其特点SparkSubmit#prepareSubmitEnvironment本地模式Spa

## Spark系列面试题 - [Spark面试题（一）](https://www.ikeguang.com/?p=1922) - [Spark面试题（二）](https://www.ikeguang

Spark是一种由Scala语言开发的快速、通用、可扩展的大数据分析引擎。Spark Core中提供了Spark最基础与最核心

1）本地模式   Spark不一定非要跑在hadoop集群，可以在本地，起多个线程的方式来指定。将Spark应用以多线程的方式直接运行在本地，一般都是为了方便调试，本地模式分三类   local：只启动一个executor   local[k]:启动k个executor   lo...

Spark的任务执行流程 https://wenku.baidu.com/view/9bf37bd07f1cfad6195f312b3169a4517723e513.html Spark总体架构和运行

简单介绍一下 Flink   Flink 是一个框架和分布式处理引擎，用于对无界和有界数据流进行有状态计算。并且 Flink 提供了数据分布、容错机制以及资源管理等核心功能。Flink提供了诸多高抽

概述2019年是大数据实时计算领域最不平凡的一年，2019年1月阿里巴巴Blink（内部的Flink分支版本）开源，大数据领域一夜间从Spark独步天下走向了两强争霸的时代。Flink因为其天然的流式

有没有去面试的时候被问到Flink的面试题你答不上来，为什么那？，菜吗？ 不是。原因是你接触的面试题太少了，那我今天就根据不同的群体来给大家你分享。 好今天的Flink的题目就分享到这里，背过上面的那些题目害怕面试官提问？信自己，努力和汗水总会能得到回报的。我是大数据老哥，我们…

相信小伙伴们对于Flink一定不会感到陌生，作为连续三年蝉联第一，荣膺全球最活跃的 Apache 开源项目，Flink在中国的热度也一直是居高不下。近几年，在社区的推动下，Flink 技术栈在越来越多的公司开始得到应用，因此在大数据的求职招聘中，对于Flink的着重考察也变得越…

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

1，简单介绍一下 Flink Flink 是一个框架和分布式处理引擎，用于对无界和有界数据流进行有状态计算。并且 Flink 提供了数据分布、容错机制以及资源管理等核心功能。Flink提供了诸多高抽象

Flink中的执行图一般是可以分为四类，按照生成顺序分别为：StreamGraph-> JobGraph-> ExecutionGraph->物理执行图。顾名思义，这里代表的是我们编写的流程序图。通过Stream API生成，这是执行图的最原始拓扑数据结构。StreamGraph...

16. Flink中有哪些窗口？ Flink 支持两种划分窗口的方式，按照time和count。如果根据时间划分窗口，那么它就是一个time-window 如果根据数据划分窗口，那么它就是一个coun

1 Flink的并行度了解吗？Flink的并行度设置是怎样的？ Flink中的任务被分为多个并行任务来执行，其中每个并行的实例处理一部分数据。这些并行实例的数量被称为并行度。我们在实际生产环境中可以从

你对大数据有什么理解？Hadoop有哪些了解？Hadoop的优势劣势？高可用怎么做的？不同database的应用场景？

---

🤖 AI解析：
大数据定义：处理海量数据的技术工具体系。Hadoop=HDFS(存储)+MapReduce(计算)+YARN(调度)。优势：海量离线存储稳定、数据安全(NameNode HA)；劣势：计算慢(比Spark差20倍)、不支持多任务并发、基于磁盘。高可用=双NameNode策略。Database场景：Hive(离线数仓)、HBase(实时数仓)、ClickHouse(实时+SQL)、ES(全文检索)、MySQL(RDBMS)。

📌 关键知识点：Hadoop三大组件功能；NameNode HA原理；不同数据库的选型依据；大数据从2012发展到后红海时代的趋势
⚠️ 易错点：不要只说Hadoop=大数据，Spark/Flink才是当前主流计算引擎；Hadoop3的纠删码将3倍存储压缩为1.5倍是重要更新

小红书数据开发一面：介绍项目、ODS和DWD怎么区分分别存什么数据、跨数据域问题怎么做、有哪些宽表、对数仓的理解。

---

🤖 AI解析：
ODS：原始数据层，保持与业务库一致的结构，不做清洗，是数仓的'原材料'。DWD：明细数据层，对ODS做清洗(去重/空值处理/格式统一)，按主题域组织，是数仓的'净菜'。跨数据域：通过DWS(汇总层)打通，如用户域+交易域的交叉分析。宽表：将多维度指标合并到一张表减少JOIN，如用户行为宽表。

📌 关键知识点：数仓分层模型(ODS→DWD→DWS→ADS)的设计逻辑；跨域分析要在汇总层做而非直接跨明细层JOIN；宽表vs窄表的取舍
⚠️ 易错点：ODS不等于'脏数据层'——它保持原始是为了溯源；跨域直接JOIN明细层会导致数据膨胀和笛卡尔积

周五发现小红书DAU相比前一周同一天下降了5%，从哪些维度展开归因分析？

---

🤖 AI解析：
归因框架：内部拆解×外部排查。内部：①新老用户拆分(新用户看拉新渠道/获客成本，老用户看留存拐点)；②产品模块拆(社区feed/搜索/商城/消息)；③版本拆(新版本bug/体验变差)；④地域渠道拆(iOS/Android/一线/下沉)。外部：竞品动作(抖音/快手运营活动)、季节性(节假日/考试季)、技术层面(接口异常/CDN延迟/崩溃率)。

📌 关键知识点：归因分析的标准框架(内部×外部)；新老用户拆分是第一步；要给出结论和行动建议而非只列可能性
⚠️ 易错点：先验证数据本身是否正常(埋点/ETL问题经常被忽略)；归因要落到具体行动而非泛泛分析

什么是Shuffle？哪些操作触发Shuffle？如何优化Shuffle性能？

---

🤖 AI解析：
Shuffle=数据在不同分区间重新分布的过程，发生在宽依赖操作中。触发Shuffle的操作：groupByKey、reduceByKey、join(非广播)、distinct、repartition、sortByKey。优化方法：①reduceByKey替代groupByKey(Map端预聚合)；②调整spark.sql.shuffle.partitions；③Kryo序列化；④广播Join替代Shuffle Join(小表广播)；⑤启用AQE自动合并小分区(Spark3.0+)。

📌 关键知识点：Shuffle=Spark最大性能瓶颈；reduceByKey预聚合vs groupByKey无预聚合；Broadcast Join是零Shuffle方案
⚠️ 易错点：groupByKey不做预聚合，Shuffle数据量巨大；Broadcast Join小表默认阈值10MB，超阈值需手动调或显式broadcast()

什么是RDD？五大特性是什么？Transformation和Action的区别？

---

🤖 AI解析：
RDD=Resilient Distributed Dataset，不可变、可分区、可并行操作的元素集合。五大特性：①一组分区(Partitions)；②每个分区的计算函数；③依赖关系(Lineage)；④分区器(Partitioner，KV RDD可选)；⑤首选位置(Preferred Locations，数据本地性)。Transformation=懒执行返回新RDD(map/filter/groupByKey等)；Action=触发实际计算返回结果(collect/count/saveAsTextFile等)。

📌 关键知识点：RDD的Lineage血统机制是容错基础；Transformation Lazy执行只有Action才触发Job；五大特性决定了RDD的分布式计算能力
⚠️ 易错点：不要混淆Transformation和Action——Transformation不触发计算；频繁创建RDD链但不Action会导致资源浪费

Spark如何避免数据倾斜(Data Skew)？

---

🤖 AI解析：
数据倾斜表现：少数Task处理大量数据拖慢整个Job。解决方案：①加盐(Salting)打散热点Key——加随机前缀分散到不同分区；②两阶段聚合(局部聚合+全局聚合)；③采样分析倾斜Key单独处理；④repartition/coalesce调整分区；⑤Broadcast Join小表避免Shuffle倾斜；⑥AQE自动检测拆分倾斜分区(Spark3.0+)。

📌 关键知识点：加盐打散是数据倾斜最常用的方案；两阶段聚合=先局部聚合减数据量再全局聚合；AQE是Spark3.0的自动优化利器
⚠️ 易错点：加盐后Join需两步(先加盐Join再去盐聚合)；AQE需设置spark.sql.adaptive.enabled=true才能生效

生产环境中Flink实时ETL任务出现延迟，下游Kafka消费lag持续上涨，如何诊断和处理反压问题？

---

🤖 AI解析：
诊断：①Flink Web UI查看BackPressure指标(红色=高反压)；②看TaskManager日志是否有buffer耗尽；③分析哪个算子是瓶颈(通常是聚合/Join)。处理：①增大并行度分散负载；②优化算子逻辑(预过滤减少数据量)；③调整网络buffer配置(taskmanager.network.memory)；④异步IO替代同步查询；⑤分区重平衡(rebalance/rescale)。

📌 关键知识点：反压是Flink自稳机制——下游慢时自动减缓上游速率；但持续反压意味着性能瓶颈需人工干预；Kafka lag是反压的外在信号
⚠️ 易错点：反压不等于数据丢失——Flink的checkpoint保证一致性；但持续反压会导致延迟累积，需及时定位瓶颈算子

Flink架构是怎样的？核心组件有哪些？

---

🤖 AI解析：
Flink架构：①JobManager(调度+协调)：接收Job、生成执行图、调度Task、协调checkpoint/barrier；②TaskManager(执行)：执行Task、维护状态、报告心跳；③Client(提交)：用户提交Job的入口。编程模型：Source→Transformation→Sink。核心概念：Stream(无界/有界)、State(Keyed/Operator)、Time(Event/Processing/Ingestion)、Window(Tumbling/Sliding/Session)。

📌 关键知识点：JobManager是大脑(调度协调)、TaskManager是手脚(执行计算)；Flink同时支持批流统一(DataStream API)；Checkpoint是容错的基石
⚠️ 易错点：Flink不是'只做流处理'——批处理是有界流的特例；Checkpoint间隔太短影响吞吐、太长影响恢复速度

Flink的Checkpoint容错机制怎么实现的？和Spark Streaming有什么区别？

---

🤖 AI解析：
Checkpoint原理：①JobManager定期向Source注入Barrier标记；②Barrier随数据流流经每个算子；③算子收到Barrier后快照当前State到StateBackend；④所有算子完成快照后向JobManager报告；⑤JobManager确认Checkpoint完成。与Spark Streaming区别：Flink是原生流处理(逐条处理)，Checkpoint是exactly-once语义；Spark Streaming是微批(Micro-batch)，容错靠RDD Lineage重算，是at-least-once。

📌 关键知识点：Barrier算法是Checkpoint的核心——异步快照不阻塞数据流；Flink exactly-once vs Spark at-least-once是本质区别
⚠️ 易错点：Checkpoint不是'保存所有数据'而是只保存State快照；StateBackend选择(RocksDB/Heap)影响性能和内存占用

抖音推荐算法从A模型换成B模型提高观看时长，设计AB实验方案包括分流、样本量、评估指标、注意事项。

---

🤖 AI解析：
实验设计：①用户ID hash分流保证同一用户始终在同一组；②对照组A模型、实验组B模型；③时长≥2周覆盖完整周期。样本量：n=(Z_α/2+Z_β)²×2σ²/δ²，字节要求power=0.8、α=0.05。评估指标：核心=人均观看时长(正指标)，辅助=完播率/点赞率/分享率，负向=跳出率/负反馈率。注意事项：①网络效应(社交产品实验组内容可能被对照组看到造成污染)；②新奇效应(新算法上线初期用户新鲜感异常行为)；③多重比较(看太多指标容易假阳性)。

📌 关键知识点：分流用hash保证一致性；样本量公式需指定效应量和显著性水平；网络效应是社交产品AB实验的特殊挑战
⚠️ 易错点：p=0.08不显著≠不能上线——需考虑成本收益权衡；新奇效应需跑足够长时间稀释；多重比较需Bonferroni校正

某天抖音DAU下降了5%，作为数据分析师怎么排查原因？

---

🤖 AI解析：
框架：①验证数据(埋点/ETL是否异常，最常见但最易忽略)；②看大盘(同比环比判断周期性vs突发)；③拆维度：新老用户(新用户看渠道/获客，老用户看留存拐点)、产品模块(哪个模块日活降最多)、版本(新版bug)、地域渠道；④外部因素：竞品活动、公共事件、技术异常。结论要落到行动：如'新用户次日留存从60%降到45%，原因是拉新渠道从信息流广告换线下地推，用户质量下降'。

📌 关键知识点：先验证数据再分析是铁律；新老用户拆分是第一步；结论必须给出具体行动建议而非泛泛分析
⚠️ 易错点：忽略数据质量问题直接归因会误判；DAU下降可能是正常的周期性波动而非异常

小红书笔记曝光量近一个月持续下降但发布量稳定，分析可能原因并给出建议。

---

🤖 AI解析：
问题在流量分发端而非内容供给端。可能原因：①推荐系统匹配效率下降(CTR/完播率/互动率趋势变差)；②低质量内容占比上升(标题党/同质化/搬运)挤压优质内容曝光；③流量池规则调整(冷启动流量减少导致新笔记曝光不足)；④广告位/电商卡片增多挤压自然内容；⑤用户疲劳(同质化导致活跃频率降低)。建议：优化推荐算法权重、打压低质内容、调整流量池分配、控制广告加载率。

📌 关键知识点：曝光降但发布稳=分发端问题而非供给端；小红书分级流量池机制是关键约束；推荐效率+内容质量双维分析
⚠️ 易错点：不能简单归因'用户减少了'——需区分是推荐效率低还是内容质量差导致曝光不足

小红书在某综艺节目投放广告，如何评估拉新效果？

---

🤖 AI解析：
评估框架：①核心指标：新增用户数、CPA(获客成本)、新用户次日/7日留存、人均时长、首周发布率(衡量是否有价值的内容贡献者)；②归因方式：双重差分法——选未投放的相似时段作对照排除季节性；③自然增量vs广告增量(品牌溢出效应)；④长期价值：30日/90日留存对比自然渠道用户；⑤归因模型：末次点击vs多触点归因(不同模型ROI差异大)。

📌 关键知识点：双重差分法排除季节性干扰；品牌溢出效应=自然渠道也增长说明投放有品牌价值；长期留存才是真质量指标
⚠️ 易错点：末次点击归因会忽略前置触达的价值；'一锤子用户'拉新成本看似低但长期LTV可能远低于自然渠道

小红书信息流广告收入环比下降10%，分析可能原因并给出改进建议。

---

🤖 AI解析：
拆解公式：广告收入=展示量×CPM。展示量下降：①DAU/session数下降(用户少了)；②广告加载率下降(产品调整了广告位策略)；③内容供给不足用户刷不到底。CPM下降：①广告主出价降低(大促后淡季)；②广告CTR下降(创意疲劳/用户免疫)；③填充率下降(DMP定向能力变差)。建议：提升DAU/session数、优化CTR(更新创意素材)、调整出价策略(oCPM)、改进归因模型(多触点归因)。

📌 关键知识点：收入=展示量×CPM是拆解起点；展示量和CPM需分别排查；商业sense是数据分析师的核心竞争力
⚠️ 易错点：不能只看总收入——需拆到展示量和CPM再分别定位；广告加载率过高会影响用户体验导致长期留存下降

设计一套视频质量评分体系评估每条视频在推荐系统中的表现，设计哪些指标怎么综合打分？

---

🤖 AI解析：
分层指标体系：①消费层(完播率/播放时长/重播率)；②互动层(点赞率/评论率/分享率/关注转化率)；③负向层(划走率/不感兴趣率/举报率)。综合打分：加权打分法(权重通过回归模型或专家经验定)，借鉴YouTube'观看时长预期'或抖音内部'视频价值分'。防作弊：点赞没有完播要降权重。需按视频时长分层归一化(不同时长视频互动率天差地别)。

📌 关键知识点：指标分层(消费→互动→负向)而非只列互动率；按时长归一化是必须的；防作弊权重调整体现业务理解深度
⚠️ 易错点：不同时长视频互动率不可直接比较(15秒vs5分钟)；只有互动没有完播的'刷量'视频需降权

1. Spark内存分为执行内存(Execution Memory)和存储内存(Storage Memory)
2. 统一内存管理：执行内存和存储内存可以互相借用
3. 堆内内存通过JVM管理，堆外内存通过Unsafe类直接操作
4. 常见问题：内存溢出、GC开销过大
5. 调优建议：合理设置spark.memory.fraction和spark.memory.storageFraction

1. Checkpoint是自动的周期性快照，用于故障恢复
2. Savepoint是手动触发的快照，用于版本升级和集群迁移
3. Checkpoint使用增量机制，Savepoint是全量
4. Savepoint需要显式停止作业后才能使用
5. 格式上Savepoint更规范，兼容性更好

1. 维度建模（星型/雪花模型）：查询性能好，适合OLAP场景
2. 范式建模（3NF）：数据冗余少，适合OLTP场景
3. 阿里数仓架构：ODS(贴源层) → DWD(明细层) → DWS(汇总层) → ADS(应用层)
4. 实际工作中通常混合使用：底层范式建模保一致性，上层维度建模提升查询效率
5. 面试重点：理解事实表、维度表、缓慢变化维

1. 主备NameNode通过JournalNode集群同步元数据
2. 主NameNode写入EditLog到JournalNode，备NameNode读取并回放
3. 故障切换通过ZooKeeper实现自动failover
4. 脑裂防护：配置fence机制确保旧主被隔离
5. 面试延伸：SecondaryNameNode != Standby NameNode

生产者端：
1. 设置acks=all，等待所有ISR副本确认
2. 开启幂等生产者(enable.idempotence=true)
3. 使用事务保证跨分区原子性

Broker端：
4. min.insync.replicas≥2
5. unclean.leader.election.enable=false

消费者端：
6. 关闭自动提交offset
7. 业务处理完成后再手动提交

1. 现象：某几个Task运行极慢，其他Task已完成
2. 原因：group by/key join时key分布不均匀
3. 解决方案：
   - 开启map端聚合：set hive.map.aggr=true
   - 倾斜join：set hive.optimize.skewjoin=true
   - 加盐打散：给key加随机前缀
   - 增加reduce数：set mapred.reduce.tasks=N
4. 面试加分：结合具体场景分析，如空值倾斜、大表join小表

分布式工作流调度平台。DAG可视化编排、支持多种任务类型(Shell/SQL/Spark)、失败重试和告警、补数和回溯、资源中心管理、多租户隔离。对比Airflow：更轻量、中文社区强。

1.散列性：避免热点(加盐/反转/Hash) 2.长度原则：越短越好(减少存储) 3.唯一性 4.业务含义：前缀放高频查询字段 5.预分区策略(配合分区键)。经典设计：Salt_Hash+业务ID+时间戳。

UnifiedMemoryManager：300M预留→Storage+Execution共享(可动态借用)→Other。Storage存RDD缓存，Execution存Shuffle中间数据。配置spark.memory.fraction控制占比。

穿透：查不存在的数据→布隆过滤器或缓存空值。击穿：热点key过期→互斥锁或逻辑过期。雪崩：大量key同时过期→随机过期时间、多级缓存、熔断降级。

列式存储减少IO、数据压缩、向量化引擎(批量处理)、MergeTree表引擎、稀疏索引、数据分片+副本、预聚合(Materialized View)。适合OLAP场景，不适合频繁更新。

常见场景：group by倾斜、join倾斜、count distinct倾斜。解决：1.两阶段聚合(加随机前缀) 2.Map Join把小表广播 3.分桶join 4.增大reduce并行度 5.过滤异常数据 6.自定义分区器

Map阶段：读数据→映射→分区排序→溢写磁盘。Shuffle阶段：Map输出→Reduce拉取→合并排序。Reduce阶段：规约→输出。核心：数据本地性、Combiner预聚合、Partitioner分区。

Spark Streaming：微批处理、延迟秒级、Exactly-Once靠WAL和幂等输出。Flink：事件级处理、延迟毫秒级、Checkpoint+Savepoint保证Exactly-Once。Flink优势：真正的流计算、状态管理更强大、CEP支持。

ZAB协议保证一致性。Leader选举：每个节点投票给最大的Zxid和myid。过半原则保证可用性。选举过程：LOOKING→LEADING/FOLLOWING。Leader故障后30s超时触发重选。

ODS层：原始数据层，贴源设计 DWD层：明细数据，清洗脱敏 DWS层：轻度汇总，按主题聚合 ADS层：应用层，报表指标 DIM层：维度表。表命名：{层级}_{主题}_{粒度}_{分区}

写流程：Client创建文件→NameNode检查→数据分块→建立DataNode pipeline→Packet传输→收到全部ACK后汇报NN。读流程：Client获取Block位置→选择最近DN→并行读取→校验和验证。

Watermark用于处理乱序数据。原理：插入特殊时间戳标记，告知算子在该时间之前的窗口可以触发计算。BoundedOutOfOrderness策略设置最大乱序时间。迟到数据处理：sideOutput侧输出流。

1. 顺序读写磁盘(页缓存+零拷贝sendfile) 2. 分区机制实现并行 3. 批量发送和压缩 4. 稀疏索引 5. PageCache利用OS缓存 6. 批处理+消息日志追加写 7. Consumer的pull模式

1. 使用分区表减少扫描数据量 2. ORC/Parquet列式存储 3. 谓词下推 4. JOIN时小表放前面(MapJoin) 5. 避免SELECT * 6. 合理设置并行度 7. 使用向量化查询 8. 避免数据倾斜(打散key)

Shuffle是Spark中数据重新分区的过程。在宽依赖(ShuffleDependency)中触发。过程：Map端将数据写入本地磁盘(按分区排序)，Reduce端通过网络拉取对应分区数据。优化：map-side预聚合、调整shuffle分区数、使用sortShuffleManager。