极速入湖，即刻分析：Apache Doris 实时数据湖架构的现代化演进原创

OK, 呃，大家好啊，非常呃，欢迎大家来到dori meet、20UP virtualr啊，那么今天这场分享呢，我非常高兴能够给大家一起来了解我们如何让数据湖具备实施分析的能力，并最终借助阿PA Doris共同打造下一代的实施湖桑架构。所以说我们本次的分享主题是极速入湖，极刻分析，那么基于阿paddoris构建实数据库架构的现代化演进。OK, 那么首先先简单做一下自我介绍，那我叫陈明宇，那么目前是阿巴奇Doris的p MC chair, 那么同时也是贝伦科技的技术副总裁，那么我个人呢，已经在分行数据库，尤其扎贝多斯这个项目上工作了将近十多年的时间，那么现在呢，我主要关注的是如何在这种开放的湖汤生态中实现真正的实时数据分析的能力。OK, 那么我们开始我们今天的主题啊，那么首先我想先从一些背景开始讲起，那么我们先来看看湖仓，也就是Li costs这个概念是怎么来的，那么为什么业界需要互仓这样的架构，那么以及有哪些项目在这个领域中备受关注，那么同时呢，我也会提到在这个方向上以及仍然存在的一些问题和局限，那么尤其是在这种实时数据分析上，我们在这个湖仓的数据的分析的这个能力上的一些问题和局限，那么同时这样能够能够让我们更加清楚的去理解今天我们为什么要解，呃，今天我们要解决挑战究竟是什么，以及我们为什么要解决这样的挑战。

OK, 那么首先我们来先聊一下这个lay cos这个概念啊，那么首先lay cos这个概念，或者说胡桑一体这个概念，其实现在已经不算一个很新的概念了，那么data breaks在这个呃，大概五六年前就提到了这个概念，那么从本质上讲呢，那么Li costs的出现是因为企业对这种大规模的数据分析的需求的不断的增长，那么比如说一开始那我很多的企业还是依靠于这种高性能数据库来做这种实时数据分析，那么后来随着这种低成本的可扩展性的这种需求越来越强，那么数据湖也就是data lake这个概念应运而生。那么胡超的核心的思想呢，也就是lake啊data lake和lake cos合在一起，就是想把两者的优势去结合在一起，那么既要有数据库的这种灵活性，那么也需要有数据库这种高性能，那么具体来说呢，他希望同时具备以下两方面的一个能力，那么首先第一方面是拥有这个数据湖的这种低成本的存储，那包括弹性的扩展呢，开放性以及统一的这种数据存储能力。那么其次呢，也需要具备包括数据库系统这种高性能的这种数据分析能力，包括这个对事物的支持能力，以及这种比如说数据的呃呃，高质量一致性的这样的一个呃，数据的管理能力，以及统一的数据分析能力。那么所以说简单来说，那么企业真正需要的是能够在这种数据湖上的数据进行实质的分析，那么它既不提升性能，那么也不影响数据的新鲜库，那么包括数据的一致性问题等等，那么同时更不需要花费这种这种高昂的这种成本。

OK, 那么所以说这个湖仓的这种核心目标，那么其实就是拟合这种数据湖和数据库之间的这种鸿沟，那正如我刚才提到的那么数据和数据库，它其实从一开始它的设计目标就是完全不同的，它是为不同不同的场景去设计的。

