00:00
好,那么。第二个。啊,那么第二个。那我们想啊,呃,我们肯定我们写到这个。这是克里奥见表。那未来呢,我们肯定有一张。不是有一张啊,是有一个扎病。跟他长得一样对吧,那招聘呢,字段诶终于偏多了,之前呢,可能就这么四五个,五六个对吧,字段呢都比较少,哎,周瑜呢,我们看看到一个这个字段比较多的啊,好像是十几个吧,啊这个无所谓了啊呃,那。它有什么点呢?在于你看我们刚开始在关联为表之前。咱们是不是就应该。做好这个数据的去重之后,把它。拿到这个数据。对吧,啊,那当然了,你可以去关联维表,然后呢,再去这个补充,其实也可以啊好,那我们肯定还是先。
01:04
呃,转换成这个扎并比较合适一点,对吧?好,那我们想啊,呃,如果说我们先转换成扎并。然后呢,再去关联。为表。啊,然后我们接下来我们聊一聊这个招聘的事啊,再去关联微表,那你说这里边是不是还缺字段呢。对吧,我们要去补这些个字段。把这些东西呢补上对吧,当然这中间UD去掉,我就全部都勾选了,好吧,那我们要补这些姿算。我如果说先转换成扎病。啊。然后去关联为表,把这些字段补充上,那会更方便吗?因为你要是刚开始是那个杰森格式,你再去补这个字段也是负负负对吧,比较多也不好啊,你就去好重之后呢,你就转化成这个账号B。
02:06
那这样的话,我问大家就是如果扎病真的跟这个鉴标语句写的完全一样。他能做到接下来我们所说的这个关联这件事儿吗?他是不是至少还缺一个什么字段,我看大家能不能敏感的感知到。就是我们招宾里边应该比这个建表语句呢,至少目前来看啊,多一个字段。啊,我看有没有同学知道。啊,看有没有同学能看出来就是我呢,跟你说了,我要先把这个数据去好重以后,对吧,我就转换成这个扎病。
03:07
然后呢,我去关联维表补充我们的这个字段啊,那补充里边的PU。Cat。Trademark对吧,把这些字段呢都补充上啊,最后呢分组。开窗去合。对吧,那你告诉我这里边儿。缺什么字段?原始金额。
04:00
啊,方总说的没问题,缺的就是SKUID。对吧,啊,金额怎么去啊,这不是金额吗。啊。这不是金额吗?你怎么缺金额,这不有金额吗?你肯定是没有的字段呀,对吧,你说有的字段肯定不对呀,对吧,就是SKID你看不出来吗?SKID没有,你拿什么东西去关联呢?对吧,所以在招聘里边呢,我们其实这个需求就跟前面我们埋下的伏笔就关联上了,对吧,终于把这个坑给填了啊,因为在这里面呢,我们要加一个这个SKUID。对吧,咱们呢,要去加一个SKUID。那你要是。转化成招聘的时候没有这个SQID,你接下来关联微表你怎么做?你告诉我你怎么做啊?你做不了。是不是对吧,所以呢,招聘里边肯定有这个SQID,然后呢,我们要根据SQID去关联吧。
05:04
对吧,啊,去关联微表,你更重要的,无论你是做join还是说我拿着这个SSKYD去查Phoenix也好,对吧,无所谓,你怎么着都好,但是你一定要有这个SKD。能清楚吧。对吧?那为什么说把前面的坑填上了呢?因为之前我们在写这个克里house工具类的时候,我们是不是加了一个注解,大家还有印象吗?就是说,诶,假如说呢,他在招聘里边有这个辅助字段。对吧,而这个辅助字段呢,呃,不需要写到这个克里号里边去。但是呢,我在计算的时候,或者正常加工数据的时候,我确实需要这个字段,但是我最终不需要写出去,那这种辅助字段呢,我们最终要把它干掉,对吧,那怎么呢,我们写的是一个。注解去做掉的对吧,那也就是说我们招va里边呢,会有这个s sky ID,但是这个SKD一定带了我们自定义的这个注解,能明白吗。
06:05
对吧,虽然我们把前面的坑就填上了,对吧,因为从我们第一次写完那个之后,诶,前面八个需求都没有用到这个注解。好,那我当然不不写呢,对吧,我整个需求都没有用到,我干嘛还写啊,对吧,其实是用到了,如果用不到,我们确实就不会写了。对吧,没有什么意义了,对吧,能明白吗?这个需求这个招聘里边缺一个SQID子弹。能不能明白了。这就通了吧,对吧,因为我们要有这个SQID啊。我们才能够去做这个。关联为表的一个操作,对吧,你连SQID都没有,你凭什么关联关联不了啊好,这是一个还有。还有。还有什么东西呢?呃,我们呢,其实把这个需求呢,设计的比较复杂一点,还有一个点要跟大家说一下啊,这个点呢,其实在很多公司当中是不会出现的,但是呢,我们多考虑一步,就是你如果说没有这个情况,你考虑上你不会报错啊,不是说他是取其一对吧,我们就选择最保险的那种情况啊,什么意思呢?来。
07:12
正常的,我们都知道。啊,这边来看啊,看这个all的detail。咱们都清楚啊,你比如说这这四条数据啊。呃,我们看这四条,前四条看啊。这四条呢,它来自于同一个。这个叫什么叫奥代,也就同一个订单对吧,这一个订单呢,对应有四个订单明细,然后呢,它对应四个S。Ku ID。啊,它对应四个SKUID,那没有问题。对吧,啊,那没有问题啊好。那关键有一个点是在于什么呢?
08:02
啊,我们思考一下就在于啊。这个东西呢。是这样的。我们呢?比如说啊。在工程当中,我们需要考虑一个什么特殊的情况呢?是这样。嗯。比如说。假如说呢,我们要买16号商品,有的公司啊,啊,咱们这个需求,你这个放在这你看不出来啊,假如说呢,我要买这个16号SKU的一个商品,对吧?嗯,我发现呢,我有。国有呢,这个两张券。啊,有的平台是可以这样做的,我有两张券。额外这两张券呢,都是那个什么买。100减20,比如说啊。我想呢,用两个。对吧,啊,它是针对他不是针对于订单去用的,它对于对于这个商品去用的,比如说啊,嗯,或者怎么说呢,一个是。
09:09
一个一一个是这样吧,这样我我为了解释清楚这个事儿啊,我现在呢,有两张券,就是对于16号商品啊,同一个商品对吧?呃,我我现在说的是有可能会出现这种情况,但是呢,我们了解的更多的平台呢,它没有这种情况对吧,但是保不齐你未来工作的这个平台,它就可能会出现这种情况,实上商品呢,现在我有两两张券啊,一张券呢,是打这个。九折。我一张券场打九折。另外一张券呢?是。买100。减十块。啊,买100减十块,或者说买100减。减多少?
10:01
满100减15。可以吧,诶满100减15啊。好,我有两张这个不同的券,呃,假如说16号商品呢,它刚好是这个。嗯,应该怎么说呢?呃,是一百一百零一块钱。101块钱。OK吧,假如说呢,刚好他是这个101块钱。啊就一件啊,单价101,我现在呢要买两件,我现在缺两个对吧?好,那我在有的公司呢,在一个订单当中呢,就会出现什么诶16。16哎,因为他参与的活动或者领的券他不一样。他就得把这个明细怎么样。拆开,也就是说未来这个地方啊。这个地方。我我就改一下。
11:01
我改一下16对吧,呃,当然这后面都一样,假如说这个名字都一样啊,我我这个稍微的给你改一下好吧,我尽量的。我尽量把这个给你。做细一点。哎,他前面多了一点东西是吧,什么。金沙河什么什么东西啊。对吧,比如说我现在举个例子。哎。啊,行吧,那我们就。完了,我刚才那个呢。我刚才改的那个数据呢。回了。就拿这个啊,前面的我也就不改了,大家知道这两个呢,我改成一样的对吧,这个什么华为手机啊,这边也是华为手机啊,比如说后面都一样,对吧,因为我有两个不同的券,我希望呢,参加两个不同的活动,因为我要我就是下一个订单嘛,对吧,一起把这个事儿办了,我不想下两个订单啊,那有的公司呢,在做平台的时候呢,他可以可能会出现这种情况,也就是说在一个订单里边会出现相同的。
12:14
商品啊,但是这种情况更多的平台是不会出现,我需要跟大家聊清楚这个事儿,懂吗?啊是更多的平台呢,它不会出现这个事儿,但是呢,呃,我们有的平台呢,可能会出现这种情况,所以呢,我们把这个问题给他考虑进去。啊,把这个问题呢,给他考虑进去啊好。那如果出现这种情况来看。这。这个位置。因为我们未来呢,是要根据。这些做分组条件。然后呢,求outcome count out count呢,大家都清楚。对吧,那我们肯定要做什么事。
13:01
来一条。累加一条来一条加一条。因为我默认呢,你这个订单。里边它的商品都不一样对吧,所以呢,我只要按这个分组以后,我直接呢就做累加就好了。啊,直接做累加。就好了。对吧,啊,他求的是订单的次数,好,那我问大家啊,呃,这样的两个明细。我故意搞一样的啊,故意搞一样的好说明这个事儿,因为你SKUID相同,那么你对应的SPU。Trademark category这些东西是不是都一样对吧?如果你求订单的总数,你直接做累加,那么。明明人家都一样对吧,你做哪家诶他奥ID也一样,那不是重复了吗?对吧。就这个点。啊,就是说我们呢,对于16号商品所产生的这个PU。
14:03
Trademark。Category对吧,这些情况按照这个分组呢,那么你应该算一个订单。你应该算一个零的。对吧,但是。啊,但是。怎么样?如果说你不不处理,直接来一条累加一条,来一条累加一条。你就算成两个订单啊,当然最后这个金额无所谓啊,金额你是这样的,假如说呢,你买了两件,在一个订单当中有两个16号商品,对吧,那金额呢,一个是什么8000,一个23,但是但是这这个差距太大了,对吧?啊,假如说呢,这个打折的不一样,8975啊,差这么一点点啊,差这么一丢丢啊,比如说那他俩正常累加是不是没有问题。来一条累加一条,而我们在求另外一个指标叫订单次数的时候,是不是应该要考虑这个奥迪做去重,能明白吗?
15:01
对吧,那我故意是将这个SKU搞相同的,那就算这两个SKUID不相同,对吧,我们就说回到不同的情况,那就算他俩不同,那有没有可能它对应的这个。这些东西是相同的。对吧,它所对应的这个品牌品类。还有这个。PU。他。是相同的,有没有可能在一个订单里边。对吧,啊,那这个也是有可能的啊,那我们跟着曹总这万一呢,有的平台它允许出现这样情况,一个订单里边,对于同一个SKID,它可以写多个订单明细,假如说他确确实实允许这样做。那很明显这块呢,我们要考虑对于订单总数啊,订单数这个地方呢,要对订单ID做去重。这个问题能不能明白?
16:01
大家。能不能明白?当然这是我们附加的一些东西啊,那更多的公司呢,可能会不允许出现这样的情况,对吧?啊,他可能会不允许出现这样的一个情况,能懂吧,啊就是说呢,你同一个。订单当中你下的是同一件商品,那就是合在一块儿同一个明细,对吧,他应该不会说,诶,那你分两个不同的订单明细去处理这个事情啊,那如果说有的平台它允许你分成多个不同的订单明细,那么我们在这块求outcome的时候就要注意一下这个事。啊,就要做到这个驱虫好,那接下来我问一下大家,这个驱虫我们应该怎么做呢。
17:01
啊,就是在我们封装这个扎并的时候,我们应该怎么做呢?那本来我们想着来一条这个给一。对吧,这个呢,就直接用那个split。帽子就好了。偷棒的总总金额对吧,切分之后的总金额啊,那这个给一这个呢给。这个指标啊好看了,现在呢,不能给一了呀,对吧,你不能给你要给一。没办法去融了呀,那我们应该怎么办?嗯,想一下我们应该怎么办啊,这个地方。
18:07
嗯。这个驱虫我们应该怎么做。我们从。讲这个实收仓开始到现在。做过的驱虫太多了,对吧,各种各样的驱虫,那现在呢。我为了求这个订单总数。啊,要对这个订单ID做去重,我们应该怎么做?好,有没有同学来说一说,你是怎么想的,对于这个蛆虫?嗯。
19:01
去宠爱。一点思路都没有,写那么多代码白写了。就一点思路都没有,知道吧。订单总数是维度的相同的算一条不对啊,那我不刚才白说了吗?就是你维度相同。那不能说维度相同都算一条,那我未来就是一了,我还求什么订单总数啊。对吧,应该是什么。如果你。维度相同,你订单ID也相同,这个算一条。能懂吗?假如说你维度是一样的,对吧,你呢是这个SKU是16,你呢,另外一个SKU也是16,但是呢,你的订单ID是9180,你的订单ID呢是9181,那这个当然算两条啊。
20:06
对吧,这个当然算两条了,这不是SKUID都相同,那我就后面就不说了,对吧,什么trademark categy这些东西肯定相同嘛,对吧,这个不对啊,云总你说的这个不对,订单总数是维度相同的,算一条,那那我还求什么订单总数啊,我还根据维度求订单总数,我都写一就得了呗。能理解吗?我们要什么,如果说你这个是16,且你是9180,对吧,你是16,你也是9180,这个算一条。你要把这种数据去掉。对吧,他在一个订单,那为什么我刚才针对于这个来说的呀,在一个订单里边出现了相同的商品,那你要直接对订单明细做了加一,这两个是不是变成了二,我希望呢,他俩是一。能懂吗?肯定你这样一说,那那都没得聊了,对吧,云总。
21:04
啊,状态变成咋做呢。咋做呢?能不能详细说一说?啊,小总你详细说一说,你不要就说一个状态变成。已有的订单号放进list state,好,那接下来呢?
22:01
状态里边存的ID,然后呢。啊,那我问大家要不要。对吧,你们怎么用状态都不说K的事儿呢?按什么分组啊,要不要分组,是不分组还是要分组,要分组的话按什么分组?啊,能不能告诉我。啊,要分组,按照订单ID分组。好,按照订单ID分组,然后呢。
23:02
啊,你多想一想好吧,这个问题呢,我们先。
我来说两句