Apache Doris 社区回顾、展望及 Overview & 4.0 AI-Ready原创

嗯，大家好啊，我是来自飞伦科技的伊国磊，也是ados的PMC啊，今天我的分享主题是the fastest analytics and social database base in the area area.啊，过去的一年do瑞S发展非常非常迅速啊，我们发布了我们的4.0版本，在4.0版本中呢，我们大约合并了9000多个po request, 其中包括大约300多项的功能或者性能的改进，嗯，有200多个contributor参与了我们的呃开发工作，大家可以看到我们很多开发工作集中于比如说我们的向量索引啊，我们的文本索引，包括BM打分，还有我们针对类house的优化，包括我们这客观测性的提升，还有我们的cloud native的一些系列的改进。下面呢，我将通过以下三个方面介绍一下我们这个版本的特性。首先是AI。

呃，大家可以看到啊，基本上数据库拥抱AI的第一站基本上都是vector search, 其实在Doris2.0的时候呢，我们也集成了一些vector search的功能，只不过当时我们的向量的距离计算是通过一个暴力的函数来实现的啊，它的性能其实比较糟糕的，所以在这个版本中呢，我们集成了一些an的索引，主要是基于HNSW算法，然后我们的向量类型呢，可以，呃，主要是通过一个ref float的方式来表达的。我们可以支持四种距离计算方式，像L1 L2 cos, 还有product，呃，大家都知道向量索引非常非常耗费内存，所以呢，我们也引入了一些向量索引的量化的方式，主要是SQ for SQ eight, 还有PQ，呃，目前呢，我们可以支持两种比较典型的查询，比如说像这边这个套查询，还有像右边这个呃查询。嗯，在做完这个工作之后呢，我们对很多嗯特性呢，做了非常系统的测试，首先是我们的量化的系统测试，我们以一个1000万的的向量数据集，其中每个向量是768为比例哈，它在压缩之前，它的向量缩的存储空间是31g，压缩之后是9g，大家可以看到啊，它的压缩率还是很高很高的，基本上现在的存储空间是原来的1/4，所以呢，非常非常的好的集成内存。

而同样我们在qpis上可以看到，在压缩之前我们的qpi>3300，那压缩之后是3100啊，Qpis是没有太大的降低，而它的召回率呢，是从91%降到88%啊，它的召回率也没有降低很多，所以大家可以看到量化是非常非常不错的方式，同样呢，我们可以从qpi上来看呢，就是我们的可以我们的压测呢，是通过240个客户端来并行的进行压测的，它的平均每个响应时响应延时呢降低到70ms，而且它qpi可以支撑3000多，基本上能够满足绝大多数的啊有向量索引需求的这些AI的应用。

除了向上索引之外，我们还增强了我们的文本搜索的能力，那在过去呢，在DOS很早之前，大概2.12.0的时候，我们就集成了倒排索引，但是我们的倒排索引呢，能够支持比如说大于大于等于小于小于等于这些精确性的计算，因为我们没有一些分词能力，没有打分能力，所以在对文本搜索能力支撑并不是很足，那在这个版本中呢，我们引用了啊系统的提升了我们文本搜索的能力，首先我们引用了分词能力，我们支持了像IK分子，结巴分子，拼音分子，还有ICU分子来支持这种多种多样少数少数民族语言的这种方式，呃，同时呢，我们还支持了多种多样的匹配的方式，比如像match any match free, 还有matchsh all啊，同样我们也注意到越来越多的用户再从ES迁移到DOS上面，他们遇到第一个问题呢，就是ES里面有有这种类似于losing的这样query的DSL，那么迁移到Doris上的时候，它迁移起来比较费劲。所以呢，我们在do。

