Elastic Meetup 2021 深圳站原创

尊敬的各位来宾，ES社区的小伙伴们，大家下午好，欢迎来到由ES中文社区、腾讯云和云家社区联合主办的2021年ES深圳活动，我是大数据产品中心的运营孟明玉，也是本次活动的主持人。E的生态发展已经接近十年的时间，腾讯云和EL官方合作已有两年，今天我们有幸和各位社区的小伙伴们相聚在腾讯，共同探讨elastic search最新最前沿的技术。今天的活动我们每位讲师的分享时间大概是30分钟，问答环节设置十分钟，分享的间隙会有抽奖活动，请大家踊跃参与。在活动开始之前呢，首先请我们ES中文社区深圳分会的主席杨振涛先生致辞，大家掌声欢迎。

首先欢迎大家一如既往的来支持我们社区的活动。大家从今天的这个现场。也能看到，呃，环境是持续的在变化，对吧。但是社区的发展就像ES本身一样，持续的努力可靠啊，即便昨天我们听说了，哎，像南山疫情又有点情况，对吧？今天依然是开除万难，依然给大家提供了这样一个交流的平台。另外我特别想分享的一点是，特区深圳经过几年的发展。记得上一次还是上，上一次还是在。呃呃，盛南大道那边对吧，场地可能没这边的高大上。今天从硬件来到我们活动的组织都持续的上一个台阶啊，我们社区本身的发展呢，也是在上台阶啊，同时呃，我自己在这个社区的活动参与方面呢，也投入比较有限啊，所以这个健力棒呢也持续的。

呃，交给新来的同学啊，那今天的活动呢，全程都是由我们，呃，社区新纳入的新成员啊，王华一手来策划和组织今天的这个活动的啊，那等一下他也会给大家做一些小小的分享，介绍一下我们社区的一些最新的动态，特别是腾讯和腾讯云在这边对社区的一些参与和支持。啊，那最后也希望大家在今天的活动中。包括我们线上的各个技术学E。有所思考，相信下一次活动有更多的同学能够参与我们的分享和交流，谢谢大家。

感谢涛哥的精彩致辞，那下面有请ES中文社区的深圳分会副主席黄华先生也是本次活动的发起人，为大家介绍ES社区的发展进程，大家掌声欢迎。呃，感谢各位，今天来参加我们的，真的是非常的不容易。介绍下自己那个果经那个班一些。呃，经常这个头像会的这些，呃，这个是不是军方的一个，所以我提交的他们会非常仔细。

呃，接下来我跟大家分享一组数据，那么这组数据里面呢，左边呢，这个是我们整个社区里面的这个下个的发展的趋势是非常的火爆的。因为我们整个sta社区里面的这个面，在整个大数据领域是非常的越广，不光只安全，包括我们的可观测性，在大数据领域是那个，呃，可以说覆盖的那个场景是非常的丰富的，所以才有今天这么庞大的一个下载的那个量。然后我们整个社区呢，发展的是非常的迅速的，非常的迅猛，我们整个密的话，全国有96个ES，一个城市大约有5万多的人参加了我们整个一达活动，当然也包括今天现场到到现场的，以及我们线上的小伙伴们，整个社区的话有10万多的用户，我们中文社区的话是包括台北在内有九个城市，他们会近定期的举办我们的力大，包括我们今天的深圳。

呃，最后是我们的云，是我们的未来，所以我们还是拥云，然后所以讯云呢，在两也跟S商合作。那个当然那个腾讯不是白开社区，腾个专门的这个E那个内核团队，所以他们呃，那个社区有一些持续的贡献，目的话是呃，整个腾的E团队是整个全第三贡献的。好，那我今天就介绍这么多，把时间更多的交给我们的专家，谢谢大家。

好的，感谢黄华老师的介绍，那么下面就正式进入到我们加班分享的环节，有请今天的第一位讲师，来自腾讯的专家工程师毕山老师带来腾讯search压缩编码优化实践，大家掌声欢迎。

嗯，大家下午好，呃，我先简单自我介绍一下，我叫毕杰山，嗯，在社区里面我是个新人，去年加入腾讯，呃，之前过来之前是华为做了多年的。啊，今天我们现在开始我们的分享，今天分享的呃，主体是腾讯E压缩编码优化实践，嗯，今天其实想分享的内容挺多的，涉及到很多的一些，呃，技术原理方面，呃，但是时间有限，所以可能会走马观花，但希望大家能够有所收获。嗯，我们先来开始，呃，就是今天的知识，今天的目录啊，就包含三部分，第一部分的话就我们先看一下问题技术背景，第二部分是我们的整个系统性的优化思路，呃，最后我们会介绍我们下一步的一些重点工作。

腾讯的主流场景的话，其实都是一些日志类的一些场景，嗯，这个可能会占了在我们的场景里面占了非常高的比重，现在的呃，规模已经达到了B级别。嗯。存储期的话，基本都是七到30不等的，存储介主要是以S主要读。当前最主要的矛盾就是其实用户期望能够更长时间的数据。但是呢，因为基于。呃，因为GD来分的话，这个非常的成本非常的昂贵，所以呢，我们在这个如何降成本方面其实做了很多工作。

嗯，这是关于如何降成本的一些可能的一些思路啊，第一点就是我们去寻求一些，去寻找一些更优的一些机型，就是它的，呃，单基地的存储的成本会更低，然后这个可能主要这个不涉及到多少的开发工作，主要是一些工程方面的一些工作，然后第二方面的话就是。呃，关于底层这一块的一些文件格式的一些优化，我们希望通过更高效的一些压缩编码，能够去降低它的存储空间，就是说我同样的文档数量，我在底层会占的存储空间更少，或者我同样的机器数量，我希望能够存更多的更长周期的一些数据。第三方面就是关于架构方面的优化，就是集团与存储分离，这很多公司其实都已经做过这方面的一些实践，这块呢，因为涉及到一些架构上的一些改动，可能如何做到对应用无感知，这里也存在一些技术挑战，这是我们也呃当前正在做的一项工作，呃，但不是今天分享的内容啊，因为呃，关于压缩编码这块的优化的话，其实是对架构，它是当前架构上的一个。

衍生而已，所以它会对应用是无感知，是非常友好的。呃，我们这里需要讲一些基础的内容，因为接下来讲的这些优化点的话，如果不做这些铺垫的话，大家可能不太了解。嗯，我们知道在呃，ES的底层每个分片里边，它其实是有一个个ment构成的，Ment的话，它有我们去观察它的一些文件，呃构成的话，你会发现它其实有多种类型的文件，这里面有行款文件，行可就是我们的原始的Jason数据，呃，它存放的地方。

还有列存文件，列的话，其实它是按照每一个列去组织的，这个主要是用来来做一些高效的一些数据分析啊，比如说一些聚合查询，第三部分就是索引部分，索引部分的话包含了就是我们平时用来呃，我们用来检索的一些关键词，就是一些分词的一些信息，还有就是我们的一些呃。所谓的拉链就倒排索引这一块，就是每一个关键词，我关联了哪些文档列表啊，这些信息是索引方面。我们，呃，首先详细调研了一下我们的底层的文件类型的构成。我们主要是调研了一些比较，呃，一些大客户的一些大集群场景。我们发现这是行程文件。还有。索引字典文件，还有列存文件，这它的这三部分加起来，它的占比其实非常重的。

嗯，当然可能在不同的不同的一个业务，它的特点不一样，它的部分的占比就会存在一些出入。但。呃，从这个调研来看的话，我们接下来的优化的重点也是如何针对这三种文件去进行一些优化。接下来是我介绍我们的系统性的优化思路。啊，这里就用一下算绕参数的一个经典的句式啊，当我们谈论鲁迅的压缩编码的时候，我们在谈论什么呢？其实在鲁迅8.7版本之前。我们说的这个常见的这些压缩算法，嗯，呃，什么best SPA，还有这个best，这个是我们用的时候大家可能都知道这两项配置，其它可能针对的是两种不同的压缩算法，Best针对的是，然后这个best呢，底层针对的是压缩。在8.7版本之前的话，这两项压缩算法其实主要是用于行程数据的压缩。

内存字典文件这一块其实并没有并没有用到这个压缩算法。呃，在8.7版本之后，社区里边其实做了一些改进。嗯，包括呃列存存方面现在可以执行RZ放压缩，呃列存里面它其实分了几种类型啊，呃，有一项是我们贡献的，有一个是原来就有。的，然后还有就是关于字典文件，字典文件的话，其实在八点新版本也可以支持用啊来压缩了。嗯，可以看出来，就8.7版本之后是压缩算法用，现在是应用于更多的一些文件类型。嗯，我们在这块呢，我们首先拓展在底层拓展了称我们把它其实当做一个底层的一个通用的压缩算法，我们希望它能够去赋能下面的这三种类型的文件。呃，这里我们还是要介绍一下，就压缩算法的一些基础，因为可能很多同学都会用这个压缩算法，也可能知道它的效果，但是大家不一定知道它底层的一些工作原理。

我们需要去呃从原理上去看一下，就这几种类型的压缩算法，它究竟有什么区别，就为什么D它能够呃快，然后压缩率压缩效果又会更好啊。嗯，现在这些算法，它的算法其实从那个呃，从步骤来看，它包含两个部分啊，第一部分它是宏观上它要去找重，就找一些重复的一些字符串，然后第二部分呢，就是关于呃，到了字符级别，我如何使用更少的一些位置去表达每一个字符。呃，他们用的一个现在用的底层怎么去找重的这个算法，其实都是基于FN77这个算法，这个算法的核心啊，就是呃这里的一个一条红线，这个红线是表示了当前正在压缩到的位置，但是位置的呃呃左侧的这部分是已经压过的数据啊，它在。

输入一个的字符进行压缩的时候，它其实是会回看之前的数据，很少有没有匹配到一些重复的一些字符串，他一旦找到了，他就会去记录我在什么位置找到的，然后有多少一个，有多少个字节，多少个字符有重复。所以呢，最终他经过这个算法匹配之后，他通过这个这样的一个组合来表达的，呃，编码之后，压缩之后的一个数据，Liter就是指的，哎，我这一部分我其实没有找到重复的，就是原来它的那个字符直接写下去。啊，我们先看一下这个缩算法，这个算法其实非常的简单，它在刚刚的这个七个算法其实做了一个非常简单的一个巧的改动，它就是呃，他去找重复的时候，它是至少要匹配四个字节，这四个字节其实我们知道它可以转换成一个int值，它把这个int值存在了一个哈希表里面，他可去快速度去看这个哈希表，说哎，我有没有。

有没有重复的数据，有的话，他可能会尽可能的再去匹配更多的一些重复的字符串，所以S这个算法，它最少可以至少要匹配四个字符，呃呃，四个字角的一个长度啊。但是他在这个natural，它的distance这些信息的时候，他并没有做任何的压缩编码转换，它是直接存储的，所以呢，它其实只是一个快速的高效的一个找存的一个算法，它底层并没有做一个深度的一个压缩，所以我们可以看出来，它的压缩效果其实不好，很快，但是不好。我们再看一下压缩，压缩的话，首先呃，它在回看的这个窗口的这个大小这一块，它会更大，嗯，它在最小允许匹配的这个长度上，它其实是跟IZ也不太一样的，IZ是允许最少，呃，必须得四个字符的一个匹配。

但的话必须就是他可以三个就可以了啊。然后呢，核心是他在做这个，还有类似这三三类信息的数据存储的时候，它其实这里使用了大量的技巧。他用了一些比如说哈夫曼，哈夫曼编码，哈夫曼编码这个大家可能也都之前也都了解过，他对哈夫曼编码用的时候，他其其实还用做了一些改进，比如说他会去呃调查你像这个类类，还有这个这些数据的话。其实是是有规律的，就是越小的值，它的出现频率会越高。他依据这样信息呢，它有一个哈夫曼的一个编码表，这个表可以去做一些快速高效的一些转换，去减少它的一些空间占用，还有他发现其实通过编码我们知道他编码的一个。

原理是，我出现频率越高的字符，我希望用越短的位数来表达它。但是他。在构建一颗哈夫曼树的时候，他发现我其实只需要记录我的每个字符。我究竟使用多少个。来表达就可以了，他不需要具体记它使用了哪些位去表达，所以下面呢，他又做了一些改进，他这里仅仅去记录它的长度，如果记录它的长度的话，它又可以它因为它是一个守互递增的一个数据啊，还有就是有有时候我们不同的字符，它有可能会使使用相同的一个长度的一些未来表达。呃，这里呢，他又会对这个这个长度的信息采用R编码。说R编码之后的结果呢，它还进一步占用分段编码，所以这里呢，这个方法它的技巧性非常的高啊，它的压缩效果也会非常好。

