面试在精,不在多
蚂蚁面试就是不一样。
或者说大厂面试,跟其它面试就是不一样。
我们以往面试是不是1个小时,2个小时,有的甚至4个小时。
可是蚂蚁不一样,10分钟就搞定。
你以为只是蚂蚁这样吗,不。
腾讯,有的面试官也是这样,20分钟就搞定了。
那么短短十几分钟,是不是面试官对应聘者不感兴趣?
今年年初,我大连的朋友,为了准备腾讯面试,可以说是下了苦功夫,各种刷题,以及探讨该如何准备面试。还请教了在腾讯工作的同事,咨询了关于面试准备,以及如何拿到 offer 的相关建议。
可是这一轮,完全意料之外,简单20分钟就完事了,而且进入了下一轮的面试。
蚂蚁面试同样也是,面试不在于时间的长短,而是在于面试官关心的问题,我们是否都给了面试官想要的答案。
咱们又不是面试官肚子的蛔虫,怎么知道他想什么,关心什么。
所以这是最难的!
那怎么办?那么我们就需要借鉴别人的经验,化为自己的知识。
以我身边面试同学的实战经历,总结蚂蚁面试官,关心哪些问题。
这里给我们分享下,蚂蚁面试官关心哪些问题。(非常宝贵,值得收藏)
1.数据规模
比如咱们列举一个具体问题,你们的数据规模,大概有多少?
对于大厂来说,如果我们公司数据量小,是和工作不匹配的,所以数据量一定要跟上,至少TB级别,能达到PB级别更好。
数据增量来说,对于小公司,其实也就万级别的,但是和大厂匹配的话,最好是上亿级别。
这时候很多同学就不自信了,难!其实不止你难,都难,国内又有几个大厂,所以我们这时候就要多学习,多请教。
2.任务数量、任务是否稳定产出
离线任务和实时任务的数量,其实也反映了业务复杂度。所以这个数量,也比较关键。有的公司十几个,比如ETL任务,Flink实时,Spark实时,Hive离线,Spark离线等等。
任务如何保证稳定产出,有的是短信报警,有的是需要人工远程监控,也就是虽然下班了,但是轮班到我们,也需要家里远程监控任务,是否稳定输出。如果有bug,运行出错,要及时解决和重启任务。
像阿里大数据监控系统依托自动化工具和智能化技术,大多数情况下无需人工干预,但在复杂场景或紧急业务中,人工干预仍然是保障系统稳定的必要手段。
保证任务产出流程为,“自动监控 → 智能解决 → 人工介入 → 优化解决”。
3.数据治理
有的公司数据治理并不系统,比如在ETL阶段只是有数据的清洗,或者字段的补充和修复,并没有系统的数据治理。
所以如果我们只有小公司的数仓经验,想面试大厂,数据治理的经验是一定要补充的。
表现出自己的专业化和系统化。
我们要记住,面试并不止是工作经验的展现,而是能力的Show。
很多同学,以为只要有经验就可以,只有经验是不行的,还需要有突出能力的表现,比如突出解决问题能力,突出技术能力。
我们要知道公司不培养能力,需要我们有意识的锻炼自己,才能让自己在面试中脱颖而出。
4.调优
大厂是非常关心,因为他们的数据量确实大。所以被问到的概率是非常大的。
不止大厂关心,小公司也经常作为面试的门槛。
所以如果我们是做开发,必须会调优。
在面试中,如何让面试官觉得我们会调优。
有的朋友,只说几个参数、配置这是不行的。
最起码,我们要说出相关场景。
1.什么场景下遇到问题。
2.这个问题,怎么分析的。
3.分析后,尝试了哪些解决思路。
4.解决后的效果是什么。
这里举例仅供大家参考
1. 背景与问题场景
场景:
淘宝每日运行一份用户行为分析的 Hive SQL 报表,任务处理的主要数据包括:
用户点击日志(约 100 TB/天)。
商品销售数据(约 10 TB/天)。
运行 SQL 脚本用于生成用户购买转化率报表,处理时间原本约为 2 小时。
问题:随着业务增长,数据量快速上升,SQL 脚本运行时间飙升至 6 小时,严重影响后续业务的正常运行。
2. 问题分析
在问题发生后,采用以下方法逐步分析原因:
(1)监控任务执行阶段
通过 Hive 的 EXPLAIN 命令和 Yarn 资源监控平台,分析 SQL 的各阶段执行耗时:
Map 阶段耗时过长:数据量过大,导致 Map 阶段执行时间明显增加。
Join 阶段 Spill 到磁盘:部分 Join 操作中间结果溢出内存,频繁写入磁盘。
Reduce 阶段数据倾斜:某些 Key 数据量过大,导致 Reduce 任务时间延长。
(2)确认性能瓶颈
结合日志与性能监控工具,发现主要性能瓶颈:
数据分区未充分利用:日志表为分区表,但查询未过滤日期,导致全表扫描。
Join 数据量过大:直接 Join 两张大表,未提前过滤无关数据。
Reduce 阶段数据倾斜:某些用户 ID(热门用户)产生了超大数据量。
3. 解决思路与尝试
针对上述问题,逐步尝试以下调优策略:
(1)优化数据扫描范围
问题:未过滤分区,导致全表扫描。
解决:在 SQL 中加入分区过滤条件(如 WHERE log_date = '2024-11-25')。
确保分区字段已被 Hive 元数据正确识别。
(2)优化 Join 操作
问题:直接 Join 两张大表,导致数据量过大。
解决:
1.使用 Map Join:对一张小表(商品销售表)提前 Broadcast 到内存。
set hive.auto.convert.join=true;
对大表提前过滤无关数据后再 Join。
WITH filtered_logs AS (
SELECT * FROM user_logs WHERE log_date = '2024-11-25'
)
SELECT ...
FROM filtered_logs
JOIN sales_data
ON ...
(3)解决数据倾斜
问题:Reduce 阶段由于部分 Key(热门用户)导致数据倾斜。
解决:
1.随机打散热点 Key:通过新增随机数字段,打散热点 Key。
SELECT CONCAT(user_id, '_', RAND()) AS user_id_rand, ...
2. 使用 Hive 的 skewjoin 参数:
set hive.optimize.skewjoin=true;
(4)合理设置资源参数
问题:资源不足导致性能瓶颈。
解决:1.调整 Hive 执行参数:
set hive.exec.parallel=true; -- 开启并行执行
set hive.exec.reducers.bytes.per.reducer=256000000; -- 合理设置 Reducer 数
2.增加任务运行的内存和 CPU 配置。
4. 调优后的效果
经过上述优化,SQL 性能有显著提升:
执行时间从 6 小时缩短至 1.5 小时,满足业务需求。
资源消耗降低:减少了磁盘 I/O 和内存使用。
当然这些问题,不止蚂蚁关心,对于大厂来说,几乎是通用的,调优几乎是必问的。
我们可以换位思考,如果你是公司的领导,那么肯定想招聘一个,可以直接上手工作的员工,特别是社招。
对于大厂来说,由于数据量很大,所以需要理论上精通大数据调优,比如Hive调优,Flink调优等。
这里需要强调的是,有的同学为了让自己简历好看,获取更多的机会,所以就把各种组件调优,全部写上。
这是另外一种极端,是非常不可信的。我们在实际的工作中,能遇到一两个调优就不错了。简历上布满了调优,这是非常不切实际的。
所以我们不要以为调优写的越多越好,面试在精,不在多。多了,反而不可信。
另外2024年,受ChatGPT影响,面试发生了巨大的变化。
对于社招来说,不再是传统的先笔试后面试,而是先面试,然后现场再给一道编程题。所谓现场,就是面试官监考,需要屏幕共享。
所以我们想跳槽的话,一定要做好这方面的准备。
当然面试还有其它的变化,比如面试的难度,面试招人的规则等等,都发生了变化。
如果小伙伴比较关心的话,咱们下次再详细说。
最新经典文章,欢迎关注公众号
社区创作者介绍
2013年创办About云社区,成为大数据垂直领域NO1。2017年最早提出并发起系统帮助IT人面试和就业,帮助1万+Learner拿到offer,积累了大量的行业经验和资料。
2020年成立北京梭伦科技有限公司。2023年上线中文本Chat GPT智能星。通过智能星+面试提高我们面试、职场竞争力。
个人微信:w3aboutyun
|
|