75.腾讯云EMR-实时数仓搭建-DWS层-交易域-SKU粒度下单需求-需求分析 1原创

好，那接下来呢，我们看第九个需求啊，大家心心念念的这个需求对吧，那这个呢，是SPUSKU力度下单的各窗口的汇总表。呃，力度呢是SKU啊，因为SKU呢已经是最细力度了，对吧，所以我只写了一个SKU，但实际上它还包含PU，什么trademark，还有category。懂吧，因为它是属于这个最细力度了，对吧，所以我们写SKU就够了啊，但是实际上呢，真正的字段里边，那么它会包含有PU trade b category啊，这些东西都有，因为未来呢，我们可能不光。按照SKU分组，求一个什么指标对吧，我要在SKU trademark TEG这个角度都可能啊，对吧，好那。这是力度，我们需求呢下单那又是下单对吧，但是这个下单呢不一样了，诶之前呢求的是人数，是不是求的是人数，现在呢，我们求的是来看啊。

订单数。原始金额。活动减免金额，优惠券减免金额，订单金额。啊，那我们要求的是订单数和各种金额对吧？诶也就为了未来求这个GMV做准备了。对吧，按照各个维度去求这个卖哪个商品卖的好，对吧，哪个品牌卖的好，哪个品类卖的好，卖的最多件数最多对吧？诶那相当当于这样子的，我们都可以都要做横向纵向的一个。对比对吧，每个品牌底下哪些商品卖的好。对吧，都可以横向纵向做对比，那这是属于订单数以及订单总金额。对吧，好，呃，那这个需求放在这儿啊，我们就直接先看一个东西。

建表语句就最终我们要有哪些字段给大家先看一下啊，因为我们刚才只是提了一下对吧，首先呢，那SKU我们的力度。对吧，然后呢，各种金额我们的度量。原始金额。对吧，呃，活动定位金额，然后呢。购物券减免金额。总金额，这是负的金额。对吧，实际上呢，就是拿它X啊，这是YZ，它这个值呢，是X减Y减Z得到的，对吧，原始金额减掉两个优惠金额，然后得到这个金额。啊，当然了，这个就是你下订单这个东西还记得吗？是我们直接拿着SQ number乘以all the price算出来的，在上游算的对吧，但是呢，你上游不算，在这过程当中去算也可以，这个都无所谓对吧？好，当然上游算了，我们就不用管了这个事情啊呃，然后呢，还有一个这个。

订单数，哎，那个。怎么这里边把有一个字段弄丢了是吗？诶不对啊，我看一下啊。看看最后有没有这个建表语句，没有的话应该就没有那个订单数了。我看这个招聘啊，稍等我们把那个订单数如果说去掉的话倒也行，因为如果说我我之前把它去掉了吗？不应该啊。嗯，稍等啊，我看一下这个招聘。看看这个。All amount carbon amount。行吧，没有这个。订单数了是吧，呃，那我我我把它加上加上。这个。啊，咱们加一下好吧，加一下啊。呃，订单数。

在这边。叫凹的。Count可以吧，啊，那这个东西呢，我们加一个啊啊用ill in64也就够了，对吧。属于big in的类型的，Long类型的，对吧，我们加一个啊all看好吧，我们加一个，呃，那也就是说这个招呢，我到时候再去改啊，再改OK吧，因为这边写了订单数，所以我特意看了一下啊，我所以我特看了一下，我就怕这个东西改，因为这个需求改过一版。这个需求改过一版，跟其实以前这个需求跟现在不太一样啊，但是没关系，就整体上差不多啊。因为以前呢，还多了一个用户，这里边多了一个用户，但是我们后来一想，同一个用户在十秒内对吧，对于同一个SKU去下订单，同一个用户啊，同一个SKU，呃，在十秒内下订单的次数其实几乎不可能。很垫底对吧，所以呢，你按十秒开窗聚合其实意义不大啊，那要不然两种改法，当然我们提了两种改法，第一你保留用户，那就不做开窗啊，第二就把用户去掉，我们照样开窗，所以呢，就把用户去掉了啊，因为如果你把用户这个维度也加进来的话，也可以对吧，那这样的话就不需要去开窗了啊，不需要开窗了，这个意思啊好。