我们再看，接下来再看一下ctd的压缩，Ctd的压缩它在找方面也是RC7这个算法。他跟那个安老师也有一些相似的地方。它的区别核心也是在这个里头，关于little length，还有这个，还有底下这个我的。匹配在长的时候，他使使用那种新的一种算法。叫FSE编码，FSE编码的话，它其实是有，呃，底层的核心原理是那个AI的算法，这个下面这个论文我贴出来，大家感兴趣的可以去看一下啊，这个是它底层的核心，我们接下来讲一下这一块。嗯，E算法，我们看一下它的原理是什么，它为什么会特别快，效果会特别好。A，算法的核心是底层，是一个一个转换表。这个转换表里呢。它会根据它的字符出现的频率。

就是它的概率，然后。将这些分在分配在一个一个表格里面啊，就是这个表格里面，你可以看一下，它有一个它的长度是31，这个31它其实是综合，综合了ABC这三个字符，它的一个概率信息，然后去计算出的一个这个表格的一个宽度是多少，然后它在这个表格里面，它将这个字符填充到。呃，就是呃，交叉的填充到这个表格里面去。呃，字符，每个字符在这个表格里面出现的次数就代表了它的，呃，出现的次数跟这个表格的宽度的比，其实就代表了它的出现的概率啊，其实我们可以看到这个字A的话，它出现了14，它的概率其实约为0.45，也代表它对整个分区分成了14。然后它这里面其实是有一些分区信息的，我在输入一个字符的时候，它有一个有个原始的一个状态信息，这个状态信息它通过不停的去又移又移，它会溢出一些位啊，溢出一下位置后，它会得到一个一到14之内的一个值，就是说它一定会落到一到14这个区间内。

这样的话，这个他这个状态其实就分成了两部分，一个是就是他的新的一个状态外，还有一个艺术那些字节。但是他这个分区信息呢，它每个字符它有一些分区信息，然后这分区信息本身存在这个表格里边，它不需要他在编码的时候，它不需要去在这些信输出信息里面去表达，这样的话，它就相当于呃掉了一些位，这里能够达到一个压缩的一个效果。呃，就是接下来我们再看一下，就是举一个非常简单的例子啊，这个例子是这本书，呃就呃一本书里面的一个例子，我们再取的，我简单理解一下，他这个通过这个去呃压缩的过程，它怎么去实现这个状态点呃转换呢啊。它首先输入的字符A的话，它会有一个，呃，通过右移来。

A的A总共有14次，出现了14次，总共有14个分区，它的初始状态是31，我们通过不停的又移位之后得到一个结果，小于等于14的一个值。哎，这个值是七，这个七跟这个A这个交集呢，我们又得到了一个新的值是16 16的话，我们现在再输入一个一个一个字符B，这个字符B的话，哎，它通过将这个16这个值，哎字符B的话，它总共出现了十次，我们再需要将16又移得到一个小于等于十的一个值，这我们又得到了一个新的状态。就他是通过这样去通过一些运算能够去加速它的，呃，压缩的这个速度，然后它。在存储的时候，它没有存他的分析信息，所以它能够达到一个压缩的一个效果，这就是ZTD为什么呃，就是又快压缩率又好的一个核心的一个原因啊。

嗯，我们接下来下那个算法用到了航程文件里面去，我们在航程文件里面发现用了之后它的压缩效果其实是逼近DEF的。然后它的速度的话。是接近甚至更优的，在我们的一些测试场景里边，这样的话，我们，嗯，我们现在已经在很多用户用户场景里边已经直接用这个，呃，CSTD作为一个默认的压缩算法了，它的压缩效果的话，比IC至少提升了可能30%以上。它的CP使用接近。我们在做层优化的时候，其实也调研了一个社区里面的一些最新动态，社区里面的话，其实它有一个新的一个特性叫per dictionary啊这块它的核心思想是什么？就是呃，我们上面这个是原来的这个按快压缩的这个，呃这个呃方案啊，就是原来他是这么做的，原来的时候他只能在一个就是说60K级别的一个块里边去找虫。

那这样会有问题，就是他通过C77这个压缩算法去找重的话，其实它的一开始的部分，它的数据总是不能得到压缩的，因为一开始的部分他没有，他没有字典数据去参考。所以呢，他现在用了一个用了更多个块，他分了将多个块组合在一起去做一些压缩编码，他将第一个块是做一个字典块，其他的块会参考第一个块的字典信息，这样的话，它相当于在一个更大的范围内共享了字典数据，所以他这一块呢，其实压缩效果的改善其实也还是蛮不错的啊。接下来我们看一下字典文件的优化。字典文件的话，底层。它也是按块组织的，就是我们分词之后的结果，这些词它在底层是按块去组织的，它是有序的，而且呃，它原来的时候，它这块没做压缩，它仅仅是把一些相同的一些前缀给提取出来了，它仅仅把后缀的部分存放在了这个块里面去，但其实他这块还有很大的一个压缩空间，就是还有很大的压缩空间的一些改善。

呃，我们常说这个FT其实是关一些它的信息啊，FT并不在就是核心的那个点的数据里面，它在一个索引文里。但是在存储空间更大的。其实上面的这个文件。这块呢，我们也也调研了社区最新的版本啊，社区最新版本的话，其实在8.7版本里面，这块也引入了压缩算法，就是r four，还有这个。嗯，这两个编码其实它的效果也还不错，呃，后面这个就是这case这个阿，这个编码它是什么意思呢？就是因为我们在字典里面存的都是一个小写字母，就是已经全部转成小写字母之后存了，所以它的分布分布区间其实一个很有限的一个区间，就是一个更小的一个区间，所以它可以使用更少的位置去表达它使用这个编码的话，它可以降低25%的存储空间，它通过这两个压缩算法的结合，它可以确保至少有百分25的一个存储空间的优化。

呃，我们还是在这基础上也是了。实际效果的话，这块存储空间能够下降40%以上。嗯，接下来我们看一下关于列层的一些优化，裂层的话，呃，它其实是依据不同的一些类型，它底下有不同的结构的，虽然它是按列组织在一起的。这里举了两种类型，一个是关于set，这种整呢，它针对上层，我们的field type，如果设置的是keyord的话，它底层就是用这种类型去试的。呃，这一块你看它有一个自己的一个组织下来，我会详细讲这个第二部分就是关于数字类。数，呃，数字类型呢，其实主要是值啊。类型的话，它有它有一个，它有一个自己的结构，就是上上面一部分记录有一个bit，这个bit记录了我当前。

我有哪些文档有这个列的值，接下来部分就是一个关于每一个文档里面，它这个列的值是什么，现在用了一个进进常编码的一个思路啊，就是他每一个他都用了一个定的位数来进行编码。嗯，我们需要稍微展开一下这个value这一块的结构，因为这块在我们的用户场景里面，它的占比是非常大的，很多用户场景里面我们都用了推货的这个类型，这里面核心核心有这么几个过程部分，第一个部分就是它的，我刚刚讲了，就它有一个，呃，也有一个do ID的一个列表，其实这个列表我们可以理解map。嗯，当然这里有分不同类型啊，一个是系数类型的和密集类型的，这种可能不太一样，密集类型的话，就是我每一个文档里面都有这个列的值，那其实它不需要去记录哪些哪些文档有值了啊，那个会比较简单一点，关键系数类型，实数类型的话，它就需要一个bit map来存储这一块。

第二部分就是叫，就是它底层，它会根据它的列的，这个列的值有可能是个字符串。嗯，他会每为每一个字符串去给他一个分配一个序号，比如说123这样的一个序号，这样他再去做聚合分析的时候，我们其实都是基于这个二值奥去做的，这样的话它会非常的快，它不需要去拿把它的原始的值给拿出来啊。然后关键是这个字典这一部分。就是呃，Ctionary这一块，我们通过去这个文件的一些内部结构，去它的一些内部构成，我们发现这块的占比非常大，原因就是因为我们有很多的链。他的。它的机值就是它的集合，这个大小是非常大的，所以这块它的占比非常大，非常的夸张啊，整个的在这个赛的这里面，可能大头都是在这个这块的一个，它耗耗费了一个空间。

这块呢，它其实原来也是按块去存的，按块存储它，呃，比如说可能是每32个文档，它会去组织成一个块，但是这个块他也没有做压缩，我们现在也对这一块做了压缩，做了压缩的话，其实这个这一块。它的存储空间的下降也是非常明显的，这块降低了有40%以上啊。那接下来我们再看一下关于这个数值类型的优化，其实主要是浮点数。呃，浮点数我们的用户场景里面有很多用到了或者这种类型。我们先看一下就是，呃，底层这一层其实没有浮点输入的概念，底层都是。他写值，那么上层如果只是浮点数，它就需要先转换成一个池传到底层，它怎么转换的呢？它是依据这个IEE754这个标准去做的转换，这个转换它有时候会有问题，就是一个两个相连的值，就是呃，这里给出了两个数据的例子啊，他怎么转换之后的一个结果。

左侧部分是关于它的整数位的一个表达，右侧部分是关于它的浮点数，就是小数部分的一个表达，这两这两部分它用这个标的时有一个问题，就是我有可能数相出来，这个键它非常的。你看这两个值，31.245和31.875，这两个值其实相。但底层它的那个底层这个位是差异非常大的。关于这浮点的优的在比，Facebook这篇算个假，在一条曲线里边，它的Y扭的变化是一个平缓变化的，所以它的值可能会相邻相差不大。

这样的话，他通过这个算法找出一些变化的一些。他在去编码的时候，其实重点去对这个变化的位进行编码，那这块的话，其实确实是理论上说，如果是一条曲线的数据的话，它效果挺好的，但是我们的场景里面不好。原因就是我们的数据是无序的，我们数据并不是说呃，真正的持续数据库里面，我的每条时间线的数据按那个时间线去组织的，我们是可能是按列，就是不同的用户全部放在一个里面，它是完全无序的，所以你用这个编码之后效果其实很不好，但就是用这个编码之后呢。随机访问这块效果会变差啊。那我们通过去调研我们的底层的一些数据的构成，我们发现了一个，就是发现了一个一个很明显的优化点是什么，就是我发现。

里个值个值。而且我发现这个连词它的占比很大。有的场景里面甚至临时占了百分90多以上的比例。如果用这个定场位数来编码的话。它会零值和普通的值，它需要占用相同的位数。而且通过这个I754这个标准，将这个浮点数转换出来之后，它的分布空间非常大的。这就导致每一个浮点数去存的时候，差不多底层都要用64位去表达。那这块呢，我们就想先把这个磷脂这一块，将它这块的空间给它节省下来。我们的方案是怎么样的呢？我们方案就是在原来的这个基础上，我们成年不存了。这个不存，不是说。简单的在上层我们判断这个费的值是零之后，我干脆就把这个数据给丢掉了，不是这样的，因为零值和空值它是有不同的一个业务含义的，我们去在底层其实还是需要去记录哪些文档里面的这个值是值。

呃，我们在读取上其实是用户是感知的啊，用户就是原来的读取行为，其实它没有发生任何的变化。这样的话，我们在原来的结构上做了一些扩展。原来的话，它会有一个到面一个bit map来存储哪些文档有这个值，然后下面就是。记录了它具体的每一个文档的值是什么，我们在这个做了一个扩展之后，我们现在是相当于我们有两个bit map，一个map呢是我的非零值，第二个map里面是存的是零值。我们在这部分的时候，其实仅仅非就可以了，这样的话这块空间就省下来了。上这个bit map，它其实。

其他的场景去，呃，去考虑这块核心的工作，其实在读这一块，我怎么让用户感知，读取的时候能够去发现。I。这块优化的效果是非常明显的，这块我们在呃。这个列举这个场景可能会有一点点，因为它跟离子的占比有关啊，列举的这个场景它的占比超过了96%，这个优化之后，它的存储空间下降了90%以上。接下来就是我们在航程列存，还有字典文件这一块，我们都做了一些压缩编码的一个改进。但是呃，因为有些场景下，你做了这个压缩之后，你势必会对会对你的读取的时延会有一些影响，你像这个字典编码在8.7版本之后，8.7版本之后它默认是开启的，但其实在我们用户场景里面发现开启之后有些时特别敏感的其实是有影响的，我们这块去实做了一些细腻度的一些开关控制，我们会每一个特性都允许用户可以去配置。

就是我要不要开启或者是关闭。我们接下来说一下我们的下一步重点工作。第一点就是我们的智能压缩编码的一个策略，我们刚刚讲了有些开关。可能依赖有些场景下依赖用户需要去深度去理解自己的一些呃数据特点，但是呢，我们希望一些变冷之后的数据，或者是稍微降温之后的数据，我们能够去通过一个一个一个尝试，是吧，通过一个探索，我能够找到一个最优的一种压缩编码的一个策略，能够去尽大尽可能的去降低它的存储空间。

然后第二部分的话，就是关于日志数据的一个定制的压缩算法，我们所有的压缩算法。其实都是通用的，就都是只在一个级别去做压缩，但他并没有去考虑说。我理解这个日志数据的特点。如果我理解这个日志数据的特点的话，其实这里要做的工作，要做的优化空间还非常大，并且里面也有一些论文也在做这方面的一些探索啊，这块我们现在也在做探索，第三部分的话就是计算存储分离这一块，可能前面也简单讲过，这个也是我们当前也在重点做的一项工作啊。我的分享。就这些内容。大家看有什么？感谢杰山山老师的精彩分享，那现场的小伙伴有没有什么疑问，然后现在可以进行提问环节。

