分享社招面经——百度一面
一、基本信息
- 公司:百度
- 岗位:后端开发
- 轮次:一面
- 面试形式:远程视频
- 候选人背景:小米数仓+服务端开发,2024届华中农业大学本科
二、面试问题与回答
自我介绍与背景
- 问题:请做一下自我介绍
- 回答:华中农业大学2024届本科生,有金山云和浙江时空智子两段Java实习经历。2024年4月入职小米实习,7月正式入职。前一年做数仓开发(泊车业务),2025年10月转岗到众包项目组做服务端开发,主要战果是SDK全链路采集平台。技术栈包括Python、Java、Spark、Spring Boot、Redis等。
数仓重构项目
-
问题:数仓重构是几个人做的?花了多久?
-
回答:主要由我一个人主导负责,耗时约两个月(包含双跑验证两周)。
-
问题:合并四张表为一张表的依据是什么?
-
回答:四张DWM层主题表存在大量重复计算逻辑,都需要从ODS层track打点信号读取数据。将重复逻辑抽离成base表,后续表只需依赖base表,避免重复计算。同时在DWD层过滤掉80%无用数据(只保留车速<5km/h的最后一段泊车数据),大幅降低计算耗时。
-
问题:分区策略和索引是怎么设置的?
-
回答:主要分区是泊车功能类型和日期,使用Iceberg存储。索引主要在Doris层设置,针对省市区、功能类型等常规维度。数据经过聚合计算后量级在百万级,不需要复杂索引设计。
数仓全链路监控
- 问题:数仓全链路监控的核心指标和告警机制是怎么设计的?
- 回答:数仓链路监控分两块:一是作业链路监控(超时、失败情况),通过公司内部工厂平台配置;二是Doris指标监控(异常分析、空值判断)。报警阈值按业务设定,如核心泊车次数指标日波动超过50%就触发告警。
SDK全链路采集查询性能优化
- 问题:查询耗时从18秒降到7秒,除了并表还做了哪些优化?
- 回答:之前数据来自多个DWM主题表,存在数据口径不统一、需要在Doris层再次聚合计算等问题。通过构建一张DWS层应用层大宽表,把指标在DWM层就预先计算好,Doris直接查询大宽表,避免重复预计算,查询耗时从18秒降到7秒,维护成本(人效)也降低75%。
高并发场景与Redis分布式锁
-
问题:第二个项目(SDK调用全链路统计平台)涉及高并发吗?
-
回答:并发不高,主要是to B场景且单趟数量固定。高并发实践主要在浙江时空道宇实习期间的日报提交防重复场景,使用Redisson分布式锁,锁对象是员工id+当天日期。
-
问题:五层架构是怎么设计的?
-
回答:采集层(AOP/装饰器异步采集SDK调用)→ 缓存层(Redis list队列,每1000条批量写入)→ 持久层(PostgreSQL)→ 计算层(Spark同步到Iceberg)→ 可视化层(Doris看板)。重写线程池拒绝策略,把溢出请求写入本地日志做兜底,保证最终一致性。
Redis相关
-
问题:Redis分布式锁的实现?
-
回答:Redisson底层使用Lua脚本保证setnx和expire的原子性,通过看门狗守护线程在业务时间达到锁过期1/3时自动续期。除Redis外,Zookeeper临时节点也可实现分布式锁,通过监听上一节点判断锁释放。
-
问题:Redis过期键删除策略?
-
回答:惰性删除(访问时检查过期)+定期删除(随机抽样部分key)。这两种策略可能导致缓存雪崩(大量key同时过期)、缓存击穿(热点key失效)、缓存穿透(数据库与Redis都没有)。
-
问题:Redis持久化方式?
-
回答:这块不太熟悉,记得有RDB相关的机制把数据刷盘,具体细节模糊。
-
问题:Redis常用数据结构?
-
回答:string、list、hash、set、zset,以及bitmap、HyperLogLog等。
-
问题:Hash底层结构和冲突解决?
-
回答:底层用ziplist和hashtable(字典),冲突用链表法,链表过长时触发rehash(具体阈值不太记得,知道是因为链表过长影响性能时触发)。
-
问题:String底层结构?
-
回答:用SDS(简单动态字符串),不是C的char数组,通过结构体记录len等字段实现O(1)取长度。
其他基础知识
-
问题:OAuth 2.0核心流程?
-
回答:不太了解,模糊记得是先向OAuth服务器请求拿token,后续请求带token到header里去做认证,类似JWT机制。
-
问题:服务注册与发现的核心原理?
-
回答:以Zookeeper为例,从节点初始时向主节点发送注册请求,后续通过心跳机制保持存活,主节点也会定期询问各节点状态。
-
问题:MySQL事务隔离级别?
-
回答:读未提交、读已提交、可重复读、串行化。但项目主要用PG和Iceberg,MySQL业务知识不太熟悉。
-
问题:RocketMQ和Kafka区别?
-
回答:Kafka基于分区,通过offset推进数据;RocketMQ通过exchange等机制(回答不准确)。两者都支持10万级吞吐。公司用基于Kafka封装的Talos。
-
问题:消息队列如何保证消息不丢失/不重复?
-
回答:不丢失通过死信队列;消费端通过ACK确认避免重复(精确一次)。重复消费这块不太了解。
算法题
- 问题:数组中第K大的元素
- 回答:先用Arrays.sort排序,再取下标为n-k的元素。提到更优解可以用堆/快速排序的partition方式,但快排代码不太记得了。
反问
- 问题:候选人反问公司业务、团队方向
- 回答:面试官介绍是百度网盘相关,大团队做AI工程,智能化搜索、AIGC方向。
三、表现亮点
- 数仓重构项目讲解清晰:从问题(数据量增长导致作业超时)到方案(抽离base表+DWD层过滤80%数据+加盐打散解决数据倾斜)到结果(从2小时降到1小时内),逻辑链路完整。
- 主动结合业务场景做架构选型说明,如选Redis而非MQ的轻量化考量。
- 主动谈及对AI/RAG/Agent的探索(自动化制图方案),展现学习能力和技术热情。
- AI coding实践能力突出,熟悉多Agent协作开发模式(架构师/挑刺角色等)。
- 沟通节奏好,能识别面试官追问意图并补充关键细节。
四、不足与改进
- Redis持久化机制(RDB/AOF)知识盲区,只能模糊回答有"刷盘机制"。
- OAuth 2.0核心流程不熟悉,只能用JWT类比,无法说清authorization_code等具体流程。
- MySQL事务隔离级别只能列名词,无法详细解释每个级别解决的问题(脏读、不可重复读、幻读)。
- RocketMQ vs Kafka的核心区别表达不清,把Exchange概念错配给了RocketMQ(实际是RabbitMQ的概念)。
- 快速排序代码细节遗忘,算法题只能给出O(nlogn)的兜底解,没有写出O(n)的快速选择/堆解法。
- Redis哈希的rehash触发阈值(负载因子1/5)记不清。