那么在这个湖仓概念出来之前呢，企业往往去呃需要面临一个两难的选择，那么要么去选择这种数据湖data到lake这样的一个呃生态，那么获得这种更灵活的，更低成本的统一的数据存储和处理能力，但是会牺牲一定的性能，包括数据的一致性，数据的质量等等，那么要么你就选择这种数据库来追求更高的这种分析性能，更好的数据质量，然后更呃更一致的这种这种数据视图，那么但需要放弃这种灵活性，那并可能会去承担这种更高的这种成本。那么所以说过去的几年，那么很多的技术项目都在努力的去缩小这两者之间的差距，也就是数据数据库之间的这种GAP。那么希望呃，找到一种既能保留数据库的这种灵活性，那么又能拥有这种数据库性能这样的一个解决方案。OK, 那么在这些项目中呢，那么以iceberg为代表这种湖仓演进的，呃，以iceberg为代表的这种项目呢，是这种湖仓眼镜的一些呃典型代表，那么我们来先来说这种开放表格式啊，那么说严格来讲，包括iceberg、派蒙、whodi dota lake这样的一些开放表格式，它本质上呃，并不能称为一个完整的所谓的湖仓一体系统，或者说湖仓的一个生态。

它本质上只是一个表格式，或者叫做open table format, 那么但是经过这多年的发展呢，那么其中我们可以看到包括iceberg这样的系统其实已经脱颖而出，成为事实上这种数据弧的这种表格式的标准。那么首先我们来看一下为什么在整个这个互相一体架构中，这个开放表格是如此重要的，那么其实包括我们刚才提到包括iceberg delt lake啊，国内的阿patch p woody这样的一些项目，那么其实核心都在解决一个问题，那就是如何在数据湖中去有效的管理数据文件。那么而这正是支撑这种数据分析的这种最基础的能力，所以说像这种呃SG这种开放表格式会在这种故当一体的架构中脱颖而出，成为这种数据存储的机制。那么们可以看到回到这种早期的函度或者hive的时代，那么有我们有海量的文件都存储在我们的HDS上，或者说对象存储上，那么当当时并没有任何有效的这种文件管理机制，比如说我们没有版本的控制啊，没有模式的管理，比如说s givenn的管理，也没有任何的事物的保证，比如说a cid保证，可以看到我们在HAVEVE4的时候才出现了这种a cid的事务性保证。

那么所以说在这种哈卡顿的时代，虽然可以用很低的成本去存储这种大量的数据，但由于这种数据质量的这种管理困难，效率低下，那么所以说我们的高性能分析几乎无从谈起。那么所以说以S为代表这类弧表格式的出现，那么就是在这一层引入了一个统一的表级的语原数据的管理层，那么它让我们可以在这种数据库中进行包括事物操作，包括模式演进，比如说scheme evolution partition evolution, 包括我们的管理版呃，版本管理等等这些能力，并且借入因为我们存储的这种呃呃文件中的这种源啊原数据信息等等，所以可以借助比如说分区裁剪位自下推索引等等机制来实现这种高效的数据管理与查询。那么所以说也正是因为有了这样的能力，那么胡桑也就是lay cos的愿景才真正的变得可以实现，所以说这就为什么我们的开放表格是在整个的胡塞生态中显得尤为重要。

OK, 那我们来接下来看一下啊，基于像I的这样的图表格式去构建这种实时查询的时候，其实仍然存在一些挑战。那么首先我们先明确一点，当我们去说这种实时查询或者说real time query的时候，其中我们通常是指一种高并发低延迟的场景，那比如说我们同时要处理呃，数百甚至上千的请求，那么平时我们的响应时间可能在秒级甚至这种毫秒级。那么这通常来说可以看到这是一个数据库非常擅长的一个场景，那么但是在这个数据湖上，就是我们直接去拿数据库去查询这种数据上的数据，去提供这种实时分析的时候，其实会面临几个主要的难题，那么首先第1点是还是原数据管理，那么虽然说像XBG这样的开放表格式确实提供了一些高效的这种文件管理能力，但它其实只是定义了我们如何去管理文件，但它并没有呃具体的去做这种文件管理的实现，那么所以说随着这种比如说数据量的增长，或者说写入频率的不断增加，那么问题就会出现了，那比如说我的manifest的文件，我们的这个这个文件列表的这个原数据文件的暴涨。