我们现在是在E。对比的话是08:07。有些压缩其实是在我们的底层里面也有啊。现在，嗯。的点三七里面也有部分就是我们的所有的都在710里。还有其他的小伙伴也。您说。有没有什么？

生活费。外的消耗。加做的工作。他下去之后。是这样的豪横数据的话，现在默认都有压缩。一下就好。嗯，如果是你你的特定业务场景的话，其实这块是可以的，就这一块呢，当然这里可能需要再加一些特定的一些开关控制，对吧，就是你像航款的话，现在还需要做一些改动才可以支持，但是如果你这个场景你对成本不敏感，但是你对你的随机访问非常敏感。

那其实可以这样去做的啊，我们其他的其他的都可以支持发加曝光量，就是航存这个现在还不支持，因为我们，呃，我们主要场景是日志，日志这一块呢，航船这一块的读取其实不是很敏感。江苏的电子。

CPU的消耗速度。你这个上层做是在哪一层上层。其实这样的话也可以，但是这块。那个那地方是有一个。但是这里可能会有个问题啊，就是。因为你在上层，你可能只能在一个客户端去做这个压缩，那你可能在只能做。一条道的内部的压缩对吧。啊，所以你这个场景是是一个特定场景，是一个个定场景，可能跟我们这个通用场景不太一样，我只能说技术上是可以容易实现的啊。但是我们主要是考虑我们的一个广泛的一些场景的一些通用性。

好的，这边老师可以看一下线上的小伙伴有一些问题。彩色分离的话，目前。呃，我们现在正在做方案，可能会推出的话，应该是在明年啊。因为这一块的依赖挺多的，也有就是我们如何尽可能的去降低我们对这个，呃，对这个用户的一些访问的一些感知，这块其实存在一些技术挑战。啊，这块我们现在正在做方案。哦，这块这块的优化的话。这块我们目前还没有去考虑，因为这块不是我们存储的大头。

这块还还不是我们的一个痛点啊。嗯。呃，行，这一块其实可以实现的。这块如果是用户自定义的话，这块其实有些有些开发工作要做。嗯，好的，那我们今天的这一环节的问答就到这里，然后感谢大家的违约发言，那下面来，呃，有请来自凯贝塔的杨庆明老师，大家然包弟的实时数据融合平台价和分享啊，由于静明老师今天在线上给大家分享啊，希望大家调调试自己的手机到静音模式啊，然后耐心的观看，谢谢。

OK，大家。对，可以可以，杨老师请你全屏一下你的屏幕，全屏一下对，全屏一下你的PPT。这样可以吗？可以的可以的，OK，呃，那个大家不好意思啊，因为我在上海，所以被标记了过不来了，那个今天就线上跟大家交流一下，然后我先简单自我介绍一下，我是来自他data的阿，那那个今天跟大家分享的主要是基于yesgo来搭建构建一套企业级的实时数据融合平台，所以这里面我们会比较关心两个地方，第一个是实时，第二个是融合。因为对于很多企业来说，目前嗯有很多的呃离线的一种解决方案，包括嗯哈杜为主的那些，呃，CDHTDH，那还有一些传统的数仓啊，还有dataac那一套，那嗯我们现在越来越多对数据的这个时效性有一些高的要求，特别是对于业务端来说，它很多数据是不能去等待的。

所以啊，我们今天来探讨一下，在一些那个啊，我们的一个实际的一些案例中啊，用户是如何来解决这个问题的。嗯，今天会跟大家分享四个地方，第一个首先来讲，呃，了解一下我们客户的一个整个一个背景，包括他当时当前的一个it的一个痛点，然后接下来看一下我们是如何来解决这个。解决这个事情。呃，首先我们，呃，这是一家做那个珠宝行业的一个企业，然后他们的那个历史也非常悠久啊，从那个it开始，九零年代就已经开始有了，其实更早。然后他们也是第一批上到那个香港那个上市的一个呃零售企业，那他们的一个典型状态就是呃呃业务非常的做的比较不错，然后铺的也非常开。那一共有大概700家门店在中港台奥分布，嗯，他们是卖珠宝的，所以嗯，当然我们其实我看他们CIV比较熟，呃，大家如果珠宝上有什么兴趣的话，可以聊一下啊，有折扣啊，OK，那那个他们实际上很多的业务都是在珠宝零售，那现在互联网起来之后，在移动端，包括呃线上的电商都有自己的一些这个呃平台去售卖。

那呃，随着他们的这种体量越来越多啊，他们会发现一个问题，就是他们和不同的电商去对接，包括一些商品的上下架去做，然后以及他们有很多的这种呃数据，呃，在那个已有的数据库里面沉淀下来之后，发现做新的应用的时候就有一些痛点出来了，那比如说我现在要做一些这个门店的活动啊，我要去上新，或者是去推广一些营销活动啊，对于开发来说，他们的成本非常高，因为他们需要从啊各种各样的这个数据库里面去把数据捞出来，然后再去做迭代。那所以现在，嗯，他们一个典型的一个痛点就是，嗯，如果我在香港的门店里面需要去调一个货，嗯，我需要去从比如说从澳门这边调一个钻石过来，呃，我们原来想象中可能就是很简单，我就是。

比如说我从那个呃销那个销售POS系统那边去拉一个货，对吧，然后那个店员那边就直接能够系统拿到货了，然后跟顾客说，哎，我那边个那个从澳门那边寄给你就可以了，那实际上在那个现实情况中不是这样，他们的系统会受到一些历史原因的牵制，导致很多的这个呃数据没有办法做到实时，那实时的呃呃实时过程中会发生一些交易行为，包括一些调货，转货，存货，包括在上的一些运货等等，那各种状态导致啊我们的那个啊。顾客他们在这个真的发生转货这个动作的时候，就需要让啊那个顾客来等很多时间，所以这个这个场景是一个非常典型的，因为it系统的一个瓶颈，导致业务受到一个呃掣肘，所以他们接下来想把这个事情给解决掉的时候，会发现他们呃根本的原因在哪里呢？是因为我们it在提出这个呃那个业务在提出需求的时候啊，对于it来说，大家可以对比一下，就是实际上我们很多业在提需求的时候，可能感觉诶这不就是做一个页面嘛，你就你就帮我加一张报表对吧，然后感觉一周你应该可以帮我搞定，然后他们就排的很快，然后需求也很疯狂的在往上加，对吧？但实际上在我们的这个传统的it开发这个呃模式中，嗯，我们基基本上都是先要制定需求和BA，要确定好你这次要做什么事情。

然后接下来你这个对应的业务需求背后一定有很多的数据模型，然后我们定义完了数据模型之后，开始来做数据的抽取啊等等啊，因为这些原因导致最终我们的一个上线时间会被拉的比较长，短的话一个月长的话可能两三个月都有可能，那这个就对于业务来说他很难接受啊。也有说我我现在有一个双11对吧，然后我提前三个月跟你说OK，但是但是突然发现一两个礼拜前出了一个policy，我这边审计不过了，我得换一个策略，呃研发说对不起，我们这个调整不了了，因为整个逻辑都不啊已经定下来了，那造成的结果就是他们这个啊，那个活动就只能下掉啊，不能上这个对于这种呃零售行业来说，在这种618双11这种阶段，其实是呃影响非常大的。

所以嗯，他们想，嗯，他们会，嗯发现有很多的问题，现在制肘住他们的这个it系统发展了，那就坐下来看一看到底有哪些问题存在啊。首先第一个就是数据孤岛，嗯，我相信在很多的呃，传统的企业，以业务为生的企业中都会面临这种问题，因为他们的这种啊，历史进程啊，是以业务为生啊，他们的it系统大部分都来自于第三方的采购，呃，每一套业务系统采购进来之后，都会带着他们绑定的数据库，Oracle也好啊，Mysq DB two啊，乃至现在的一些新的数据库，像那个啊，PG也好啊，那个新的一些这个啊非关系型的数据库，但是嗯，对于企业来说，呃，采购系统解决了他们的业务问题，但是对于他们的it来说，一旦要在这些业务系统之上去做新的业务，就会非常的头疼。

啊，第二个就是有这么多的业务系统，他们的年龄又是非常的悠久，嗯，他们的可维护性就是非常低了，嗯，我看到过他们的一些存储过程，有一两千行，然后一两千行的代码，是从2000年开始维护，维护的人里面每一个加注式的人，我看了一下有大概有十几个人维护同一份存储过程，前前后后，这种历史原因会导致。整个一个系统是很难进行有效的迭代和维护，这个东西就没人敢动，基本上就是说没人敢动，只是出了bug，我们去捋一捋，看一下要不要加一些判断来解决这个问题。那第三个就是因为嗯，很多业务系统，其实他们都啊分管于不同的那个业务部门，有的甚至于是管那个HR来管业务系统，这个就导致我要拿这个业务数据的时候就很难，因为他有很多的部门需要来协调，我今天问你要一下，可能一周了，我们这个项目落地了之后一周我还没拿到这个数据的啊，开放权限。

啊，这个就会影非常影响我们整个一个开发周期。最后的话就是刚刚有一个那个对比的一个，呃时间对比图，对于研发来说，其实大家都做研发，我也是做技术出身的，很明确就是有时候我们对于技术来说，呃，我们明确了需求之后就去做，我最怕的就是做到一半，你跟我说改需求，然后快做完了，你说哎，我我可能不是想要这个东西，这个就是对于我们的研发来说是非常头疼的。所以对于这个，呃，我们的这家企业来说，他们最大的一个问题就是整个it括IT1这个历史。那他们需要解决这个问题的话，希望能够通过改变当前的一个呃集团数据架构来呃来呃，完全的cover掉这些问题，所以我们可以分析一下这当前的一些问题最终能够通过这个平台来解决，这个平台需要具备哪些能力，首先呃，我所有的数据都要实时的，因为我现在业务不能做到实时查询，所以我会丢单，那我的数据我要能够实时的查询，包括实时的一些。

第二个就是我要能够啊做全全文的搜索，对于全的搜索来说，现在很多的包括一些移动端在前台进行一些搜索之后，我们的体验其实都是非常不错的，能够很快的就能走，从前端看到我搜的一些呃，那个关键信息能够匹配出来，但是对于我们很多传统的零售行业来说，他们自己的那一套搜索是非常老旧的，在关系型数据库里面做很多的SQL查询，做一些like模糊查询。所以对于他们来说，他们现有的一些系统的门店的销售的，呃，店员来说效率是非常低的，可能页面要十几秒才能转出他们想要收的货。第二个啊，第三个就是数据的统一，那呃，因为他们的历史原因，导致在中港台澳几个地方的数据库全都是分散的，全都是分散，然后一个订单在所有的门店里面啊，在所有的这个数据库里面都会存一份，只不过他的状态会不一致，当你想要拿这个订单最终的一个状态的时候，他需要去所有的数据库里面去查一遍。

那可想而知，这个这个速度肯定就快不起来。所以呃，综合起来来看，他们其实是希望有一个能够做到实时查询更新，然后是能够做全文搜索，然后能够帮我很快的做成一个数据统一的服务的一个平台。那嗯，可以看到我刚刚提到的那个，呃，他们的历史原因就是因为这个啊，他们有很多的种各种各样的数据库，他们有各种各样的一个各个地方的数据库，导致这个订单的数据是非常分散的，然后每个订单都有，所以数据也冗余。那。对于他们的那个数据痛点来说，他们就是有三大痛点，在零售行业基本上就是啊，订单、库存，还有商品啊这三个为核心的这个主数据，那这个主数据和我们传统的数仓来说，它最大的区别就是嗯，数仓我们都是一些维度表，实时表，嗯基本上只使用于做一些报表，他们这个三个主数据真的就是所有的集团可以想象零售行业中，嗯，所有的项目啊，你包括你要做一些这个啊，活动啊，或者做一些营销，全都离不开这些模型，这三个主数据模型我们称之为叫实时主数据模型。

对于集团层面来说，他们基本上都要，那现在他们现有的这三套主数据模型就存在这种情况啊，在各个数据库中存在，然后有各种关联关系，一张商品表相关的属性表有二三十张，然后订单的话有十几，呃，那个1.5亿的存量订单啊，很难去做完整的消化。所以他们会发现整个一个开发周期中啊，大家也可以对比一下，就是真的在落地项目的时候，是不是有大部分的时间都消耗在数据准备上，我们需要去每个呃，集团的这个呃，我们称为叫基础数据也好，对吧，或者是企业的这个呃核心数据也好，去那些那个库里面去拿一份，然后这个数据的一致性谁来维护呢？自己项目组的人来维护。

