00:00
好,那接下来我们看商品维度表的数据装载啊,那谈到这个数据的装载呢,我们必须得首先搞清楚这个数据从哪儿来,那然后呢到哪去,那也就是这个数据的走向是什么样的啊好,那现在我们先通过这个PPT呢,看一下这个数据的走向,来我们点开。好,大家现在呢,看到两部分内容啊,那第一部分指代的就是ods层跟商品相关的业务表,那这些业务表呢,就是我们商品维度表的主要的数据来源啊,OK,那下边这部分呢,诶,指的就是商品维度表,OK,那现在我们来看一下这个数据的走向是什么样的啊。假定今天就是2020年6月14号啊,也就是数据仓库的第一天,那由于第一天的时候呢,我们会对所有的业务表进行全量同步,那所以说O层这些跟商品相关的啊,他们第一的存放的都是全量数据啊,那就是下。
01:02
啊,那我们要做的工作是什么呢?那就是从这些表当中去寻找我们商品维度表所需的所有字段,啊,那拿到之后呢,将这些数据insert到商品维度表14号的分区当中。啊,那第一天的工作就结束了啊,那随着时间的推移,我们来到了第二天,也就是6月15号啊,那由于跟商品相关的这些业务表,我们采用的同步策略永远都是全量同步啊,也就是不止第一天是全量,那他们后续每一天都是全量啊,因为跟商品相关的这些表啊,他们有一个这样的特点,就是数据量呢不会特别大,那而且呢,既会发生,既会有新增,也有可能会有变化,那所以说那适合采用每日全量同步啊,那也就说到了15号的时候呢,那我们拿到的仍然是全量数据,那所以说我们要做的工作呢,跟第一天其实是一样的啊,那也是从这些表当中获取我们商品维度表所需的字段,然后把数据insert到商品维度表,15号的分区当中。
02:06
啊,那以后每一天都是同样的操作。啊,大家其实也发现了啊,那由于我们这个商品维度表相关的这些业务表啊,那他们每天做的都是同样的这个同步对吧,都是全量同步,那所以说诶,我们往商品维度表当中装载数据的时候呢,我们首日和后续每日的装载逻辑其实也是相同的,嗯,OK,那这个呢,就是我们商品维度表的数据的走向,好,那接下来我们看一下这张表具体的装载逻辑,好打开这个建表语句,呃,好,大家应该心里都清楚啊,就是我们商品维度表它的这些字段啊,实际上是由ods层的一些跟商品相关的业务表拼凑而来的,对吧?那所以这张表的装载逻辑呢,大致应该就是这样的啊呃,我们应该先从ods层跟商品相关的这些业务表当中,逐个的去获取我们所需的字段啊,那当然这些字段呢,肯定是来自于不同的表了啊,那所以说我们可能会写很多的子查询,没错吧,那OK,那写完这些子查询。
03:10
之后呢,哎,我们再使用这个join,把这些字段拼接到一块儿,那这样一来就能得到我们最终的结果,啊,大体的思路就是这样了。好,那接下来我们先来分析一下啊,就是这些字段,嗯,都应该来自于哪张表啊,来咱们分析一下,那就是从ID开始到这个Excel字段,这部分内容呢,其实都是Su的基本信息,那它肯定是来自于OD层的Su啊,那接下来再往下走,那po ids PU名称,哎,这个是属于PU信息,对吧?那所以它肯定是来自于ods层的PU啊,那接下来往下走,那这有三级分类的ID和名称啊,那这个不用多说,肯定是来自于ods层的三个分类表啊,其实就是这三啊,应该是ods base category123啊,OK,继续往下走,那这个品牌名称和品牌ID,那这个属于品牌信息,那所以说它肯定是来自于O层的品牌表,OK,那这些其实都是比较简单的。
04:11
那接下来我们看最后的这两个字段啊,最后的两个字段呢,分别是平台属性和销售属性,那这两个字段呢,相对要难一些啊,那所以说我们这儿花一点时间去分析一下这两个字段啊,那首先我们先来明确一下这两个字段,哎,它的这个数据的结构啊,好,大家来看一下它后边的类型呢,是结构体数组,这个我们之前已已经提到了,对吧。然后呢,我们再来看一下这个结构体数组当中的内容到底是什么样的,假如说现在呢,就有一个结构体数组。啊好,那我这里边的小方块儿呢,代表的就是一个一个的结构体啊,外边的这个大方块呢,指代的就是这个数组啊好,那我们现在先明确一点啊,就是这里边的一个结构体所指代的是一个什么?啊,实际上这一个结构体啊,指代的就是诶,我们的一个平台属性,或者是一个销售属性。
05:03
啊,是这样的啊,那由于我们每个商品都有若干个平台属性,或者是销售属性,对吧,那所以说我们把这些属性呢,放到了一个数组当中啊,这就是这个结构体数组的这个内容。啊,这个大家一定要注意啊好,那接下来呃,我们再来看一下这个结构体当中的具体的字段是什么啊,来看一下结构体当中的字段呢,我们来分别有at t ID,这个其实属性ID啊,还有value ID,那value ID指的是什么呢?就是那个属性值ID,那at t呢指的就是。啊,是这样的啊,那当然这个是平台属性,下边的是销售属性,平台属性跟销售属性呢,在这儿是对称的啊,他们的设计是一样的啊,所以说我们现在就重点看一个就够了啊OK,那这个就是我们平台属性和销售属性的这个数据的结构啊,OK,那我们看了这个呃的结构体里边的字段之后呢,我们基本上就明确了我们需要什么字段了啊,我们需要的应该是什么,需要的是每个平台属性和销售属性的啊,这个属性的ID属性值的ID属性的名称和属性值的名称。
06:15
没错吧?那现在我们就来分析一下,我们到底去从哪张表里获取这些字段。好,那现在我打开一个PPT啊,我们来好好分析一下啊,来大家注意观察,那这些表就是与商品相关的所有的业务表对吧?啊,那我们把这里边比较简单表都去掉啊,只留下平台属性和销售属性啊,那由于平台属性和销售属性啊,这两部分的表它的设计是对称的啊,那所以在这儿呢,我们就只保留一部分就行,我们把销售属性也去掉,那咱这儿呢,就以平台属性为例,哎,去分析一下这两个字段,好,那现在我们简单回顾一下啊,就是这几张表当中他们所存储的数据是什么啊,那SKU这个不用多说,那就是一个一个字SKU对吧?好,那先来往下走,那平台属性表里边存的是什么呀?
07:04
啊,其实前面咱们分析过啊,这张表当中存储的是所有的商品的平台属性的K。啊,因为咱们前面说过啊,就是一个属性呢,实际上就是一个K一个V对吧?啊,这就是一组属性啊,啊,那平台属性表当中存储的就是所有属性的K啊,那平台属性指表当中存储的是什么呢?那显然就是所有的平台属性的value。啊,那当然K与Y6之间必须得有一个关联关系对吧?啊,好,那接下来我们再往上看啊,那这张表当中存储的是什么呢?啊,S ku y。那实际上这张表当中啊的就是我们的S。啊,因为你想啊,那这张表当中有所有的K,这张表当中有所有的Y6,但是我们如果没有这张表的话,我们并不知道那这个K和这个Y6属于哪个SKU,就是我们不知道这个属性它属于哪个商品。
08:03
没错吧,那所以说那我们需要有一个这样的表去SK平台属性之间的关联关系啊,OK,那我们再来看一下这几张表的具体的字段啊,来我点一下。好,大家注意观察,我们先看这张表,那这张表当中,那首先有一个主键ID,那ID呢,指的就是属性ID,没错吧?那这个at tr name指的是什么呢?指的就是属性的名称啊,那这里边就是属性的K,其实没错吧,那下来往下看,那这个呢,是base at TL平台属性表啊,平台属性值表,那这张表当中呢,诶主键诶是ID,那当然这个指的就是属性值的ID,没错吧,那下面这个呢?啊,这个就是属性值的呃,Name,那也就属性值的这个,呃,名称对吧?Value name啊OK,那这这两张表啊,那这里边其实就是那个所谓的VALUE6嘛,没错吧,那大家来看一下这张表,这张表刚才说了,它的主要作用呢,就是保存商品与平台属性之间的关联关系,对吧?那所以说其实这张表当中的核心字段就是谁呀,就是他们俩。
09:07
那个SID是ID值啊,OK,那大家看一下这个关系是不是应该是已经捋清楚了呀?啊,那你想一想啊,那我通过这张表是不是能够找到我们每一个SKU啊,那它的属性值都有什么?没错吧?哎,可以通过YID去关联到这张表吧,是不是能拿到属性值没错吧?那通过这个属性值表里的ATID呢?我们是不是要能拿到这个属性值所对应的属性啊?没错吧,啊,是这样的啊,这就是这几张表当中的关联关系,那所以说理论上啊,我们要想获取每一个SKU的属性ID,属性值ID,那属性名称,属性值名称我们应该怎么去拿呀。应该怎么去拿呀?那是不是通过这张表我们能拿到每个SKU的属性值ID?没错吧?那进而能够拿到属性值名称,那进而能拿到属性ID,那进而呢,能拿到属性名称。
10:14
没错吧,也就是我们应该,呃,是不是需要用到这样的三张表才能拿到我们所需的这些字段呀,对吧?啊,但是细心的同学其实能够发现的啊,其实我们根本就不用这么麻烦去做这么多的关联,为啥呀,因为在这张表当中哎,有三个冗余字段。啊,你看一下这三个容易钻分别是啥,是不是分别就是属性ID属性名称和属性值名称啊。没错吧,那实际上我们要想获取这四个字段,我们只需要这一张表,是不是就够了呀?那同样的道理啊,那我要想获取每一个SKU的销售属性,对吧,那我们是不是只需要诶这张表就够了。没错吧,那因为上下是对称的嘛,啊OK,好,那现在我们商品维度表的取数逻辑咱们就分析完毕了啊。
我来说两句