00:00
好,我们继续啊,呃,那我们终于把这个日志数据的采集和分流啊,就算是告一段落了啊,但是大家需要注意啊,这里面我们还有一个问题没有解决,就是那个密等的那个问题啊,听到了吧,就是密等处理还没有解决啊,这个我们要放到后面的,后面再去解决,就先把它留到这。好吧,行呃,那接下来呢,我们就先进入到这个第三章啊,我们研究一下业务数据,它的这个采集和这个分流。能听懂吧,好,那首先的话呢,还是我们先看一下这个整体的一个架构啊,这个架构的话,我觉得大家应该也都呃差不多能够想得到了哈,来我们一起来看一看。好,呃,首先我们当前这个业务数据的话呢,我们还是把它放到了这个业务数据库里面,比如说我们的这个买烧烤啊,当然有可能是这个什么Oracle等等一些。对吧,那你放到这个MYSQL里面的数据,我们将来怎么去把它采过来呢?那我们就用Maxwell。
01:00
嗯,就现在这个比较主流的吧,应该还是这个Maxwell啊,当然另外一个这个开啊,我之前也提到过,开呢也有用的。啊,甚至于我们以前的话就是用的这个canon啊,后来因为这个大家前面那个离线舒仓呢,哎,用的这个Maxwell了啊,所以说我们这个为的前后统一,我们就也把它改成了这个Maxwell。OK吧,行,那我们通过这个Maxwell呢,我们可以什么从你的诶MY中呢,把你这个数据的一个改动啊,及时的采集到我这个卡卡中,那也是一样的,我先把它放到一个统一的topic中,对吧?我不管你是来自于什么表的数据啊,不管你是新增的还是什么修改的,我都什么统一放到一个topic中,这就是我们的一个采集过程。好,那我能够把数据成功的踩到这个卡夫卡中以后,然后接下来我们就是启动我们的,诶,这就是我们的ods层了啊,接下来就启动我们的这个实时任务啊,就Spark streaming,然后呢,还是从你的卡夫卡中去消费数据。那消费出来数据以后呢,我们这里面还是去做你的这个分流操作啊,各种这个分流的工作。
02:01
明白吧,各种分流的处理啊,比如说你这个转换结构啊等等一些啊,那么最终我们想做到的效果是什么啊,听好了,我们的事实数据啊,因为我们的业务数据,我们就包含什么,包含你的这个事实表和什么,和这个维度表对不对,那就分成我们的事实数据和这个维度数据。好,那我们现在我们的规划是我们的事实数据,我们要把它按照以表为单位,听懂了吧,哎,以表为,呃,以表为为为基准吧,啊以表为基准,然后呢,以操作为单位。进行一个分流,那么这是什么意思呢?你看啊,我们大体来看的话呢,就是把你的事实数据,我们还是往这个卡夫卡里面去放,放到你对应的这个什么topic中,比如说我订单表的数据,我就往订单topic里面去放好,那么当然我们比如说我们的订单明细的数据,那我就什么放到这个订单明细的这个topic中,比如说你的这个什么支付的,那我就什么放到这个支付的这个topic中。理解吧,然后呢,这个收藏的我就什么放在这个收藏的这个topic中。
03:02
就以此类推呗。这个大家能够理解是吧,但其实我刚刚说的那句话,什么话呢,就是以表为基准,然后呢,以操作为单位,啥叫这个操作为单位呢?啊,其实这个东西啊,看你想不想做吧。它表达什么意思呢?你看到了啊,就像我们这个订单数据哈,我们的订单数据,那我的一个订单表中的数据,我有新增进来的数据。对吧,我是不是也会有这个修改的数据啊同学们。能理解吧,就是比如说啊,在我这个业务数据库里面,我是不是可以对我的订单表,我新加几条记录,我是不是也可以去修改一下以前的这个记录。对吧,那你不同的操作,其实对于我的这个Maxwell来讲的话,它会什么采集到你这个不同的处理。那我在这个位置的话,我也是能够识别出来的,你当前这条数据是属于订单的数据,那么我也能够知道你是新增的数据还是说修改的数据,这个我都是能够知道的。好,那最后我们在做这个分流的时候,如果说哎,你不考虑这个新增和修改,反正你只要是订单的数据,那我就统一都扔到一个订单的topic中,诶这样也OK。
04:11
如果说我们想做的更细一点,那我就要以操作为单位来去做了,比如说我希望这样子。你一个订单表的数据,如果说你是一个新增的数据,那我就专门放到一个topic中,这个topic就是什么订单。新增的topic。那如果说你还是这个订单的数据,但是呢,你是一个修改过的数据。对吧,那我就把它放到一个什么呀,叫做订单,诶修改的这个topic中,就说白了,我会把你每一个事实数据,你是新增的数据还是修改的数据,我也可以把它什么单独的拆开放到不同的topic中。就说白了,你可以什么呀,完全放到一个topic,或者说你可以分开啊,分开对吧,比如说这个是新增的对不对,这个是修改的啊,那如果你要放到一起的话,就什么新增的呀,什么修改的呀,都在一起。
05:10
好,那这个你到底做还是不做,这个从哪个角度去衡量呢?就从你后续你分析的角度去衡量,如果说你在最后对这个数据做分析统计的时候,你是有类似的需求的,比如说我想看一下当日新增订单的一些什么统计。我就只想看新增的订单的统计。或者说我只想看修改了订单的统计。这种情况下你想想,我前面给你分开了以后,那我后面是不是就好处理了呀,如果你想看新增订单的数据的统计,OK,那我就把它怎么拿过来就行了,我就从你的这个topic里面去出数据。如果说我统计的是修改的订单,那我就从这个topic里面去出数据。对吧,因为我前面把它分开了,分开以后那我就什么知道我要从哪个topic出数据了。那如果说你没有分开,你在同一个里面的话,那你数据过来以后。
06:02
你是不是还得去做一个过滤操作呀,对吧,我得过滤一下,哎,你是不是新增的,你是不是修改的。对吧,那你还得适当的在你的数据里面去打标记,我才能知道你到底是新增的还是修改的,或者说你从你这个数据中已有的字段上的去做一些判断。比如说你的什么create time对吧,创建时间。能理解吧,啊或者什么这个修改时间等等一些。好吧,好,那如果说我们最后的这个分析啊,没有说这个类似于什么啊,要区分对待的,我们就是整体看你的这个订单,然后呢做分析,不管你是新增还是修改的,我是整体做分析的,那我觉得你不分也OK,你就把它什么怼到一个什么topic中,将来只要是你这个订单相关的这个分析统计,你都从这里面去出数据就完事了。明白我的意思吧,啊,所以这句话你要去考虑啊,你到底要不要这么去做啊,你怎么做都都能说得过去啊,同学们怎么做都可以都能说得过去啊,所以说呢,我刚刚就是说以表为基准,然后呢以操作为单位啊,以操作为单位去做这个数据的一个划分。
07:07
好吧,诶,那我们这个项目的话呢,最后我是会把它分开的啊,就是新增就是新增的,然后修改就是修改的,明白我的意思吧,新增就是新增,修改就修改好吧,这个我到时候是会把它分开的啊。OK,呃,那这是我们这个事实数据的一个分流处理。那我们的业务数据里面还会有维度数据啊,对吧,这个维度数据怎么处理呢?来维度数据。其实啊,你直接扔到my soq中,你不拿出来也可以,我觉得你的维度数据就在你的my soq里面放着吧。对吧,你放到这个买so中,将来比如说诶我做下一层的处理的时候,比如说诶我想看一下你这个订单,对吧,我拿到你的某条订单数据了,我想看一下这个订单。是男的下了订单,还是女的下了订单?或者说我想看一下这个订单,诶他这个下订单这个人的这个年龄是多少,对吧?啊这个什么地址信息是哪些。
08:08
那这个时候你看一下你所要的这个东西,它里面有吗?它里面没有。它里面只有一个用户的ID对吧,或者什么省份的ID。那你是不是得拿上你的用户的ID和省份的ID,想办法去关联你的维度数据,是不是才能够把它这个数据拿出来的呀。对吧,那么如果你要去关联这个维度数据的话,那你想想我就直接去关联我的买SQL,我从我的买SQL里面把数据给他调出来,是不是也可以。对吧,所以说啊,如果说你对这个时效性的这个要求不是特别特别要求高的话,那我觉得你搁到买色中也可以,就不用往出拿了。能明白啊,因为你连麦搜狗其实相对来讲它也是挺快的啊,它也是挺快的。好呃,但如果说我们想做的更好一点的话,那我们也可以把这个维度数据呢,去做一个分流操作。那我们就会有这么几种情况。
09:00
比如说我可以往red里面去放,如果你要放到这个red中,那么它的好处就是一定是比你的MYSQL查起来要更快的,就是我从red面去读数据,我从它里面去关联数据,跟从MYS去关联数据,那一定是red的关联效果会更好。对吧,它会什么更快一点,因为它基于内存吗。对吧,但是red的话呢,跟这个买相比的话呢,它也有一个什么不足的地方,什么地方呢,就是容量问题。因为毕竟呢,它是在这个内存里面去构建数据的,所以说如果你的维度数据比较大的情况下,那你就要考虑一下使用合适不合适,它的内存中能不能把这个数据给我维护的起来,代价高不高。明白吧啊,那如果说你的容量是比较就就你的数据是比较小的啊,没有那么多,那我觉得扔到中啊,这也是可以接受的啊,因为数据量不大嘛,那我就维护到red中也是挺好的。对吧,这是一种方案,好,那如果说诶确实我的数据量是比较大的啊,确实数据量是比较大的,那这个时候怎么办呢?那我就考虑数据呢,还在你的这个MYSQL里面放着。
10:10
啊,数据呢,还在你的MYSQL里面放着,因为毕竟你的MYSQL是能够维护的了这么多数据的,但是你从MYSQL查数据吧,稍显慢一点。那怎么这个问题怎么优化呢?我可以这么去做,我在你的MYSO的前面,我再搞上一个RA。让这个帮你做缓存。就是我将来去关联数据的时候呢,我先关联RA,如果说red中有它里面这个缓存的数据,我就直接从red去把数据拿走,如果说没有的情况下,我再跑到你那买SQL去关联数据,就说白了,让red呢帮助MYSQL挡到。而我们经常活跃的数据,我们应该在里面都会有,除非一些什么比较冷门的数据,比较偏门的数据,比如说一个用户N年都不访问。对吧,突然来了下了个订单,那大概率情况下,这里面是没有他的信息的,那你只能是走买SOHO,那你偶尔走一次买SOHO,这个我们能我们也能够接受。
11:08
明白我的意思吧,这样的话呢,诶你数据量大,那你拿MYSQL去承载,但我的red呢,我可以把你里面的一些诶活跃的数据,热点的数据维护到这个red中,帮你做一个缓存。对吧,这种方案也可以。好,那如果说我的数据量呢,再大一点。对吧,就是大到这个买SOHO的可能有点。这个支撑不住的时候就力不从心了,对吧,就是我想去维护这么多数据,但是呢,着实啊,压力比较大的时候,那我们就可以考虑把你的维度数据呢,往另外一个主件里面去放谁呢?比如说h base。对吧,就目前我们的项目中是没有用到h base的,但是你们后面的那个项目中是会使用这个h base的,我把我的维修数据我扔到h base中。对吧,因为h base啊,它其实查起来也会很快,因为它毕竟它也是一个脑嘛。
12:04
对吧,他查的也比较快,但是对于这个跟比的话呢,它还是稍显慢一点的,但人家容量大呀,这容量超级大,你就不用担心用了h base有存不下的数据啊,不用担心这个事儿,因为它底层用的是你的,用的是你的HDR,没有什么存不下的。对吧,那同样的道理,你数据量诶,他能帮你搞定了。但是呢,查的效率我们可能说,哎,你这个查的有点慢了啊,我不太满意怎么办呢?同样我在你的h base前面搞一个。对吧,我把你的热点数据呢,在red里面做一个缓存,那我将来去关联的时候,我还是先走你的red,如果red有,那我就直接关联成功了,如果red没有,我就跑你的HP里面去查一次。那么从它里面查的话,一定要注意是要通过你的RK去查啊,同学们,因为只有RK它才能够保证你的效率,如果说你想通过别的方式去查,那对不起。它的性能是很慢的。
13:01
理解吧,啊,所以说我们这个整体的方案就是你的维度数据啊,看情况,如果说维度数据比较小,那我就是直接扔到RA中对吧。然后去做,如果说维的数据呢,相对比较大,我的red呢,可能维护起来这个压力比较大了,那我可以把数据呢,放到你的MYSQL中,然后呢,在MYSQL的前面呢,搭上这个red的缓存。如果你的数据呢,诶更大了,对吧,就有可能我这个my soql的话,它这个刚刚好能够维护了,但是呢,从查询角度来讲的话,因为数据量比较多了,它不能够及时响应了,那这个时候我就考虑把你的数据呢,扔到我的HV中,对吧,然后呢,它的性能会稍微慢一点,那我在前面也是搭上这个red的缓存。理解吧,就这几种方案我们都可以去选择啊,就看你的这个实际情况是什么。明白了吧,好呃,那目前我们的项目的话,我们的数据量肯定没有多大哈,我们就直接什么采用这个就译成就搞定了。对吧,那么大家这个后面的项目中啊,会使使用到这个h base。
14:03
对吧,就是会涉及到这种方案的,OK吧,现在我们就不说那么多了啊,因此我们的这个维度数据这个分流啊,我们要把它分流到。中啊,你可以选,可以选MYSO,可以选h base,但是目前我们选的是。对吧,所以说整体的这个分流操作就是你把你的数据呢,诶先保证能够踩到你的卡夫卡中,踩到卡夫卡中以后呢,我们就做分流,分流的时候呢,我要去判断你是事实数据,OK,那我就往卡夫卡里面再接着放,以表为单位,然后呢以表为基准,然后呢,以操作为单位往里面去放,对吧?然后呢,如果你是一个维度数据OK,那我就什么直接怼到RA中就OK了,那最后处理完成以后呢,这个就是我们的DWD层,这就是我们的dim层。明白吧?啊,这是我们这个事实的明细啊,这是事实明细,然后这个是你的维度啊,维度明细。OK吧,好,把这个图来,现在又要放到你的脑子里面了啊,因为接下来我们的操作就要围绕着这个图来展开。
15:07
好吧,行,先说这么多啊。
我来说两句