所以最终就会造成说从这个基础库里面出去的所有的数据链路会越来越多，而每一个呃，那个开发组自己对于这个数据同步的理解又不一样，就会造成你出去的数据的一致性没有办法得到保证啊，然后就会发现说我这个应用出来的报表和你这个应用出来的报表大家都是同一个维度的数字，对不起来。这个是很多现在企业中面临的这个问题，那嗯，从研发的这个，呃，占比上来看，大部分的人全都是在这个应用开发上，所以在应用开发上的话，我们其实是能够去做核心业务，但实际上不是的，大部分时间都在数据准备上，我们没有把很多的时间聚焦在核心业务上。所以我们是希望通过这么一套呃解决方案去能够帮用户啊完成说啊从前到后的一个呃数据的融合，那看到我们的那个呃第一层其实就是呃将所有的这个呃数据库，你无论是关系性的，非关系性的也好，Oracle MySQL也好，全部啊经过通过实时同步，同步进我们的这个整个一个平台，那我们的平台采用了呃两种数据库，也是我们今天的一个主题，就是ES加芒果，呃E和芒果，其实呃有时候会看到网很多的VS的一些文章，但实际上他们是一个非常伙伴，因为果和ES模是非常相相近的，同时他们在很多的业务场景中，其实是可以做互相的配合，比如说ES非常适合做全端的一个查询，在我们的啊这种场景中，业务场景中，它就是来解决用户大批量的一种模糊呃关键词搜索，以及一些啊呃聚合的复杂的查询，而猫go负责把所有的模型都能够快速的处理掉。

并且响应到前端去，所以他们是一个非常好的兄弟伙伴，然后我们把数据进到mango里面，嗯，在mango中完成整个一个数据的实时建模啊，比如说我们的商品模型，它在关系数据库里面，它有二三十张表的一个组成，那我们就通过产品的方式把他们的那个模型全部都变成一张啊，固化视图我们称为固化视图，实际上就是一张大的很大的一张大宽表。

但这张大宽表它是真的是业务在那边更新的，所以可以想象，如果是一个ERP，或者在那边有一个下了一个新的订单，那我们整个一个大宽表，那关于那条订单的状态就会被更新到最新。然后我们把mon中的那个商品模型的主数据模型推到我们的ES去，嗯，对于前端来说，就我们就不再是说只是针对于普通的啊，BI也好啊，比如说那个包啊，Power BI啊，Table啊这些啊，展现啊，或者是一些数字大屏啊，更多的是像面向于业务系统，比如说像supply chain啊这些，呃，供应链或者是一些这个呃，营销系统。那对于这些系统来说，真的就是呃，业务业务端包括销售人员，他们真的就是靠这个去卖的，卖卖他们的产品。嗯，所以我们的整个一个实施同步的一个方案是这样，就是首先把他们的所有的OR4个地方的or的数据全部都拿过来，通过log的方式监听，监听进来，然后监听进来之后啊，经过中间的各种处理啊，比如说规则处理啊，啊那个脚本处理啊，啊字段处理，大小写转换等等，然后把这些全部都处理完了之后啊，我们写到我们的芒果里面去。

啊，写到mango之后，我们再通过我们的实时同步把mango的数据写到我们的ES里面去，那mango和ES其实啊不一定是1:1的一个写入，我们更多的是会做一些模型的过滤，因为mango中的主数据模型可以想象是一上非常完整的，整个集团所有的商品模型都在这个里面，而ES面对于不同的前端应用查询的时候，我们会生成不同的呃那个报表，包括一些模型给到前端，嗯，最终的目的就是对于前端，前端来说，比如说他要查一个呃聚合数字，那他不需要再拿到ES的数据之后再自己去做板，而是通过啊，直接查询ES的某个记录就能够把数字查出来了。

所以在这个到的过程中，其实我们也完成了实时的增量聚合处理的这个动作，到E的数据就是所有的前端业务要拿来展现的数据，而并不是传统开发模式中，我从数据库里面拿一条数据，然后自己在前端也好，后端也好，把它处理完成再突出去。所以整个一个模式可以看到我们通过这种啊流式处理的方式，实时的将端业务系统的数据啊，经经过计算加工之后提供到前端，对业务来说，他们直接访问ES，就是高性能查询的这个数据库啊，完全解决了他们整个呃业务上最大的一个问题就是呃时效性的问题。那对于啊，增量聚合来说啊，我们很多时候其实都会面临这样的问题，就是一个聚合场景，我们往往都是通过一些像最以前就是CQ的一个，你有一条数据就得一把，那基本上都是在间跑完成，现在还有很多企业都是在做这种方式，因为业务需求太多了，我没有时间去优化。

那第二种情况就是现在大数据产生了，我们用SPA去做，那SPA它其实还是通过窗口的方式在做一些窗口化的goodbye，那到最后那我们现在有来做一些的计算。那我们的这种嗯，计算的实时计算的方式啊，有link就会有些类似，但是啊整个都是啊自己来做的，就是我们还是基于第一把我们会有一个初始化的增量聚合啊，帮用户把所有的报表，他想要的各种报表全部都聚合完，接下来增量聚合过程中，我们可以理解为举个简单例子，就像goodbye啊，一定会有fields，基于他们这些fields去做一个小范围的增量聚合，那其实1亿条数据里面匹配到这些报表数据的可能就那么十几条啊，这是一种增量聚合的实现方式啊，来保证最终我们数据啊是一致性的，哪怕你原端有增删改，查目标端对应的报表数字，也能进行到回滚或者是啊新增或者计算等等实时计算。

那嗯，对于用户来说，他可能希望有一套完整的那个数据服务平台，所谓的数据服务就是我们不希望再像以前一样说，我们还是从四个or那个呃，九个入口里面去取数，然后自己的项目Java code去啊里面去做一些很多计算，而是希望通过有一个统一的出入口，对于DBA来说，它非常容易管理，因为他只要管理这个统一的出入口的账号权限就可以了，而对于应用端的权限来说，是有这个统一的数据服务来管理的。而对于呃应用端来说，它只要取这个API啊来作为一个访问的出入口，所以API会连入我们的mango，连入我们的ES，去做我们的实时的数据啊，那个底座，那这样的一套呃数据服务啊提供了之后，向上的可以看到在啊用户这边，他们就是用到全渠道商品库存中心啊，营销中心啊，还有他们的一些实时盘点，嗯这样子一套流程下来，对于用户来说，他们的呃对接成本会降到最低，因为他们只要接API，而API的格式我们采用最标准的格式。

OK，那嗯，在用户这边，我们的一个方案就是首先所有的数据库啊，在底座通过我们的批流一体的这种实时数据同步，其实就是log啊进行采集，采集完之后进到我们的这个芒果中去进行一个建模，这个建模会参考一些数仓的规范建模，但是它建出来的模型啊，还是我那点，就是是基于业务来做的实时主数据，并不是一些维度表。然后接下来有主数据和我们的一些这个，呃，那个底层的天层数据之后我们向上就可以提供一些业务模型了，大家可以想象一下，如果我有我有一个非常完整的商品模型，以及一个呃订单库存模型，我现在要统计啊，今天的一个各个门店的销售报表，其实很简单，我只需要把一个订单做一个聚合就可以了，那这个过程其实我就是对我已经有的这个库存模型做一个聚合啊，那基于实时增量聚合的框架，就是很快的把它整个一个结果算出来，然后他说呃，业务端说我还要再查一个报表，是基于月的，OK，我再来一个报表啊，又还是基于实时聚合，那对于我的这个查询的模型来说，我永远在查这一个库存模型。

那有可能会有商品模型和库存模型合并的这种场景出现啊，比如说我这个商品下面有多少个订单，那其实也就是把这两个主数据模型进行一个合并，所以一旦有了我们中间这一层主数据模型之后，上做任何的业务模型就会非常的快啊，整个链路因为又可以做到实时，所以对于应用端来说，他们拿到的API的数据也都是实时的。那我们的API会建，建立在果和上，是因为芒果和ES他们本身就是处理面向op的，当然op我们也能做，嗯，包包括EE他们都能做这个事情，只不过他们做的还是实时的，要比传统的那个哈杜普要会更快一点啊。OK，然后嗯，这是我们整个一个平台搭建的一个过程，从Oracle这边进到我们的mango ES，然后啊，进到他们的微服务，以以API的方式提供给微服务方式，然后嗯，对于前端业务来说，把所有的啊，那个集团级别的一个业务系统全部都接入进来。

嗯，这是他们的一个物理部署的架构图，他们是一个两地两中心的一个呃架构，呃在呃大陆这边也会有，然后在那个香港这边也有一个中心，嗯，所有的mongo啊都是分布式的，ES也是采用分布式的呃集群部署，嗯读写全部做分离，所以呃比如说我们的主节点是在我们的香港那啊我们接下来我们的数据会从香港去写入，但是啊对于我们的来说啊，包括业务端来说，他们的API会访问我们的呃就近就近的一个分配，那这个这一层的呃读写分离，包括那个呃策略的一个转发，是通过他们他们自己的一套这个呃类似于像那一套这个服务来做的啊这个并不是我们整个一个，但是它也会让让我们的整个集群啊，工作起来会更方便一点，因为大陆的肯定不希望去访问到我们的香港。

那嗯，整个技术站的话会用到这些，包括那个他们用到AWS啊，腾讯其实也有后来有用到他们的一些这个数据数据服务对。然后嗯，说完我们的方案之后，就可以跟大家快速的分享一下我们到底嗯怎么来做的，其实就几步啊，比较关键，第一个就是了解需求，然后接下来去做一些数据源的准备，接下来就开始做建模，天源层，主数据层还有业务层，最后就呃上线，嗯涉及到的一些这个人员分配，当然不不一定是每个人都以对应一个角色了啊，可能是一个人会对应多个角色啊，基本上都是以数据为主要核心啊。嗯，然后我们每一个角色里面要做整个一个death的话，我们称之为叫那个数据融合平台data service，嗯，做这个death的话，我们可能会用到呃，这么一些这个人天啊，比如说100个人天，我们会这么来去分配啊，比如说项目的评估啊，设计啊等等啊，是包括最后的数据治理。

嗯，整整个一个实施过程中，他们的服务，呃服务器其实也是呃比较的这个低成本的，没有用到特别多的服务器，都是八和16G，然后16和64G2台同步节点之类的，就能够搞定整个一个集团层面的数据同步。那这是我们的一个实施进程就部署啊，然后做开发啊等等啊。然后刚刚有提到我们的三层建模，这个其实就是我们最核心的一个最佳实践啊，我们会告诉用户，我们先把所有的数据要放到我们的这个芒果里面去啊，作为一层天元层数据为什么要这么放，是因为啊，第一我们能够极大的减少对于原端数据库的一个压力，因为它只做一个单表同步，没有任何计算。第二个就是放进来之后，我们的数据就不会在冗余了，所有的用户，所有的数据都在这里面存了一份，而不是所有的项目都从原端的业务库这边去拉啊，有很多的呃，链路有很多的这种啊，那个逻辑关系在里面，那接下来我们在天元层之上，我们可以去快速呃，去建立很很完整的一个主数据模型。

啊，在主数据模型之上去做你的业务模型，分析模型都会很快，当然我们也可以直接从我们的天元层去做我们的业务模型，因为有可能它不一定会有我们的主数据模型，或者说呃，主数据模型太大了，呃，我们其实只是一个很快的一个小报表，那我们可以很快速的去做。嗯，这就是我们的一个实际的演进过程啊，大家可以看到上面就是一个订单模型，订单的一个状态的一个流程，他们整个一个订单的一个流程走向，这些流程的logic原来都是写在Java code和MQ里面，后来就被呃就被呃放到我们的整个一个平台里面去，所以我们的平台嗯，不只是在做数据的同步，就是在天元层那里，可能是在做数据同步，但是从天元层到主数据层就开始在做数据的建模，以及业务关系的处理，订单状态的变更啊对我们后面的一些啊，这个呃，包括呃价格的计算，金价的一个变化等等啊，这些全都是啊，对于业务来说是比较重要的一些这个属性。

那下面这张表就是他们的商品模型表啊，有二三十张，做一个关联关系，这个是三式的设计，非常典型，我们把他们全部合并成一张大款表商品模型，所以他们原来的那种开发模式是说我要查一个API，然后我要查很多次，对吧，然后现在只需要查一个API，所有的商品属性都在里面帮你建好，呃，索引对应的后台索引，所以查询起来会非常快。OK，所以嗯，自从我们帮他们做完这件事情之后，他们啊第一个就是前端响应从十秒降到了啊亚秒级别，因为嗯从原来从那个芒果这边去查的时候，其实我们有做过一些压测，芒果去作为一些全文索引，嗯跟ES比起来还是有一些差距，然后ES整个承担前台的所有的业务压力，然后模型的一个整合，这个这个组合中用户的一个查询就直接降到了这边。

