00:00
好了,同学们啊,那咱们接下来咱们这个Q补构建好以后啊,大家可以点开这个下拉箭头啊,查看咱们这个Q补的一些详细信息啊,首先啊,第一步就可以查看咱们这个Q补的一些信息了啊,大家可以在这分明别类的看一看,咱们这个Q补是怎么设置的,那这个第二步呢,我们可以查看一下咱们这个Q补它底层的一个circle啊,大家可以看到啊,在我们这生成这么一个circle,而这个circle就是根据咱们这个QB的一个设置,它自动帮咱们生成的是吧,它是按照咱们的这个EP啊,Inner join上咱们这个dept。然后呢,你的质问条件就是EP的编号啊,员工编号,部门编号,等于咱们这个DP的部分编号是吧?然后呢,他在这查了一些字段啊,查了一字段,那这个就是咱们这个QB啊,它的一个底层参考,好吧,然后这个jeson呢,就是咱们这个QB啊,在咱们这个K的底层,它是以什么形式保存的,好吧,那这种东西啊,就属于原数据了啊,原数据。这个noification啊,是一个通知列表,咱们当前没有设置,所以它是空的,那这个owner呢,就是咱们这个QB的一个所属主啊,咱们这个QB属于咱们这I这么一个用户,好吧,最后一个啊,Star什么呀,就咱们这个Q部它底层的一个存储信息,咱们这个QB是吧?它是存到哪啊,存到咱们这个HDS上有一个segment是吧?咱们当前这个sgament是不是一个负build呀,这个副build叫什么呀?叫全量构建啊,为啥叫全量构建啊,因为咱们设置这个Q5比较简单,咱们那个员工表,咱们那个EP表是吧?咱们的作为一个员工实时表,而咱们那个表它没有分区,那对于一张没有分区的实时表,那我每次构建啊,那我肯定是什么呀,是这个全量构建,这个都不用管吧,啊这个啊肯定是全量构建。
01:47
OK啊,那咱们这个既然啊,咱们这个Q补啊构建好以后呢,那咱们接下来就可以在这个地方啊写这个circle来查询咱们的这个cub了,注意啊,在这啊文档上给家提供了一个小案例,就咱们这个haveve和这个kidding它的一个性能对比,那由于咱们这个kidding啊,已经按照这个cube咱们已经算完了,那所以说啊,咱们这个have那肯定是跑不过kin的,这都不用想的,应该知道吧,你看我有这么一个需求,就是根据咱们的部名称。
02:16
来统计咱们员工的一个薪资总数啊,那这个时候我就不用写了吧。我们得按照咱们的这个员工表啊,跟咱们这个部门表是吧,做一个准啊,然后呢,咱们的一个连系条件就是员工表的部门编号等于咱们这个部门表的编号,然后呢,按照谁呀,按照这个部门名称,你给我勾BY,那所以说咱们前面就可以查谁呀,查一下咱们这个员工,呃,部门编部门名称和咱们这个sum sirary啊,也就是说啊,这么一个circle啊,你给它粘你你给它粘贴过来,粘到咱们这个kidding的这么一个官方界面,这个地方咱们就可以执执行了,好吧,我把这个circle我简单给你格式化一下啊,大家看的稍微清晰一些。啊。咱们就可以啊,按照咱们的这个员工表,哎,转上咱们的这么一张部门表可以吧,转上咱们的一个部门表,然后呢,按咱们的这个员工表的部门编号,等于咱们这个部门表部门编号,然后呢,我按照我的部门名称,我做一个勾,咱们分组统计是吧,求一下咱们这个部门每一个部门的总工资,那这么一个circle啊,你就你就可以给他,呃,咱们CTRLC复制一下,咱们点开submit提交。
03:26
啊,你发现啊,咱们这个K点就开始跑起来了啊,他第一次稍微慢一点啊,因为他要读取一些血数据,好吧,他正在执行,大家稍微等待一下,你看啊,那这个时候啊,很快我们这个呃,结果就出来了啊,因为因为是第一次啊,他需要收集一些元素信息,跑的比较慢啊注意啊,咱们这个一旦成功了,你可以打开谁啊,你可以打开咱们这个雅安。在们这个牙上啊,他用的是谁啊,他用的就是咱们这个spider这么一个绘画任务去跑的,那怎么证明这个问题呢。大家可以点开这个spider任务的这么一个什么呀,这么一个application master,大家打开啊,在我这个application master里边,你会发现它打开的就是一个SPA circle这么一个页面啊,由于我们刚才执行了一次,所以说啊,我在我这个SP任务里边,我已经有这么一个已完成的任务了,看到没有啊,已经完成了drops啊,那咱们这个任务啊,一旦跑完一遍以后呢,你再执行它的速度就非踌快了,大家看一下啊,我我我接下来把这个circle我再次点submit提交,你看咱们第二次基本上就秒回了啊,就是我我我零秒就出来了啊秒回结果。
04:30
可以吧,那咱们接下来你再打开咱们这个spider刷新。啊,由于咱们那个跑的是同一个任务是吧,所以说啊,咱们这个spider它并没有增加,那我还以那我还可以写个别的啊,你就比如说啊,在这个地方啊,我刚才是按照这个部门名称来搞拜的,那咱们那个度量字段以外呢,除了名称我是不是还有谁啊,我是不是还有一个那个作呀,我就可以啊按照我这个job,我这个岗位我做一个分组计是吧,我求一下我这每个岗位的它这么一个工资和也可以吧,同学们,那接下来我就可以把这个job也拿过来,咱们直接CTRLV那这么一个circle口啊,你再执行。
05:07
哎,你发现啊,咱们这个岗位按照每一个岗位做了一个工资统计是不是也出来了,那你一旦跑一个三好啊,那在咱们这个spider里边,你刷新他应该就会多这么一个已经完成的jobs啊,通过这个啊,就可以说明咱们的这个spider这么一个长期在后台运行的这么一个任务,它就是供咱们这个K点做查询使用的啊,这个东西啊,就是咱们这个kon的一个查询引擎,而这个呢,是咱们的这个构建引擎啊,这两个任务是不一样的啊,只不过啊,咱们这个查询也好,还是构建也好,我这个K的4.0用的都是Spark,大家把这个好好了解一下好吧。那咱们大家发现了啊,就这么一条circle在咱们这个,在咱们的这个K上跑,它需要跑这个0.63秒,它是一个亚秒级别的返回啊,那如果说你在你的那个have里边跑,那这个速度肯定比较慢了,大家都知道啊,咱们这个have当前是不是基于MR啊,咱们并没有调它是MR,那它肯定速度慢啊,你比如说啊,我把这个circle我拿到我的have里边,大家可以跑一下。
06:11
啊,他怎么的也得几十秒吧啊。并且啊,咱们这个数据量还是比较小的情况下,咱们这个氦王LMR速度都需要几十秒,那如果在公司里边,咱们这个数据量大起来是吧,你在have里边跑这么一个circle口,基本上需要半个小时以上啊,半小时,而在咱们的K里边是吧,都是压秒就是秒啊,一秒就返回啊,所以说啊,咱们这个K的性能肯定是要远远大于have的啊,这就这这个概念啊,也就是咱们这个K可以作为一个计息查询这么一个工具啊计息。查询哎,这么一个工具去使用的原因,好吧,啊,你看咱们这个咱们这个have是吧,用了38秒才把咱们这个按照各岗位啊统计的一个工资和给他求出来,咱们这个答案肯定是一样的啊,大家可以对比一下。
07:00
在你这个have里边求的跟咱们这个K里面求的,它这个答案6000是吧,4150 8275,五千五千六,这个答案肯定是一样的,只不过啊,一个这个返回速度是压秒,一个是38秒啊,并且啊,咱们这个数量比较小啊,如果数量大的话,咱们这个速度差异会更大。好吧,那所以说啊,咱们这个have跟K点的一个性能对比是没法比的,好吧,因为咱们这个K点是预计算嘛,它提前把这个速度啊,已经给你算好了啊,所以说它的速度肯定比较快,好吧,这是为什么说咱们这个KD是一个亚秒级别的响应啊,这个0.63秒就是一个亚秒,就是不到一秒我们就可以出结果啊,就这么一个意思,好吧,那咱们这个KLY和have的一个性能对比,我就给他讲到这里好吧啊。
我来说两句