我们的版本文件的堆积，包括很多小文件问题，Small far的问题，那么这些问题都会随着时间的推移来逐渐去拖慢我们的这个数据分析性能，那么所以这是第一点的第一个挑战就是我们的原数据管理的问题，那么第二点呢，就是我们的IO的挑战，那么通常来说这种弧表格式通常来说是存储在我们的一些共享存储系统上啊，那最常见的时候，比如说我们的对象存储我们的SD Fi等等。而与许多这种数据库使用这种本地磁盘相比，我们可以看到在这种远端存储或者对象存储上，它的这个IPS，它的延迟，它的随机访问的性能上都要低很多。那么从而这个在硬件这个。这个能力上就根本上就限制了这种实时查询，我们刚才说的高并发这种低延迟这样的一个需求的这样一个能力，所以说第二点是我们如何要解决这种IO的挑战，那么第三点就是查询引擎的本身，那刚才我们说过像这种I这种股表格式本身呢，它只是定义了表格式和原数据管理的方式，但它没有做具体的实现，那么所以说查询引擎的计算性能其实是直接决定了这种弧表格式的这种呃呃，不管是管理的呃效率，还是说查询速度，还是说可过性等等，都是完全取决于我们的查询引擎，或者说数据处理引擎本身的这种计算能力的。

那么所以说呃，我们第三点就是我们的查询引擎，或者说计算引擎本身的能力，也是我们在这种湖上数据去提供这种实时分析的一个呃重要挑战之一。那么所以接下来呢，我会介绍这个阿帕Doris，那么是呃并逐步向大家展示那么Doris是如何呃应对并解决上述这三点挑战的。OK, 那么来接下来我们来看一下为什么我们去选择阿BA Doris作为我们一个呃胡桑查询引擎的一个呃呃非常好的一个选择之一。OK, 那么首先在这个介绍这个阿贝do瑞斯的这个胡桑查询能力之前，我还是要简单介绍一下阿巴斯do斯这个项目，那么Doris本身呢，它是定位成一款高性能的分析型的数据库系统，也就database，那么所以说它拥有自己的一个存储格式和计算引擎，那么它提供了非常多的这种数据设计方式，能够非常方便的像很多主流的数据源，比如说你的湖上的数据啊，你的数据库中的数据，TB数据库能数据你的流平台数据，然后数据导入，并将这些数据存储在到系种，并在提上提供这种高性能实时分析。

那么当时就同时呢，也兼容这种MYCYQ结议，支持这种标准的I think的这个NSI的这个CQ语法，所以说对于熟悉SQL的开发者来说，它的使用是非常友好的，非常容易上手。那么但是今天呢，我们刚才说到，我们主要强调的是这种湖上数据的查询，所以说今天我想重点强调Doris的另一项重要能力，就它可以作为一个统一的查品性去直接的去分析我们的糊账数据，那么也就是说到时候可以直接查询这种外部的，比如说IG表，或者派蒙这样的一个弧表的数据。那么也可以把这些呼表数据和自身内部的数据进行一个关联查询，然后包括你可以呃去查询S3上的文件，然后去查询这些databaser文件，然后通过一个C口进行这种join的query。啊，并且就是也就是说包括支持支持这种跨数据源的任意的这种连接查询，那么所以说接下来我会重点讲解Doris是如何在这种图表之上，也就data lake啊，Data lake啊table之上提供这种实时查询服务，那么以及这种能力是如何帮现实呃帮助实线这种啊lake house这样湖仓一体的这样的一个架构。