呃，那刚才呢，大家也看到了这个整个的这什么。接标语句里边字段的这么多，那首先咱们要取的是什么？肯定是下单数据对不对？从DWD层当中，All the detail，从这个里边去取我们的数据对吧？好，那我们来看一下，其实这里边还缺了很多的字段啊，你比如说我们有的有什么呢？呃，你要的刚才看到的这个什么金额，对吧。来。

减免的金额。这是这四个金额对吧，原始金额，活动界面金额。购物券减免金额。梦没有问题，然后呢，SQID有了，SQ name有了。对吧，但是很明显少了谁像。Trademark ID。ID。还有这个PUID对吧？啊都没有，那那些信息我们要怎么获取。啊，我们要怎么获取。就是很明显咱们这儿缺。PU trademark category。

对吧，很明显缺这些东西啊，那不行啊。我们要补充啊，那对关联维表啊，终于用到咱们dim层的数据了，对吧，其实dim层是咱们写书仓第一个写的代码就是DM层，但是呢。到现在才来用，因为你涉及到关联微表才要用到，对吧，所以它其实难度难在哪儿，就是关联维表的。对吧，其实就是关联维表这个地方啊，那咱们要去关联维表吧啊。所以说这里边呢，主要在关联微表上，那我们要关联SPU，关联trademark，关联CATEGORY123。对吧，关联这些个为表啊，主要就是这个地方比较麻烦，OK，这是第一个点，我们跟其他需求不同的地方呢，它要关联。为表啊，大家记一下这个东西啊，等会写招聘的时候，我也要把这个字段补上对吧？啊，不能就光界面语句有招聘那个没有那不行啊。

好，那这是第一需求，这个需求不同于以往DWS的需求的一个点了。对吧，我们要去关联为表，好，那还有刚才我们看到我们的建表语句在这儿对吧？呃，那咱们招兵呢，起码也是这些个字段，当然呢，我这个还没加。这个资料没加，等会呢，我们写招聘在I idea里面去加一下，好吧，加完之后之后呢，我把招聘替换一下，这个没关系嘛，对吧。呃，那很明显这个字段怎么样。很多。对吧，那如果说我们跟这边来写啊。跟之前的写法一样，比如说这边对吧，呃，之前呢，大家都知道只有五个字段，诶我空着空着或者给当值对吧？啊那三个字段那也没关系，他看着呢也不长。对吧，好，那你要知道一个问题。我们转化成渣，并。对吧，好，那你想啊。

我们要去关联为表对吧，补充信息，好，那我们里边能提供的呢，是这个信息可以对吧，那这个呢，肯定给那无所谓嘛，对吧？呃，这个信息肯定给不了对吧，不用圈了，这个给不了，因为他肯定在开装之后。对吧，开窗之后给的我们就先打个叉，因为刚才我们看到那个是先在开窗之前形成差并，然后呢开窗聚合对吧？好，那我们想呃，开窗之前这个要有。啊，因为这个是属于分组字段，那也就是说不对呀，你不光是这个属于分组字段吧，你这些东西不都应该属于分组字段吗。那我们想啊，我在分组的时候，我只按照SQID分组可不可以。我不按照这么多分组。对吧，大家想一个问题，我按照SKUID分组啊，与按照所有的这个商品的信息分组相比起来。

有没有什么区别？我在这个地方是不是可以只按照SUID加SQ，甚至SQ name我都不加，对吧？我只按照SKUID进行什么？分组。对吧，因为SQID相同了，其他字段也相同，那这有什么好处呢？对吧，本来我们看到的是不是应该这个对于这个需求而言，那很明显这个这些是什么。是力度吧，组合的一个力度对吧，维度组合的好，那这窗口信息，这是度量最后一个版本对吧，那我们应该这样去看，因为它是有力度的，那我们这个作为力度的话，我们按理来说是不是要按照它进行一个keep。但是呢，这么多字段KPI，那也就说明什么呢？你要在K前先关联为表，因为这些信息其实都没有。

对吧，这个没有PU也没有。你要在K前关联为表吧，好，那我们想根据这么多字段，十几个12个字段应该是啊呃，替换成我们只按照这一个字段进行分组，其实结果没有变化。对不对。想一下，如果没有问题，可以扣一啊。我根据SKUID分组与根据这12个字段进行分组。结果是一样的，对不对。为什么？因为SKUID针对于其他的这些维度怎么样，它是。为一一对应的。它是一一对应的，对吧，我通过一个SQID能唯一的找到其他的。

