00:00
好了,同学们啊,那咱们接下来来看一下咱们这个kding的一个特点和咱们这个kding4.0的一个升级,好吧,那这个特点啊,其实咱们在这个课程介绍里边,我们基本上都讲过了,咱们这个king的一个主要特点,它包括什么呀?支持咱们这个标准的S后接口啊,我还支持超大规模的数据集,然后呢,我这个速度比较快,它是一个亚秒级别的一个响应,然后呢,我这个K点也可以搭建集群,它有一个可伸缩性,包括这么一个高吞吐力的这么一个特点,最后啊,我这个K里还支持标准的数据库连接,所以说啊,我可以继承各种BA工具。可以吧,啊,所以说这几个特点我们简单看一看就可以了,第一个就是标准circle接口,我这个K点是以标准的circle口作为对外的一个接口的,也就是说我们可以支持写circle口来查询他们那个数据,好吧?啊,第二个就是超大数据集啊,我们当前啊,这个kidding对于大数据的一个支撑能力,可能是目前所有技术中最为领先的。早在这个2015年啊,这大概七年前了,是吧,我们这个eBay它的一个生产过环境中,我就支持啊,百亿记录的一个秒级查询,就使用咱们这个K点啊,对于买百亿记录,咱们做一个秒级查询啊,那之后啊,在咱们这个应移动的应用场景中,我就有了千亿的记录秒下你那个案例,所以说啊,咱们这个K点只要你们公司玩好了,这个速度是相当快的,并且咱们这个数,这个数据规模也是非常大的啊,那再往下啊,就是一个亚秒级别的一个响应,我这个K点拥有优异的查询速度啊,这一点是得益于一聚散的,因为咱们这个K点啊,在查询之前,咱们有一个Q补构建的过程,而咱们这个QB构建就是咱们的预计算,就是我提前啊,利用这个时间换这个速度啊,利用这个空间换时间啊,我提前把这个结果就所有的我需要同这个结果我给它查出来啊,存到咱们这个power文件里边,然后呢,我将来再从这个power文件里边查的时候啊,基本上就是秒秒秒。
01:59
回结果啊,描述结果啊,所以说咱们这个预计算这么一个概念啊,是非常先进的,好吧,啊,就是很多复杂的计算,比如说连接呀,聚合呀,分组啊,是吧,在咱们这个离线的预计算中,也就是说我那个Q5的构建过程中,我已经完成了,那这个啊,就会大大的降低咱们查询时候我所需要的一个计算量,提高了咱们这个响应速度啊。
02:21
然后呢,我这个K点还支持这么一个可伸缩性和高速动力啊,单节点K点我可以实现每秒七准查询,我还可以结合组K分布式期的服务来搭建咱们这个kid集群,我这个速度会更快,是这样的啊,那除此之外呢,我最后一个特点就是支持咱们这个BI工具啊,Kidding可以与现有的BA工具进行进行集承啊,其中包括如下内容,其中啊,咱们的ODBCDBC这种协议我都支持的啊,那既然支持这种协议,那基于我这两种协议的所有的BI工具我都支持,就比如说table AU啊,Excel啊,Power BI啊是吧,还有咱们这个GDBC的这么一个BT,还有还有什么S库等Java工具我都可以支持。
03:02
啊例除此之外呢,我还支持我的一个API啊,另外你既然支持API了,我就可以与这个javascript和咱们这个外部软院进行继承,那除此之外呢,K点团队啊,还专门贡献了一个插件,叫做ZB这么一个插件,而咱们这么一个插件啊,也可以用来访问咱们的K点服务啊,其中最后啊,咱们还讲咱们这个K的4.0,它还讲了一个MDX,这个MDXMDX啊也是一个新的一个BI插件,它可以对接咱们的Excel,用来分析咱们这个K的那个数据,好吧,我们最后都会讲OK啊,那这个这是咱们K那个特点。那看完咱们这个K点的特点以后呢,那咱们接下来再往下啊,看一看咱们这个K点4.0它都升级了什么东西,因为咱们说完了咱们这个3.0~4.0,咱们这个K点做了一个很大的升级,那我们在这一章节就重点看一看咱们这个K点4.0它都升级了什么?好吧,阿尔法吉K点4.0是继咱们这个3.x之后的一个重大的版本更新。
04:00
它采用了全新的一个Spark构建引擎,和咱们这个park作为一个存储系统,同时呢,我也是借用咱们这个Spark作为咱们的查询引擎,也就是说啊,我这个K420完全抛弃掉了MR,不再用那六啊,我全面给它设级成了Spark啊,大家都知道啊,咱们这个Spark是一个分布式的一个查询和一个计算框架啊,它的速度要比这个MAP6要快的好吧?啊,那我们看一下啊,King4.0的第一个版本叫K04.0这个什么al尔法是吧,它是于咱们这个2020年7月才发布,所以说咱们当前讲的这个课程还是相当新的啊,发布了没没没几年,也就一年多一点啊,那此后呢,我相继发行了咱们这个K04.0贝塔以及正式版本。那首先先介绍一下啊,咱们这个4.01个主要优势,咱们这个K04.0啊,是完全基于Spark去做构建和查询的,它是能够充分的利用咱们这个Spark做一个并行化,向量化和一个全局动态代码生成等技术啊,去提高咱们这个大数据场景下,我查询和这个构建的一个效率,那么接下来就从咱们这个数据存储,构建引擎和查询引擎三个方面来聊一聊咱们这个K赛的一个升级,那第一个啊,就是这个数据存储。
05:14
咱们这个大家都都知道啊,如果学过咱们这个K3的小伙伴都知道,K3.0是使用那个h base啊,作为咱们这个存储结构的,因此我们可以称之为kid on base。而咱们这个4.0就完全砍掉了HP啊,我底层啊使用谁啊,使用咱们这个PU作为一个存储文件,因此我们可以称之为k on PU,那首先来看一下啊,咱们这个on h跟这个on part它的一个对比。哎,如果你是on hps,那这样一来,咱们这个q point,就是我我qbe的每一个q point,它的一个数据都是存放在我hps的一个表里边,我hps一个segment是吧,就应我一张HP表L啊,就是我K里边的一个切片数据,切片就对应我H1张HL,那我这个查询下压的这么一个工作是由这个h base它的一个斜处理器进行处理的。
06:05
因此啊,咱们这个hps它不是真正的列存,并且对咱于对于咱们这个o lap而言,我的吞吐量并不高啊,所以说啊,咱们这个K04.0,把咱们的HP替换为了八,也就是说我把你所有的数据按照文件去存储,每个sment我都存在一个对应的HDF目录。所有的查询啊,构建啊,都是直接通过读取读写咱们这个文件的一个方式,不再经过h base这么一个写处理器了啊,虽然对于咱们这个小数据这个查询性能会有一定会有一定损失,但是对于咱们这个复杂查询,它带来的一个提升是非常厉害的,更可观更值得的,好吧,那咱们这个存储引擎,由于咱们这h base是吧,换成了帕,所以说啊,咱们这个K点对于咱们这个数据存储它的速度更快了,是这样的啊,那第二个呢,构建引擎。在咱们这个K3.0里边啊,我一般都会使用MR作为咱们这个Q5的构建引擎,去逐层构建客户,因此它的速度比较慢。
07:06
而在咱们的K4.0里边,我的构建引擎换成什么呀,换成了一个特定优化过的一个SPA引擎,我这个步骤呢,也不再是逐层构建了,我这个步骤减为了两大步,我第一步对于进,对于咱们这个客户进行什么呀,进行一个资源探测。就是收集一下啊,咱们这个构建Q我所需要的一个语言数据信息,那第二步呢,就使用咱们这个Spark引擎去做一个计算和这个构建,我有效的提升了咱们这个QB的一个构建速度啊,因为咱们这个Spark啊,本身比这个MAP6就快,再加上啊它这个MAP6是一个逐层构建,而咱们这个Spark呢,直接就分为两步啊,第一步是资源探测,第二步就是QB构建啊,速度是明显变快的,好吧,尤其是你的这个数据量越大,我这个速度提升它越明显啊,第三个啊,就是咱们的一个查询引擎。我在K030里边,我的查询完全依托于谁啊,就是咱们这个HP的些处理器和咱们那个什么Kate这么一个引擎,这就导致啊,当咱们这个数据从这个HP读取以后呢,如果你想做聚合排序,我就会局限于咱们那个查询服务器叫k server这么一个单点的一个瓶颈。
08:19
而K的4.0呢,会把咱们这个。查询引擎转全部转化为了这个SPA circle的一个data frame作为咱们这个查询引擎,那得益于咱们这个sparkrk的一个分布式的查询机制,所以说啊,我这个KN4.0,我的查询速度已经有了不少的改善啊,尤其是咱们那种下压的circle,就比如说啊,我在我当前的QB里边是吧,查不到,我要把这个circle给它下压,下压下去,经过咱们那个路由层,我直接去那个have里边查询啊,咱们这个K4.0的速度明显变快啊,有了这个质的变化,好吧,啊,那咱们这个K点的一个特点,跟咱们这个4.0的一个升级。我就给大家讲这里好吧。
我来说两句