OK, 那么首先我们来看一下基于Doris的构建，这种湖仓架构长什么样？那么Doris与数据湖的生态其实是深度集成的，那么在这张PPT的这个右侧，我们可以看到这是一个以Doris为核心的呃核心分析引擎的这样一个呃湖仓一体架构的一个示意图。那么所以可以看到从整体上来看，那么这个架构分为几个层次，那么首先最底层是我们的共享存储上，也就是刚才我们说的这种远端存储，包括呃，我们的对象存储或者RDFS上，那么在其上面呢，是我们的开放格式层，那么其中这开放格式中就包括两部分，一部分我们的是开放文件格式，比如说包括把K的or RC这样的一个开放文件格式，那么以及在提上之上封装的包括iceberg p蒙这样的开放表格式，所以说这是一个开放格式层，那么旁边呢，是我们的这个啊开allo服务层，那比如说我们传统的这howmas store, 或者说这个商用的这种啊，Awslue, 或者说开源的，比如说这个Unity grabinno啊，Applaris这样的一个呃，统一的数据服务，然后来去用于一种统一的这种原数据管理。

那么就最顶层的就是我们导所在啊，就是这种查询引擎，怎么进行统一的这种数据的处理和查询分析。那么所以说这样的架构可以可以可以支撑非常呃可以支撑多个这种重要的应用场景，那么比如说你可以在这样架构上去提供这种大规模湖上历史数据的这种呃实时呃实时处理查询，我们叫实时仪表盘，包括你可以对这种呃批处理和流处理，比如说我们派萌可能会适合一些呃呃批处理和流呃呃批批存处和留存组这种统一，所以说你可以在其上做这种批处理和流处这种统一分析。那包括你无需一条L去做这个数据库的加速，那么也就是说你不需要在在数据处理分析之前，把这个数据先从你的数据源，比如说你的故障数据复制到DOS的内置存储中进行分析，那么你省略了这个ETL的步骤，可以对这种类似于这种zero e TL的这种数据处理和这个这个数据库加速能力，那其次刚才我们说过的，我们支持这种呃跨多数源这种联合查询能力。

那么所以说现在呢，在这种这种架构下，我们回到之前提到的这种弧表的实时查询的挑战，来看一下Doris是如何逐渐的去解决这些，呃，解决在这种弧上查询的这种实时分析能力的。OK, 那么首先我们刚才说到第一点挑战就是我们的这个IO挑战，那么首先这个对象存储，那么它可以提供啊，非常高的存储，这是我们所所知道，比如说我们在AW，呃，AWS Switch上可以有一个非常高的一个呃，吞吐的一个访问，那么这对于这种大规模的这种顺序读取非常有利，比如说你可以从对账存储储上去，大快速去拉取非常多的这种呃，大量这种文件，那么但是对于涉及到这种大量的这种随机访问的这种分析型工作负杂来说，那么对象存储它的IPS和延迟往往是无法满足的，那么所以说为了解决这个问题，那么do瑞斯其实实施了两大类的这种IO优化。那么其次第一点是I，呃，这个优化IO的这个访问模式，所以说我们为了充分利用这种对象存储的这种高吞吐的特性，但是DIPS这种特性，所以DOS会在这个查询的时候会自动检测相邻的一些L请求，然后并且把这种呃，这个相邻的这种小请求合并成一个大请求，那么所以说这样可以看到可以显著减少这种LPS，并这个这个提升这种有效吞吐。那么此外都是斯还提供这种啊预取线程，比如说当我们的这个CPU正在处理当前批次的这个数据的时候，我们的预取线程会提前读取下一批数据，来充分利用这种可用的带宽，那么首先这些优化呢，都显著的减少这种IO的请求速度，并且大幅的提升这种吞吐，呃吞吐量，所以说非常的去非常适合我们的，呃，读取这种存储在对象存储上的这样的一个数据。

那么第二点的IO优化呢，是利用了我们本地缓存去实现这种低延迟，那么可以看到在第一步中，我们时间呃优化这种IO访问模式去提升这种吞吐量，其实还不足以解决这种查询延迟的问题，它只是只是解决这种吞吐的问题。那么所我们可以看到我们高速的本地磁盘和这个内存缓存，那么在在这个查询延迟方面就变得这个非常关键了，所以说Doris还提供了这种呃这个多级的缓存能力，包括我们的原数据的缓存，包括我们的数据文件的缓存，甚至包括我们的查询结果的缓存，那么可以帮助用户对种呃呃高效的应对这种热点数据的这种重复访问，比如说我们在一些这个报表系统中，我们很多大量的用户去并发的去重复访问同一份儿数据的时候，我们可以通过这些缓存提供一个非常低延迟的这种查询响应，并且能够提供这种高分发的查询，这个这个查询服务。