然后查询次数当然就只有一次，因为我们就是一个模型啊，一个模型对应一个业务啊。然后嗯，整个一个，呃，数据数据门户的话，对于DBA来说，他们的帮助也是非常大的，因为对于DBA说，他们很多日常工作都是在啊数据查询上，对吧，我要给我一些报表啊等等，那现在有了平台之后，他们可以通过开放数据自己去查通过啊，包括bar啊，一些非技术人员都可以去平台上去查这个事情，那就帮DBA去释放了很多的工作压力。那整个API的一个研发流程也得到了极大的改善，包括嗯，原来他们要做两三个月，现在只需要真的就只要嗯几天，甚至于最多也就是一周的时间，因为啊，所有的数据已经都在我们的平台中，包括主数据模型啊，在ES那边都有了，你没有的数据在平台里面如果搜不到，很很简单，我们再来一次，把这个模型放到我们的平台里面来，那接下来啊，你如果再用新的模型，就不用再重复的去做这个事情。

OK，嗯，那我们整个一个API上线的流程可能也就是这么几天啊，提交需求，然后做研发，然后最后就是上线啊非踌。嗯，最后的话，我们在发布A的时候也会有一些这个，呃，Swa自一些S生，那不用去写一些文档啊。所以给到我们的用户，他们的一个呃价值来说啊，他们就觉得现在在我们的平台上去做了很多的十几个应用之后啊，越来越快开始把原来的陈年往事的一些应用，应用系统it的一些痛点都拿出来做，因为其实很多的it痛点都在数据上。OK，呃，今天我的分享就完了，然后因为我今天就没有露头，就就录了一个微信，嗯，大家如果感兴趣的话，也可以加我微信一起来交流一下，对。

好，谢谢大家。感谢庆明老师的精彩分享，那现场的小伙伴还有一些问题可以问我们庆林老师，然后我这边叫庆老师来现场解答一下。有要提问的小伙伴吗？好的。我问一下那个他们做数据同步的时候，如果数据掉了，订单数据这些东西应该是不掉了，就是如果你果数据同步数据掉了话。呃，所谓的数据掉了，是指没有拿到或者说是丢失了，可能中数据有很多个数据的时候，其实数那个数据。

OK，嗯，这里面有几种情况，第一种我们实际中确实遇到过，第一种就是产品的缺陷，因为我们是用log manner去解析，那有可能有很多C场景，我们是没有cover到，那就会丢，这个是产品的问题，就去修，对吧？然后如果我们遇到这种实际订单在生产中去丢的话怎么办？我们可以很快的把这些订单的丢失订单的一些这个呃，订单号拿出来，然后再去单独的对这些订单做一次修复，就是等于让他再重跑一次数据。然后就能够把这个订单补上，而第二种就是我们提供了数据校验机制。数据校验可以做全量的校验，然后也可以做批量的校验，也可以做实时的校验，你来一条，我校验一条目标，这样就能够保证我们数据的一致性，嗯，对于整个同步同步来说，呃，我们的校验必须要保证100%，而不是很多的啊，AP类的业务，它允许你有错误，对吧，如果不对了，我第二天再重跑一次就可以了。但是对于交易来说，一个订单如果状态发生变更，就像您说的，如果丢失了，我们目标端如果没有发生，那可能这个订单会被卖两次，这个影响是非常严重的，所以对于我们来说，我们整个链上的数据都需要保持有，呃，一直都是百分百正确。

嗯，好，还有其他小伙伴有问题吗？呃，老师想我想问一下在学的时候有没有。我用其他的词。其他的组件，而是说因为是全部都是word数库，你就选这个东西。OK，呃，是这样，就是对于我们，对于我们产品来说，我们其实做嗯，呃，很重要的一个部分是我们核心能力就是异构数据库的实时同步，所以嗯，不只是orac口进能mongo这种组合，呃，Oracle到mongo到马克到卡夫卡，到各种，嗯，只要你能想到的数据库，我们都可以拿来做我们的数据源和数据目标，所以只是说用户这个场景中，他们都是orac啊，我们就用log mind，那比如说你是MY，我们就基于MYSQ做的b log来做，那比如说你是芒go，我们就用芒果的train stream来做啊。

好，谢谢，还有其他的小伙伴吗？嗯，华那边。呃，同学，就是关于整条链路添加一个细节上确认一下，就是第一说是帮我在相当于是就是接入消息，就是就是添加一个TT的类型，然后当中提到了他来做呃模型的整合。那我有两个小的疑惑，一个点就是我实时同步给的是一个单独的一个。实力，或者再通过你的图分离丢到另外一个口做，我怎么处理？对，呃，其实整个mango的集群，它都是自己自己的一个呃主备，就像ES集群一样做的那种呃集群，所以mango之间的同步其实并不是我们来做的，是mango自己来分发的。

看你们处理的这个就是你看依靠我是本身的处理的。嗯，没有，所有的模型都是通过平台去做的，Mango只是能够因为它它和ES非常像，就是对于这种高性能，高吞吐，低延时这种呃，TP类的场景是非常合适的嘛，所以呃，芒果他负责做大并发的这种，呃读写读写场景，那更新模型之类的肯定会在芒果上去做，因为它本来的这种数据肯定要做更新嘛，但是一些计算类的，比如说金价的计算啊呃，实时聚合啊呃，这些计算其实都是通过平台去做的，并不是在数据库上去做的。那接着做完这个之后要要到。对，没错，所以这个时候go就从原来的目标端变成了端，从go这边再做了一波清洗也好，字段的聚合也好，写到了那个E这边。

就是会也是在平台这一侧，它会有一个自动的这个过程。Sorry，没听清楚自动的过程是指什么意思，就是就是，因为毕竟是两个。OK，呃，到E对于平台来说，就操作上其实是一样的，就是我拖两个数据节点出来，然后拼一拼就OK了，但对于我们的那个开发者来说啊，如果真的去做这件事情，你芒这边你把它当做数据源，那你用的肯定不是logo manner啊，我们用的是change stream，官方提供的change stream来做，所以它作为源，我们用新stream去开启一个类似于像logo manner一样的一个东西，去监听我们的日志。那那最后到给看到头上或者是呃，一个API，或者说注册到A上，那这个是相当于是也是这个平台提供。

对，平台的API可以基于任何的数据源去发布他们的表，作为一个API，包括呃，平台，它也可以基于任何的数据库去存储数据一样。那最后不是关于E这一端，因为查询到其实前端应用询基本上是到E这E。经过实际的这种项目上去看的话。是那么高，所以想问一下，就是说我没有压测过吗？就是说这个对来说达到怎样的一个效。呃，在我们这个用户场景中，他们的那个呃，ES其实并不像比如说像电商行业这么的这么的厉害，因为你可以想象，像电商行业他们是以以单量取胜，而像珠宝行业，他们其实是以以货以一个单的一个价格取胜嘛，所以他们哪怕是在双十一六幺八这种啊零点搞活动，也不会有这种像那种淘宝啊这种天猫这种一下子一个大发，他们的一个大发，其实目前啊，ES架上就是三个分片啊，就能够cover当啊，目前所有的这种高并发场景了，平时基本上都都用不到三分片的一个，基本上没有什么太大波动。

嗯，好的，时间关系我们，呃，这轮的环节就到这结束，感谢大家的积极提问和庆老师的耐心解答。好，那么下面继续我们的分享，有请来自字节跳动的鲁运成老师为大家分享字节跳动在ES的内核拓展，大家掌声欢迎。

哎呀，我要鲁运。跳动。是。就是主要是想讲一下在耶稣一些一些内容上的拓展。大家分享一下和交流一下。嗯，我大概会主要讲我从三个方面来讲我们做的工作吧，第一个是我们的存储上做的一些引擎的改造，主要是在三级群上，我们会做一些存储计算分离的工作。然后以及。

那我们在跨级上会做一些呃，跨集群副本复制的工作，然后在功能上我们可能会有向量检索，然后还有一些地理位置的呃引入，然后在安全上面我们说我们。在引擎做一些安全的改造，以及D整体的的可观。然后我在。介绍。嗯，第一个点我们在存储上做了一些。呃，价格上面的改造可能在ES上面改动比较大。主要是我们做的第一个是在单集群上面做的就是重储计算分离，为什么会做存储计算分离，就是因为我们有些呃业务请求样的时候有高低峰，然后在高低峰的时候，我们需要在高峰期给他扩容，因为扩容的时候呢，速度特别慢，然后数据迁量也特别大。

然后再一个就是我们搬太多的副本时候呢，会造成很多的存储。成存储的成本比较高啊，那会造成我们的整体的那个资源过多。所以我们就提出要做存储计算分离的这个架构。嗯。大概数据分离呢，主要想要做的是一个的架构，就想说因为如果做本的时候，他需要写多的数据，然后造成多个磁盘流，然后搬数据的时候也需要将数据的搬迁，所以我们想要的是说做扩容的时候，我快速的扩容样子造。帮助我们做那个数，呃，就是共享，我们帮助我们之后只能分，你说帮助我们做个。就是快速的扩容吧。那然后呢，我们选用的存储呢，选用的是共享的存储的云盘。

下这个NF的地方是共享存储。总体的架构去了之前E是嗯，一写一读主副本的架构。是采用了一写多读的架构，这样子的话只要一个地方写，然后第二个所有的副本采用。采用读读网的形式，这样能达到我们快速扩容的方式，这样子的，然后我们的数据只会写一份，这样子我们的云盘的成本整体会减少很多。大概的价格形式是这样的。嗯，我们大概会怎么做的呢，主要是说我们在。呃，这个主下的这里的时候，用主下的承担所有的写操作，然后副本的时候呢，副本会去读啊的数据。

啊，就是我们看一个写入的流程，就是说一次写入的时候，会写入到主的，主的会写成会写，然后刷成，然后主的会。将定期的会将段的一些信息同步到所有的副本，这样子保证副本是数据可见，帮他传到这个信息到副本之后。副本会开那个manager，然后他就会更新自己的。的那个可见性。然后我们的NFS保证的是多副本是可靠的，因为它N这边是有也会有写多份数据，所以它是存储是可靠的。第四一个呢，我们的。可见主要依赖于就是那个呃，Segment。基本上这个是做到秒的，只要你刷卡的话就会有。啊，基本上这套下来，我们的增减副本可以做到两级完成。

啊，我介绍完了我的。啊，那个班群的存储计算分离之后，想介绍一下多群的，因为我们有一些架构是需要机IDC以及跨阳的数据。后来。因为。官方的license的原因以及。出呃，一些数据同步的压力，比方说我们需要从新加坡的数据同步到美国这样子的方式，所以呢，就会造成一部分这样子的读写压力，以及这个集群容灾的要求。所以我们就。自己实现了一套CR的流程。然后这套的流程呢，其实跟官方差不多，但是我们有一点点的小改动，主要是对license。做license的那个原因没办法，然后主要的特点，我们是支持索引的，同步的，然后我们我们的这套设计也是license。

最后面呢，因为官方ES的方式是采用拉的方式去拉，所有来同步，但是我们改一下。改成那种push的方式，这样子的话会比较比较比较快一点。或者我们。这边会能更快的感觉到本STEM集群的一些信息。然后我们的数据基本上可以做到秒级的同步到所有的slave集群。啊，这个秒级是看网络演示，比方说从新加坡到可能需要。两百三百毫秒的延迟，这个网络的延迟是避免不了。然后主要介绍一下我们这个快捷副本的一些方案设计。然后其实它跟官方的C差不多，但是我们可能是因为的方式呢。需要在master这里维护一套副本的slave slave集群的一些信息，然后主要的第一个步骤主要跟recover是一样的，就是将主集群的段信息以及呃的回放。这个跟。

嗯，当副本的时候，那些副本恢复的流程是一致的，但是我们做了第二步，就是因为我们采用复始的方式，所以在主的集群里面会把trans log拉出来。记录所有的slave的后将。室外的4.5汲取。这个加slave，然后在slave里面re。基本上的流程啊，可能跟官方无疑，只是把复式改成。嗯。前面两个前面的主要是介绍我们在存储上，在整个集群上面做的一些功能，那个改造的主要是在单集群的集群上。

后面我将介绍一下我们在一些功能上面做的一些引擎的改造，主要是在向量检索的地理位置上。嗯，因为椰子主要是做对于。本的检索打分，但是因为我们有一些使用是需要对于向量或者图片的检索以及视频特征的检索。这个主要应对于。啊，一些消除视频的打。或者是。照那个版权信息的，所以我们需要有一部分。就是将文本和图片、视频的特征结合起来做搜索。然后视频的量也比较大，TBPB的图片视频，那我们可能就需要做一些向量特征的检索，那我们在这里入了一些向量检索的。计算引擎，然后放到ES里面去。

然后这这个这个好，下一点做一个小鸭子，然后呃，我们小鸭子主要就是说我们可以将这个图片放进去搜索，将图片的特征值提取出来，并且里面的文本提取出一些相似的搜索，这样就能知道哪个。可能是我们需要的图片。那我们做到的相当于是在ES做了一层引擎的拓展，现在可以支持多种的计算引擎的拓展。一般像。里面介绍。这个这个框架，我们也因为依赖于框架的，将这些数据全部用到native方式调用再调用。所以他的。它的那个速度会比较快，你看全部在内存里面跑，加了一些S的优化。就你会在这里面跑那些。