对吧，也就相当于SKD已经是最细力度了，对吧，所以我分组聚合的时候，我只按照SKD分组，我聚合好以后再去关联，为了。我聚合好以后再去关联为表。对吧。那明显的好处了，因为关联为表，为表呢，在h base。你不管是类似于像弗林格斯克里边那种draw。还是说我要在data STEM里边，在map函数里边，对吧，我来一条数据我就查一次，来一条数据查一次，无论哪种方式，我聚合之后数据量是不是少了，我数据量少了，我关联的时候效率是不是提高了。对吧，因为如果你想要按12个字段进行K。

那么你一定在K前关联为表。对吧，管理好，然后你才能做KPI啊，KPI之后聚合。对吧，好，那另外一种呢，我们先不关联，我们呢先按SQID怎么样进行KYKY以后呢，我们做一个聚合，先聚合起来，聚合起来以后数据量是不是下降了，因为聚合了十秒一个窗口聚合了，对吧？好，那这个时候我再去干什么事了。关联为表。对不对，我再去关联为表。那不就好了吗？对吧，这样效率肯定比刚才要高，对不对。还有很多同学没有明白这个点吗？再想一想啊，是不是没有明白为什么我们只按照SKUID就。

分组跟这按照12个字段分组结果是一样的。因为刚才的扣一的同学很少啊，平常比这个要多很多。能不能明白啊，就刚才我们所说的。按照SKUID分组与按照12个磁段分组求得的聚合结果其实是一样的，把这个点想明白，第二个你肯定能想明白对吧？那聚合前关联为表跟聚合后关联为表。效率上肯定是有差距的吧，对吧。能不能明白？

能明白吗？啊，好，那就。没有问题。好吧，那没有问题，OK，那这是我们说的这个点，那说这个。分组时数据量的差距啊，对呀。分组时候数据量没有差距一样的，但是呢，呃，分组前关联为表跟分组后关联为表这个不一样，对吧，因为我们的分组聚合后关联为表的话，访问Phoenix里边很明显就少很多对吧，因为十秒钟聚合一次，十秒钟聚合一次肯定数据集有所下降，对吧？啊提高的效率在这，好那我们为什么要说这个点呢？那就在于。你看我们说了要在关联，关联为表在什么，在聚合之后。

啊好，那聚合前呢是分组。分组之前呢，是要写成Java并对吧，我想说的是这个事。就关于这个招聘的点啊，把刚才那个点说出来跟他有关系对吧？好，那也就是说我们在分组的时候，其实这些东西都没有。对吧，这个puu都没有，这实里边有很多这个也没有对吧，窗口信息也没有，因为它肯定要聚合之后，聚合的时候才能补充窗口信息吧，那这里边呢，绝大部分数据都没有，对吧？这些东西都没有，好都没有的话，那你要写，你写成这个样子，你怎么写啊，呃，空空空空空空空空一堆，然后呢，有这么两个字段，三个字段对吧，两三个几个字段啊，不多，反正不多对吧？好然后呢，也最后呢有个荡值，那而且呢，特别冗长，因为我们这个字段呢。很多。对吧，资料很多，所以呢你就看起来很不爽，很不舒服，所以呢，我们这个地方扎病啊，用了一个构造者设计模式的方式，就是大家以前所看到的那种，诶，那我要的属性就给，我不要的就不给。

我们用过的。叫什么？虽然构造者设计模式这种名词呢，我们很少提，但是呢，我们经常用这种方式，能不能把它的里边关键词说出来啊？对了，就是builder，你有没有发现build这个东西啊？是不是你只需要给你想要的字段就行了？你不想要给的，你不用给，他自己有默认值，并不要我们自己new一个什么对象，你必须要把所有的参数都给全了，或者说呢，你你写很多的构造方法。对吧，或者说你要写很多的构造方法。是不是？对吧，所以这个招聘呢，咱们用构造者设计模式来做这个事情。

好吧，咱们用构造者设计模式来做这个事情。OK吗？就是这个点在这儿啊。好，呃。没build过，怎么找不到，怎么build啊？