那么此外都是对于这种iceberg，或者派这种原数据访问本身也进行很多深度的优化，比如说包括我们去做这个分区裁剪，去做这种manifest的文件的缓存同时等等，那也大幅的提升这种五表的这种元数据的访问效率，OK, 那么这是第一个挑战，也就是IO性能方面的挑战。OK, 那么第二方面是数据扫描和这个调度任务，那我们刚才看到我们在我们当前重点的一个讨论的的场景是说我们的real time query, 也就是实时分析场景，那么在这个场景中呢，我们通常是指的是一些在线服务，那么我们都知道这种在线服务通常是对这种查询延迟的要求是非常高的，或者说它是对可预测的，他可能不要求你的查询延迟是必须是比如说呃，50ms甚至更低的这个，比如10ms的级别，但他需要比如说你在这个P99分位有一个非常稳定的可预测的这种P99分位的查询延迟。

但是我们可以看到，在这种访问弧表的时候，虽然说我们很有很多的catch来去尽量避免这种网络IO，但其实还是有很大的一部分的这个请求还是需要直接通过网络IO的，但是网络IO通常难难以预测，比如说你通过网络抖动啊等等一些问题都会导致你的一次网络IO可能呃瞬间跳到这个啊百毫秒级别，甚至这个更高的这种延迟。所以说为了解决这个问题呢，那么DOS其实引入了这种基于优先级的这种任务调度框架，那么这个框架呢，尤其是适合在这种混合工的负载下，它是非常有效的，那比如说我们在这种混合查询场景下，我们同时存在这种大查询和这种小查询的时候，那么我们可以防止这种单个大查询去占用了所有线程，然后从而导致小查询被饿死，那么这个机制呢，这个确保了这种查询延迟，它是保持这种可预测性的，因为我们。通过这种优信息调度队也可以去优先的让一些小查询先执行，那么这样的话，我们呃可能无法保证每个小查询都会非常快的返呃以最快的速度返回，但是可以保证，比如说我们P95或者P99分位有一个非常可预期的这样的一个呃这个这个呃查询延迟的这样的一个性能。

OK, 那么其次呢，在这个执行层方面，那么到时候他应用了一系列的这种啊运行时的优化，那比如说我们动态分析裁剪，那我们可以在这种呃，不光是我们在这个查询规划的时候，可以静态的通过元数去进行分区裁剪之外，那我们可以在运行的时候，可以动态的去生成这种分区列上的位词，那么从而去跳过呃，在运行的时候啊，在查询呃执行的过程中去跳过这种不必要的分区。嗯，这种是这个动态分析裁剪，那么其次这种top n的这种场景优化，比如说我们order by某一列去取它的这个，比如说前10的这种结果的时候，我们可以通过这种两阶段的访问策略，比如说我们优先读取这种排序列，然后进行排序以后，那我们只定位到这个，呃，排序最高的前10行的数据，然后拿行号去读取其他的列，那么这样来可以尽可能去避免这种读取不必要的列来减少IO。

