简介这份资源是面向大数据开发、大数据运维、云计算、数据治理及大数据架构师岗位的面试题合集适合准备跳槽或系统梳理知识体系的初中高级从业者。内容围绕Linux与Shell基础、Hadoop生态、Zookeeper、Flume、Kafka、Hive、HBase、Sqoop、Scala与Spark等核心模块展开涵盖HDFS读写流程、MapReduce Shuffle、YARN提交流程、Kafka数据丢失与重复、Hive数据倾斜、HBase RowKey设计、Spark宽窄依赖与Shuffle机制等高频考点。资源包内含1个docx文档压缩包约491KB目录按技术栈分章编排便于按模块检索与查漏补缺。目前已有880人学习适合作为面试前的速查手册与知识清单帮助读者快速定位薄弱环节、理解常见追问思路提升面试应答的条理性与深度。1. 大数据面试的底层逻辑为什么背题没用拆题才有用2023年这波大数据面试题被冠上“史上最全”的名头但真正面过几轮的人都知道面试官手里那套题早就不是考记忆了。大数据开发、大数据运维、云计算、数据治理、大数据架构师这五个方向共用一套底层知识栈但考察重心完全不同。开发岗盯着你写没写过 Spark 调优、Flink 状态管理运维岗问你 YARN 队列卡死怎么排查、HDFS 块丢失怎么恢复云计算方向绕不开存算分离和资源弹性数据治理要你讲清楚元数据血缘怎么落地架构师则要你在成本、时效、一致性之间做取舍。这篇笔记不打算给你一份“背完就能过”的题库而是把每个方向最高频的题拆成“面试官到底想听什么、你该怎么答、答完怎么验证”。适合已经入行一两年、准备跳槽或晋升的从业者也适合刚转方向想摸清边界的新手。下面按知识域逐层展开每章都落到可复现的命令、参数和踩坑记录。2. 大数据开发岗从 SQL 到引擎调优的硬核拆解2.1 面试官问“手写 SQL”时实际在考什么开发岗一面几乎必出手写 SQL但题目本身不难难的是面试官在你写完后的追问。常见题面是“有一张订单表求每个用户最近三笔订单金额”很多人上来就写窗口函数row_number() over(partition by user_id order by order_time desc)这没错但面试官接着会问如果订单表有十亿行这个查询在 Hive 和 Spark SQL 上分别怎么跑这就从语法考到了执行计划。我一般会先确认分区字段和排序字段的索引情况再决定用窗口函数还是lateral view加explode。下面这段 SQL 是标准写法但关键在注释里标出的参数-- 假设表名为 dwd_order分区字段 dt用户 user_id订单时间 order_time金额 amount SELECT user_id, order_id, amount, order_time FROM ( SELECT user_id, order_id, amount, order_time, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY order_time DESC) AS rn FROM dwd_order WHERE dt 2023-01-01 AND dt 2023-01-31 -- 分区裁剪必须带上 ) t WHERE t.rn 3;逻辑说明子查询里用窗口函数按用户分组、按时间倒序编号外层过滤前三。参数上dt分区裁剪是 Hive 和 Spark 都能下推的如果不带分区十亿行全表扫描直接翻车。另外ROW_NUMBER在数据倾斜时某个用户订单极多会拖慢单分区实际生产里我会先对user_id做盐化处理或者改用DISTRIBUTE BY user_id SORT BY order_time DESC加LIMIT的写法。面试时如果你能主动提数据倾斜和分区裁剪基本就甩开八成候选人了。2.2 Spark 调优三个必调参数和它们的代价Spark 开发岗面试调优是绕不过去的。面试官最爱问“你遇到过 OOM 吗怎么解决的”这题没有标准答案但有几个参数是必须知道的。我一般会从spark.sql.shuffle.partitions、spark.default.parallelism、spark.memory.fraction这三个入手。spark.sql.shuffle.partitions默认 200小数据量时任务启动开销大大数据量时单分区数据过多导致 OOM。我通常按shuffle 数据量 / 128MB估算再取 2 到 3 倍。比如 shuffle 写 50GB设 800 到 1200 比较稳。但调大不是没代价分区多了小文件就多HDFS NameNode 压力上来下游读取也慢。spark.default.parallelism控制 RDD 阶段的并行度默认是 executor 核数总和的两倍。如果 stage 里 task 数远小于这个值说明并行度不够CPU 利用率上不去。我一般会把它设成spark.sql.shuffle.partitions的 0.5 到 1 倍避免 shuffle 后 task 数骤降。spark.memory.fraction默认 0.6表示执行和存储内存占总堆的 60%。如果频繁 GC 或者 shuffle spill 严重可以提到 0.7 到 0.8但留给用户代码的内存就少了map里创建大对象容易 OOM。这个参数没有银弹我一般先看 Spark UI 的 Storage 和 Executor 页确认是执行内存不够还是存储内存不够再决定调不调。# 提交任务时的典型参数组合 spark-submit \ --master yarn \ --deploy-mode cluster \ --executor-memory 8g \ --executor-cores 4 \ --num-executors 50 \ --conf spark.sql.shuffle.partitions1000 \ --conf spark.default.parallelism800 \ --conf spark.memory.fraction0.7 \ --conf spark.sql.adaptive.enabledtrue \ --class com.example.MainJob \ app.jar注意spark.sql.adaptive.enabled在 Spark 3.x 默认开启它会自动合并小分区、处理倾斜 join但有些场景下反而让执行计划不稳定我一般会在压测时对比开和关的耗时再决定。参数说明executor-memory8g 是堆内实际容器内存还要加 10% 到 15% 的 overheadYARN 上不设spark.executor.memoryOverhead容易在 NodeManager 端被 kill。2.3 Flink 状态管理与 Checkpoint 的面试追问Flink 开发岗现在越来越热面试官常问“Checkpoint 超时怎么排查”。这题背后是状态后端、背压、Exactly-Once 三件事。我一般先看 Checkpoint 的 duration 和 size如果 size 突然涨说明状态膨胀可能是 key 设计不合理或者没设 TTL。如果 duration 长但 size 正常多半是背压导致 barrier 对齐慢。// Flink 状态 TTL 配置示例 StateTtlConfig ttlConfig StateTtlConfig .newBuilder(Time.days(7)) .setUpdateType(StateTtlConfig.UpdateType.OnCreateAndWrite) .setStateVisibility(StateTtlConfig.StateVisibility.NeverReturnExpired) .cleanupInRocksdbCompactFilter(1000) .build(); ValueStateDescriptorLong descriptor new ValueStateDescriptor(count, Long.class); descriptor.enableTimeToLive(ttlConfig);逻辑说明Time.days(7)是状态存活时间OnCreateAndWrite表示每次写入更新过期时间NeverReturnExpired保证不返回已过期数据。cleanupInRocksdbCompactFilter是 RocksDB 状态后端的清理策略每 1000 次 compaction 过滤一次过期数据。参数上TTL 设太短会丢历史状态设太长状态无限涨我一般按业务能容忍的回溯窗口来定比如风控场景 7 天实时大屏 1 天。面试时如果你能说出“RocksDB 的 compaction 会放大写延迟所以 TTL 清理要配合增量 Checkpoint”面试官基本会点头。3. 大数据运维与云计算故障排查与资源弹性的实战题3.1 YARN 队列卡死从现象到根因的排查路径运维岗面试最爱问“线上任务卡在 ACCEPTED 状态怎么办”。这题考的是对 YARN 调度器和资源池的理解。我一般按四步走先看 ResourceManager 的调度器类型Capacity 还是 Fair再看队列的usedCapacity和maxCapacity然后查是否有大任务占满资源最后看 NodeManager 是否失联。# 查看队列资源使用 yarn queue -status default # 查看应用状态 yarn application -list -appStates ACCEPTED # 查看节点状态 yarn node -list -states RUNNING逻辑说明yarn queue -status输出里usedCapacity接近 100% 说明队列满了maxCapacity是弹性上限如果usedCapacity超过maxCapacity说明配置有问题。yarn application -list看 ACCEPTED 的应用是不是在等 AM 容器如果是多半是yarn.scheduler.maximum-allocation-mb设太小大任务申请不到容器。yarn node -list看 RUNNING 节点数如果比预期少去 NodeManager 日志里搜Container killed或OutOfMemory。踩坑记录有一次队列卡死查了半天发现是某个任务把spark.executor.memory设成 64g而单节点总内存才 128gAM 申请不到资源一直等。解决方法是给队列设maximum-allocation-mb上限同时在提交脚本里加资源校验。面试时如果你能说出“ACCEPTED 卡住不一定是资源不够也可能是调度器配置的 maximum-allocation 限制”这题就答到点子上了。3.2 云计算存算分离对象存储替代 HDFS 的边界云计算方向面试常问“存算分离后HDFS 还有必要吗”。这题没有绝对答案但你要能说清楚对象存储和 HDFS 的差异。对象存储如 S3 兼容接口便宜、无限扩容但延迟高、不支持随机写、rename 是拷贝加删除。HDFS 延迟低、支持 append但扩容要加节点、运维成本高。我一般会按场景分离线批处理、冷数据归档用对象存储因为吞吐够、成本低实时计算、需要频繁 rename 的场景比如 Spark 写临时目录再 rename 到正式目录还是用 HDFS 或者本地 SSD 加缓存层。参数上对象存储的fs.s3a.connection.maximum默认 15高并发读时要调到 100 以上否则连接池打满报 timeout。fs.s3a.fast.upload开启后用小文件合并上传能减少 PUT 次数但内存占用会涨。!-- core-site.xml 中 S3A 的关键配置 -- property namefs.s3a.connection.maximum/name value200/value /property property namefs.s3a.fast.upload/name valuetrue/value /property property namefs.s3a.fast.upload.buffer/name valuedisk/value /property property namefs.s3a.block.size/name value128M/value /property逻辑说明connection.maximum控制 HTTP 连接池大小读多写少时调大fast.upload.buffer用 disk 避免堆内存溢出block.size影响并发读的粒度128M 和 HDFS 块大小对齐。注意对象存储的 rename 是拷贝加删除Spark 的_temporary目录如果和最终目录不在同一个桶rename 会变成跨桶拷贝耗时翻倍。我一般会强制临时目录和最终目录在同一个桶或者直接用DirectCommitter绕过 rename。3.3 数据治理元数据血缘的落地难点数据治理岗面试元数据血缘是必问的。面试官想知道你做过没有而不是听过没有。血缘分表级和字段级表级靠 SQL 解析字段级要靠 AST 分析。我一般用 Atlas 或者 DataHub 做采集但难点不在工具在 SQL 方言太多、动态 SQL 解析不了、临时表断链。-- 示例从 Hive 元数据里提取表级血缘的简化查询 SELECT t1.db_name AS source_db, t1.tbl_name AS source_table, t2.db_name AS target_db, t2.tbl_name AS target_table FROM (SELECT db_name, tbl_name, input_tables FROM lineage_meta WHERE dt 2023-06-01) t1 LATERAL VIEW explode(input_tables) tmp AS input_table JOIN lineage_meta t2 ON t1.input_table t2.tbl_name;逻辑说明这段 SQL 从血缘元数据表里展开输入表再关联目标表。实际生产中input_tables字段往往存的是 JSON 数组需要先用get_json_object解析。参数上dt分区按天存快照方便回溯。踩坑最多的是动态 SQL比如INSERT INTO ${table_name}这种解析器拿不到实际表名血缘就断了。我的做法是在调度系统里埋点把变量替换后的 SQL 也存一份解析时优先用替换后的版本。面试时如果你能说出“血缘断链的根因是动态 SQL 和临时表解法是调度层埋点加解析层兜底”这题就稳了。4. 大数据架构师选型、成本与一致性的权衡题4.1 Lambda 还是 Kappa架构面试的第一道分水岭架构师面试第一题往往是“你们公司用 Lambda 还是 Kappa”。这题考的是你对实时和离线统一的理解。Lambda 维护两套代码批处理保证准确性流处理保证时效性但代码重复、口径容易不一致。Kappa 只用流处理历史数据重放但流处理做复杂 join 和回溯成本高。我一般会按业务时效性和团队能力来选。如果业务能容忍 T1Lambda 更稳如果要求秒级且逻辑不复杂Kappa 更简洁。参数上Kappa 架构里 Kafka 的retention.ms要设足够长比如 7 天方便重放log.retention.bytes按磁盘容量算。Lambda 架构里 Hive 和 Kafka 的口径对齐要靠统一的 UDF 库否则同一个指标两个数。# Kafka 主题配置示例Kappa 架构重放依赖 cleanup.policy: delete retention.ms: 604800000 # 7 天 retention.bytes: 1099511627776 # 1TB segment.bytes: 1073741824 # 1GB逻辑说明retention.ms和retention.bytes同时生效谁先到删谁。segment.bytes影响重放时的并行度段太小文件多段太大重放慢。我一般按“重放窗口内数据量 / 分区数”估算段大小。注意 Kappa 架构下如果流处理逻辑改了重放历史数据要保证新逻辑兼容旧数据格式否则翻车。面试时如果你能说出“Kappa 的重放成本被低估了状态后端和 Kafka 保留策略要一起设计”面试官会认为你踩过坑。4.2 成本优化从资源利用率到存储分层架构师还要对成本负责。面试官常问“集群资源利用率低怎么优化”。我一般从三方面入手资源调度、存储分层、任务治理。资源调度上YARN 的DominantResourceCalculator比DefaultResourceCalculator更合理因为它同时考虑 CPU 和内存。存储分层上HDFS 的StoragePolicy可以把冷数据从 SSD 移到 HDD再移到对象存储。# 设置 HDFS 存储策略 hdfs storagepolicies -setStoragePolicy -path /warehouse/cold_data -policy COLD # 查看存储策略 hdfs storagepolicies -getStoragePolicy -path /warehouse/cold_data逻辑说明COLD策略表示数据只存一份且在归档存储上。WARM是 3 副本中的一份在 SSD其余在 HDD。HOT是全 SSD。参数上dfs.storage.policy.enabled要设为 true否则命令不生效。任务治理上我一般会跑一个离线分析找出连续 7 天没被访问的表自动打冷标签。注意存储策略变更后已有数据不会自动迁移要靠Mover工具触发。4.3 一致性取舍Exactly-Once 的代价架构师面试还会问“Exactly-Once 怎么实现代价是什么”。这题考的是你对分布式快照和事务的理解。Flink 的 Exactly-Once 靠 Checkpoint 和两阶段提交但代价是 Checkpoint 期间 barrier 对齐会阻塞吞吐下降。Kafka 的 Exactly-Once 靠事务和幂等生产者但事务超时和生产者 ID 管理复杂。我一般会按业务容忍度选金融场景必须 Exactly-Once用 Flink 加 Kafka 事务日志场景 At-Least-Once 加去重就够了。参数上Flink 的execution.checkpointing.mode设EXACTLY_ONCEexecution.checkpointing.timeout设 10 分钟execution.checkpointing.interval设 5 分钟。Kafka 的transaction.timeout.ms要大于 Checkpoint 间隔否则事务超时回滚。// Flink Kafka 生产者 Exactly-Once 配置 Properties props new Properties(); props.setProperty(transaction.timeout.ms, 900000); // 15 分钟 props.setProperty(enable.idempotence, true); props.setProperty(acks, all); FlinkKafkaProducerString producer new FlinkKafkaProducer( topic, new SimpleStringSchema(), props, FlinkKafkaProducer.Semantic.EXACTLY_ONCE );逻辑说明transaction.timeout.ms要大于 Checkpoint 间隔加最大延迟否则事务在 Checkpoint 完成前超时。enable.idempotence保证单分区不重复acksall保证所有副本确认。注意 Exactly-Once 只保证 Flink 内部和 Kafka 之间如果下游是 MySQL还要靠幂等写入或事务表。面试时如果你能说出“Exactly-Once 的瓶颈在 Checkpoint 对齐和事务超时不是所有场景都值得上”这题就答到架构层面了。5. 避坑与常见问题面试和实战里最容易翻车的五件事5.1 背题不背场景一问就露馅现象面试时问“Hive 数据倾斜怎么解决”候选人背出“加盐、调并行度、用 MapJoin”但追问“加盐后怎么保证结果正确”就卡住了。原因只记了结论没理解加盐后要二次聚合。解决每个方案都要能说出“为什么这样能解决、代价是什么、什么场景不适用”。我一般会准备两三个自己踩过的倾斜案例把 SQL 和参数都记清楚。5.2 参数照搬网上不看集群规模现象网上说spark.sql.shuffle.partitions设 2000直接抄到自己的小集群结果任务启动 2000 个 task调度开销比计算还大。原因参数和集群规模、数据量强相关。解决先算 shuffle 数据量再按每分区 128MB 到 256MB 估算最后用 Spark UI 验证 task 执行时间是否均匀。5.3 运维排查只看日志不看监控现象YARN 任务卡死只翻 ApplicationMaster 日志翻了半天没头绪。原因日志只记录应用内部资源层的问题在 ResourceManager 和 NodeManager 指标里。解决先看 Grafana 或 Prometheus 的队列资源、节点内存、磁盘 IO再定位到具体节点看日志。我一般会先跑yarn top看哪个队列在占资源。5.4 数据治理只上工具不改流程现象买了元数据管理平台血缘图很漂亮但开发还是乱建表血缘断链没人管。原因工具是辅助流程和规范才是根本。解决把元数据采集嵌到调度系统里建表必须走审批SQL 上线必须过解析。我一般会在调度平台加一个钩子SQL 提交前先解析血缘解析失败不允许上线。5.5 架构选型追新不看团队能力现象听说 Flink 好把所有离线任务迁到 Flink结果团队没人会调状态后端Checkpoint 天天失败。原因选型要考虑团队学习曲线和运维成本。解决新架构先小范围试点跑稳一个业务线再推广。我一般会按“业务价值 / 迁移成本”排序先迁时效性要求最高的再逐步替换。6. 面试复盘用一张表把知识域串起来面试复盘不是记题目而是记“哪个知识域答得好、哪个答得虚”。我一般会做一张表按岗位方向列知识域按掌握程度打分再针对低分项补实战。下面这张表是我自己用的复盘模板你可以直接抄。知识域开发岗权重运维岗权重云计算权重数据治理权重架构师权重我的评分SQL 与执行计划高中低中中8Spark 调优高中中低高7Flink 状态管理高低中低高6YARN 资源调度中高中低高7对象存储与存算分离低中高低高6元数据与血缘低低低高中5成本优化低中高低高6Exactly-Once 一致性中低中低高7填完表后我会挑评分低于 7 的知识域找一个小数据集跑一遍。比如 Flink 状态管理我会用本地 Kafka 加一个简单的计数任务故意让 Checkpoint 超时然后调execution.checkpointing.timeout和state.backend看效果。对象存储那块我会用 MinIO 搭一个 S3 兼容端点跑 Spark 读写观察fs.s3a.connection.maximum和fs.s3a.fast.upload对耗时的影响。最后说一个我自己的习惯每次面试完不管过没过当天晚上把被问住的题记下来第二天用最小可复现的方式跑一遍。跑不通的说明知识域有盲区跑通了但讲不清楚的说明表达有问题。这个习惯坚持了两年比背任何题库都管用。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/13 12:30:53 · 阅读 1.2k 大数据面试底层逻辑：开发、运维、云计算、治理与架构师拆题实战
简介这份资源是面向大数据开发、大数据运维、云计算、数据治理及大数据架构师岗位的面试题合集适合准备跳槽或系统梳理知识体系的初中高级从业者。内容围绕Linux与Shell基础、Hadoop生态、Zookeeper、Flume、Kafka、Hive、HBase、Sqoop、Scala与Spark等核心模块展开涵盖HDFS读写流程、MapReduce Shuffle、YARN提交流程、Kafka数据丢失与重复、Hive数据倾斜、HBase RowKey设计、Spark宽窄依赖与Shuffle机制等高频考点。资源包内含1个docx文档压缩包约491KB目录按技术栈分章编排便于按模块检索与查漏补缺。目前已有880人学习适合作为面试前的速查手册与知识清单帮助读者快速定位薄弱环节、理解常见追问思路提升面试应答的条理性与深度。1. 大数据面试的底层逻辑为什么背题没用拆题才有用2023年这波大数据面试题被冠上“史上最全”的名头但真正面过几轮的人都知道面试官手里那套题早就不是考记忆了。大数据开发、大数据运维、云计算、数据治理、大数据架构师这五个方向共用一套底层知识栈但考察重心完全不同。开发岗盯着你写没写过 Spark 调优、Flink 状态管理运维岗问你 YARN 队列卡死怎么排查、HDFS 块丢失怎么恢复云计算方向绕不开存算分离和资源弹性数据治理要你讲清楚元数据血缘怎么落地架构师则要你在成本、时效、一致性之间做取舍。这篇笔记不打算给你一份“背完就能过”的题库而是把每个方向最高频的题拆成“面试官到底想听什么、你该怎么答、答完怎么验证”。适合已经入行一两年、准备跳槽或晋升的从业者也适合刚转方向想摸清边界的新手。下面按知识域逐层展开每章都落到可复现的命令、参数和踩坑记录。2. 大数据开发岗从 SQL 到引擎调优的硬核拆解2.1 面试官问“手写 SQL”时实际在考什么开发岗一面几乎必出手写 SQL但题目本身不难难的是面试官在你写完后的追问。常见题面是“有一张订单表求每个用户最近三笔订单金额”很多人上来就写窗口函数row_number() over(partition by user_id order by order_time desc)这没错但面试官接着会问如果订单表有十亿行这个查询在 Hive 和 Spark SQL 上分别怎么跑这就从语法考到了执行计划。我一般会先确认分区字段和排序字段的索引情况再决定用窗口函数还是lateral view加explode。下面这段 SQL 是标准写法但关键在注释里标出的参数-- 假设表名为 dwd_order分区字段 dt用户 user_id订单时间 order_time金额 amount SELECT user_id, order_id, amount, order_time FROM ( SELECT user_id, order_id, amount, order_time, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY order_time DESC) AS rn FROM dwd_order WHERE dt 2023-01-01 AND dt 2023-01-31 -- 分区裁剪必须带上 ) t WHERE t.rn 3;逻辑说明子查询里用窗口函数按用户分组、按时间倒序编号外层过滤前三。参数上dt分区裁剪是 Hive 和 Spark 都能下推的如果不带分区十亿行全表扫描直接翻车。另外ROW_NUMBER在数据倾斜时某个用户订单极多会拖慢单分区实际生产里我会先对user_id做盐化处理或者改用DISTRIBUTE BY user_id SORT BY order_time DESC加LIMIT的写法。面试时如果你能主动提数据倾斜和分区裁剪基本就甩开八成候选人了。2.2 Spark 调优三个必调参数和它们的代价Spark 开发岗面试调优是绕不过去的。面试官最爱问“你遇到过 OOM 吗怎么解决的”这题没有标准答案但有几个参数是必须知道的。我一般会从spark.sql.shuffle.partitions、spark.default.parallelism、spark.memory.fraction这三个入手。spark.sql.shuffle.partitions默认 200小数据量时任务启动开销大大数据量时单分区数据过多导致 OOM。我通常按shuffle 数据量 / 128MB估算再取 2 到 3 倍。比如 shuffle 写 50GB设 800 到 1200 比较稳。但调大不是没代价分区多了小文件就多HDFS NameNode 压力上来下游读取也慢。spark.default.parallelism控制 RDD 阶段的并行度默认是 executor 核数总和的两倍。如果 stage 里 task 数远小于这个值说明并行度不够CPU 利用率上不去。我一般会把它设成spark.sql.shuffle.partitions的 0.5 到 1 倍避免 shuffle 后 task 数骤降。spark.memory.fraction默认 0.6表示执行和存储内存占总堆的 60%。如果频繁 GC 或者 shuffle spill 严重可以提到 0.7 到 0.8但留给用户代码的内存就少了map里创建大对象容易 OOM。这个参数没有银弹我一般先看 Spark UI 的 Storage 和 Executor 页确认是执行内存不够还是存储内存不够再决定调不调。# 提交任务时的典型参数组合 spark-submit \ --master yarn \ --deploy-mode cluster \ --executor-memory 8g \ --executor-cores 4 \ --num-executors 50 \ --conf spark.sql.shuffle.partitions1000 \ --conf spark.default.parallelism800 \ --conf spark.memory.fraction0.7 \ --conf spark.sql.adaptive.enabledtrue \ --class com.example.MainJob \ app.jar注意spark.sql.adaptive.enabled在 Spark 3.x 默认开启它会自动合并小分区、处理倾斜 join但有些场景下反而让执行计划不稳定我一般会在压测时对比开和关的耗时再决定。参数说明executor-memory8g 是堆内实际容器内存还要加 10% 到 15% 的 overheadYARN 上不设spark.executor.memoryOverhead容易在 NodeManager 端被 kill。2.3 Flink 状态管理与 Checkpoint 的面试追问Flink 开发岗现在越来越热面试官常问“Checkpoint 超时怎么排查”。这题背后是状态后端、背压、Exactly-Once 三件事。我一般先看 Checkpoint 的 duration 和 size如果 size 突然涨说明状态膨胀可能是 key 设计不合理或者没设 TTL。如果 duration 长但 size 正常多半是背压导致 barrier 对齐慢。// Flink 状态 TTL 配置示例 StateTtlConfig ttlConfig StateTtlConfig .newBuilder(Time.days(7)) .setUpdateType(StateTtlConfig.UpdateType.OnCreateAndWrite) .setStateVisibility(StateTtlConfig.StateVisibility.NeverReturnExpired) .cleanupInRocksdbCompactFilter(1000) .build(); ValueStateDescriptorLong descriptor new ValueStateDescriptor(count, Long.class); descriptor.enableTimeToLive(ttlConfig);逻辑说明Time.days(7)是状态存活时间OnCreateAndWrite表示每次写入更新过期时间NeverReturnExpired保证不返回已过期数据。cleanupInRocksdbCompactFilter是 RocksDB 状态后端的清理策略每 1000 次 compaction 过滤一次过期数据。参数上TTL 设太短会丢历史状态设太长状态无限涨我一般按业务能容忍的回溯窗口来定比如风控场景 7 天实时大屏 1 天。面试时如果你能说出“RocksDB 的 compaction 会放大写延迟所以 TTL 清理要配合增量 Checkpoint”面试官基本会点头。3. 大数据运维与云计算故障排查与资源弹性的实战题3.1 YARN 队列卡死从现象到根因的排查路径运维岗面试最爱问“线上任务卡在 ACCEPTED 状态怎么办”。这题考的是对 YARN 调度器和资源池的理解。我一般按四步走先看 ResourceManager 的调度器类型Capacity 还是 Fair再看队列的usedCapacity和maxCapacity然后查是否有大任务占满资源最后看 NodeManager 是否失联。# 查看队列资源使用 yarn queue -status default # 查看应用状态 yarn application -list -appStates ACCEPTED # 查看节点状态 yarn node -list -states RUNNING逻辑说明yarn queue -status输出里usedCapacity接近 100% 说明队列满了maxCapacity是弹性上限如果usedCapacity超过maxCapacity说明配置有问题。yarn application -list看 ACCEPTED 的应用是不是在等 AM 容器如果是多半是yarn.scheduler.maximum-allocation-mb设太小大任务申请不到容器。yarn node -list看 RUNNING 节点数如果比预期少去 NodeManager 日志里搜Container killed或OutOfMemory。踩坑记录有一次队列卡死查了半天发现是某个任务把spark.executor.memory设成 64g而单节点总内存才 128gAM 申请不到资源一直等。解决方法是给队列设maximum-allocation-mb上限同时在提交脚本里加资源校验。面试时如果你能说出“ACCEPTED 卡住不一定是资源不够也可能是调度器配置的 maximum-allocation 限制”这题就答到点子上了。3.2 云计算存算分离对象存储替代 HDFS 的边界云计算方向面试常问“存算分离后HDFS 还有必要吗”。这题没有绝对答案但你要能说清楚对象存储和 HDFS 的差异。对象存储如 S3 兼容接口便宜、无限扩容但延迟高、不支持随机写、rename 是拷贝加删除。HDFS 延迟低、支持 append但扩容要加节点、运维成本高。我一般会按场景分离线批处理、冷数据归档用对象存储因为吞吐够、成本低实时计算、需要频繁 rename 的场景比如 Spark 写临时目录再 rename 到正式目录还是用 HDFS 或者本地 SSD 加缓存层。参数上对象存储的fs.s3a.connection.maximum默认 15高并发读时要调到 100 以上否则连接池打满报 timeout。fs.s3a.fast.upload开启后用小文件合并上传能减少 PUT 次数但内存占用会涨。!-- core-site.xml 中 S3A 的关键配置 -- property namefs.s3a.connection.maximum/name value200/value /property property namefs.s3a.fast.upload/name valuetrue/value /property property namefs.s3a.fast.upload.buffer/name valuedisk/value /property property namefs.s3a.block.size/name value128M/value /property逻辑说明connection.maximum控制 HTTP 连接池大小读多写少时调大fast.upload.buffer用 disk 避免堆内存溢出block.size影响并发读的粒度128M 和 HDFS 块大小对齐。注意对象存储的 rename 是拷贝加删除Spark 的_temporary目录如果和最终目录不在同一个桶rename 会变成跨桶拷贝耗时翻倍。我一般会强制临时目录和最终目录在同一个桶或者直接用DirectCommitter绕过 rename。3.3 数据治理元数据血缘的落地难点数据治理岗面试元数据血缘是必问的。面试官想知道你做过没有而不是听过没有。血缘分表级和字段级表级靠 SQL 解析字段级要靠 AST 分析。我一般用 Atlas 或者 DataHub 做采集但难点不在工具在 SQL 方言太多、动态 SQL 解析不了、临时表断链。-- 示例从 Hive 元数据里提取表级血缘的简化查询 SELECT t1.db_name AS source_db, t1.tbl_name AS source_table, t2.db_name AS target_db, t2.tbl_name AS target_table FROM (SELECT db_name, tbl_name, input_tables FROM lineage_meta WHERE dt 2023-06-01) t1 LATERAL VIEW explode(input_tables) tmp AS input_table JOIN lineage_meta t2 ON t1.input_table t2.tbl_name;逻辑说明这段 SQL 从血缘元数据表里展开输入表再关联目标表。实际生产中input_tables字段往往存的是 JSON 数组需要先用get_json_object解析。参数上dt分区按天存快照方便回溯。踩坑最多的是动态 SQL比如INSERT INTO ${table_name}这种解析器拿不到实际表名血缘就断了。我的做法是在调度系统里埋点把变量替换后的 SQL 也存一份解析时优先用替换后的版本。面试时如果你能说出“血缘断链的根因是动态 SQL 和临时表解法是调度层埋点加解析层兜底”这题就稳了。4. 大数据架构师选型、成本与一致性的权衡题4.1 Lambda 还是 Kappa架构面试的第一道分水岭架构师面试第一题往往是“你们公司用 Lambda 还是 Kappa”。这题考的是你对实时和离线统一的理解。Lambda 维护两套代码批处理保证准确性流处理保证时效性但代码重复、口径容易不一致。Kappa 只用流处理历史数据重放但流处理做复杂 join 和回溯成本高。我一般会按业务时效性和团队能力来选。如果业务能容忍 T1Lambda 更稳如果要求秒级且逻辑不复杂Kappa 更简洁。参数上Kappa 架构里 Kafka 的retention.ms要设足够长比如 7 天方便重放log.retention.bytes按磁盘容量算。Lambda 架构里 Hive 和 Kafka 的口径对齐要靠统一的 UDF 库否则同一个指标两个数。# Kafka 主题配置示例Kappa 架构重放依赖 cleanup.policy: delete retention.ms: 604800000 # 7 天 retention.bytes: 1099511627776 # 1TB segment.bytes: 1073741824 # 1GB逻辑说明retention.ms和retention.bytes同时生效谁先到删谁。segment.bytes影响重放时的并行度段太小文件多段太大重放慢。我一般按“重放窗口内数据量 / 分区数”估算段大小。注意 Kappa 架构下如果流处理逻辑改了重放历史数据要保证新逻辑兼容旧数据格式否则翻车。面试时如果你能说出“Kappa 的重放成本被低估了状态后端和 Kafka 保留策略要一起设计”面试官会认为你踩过坑。4.2 成本优化从资源利用率到存储分层架构师还要对成本负责。面试官常问“集群资源利用率低怎么优化”。我一般从三方面入手资源调度、存储分层、任务治理。资源调度上YARN 的DominantResourceCalculator比DefaultResourceCalculator更合理因为它同时考虑 CPU 和内存。存储分层上HDFS 的StoragePolicy可以把冷数据从 SSD 移到 HDD再移到对象存储。# 设置 HDFS 存储策略 hdfs storagepolicies -setStoragePolicy -path /warehouse/cold_data -policy COLD # 查看存储策略 hdfs storagepolicies -getStoragePolicy -path /warehouse/cold_data逻辑说明COLD策略表示数据只存一份且在归档存储上。WARM是 3 副本中的一份在 SSD其余在 HDD。HOT是全 SSD。参数上dfs.storage.policy.enabled要设为 true否则命令不生效。任务治理上我一般会跑一个离线分析找出连续 7 天没被访问的表自动打冷标签。注意存储策略变更后已有数据不会自动迁移要靠Mover工具触发。4.3 一致性取舍Exactly-Once 的代价架构师面试还会问“Exactly-Once 怎么实现代价是什么”。这题考的是你对分布式快照和事务的理解。Flink 的 Exactly-Once 靠 Checkpoint 和两阶段提交但代价是 Checkpoint 期间 barrier 对齐会阻塞吞吐下降。Kafka 的 Exactly-Once 靠事务和幂等生产者但事务超时和生产者 ID 管理复杂。我一般会按业务容忍度选金融场景必须 Exactly-Once用 Flink 加 Kafka 事务日志场景 At-Least-Once 加去重就够了。参数上Flink 的execution.checkpointing.mode设EXACTLY_ONCEexecution.checkpointing.timeout设 10 分钟execution.checkpointing.interval设 5 分钟。Kafka 的transaction.timeout.ms要大于 Checkpoint 间隔否则事务超时回滚。// Flink Kafka 生产者 Exactly-Once 配置 Properties props new Properties(); props.setProperty(transaction.timeout.ms, 900000); // 15 分钟 props.setProperty(enable.idempotence, true); props.setProperty(acks, all); FlinkKafkaProducerString producer new FlinkKafkaProducer( topic, new SimpleStringSchema(), props, FlinkKafkaProducer.Semantic.EXACTLY_ONCE );逻辑说明transaction.timeout.ms要大于 Checkpoint 间隔加最大延迟否则事务在 Checkpoint 完成前超时。enable.idempotence保证单分区不重复acksall保证所有副本确认。注意 Exactly-Once 只保证 Flink 内部和 Kafka 之间如果下游是 MySQL还要靠幂等写入或事务表。面试时如果你能说出“Exactly-Once 的瓶颈在 Checkpoint 对齐和事务超时不是所有场景都值得上”这题就答到架构层面了。5. 避坑与常见问题面试和实战里最容易翻车的五件事5.1 背题不背场景一问就露馅现象面试时问“Hive 数据倾斜怎么解决”候选人背出“加盐、调并行度、用 MapJoin”但追问“加盐后怎么保证结果正确”就卡住了。原因只记了结论没理解加盐后要二次聚合。解决每个方案都要能说出“为什么这样能解决、代价是什么、什么场景不适用”。我一般会准备两三个自己踩过的倾斜案例把 SQL 和参数都记清楚。5.2 参数照搬网上不看集群规模现象网上说spark.sql.shuffle.partitions设 2000直接抄到自己的小集群结果任务启动 2000 个 task调度开销比计算还大。原因参数和集群规模、数据量强相关。解决先算 shuffle 数据量再按每分区 128MB 到 256MB 估算最后用 Spark UI 验证 task 执行时间是否均匀。5.3 运维排查只看日志不看监控现象YARN 任务卡死只翻 ApplicationMaster 日志翻了半天没头绪。原因日志只记录应用内部资源层的问题在 ResourceManager 和 NodeManager 指标里。解决先看 Grafana 或 Prometheus 的队列资源、节点内存、磁盘 IO再定位到具体节点看日志。我一般会先跑yarn top看哪个队列在占资源。5.4 数据治理只上工具不改流程现象买了元数据管理平台血缘图很漂亮但开发还是乱建表血缘断链没人管。原因工具是辅助流程和规范才是根本。解决把元数据采集嵌到调度系统里建表必须走审批SQL 上线必须过解析。我一般会在调度平台加一个钩子SQL 提交前先解析血缘解析失败不允许上线。5.5 架构选型追新不看团队能力现象听说 Flink 好把所有离线任务迁到 Flink结果团队没人会调状态后端Checkpoint 天天失败。原因选型要考虑团队学习曲线和运维成本。解决新架构先小范围试点跑稳一个业务线再推广。我一般会按“业务价值 / 迁移成本”排序先迁时效性要求最高的再逐步替换。6. 面试复盘用一张表把知识域串起来面试复盘不是记题目而是记“哪个知识域答得好、哪个答得虚”。我一般会做一张表按岗位方向列知识域按掌握程度打分再针对低分项补实战。下面这张表是我自己用的复盘模板你可以直接抄。知识域开发岗权重运维岗权重云计算权重数据治理权重架构师权重我的评分SQL 与执行计划高中低中中8Spark 调优高中中低高7Flink 状态管理高低中低高6YARN 资源调度中高中低高7对象存储与存算分离低中高低高6元数据与血缘低低低高中5成本优化低中高低高6Exactly-Once 一致性中低中低高7填完表后我会挑评分低于 7 的知识域找一个小数据集跑一遍。比如 Flink 状态管理我会用本地 Kafka 加一个简单的计数任务故意让 Checkpoint 超时然后调execution.checkpointing.timeout和state.backend看效果。对象存储那块我会用 MinIO 搭一个 S3 兼容端点跑 Spark 读写观察fs.s3a.connection.maximum和fs.s3a.fast.upload对耗时的影响。最后说一个我自己的习惯每次面试完不管过没过当天晚上把被问住的题记下来第二天用最小可复现的方式跑一遍。跑不通的说明知识域有盲区跑通了但讲不清楚的说明表达有问题。这个习惯坚持了两年比背任何题库都管用。希望帮到你。本文还有配套的精品资源点击获取