检索会要快很多。基本上呃，像这种图片的数据有1亿条的话，我们可以在毫秒。然后我下面将介绍一下我们在这个方面是怎么做的。因为E拓展呢，可以给到我们一个接口，做engine的过程，我们可以拓展这个引擎，我们在这里面实现自己的一套抽象，我们可以将各个计算引擎。实现。不同的。C service，这样子我们就能知道说不同的引擎应该在是什么表现以及怎么编码，然后再调用引擎调用native方法去给他们做索引及做解释。所以主要的部分是在。Service里面，以及把入到E主要是在那个里面做到。后我们什么时候生成，主要是在生成的时候。

So，然后生成的。向量的那个。这一部分呢，我们因为这里全部是可扩展，基本上作为抽，所以现在基本上嗯，可以横向的扩展出其他的存储或者计算引擎。小的。性能介绍。我让的那个正我开始介绍那个小鸭子的。1000万的数据在128人。召回率99。性能也在90毫，基本上在90毫秒。啊，那就可以返回。啊，开始介绍完了那个我们的向量，后面想要介绍一下地理位置。

嗯，在E地理置里面主要用的是本是用哈的，本是用的三角是呢，呃，有一些是基于地理位置做召回及做基于地理位置的检索或者之类的应用。需要有。需要一些热力图或者一些其他的方式，所以我们过HH呢主要是。一套地理位置框架。它基于六边形的。然后这个呢，主要是用来做热力图以及一些嗯。地理位置的召回的应用。然后在上面说啊。它会基于六边形，然后做一个区域范围的查询，这样子的话会比官方的一些地理位置的查询会稍微有一点点的提升。我们的。呃，在一公里以内的圆的范围的查找，如果基于基于H3的话，会呃，从18毫减小到八毫。

我们还有一些聚合的场景，因为基于H3已经将你的数据聚合好，写入到ES里面，这样子的话，我们的呃基基于地理位置的聚合查询会。原来快到一倍以上。就是我们在功能上面，前面介绍我们是在功能上面的，基于引擎的改造，也是前面两个也是其实都是在做的，其实在做一些其他的东西，主要是在安全上的，应对一些监管的要求。UN还有一些外部的验证，但是呢，可能这样比较通用的，但是就。我们想要的是以下，所以我们干脆不用，不用超超也有一些license的要求，然我们全部用GDPR的套，这个GDP主要是应对欧洲的安全监管以及。

安全监管这个GDP能代表什么？这用所有的用户，所有的服务的访问都是可以知道知道是哪个用户的。过来，在后面的图里面我将介绍这个，大家会看到gdrken带来会显示成什样子。然后这个token呢，其实跟其他差不多，我们知道token哪些权限，做了哪些事情，所以我们就摒弃了那个basic基于用户角色的方式。然后第二个我们做传输加密，基本上跟。都是在上面加的。第三个我们主要是做的数据的安全，数据的安全可能。跟官方不一样，官方的会有一个脱敏插件，就是可以的，数据敏是在，因为我们些数据是用在上，需要在。

自建IDC里面做数据的落地，所以我们需要保证这一分数据的安全，所以这个数据安全在下一讲。第四个就是审计，这个是常规操作。因为呃，应对一些监管要求，必须将数据落在非自建的IDC里面。提供。这样将。嗯。写入和读取的部分注入到E里面去，主要是注入index input index output部分，大家看代码会知道，Index index output主要是用于在里面读写数据的。

然后在我们读写数据的时候，因为它也是基于快的读写，那我们在基于快读写的时候，会去拉一基于索引的一个主，用主密钥来加密这一部分的数据，这个实现的存储上面的。加密。所以这里有一层抽象，就是我们在可以抽象成X2的。我对下面这一层的存储的抽象，可以做到数据的的加密以及文的落，或者是基于文件系统的交易，这样子就可以继续多种。数据安全落地了。哦，这有一个小的介绍，就是可能因为它有加密的话，这一部分的数据可能会有一部分的性能损失，但是基本上还是在可接受范围内的。

嗯，可观测性响应，想要做整个在E链上的可观测。那一会我们可能要看到了。基于ES的可观像是没只有E去其他的数据过来做，我们可能想说己的那些数据做。这边的这个是一个一个流程，就是会进去生成的一个过程。然后那上面的那个什么点。Test就是我们的服务名称，这个服务名称带过来，就是基于GR带过来。然后我们解析到这个服务是从哪里。它的调用上下是什么样子。哦。

这个比较清晰，就能知道在每个第二个链上，它耗哪个节点，上面耗时是多少，这样子也能方便我们。啊，整体看到我们数据在哪个地方的耗时。那我们这几个操作主要是在接入层，数据处理层以及擎做一些数据和的打点介绍。然后我们做在协调节点数据节点及做了一些点的数据。做的呢，主要是自己实现action filter，对所有的action进行过滤。也是也是我前面说到的，我们会在安层自己实现啊，就是再封装一下它的engine，做一个抽象。

SH的知道在哪个时间点做了index操作，在哪个时间点做了一些操作。就是在单个按键里面。然后最后一部分是还扩展了那个和index operation这个主要是什么，主要是做那个写那个查询的。可以把自己点上去，比如一些日志的消息或者一些。的消息，以及我们配置的查询，都是可以重新从这个里面获取，然后导到一些平台上面去的，那我们就可以从四个层面到ES这个节点的，到各个单个节点里面各个步骤的信息，然后。那当然这只是一个三个节点，还是需要。

需要像这样串起来的话，需要将各个节点串起来。做到的呢，主要是基于这个。E的。能将我们的一个统一的ID串。所有的请。会将用户请求过来的ID直接。这样子呢，我们打点之后，就根据这个ID做一个观念，那我们就能知道整个ES的第二在哪个节点发生了什么事情。这里主要是从接的每个实力的时候点及整个第二链上的打点上班再做一次聚合。就能知道他的请求是怎么样的。他上报时候，比如说我们就会有说从哪个I。哎，就是他为什么会logo level，主要是因为做这个logo。看他的log是什么什么。啊，它的数据是什么样的。

RY做了哪些操作？它的参数是什么？都能。再做一次聚合就能。满足我们在整个E电路上面的观测。大概介绍少一点，没有大概介绍那么久，差不多半个小时。然后就想说，我们主要在三个层面做了一些单检的改造，主要是在单级群，跨级群，还有向量检索的，还有地理位置上。后面在整个。的EF安全链路的观测性上面做了一些改造。谢谢大家。然后我这有任务招聘链接。好，就就这些。这个情呢，先想下，看看大家有没有什么问题想要提问的。

嗯，现场有小伙伴想要，有问题吗？嗯，这边线上的小伙伴是。有问题想要提问吗？我这边来看一下。老师这边可以看一下，然后。嗯，那个向量的交回主要是基于啊，我们有个扩展的引擎，就是MSB和bus，然后再把特征向量特征的这个部分是在外部，然后特征中程提取的。把这个人写到，然后计算啊，计算啊所引计算的这个部分，我们是通过呃拓展几个引擎做的，一个是是我们现在做了两个，还有一些公司的一些拓展面积。

不是你就不说了，那两个是可能是在外部可以用的。如何实现文本的结合的实现，就是说呃，Yes，有文本的，然后我会将多个结合起来，然后再统一做。没有，我们可以再说该会实现那个方向，可以将不同的单做的结合。可以文本的打分和向量的打分做一个计算，这个是通过方程。并发读写，因为E本身是啊L的，所以他写的时候是只会写一个，不会有。会去改同一个文件，然后不同的，呃，所以这个不会存在，写的安全，读的话应该只会比已经刷掉的，对啊，所以它也会读原来的，这样子是分开的，所以就不会有这个。技能指标开始有一个介绍，大概在一级的数据里面是100毫米。

好的，还有其他小伙伴有问题吗？陈老师的心比较小，比较害羞啊。发货还是？嗯。想问一下你做那个审计，嗯，那个那个审计看是怎么做的，然后那个。有没有弄到线上去，然后那个块对性能的消耗也大。嗯，是这样的，审计本身我们是不能做的，因为如果我们是自己平台，然后还能接触到审计的数据的话，就相当于自己就自己。只能把数据上报上去，然后把数据给到这边，他们做。啊，我们的这。

嗯，你说的审计是指说审计这一个怎么做审计，还是说我们怎么把数据上报到审计是。就请求过来之后，他能够请求操作记录的。那个业务的一个执行的执行，执行的那个。这样就算是。但是会有一些员工的信息，可能一些O的操作，这个可能就不会到这个里面，会外的打到数据里，就比方说他的的response员工信息或者话那些的response会分开打到其他的平台里面去，那包括它的操作链路，就比方说审计的操作链，谁做什么事情的，是可以从这个件里面看到。

就比方说我们这里会有。一个会有个节点IP，但是因为信息里是随机访问，就会有一个从哪个节点做哪个操作个查询，然后。如果有人的话，他这里会有一个，因为我们有GDPGDP知道哪个服啊，在哪个时间做什么事情，这应该是满足审计要求，但如果你说他要查询到数据，需要在另外的一个审计平台做。就是这个东西是就是现在会常态化对。就是如果不排行三四会，因为我会一视频三上吧，啊现在是这样子的，写入的话会要做降采样查询，不做降采样。因为写入量太大了，会导致性能的损耗，如果写入不降啊，写入的话大概用20%的降采样，然后在查询不降采样的情况下。

基本上没什么损耗，因为这些都是网络请求，然后再到另外平台做聚合在E，所以所有的操作都是网络请求。然后如果发送失败的话，也不会对这个做，也不会有那个。太多的损耗，就是比方说他上报失败，会不会就只有说上报就是掉了，就是相当于一个降材样的。这是一个是插件化的吗？还是说是做插件化的，因为。E action。还有那个是等可以将引擎通过插的方式。

顾客进去。这边还有其他问题吗？那我们提问环节就到此结束。嗯，还有其他的小伙伴有问题是吗？啊，我想问一下关于计算分理这块的。就你们你像这个共享存储这块的访问实和基于这个圆盘访问识别这个差距有多大呢。还有基于这个，呃，这个实现的方案，现有。不大差异。是这样的，我们所有的NFS的那些架构都是基于单机房的。呃，不会，就是因为云所的云盘或者N机度是允所。

二你问的第二个应该是说性能是20。啊，首先第一个是可能是本身MF。那一段数据是会在内存里面保留的。然后如果是新货，新的副本。扩。他要把数据读回来，会有一定的延时，但是有个过程是可以在的时候把一些数据先到内存。在加载的数据可能会比较慢一点，但是因为是机房，大概机房。两个两路的话，也就一毫秒不到吧。然后这样的话，基本上的延时，目前看。嗯。根本地盘可能差个两毫秒的写入也是，但是查询的话应该有缓存。

这样的话。没什么，就是当他跑起来之后，基本上没什么太大的想。好的，那我们进行下面的分享环节。那下面有请来自VIVO的刘林老师为大家带来VIVO的技术演进之路，大家掌声欢迎。

大家下午好，然后我今天给大家带来的这个，呃，演讲是那个E测试集群在VIVO的一个应用实践，然后。啊，我叫刘世林，然后在为我从事D类的一个工作啊，然后下面开始我的一个分享。然后主要的分三大类，然后第一个呢，就介绍一下我们整个VIVO的一个当整个ES的一个使用情况，一个规模，然后第二个的话呢，是。啊，我们在调练和日志中心的一些应用的一些实践，然后我们第三，因为我们的规模还算。啊，有一定的规模，然后我们会讲一下我们的一些平台化的一些建设啊，给大家一些参考意义的参考。

然后这个当前也有规模，我们的话是因为我们大家都道我们VIVO是一家啊，因为大家都手机比较熟悉嘛，然后所以我们在在各个地区，对于我们自己的一些机房，在俄罗斯啊，然后德国欧洲主要是在德国，然后比如说我们的新加坡，就是南亚这一块，然后甚至我们在印度会有自己的一个机房的一些建设。中国的话，国内的话就是相对于说业务量是是最大的，然后我们这块的话就是，呃，主要是在比如说我们在华，华南华北啊，包括我们深圳这块都是有自己的一个机房的一些建设。然后数据量的话，我们这边大约数据量的业务的，我们不包括我们的一些调用链之类的一些系统内的一些东西，只是业务的话，大约就是超过了1PB的一个存储量，然后日志内的话就是差不多最少保底，因为我们保持大概是一个月啊，大概一个月的数据量是500TB以上啊，可能还在持续增长，因为有些我们不会去动态保持太久，因为有些日志的话用过之后他们也不需要。