那么所以说可以看到这些技术，它最终目标都是减少不必要的IO来提升整体查询效率，咱们同时保证这个延迟在一个可控范围，那么这是我们第二方面就是数据扫描和任务调度方面的一些优化。OK, 那么第三方面呢，就是针对我们的开放文件格式本身，那么DOS提供的这种原生的这种帕读理器，我们完全重新实现了这种呃，基于C加加的帕ER reader, 并且支持包括这种向量化存储维次下推、延迟化等等这样一些能力，那么在此基础之上呢，那么DOS就刚才说过，我们对这种文件格式引进了非常多的专属优化，我们这举两个例子，比如说我们的with下推，可以利用这个帕馈的这种行组的索引group index, 我们的lo filter index, 以及就是在帕呃帕馈的这个新版本中引入的这种page置index来去，呃通过这种位置下推能力裁剪不必要的这种啊列读取，或者说配置呃，Page data, 呃，Data page的这种读取。来去减少我们这种不必要的IO，是通过微次下推的能力，第2点我们刚才说延迟雾化，那么其实刚才我们说的这个套喷的这个优化，其实也是延迟雾化的一种，那在这种高选择性条件下的时候，我们可以先读取这种呃条件里，那么通过条件类的过滤以后，然后定位到少量的我们需要读取的行，然后再读取剩余的列，所以说在这种高选高选择性条件的这种条询下减少IO，那么所以说这些优化组合在一起呢，可以显著提升这种在开放文件格式啊，这种腾讯效率。

那么总的来说呢，都是通过在IO那调度，还有文件格式方面的一系列优化，来去显著提升我们访问，呃，这个这个湖上数据的这种延迟，来为实时数据分析提供这种坚实的基础。OK, 那么接下来呢，我我会我呃，这个我想介绍一下一个非常重要的功能，就是物化出度这个能力，那么我们可以把这个物化出度，也就是某2B，我成为这种连接数据和数据库之间的桥梁。那么呃，物化储能本质上是提供一种将这种数据计算和持久化存储去结合起来这种方式，从而减少这种运行时的这种计算量，那么尤其对于这种复杂的分级查询来说是尤其有用的，可以显著的提供这种查询性能。

那么从右侧这个这个这个示意图可以看到啊，这个无化石的就像一个桥梁，可以将说这个后据呃湖中的这个数据与数据库的产品引擎去连接起来。那么那么在这个物化值的方面呢？那么其实其与其他这种查询擎相比，那么DOS一个主要的优势可以在于它是拥有自身高效的这种内部的存储格式，所以说虽然可以看到很多的这种产品引擎，它都支持这种雾化输储能力，但是Doris它可以用自己这种高效的内部存储格式来去做作为这个物化输入的这个存储格式。那么基于这种格式来构建的优化尺图，那么会比这种基于比如说开放开放文件格式有帕的or RC等格式可以提供更优的这要的一个访问性能，那进一步提升这个查询效率，那比如在查询加速方面，那么DOS，那么同时在这个查询加速方面，那么DOS的查询优化器还支持这种透明的改写，那么这意味着用户其实无需修改原始的C口，他这是不需要感应到你下面这个有这个物化制度构建。那么那么优化器会自动的识别这种啊，自动的匹配啊，这个这个C口和这个无化视图啊，并加以利用，那么它甚至可以在同一个C口中，那么其中的一部分的数据是来源于这个已经呃预计算好的这个物化制度的数据，还有一部分数据是实时计算，从原始数据中进行实时计算数据啊，把这两部分数据相结合进行返回，那么所以说可以让数据管理员能够为用户提供这种无感的这种查询加速。

那么那么同时我们也知道我们的物化视图是有一个这个刷新的这个能力的，那么在这个数据的新鲜度方面呢，到时也支持从这种秒呃分钟级到秒级这种物化这视图的这种这个这个刷新的调度，并且支持这种分区级别的这种刷新，那么可以帮助。呃，帮助将这个物化视图的数据刷新的这个开销降到这个这个一个合适的一个一个程度，那么这是物化视图的一个介绍。OK, 那么在这种真实的用户场景中，我们可以看到啊，一个精心设计的这个物化输度能够带来非常大的一个性能提升，那么这个性能提升其实也是在这个意料之中的，因为如果这种我们查询命中的这个无法输入数据，它几乎是不需要任何运行式计算的，可以直接获取到这个最终的结果，所以这张无法输图非常适合这种在线的这种实时业务的工作符。那么同时刚才说过，我们从这个呃数据的正确性和新鲜度的角度来说，那么do时斯也提供的灵活的策略来控制这种无化制度使用，比如说你可以去设置这个呃数据新鲜度的一个可容忍的一个呃呃延迟，比如说一个10分钟的一个刷新延迟，那么来用户来根据实际的需求，那么在这个数据的新鲜度，也就无化视图数据上的新鲜度和查询性能，还有我们的物化视图构建的成本之间去做出一个平衡。

