00:00
如果说那么多,我简单给大家举个例子呗,就比如说咱们刚才提交的这么一个案例。啊,咱们前面演示这个案例没看代码对吧?呃,带大家简单瞅一眼啊,首先我给大家提供的代码里面分主要分为两个包,第一个叫S,第二个是tenny,也就是说这个是造数据的。后面这个就是咱们一个一个的调优案例。啊,我都写好了,大家直接看一下代码结构,然后去跑就可以了,那这边呢,我这边不是简单的照啊,这边我说你看各种各样的实体类,然后呢配置。我这边可以配置什么呢?啊,日期啊呃,条数啊,要不要有倾斜的数据,这边是通过我的设计是可以产生倾斜数据的,对吧,那再比如说倾斜率达到多少。啊,都可以来调,你改配置就行。然后呢,最大的设备ID多少让他去生成,还有等等等等优惠券呢,商品ID有多少啊,等等等等一大堆设置,你在这个类改就行了啊,你自己去改。
01:06
我就没有写成配置文件的方式,因为这样可能有的。呃,提交打包的时候又找不到什么配置文件路径啊,又不会整啊,省得大家麻烦我直接写死了啊,你就改个代码重新提交好了。那最后经过咱们的一系列逻辑,他才去生成的啊。啊,这边我写了一堆逻辑啊。好,那生成的数据长什么样,大家给大家看一下,这个主要是模拟了咱们前端买点产生的Jason数据啊。比如说这个启动日志,它就会会有空本,还有什么地区啊,手机型号啊,操作系统啊等等等等的一堆信息,还有一个启动日志。还有一个时间戳啊,这一类数据叫做启动日志,还有一类叫页面数据,页面数据有一个空,有一个曝光。
02:02
曝光不一定有啊,但是这个配角是一定有的啊,然后还有有时间戳,可能还会有什么action啊,就用户的行为。啊等等啊,照的是这两类数据。给大家看一眼格式,然后呢,我这个这个就是照的数据了。你放心,我写的这个的话。呃,应该可以达到每秒钟单并行度接近1万条啊,没什么问题。当然跟你资源性能有关系啊。行,那这边主要咱们跑这个UVDEMO啊。这个其实是什么呢?计算UV嘛,咱们是不是根据设备ID就mid呃去重。去虫之后是不是靠一下。对吧,就得到了一个实时的UV值嘛,呃,那这边很简单,你看一下代码执行环境,我这边是故意把这个操作链给打散了,故意的啊,就是咱们方便去观察,那这边是一个checkpoint,我用的是。
03:04
呃,基于内存的这个状态后端啊,没有用Rose DB啊,那这个po是存在HDFS,那其他的什么间隔就是几秒几秒的。那这边大家。看adds这边就是自己造的数据。这种就相当于说给大家看了一下怎么自己造,又不是随机的,而且是跟你实际生产环境,数据结构你要保持一致嘛,才去测嘛。然后后面就是一些简单的处理,呃,新老用户修正,当然这个不写也行啊。那后面我怎么实现的UV呢?很简单,我按照设备ID做了一个什么呢分组。分完就同一个mid到一个组,再之后呢,做了一个过滤,过滤里面我定义的一个状态,也就是说每个设备ID我存了一个状态。也就是说,呃,判断他来过我就不再往下了,也就是说我始终只保留第一条mid,这不就去重了吗?啊,当然这是呃,咱们实际计算UV。
04:07
这只是一种实现方式啊,还有很多很多高性能的,节省资源的,什么用位图啊。啊,用什么基数统计啊,Hyper log啊,对吧,等等等等那些,比如说用呃,几十K的内存大小就可以统计啊,几亿的UV值,像那种那些之前理论课应该也都介绍过了,我就不讲了,这边这个案例简单一点,咱们就这么来算啊。然后呢,就是。推完重我就是再reduce一下就得了呗,把它累加起来。啊,每一条数据都转换成一个一,然后累加起来做一个打印,没了,逻辑特别简单啊,说白了就去重,去重完统计一下没了。好,这个是代码,那接下来呃,咱们来试一下吧,自己造的数据,现在并行度是五啊。
05:01
自己造的数据,我们来感受一下。这跟刚才那个是一样的啊。如果你提交价包会报一个什么类加载器的错误,那个是一三版本开始的一个一个问题啊,那个不影响你使用,对了,这个忘给你们提一下啊。呃,你加上这一行配置就行了。不,不去检查这个类加载器就行了,把它置为force不影响你使用。他这边的实现有点问题。那个你百度一下也行,那什么内接的,其实那个不影响使用啊。好了,现在已经执行。来,我们点开web UI。呃,那我们看看有没有反应了。
06:09
大家,嗯。简单看一下,你看是不是有法尼亚了?是反压对吧?啊,那至于反你要怎么看,咱们下一个章节后面章节来具体介绍,那至少咱们现在可以看到,你看这个繁忙97。那后面这些是正常的。至咱们可以看得出来吧,那么如果是的这个是的能不同的映前子前的个繁忙情况,还有反压情况,如果是早期版本,你就随便点一个点一个这里的被压。早期版本是你点了才会去采集它的一个反压状态啊,你就看看,反正至少我们目前能看到已经有反压了吧。对吧,这有79的反压,这77差不多,那我们看一下接下来怎么看呢?我们说第二步看什么看source。
07:01
嗯。好,我们点开哪一个呢。选中之后选这个sub task。选中之后,这里是不是有一堆信息啊,数据接收量,数据发送量,有一个是条数,一个是数据量大小,对不对。那这个SS没有没有接收,那肯定啊,他是往下负责往下游发的嘛。那我们看一下单并行。你瞅一眼大概多少条?是不是已经发了这么多条了?对吧,那你怎么看每秒钟呢。你是不是有指标啊,同学们。来看matres,在这里应该有一个什么per second。我们找一下啊嗯。往后翻吧,哎,你看records。
08:00
Out out是往下游发嘛,Out是发送嘛,你看它每秒钟发几条点一下。这个是一个子任务啊,前面这个这个大家应该会看吧,前面是不是有个编号零啊,你再往下翻是不是有一对吧,再往檄翻有二有三有四,这个代表的是什么?子任路的编号,咱们并行度是不是五啊。呃,再给大家回忆一下啊,你看。子任务吧,他是不是有个ID啊,五个并行度嘛。对吧。他就分别对应不同的子任务来看的这个指标,那这边你不信的话,你再继续找。Per second大概都瞅一眼,这个是四编号为四的子任务,对吧,有一个number out。嗯。Record out对吧?零编号的这个子任务啊,你也看,再看几个number record out。
09:03
Per second,咱们主要看的是每秒钟啊,每秒钟。啊,我就点几个就行了,看一下数据量啊。这个呢,7000多7000多,7000多7000多,他再怎么变是不是都七千七左右啊,那这个应该也是七千七嘛,看另一个子任务,这也是7700。7700。七千七千多,也就是说我这边是不是大概7000~8000了。对吧,好,那就算你按7000来算。1000了。一每我说。我写到这吧,现在是7000条每秒啊。瓶颈就是7000条每秒。他们并行。
10:03
那个时候你要结合你实际,呃,生产环境呃。高峰期的QPS。这个是需要你,因为你你不同的企业,不同的数据来源,它这个值肯定是不一样的,但是你是肯定会知道的,这个是最基础的一个指标啊,比如说咱们刚才举的例子是2万条每秒。对吧。或者说呢,咱们给个3万条每秒。是懂的呀啊。就最高峰。啊。大概就3万条每秒,那能不能顶得住并行度给多少呢?你可以算一下,是不是3万除以7000呢?啊,一出就四点多呗。四点几嘛,那我们说你给个五就得了呗,对吧,如果你还不放心,你四点几乘1.2肯定是六七左右嘛。
11:00
啊六或者七,你你这个时候并行度你就可以给多少,给个六就行了呗。对吧。那所以呢,你一开始可以给一个小的并行度啊,十以下你就测。结合你实际的QBS。那这个时候呢,你不就。比较一个相对比较优的,最优的一个并行度设置就是这么来的。另外,为什么说每个任务不一样呢?除了代码不一样之外,跟数据也有关系。你想想啊,如果你的数据是只有两个字段,或者说你一条数据就是ABC。呃,1万条。每秒钟1万条跟你。一条数据ABCDEF特别特别长,然后1000条。也1万条吧,这两种情况是不是处理起来效率不一样对吧,所以你不能单纯根据这个每秒钟的数据量去算,你要先什么,先测一下。单行度的上限,那这样的话,咱们就不去关心数据长什么样的对不对啊,不管你是长还是短,你长你长你短你短,你也不用知道它的长短,但是你要知道它的深浅,对吧。
12:13
好,这个是全局设定,呃,那么另外呢,就是一个原则,就是什么,如果你的数据源是卡不卡。那我觉得。呃,你优先就按照什么按分区数来就行了,比如说卡不卡,你消费的topic分区数是五,那你直接就并行度给个五就得了。那你简单去验算一下,大概能扛住那就OK了嘛。对吧,这这都是非常简单的啊,非常简单,那一般而言,咱们大部分的任务应该都是十以下。啊,只有一些,呃,大厂。呃,数据量一天能达到PB级别,然后呢,并发比较高,QPS极其高的情况下,可能他们的这种那个并行度都不是十这种量级了,可能就是大几十甚至上百。
13:00
对吧,咱们知道默认最大并行度都是128啊,甚至他们还会把那个。默认的最大值,比如说调成256啊之类的。但一般来讲,大部分大部分的企业应该不至于啊,大部分还是十以下。
我来说两句