企业官网建设流程全解析

简介：这份资源是面向大数据开发、大数据运维、云计算、数据治理及大数据架构师岗位的面试题合集，适合准备跳槽或系统梳理知识体系的初中高级从业者。内容围绕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.partitions=1000 \ --conf spark.default.parallelism=800 \ --conf spark.memory.fraction=0.7 \ --conf spark.sql.adaptive.enabled=true \ --class com.example.MainJob \ app.jar

注意spark.sql.adaptive.enabled在 Spark 3.x 默认开启，它会自动合并小分区、处理倾斜 join，但有些场景下反而让执行计划不稳定，我一般会在压测时对比开和关的耗时再决定。参数说明：executor-memory8g 是堆内，实际容器内存还要加 10% 到 15% 的 overhead，YARN 上不设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(); ValueStateDescriptor<Long> 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，而单节点总内存才 128g，AM 申请不到资源一直等。解决方法是给队列设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> <name>fs.s3a.connection.maximum</name> <value>200</value> </property> <property> <name>fs.s3a.fast.upload</name> <value>true</value> </property> <property> <name>fs.s3a.fast.upload.buffer</name> <value>disk</value> </property> <property> <name>fs.s3a.block.size</name> <value>128M</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 和回溯成本高。

我一般会按业务时效性和团队能力来选。如果业务能容忍 T+1，Lambda 更稳；如果要求秒级且逻辑不复杂，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_ONCE，execution.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"); FlinkKafkaProducer<String> producer = new FlinkKafkaProducer<>( "topic", new SimpleStringSchema(), props, FlinkKafkaProducer.Semantic.EXACTLY_ONCE );

逻辑说明：transaction.timeout.ms要大于 Checkpoint 间隔加最大延迟，否则事务在 Checkpoint 完成前超时。enable.idempotence保证单分区不重复，acks=all保证所有副本确认。注意 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. 面试复盘：用一张表把知识域串起来

面试复盘不是记题目，而是记“哪个知识域答得好、哪个答得虚”。我一般会做一张表，按岗位方向列知识域，按掌握程度打分，再针对低分项补实战。下面这张表是我自己用的复盘模板，你可以直接抄。

填完表后，我会挑评分低于 7 的知识域，找一个小数据集跑一遍。比如 Flink 状态管理，我会用本地 Kafka 加一个简单的计数任务，故意让 Checkpoint 超时，然后调execution.checkpointing.timeout和state.backend看效果。对象存储那块，我会用 MinIO 搭一个 S3 兼容端点，跑 Spark 读写，观察fs.s3a.connection.maximum和fs.s3a.fast.upload对耗时的影响。

最后说一个我自己的习惯：每次面试完，不管过没过，当天晚上把被问住的题记下来，第二天用最小可复现的方式跑一遍。跑不通的，说明知识域有盲区；跑通了但讲不清楚的，说明表达有问题。这个习惯坚持了两年，比背任何题库都管用。希望帮到你。

本文还有配套的精品资源，点击获取