那么所以说可以看到物化视图是我们在这种图上数据去做实时分析场景下一个非常重要的一个桥梁和一个功能。OK, 那么好到这里，那么我们对这个Doris的在这个弧表上的一个实时查询的介绍呢就告一段落了，那么我们不仅介绍了do瑞作为这个数据库的核心能力，包括数据的是摄取、更新和查询性能以外，那么重点介绍了那么针对湖表所做的这个专题优化，包括IO的调度，任务调度，文件读取以及物化制度等等。

那么接下来我要简要分享一下Doris当前以及未来在这个数据湖生态中的贡献和一些整合的计划。OK, 那么这里是我们关于这个阿帕Doris去支持iceberg和派蒙这两类这个开放表格式的一个现状和规划的一个概览，那么这两种格式也是Doris目前主要关注的两种，这个开放的这个服务格式，互表格式，那么首先对于s per格式我们已经提供了比较完善的这种支持，包括对这种啊。呃，比如说各种catalog集成，比如说Lu catalog catalog等等，那包括对这个呃Spark v1和VR这种表格式的这种基础查询能力，那包括我们支持这种啊open only的这种insert，什么time travel啊啊steam change啊，然后包括branch tag啊这种啊分支和标签的这种管理与查询功能等等。那么在未来呢，我们还在推进对这种啊呃V3表格式的支持，那么以及包括这种呃va data typeb, 以及包括呃更多的数据写入的这种更新和删除的这种支持等等。那对于派蒙呢，那么当前支持功能也是包括比如说啊，刚才说过的我们catalog的集成啊，包括我们的这个阿里云的这个DLF的这个rest catalog的集成等等，我们现在都已经支持了，包括支持对这种deliciousion vector的这种技术查询能力，包括我们的temp travel, 我们的呃，Bach incquimental query等等这样一些能力，那么同时也支持了这个排的这个啊brancher t的这样读取能力，那么在未来规划中呢，我们也在逐步的去啊，引入比如说对这个派蒙的这个表的写入的支持，以及这种DDL，比如说我们建表删表，建股商库的支持等等，那么寄希望于用户能够直接通过Doris，然后去很好的去啊，不仅仅是查询我们的互商数据，也能很好的去管理我们的互上数据。

那么所以说。啊，无论是现在这种可用的功能，还是即将上线的这种新增性导时，都能确保你能够充分利用比如说我们的IP的能力来去提供这种无上数据的实时产品分析。那么有了这些能力呢，那么用户也可以在这个弧表上进行这种实时分析，包括这种混合的工作负载，那么同时他也可以通过利用这种DOS，刚才说我们比如说X的这种写入能力，在这种股表上去提供这种轻量级的数据处理能力等等。