里面也支撑了一个啊，Search这样的一个搜索函数，它的参数呢，用户可以输入像lon这样的跨DSL这样的用户迁移起来就非常非常简单了。呃，除了文本匹配之外，我们还支持了BM打分的策略，呃，B m Mo打分，我们的基本原理呢，是我们在一个tablet级别会生成一些文本或者分词的统计信息，在我们在查询执行过程中，我们在搜索每个segment的时候，我们会把这个tablebt级别的全局信息啊注入到这个segment内部，然后再segment内在查询的时候完成打分，然后当所有的segment啊都打分完成之后，再汇聚到一个中心节点完成top hit的计算。目前呢，我们可以支持像match anyn matchtro match free match free prerix, 还有search这所有的匹配算法的打分能力，大家可以看到右上角这个简单的呃思后L语句，它就完成了对文本的过滤。同样对。

相关性做了BMM打分。呃，除了呃，We search和for text search之外，我们还实现了一种融合的搜索的方式，它能够将we search for text search, 还有我们传统的circleql的这种匹配，我们认为cql search做一些融合，比如我们以左边的这个比较典型的circleql为例子，它可以对update time做circleql的这种过滤，比如大于某个日期，小于某个日期，同样呢，它可以对description字段做这种啊，文本上的。呃呃匹配，然后呢，我们可以根据呃向量。向量数据向量数据这种像语义级别的近似计算，大家可以看到一条circle就可以完成三角的融合，我们相信呢，通过这种hybrid search试能力，能有效的对像现在典型的AR上的比如RA做赋能，消除大模型在呃筛选内容式的这种幻觉。

呃，我们的第二个AI能力是我们的AI function, 呃，我们希望能够通过AI function能跟大模型做的很好的这种联动，比如说啊，我们以右边这个呃搜后为例子，首先呢，我们建立一张表，它存储的是一种招聘的信息，呃，第二个呢，我们也可以再建立另外一张表，它存储的是一个求职的信息，那在过去呢，这两者之间的信息匹配啊，往往需要添加很多很多字段去描述，那现在就不需要了，我们可以把这两者的信息做一些关联，关联完之后可以简单的把这个信息传递给大模型，做一些filter，那大模型自然会做这种相关性的这种判断，做这种过滤。那除了这种孤立函数之外，我们还集成了其他的十几种的这种AI的函数，包括AI classify AI extract, 还有AI generate的这样的函数，通过这些函数呢，能够非常好的跟大模型做联动，目前呢，我们支持像open AI啊，Germaniny啊，Deeppick就主流的啊，某模型提供商。

第三个能力是我们MCP server的能力，通过MCP server呢，我们可以将Doris的库表信息，还有我们的执行查询的这些审计日志信息啊，包括智能诊断这些能力通过MCP协议暴露给AI的应用，包括像一些AI agent.同时呢，我们现在呃，我们的MCP啊，协议支持主流的MCP server client or cloudy deskt top.除了这些其他数据库都能提供能力之外呢？我们的另外一个特点是Doris，我们同样是个click house engine, 我们可以通过Doris catalog将mycyle postcyle click house甚至是S3成一个文件报露成DOS的内部的一张目表，通过DOS mcb协议跟其他的AR的applicationlic server做联动，这样的话，用户就不需要在你的模型开发的过程中连接多种多样的数据源了，有do一个数据语源基本上就可以了。第二部分我想介绍的是我们的性能上的改进，首先是上性能的提升，呃。

在这个周期里，我们对ARM做了些系统性的优化，不论是算子层面，还是我们的很多表达是函数执行层面都做了系统性的优化，我们系统性的适配的像nail，还有SVE这些ARM上的指令集，比如说啊，我们在优化完之后，我们在AWS的grav for的架构上面对主流的这些奔nch mark就做了测试，包括K、奔SSB，还有TBCHTPDS，在一个典型的比如16核CPU 32g内存的场景下呢，我们发现ARM上的性能呢，基本上要领先叉八六百分之40~50%，如果我们考虑到M的芯片的价格往往比叉86要更便宜的话，这个性价比提升的将是巨大的。啊，我们性能优化的第二点是针对于top n的优化，Top n查询实际上是在很多工具里面经常用到这种查询，比如说啊，我们用DB的时候，经常是selection from table limit10，甚至order bag个字段，LIMIT100之类的。

