AnalyticDB PostgreSQL版：Data+AI 时代的企业级数据仓库
内容介绍：
一、AnalyticDB PostgreSQL产品架构
二、核心技术
三、客户案例
四、功能发布
分享的内容主要包含四部分，首先介绍AnalyticDB PostgreSQL版整体的一个产品架构大图；然后介绍Data+AI的核心技术；接下来是对应的客户案例；最后，分享一下我们近期跟data AI相关的一个功能发布。
一、AnalyticDB PostgreSQL产品架构
第一部分是产品的整体架构大图，左右两侧分别是Data+AI的上下游生态，中间是ADPB的一个整体的核心架构。从底往上看，底层是存储，从数据的类型来讲，既有数据分析的数据存储也有AIML相关的特征存储，还有模型本身的存储。从数据的格式来区分，既有结构化的存储，又有半结构化，像JSON这样的格式，另外还有像图片文档这样的非结构化的存储。然后上面分别从Data Warehouse Workload以及Vector Search Workload还有RAG和AI的场景来看一下整体的核心组件。
对于Data Warehouse Workload数据分析场景来讲，在PGA已有的Hip Table，还有一行一行执行的火山模型的执行引擎以及优化器之上自研面向OLAP场景的行列混存的实时引擎Beam以及向量化执行引擎Laser，同时引入面向复杂分析场景的优化器Orca，在这些计算存储优化器之上又构建了增量实时物化视图。基于这些核心的能力，提供高性能实时的ELT和Analytical Query的负载。
其次向量检索方面，向量检索的底层基于HNSW的图索引，倒排索引和Btree索引来提供向量标量的融合查询以及RAG场景向量跟全文的双路召回，还有像稠密向量跟稀疏向量的融合检索。
在RAG这个场景除了基于向量检索之外，还对像业务开发当中常用的通用的逻辑做了分装，比如说文档的切片以及切片之后的向量的特征提取，还有召回之后的根据业务需求的一个精排。
对于ENDB的AIML场景，本身是基于PG生态的，所以也集成了这样开源的一个PG项目叫PostgresML。这样直接在数据库内部把数据里面当成特征存储，然后直接在里面可以做这个模型的训练、微调以及推理。
然后再看左边，无论是数据分析的负载，还是AIML的负载，就是特征的数据，都需要有数据员能够进来，主要是包含实时的流式数据跟历史的批量数据加载。同时有一系列各种场景的数据同步工具。然后右边主要是RAG跟AI的一个上下游生态，阿里云的大模型服务平台百炼本身就集成支持了ADPG作为向量知识库，同时像通义灵码、点金也都把ADP作为底层的向量检索的知识库。对外的话像大源模型的Agent Framework比较流行，像Dify Liamaindex，还有LangChain的话内部也都对ADPG做了适配，所以大家在开发业务应用的时候，直接用Framework就很容易选择ADPG作为这样一个底层RAG的一个组件。无论是RAG Service还是Interbase AIML都需要跟Modescope模型服务去做交互。
二、核心技术
第二部分是基于刚刚那个架构，分别讲一下数据分析和RAG场景的核心技术。
1.数据分析的核心技术
首先看一下数据分析场景。定位是高性能和实时数仓的话，怎么体现这个高性能和实时数仓呢？这张图从左往右看，本质上分为三个环节，第一步数据能够进来，第二部分就是在数仓里面去做ELT，然后第三块是去做查询分析，本身这三个环节，大家如果做数据分析已经非常熟悉了，那怎么样让这三个环节都做到高性能跟实时是这个技术的关键。
首先看写入部分。作为OLAP，批量加载本身是都支持的一个基本能力，那难点的挑战在于哪里呢？在于实时的写入更新和删除，为此自研了行列混存的实时引擎Beam，把它的架构叫做Heap的Delta加这样一个Pax行列混存格式的Primary，然后用这个Heap表直接接入实时写入更新删除，同时行列混存的话又能够提供OLAP场景需要的高效扫描过滤。通过这个组件跟2级索引，就是内置PG的索引都适配好了，又能够很好的支持点查跟范围查这种Serving常见的一个负载。
然后再看查询，关于右边的查询，除了存储刚刚讲的，通过压缩编码列裁剪聚簇排序，提供高效扫描过滤之外，向量化的执行引擎和对复杂查询的优化器也是必不可少的。当今向量化执行引擎其实已经是数据分析产品很基础的或者必备的能力，核心其实就是各种像Soat、Scan Join这种算子的向量化，以及在分布式架构下面执行的并行化。那从工程上角度来讲，怎么做好这些事情呢？尤其是向量化。本质上来说，就是每一个算子的向量化，我们充分根据算子的实现逻辑去利用好CPU的指令流水线执行，以及Lperfess、SIM指令的特性，能够让每个算子实现以最少的资源去发挥最大的性能，这是执行引擎。
不同于存储跟执行我们是面向分析场景完全自研的，优化器方面选择引入了Orca，并且在Orca上做查询优化特性的增强。比如通过RuntimeFiltal能够做dynamic join，Filtal然后尽可能的在数据做网络shafer之前就过滤掉大部分数据，以及通过存储层的字典编码直接加速执行成像这个scantfiltal以及aggregation这样的算子，本质上来讲利用数字的计算性能要远大于字符串的特性。
基于计算存储优化器，来看最复杂或者最耗时的部分。传统讲ELT的时候，一般都是讲的虚线部分，做T+1的一个批量调度处理，典型的负载就是insert into select，本身这种insert into selec性能就是由查询跟写入决定的，在这个基础之上，实现了上面深色的实时IMV叫实时增量播放视图，那这块跟T+1有什么不同呢？是根据数据进来驱动增量自动的做刷新的，这样做的好处是能够最大程度的利用好系统的硬件资源，让整体的计算量达到最小，并且对查询来说，因为大量的计算都已经前置掉了，所以查询本身也会比较快。所以结合传统的T+1的批量调度处理加刚刚讲的实时增量的物化视图，整体在仓内实现了流批一体的能力。当用户用IMV来构建ELT时，体感上会感觉这个里面内置了一个Flink的流式处理引擎。
2. RAG场景的核心技术
接下来讲述一站式RAG的核心技术。从去年开始，大模型以及对应的RAG的应用，带火了向量数据库，ADB-PG早在19年、20年的时候就已经做了向量检索这个功能，当时的场景还是图片搜索——图搜，然后结合结构化的条件过滤（标量过滤），分别是靠底层的这个HNSW+ Btree来支持，当然跟其他的向量检索符或者向量数据库不同的是什么呢？我们有比较强的优化器，可以对向量标量，根据这个标量的selectivity选择最优的执行计划来决定下面走哪些索引，走什么样的执行计划。本质上回到IE的场景，是把图片搜索变成了文本的搜索，然后文本更标量。文本的除了向量检索的话，业务通常也会结合全文检索做双路召回。所以整体上来说，底层的核心能力就是靠向量检索、全文检索以及标量过滤三种类型的索引，然后由优化器根据你的标量的过滤条件来决定模式前置过滤，后置过滤，还是说把过滤条件直接下推到索引里面来提供最高效的性能。本身因为是一个数据库，所以在这个数据类型方面无论使用Vector，Text，Array， Json这些都支持，每种数据类型都有相应的索引来支撑。为了让业务更容易使用RAG，针对常用的文档的切片、切片之后的向量特征提取以及召回之后的精排都做了一个通用逻辑的分装，通过ID Service以API或者SDK的方式直接提供给上层的应用来使用。如果业务要更灵活的使用，也可以直接通过SQL来跟数据库交互，在ID Service跟SQL之上的业务可以基于Agent Framework来使用。也可以直接用中国阿里云的百炼，当使用阿里云的百炼的时候，既可以选择直接指定一个ADB-PB数据库，这种模式下是一个专属的知识库，也可以选择内置，内置情况下它是一个APP的数据库，里面是多个住户共享的。
三、客户案例
第三部分是分别对应前面讲的数据分析跟RAGAI分享两个客户案例。
1.丝芙兰
它是用做数据分析的场景，基于高性能的实时分析真正做到了降本增效。
视频内容：在男性的美妆领域上面，大家现在比较火热的一个就是护法。基于Analytiv DB的这个用户洞察和建模上面，找到这些希望能够改善自己发质的男性人群，把护发产品分享给他们。
《以“数”之名 为“美”助力》——全球美妆零售领导者如何玩转云上数据库
我叫Rex Xu，是丝芙兰的Data Hub总监，负责整个丝芙兰数据中台的建设和设计。丝芙兰是全球最大的高端美妆零售商，从2005年进入中国市场，至今已在中国大陆100个城市开设了341家线下门店，同时它有自有的电商，也会依赖于天猫、京东等一线的电商平台来拓展线上业务。因为在中国整个零售行业包括美妆市场是一个高速发展的状况，如何通过技术赋能、数据赋能来更好地服务全域几千万的丝芙兰会员，实现精准实时的个性化推荐和会员运营，成为数字化转型中探索的一个核心。
挑战1：数据资源整合
我们面临的第一大的挑战是有非常多的线上和线下的数据和数据源，丝芙兰整个的数据平台需要接入4到50个各种各样的数据系统，（要面对）整个的数据中台的foundation，或者是数据的清洗和数据资产的沉淀。
挑战2：实时数据分析
无论是线下还是线上，商机都是转瞬即逝的，无论是业务还是用户，对于这种个性化的体验的要求越来越高，所以要实现接近于实时或者是real time的一个数据的接入和数据的处理分析。
挑战3：高性能 高安全 高稳定
同时在数据中台的建设过程中（要探索）如何能够达到一个高性能，安全同时又稳定的这样的一个中台，这也是为什么我们选择了阿里云云原生的数据库和数据产品体系。
在2021年，使用阿里云数据的产品数据体系来打造数据中台，来完成数据和模型AI上面一个赋能。首先会完成数据foundation的搭建，在数据应用上面，这几年完成了几个非常重要的服务层的搭建。首先是用户标签的搭建。
接下来看另外一个RAG场景的案例
2.RAG案例
主要是领跑汽车。基于ADPG的向量检索引擎的，然后通过向量检索、全文检索跟结构化的条件过滤，然后多模态一站式的召回能力大幅提升智能座舱的交互效率，以及知识检索的准确率和用户体验。
四、功能发布
1.高性能全文检索-pgsearch（09月公测）
最后是近期的重要功能发布。前面讲RAG场景全文检索其实在向量检索技术之上是很重要的能力，支持全文检索主要是通过pg本身自带的这个tsquery跟GIN的倒排索引。本身tsquery是基于TF-IDF算法的，以及底层的GIN索引。客户也反馈尤其在数据量大的时候，它的性能可能会不太符合预期，尤其是跟像专门做全文检索ES这样的系统比起来，为此也在这方面提供了高性能的全文检索，叫pgsearch，它的底层技术是什么样的呢？首先，引入了rust的这样一个开源项目tantivy来对标GIN索引，同时引入了BML算法，无论是在性能还是效果上都会更好。
右下角这张图是Tantivy就是Tec Hub官方给出的，相比其他倒排索引的项目给出的一个性能对比，拿它跟Lucene来看的话，整体在不同场景的话，有一个2~5倍的提升。然后去测基于Lucene构建的全文检索系统的话，无论是单个term还是多个term的场景，包括导入还是查询的话，大概都是提这样一个三倍的性能。同时也跟GIN索引做了一些对比。左下角这张图是测试的数据，对比下来在查询的时候有六倍的性能，导入也有三倍，当然如果用检索索引上面加上tsrank，那是数量级的提升。所以如果在用全文检索需要对性能有更高要求，不管现在用的什么系统都可以。
2.In-Database AI/ML（09月邀测）
另外重要的功能发布的话就是In-Database AI/ML。如果通过AI来驱动业务价值的落地，去做模型的一个训练和数据推理，本身是有一定门槛的。首先需要有特征存储，有模型的训练和推理平台，并且需要有业务系统去把特征存储里面的数据做加工，并且喂给平台里面做模型训练的推理，所以这里面是存在多个系统里面的交互。那在这部分本身同样基于pg生态，引入Postgrage ML这样项目，并且适配分布式架构，拥有分布式推理的能力。本身数据仓库就是说在特征存储这块本身就是能够胜任的，那我们就是基于这个数据窗口同时引入Postgrage ML，然后Postgrage ML的话，就像这张图上面一样，就是本身就集成了众多流行开源的算法库或者训练推理库。这样一来在ADPG里面就可以提供一站式的这样一个从特征数据的导入、标注、加工以及模型的训练都是通过SQL的。比如说一个典型的场景就是业务数据进来，然后做完特征加工标注之后直接select的pgml train就可以训练出一个模型，当然你可以在这个train里面指定对应的算法，指定对应的参数，然后步数，然后再有新的业务数据进来的话，无论是通过前面的实时增量物化视图做到实时还是T+1的这样一个数据加工去做批量推理，然后直接调这个pgml做predict就能够推理出相应的业务数据的结果。这里大家可能有个疑问，就是In-Database ML是不是可以说有了它就可以替代像阿里云PI这种Standalone的ML呢？那显然这两个也不是完全平替的关系，它的场景的话在这里我也列了一个对比，从简单敏捷性、功能灵活性、安全性、成本和规模上来对比。简单来讲总结来讲呢就是ADPG这种Database ML的话更适合的是典型业务场景的一个通用解决化的方案，它的分装程度比较高，对业务来说大大降低了使用AIML来驱动业务价值的门槛，同时整体的流程也比较简化。如果说今天我们可能业务这边本身我们就有一个庞大的专门做机器学习算法的一个工程师团队的话，它需要更大的灵活性或者说要更大的资源规模去训练大模型的话，像PI依然是更合适，前者的话分装程度高，上手门槛低，然后落地速度快。
光云科技X AnalyticDB构建下一代云原生企业级数仓
内容介绍
一、光云科技业务介绍
二、企业级数仓架构和应用
三、AI赋能业务的探索实践
一、光云科技业务介绍
1.业务概况
主要介绍对于ADB应用的使用。第一我们其实主要是做电商相关的。因为电商的应用场景也确实比较复杂，从09年开始做电商相关的SaaS然后涉及到各个品类，就是商品、订单、库存各个维度细节。
2.海量数据分析面临的挑战
对于ADB的使用主要两个部分，第一是传统的数据仓库，第二个板块是后面与AI相关的东西，传统式仓库最开始其实我们在我们应该是ADB For PG最早一批客户，因为在19年在做数据库以及这个数据仓库选型的时候，就选择了这个ADB For PG，然后呢也是从最早的四年级的版本到现在这个最新的架构，一直在跟着这个PG团队在做演进，我们面临的场景，第一自己做数据中台的介绍其实就在于数据越来越多，数据需要聚合的维度越来越多，可能商家会从会员商品库存全维度的计算，我们基于这样的场景也要去开发很多的报表和数据的产品，所以基于这个板块，可以看到会有经营的分析会有商品的运营的分析，可能会涉及到电商公司所有全维度的数据，我们的产品是偏中后台的，比方说ERP或者是OMS它的订单的整个的履约就他所有电商公司最核心的中后台的链条可能都在系统里面在跑，所以会面临很多很复杂的实时的计算，因为每一个公司对于自己数据经营的维度是不一样的，对自己的数据的理解也是不一样的，所以它会有很多复杂的配置。然后需要实时的计算，并且可能需要跨很长周期的查询，比方说我要查近两年的趋势的变化，同时在一些特定的节点，比方说月末它的并发也会比较高，所以从19年其实一直在解决这类问题，因为在真正有数据仓库之前都是拿数据库做预处理的比方，但是这个不够灵活，可能每天晚上给客户做好一些简单的加工，但是它要很灵活的查询的时候就完全不行了。
二、企业级数仓架构和应用
1.基于AnalyticDB的实时数仓架构
我们会面临多平台的数据，从不同的数据源里面去做写入，大家也有本身通过RDS的加上DTS的实时处理，然后再自己做一些MQ的写入，到我们的数据仓库，当然还有一个就是我们批处理是基于max computer的整个的核心离线数据仓库的处理，所以其实我们是一个两层的结构，有实时的部分也有离线的部分，然后往这个数仓，当然我们最终的查询端都是基于ADB For PG的处理，所以基于这个处理呢，我们用了这个平台之后可以做很多的复杂的不同业务域的聚合的分析，包括大数据量的都可以去做承载。
2.服务质量-故障资源弹性
从最早的跟着ADB For PG的演进，对于数仓的可用性的要求从业务的场景没有TP那么高，AP相对来说还是可以接受一定的故障，因为数据量的架构毕竟跟TP和业务的要求不一样。但是随着最新的ADB For PG的rand的这个结构，整个的双层的负载以及故障的处理，对于我们的可用性也会有进一步的提升。所以我们也是跟着PG一直在做演进，我们现在的集群也慢慢在往最新的架构上去迁移。
3.基于实时增量物化视图实现流批一体
刚刚前面提到实时物化视图，对于电商的场景也是非常友好的，因为在过去我们有两个选择，第一个要么自己基于flink搭建一套整个的架构，但是这个说实话也会面临人员的投入，会面临基础的建设，但是有了这个实时物化视图之后，对于一些非常复杂的产品，特别是一些大客户他对于一些结构，对于一些要求会比较特殊，那就可以用这样的特性。他们本来所有的全量数据在我们这里，我们通过对实时的类似于其实他就是解决了这个flink的一部分的能力，比方说他需要商品和库存，再加上他的会员，他的用户相关的信息需要做一系列复杂的计算之后生成一个结果，结果还要实时而且需要马上看到变化，因为他可能要拿这个数据去做业务的应用，对他这样的数据像过去我们可能就是用非常复杂可能这个成百行的这个SQL去一个非常复杂的查询去把它聚合出来，然后再给它做一个呈现，但是如果有了实时物化视图的能力，我们就可以提前做好内置的任务，然后实时的计算出来，达到这个流批一体的这个能力，其实最终还是要快速的响应它的前端的业务的需求。
4.资源隔离实现混合负载
资源的隔离其实也是一个新的特性，因为我们往数据仓库里面写入的会有DTS，对DTS的上游是业务库，但是业务库他的压力可能会有波峰波谷，比方说双十一的零点，那双十一的0点可能会有大量的订单的写入，他会对于很多的数据的处理，包括有些客户大，他可能就因为做上市你会涉及到租户，不同的租户的规模可能不一样，所以呢它对于如果整个DTS的管道它是一个大的通道的话，它本身就会消耗这个ADB很多的固定的资源，那有了这个资源的隔离之后呢，我们就可以对一部分的通道或者对一部分的租户做资源的控制，那这样的话他就可以相对来说不影响计算的资源，就可以达到这样的一个隔离和更精细化去控制的一个效果，所以这个也是一个新特性对我们的业务上的一个优化。
5.冷热数据分层存储
冷热分层存储主要就是前面说的商家的数据，他用我们的这个SaaS系统可能用一年，两年，四年，五年，甚至有七八年的，但是它的数据是一直留在我们这里的，我们肯定不能去做删除，我们可能最多只能做归档，那归档的话在原来传统的模式下，可能我们就是把数据导出来上传到OSS上去，然后去做手动的归档，但是有了这个冷热的分离之后呢，我们就可以用这个特性自动的去做一些冷热的隔离，这个一个是在成本上会有一些优化，第二个就是在运维上对于我们的运维会更加友好。
6.实时数据集成
然后实时的数据集，其实我目前来说主要就是在DTS这一块，然后这个新的特性这个stream server呢，我觉得后面整个的升级之后可能对我们应用方是没有感知的，但是它整体带来的效果就是可能它的写入速度同比会更快，因为我们很多的实时的数据的写入都是在每天往这个数据仓库里面在写。
三、AI赋能业务的探索实践
1.当前数据架构在AI时代下瓶颈
前面看的时候就是我们整个数仓的板块，因为我们一路见证了从这个PG的4.3一直到现在新的版本，刚才前面那几个都是当下对于我们做SaaS而言非常友好的几个特性，也是我们现在在做陆续的迁移，我们慢慢再把老集群也在往新的这个集群去做迁移。然后在AI这个板块的话，就是刚刚前面有个介绍，主要我们的场景呢是在RAG这一块，我们也会帮商家去构建它的私域的知识库去做电商场景的问答，刚才前面也有这个分享的嘉宾在介绍，他们是做企业的知识库，但是我们主要是围绕电商的场景，最直接就是大家在购物的时候去咨询这个客服，这个客服背后能力的支撑，就有可能是像我们这样的厂商在做这样的AI的智能客服然后整个的客服场景包括这个阿里云的百炼，我们也都在去做应用，因为在没有大模型之前，其实我们基于GoogleBeta的这套体系本来就在做AI的客服，但是这是上一代的技术的范式，我们称为传统的所谓的小模型，那现在大模型出来之后我们会针对前端不同的意图去做不同的路由，比方说一些在电商的场景，比方说我是卖食品的或者说卖医药的，我们对于一些要求非常严谨的意图是不能去所谓的泛化的，一定是百分之百要求精准的，所以我们作为不同的意图会做不同的路由。这个是基于我们有过去传统小模型，做了五六年大量的沉淀，所以我们基于这套体系在一部分的意图，我们就会去调动大模型的能力，因为他有更好的推理的能力，有更好的去学习内部知识再去做泛化的能力，所以这是大模型擅长的，所以我们在整个的板块里面对于大模型以及RAG的应用，在电商里面我们也是应用的非常的多。
2.企业级智能客服解决方案
这是我们整个的企业级的一些解决方案是我们对于不同的平台，我们的产品叫快麦小智，我们对于整个的电商公司内部的系统，包括它的这个ERP，也包括它的物流，包括它的这个OMS里面的商品数据去帮他做了很多的集成，集成到我们整个的这个平台上来，然后去支撑整个前端的电商平台的交互，这样就是让他的客服也可以通过系统集成以及大模型的能力去充分调动它背后的这些接口，因为在过往他更多是被动的，今天打开a软件，明天打开b软件去做不同的查询。
（1）智能导购
最直接的就是刚刚说的智能导购。一部分的场景会用大模型去做导购的能力，它不单单只是传统的基于问答，基于微调的或者叫基于传统机器学习的一些问答，比方说我们现在部分的场景，电商的场景，我会去问商品对比，就这个化妆品a款和b款它到底有什么差别？它们有什么成分？这些知识其实都是写在商家的内部的知识里面的，在商品详情页里面可能是没有的，我们就通过大模型去学习了它内部的知识之后，帮他去做商品的对比，去帮他去做商品的推荐，本身就能去分析这个意图，核心是意图识别的能力，再配合背后这个RAG的能力才能达到这个类似的效果，当然这个课题比较大，就今天我们说RAG真的要想在two B，要想在电商要求这么高的场景下去做好，确实里面还有很多很细节的活，所以这个也是我们在大模型出来之后，我们沉淀了一年,就一直在做，怎么真正的去把一个RAG做好，要达到电商咨询这个导购的准确性的效果。因为电商的场景是你宁愿不回，你不能乱回，电商的咨询它是带有资损的，就是消费的一个截图，你当时这么回答我的，你就必须这么给我承诺，所以会有大量行业化和和技术细节的一些调整。
（2）光云在智能客服领域的AI实践
然后是中间最重要的RAG的环节，基于ADBPG的AI的能力，因为我们原来是用其他的向量的数据库，但是现在因为有了整体的解决方案之后，就在陆续做一些迁移，整体的运维我们的组件，因为ADB For PG本身就他用了很多年也比较熟练，所以整个的就会慢慢往整个这一套的这个架构上去做牵引，所以这中间最核心的就是向量数据库的应用，所以我大概的分享就是这样的，我们在传统的数据仓库和AI板块都是对于APG有非常广泛的使用。
