大数据工程师面试中，技术栈的熟练度并非最高频考点，真正让候选人卡壳的往往是业务场景与数据架构的匹配问题。根据2024年拉勾网对300家互联网公司的面试题统计，以下三个问题出现率超过70%，且平均正确率不足40%。

1. 实时计算延迟到底该压到多低才算合格？

多数人脱口而出“毫秒级”，但实际场景中这个答案可能直接导致成本失控。以电商大屏实时GMV为例，业务方容忍的刷新间隔是5秒，而风控系统要求的是500毫秒内完成规则匹配。某生鲜平台曾盲目追求100毫秒延迟，引入Flink+Redis+Kafka整套组合，结果每月额外支出12万元集群费用，最终发现业务方实际需求是3秒更新一次。正确做法：先测量业务决策链的响应阈值，比如客服系统仅需2秒内展示用户历史订单，而推荐系统可以接受30秒的模型更新延迟。

2. 数据湖和数据仓库在存储格式上到底差在哪？

很多人面试时背概念说“数据湖存原始格式，数据仓库存列式格式”，但落地时往往混淆。某教育公司在做学生行为分析时，用Parquet格式存储所有日志到数据湖，结果查询某学生上周做题记录需要扫描300GB数据。后来改用Hudi的MOR格式，保留原始JSON的同时建立增量索引，相同查询仅扫描2.3MB。关键区别在于：数据湖的存储格式必须支持ACID事务和增量更新，而数据仓库的格式更侧重查询压缩比。如果只是纯存日志且无修改需求，直接塞ORC格式反而更高效。

3. 数据倾斜真的靠加机器就能解决吗？

某打车平台曾用200台节点跑订单聚合任务，但某省司机接单数据占比42%，导致整个Stage等待该分区完成。加节点后反而因为网络开销增加，耗时从3小时升到4.5小时。实际解法：先看倾斜键的业务含义，像地域、商品ID这类天然热点，用两阶段聚合更有效——先按用户ID加盐拆分为随机子分区，局部聚合后再二次汇总。如果倾斜键是空值，则需要过滤或填充默认值，而非单纯调大spark.sql.shuffle.partitions参数。

最常踩的3个误区：

• 误区一：盲目追求“全链路实时”。实际上业务中80%的场景可以接受5分钟延迟，用Spark Streaming微批次比纯流计算节省70%运维成本。
• 误区二：认为数据湖可以存一切。流式写入小文件导致NameNode内存暴涨，必须在写入时做文件合并，否则500GB数据可能产生10万个碎片文件。
• 误区三：用Hive的静态分区策略处理动态数据。按天分区时如果某天数据量突增10倍，需要提前开启动态分区裁剪，否则查询会扫描无关分区，比全表扫描更慢。