然后服务器的话，ES我们的服务器的话，基本上基本上都是物理级，呃全都是，呃在目前来说规模的情况下面来看的话是七百七百多，然后实例输数的话，就是我运行的实例，就是当前运行的实例就是1800多，呃可能还会有上面涨，现在还在持续增长，基本上每天都会有，或者是每周都会有很多的实力会去扩容，或者是说我们去创建。然后集群数量的话是不管大小啊，基本上我默认是三个实例数的话的集群在600家。

呃，日之内的话，我们的实时写入，写入量的话，基本上都是百万级每秒的这样的一个写入，然后我们当然说不是一个集群呢，可能是拆分了很多个集群。然后美的的存储量的话，都是100亿家的这样的一个存储的一个规模，所以所以说压力还是有的。然后稳定性的我们业务要求要求的话是四个九，核心业务四个九啊，就是我们单个集群最大的就是写入的热量，每基本上超过了一个30TB的一个写入量，所以所以说呃，在有些集群我们会做一些特殊的一些关照，所以有时候我们呃会给他做一些特殊的优化这样的一些操作。呃，我们讲一下就是我们在调用内的使用的一些实践，就是我们怎么在呃调用内的一些大规模的一些呃大数据的写入的一些这样的一个结的。

然后可用性的话，一般我们要求，因为我们第二天也好，我们的日志也好，我们都是虽然说是对内的一些服务，但是我们开发的，对于开发来说，我们要去及时排查问题，不是从调用链和日志去观察，然后他们要求的话，就基本上是啊，要求四个九。就是你不能，就是你每年的停机的不能超过一个小时。然后就是说影响他的一个查询量，或者是说影响到的一个其他的一些指标。的话，我们基本这个。因为我们大家都知道，很多的一些调用链都递归到涉及到很多呃，微服务之类的，微服外的每个调用链子的一个关系都是啊，非常多的，比如说类似于一个核心的一个服务，都涉及到好几百个为服务之类的一些东西。啊，实时响应，因为因为大家都知道，我们去查询日志也好，我们就查询相关的一些东西，都要求响应比较快，比如说人的体验感不是在一到三秒内，比如说我超过这几天就就会感觉是有一点是否是网络问题，感觉还是我的系统会出什么问题，所以我们还是有一定的一个相应的一些要求。

呃，我简单介绍就是我们的就是调链的一个架构，下面的话是我们的呃圈外部，那外部的话是就是我们的整个的一个关注的那个一个外部情况，就是一个外部一个一个要页面就是给用户，就是我们的开发，然后包括他们自己去查询的整个调用链的一些情况，然后下面的话就是我们从采集端最下面就Java安了，因为我们的大部分的一些开发啊。或就是百分之七八十都是在呃Java单去开发啊，然后我们放到去进行一个聚合，然后就放到聚合去聚合它进行一个嗯过滤，然后我们再会放到这一个去卡不卡进行一个实时流计算。

然后计算存在在在flink的上面集群，然后我们要求刚刚说了要求，我们是要求是一个可用性是四个九，所以我们还做了一个双机房，呃的一个部署啊，我们会在这个。在分泌的这个就是一个双写的一个过程。放卡里面，然后蜂卡。然后两个两个的一个，比如说我们的是单独的一些集群或者的一些指标，然后比如说都会放在这个E里面去，当然我们的额现在后面的话，我们会进行，因为使用量非常非常大，然后导致要就是我们的集群呢，负载非常高，所以我们就会要求我们就会先做一些特殊处理，然后进行一些改造，所以我们这里看到的内一些消息，现在是就是说呃，已经不是单个的一个集群可以解决的一些事情。

然后。我们还会就是就是我们在做处理大规模的一些呃E的时候，我们会尽量的去呃按日期去拆分，因为我们大家都在日，我们的时间，我们的日内也好，还是我们的啊，第二练的一些数据都是可以按照按天或者是按小时这么去计算。比如说我们去看到它的一个监控的一些指标，比如说我们看到最近五分钟，肯定是基本上是每秒获取到一些指标，那么我们如果是拉取到我们的时间范围拉长一点，比如说拉取到一天，我们有可能的指标可能是变成五分钟和十分钟的一些指标，进行一个降精的一些处理。然后我们会适当的会减少一些所就是按照时间的日期啊，比如说有时候按小时去拆分减，但是还得减少你的一个索引故障，比如说你的索引状态变锐的或者是噎抖就产生的一些影响的一些状态，可减少的一些情况，方也方便我们用一个集群的一些管理。

然后我们还拆分了一些索引的一些拆分，就是我们在业务逻辑上面。呃，拆分呢，比如说我们，呃，就是一些mirror的一些指标进行一个简单的一些拆分，比如说指标类告警类的一些日志进行一个拆分。然后日志的话，因为我们大家都知道，我们默认的一些热数据都是放在V的一些SS上面，然后呃，也进行了一些冷热数据的一些迁移，然后就是都是自动化去完成。然后也在一定程度上减少一些直观上的一些压力。然后。然后我们还在应用级别的话，就是，呃，就是采用了一些手段去保障我们的E大流量的，下面不要去。

然后呢，比如说我们的日志降级，然后比如说我们可以动态调整我们的应用内，比如说某个应用在发生故障，它会疯狂的去打印A那个A日志，或者是或者是说应用，比如说开发不小心打开了debug日志在。啊，我们举个例子吧，就是大家可以看到手机上面那些推送啊，那是这样的，比如说我们的一，比如说哪个明星啊，或者是说哪个要离婚了，对吧，大家都知道在微博上面都是说，哎，微博优化了对吧，但是呢，我们这里也会有相应的一些流量上上流。然后我们还会做一些呃细力度的一些策略的调整，比如说一些链度降级，比如说在一些大规模的一些活动，然后可以减少这上面的一些写入的一些压力。然后我们甚至还可以控制那个呃卡不卡的一个发送频率，然后甚至就是说呃招网一些数据，就是一些管控，比如说IP级的一些管控，比如说应用级的管控，进行降级啊，比如说就不会影响到一些全之类的，比如说影响到我们ES的一些写入，然后会导致其他的都不可用。

然后我们集群的话，其实后台配置的话，就是比较就是比较规范化的类的一个操作，呃那呃整个提升的所有的节点都是物理，然后190标准的192G，然后CPU核数是32。然后业务类的标准存储nv me SSD。然后日志的话，当然我们刚刚也说了，我们做了一个冷热数据的一些分离啊，冷数据的话，我们是放在了T12TB的一个外挂的一个，呃，S盘上面。

然后部署的时候，我们会标准的计算它的一个40%的一个内存，剩余的一个量就不会超过这个值，比如说也就是说我100个G，我会流只会用到60个G，剩余的四个G，我们会做系统的一些缓存与查询，那个查询效率。集群配置的话，我们当前线上的话就是，嗯，保留的还是保留两个版本啊，因为我们没有全部升级到最新的一些版本，然后老的版本的话，老的业务大部分都是在6.3.2啊，大部分的新申的新申请的一些业务都是升级到七的一些版本啊，七的版本的话，我们会默认打开它的一些安全认证和审计，因为我们不知道七它默认的base的一些。呃，都是免费的嘛，对，然后我们都是就是说每台机器上面也不要求是啊套就是你的版本号是一样的，也是混合部署。也就是说你的六和七都可以出现在同一台上面，但是由于我们刚才看我们的下面这个套餐啊。

我们分ABCD4个。啊，D是最小的，然后D类A类是最二的，A类就是说我们D的话是零到400个G，然后内存默认标准是四个G。然后会给G的一个区。然后C类的话就400~900，然后以此推推推，然后A类是就是独立套餐，什么叫独立套餐呢？就是你这个机器是独占的。就是你的，比如说你这个要求是就是基本上就只有一个，比如说我存储量确实比较大，然后这样的话就会适量的会浪费一点内存的一些使用。然后我们还会就是我们日志的一个分配一些基本的一些设置，比如说日志指标的话，默认是就像之前的话都默认是无副本。

因为他写问量太大，如果写入副本量的，然后数据也比较多，然后这样的话，就我们给他设置的是无副本的状态，业务类的话标准是一个副本，比如说你是。你是那个十个主分片，那你的就是20个分片啊，是这个样子。然后集成参数的话，你的刷新频率业务标准的话，是我们会给他设置的，是啊一秒这不变，这是系统默认的，我们也不会去改动他业务要求也是这样子。然后如果不分使用量比较大的，我们会适当调整它的一个标准，变成了那个呃，五秒日志内和那个刚刚说的监控内都是30秒，比如说你30秒之后才能看到部分的一些东西，所以在某的一个程度上面，我们是不能完全准确的看到实时的一些东西。然后面品的一些最大字段，原来默认的是1万，到我们这里调整到了2万。然后直接写入的一些模式还是。

然后的一些日志类的收同步类的一些，呃，原来是应该我记得没错，应该是60，我们调整了90秒。啊，一次分辨的话，原来呃，默认好像是十分钟，我们调了个位20。然后呃，插件插件的话，所有的业务，业务类的区分是默认不安装的AK和IK拼的所有的一些插件啊，比如说标准就是我们在安装包里面就打包这两个插件就可以直接去使用。呃，大部分都是用上了这个插件，基本上呃，使用效果情况来说，基本上除了这两个除V字研的，然后或者是说其他的一些特殊情况，基本上都是没有什么问题。然后分享两个两个案例吧，就是我们在使用的一些坑，希望大家可以避免一下，就是我们在这个版本呢，是在呃六点。啊，6.3.2就是我们刚刚说的六点三点和7.4.2的一个上面的一些bug，呃，大家可以看到，就是我们的状态上面就是看到，就是写刚开始创建索引的时候啊，就是。

呃，它是一个正常的，但是随着数据的写入啊增长，就是它随着用数据插入越来越快的时候，它就会变成了一个的状态，出现了部分的一个，每个索引的上面呢，就是会出现一些啊。未分配就是的一个状态，然后呢，我们看一下日志，就是它会就是分配副本不成功，然后说提示志出现空指针异常。或者的异常呢，其实其实这个东西我们去看了，也其实去看了一些，呃，观方的一些带一些东西，然后他的就是后来的跟我们去看到的计划，就是说他说你重试，然后重试五次之后还是不成功，他就会报这个错。然后实际的话，它是一个一个有个case，就是大家可以在上面的链接可以去看到，呃，这个链接上面上面最后的那个get的一个状态，它的最后一句话就是说get message。

然后在6.1版本修复之后呢，就变成一个。呃，大家这里很多人懂这个代码，可以帮我去了解一下这段代码的一个，其实他是还是跟那个分配的一些的一些有关有关系。这样的话就是大家不知道有没有遇到这样的相似的一些问题，然后之前这个遇到的话，我们采取的方式就是说我们去减少它的一个啊，临时采用的方式就是减少它的一个分配的一些一个大小。适当的一些避免，但是还是偶尔会出来，嗯。然后第二个案例的话，就是我们看一下背景，首先我们的故障集群版本的话，是7.0的一个版本，然后数据集成节点是31个节点，存储的一个量大约是61个T。然后业务反馈的话，就是在年底的时候啊，反馈就是说嗯。

就是数据写入不了会有问题。然后我们看到整个我们的一个解析一个过程，就是我们会出现我们默认是这样子的，就是这个集群呢，它是所有六十三十一个节点都是must，我们也都知道它是啊，在七的版本，它改进了这个，改进了这个的一个选举的一个方式，然后。31个节点呢，它都是可以啊，进行一个参与选举，当发生有故障的时候呢，这个节点正好是就超过了半数的是基本上是不能响应的时候，这个等于就是跨级重新选举，然后持续选举不成功，然后这就把它剔除了。然后所有的点都是发起投票，然后选不成功就中断，就导致整个过程一直没有成功啊这样的情况下面我们。就是想了很多的一些办法，然后解决的呃，一些问题，首先呢，我们临时的解决办法就是暂时，因为要业务及时恢复，但是如果你持续写入数据的话，它恢复的速度是非常慢的，然后您说我们就关闭了那个通过卡夫卡那上面的卡夫卡暂时关闭的业务的一些写入，然后修改，就把所有的那个number复制就是你的副本。

就是设置为零。然后我们并且重启部分的人员选取不能够已经完全没法响应了，就是你的所有的接口，你的IPA的，所以去访问他的C去访问它的时候都是不成功的。然后我们长期的一个解决办法就是说我们减少must must的一个选取的一个呃节点，我们把master的节点和对not，然后就是进一个拆分部分节点，我们新增的节点就是拆分为啊，Data是节点，Master节点就是我们减少它的一个，就是我们进行独立的一个部署出来。然后运行创建索引和map，就是这样的情况，下面呢就是使用固定的一些模板。不用是动态创建去创建索引的这个情况啊，减少它的一些呃。

