字节安全风控数开实习一面凉经

针对简历的项目提问,
介绍一下mapreduce的过程,
spark的优势,
数据倾斜的解决方案,
数仓分层的好处,
介绍一下flink,
如何实现精准一次
sql题:现在有一张表存的是这两个字段,student_id, score 数据格式如下,lihua01,['math':98 english':87, chinese':99].
写一个hivesql实现查询每个学科排名第三名的同学

sql题:hivesql实现查询今日订单量是过去7日订单量均值的2倍的商家id

#牛客AI配图神器#
全部评论
校友啊,数开看看我们这里呀,我可以帮你tui
1 回复 分享
发布于 2025-04-16 17:14 天津
SELECT subject, student_id, score FROM ( SELECT student_id, subject, score, ROW_NUMBER() OVER (PARTITION BY subject ORDER BY score DESC) as rn FROM ( SELECT student_id, kv.key as subject, kv.value as score FROM student_score LATERAL VIEW explode(score) kv AS key, value ) t1 ) t2 WHERE rn = 3;
点赞 回复 分享
发布于 2025-07-07 15:57 北京
SELECT shop_id FROM ( SELECT shop_id, SUM(CASE WHEN order_date = CURRENT_DATE THEN 1 ELSE 0 END) AS today_cnt, SUM(CASE WHEN order_date >= date_sub(CURRENT_DATE, 7) AND order_date < CURRENT_DATE THEN 1 ELSE 0 END) / 7.0 AS avg_7_cnt FROM orders WHERE order_date >= date_sub(CURRENT_DATE, 7) -- 近7天及今天 AND order_date <= CURRENT_DATE GROUP BY shop_id ) t WHERE today_cnt >= 2 * avg_7_cnt ;
点赞 回复 分享
发布于 2025-07-07 15:57 北京
WITH -- 1. 统计今日订单量 today_orders AS ( SELECT shop_id, COUNT(*) AS today_cnt FROM orders WHERE order_date = CURRENT_DATE GROUP BY shop_id ), -- 2. 统计过去7天(不含今天)日均订单量 last7_orders AS ( SELECT shop_id, COUNT(*) / 7.0 AS avg_7_cnt FROM orders WHERE order_date >= date_sub(CURRENT_DATE, 7) AND order_date < CURRENT_DATE GROUP BY shop_id ) -- 3. 筛选今日订单量为过去7天均值2倍的商家 SELECT t.shop_id, t.today_cnt, l.avg_7_cnt FROM today_orders t JOIN last7_orders l ON t.shop_id = l.shop_id WHERE t.today_cnt >= 2 * l.avg_7_cnt ;
点赞 回复 分享
发布于 2025-07-07 15:56 北京

相关推荐

