数据开发面试经验

1、如果业务方需要实时查看网站的每分钟PV/UV，你会如何设计技术方案？

我会设计一个流式计算方案。前端埋点日志通过Kafka实时收集。对于PV，使用Flink进行滚动窗口计数，结果可写入Redis供前端查询。对于UV，难点在于去重。如果数据量极大，可以使用Flink的HyperLogLog进行近似计算，平衡精度和资源；如果要求精确，可利用Flink状态后端存储窗口内的用户ID集合，但资源消耗较大。最终结果可写入ClickHouse或Doris，支撑高并发查询。

2、某张核心Hive表，早上的定时任务产出数据量突然比往常少了30%，你如何排查？

我会按数据流向进行层层排查：1. 检查任务本身：查看任务日志是否有报错，是否因资源问题导致部分数据未处理。2. 检查上游依赖：确认该任务的所有上游表和数据分区是否已正常产出、数据量是否正常。3. 检查数据源：确认源头业务数据库或日志文件是否发生了异常变更，例如字段缺失、采集异常。4. 检查业务逻辑：确认ETL代码中的过滤条件、Join逻辑是否被意外修改。这是一个系统性的血缘追溯和对比分析过程。

3、请介绍一个你最满意的数据项目，并说明你的贡献、遇到的挑战和如何解决的。

简短背景。如：为支持精准营销，需要构建用户标签系统。

你的具体任务。如：我负责设计并开发‘消费能力’与‘兴趣偏好’两大标签体系的数据管道。

你的核心、行动。这是重点，要技术化。如：在计算兴趣偏好时，面临用户行为稀疏性挑战。我采用了TF-IDF思想进行行为权重衰减，并引入协同过滤补全部分数据。开发上，使用Spark GraphX处理用户-物品关系图。

量化成果。如：项目上线后，生成了XX个标签，赋能了Y个营销场景，使活动点击率提升了Z%。

4、如果业务方坚持认为你提供的数据结果不对，但你的检查显示任务运行正常，你会如何处理？

首先，绝不假设对方是错的。我会：1. 对齐口径：和业务方一起确认指标的业务定义、统计口径和时间范围是否完全一致。2. 数据回溯：提供从原始数据到最终结果的关键中间步骤数据，请业务方共同复核。3. 交叉验证：尝试用另一种计算逻辑或数据源进行佐证。核心是建立共同排查的协作氛围，而非技术对峙，目标是共同找到差异根源。