经营
10亿用户量,连续7天登录的用户标签该怎么打?前妻的车站剧情
2023-10-09 18:34  浏览:28

这是我的第33篇原创



今天来挑战一个炒鸡难题:10亿用户量,日均活跃用户1亿,那么,连续7天登录的用户标签该怎么打?

没有复杂的业务逻辑,没有频繁变化的需求,就是这么一个简单的需求,但是前提是恐怖的10亿级别的用户量和亿级别的日活,纯粹的海量数据,怎么解?

超级脑力爆发开始!

OK,Let's GO!

大数据工程师方案

团队里的大数据工程师立马跳出来:这个简单!distinct后inner join!是的,绝大多数人都会想到一种方法:从log的每天的分区表里捞7天内每一天当天所有的用户id,进行distinct之后,形成7个结果集,然后进行7天数据的inner join,结果就是连续7天活跃的用户。

大数据工程师花了10分钟,写好sql,立刻执行,然后等了2个小时,还没跑出来。。。

这个思路的优点是非常清晰明了。但是缺点也非常明显:每个结果集里的数据都是亿级,7个亿级数据join,效率可想而知。

所以我们必须优化。


高级大数据工程师方案

这时候需要请高级大数据工程师出场了。高级大数据工程师想了想,提了一个新思路:从log里提取每天的活跃用户单独存表,然后对每张表按统一的规则进行分桶后inner join。

他花了20分钟写了一个任务,把每天活跃的用户存在单表中,然后花了10分钟写了分桶join的sql,开始跑数据。

1个小时后,7天的数据进到7张活跃用户表中,15分钟后所有连续7天登录的用户数据被拉出来了。

我们保持join的思路不变,既然是海量数据的join,那么解决方案其实就已经昭然若揭了。hive的join优化绝招--“分桶”闪亮登场!

如上图所示,我们从log中将7天登录的用户id单独存表,其中只有user id,然后把7张表根据相同的规则进行分桶,这里为了理解方便用的是id区间规则,实际使用的过程可以先对数据进行采样,然后使用hash散列进行分桶。假设每天有1亿用户,分500w一桶,共分为200桶,这样一来,只需要在每桶之间进行inner join 最后合并结果即可,而不需要进7张大表的全表扫描 join,资源消耗自然小了很多,效率嗷嗷快~~~

但是在有中间表的前提下,还是有15分钟才能跑完。还能不能更快?


架构师版

15分钟把所有连续7天的用户id拉出来,其实还行,但是再加上打标签的工作,而且这个得每天都要跑一次,这就不太合适了。另外,运营同学还会有各种其他的骚需求,比如7天任意登录即可、连续30天登录才行,那得多费劲?怎么办?再继续优化!

原有的思路是inner join,虽然还可以在细节上优化,但是7个表的量级一致,貌似也没有更好的优化方法。那就只能换思路了。

思考:

  • N天连续登陆、N天只要登陆一次,实际上是一个“与”和“或”的N次简单逻辑运算;

  • 登陆、没登录,是一个状态位,可以用0、1表示;

  • 用户id的增长是序列增长的;


于是,架构师迅速锁定了方案:


  1. 将当天是否登录的情况用0、1表示;

  2. 然后把所有的用户登录状态按照固定的顺序排列起来,形成一张10亿级别的超大bitmap;

  3. 然后对整个bitmap进行 7天数据的“与”、“或”操作,得到一张新的bitmap;

  4. 然后按照这个bitmap,以及相应的顺序,直接给所有的user直接打上连续7天登录打标签;

架构师花了2个小时构思方案,然后扔给大数据工程师,又花了半天时间,把位图生成任务写好,花了5分钟写了位图操作的sql,最后只花了几分钟,就把所有用户的7天是否连续登录的结果算出来了,同时还可以满足运营的各种乱七八糟的标签的需求。完美!

总结

三个层次,层层递进。

虽然在每一层,都涉及了新的知识,但是我们细细咀嚼一下就知道不是这么简单。

大数据工程师版本的解决方案,写个大sql,在一个任务中进行每天活跃用户id的提取、去重、join的操作,简单是简单了,但是太粗暴了,再来一个需求,就又要重新再写,而且不能扩展,遇到连续30天这种需求,就得抓瞎了。这是乱拳打死老师傅。

高级大数据工程师的解决方案,加了中间表,进行了分桶操作。不要小看中间表这一步,这就可以应对更多更复杂的需求,比如连续10天、30天,只要中间表在,我们就能持续高效应对各种类似需求。这个中间表的设计起到了业务和数据解耦的作用,这是架构设计的雏形。这是功夫在手,战功赫赫。

架构师的解决方案,从计算的根本出发,直接进行计算,而不是用数据库的join操作得到结果,这才是架构最核心的价值--从底层规则构建解决方案。这是小李飞刀,一招致命,例无虚发!

小李飞刀剧照,应该没几个人看过了吧?


其实各个领域的高手到了最高深的境界,都能悟到这一点,就是底层规则决定上层应用。管理的底层规则是人性善恶;**的底层规则是为人民服务;PUA的底层逻辑是心理操控。


利用规则不是高手,创造一个规则才是神人!



往期精彩回顾



干货|架构师的视角看透中台底层规则 |论数据驱动业务的“力”热文|大数据工程师体系职业路径全解转发,点赞,在看,安排一下?

以上就是10亿用户量,连续7天登录的用户标签该怎么打?前妻的车站剧情的全部内容了,希望大家喜欢。

发表评论
0评