00:00
嗯,好,那咱现在一起看一下,呃,交易域支付成功这个事物实时表,首先先明确一点,就是它所对应的业务过程是什么叫做支付成功啊,注意啊,我这么明确了啊,他叫支付成功,而没有说简单的就是说了一个支付,为什么说呢?为什么这么说呢?因为单纯的一个支付,你要这么说,它并不是一个就是准确的说法,因为支付这个操作它本身就不是原则性的,没问题吧,对不对,因为你点了支付之后,你可能会真正的去付款,你也可能点了支付呢。你没有付款对不对,它本身就不是一个原子的操作,对吧?诶你要说支付的话,那所以说啊,我们的这个实时表所对应的业务过程,那必须是不是都得是原子的一个操作呀,对不对?所以在这儿呢,我们这个业务过程,它指的是你最终支付成功的那个操作啊,而不是说单简单的一个支付,这么这个说法,这一定要搞清楚啊,就是明确了是支付成功的,哎这个操作,那也就是换句话说也就什么呢?假如说你在这个去支付某个订单的时候,你只点了一下支付,但是最终呢,你比如说跳到了支付宝或跳到了微信,你没有真正的去完成这个支付,你说这样的操作我们会记录在这张表当中吗?是不会的,我们只要那个最终是成功那样的操作啊,这个理解一下好了,同学,那这个表所对应的业务过程咱就说完了,说完之后呢,接下来呢,我们来先设计一下这张表的表结构啊,表结构呢,还是那四个步骤吧,咱还是对对照着这个业务总线矩阵去看啊,首先找到与之相关的业务过程,就是支付成功,这个很简单,那接下来往后看啊,下边要做的一步就是声明这张表的力度对吧。
01:35
就是每行所指代的内容,那你想一想,他每行所指来的应该是什么,其实也应该是一个什么,是不是就是一次支付成功的操作记录啊,对吧?当然我们需要精确到什么程度,需要精确到是谁,在什么时候,对不对,成功的支付了哪个商品啊,咱也得精确到这个商品才可以,对不对,因为你要是不精确到商品,那将来比如说我想去算一下,呃,比如说某每个商品,我的这个被支付的总额你能算出来吗?你算不了对吧?所以这必须得精确到商品才行啊好了,那接下来呢,我们继续往后看,那这就是它的力度就明确了啊,一行是一次支付记录,精确到人啊,这个时间商品啊,这条网就好,继续往后看,那下边呢,我们看看第三步做的工作,也就是确定它的力度啊,它的力度都呃,就确定它的这个这个维度啊维度,那维度都有啥呢?你会发现它的维度跟上边这两张表的维度也基本上是一致的吧,对吧,也基本上是一致。
02:35
啊,为什么也是一致的,这块我给大家简单说一下啊,那实际上所谓的这个支付成功的这张实时表里存放的其实也存该是什么,说白了也是订单明细,也是订单明细啊,为什么也是订单明细呢?啊很简单,因为咱们刚才说了,我的力度需要精确到人,用户啊,也也需要精确到这个是哪个用户在什么时候是不是成功支付了哪个商品啊对吧,是这样的,所以的力度其实也相当于是明细力度,只不过呢,这里边放的明细不是全部的明细,它只有什么样的明细呢?
03:06
最终支付成功的那些明细啊,而上面这个下单里边存放的什么?是所有的明细,那这个放的是什么呢?是取消的订单锁定的明细对吧?那这个呢,是支付成功的订单锁定的明细,就说白了,这张表你一会儿就会发现它跟上面一个取消订单啊,是不是很像很像啊,对吧?啊,包括他的装单语句的逻辑基本上也是差不多的啊,这个理解一下行了,那这个完成之后我们继续往后看,那既然它里边放的也是订单明细,那所以说它里边的这个表结构跟上面的表也差不太多啊,好了,那现在我们看一下它具体的字段啊,呃,前面这几个呢,就是与之相关的维度啊,这个不多说,然后重点看后边,这是不是与与前面相比多了一个维度啊,对吧?这个多出来的维度是什么?是支付方式,这个是不是应当是支付这个业务过程所特有的一个维度啊,对不对?前面因为涉及不到支付,它没有这个概念,对吧?OK,那这个支付方式就是它的一个维度,当然这个维度呢?啊,由于它相对来说比较简单啊,所谓支付方式就是什么支付宝,微信银联那个东西,对吧?啊,其实比较简单,就一个字段,所以我们并没有去做维度表,而是将它退。
04:07
发到了是这个支付成功的这张表当中,哎,这个理解一下啊,好了,那这个完成之后我们继续往下走,下边最后一步就是确认事实,那这张表的事实你看一看是不是跟前面的表的事实也是基本一致的呀,对吧?那只不过在这儿我们换了个叫法,我们管它叫做支付的件数,支付的金额,诶这个理解一下就行了,好了,那到目前为止呢,这张表的设计过程咱就走完了,呃,走完之后我们来看一下它最终的表结构,来找到这张表的加法语句,往下翻,CTRLC。来,咱给它拿过来,我放在这个位置啊,呃,来吧,那现在呢,我们就一点一点来看啊,首先先看一下它的这个,呃,表名叫做什么?表名叫做DW d trade,然后呢,就做pay detail success INC,对不对,我这特意强调了一下,是支付成功的这个明细,对吧?哎,这个就不再多说了,然后往下走,呃下边呢,就是它的行,还有列,还有分区呗,先看行一行,其实说白了啊,一行你你其实就应该是一个什么呢?就是一个订单明细。
05:03
没错吧,但是呢,这个订单明细它不是全部的那个明细,而是什么呢?只有那些支付成功的订单所对应的明细,这一点要搞清楚啊,行了,那继续往下走,行清楚了之后我们往下走就是列呗,对吧,列还是维度加度量来先看维度,那维度呢,首先从这个UID开始往下走,走走一直走到这儿,这些其实都是大家特别熟悉的那几个维度了,对吧,我就不再一点点说了啊,然后往下走,这儿有一个什么,这是咱那个时间吧,对不对,然后呢,这里边呢,有一个date ID啊OK,那这个应该是能搞清楚的,然后中往中间看各位东西,这个是什么。这其实也是维度,是我们退化进来的维度,对吧?这个退化进来维度指的是什么?是payment type,是不是就是支付方式啊,对吧?从那儿能看出来啊,业务系统当中支付方式它存的也应该是什么,也是编码,对不对?编码在这儿我是不是需要给它加上一个具体的文字说明啊,对不对,这个应该是能够搞清楚的,接下来咱继续往下走,那下边呢,我们看这几个字段,这几个段是不是仍然对应的是度量值啊,对吧?这个就不再多说了,然后我们看中间,中间这儿呢,有一个call back time。
06:05
这个call back time指的是什么呢?叫做回调时间对吧?诶这个回调时间是啥意思呢?完了之后你还你注意观察一下我后边给他的注释,我给他的注释就是什么?就是支付成功的时间,也就是我们这个所谓的支付成功的时间呢,是用这个所谓的回调时间去,哎,这个代替的对不对?OK,那回调到底是怎么一回事儿,这个一会儿我再给大家解释,这个跟我们在业务系统当中去做这个支付的时候的那个具体流程有关,咱得知道在业务系统当中,我这个支付的流程到底是什么样的,我们才能知道这个回调时间是什么意思啊,这个一会儿咱再说啊行,那现在呢,我们继续往下走,那这块咱们看到的其实还是那几个来源,对吧,这个来源呢,仍然是维度,做了维度对话,诶包括我们上面的这个支付类型,在这儿做的也相当是一个维度对话,对吧?诶这个理解就行了,好了,那这张表的例咱就说完了,诶跟前面那些那个下单呀,或者是取消订单呀,跟那两张表基本上是类似的,呃,你要说哪儿不一样呢?是不是应该就是多了一个这样的,诶支付方式的维度啊,对吧,别的。
07:09
基本上是一致的啊好了,那这个完成之后,我们继续往下走,最后明确一下它的分区规划,它的分区是不是仍然是INC增量分区啊,对不对,这个咱就不多说了啊好了,表结构咱就说这么多,来视频我停一下。呃,来吧,各位同学,那我们刚刚已经完成了,就是这张表的一个,它的什么呀,它这个表结构的设计了,对吧,那下边呢,我们来分析分析,就是它的数据装载,咱应该怎么做?呃,还是老规矩对吧?啊,数据装载呢,咱们得先分析数据的流向,数据从哪来,最终到哪去,对不对?来吧,咱们分析分析数据从哪来。来吧,分析分析数据从哪来,数据从哪来,是不是还是得去分析一点,就是哪一点,就是说你影响哪张表啊,对吧,那影响谁呀。咱这这个什么什么业务过程,是支付成功的业务过程,对不对,那他会影响谁呀。哎,对,大家最容易想到的一张表就是谁,就是older info,那支付成功这个业务可能到底会不会影响到info,答案是肯定的,是会影响的,为啥呢?因为只要你一支付成功了,那OK,我的这个older status是不是就会发生变化,它理论上会变成什么呀?会变成100几来着,应该是1002吧,对不对?所以说会对他产生影响,这个应该是没啥问题的,对不对?好,那他会对明细产生影响吗?
08:27
不会,除了下单汇兑明细才是讲别的是不是都不会,对不对,OK,那我们这儿要找的是什么?我们要找的是不是就是支付成功的订单明细啊,没问题吧,好,那我们怎么去找呢?其实跟那个取消订单是不是应该是一样的道理,我们得先找到什么,先得找到支付成功的order in full对不对,是不是进而再去关联订单明细,是不是就能找到支付成功的订单明细了,对吧,也是这样的一个逻辑啊,好了,所以呢,按照咱们现在的理解,我们应该怎么做呢?应该先从order info这张表当中寻找支付成功的订单明细的订单订单info,对吧?啊,然后呢,再用它去关联欧德里,进而找到支付成功的订单明细,应该是这样一个逻辑吧,对吧?好,那这个方案咱们实现起来好不好实现呢?来分析分析啊,首先第一点。
09:16
就是咱这张表去做的时候,我们也需要去区分一个首日跟每日对吧?啊,那分析分析在首日的时候,我们怎样从这一堆历史数据当中去寻找那个支付成功的订单。怎么去寻找首日的时候,因为你也得分首日的每日嘛,对吧,首日你怎样从这里面去找。支付成功的订单,根据订单状态直接过滤行不行,直接来一个orders,等于1002,这个能不能找出来?这个找不全对吧,咱们为啥找不全,刚才已经分析过了,对吧,因为对呀,因为你状态变成1002之后,他是不是可能后边还会再变呀,对吧,而这个状态这展示的是什么,知道最终状态对对,所以你直接这么找,不太好找啊,那也就是说你要从那儿找你那个过滤条件,其实写起来的话呢,可能是不是比较麻烦呀,对吧,而且你可能容易漏,对不对,所以在这儿从这张表里去找我们那个支付成功的订单,就是不是特别的好,但也不是说不能行也行啊,但不是特别的好,OK,好,那也也就是在这儿呢,咱们其实不太好,那我们换,呃,换一个思路,看看还有没有其他的更好一点的办法呢,更直观,更直接一点的方案还有没有。
10:23
那我不从这张本里找支付成功订单了,那我从哪张表里能找到?其实各位同学大家可能忘了一张表啊,哪张表叫做payment in for,这张表里咱们存放的就是什么来着,是不是就是一条一条的支付记录啊,对吧?好,那你说这张表当中我们能不能找到咱们想要的那个支付成功的订单呢?能不能找着,能不能找着咱们来分析分析啊,首先各位同学,首先咱们先明确一点,就是说这两本的结构是什么,咱们得先熟悉了啊,大家熟悉不了,熟悉不熟悉这本的结构,熟悉吗?可能不太熟悉啊,不太熟悉咱们就来一起熟悉一下啊,首先先明确它的每行指来的是什么,每行是什么。
11:05
其实就是一个订单的一条支付记录,因为大家都知道我们真正在去支付的这个这个订单的时候,我们是以什么为单位去支付的呀,咱们就是以订单为单位,以order特为单位,对吧?我们不会说一个明细一个明细的去支付,这一点大家应该是有体会的啊好了,那所以这张表当中一行所指代的就是一个订单的一条支付记录,好了,行明确了,接下来我们再看它的列都有啥啊列首先第一个就是OID很熟悉,你支付的是哪个订单,咱得知道对吧?但你是谁支付的,咱是不是也得知道对不对?那第三一个字呢,就是payment type,就是你的支付方式,诶支付宝,微信、银联就那些东西,这个咱们就暂时先不去看这个编码了啊,然后往后看下边一个呢,就是total amount,就这个字段啊,这是不是就是支付的总金额呀,对吧,这个没什么可说的,然后往下走,这是你支付的这个内容,Subject,对吧,这个也不多说,然后往后看,后边这样呢,有一个什么字,叫做payment status,叫做支付的状态,大家其实看到这个状态之后,就应该能够体会到我之前。
12:05
说的一句话,哪句话来着,就是支付它本身不是一个原子的操作,支付它也是有步骤的,对吧,那没问题吧,所以说是不是不同的步骤会代表不同的状态,对吧?好,那一会儿我再给大家解释这个状态到底是啥意思啊来我们继续往后看,这儿呢,还有一个什么create time叫做什么叫做创建时间,对吧?好,创建时间指的是什么?诶大家不知道,一会儿我再说,那后边还有一个什么call back time回调时间,这就是所谓的回调时间,好,那有回调时间还有什么呢?还有回调的内容,好了,那现在这些字段咱们基本上都看了啊,有些咱能看懂,有些看不懂啊,OK啊,啊,这些东西大家之所以看不懂是因为什么呢?是因为大家现在还不太清楚我们这个支付的流程到底是什么样的,那接下来呢,我就先给大家简单的介绍一下这个支付的流程,之后呢,我们再来看这些字段到底是什么含义,那实际上我们正正常情况下一个电商系统对吧,我们去做支付的时候都是怎么做的,就是不是所有的电商平台咱们都有自己的支付系统,对不对?那比如说举个例子,那假如说我们现在是一个小型的电商平台。
13:05
那我们一般情况下,你要想做支付的话,你应该让他用什么去支付地方地方接口,对吧,要么就是比如说微信的,要不就支付宝的或者其他的,对不对,是这样的,OK,那所以说我们正常情况下,你一个电视平台再去做这个支付的时候怎么做啊,他是这么去做的,当我们在他的这个电商平台上边点了一个支付按钮之后,这时候会怎么样,会怎么样呢?我们这个系统它会去调用第三方的支付接口,比如说调用支付宝的或者微信的接口,对吧?它调用的时候,你看咱们这个当前的客户端,你会发现它会怎么样,它就会跳转到比如说那个第三方的一个支付平台的一个支付页面,对吧?诶,这实际上是调用第三方支付接口的一个过程,好那调过去之后,那你会在怎么样的,你两种情况,要么就是你去真正的支付,要么就是说你直接不支付,是是有这样的两种情况嘛,对吧,那所以说我们系统就是咱们自己这个电商啊,我要想知道你这个最终支付的结果,我得怎么样才行。
14:02
啊,就是必须得拿到最终的那个支付的状态才行,对不对,他怎么能拿到呢?啊,一般情况下,这个第三方的这个支付服务呢,它都会有一个回调的操作,他会去回调我们这个电商的平台,那回调的时候呢,就会顺带着把什么信息给你带过来呢。把什么带回来,诶把你这个支付的结果给你带回来啊,是这样的,那这里边这个结果通常,哎,它是一个那种半结构化的一个一一个格式啊,比如说是一个阶森字串,对吧?里边呢,有一个非常重要的字段,通常会有一个什么字段呢?就是支付的状态,对不对,这个状态可能是失败了,也可能是成功的,是这样的,那这就是一个支付的完整流程,就是说你会先调用第三第三方的支付接口,然后呢,再怎么样呢?诶再回掉我们的系统,把这个支付的结果告诉咱们啊,是这样的一个过程,好,那这就是支付的流程,好,那这个支付的流程搞清楚之后,我们再来分析分析啊,就是说我们这张表的数据,它到底应该是如何发生变化的,对不对,OK,那现在呢,我们就模拟一个这个就是真正的一个支付的过程,对不对,来看一看这两本的数据它是怎么变的啊,那首先那我们要想做支付的话,第一步是什么?是不是就是我们用户需要点一下那个支付的按钮啊,对吧?那其实在你点的过程,你只要一点完这张表里,其实它就会怎么样一条数据呢。
15:18
就会INSERT1条新的数据,那这个数据刚insert进来之后,它是什么样的一个状态呢?来我们前面这些东西基本上都是有的,来支付的金额,支付的这个对象等等都是有的,然后往后看,那这时候我这个状态是什么呢?注意看这个状态,我可以告诉他,这一共有三个状态,1602 1601,还有103,对吧,他最开始的状态其实应该是一个1601的状态,1601,那这个1001在这指的是什么呢?是支付成功的状态吗?是吗?其实并不是,是一个,就是相当于是一个待支付的状态吧,对不?虽然你点了支付,但是你还没有真正的支付嘛,对不对,这相当于是1001是一个待支付的状态,好了,OK,那也就这最开始是1001,那之后我们继续往下走,那这时候cur time的值有没有呢?有,你刚插入的时候就会有一个相当于是插入时间,对吧?Cur time OK,那继续往下走,那这个call back time有内容吗?
16:12
你刚支付的时候没有的那个同理,这块是不是也是没有东西啊,对吧,他俩是空的啊,OK,好,那假如说我现在点完支付跳到了那个第三方的支付页面,我真正的完成了支付了,OK,那这时候他会怎么办?是不是正常情况下这个第三第三方的支付服务会去调用,我们会会会去回调咱们这个接口啊,对吧?那回调咱们的时候是不是会把这个最终的支付信息给咱们拿过来对不对?那我后边电商的这个平台当中的逻辑就应该是什么样的呢?诶他会去解析这个回调的内容对不对?OK,那完了之后同时会把什么呢?会把回调的内容是不是写到咱们这张表当中对不对?OK,那这时候是不是会有一个回调的时间也给他填上,对吧?我什么时候接收到的那个回调对不对,OK,我把那填过来,OK,那我这个状态我怎么改呢。这个状态怎么改,其实取决于什么呀,大姐夫。
17:00
这个状态其实呃,1001是待支付的状态,对吧?1002是成功,1003是失败,我告诉大家,你说这个应该取决于什么呢?取决于是不是这个回调内容啊,对吧?如果回调内容当中那个状态字段是成功的状态,它这儿就会变成1602,那如果是失败的状态就会变成103,它是这样的一个逻辑啊好了,那截止到现在,大家就应该已经对咱们这张表的这个表的结构以及它的变化逻辑比较熟悉了,好,那现在我问一下大家,我们现在要找的是什么样的订单来着,是要找的是支付成功的这个订单对不对?好,那你说我们从这张表里能不能找到支付成功的订单。能不能找,能不能找着,是不是还是得分两种情况,一个是首日,一个是每日,对吧,OK,那首日的时候大家说我们从这里边能不能拿到支付成功的订单,首日首日说说白了,咱们拿到的数据跟这是一样的结构,对吧,OK,好,能不能拿到。能不能拿到,哎,你说哎,我直接来一个物理条件payment这个呃,Status就是那个支付的类型等于1602,你说我们过滤出来的这个订单,这是不是有OID啊对吧,是不是支付成功的历史订单是不是。
18:12
应该就是吧,对不对,是不是只要我这个订单他的状态之前这个支付的状态以前是1602,只要是成功了,还会还会再发生变化吗?就不变了,对不对?所以在这儿呢,它也相当于是就是一个最终状态嘛,对不对,支付成功就是一个最终状态,所以说只要payment stas等于1602,那我对应的那个OID,那不就是支付成功的订单嘛,对不对,你只要找到支付成功的订单了,你再用它去关联那个明细,不就拿到了支付成功的明细了吗?这个应该是能拿到的,对吧,这是首日,那每日咱们从这儿拿能不能拿到呢?每日每日注意你拿到的就不再是这样的数据了,对吧,你拿到的应该是一个一个的insert update操作对不对啊,那你说从这一堆操作里边,咱能不能拿到支付成功的这个操作能不能拿到,如果能,那具体应该怎么拿,首先类型应该是什么类型。
19:02
是字还是update类型?啊,你你要知道拿什么类型,首先你得知道支付成功到底是怎样影响这张表的,对吧?刚才按照我们刚才的分析,支付成功是怎样影响到的,是因321条吗?并不是inser,什么时候inser是你点支付按钮的时候inser的,对吧?但那个成功了嘛,不一定啊,对吧,所以不能以inert为准,我们应该是啊update对吧?诶首先你得是update类型,而且还得保证update的逻辑什么样的,首先你改的字段得是哪个字段,得是payment字段,没问题吧,而且还得保证你改完之后的值是多少呢?是1602,这是不是才是成功的一个标志啊,对不对?所以说我们,诶在每日的时候,我们从in色的阿操作当中也能找到咱想要的那个支付成功的操作,所以这个理论上是没问题的啊,是这样的啊,所以说那咱们从这张表当中去寻找支付成功的OID应该是没有任何问题的,首日也可以,每日它也行,哎,都行啊,是这样的啊好了,那所以说那咱们现在的方案基本上就定下来了啊,我们主要是怎么去找到咱们这两本。
20:06
的这个数据呢,我们这样去找,我们从payment in inform那张表里去寻找支付成功的order ID,不管是首日还是每日都从那张表去找好,找到之后接下来怎么办呢?是不是在用它去关联那个order detail啊,对吧?好,那找到order detail之后,诶,他俩一关联,那是不是就拿到了支付成功的订单明细了呀,对吧?OK,拿到之后我们再去往咱们这张表里去做装载就行了,当然呢,我们首日应该做动态分区,每日是不是就不用再做动态分区了,对不对,这个大家应该是能够搞清楚的,行了,那咱这张板的数据状态的流向,以及大体的一个数据状态的逻辑我就说完了,当然了,呃,按照我们刚才的描述呢,我们只用到了payment和order detail,但是这两张表是不够的,就因为我们这里边说还有一些东西是拿不着的呀,对吧,比如什么pro ID啊,这个是不是拿不着,拿不着是不还是得关联对吧,那下边这什么活动的ID优秀咱也拿不着,拿不着的话你就去关联相应的表,那就完事了,OK,那这个呢,就是咱这张表的一个大体的重大逻辑啊,然后呢,逻辑。
21:06
大家现在基本上应该已经捋清楚了啊,可能有些细节我没有提到,细节呢,到时候大家自己琢磨琢磨啊,然后接下来的时间呢,大家就按照我们刚刚所讲的这个逻辑,所讲的这个思路,把这个circle自己去写一下啊,不管能不能写出来啊,这个大家呃都去尝试一下,能写出来最好,写出来的话呢,也没事儿,那后边咱们再多练就行了啊来视频我停一下。
我来说两句