03-20 11:09
已编辑
中国地质大学(北京) Java
面试官你好,我叫汪明海,目前是中国地质大学(北京)计算机技术专业硕士在读,本科是电子信息工程专业,研究生期间&nbsp;GPA&nbsp;3.7,专业排名前10%。我主要专注于&nbsp;Java&nbsp;后端开发方向,具备扎实的基础和一定的高并发系统实践经验。在百度有一段接近一年的后端开发实习经历,期间作为模块负责人参与了一个高并发图生视频系统的开发。这个系统日活大约10万,轮询峰值达到7000&nbsp;QPS。在这个项目中,我主要做了几件比较有价值的事情:架构权衡选择缓存来解决高qps的问题对大表进行分表解决海量数据问题对用户上传图片去重降低存储成本同时解决线上问题和完善监控保证系统稳定除此之外,我还独立设计并实现过一个电商交易系统,完整覆盖用户、订单、库存、支付等核心链路。在这个项目中重点解决了分布式场景下的库存超卖、接口幂等、订单状态一致性等问题,比如通过分布式锁&nbsp;+&nbsp;乐观锁&nbsp;+&nbsp;RabbitMQ&nbsp;实现库存控制和延迟关单。技术上我比较熟悉&nbsp;Java、Spring&nbsp;Boot、MySQL、Redis,也有一定的分布式系统和高并发处理经验。我个人做事比较踏实,执行力强,也比较喜欢深入分析问题和做系统优化。希望能在后端方向继续深入发展,参与更大规模系统的设计和优化。围绕项目,无八股算法部署服务的方式pod&nbsp;最大多少个:高峰期7k&nbsp;QPS:&nbsp;20到30个&nbsp;Pod每个pod占用的资源:API&nbsp;查询和任务消费/回调合并在一个&nbsp;Pod&nbsp;内,这类&nbsp;Pod&nbsp;既有高并发读流量,又有异步写和状态更新,也就是2C4G&nbsp;request,4C8G&nbsp;limit。分表的分页表怎么做有没有更好的方案&nbsp;&nbsp;从产品思维:根据用户会员等级,限制用户查询的数量。加入缓存遇到了哪些问题:数据的不一致性问题,具体来说,当回调主动更改缓存任务状态时,有可能更改失败,因为mysql和redis的更新不在一个事务内,这个时候ttl就发挥了作用,视频生成的平均时长是2到3分钟,ttl设置为3分钟,当任务过期就被清楚,从数据库取出最新的数据,保证了redis和缓存的一致性消费者怎么回调:消费者回调通过rpc的方式回调我们的服务,传入状态和视频结果等信息,我们的服务去更新数据库和缓存服务之间调用的输入输出&nbsp;&nbsp;用了&nbsp;rpc&nbsp;的什么协议调用的:百度内部常见的&nbsp;RPC&nbsp;框架是&nbsp;brpc。它底层一般跑在&nbsp;TCP&nbsp;之上,消息序列化常用&nbsp;protobuf;协议层不是只有一种,百度内部常见有&nbsp;baidu_std&nbsp;等私有协议,brpc&nbsp;同时也兼容&nbsp;HTTP、gRPC、Thrift&nbsp;等多种协议。HTTP&nbsp;协议通常把数据组织成请求报文和响应报文。无论请求还是响应,整体结构都是请求行、头部、空行和消息体。起始行用来说明请求方法、路径、版本,或者响应状态码;头部用&nbsp;key-value&nbsp;的形式描述元信息,比如内容类型、长度、认证信息;空行用来分隔头部和消息体;消息体里才是真正的业务数据,比如&nbsp;JSON、表单或者二进制文件。因为底层&nbsp;TCP&nbsp;是字节流,没有消息边界,所以&nbsp;HTTP&nbsp;还会通过&nbsp;Content-Length&nbsp;或&nbsp;chunked&nbsp;机制来标识消息体长度。rpc和http的区别我的理解是,HTTP&nbsp;和&nbsp;RPC&nbsp;的核心区别在于抽象层次不同。HTTP&nbsp;是一种通用的应用层通信协议,通常是面向&nbsp;URL&nbsp;和资源来设计接口;而&nbsp;RPC&nbsp;是一种远程调用模型,目标是让调用远程服务像调用本地方法一样。在使用场景上,HTTP&nbsp;更适合前后端交互和对外开放接口,因为标准统一、通用性强;RPC&nbsp;更适合内部微服务调用,因为通常会结合二进制序列化、长连接和服务治理能力,在性能和调用效率上更有优势。不过两者不是完全对立的,因为&nbsp;RPC&nbsp;也可以基于&nbsp;HTTP&nbsp;来实现,比如&nbsp;gRPC&nbsp;就是基于&nbsp;HTTP/2。在这个项目中的一些不足和经验我觉得这个项目有两个比较明显的不足。第一,前期方案选型时,我们基于当时的成本、风险和收益考虑,选择了缓存方案,这个决策在当时是合理的,能快速支撑业务上线。但后面随着流量增长,我发现轮询查缓存的方式扩展性有限,后续更适合往服务端主动推送的方向演进。这个经历让我意识到,技术方案要结合业务阶段做取舍,也要提前考虑后续架构升级路径。第二,项目里对慢&nbsp;SQL&nbsp;的监控还不够完善,缺少及时报警机制。这样会导致数据库性能问题不能第一时间暴露。后来我复盘时觉得,除了完成功能,线上监控和告警体系也非常重要,尤其是慢&nbsp;SQL、接口耗时和错误率这类指标,应该尽早纳入日常治理。所以这个项目最大的收获是,我现在做项目不只关注功能实现,还会更关注方案演进能力,以及系统上线后的监控和稳定性建设未来技术规划我对未来的职业规划,现阶段还是希望先立足于技术成长。短期内,我希望先把基础打扎实,不只是把功能做出来,而是真正理解业务,提升自己在代码质量、系统设计、问题排查和工程规范上的能力。中期的话,我希望能参与更有挑战性的项目,比如高并发场景、微服务架构、性能优化这类方向。因为我觉得这些场景能更快锻炼一个工程师的技术深度和系统性思维。长期来看,我希望自己不仅能解决具体技术问题,也能独立负责一个模块,能够把业务理解和技术实现结合起来,做一个既懂技术、也能真正支撑业务发展的工程师。如何看待和应对项目中期进度不理想、需要赶工的情况?这个问题重点是:态度&nbsp;+&nbsp;方法论可以这样回答:我觉得这种情况在项目中是比较常见的,关键是如何理性应对,而不是盲目加班。我一般会从几个方面处理:①&nbsp;先分析原因是需求变更?技术难度被低估?还是沟通问题?②&nbsp;优先级重排区分核心功能&nbsp;vs&nbsp;非核心功能必要时做取舍(保证主线)③&nbsp;提升执行效率拆任务,减少阻塞提前沟通依赖问题合理利用工具(包括&nbsp;AI)④&nbsp;主动沟通及时同步风险和负责人一起调整计划⑤&nbsp;对赶工的态度我可以接受阶段性加班,但不提倡长期透支,更重要的是通过复盘避免以后再次出现类似问题。
查看12道真题和解析
点赞 评论 收藏
分享
评论
1
15
分享

创作者周榜

更多
正在热议
更多
牛客网
牛客网在线编程
牛客网题解
牛客企业服务