这非常典型的查询，尤其是而另外一个在日场景下面也用的非常非常多，比如说啊，我们以左上角这个circle口为例子，假设说这个表有100列，那么我们order by其中两列。在我们正常执行过程中啊，就是把这个表这100列全扫出来，然后用这两列排序，然后再去比如limit的10，那在这个过程中我们会发现其实在我们的排序过程中，其实其他90多列其实不需要的，那么我们在我们就但是呢，我们原来的执行方式需要把这90多列全都读出来，那么就明显的RO放大。呃，另外呢，在整个过程中，所有的数据全都要堆到内存里面做排序，那对内存的消耗也比较大，我们在考虑网络上的沙暴，那对网络的带宽消耗也比较大。所以呢，在这个版本呢，我们实现了啊，基于套喷的延迟孵化的技术，那首先呢，我们会把我们的查询分为两个阶段，首先我们会只读取我们必要的排序字段，在内存里做排序，排完序之后，我们在返回结果给用户之前再发一次RPC，去把剩余的其他字段全都读取出来。

那我们这个优化，它不仅仅对这种单表的这种套分查询有效，甚至对于多表的状，它同样能够生效，我们拿我们的这个新的，呃，执行能力跟我们过去比如在TBC是1TB上一些典型的查询做了一些改写，发现在很多查询上面它都有10倍以上的性能提升。呃，我们第三方面的性能提升是针对于我们数据湖上的一个性能提升，呃，我们将我们的多个物化视图的能力迁移到了图数据弧上面，我们可以针对像icebg或者派蒙上的呃查询，对多个表我们可以建一张物化视图，然后在查询的过程中我们感知数据的变化，然后如果能够支持我们透明改写到我们的无化视图之后，就会以直接改写到无化视图上进行查询。

我们可以看到啊，通过多模化速度的加速，它都有很多查询都有几十倍以下的性能提升，对于延时呢，也有降低很多很多倍，比如我们的延时基本上降到几十毫秒这种在线的级别。第4方面呢，是我们对mow表的执行引擎，Mow表是一种非常非常常见的一种执行引擎，也是非常受用户欢迎的一种执行引擎，很多情况下呢，用户将会将马西上的数据分布分表中的数据同步到DOS中，用DOS的1的这种分布式计算能力来做这种跨库跨表的查询。那在优化完我们的mow执行引擎之后呢，我们将它跟click house做了对比，我们可以看到啊，我们在一个SSB这样的benchmark的数据集下来，将SSB这种数据呢，做25%的数据更新，持续的更新，然后再做查询，大家可以发现啊，所有的查询DOS就要比CS快很多，那整体查询。呃，延时上来看呢，我们大约比C快25倍。

另外一项查询呢，另外一个性能优化是对我们vaor的性能优化，Vaor是我们在DOS2.1中推出的一个呃功能，它的用户场内的这种使用方式，就是像左侧这样，会把一个原来的Jason这种存储这种行存的把。拆开拆成多个列存，那就会利用列存的很多优势，比如列裁剪或者压缩这样的技术来加速我们的查询，在这个阶段我们对它也做了一些RO上的优化，我们可以看到啊，在这层bench这样的一个benchmark场景下面，我们的cold run啊是拿到了第一，然后hot run是第二，我们认为呢，How cold run也是非常非常重要的，因为在很多用挖人的场景呢，它是存日志的，而日志的很多都是冷查询的查询，冷数据的查询，所以对于冷数据的这种性能优化，我们认为是非常关键的。同时呢，我们也注意到并不是所有的啊Jason它都能够变成列存在在数据库中存储的，而且并不是所有的访问方式列存都非常非常合适的，而有很多场景下面的用户需要一个行存的访问方式，那么在这个阶段呢，我们也对我们的JNB的性能也做了很多优化，JCNB我们发现啊，我们提我们有大约二三十个啊，对JC处理函数我们可以看到啊，几乎在所有的函数上面，JCNB的性能都比JC要好很多，平均呢要好5~10倍以上，所以呢，在do4.0之后呢，我们可以这么说，就是过去用户在DOS里边存储J些string这种方式都可以通通的迁移到使用JCB上来，你会得到巨大的性能提升。

