一道有趣的sql题目

嗨，牛友们！潜水很久了，今天上来冒个泡，跟大家分享一下我这个菜鸟拿到滴滴 Java Offer 的心路历程，希望能给跟我一样基础比较薄弱的兄弟姐妹们一点鼓励！先说说我的背景吧，真的是普通到不能再普通了。 本科普通双非的计科专业，大学四年也没好好卷， 算法 contest 没参加过，项目经验也就做过一些课设和简单的外包，八股文背起来也是稀里糊涂的。 秋招那会儿，雄心壮志投了一堆简历，结果大家都懂的，颗粒无收，简历石沉大海，面试机会寥寥无几，更别说 Offer 了。 当时真的觉得自己是不是不适合干这行，怀疑人生都来了。痛定思痛，秋招失败后就开始反思自己，知道自己八股文不行，项目经历也不够亮眼。 春...

想找寒假实习 全都是已读不回 投了半个月了 #寒假躺平还是提前实习#

😭简历求拷打😭😭😭😭听劝这样的简历春招还有机会上岸中厂吗🤡编程技能的话大概就每个了解到50%吧复习一下能捡到70%应该太久没背了属于是每个知识点可以唠个5分钟，再深入就不会了后面两个分别是gpt和kimi的#投了多少份简历才上岸# #你的简历改到第几版了# #你已经投递多少份简历了# #春招# 引流用 #字节# #腾讯# #阿里#

这是之前在处理一个实时流数据上碰到的。 之前背过很多，类似的关于高并发问题的一些官样文章。初读起来，总感觉索然无味。好像和幼儿园里把大象放进冰箱里的故事一样。 在业务中碰到的情况很特别。 同一个用户，会在同一个时间点有多条订单，即使把时间精确到 00:00:00，依然发现无法区分。前辈提醒后，才发现这其实是一种高并发的情况。 在Flink实时流里，通常碰到高并发的情况下，会进行一次打乱操作。在SQL任务中，我忘记进行了这种操作，后来发现其实是有这样的key by 参数。 大约可以这样处理。 在处理的时候，通过key by 的操作，会将并发数据存储同一个kaf...