2025年「面试」大数据面试题及答案.docxVIP

2025年「面试」大数据面试题及答案

1.请描述HadoopHDFS的写入流程，并说明副本放置策略的优化逻辑。

HDFS写入流程：客户端通过FileSystem接口调用create方法，向NameNode发送创建文件请求；NameNode检查文件是否存在、权限是否合法，确认后返回DataNode列表（通常为3个副本）；客户端将文件分块（默认128MB），通过Pipeline机制将第一个块的数据包发送到第一个DataNode，该节点存储后转发到第二个，依此类推；每个DataNode接收数据后返回确认，形成反向确认链，客户端收到所有确认后继续发送下一个块；所有块写入完成后，客户端通知NameNode提交文件，NameNode更新元数据（此时文件才可见）。

副本放置策略优化：HDFS默认采用机架感知策略，第一个副本在客户端所在节点（若客户端不在集群则随机选），第二个副本在另一机架的随机节点，第三个副本与第二个同机架但不同节点。优化时可根据业务场景调整，如冷数据（日志）可设为2副本减少存储，热数据（实时计算中间结果）设为3副本保障可用性；对大文件（如TB级）可通过dfs.replication.consider.pinning参数将副本固定在高性能节点，降低跨机架传输延迟；生产环境中可结合容量感知策略（dfs.datanode.available-space-volume.choosing.policy），优先选择可用空间大的节点，避免部分节点磁盘爆满导致写入失败。

2.简述SparkRDD、DataFrame、Dataset的核心区别及选择依据。

RDD（弹性分布式数据集）是Spark1.0的核心抽象，以不可变、可分区的JVM对象集合形式存在，支持丰富的转换（map、reduce）和动作（collect、count）操作，提供细粒度的控制（如自定义分区器），但缺乏结构化信息，执行时需通过闭包序列化反序列化JVM对象，性能较低且无法利用Catalyst优化器的逻辑计划优化。

DataFrame是带Schema的分布式数据集，本质是RDD[Row]+Schema信息，通过Catalyst优化器将SQL转换为物理执行计划（如列裁剪、谓词下推），支持类似关系数据库的操作（groupby、join），序列化时使用二进制格式（如UnsafeRow），减少内存占用和GC压力。

Dataset是DataFrame的强类型版本（Dataset[T]），结合了RDD的类型安全和DataFrame的结构化优化，通过Encoder将JVM对象转换为二进制格式（如Kryo或Spark内置编码器），支持lambda表达式操作（filter、map），同时保留Catalyst的优化能力。

选择依据：需类型安全且需精细控制数据处理时选RDD（如复杂的图计算）；处理结构化数据（日志、业务表）且需高性能SQL支持时选DataFrame；需类型安全+SQL优化（如ETL中同时使用lambda和SQL）时选Dataset（如Spark2.0+的通用处理场景）。

3.如何定位Flink作业中的状态泄漏问题？请给出具体排查步骤和修复方案。

定位步骤：

（1）监控指标：通过FlinkWebUI查看各算子的状态大小（StateSize）和检查点（Checkpoint）大小，若状态持续增长且无明显业务增长驱动（如窗口未正确清理），可能存在泄漏。

（2）日志分析：开启DEBUG日志（perties中设置org.apache.flink=DEBUG），观察Checkpoint完成时的状态句柄（StateHandle）是否包含未释放的对象；检查是否有“StateBackendisnotabletoserializestate”等异常，可能因状态中包含不可序列化的对象（如外部连接）导致重复创建。

（3）堆内存分析：使用jmap或JProfiler对TaskManager进程提供堆转储文件，通过MAT（MemoryAnalyzerTool）分析大对象，定位是否有算子状态（如ValueState、ListState）未被清理。

（4）状态TTL检查：确认是否为状态设置了TTL（StateTtlConfig），未设置时历史状态可能永久保留；检查TTL更新类型（OnCreateAndWrite/OnReadAndWrite）是否与业务场景匹配（如仅写入时更新可能导致读取旧数据未触发清理）。

修复方案：

（1）清理超时状态：对基于时间窗口的状态（如EventTime窗口），确保使用了正确的触发机制（如EventTime+Watermark），并在窗口关闭后调用WindowFunction的clea