下面一个优化是我们针对cash。在过去我们经常见到用户的一种使用方式，就是查询DOS之后，然后把数据放到一个red中做缓存，这个这种查询模式，它对一些数据不怎么更新，比如数据是T+1的更新，这种高并发的报表是极为有利的，因为在每一天数据就要更新一次，那所有重复的查询就要拿从red拿回就好了，他对用户的查询延时，包括数据库的负载都有大幅度的提升。

那我们也可以注意到，在过去这种方式呢，它有个明显劣势，就是假如说数据更新了，那么red数据可能来不及更新，那查询数据可能是旧的，对吧？所以呢，我们注意到用户这种使用方式之后，我们在DOS里就内置的这种能力，那首先呢，我们在查询过程中，我们会把我们的查询结果以一个catch的方式缓存在B上，所以呢，它可以分布式的存储，它的cash实际上可以是巨大的，那在查询过程中我们会感知数据是否有更新。那如果数据更新，那么catch也会自动失效，以及你的C后语中是不是有一些non determinemistic的函数，比如now，它显然会不断发生变化的。那在满足这个条件之后，我们才会使用cashche，那用户就不要再关心Reddy的cashche是否生效，是否失效了。那用Dollar SE cashche呢？你可以默认打开，那么你会发现很多场景下面性能就会有极大的提升。

同时呢，在这个版本中呢，我们对我们的优化器也做了很大规模的提升。啊，我这里呢，我列举出四个比较典型的，首先是分区的裁剪，我们发现呢，在很多场景下面，用户会把大量的历史数据存在DOS里面，比如说按天分区存30年的数据，那么可能有上万个分区。那分区裁剪性能就十十分关键了，在这个版本中呢，我们将我们的分区裁剪性能提升了10倍以上，同时呢，我们对数据的倾斜还做了优化，大家都知道在join成在join啊算子里面选择哪个表作为哈希表，哪个表作为prob测，它对性能影响是非常非常大的，那在数据倾斜场景下面呢，这个影响更大，在这个版本里面，我们优化了我们数据倾斜的计算方式，那我们的性能呢会提升5倍以上，同时呢，我们还优化像我们的分布式聚合能力和data trade的能力，它的性能分别提升啊4倍到7倍。

在执行层呢，我们也优化了大约几大约十几项的这种算子或者函数的性能，比如说我们的set算子的性能就提升了30%以上，而且我们对于我们的排序算提升了170%和520%这样的性能。大家都知道排序其实是在Co里比较常见的这种使用方式，所以呢，我认为这种排序算子提升性能是非常关键的，而且我们还对一些像低技数列排序啊，高级数列的排序都做了一些优化，包括状语算子，我们整我们整体提升提升了10%，20%。那在函数和表达式方面呢，比如说像串口函数，我们提升10%左右，还有说表函数，Explode函数，我们提升65%，对于在应用行为分析中经常用到的漏斗分析函数呢，我们提升了300%。还有KSW这样的函数，KSW函数我我我们有注意到是在那比如说一些BR工具里面total拽生成的一些circleql里面经常常见的一种函数啊，我们像我们对一些通用的case s问的提升有10%以上，对于一些有很多not值处理的啊，Case s问的函数，我们还提升了175%~1%些复杂的CASE4，我们提升到720%，复杂的case问呢，我们注意到有很多情况下，用户拖到C口里面有几十个case s问，那这种我们的性能提升是非常非常大的。