OK, 那么接下来我想通过两个真实的用户案例来向大家展示Doris是如何提供这种数据库的分析能力的。OK, 那么第一家案例呢，是来自于这个天翼云，那么它是一家领先的这种云服务厂商，那么那么我们来看看他是如何利用阿PA Doris和iceberg去构建这种现代化的统一的服仓架构的。那么在这种呃引入这个dorisbg之前呢，那么它的数据平台其实是非常分散的，那么比如说我们的数据库和数据仓库使用了多个系统，那么导致比如说查询缓慢，我们的数据需要重复存储，还需要投入大量人力来维呃维呃这个这个维护这种系统等等，那么于是他决定他们决定这种简化这样的一个啊整个的架构，比如说呃，那么那么最终呢，他们使用了这个Doris来提供这种实时的高性能的分析，那么使用gasberg提供这种开放且可靠且统一的这种呃数据存储，那么通过这样的一个组合呢，他们构建了一下一个统一的架构，那比如说do瑞S可以直接查询s word的表，那包括支持刚才说过的五八视图能力，然后支持这种热点数据的缓存能力等等，那么所有这些都可以让这个数据变得更快更高效，那么可以看到他们当前呢，已经在这个呃构建了50个集群，将近3000多个节点上，然后同时支撑了这个20多个这样的一个呃业务线，然后管理的整个数据量超过这个15PB，那么同时呢，查询性能也大幅的提升，那么可以看到在某些场景下可以达到这个8000~1万5的这个QPS，那么它的。

存储成本，像比如说在这个日志场景下，相对于这种旧的这种ELK的这个这个系统下降了于80%，所以说简而言之呢，这么像这个项目展示了Doris与SBG的结合，如何真正的去支持这种大规模的实时分析，那不仅有更好的性能，更低的成本，并且数据架构也变得更加简单了，OK, 那这是我们的第一个案例。呃，那么第二个案例呢，来自于小米，那么这也是一家这个全球领先的这种科技公司，那么它需要呃，他们需要是一套能够支撑其全球规模，就global scale的这样的一个数据架构，那为包括他们的小米的智能手机，物联网设备，以及这个呃，这个呃，智能汽车设备，然后提供这种分析能力。

那么他这么之前系统同样也是很分散的，比如他们使用了包括prestal read Spark Doris等等多个系统，呃，来来去做这个这个分析系统，那么同呃，那并且呃去去引入了包括iceberg加派蒙，然后去。去做数据存储，那么这两个互表格式上的这个数据存储也也相对来说会有一些重复，那么所以说这种复杂性的也带来这种高运维成本，并且查询的性能也不是很很一致，也不太稳定，那么为了解决这个问题呢，他们也构建了基于Doris和派蒙的这样的一个统一的护仓，那么首先Doris也是提供这种实时高性能分析，那么配合其自由存储，就是我们的这个这个内部的格式，还有这种物化视图的能力，来提供这种这种呃呃高并发低延迟，这种呃查询响应，那么同时通过派蒙呢，来提供这种低成本灵活的这种数据库存储。那么两者结合，那么实现这种无缝的整合，首先查询更快了，数据治理也更简单了，那么我们的基础设施的成本也更低了，那最终效果也是非常明显了，那么他们整个整体的这个查询性能提高了6倍，那各类的这个工工作负载的这个数据访问也实现了统一，那同时我们可以看到这个架构也更加简单了，并且扩展性更强了，能够这个让团队能够在这个全球范围内实现这种实时的这种洞察的能力。

OK, 那么以上就是我想为大家分享的如何基于Doris去构建中统一实时数据湖仓架构的这样的一个呃，技术方案和我们这个遇到一些挑战以及解决方案等等。OK, 那么在结束之前呢，我们还想简单的介绍一下阿拜Doris的这个开源社区。对，那么DOS也是一个非常活跃的R项目啊，那么拥有一个充满活力的一个社区，那么目前已经拥有了包括700多名的贡献者，我们的k top上也超过了14000个的star，我们企业用户超过了5000家，那我们也非常恶劣的欢迎每一位感兴趣的同学来参与呃和探索我们的这个阿PA的社区，我们社区也提供非常丰富的包括使用案例，我们的学习资源，我们的贡献指南等等，那么同时也还有多种渠道可以和社区进行交流，那么都在这个PPT上了，那么我们可以去获取支持或者来分享你的想法。

OK, 那么以上就是今天的分享呢，非常感谢大家的收，呃，大家的这个收看。