00:00
好,那么接下来呢,我们来看第九个需求,这是一直我们念叨的一个需求,对吧?啊,包括大家呢,可能也挺向往的一个需求,因为虽然比较难,但是越难的东西可能才才会能够掌握更多的一些知识点。对吧,啊,因为它里边呃,使用的技巧啊,或者说用到的知识点啊,都会比较多一些嘛,对吧?呃,那这个需求呢,我们看一下啊,叫用户。PU力度下单各窗口汇总表。诶。用户PU力度,也就是说它里面有两个维度。对吧,还是一样的要求下单啊,但是呢,我们要用到用户和这个PU。这两个力度。对吧?啊,关键的在于什么呢?这个PU最关键的是PU,因为用户呢倒还好,如果说你只是采用这个用户ID对吧,那本身我们的订单表里边确实就有这个用户ID,但是订单表里边儿有没有PU啊。
01:07
这个大家知道吗?啊,或者说不清楚的,我们一块儿来看一下对吧啊。那也就是说,从这个需求的名字大家就能看出来,终于,终于要到我们做什么事了。好,对吧,我们先来看一下搂一下啊呃,他要下单对吧,下单的话呢,我们主要找这个out in for跟all detail对吧?呃,All detail tell打开啊,这是all tell,然后呢,我们再打开这个all in for。好,那我们看一下奥林four里边呢,它确实有这个UD。对吧,他本来就有这个U在这个倒还好,对吧?呃,当然如果说。你呢?这个用户力度对吧,用户这个维度,你不想用用户ID,你要想用这个性别。对吧,或者年龄这样的指标。
02:00
诶,那我就没有了。啊,我就没有了,如果说啊,这个具体的需求我们等会再去分析对吧?啊但是呢,它确实有这个u zd的啊呃,没了SPD没有,这里边不可能有SPD,因为它呢是整个的一个订单,All里面不会涉及到具体商品的信息,对吧,那我们看all detail all detail呢,它你看啊呃,一个all的ID,诶那918091809180对应的四条对吧,因为他一个订单呢,对于四个明细嘛,这很正常对吧,前四条啊,那么他呢,有这个SKID,诶分别买了四个不同的商品。对吧,啊,四个不同的一个商品,这个也没有问题啊啊那么SQ name也有了,对吧?商品的名称,嗯,然后呢,价格啊number对吧,SQ number创业时间到底是怎么来的对吧?是广告还是正常的去发现的啊然后呢,金额,哎后面呢都是几个金额了,没什么了。也就是说,我们整个两张表里边儿都没有看到谁。
03:01
叫这个。PU。对吧,我们整个都没有看到这个PU。那怎么办?我只有SKU,我没有SPU,那怎么办?是不是很明显,当前这个需求我们要做一件很核心的事情,就是说下单实时表,对吧,而我们的用户还有这个SPU,它属于维表,很明显我们要呢,拿着事实表去关联维表了吧,诶,终于到DWS层,我们最后这几个需求呢,就是这样设计的,对吧?呃,有很多需求呢,我们要用到这个实时表去关联维表才能够完成,对吧?因为就这里边呢要去关联。为表。啊,要去关联维表对吧,所以整个的我们来看一下啊,我们要做的事情对吧?首先那消费这个订单明细就是下单主题数据这个没有问题啊,然后接下来呢,呃,过滤档值数据这个呢,我们写data stream那个API。
04:02
Flink consumer卡夫卡的consumer的就就写过了,对吧,然后呢,按照违建对数据去动,因为一定要去动,为什么呢?因为后续呢,我们要求这个订单数和订单金额。我们要求订单金额,既然要求订单金额的话,那么。你就知道了。对吧,你就知道了,那肯定要怎么样。去重啊,你要不去重那不完了吗?对吧,他不是说要求一个什么用户数对吧,不是这种啊,不是像那个支付那个支付那个需求呢,你可以去重,也可以不去重,这个都无所谓啊,那么这个地方呢,我们求订单金额,那是一定要做去重的。啊,而且我们知道订单金额这个东西呢,你可以。不从这个什么,呃,订单明细。购物券或者订单明细。这个活动表里边去拿,也就是说这个驱动方案呢,我们还可以复用第八个需求的驱动方案,对吧,直接保留第一条啊,因为你去传方案里边选一个嘛,都可以对吧?啊,那之后呢,我们最后将数据要提交出去,当然了在这边要根据维度去开窗聚合。
05:14
对吧,啊,但是呢,维度我们肯定要关联啊,要关联维度信息,所以这里边儿最难的一个操作就在这。你懂吧,就是这个东西比较复杂啊好,那这个关于工具类,我们到时候再聊啊,我们现在不看这个事儿对吧?啊。呃,这是工具类的一个方法,怎么写的啊,到时候我们再说啊,这是优化,我们就不聊了,我们直接看这个建表语句,看一下我们里边要放什么字段,好吧,嗯,首先是这样的。哎,这里边呢,我们首先这两个。没什么好说的。对吧?啊,没什么好说的,那么接下来呢,我们还放了什么呢?除了PU之外。因为我们有用户PU力度,那未来有没有可能有用户trademark啊,用户这个品类对吧?啊有用户品牌用户品类用户IPU都有可能吧,那我们呢,把商品相关的信息是不是都可以放在一块儿了。
06:14
对吧,啊,甚至啊,你可以把原来的SKU。ID跟SQL都保留下来。也可以。对吧,都保留下来,因为这样的话力度更细一点,未来呢,你算任何指标都可以。啊,三任务指标就比较方便了。啊都比较方便了啊好,那我们看一下这里边呢,呃,开装时间啊,然后呢,Trademark开这123加哎,Use ID对吧,用户力度啊在这,然后呢PU相关的,然后呢求两个东西,一个all count,一个all amount。对吧,订单的数量,订单的总金额。OK吧,订单的总金额,那么还是一样的,按照这个内容来啊,那主要的在于呢,就是我们为什么要提前看一下这个金标语句啊,因为我们不光要去关联刚才我们所知道的,那这个需求呢,肯定要关联这个PU。
07:09
对吧,要把SKU拿到,那就是拿SKUID去关联,你看啊在这边。呃,找到sko对吧,拿着SQID去关联这个ID,然后找到SQID。对吧,找到PU啊,找到PU以后呢,你可以再去关联puo,去补上它的一个s PU name。对吧,补上它的s SP name,同理,在关联SQ four的时候呢,这里面还有什么呢?Trademark ID以及category的ID,对吧?你都可以关联上,然后接下来呢,你可以去关联我们的trademark这张表,哎,把trademark name放进来,对吧?同时拿着CATEGORY3去关联这张表啊,然后呢,取name,取二的ID,接下来再关联二,取name,对吧,取一的ID,然后最后关联一取name,那这样的话,咱们的字段就全了。
08:05
也就是说这里面呢,我们至少要关联几张为表,一个SKU,首先关联对吧,取谁呢?取SPU。Trademark以及CATEGORY3的ID,然后拿着这个东西去关联po表,对吧,这是第二张,拿着这个东西呢,关联trademark表,拿着CATEG3呢,拿。三对吧,同时取二的ID啊,然后拿着这个关联二同时取一的ID,然后拿着它去取一对吧,那1234566张表。对吧,也就是在这里边儿呢,我们要去关联六张。为表。啊,要去关联六张为表。对吧?啊,要求关联六辆为表啊,这个是我们最复杂的操作就在这儿啊,那用户呢,因为我们当然你可以设计需求啊,说未来呢,我想看一下这个用户的年龄,年龄段它的一个占比,对吧?呃,或者说呢,看一下用户的这个性别。
09:12
对于下单的一个占比情况,就类似于Spark streaming,我们写过的那个案例,对吧,那你也去关联一下用户信息,把这个用户的。年龄。对吧,把这个用户的性别把它拿过来,或者用户的其他的一些信息拿过来,那可不可以啊,也可以啊,对吧,这个意思啊,就是说呢,你要是不想做这事,你就放用户ID就好了,你要是想做,那你也可以去关联,那就无非就多关联一张尾表嘛,那其实这个需求呢,我们说关联六张尾表。只要你会关联一张,那六张是不是就通了。没毛病吧,你再多加一些无非就代码了。稍微复杂一点啊,你主要就根据需求来,如果你需求确实需要你工作的时候啊,那你就关联呗,你会关联一张,你跟关联两张三张四张,五张六张还有什么区别吗。
10:03
那不都一样的吗?无非就是说把这个代码再写一写,大不了封装一个工具类,对吧,反复的调用呗,你关联不同的表我就传,传不同的表明你要不同的字段,那我就传不同的字段呗,对吧?因为你每张表要的字段可能不太一样。能理解这个意思吗?所以这个需求最核心的点在于什么呢?就是关联为表。OK吗?这个能明白啊。最难的也是这个操作啊,最难的也是这个关联维表的一个操作,OK吧。这个呢我们先解掉,因为这个里面呢,它不光有这个点啊。
我来说两句