第三个方面呢，我想介绍一下我们在功能上的一些改进。首先就是我们的lake house, 嗯，在这个版本中呢，我们系统的提升了我们lake house在泰蒙和icebg这两个lake house引擎上的，呃能力，首先呢，我们支持了这两者的rest catalog, 我们也支持了branch tag这样功能，还有time travel这种功能。我们也支持了skime change还有system table的功能，针对派蒙呢，我们也支持了像batch incremental query的能力，通过这些能力的提升呢，我们DOS现在是完整的支持了派蒙和iceberg上的query的能力，未来呢，我们在下个版本还要支持像right back的能力和compassion之间能力。

我们将生从一个简单的query engine正式升级为一个完备的啊cos管理引擎。啊，第二方面呢，我想介绍往下我们在存算分离能力上的提升，存算分离是到了3.0推出了一个非常重磅的功能，到目前为止我们统计到啊，就大约有300多家企业已经升级到了醋酸分离的版本，同时呢，在中国主流的云计算平台，比如说阿里云，腾讯云，百度云，天翼云都已经开始啊托管我们的存算分离的版本，那在4.0上面呢，我们对对于存算本分离版本做了更加细入的优化，比如我们的catchche的持久化，Catchche l ru淘汰策略，包括我们的预热的功能，包括我们读写分裂的功能，以及大家都。经常遇到就是小文件读写S3的时候，那么多IO，那么多小文件元素的访问的成本问题，做系统性的优化，所以呢，大家可以也可以尽快升级到4.0版本来体验我们存在分离的提升。第三个呢，就是s spll disk, 那在过去呢，啊Doris，我们可能只是做一个简单的报表查询了，啊这么一个olap引擎，但是呢，我们现在注意到越来越多的企业用户在将他们过去在hive或者Spark上的一些离线的计算逐渐逐渐向啊DOS迁移，尤其是一些中小用户，他们可能不太想维护非常复杂的技术站，他们希望通过Doris来完成整个数仓的离线的ETL或者ELT的计算。

那在过去用户经常遇到的一个问题就是诶，跑着跑查询，这个查询内存不足OM了，那我们在过去用户只能来把任户拆，小用户又在用户侧完成这种拆分，那在这个版本呢，我们提供了标date的能力，目前呢，我们能够对像hush aggregation order by hassh John, 还有CT这四个主要的算子做落盘，它的基本原理啊，就是我们会把内存里的数据结构做成按照哈希做分区，落到一个一个分区里面，然后再。按照一个个分区来完成计算，比如说我们以哈是join为例，因为哈是join是在几乎所有的差询里面就会遇到这么一个join这个算子，我们会把呃build的哈希表，把哈希表把它落成一个一个的文件，按照哈join的key做成一个一个分区，每个分区落成一个或者多个文件，然后同时把呃prob册就是也落成按照哈还John的K落成一个一个或多个文件，然后呢，按照分区，一个一个分区加载到内存里，构建哈希表，然后再做这种PRO，这样通过这种硬盘的方式来完成这种重要的计算。我们对我们整个s SP data层呢，也做了一个系统性的测试，我们使用3个B，每个B16核CPU 64g内存。

我们跑的是TPCDS是TB，叫奔驰mark。我们相信这种数据集基本上能满足很多中小用户的需求了。我们可以看到啊，内存和硬盘的比例基本上1:50左右，我们通我们大概使用了啊，28000多秒，近3万秒的时间完成了整个TPCDSTB的这种奔驰mark的啊，100条的运行，大约呢，我们也测试过Spark Spark大约是在3万多秒，所以它的性能基本上是差不多的。