这样的一些问题的一个问题出现。然后接下来介绍我们一些平台化的一些建设。因为我们。刚才也说了，我们的集群非常多，节点数也非常多，不可能简简单单的靠一些人工去，嗯，去维护，那这个肯定是吧，大家都是希望都是做一些白平化的一些事情。减少提升我们D的一些对吧。首先呢，我们看一下我们集群整个ES集群的一些能力图，然后呢，我们从整看整个ES的一个生命周期，然后就是说我们从用户提交预算到我们的用户申请的一个工单部署架构类，然后我们要求是就是说我们都是在平台话已经全部完成。然后安全管控方面的话，就是我们要求是最小，默认是最小权限，然后做到产生审计权限管控，然后我们还要核算的一些成本。

然后成本计算，成本统计的一些东西，整个我们做的，因为我们自己最最接触最多的话呢，是集中管理。啊，比如说我们开放给开发，他们用来查询平台。然后啊，进行数据查询，然后数据变更，数据变更是指更新你的map map品和你的一些呃，就是你的索引的一些结构，或者是说我要增加副本，或者是说怎么样子这样去操作，然后数据传输，数据传输的话就相当于说我要把数据导出，然后数据清理，然后把整个索引的一些数据，然后数据导出的话是呃，也在做，就是要导出各种格式，比如说导出Excel，或者是说导出一种特殊的一种形式，还涉及到一些啊隐私管控的一些问题。然后后面的话有索引管理，然后模板的一些数据会备份恢复，就是我们的快照啊，我们目前采用的备份和还原的方式，还是经通过快照的一个方式，然后集群回收进行扩容啊，都是可以通过工单内，然后进行一个审核，然后别名管理啊，然后巡检的一些服务，巡检的话，比如说我们会识别你的哪些索引，或者说状态不对，或者说哪些参数，比如说每个某些节点的JVM参数不一致，然后会进行一个。

出来，然后后面我们还会有诊断，然后生命周期，然后进行跨进的一些搜索，然后都会去引入，比如说我们还有插件的一个滚动升级，他加入，然后版本的小版本升级啊，都是可以做到故障的一个就是我们在平台上面只要点一点就可以完成。然后安全反馈方面的话，就是仅针对针对七以上的版本，因为六的话就是我们需要去购买它的一些东西，所以就我们七的话就是有免费的话就可以接入。然后再可以简单的看一下我们的一个查询平台上面的话，可以通过点击查询，然后也设置再执行种相应的一些查询，就可以获取在左边就获取的一些数据。

然后就可以直接就相当于说你们在后台通过API的一种形式去查询呃数据，这样的话就开放给所有的开发，然后不需要我们自己，比如说用户去提取数据，然后可以看到生的上面的一些东西，但是敏感数据是看不到的。好，大家可以看到A，它上面有个AC create time，这上面的话就是如果你标记的话是敏感度是看不到的。然后这个是索引管理，索引管理的话就是可以看到索引的运行状态，你是open状态还是格子状的，然后或者是说当前的一个文档数量，然后当前的数量，然后还可以执行，可以看到当前索引的map settings。然后还有清除缓存都是可以操作到啊。啊，这个是服务变里刚刚说的就是就是说比如说你的扩容，扩容缩容，然后还有你的，呃。

一些同步状态，然后还有JVM的一些大小调整，都是可以完成在这个界面上进行一个操作啊，然后刚刚说的在这上面你既然加了你的。加了扩容，那么可以要就需要在这里面扣除相应的一些预算，那么根据一个成本的一个管控。然后这是一个实力管理状态，就可以看到你的当前的一些使用的基本的情况，然后可以看到就是你的机器负载，然后可以看到你的CP，然后值板的一个堆，内存的一个M的一个姆的一个情况。然后甚至可以看到你是在部署在哪个机房，有没有做机房，然后这样。呃，监控大家其实很重要的一个指标就是看它的一些监控，我们监控的指标的话，大约是有200多个，监控的一些指标上，所以监控的指标上还是非常多的，就是比如说我们可以看到它的一些，呃，Document的一些使用的校长的一些速度，然后可以看到它的一些的一个使用情况，然后比如说它插入或者是更新。

这些东西都是你看的。然后。这样的话就是就是方便大家去查询，都获取相应的一些东西，简简单的可以看一下。然后我们这个平台的话，做的还有些地方还是嗯做的还没有可能完善，我们还有后面要做的很多事情比较多，然后呃，优先我们会现在正在做的话，就是说我们会做一些故障自愈。比如说我们的节点挂了，比如说监测的状态不在，然后我们会做一些，呃。比如说自动拉起，或者是说yellow的状态，自动就分析它的日志类啊，分析它的JC日志，然后进行一个反馈给你的反馈给前台，比如说你的我们分析基本情况是这样子，比如说你就可以根据这个操作，就这当然当然我们的根据的新的一些分的分析啊，我们比如说通过类似提供aw的报告，就是提供一个巡检报告，就是发现异常，进行一个消息发送。

然后性能优化，就是我们会通过一些比如说我们遇到一些监控指标的一些分析，以及提供一些建设性的一些建议。嗯。然后日志分析，我们现在正在做的，也就是说这个日志分析，就我们会分析它的GC日志啊，GC日志的话就是我们会比如说我们GC比较慢，新脑的一个就是为什么会变慢，然后就会相应的一些分析关键字啊。啊，当然这个，呃。虽然我们正在做这块，但是效果不是很好，就是就是分析经常不对，所以我们在做一些，然后最后我们要做的就是白化。

呃。白化的话，就是我们提升我们整个D就是一个幸福感的一个重要的一个指标，就是我们尽量就是减少我们去后台去查询它的一些的一些东西，尽量通过我们前端页面就可以完成基本上你工作的85%以上的一个工作内容。这样的话就是基本上你自己有能力的话，就是呃去呃就做更多其他的一些东西，而不是只是天天关注于我们的一些基本的一些操作啊。这样的话就是如果全部做完了的话，基本上是整个的一个ES的一个生命周期，基本上也就非常啊比较算是比较完善的啊，然后刚刚前面几位大佬也提了，就是说很多的一些内核的开发类的工作啊，我们也有类似的一些想法啊，啊，到时候大家可以交流一下，然后。谢谢大家，然后这个呃，是我们VIVO的一个互联网技术的一个公众号，然后我们很多的一些技术就是在上面，大家可以关注一下啊，谢谢。

老的分享，那这边有什还想要提问？可以，现在进行提问。现场小伙伴有疑问吗？第三题。呃，我们会内存的话，内存是给到最大就是不超过31个G，给到31G，然后规模的话大概是30。31个节点，然后100多个索引嘛，然后分配数量的话，每个的话大约是十十几个一个分片，然后还有一个分。

31个阶段挂了43。嗯，差不多内存。哎。不超过分析。搜索要求很高。对，他是就是还是有关搜索的，还有一些业务类的一些存储的一些数据。是。刚说说的你们那个什么，一个机器是192G内存，然后32核那个，那是你那就是物理机的那种是吧？对。然后上面是应该是一个机器会是吧，对是的，但是一个集型不会在一台机上面部署多个节点，只会有一个，我就说你机器上那个那那个节点直接节点有做什么资源证离。

嗯，这个暂时还没有，然后就是你那边说的，每个机器去预留40G的那个内存是40%。对。那是这个是什么？就是我们当前算的，比如说我们会给，比如说操作系统，我们预留给他十个G，比如说类似于这样子，剩下的就划分，划分你的JVM的一个，减掉你的JVM的一些，呃，内存，然后再剩下的再计算。也就是说你们其实是如果说把资源扣除之后，然后。然后再就是可能一些对外在用。再包括说例十个G，给自己系统个正常。

比如说就相当于说我给你发，比如说192对吧，然后去掉本身的1010G或者20G给系统对吧，然后剩下的一百一百一百五一百六，然后给到了整个的一个划分，然后你最大就可以使用到了最大就可以使用三个A套餐，这四个A套餐。就是你们不是说节点的是对外对内是按照1:1的比，就是只是只是是往这个这的多少之后扣完，这完之后，扣完之后把那些所有金额用的计完，扣完之后剩余两四十。对，是。这个40%是有去。你测过什么之类的，还是说是就是一个你们自己的一个经验啊，我们之前本身是根据这么多集群大概的一个估算，然后有一个官方也有一个类似的一些，呃，就是有个一个参考值，就是官方只官方文档上面也有一个参考值，就是说它需要一定的那个缓存进行一个给其他的一些使用，不只是接的一些用。

然后本身Java他自己也有占用的一个空间。过程，我想问一下具体是做啥？呃，我们目前做到故障治愈的话，就主要是还是两个点吧，第一个是它的，呃。呃，Yellow状态，事业的状态，我们会去分析它的日志和就是拉取出来，然后进行一个简单的一些关键字的一些匹配，然后进行一些比如说是不是材料是什么原因，是不是要是当时没分配成功，我们再会分，会手动给他进行一个分配，这是第一个，然后或者是说他会达到高低水位，就是比如说它会没分配成功，会检查相应的参数，然后第二个现在做的就是不障，就是你的节点大了，比如说就会判断你的会自动拉起。

然后这是一个几个算是不能，就是不用人工去介入的一些东西，然后这是两个，然后刚刚说的一些数据分析的话，就是分析它的，呃。日志主主要还是他的错误日志和他的GC日志啊，分析这两块，然后比如说就是分析他的JC新脑袋的，也刚才说的新脑袋的一些解析，然后看能不能分析一下什么结果，所以就会看这个东西，主要是。呃，我想问一个问题，那个在你们的规模的。想这个。

交通区的那个历程上。是哪一部分？操作系统。呃，我们这操作系统的话，主要是做了个事情吧，第一个是它的一个，呃，所分区就是我们的默认的交互分区是全部关闭的，是不会开的，这是第一个，第二个的话呢，我们的大大大业大分就是大业大就是它的大业分配，这个也是关。而是做这两个事情，从内存方面就是做这两个事情。嗯。扩容的时候是否会调整中分配数呢？呃，我们一般常规的一些业务的话，就是控制一般，比如说小鸡群，一般大部分的情况下还是小鸡群为主，大鸡群还是比相对来说没有那么多，嗯。

这都是特殊情况，大部分的业务的话，基本上我们申请的时候，一般他的刚开始，比如说新业务来的时候，他申请ES都会一般都是以最小为单费以我们不会要求说你那这尽量去减少资源的一个浪费，就是你不要用，那比如说我刚了一个新业务，就是从都是能慢慢发展起来，都是以最小为，比如说我们会先给他一个啊一到三以比如说三零到300个G，然后这样就分配内存的给400个G，呃分片。数量的话，我们一般就是最少保证给到，就是你的数量不是特别多的情况下面，呃区分是这样的，就是我们基本要求是官方给的建议，就是你的基本的业务在搜，所谓的就是呃单个分辨数量总分辨啊，只是说总分店的数量不超过三个十到50个G，然后呃相应的话，日志类的话就相当可以限制放宽一点，就是50往上面走一点点，不要超过100个G这样的一个情况。

然后我们要求最少基本不低于五个分片。当然你有说，除非你有，比如说像啊和聚合类有特殊要求啊。就可能会需要他们自己了解一些风险，因为最后大家都知道就是计算不准的一些问题。然后啊，扩容的时候不会去调整它的，我们所说的扩容扩容节点。并不会去调整它的一个主分配数，如果调整主分配数的话是要index的，所以我们并没有这么去做啊，这是业务上面使用的一些问题。第三页有问题吗？好的，感谢大家。集团天数的。这个问题我来我来补充一下，就是我们社区版的E，这个集群的分数一般是限制。

呃，能不会超过3万这样量级，当然那个腾讯呢，内部对这个那个分做了一些优化，就算一个这些人提到百万级的。所以如果大家感兴趣的话，对这块优化感兴趣的话，可以去后边搜一下那个百万。嗯。还有一个吗？行。也是收集管理。呃，这个的话是我们自己写的，没用官方的这一套，我们是，呃，没有用官方的那一套IM'的那个I'm来的这个这个东西，所以我们用管管管理的话是类似于我们尽量做到无入侵，是由业务啊，我们从我们这边调接口，然后去去处理，就是比如说我们放一个周期，比如说我们每天呃新创建一个索引，然后30天后保留一个月，31天后我们自动删除，然后都是一个调用的一个结果，一个类似于这么一个任务的一个。

东西，然后升级E版本的话，版本。小版本，然后我们要求都是统一，最好容易管理起来比较方便一点，所以我们不会要求，呃，因为小版本更新，除非你是有特殊的什么呢，比如说刚刚说的遇到一个bug性的问题，影响到的业务，我们才会跟他去更新，然后需要去审核提单，一般我们是不推荐他们去，就是我们多版本就管理，也给我们后台的一些麻烦，所以我们一般都是随大流啊。然后定期合并。所以。呃，这个我们暂时这个这个的话，我们没有做这个合并索引的话，我们现在现在还没做这个事情。

呃，这个都是自己研发的，对，然后大家可以参考那个开源市区的那个可以的可以的那个东西都是上面差不多。感谢老师的耐心解答，那么截止目前，我们今天所有的嘉宾已经演讲结束了，我请代表腾讯云感谢大家的支持。