4.0版本，我们另外一个特性呢，是我们对于我们的可观测性的能力啊，做了系统性的提升，主要体现我们的成本和生态方面，这里呢，我主要是介绍一下我们在生态方面的向的提升，目前呢，我们的可观测性平台能够支持像发bit lo dash flow bit以及卡普卡就主流的数据采集和流失的消息传递的这些系统，把他的数据灌入到DOS里面。同时呢，我们也支持了像寡发的K8纳这些数据库可视化的工具，所以呢，如果在过去你在使用ELLK将stack来管理你的日志或者管理你的matrix，那么你可以放心的迁移到Doris里面，不论日志采集工具还是可视化工具都可以完全的迁移过来，迁移过来之后你可以感受到首先是成本上大幅度降低，第二个是在导入的过程中啊，速度会非常非常快的。

嗯，下面呢，我还是想介绍一下我们的ran，我们刚才提到ran对于Jason的这种列存的加速功能，但是呢，我们也注意到。在用户往DOS存在Jason的过程中啊，它有很多列是非常非常稀疏的，稀疏的意思呢，就是说有一些行，它这个列子值可能有值，可能没有值，但是呢，它有些值可能都是都有的，还有一些值可能都没有。那么呢，我们在。原来我们打散成列层的基础上呢，我们支持一种吸收列的这种列，它可以将一些啊非常稀疏的列，把多个行多个列融合成一列单独存储，这样的话才能有效的减少。我们的存储空间因为列非常非常多的时候，大家可以注意哈，就是它的原数据的无害的非常非常大的，同时读取的时候是非常非常离散的，那么通过这种列存的方式，合并性多列的多列和成一列的方式，它能有效减少我们的这种元素的overhead，同时也能提升我们读取的性能。

啊，同时我们也注意哈，就有很多情况下，在过去用户呢，都是用ES来处理Jason的这种存储和查询的。而在存储真性的时候，用户除了想依赖warrant这种自动的推断一个资源类型之外呢，他还想希望通过像ES这种dynamic temply这种方式，对于某一些列名的这种pattern做这种。呃，预定义它的推导些类型，就不希望我们自动来推导它，希望它来定义一种推导，所以我们在挖N的基础上，我们支持了我们的skimma template, 大家可以看到在左侧就是我们可以在定义的一些pattern，这pattern可以定位string类型，也可以定位成big int类型，那我们在处理Jason导入的过程中呢，我们会借助这个预定的pattern，对。我们的类型做特殊的处理就不会自动，比如说推导成印台，String会根据用户的定义来推导。

除了warrant之外呢，我们对于这种机的类型。这个版本也做了一些增强，我们支持的像GU po GU circle GU line, 还有multi po, 还有GU po啊。这些类型啊，比如说啊，我一个简单的机构类型，大家可以看到，就是比如说我们计算从北京到纽约的球面区里，呃，就可以通过这种ST distance啊，Sphere这种这种函数来完成，嗯，除了这些函数之外呢，我们在GU类型基础上，我们还提供了大约20多个机的函数，大家可以看一下我们的官方文档。嗯。通过呃呃4.0版本能力的介绍啊，大家可以看到DOS正在从一个过去一个简单的olap引擎变成一个面向全部覆载全部数据类型的这样的一个呃数据库，首先呢，大家可以看到我们在我们非常擅长在实时数据上这种实时的分析能力，我们有了S标data能力之后，我们可以做过去这种数据的啊数畅的构建能力，我们就要data war housing, 我们可以非常好的支持像派蒙I explore haveve这样的数据库的引擎，我们是我们是一个非常快的Li house的跨engine，我们能够非常好的支持各种可观性的生态上的工具或者组件，我们的成本还有我们的效率都非常非常高，同时我们也补齐了我们在AI上的能力，我们可以做，我们有A我自己的AI function, 我们可以做for search, 我们可以做VE search, 我们甚至可以做，把这种各种各样的能力融合起来，这种hybrid search能力，所以呢，非常建议大家都可以。

看了一下，到4.0去体验一下，给我们提供及时的反馈。啊，谢谢大家。