ClickHouse在有赞的使用和优化原创

现场提问。呃，大家好，嗯。我先介绍一下有赞是一家什么样的公司，然后有赞是一家商商商家服务公司，然后它主要是致力于商家服务领域最被信任的引领者。然后持续做一个enjoy的组织，然后主要包括几块，SAS服务，Passs云服务，然后支付业务，然后做一下个人介绍，然后我网络上名字一般叫那个卡卡，然后大家可以叫我卡卡。然后我是，嗯，其实年纪比较大，我有十年以上的工作经验，然后嗯。就八六年，然后是Java c c加加的程序。然后以前的话做过Linux的网络编程，系统编程一些，然后现在的话主要做大数据基础组件，然后呃做基础组件的呃，过程当中也为一些项目做了一些贡献。

嗯，但是贡献其实不是很多，都有一些参与吧。然后一八年加入有赞，然后目前在友赞是负责o lap和实施相关技术。呃，今天主要是讲这么几个部分，然后第一个是OLAP可有赞，呃，第二个是课题高，在有赞的平台化中去建设，第三个是可题高斯在有赞的应用，第四个是未来的规划和一些探索。呃，然后有赞olp的话，呃，整个过程这样的，我们一八年的话引入了，然后那时候是去解决have查询过慢的这个呃问题，特别是一些临时查询啊，BI报表原数据方面，然后psto的话，它主要的架构它是一个MTP架构，然后是全内存加pipeline，嗯，所以它会在交互式访问这方面会比较有优势。

然后但是他主要是离线数据的交互式访问，虽然现在数据库也在做，把它降低到分钟级别嘛，但这个应该还没有非常成熟吧，嗯，然后一九年的话，我们这边的话，针对实时需求嘛，我们引入了所的，因为在没有卓的引入之前，我们的实时是需要用户自己去或者flink计算到那个h base的结果，然后再直接查询那个结果。然后卓的的话，它是啊，它是这么个原理，它是预计算，但是它它预计算的是最细力度的聚合，嗯举个例子，就比如说我们有呃，他step，然后还有ABC3个维度，呃，那他他是聚合，呃就是他们step加ABC这个这四个维度的一个预先的计算，然后如果我这个那个动态查询的时候，我要查AB。

嗯，或者AC的时候，然后再次通过这部分的预计算的呃结果进行动态的聚合，然后呃卓的话，我们主要应用在那个实时监控，实时分析和一些实时数据产品。然后一九年的同时，我们也引进了T0，然后T0的话，它应用在呃一些性能要求非常高，就RT要求非常低的，然后精确度要求也比较比较高，是因为卓的基本上它是没有呃很多精确的能力，无论是数据的摄入还是数据的查询嘛，他基本上都是以模糊查询，或者嗯，或者早期版本也是没有办法做的executive once的这种这种机制。嗯，Kidding的原理的话，它是一个完全预聚合的地方体，它不同于卓的，它是说它是每一个。每一个维度组合都进行计算，但这两种的话各有优缺点吧。嗯，后面我们可以讲一下，然后T定的话，应用应用场景主要包括商家后台流量分析，财务分析，然后2020年我们引入了k Co k Co的话是实时数据分析，他其实就回归到一从明细动态聚合的，就是他不做预聚合啊，当然他也有一个物化视图，物化视图的话是可以去做，就是你可以描述一个SQ语句去做这个预居格的。

嗯，然后应用场景，我们现在的话主要是SCRMDPCDP，然后还有一些直播分析日志指标分析的。然后下面我们就详细对比这几款产品，然后比如说psal的话，嗯，他MTP系统S卡do，然后它的颜值是偏小时级别嘛，然后刚才也说了数据库技术未来可能是分钟级别，然后查询延迟的话是一般，嗯，然后收购知识程度非常完善。嗯，生产数据成本，这个是指说如果后面有日聚合嘛，日聚合它会需要一些生产数据的一些成本。

然后像这种直接查明细，并且是可以直接查HD上面的数据，基本上是没有什么成本的，然后调也是支持，然后去重方式是普通精确支除一的话，刚才也讲了，它是采用最细密度预聚合的方法啊，当然他还有一些别的技术，比如位图索引去查找这个维度啊，呃，然后一些一些那个编码就是呃，就是那个map的编码这些。然后他是支持实时的查询颜值，它是嗯，它是比相对比较低的，因为他做了一层呃叫明细，就最细力度明细的一层日聚盒嘛，那它自然而然比psto，嗯，从出发点上来说，它会嗯更加更加快一点。然后SQ支持程度只能说是较完善，因为它没有P那么完善，生产数据成本因为它做一部分的预聚合，它就相对来说就会有一些成本了，嗯，然后调音的话，新版本好像是支持，然后但是还不成熟吧，我看维度lookup是一直支持。

然后驱虫方式的话是hi log log驱虫嘛，然后他没有精确驱虫，我记得快手的同学他们也有提交的一个，就是第三方的这种也可以做到精确去从比map精确驱从，但这个我们也没有研究过啊，然后kidding的话，它就完全预具和的地方体。然后它是微延时，是微批量的，就没有办法做到实时，呃，因为它这个完全地预聚合的立方体的话，它生产它生产数据，它就成本会比较高了，就是当你需要这种，呃，就是改动啊，什么都会需要重新生产数据嘛。就这方面成本比较高，但是他的优点就是他最后把结果都存到h base。基本上查询就在h base里面查，可能有一些聚合的也是h base Co process去去做一下，他就是RT非常低，呃，他跟卓越的意思，其实卓越的当初也选择选择过这种路线，但是就是一个trade off嘛，就是他们是想说TCn.RT但是我我可以，呃更更灵活，嗯。

然后像kidding的话，有一个比较比较好的地方是它支持那个bit map去重，这个的话很多软，很多olt软件，其实目前都是不支持，嗯，最后讲一下可house，可house的话刚才也讲了，它其实就是呃，有点像pstal m TP的一个架构，然就是从原始的数据进行查询嘛，然后是但是也可以做物化视图嘛，嗯，但是他跟psto还是有点区别的，因为psto的话存储计算分嘛，属于轩nothing这种架构，就是它的存储跟计算是在。嗯，同一个节点上面。

嗯，这种优势就在于它比较快，然后缺点就在于它的盖ability，它并不是很很好。嗯，然后延迟是实时。嗯，然后可cos的话就是查询性能还是比较快的。嗯。这个后面会讲，就大概了解一下，就查询性能相对来说还是比较高的，然后物化视图呢，更快的，因为可以预聚合嘛。的话，其实是比较的一个点，就它的支持不是很好，而且不是就不是那种驱虫的话，也就是精确驱虫，还个log log驱虫，但是也没有bit map精确驱虫。嗯，可高的特性的话是其实就是比较灵活明细数据的circle查询并用化，是图进行加速嘛，这刚才也讲了，然后多核就是可以垂直扩展嘛，嗯，后分布式处理就是它有多分片的技术，然后可以水平扩展啊，然后副本是高可用的嘛，然后整个架构应该还是典型的MPP架构，然后也是支持实时的批量数据的实时批量都支持。

嗯，他它那个存储是劣势存储的，然后外LP基本上都属于列存嘛，然后它是向量化的引擎，然后也用了部分代码编译生成的技术，呃，代码编译生成技术它主要用在那个表达式生成，就是SQL表达式生成这方面嘛，然其实向量化跟代码生成大概是这个概念，就是嗯，就是说如果你传统的火山模型的话，那你每条数据每个特Bo进行处理，进行算子的流转处理的话，那最终会导致虚函数的开销，跟那个分支条件的一个，呃。呃，那个叫什么分支，分支判断的那个，反正也需要一定的开销。然后向量化的方法就是说我把数据存成销量，然后我去，我去那个分摊这部分，呃，这部分的性能啊，代码编译生成的话，我就改一改，我就是把几个算子，本来的话是每个数，嗯数以数据，呃以那个以算子这样一串为中心的嘛，但代码生成的话，我就是把几个算子同时串到一起去做，就是每个迭代我都去做这件事情。

嗯，它是可以去消除这个，嗯，消除刚才的开销的，但是问题是无论下量化还是代码，别人生成也不是万能的，只要说呃。就是比如说像下量化的话，如果在L3K之外的话，就是会物化到内存，然后它就会它就会效果就不不是很好了。这边相关论文也会有，如果感兴趣的同学可以去看相关论文，然后代码编译生成的话，也是如果cash，他不要说cash了，就是说是CPU的那个寄存器里面，如果如果最后放不下，然后雾化了之后，那它也会也会没有什么效果。

嗯，然后KT号上有组建索引，二级索引。但然k house也不是万能的，他不擅长比如说高速的低延迟的更新和删除方法，这个通俗点讲就是嗯行级别的更新或者删除方法。嗯，这个其实很多olp目前都是不支持这个东西的，虽然其实很多业务是需要这个东西，就是。但目前是不太支持，然后还有他的点查性能不太强，因为olt嘛，也不是用来做oltp那种点查类，类似于h base，然后事务也不太支持。但其实现在也会有说olp加入事物的一个呼声，因为比如说像的这种需要做ones摄入的话，如果有一个事物的机制的话，他就可以做到的at onces，就比如说卡夫卡的二阶段提交的S。然后可Co的应用场景一般会有用户行为分析，然后一些运营分析，比如说日活啊，留存率啊，路径分析，有序漏斗转化率分析，Session分析，就特别是这方面，呃，那个一关嘛，他已经办了好几年的那个olp大赛嘛，然后基本上已经演化成可cos修改大赛。

就然后也出了很多这方面的高阶的函数去做这个事情，嗯。然后还有就是实时分析，实时分析监控分析，实时受伤。嗯，大家应该都有一个问题，就是肯定house为啥会快。嗯。其实这样的就是比如说像pstal或者Spark，他们也有向量化代码生成，因为Spark是呃整端代码生成嘛，其实都有这方面技术，为什么可迪house近几年就突然出来，然后各种单表的性能测试就是非常快，那按照作者的说法是因为它是置顶，置顶而上的一个设计，就通常一个软件嘛，我们都会说先设计一个呃，大概的一个框架，然后我们大概去实现，然后不太关注这个底层的性能。

就关注力度没有这么高，然后像K他就会非常关注这个事情。然后这边举一个例子，就aggreg嘛，它会针对不同数据类型使用不同的哈希表进行优化，嗯，大家可以看一下左边这个图，然后其实AG里面肯定会用到哈希表嘛，它会用到这个。啊，比如说in特32的时候，他用的什么各种数据类型嘛，比如说呃，他有一个two level的哈，Map，他说是嗯图level的话，行本不是可以并行的更快的，呃，总之简单来说就跟数据结构啊，然后一些，嗯，包括我也看到一些循环展开，就是有一些技术，就是一般编译器也可以帮你循环展开嘛，但是他们也有些发觉不太奏效，然后自己手动的一些地方去做循环展开，它是比较关注于这个代码性能。

然后每个版本也有代码性能的一个，呃，一些性能测试的回归。然后然后可还有一个的话，嗯，就是他需要nothing的话，它那个存储嘛，它主要是me去去的话，其实跟lsm去有点像，呃只不过嗯就现在的，嗯当然也在做啊，就现在呈现出来的版本，它是没有内存的memory table那个东西的，它直接就是一个文件，就是当我就是当我写入嘛，我一个insert，嗯一条数据的时候，其实我就是在click house的服务端生成一个pass文件。然后这个pass文件呢，就是这边它会它首先它是有序的，然后个pass文件呢，不断跟别的pass文件进行合并嘛，啊所以说可house有一个很重要的点，你不能每条数据。

就是一条数据一条数据的写，你要批量的写，就是这个原因。因为他的insert into，它其实是可以支持批量的，就是可以values很多很多。啊，所以你比如说我插入100条数据，那这100条数据形成呃，大于等于一个pass文件嘛，因为可能part不同嘛，嗯，然后最后每一个pass文件有序，最后合并成一个更大的一个文件。然后还有一个是他的组件索引，跟什么mark range，还有那个嗯，就是数据文件，他要点BM的整个过程这样的，比如说首先它的组件索引，它不是说是每一个组件有一条索引，它是个哈，呃，它是个稀疏索引，就是每隔8192行，一般来说每隔8192行会产生一个球影。呃，然后找到这个索引之后，它会找到相应的mark range的文件，因为这个mark range的文件跟这个索引是一一对应的，这个mark range文件是每一列都会有一个mark range的文件。

然后同样每一列也有个bin的一个数据文件，然后mark文件里面找到刚才的索引之后呢，然后他去找嗯，Bin，他保存的bin of set。然后再去找bin off，呃，其实C收索引是比较有好处的，在olap这种场景，因为因为它可以把它放在内存里面啊，还有就是o lap跟OLTP还是不一样的，OLTP的话是检查嘛，然后你需要在毫秒之内就返回到这条数据，但是o lap更多的是聚合计算嘛，所以说索引它是。可以做，但是没有必要做的力度这么细。这是我个人的理解。然后这边的话，我们有赞的话，现在可house的集群部署大概是这么个架构。然后我们最前面的话，呃，上面有些业务嘛，就SCMDMPCDP啊这些，然后第一层的话，我们会有一个load balance，这load balance的话，我们现在是选LBS，呃，其实这边呃，任何的HTP的代理都是可以的，呃我们选LBS主要还是公司的那个HTP代理，我们叫统一接入嘛，那个统一接入限制比较大，就比如说上传的那个那个配置啊那种东西，就可能他们不愿意这样，嗯，然后后面那一层就到达一个pro。

Pro的话，这边的话，我们其实用了一个，嗯，现在还有点小名气的一个一个代理叫API six，然后这个代理基本上是基于open，就是open是基于那个NGX嘛，NGX加lo就是。NS加鲁瓦加携程这一套去实现了一个open re，然后open API在基于open rest去做这个做了一个网关嘛，这个网关大概是用来熔断泄流安全日志的。

我们除了这些的话，嗯，后面还会讲到，我们也写了一些自定义的插件，去满足一些业务的需求。嗯，第三层的话就是分布式表，就K里面它有一个分布式表。然后但然后下面再再下面那层是那个真正的那个分片嘛，就是每一个分片有两个那个副本嘛。呃，不是，呃，因为我们现在是两个嘛，就是也可以配多个，一般都是两个，然后多个分片嘛，这边就是比如说N乘二嘛，就是每每台机子基本上就是这样的，比如说N乘二总共有三个分片的话，那就是三乘二就六台。然后最后还有一个u keepper u keepper的话协调多个副本复制的，然后这边的话就keepper的话是建议大家在生产环境里面还是要用SSD的那个。硬件。呃，然后因为那个disribu table跟那个成本问题嘛，所以说disribu table那一层跟需的那一层，我们是12为一的，就是每台机子的下载上面每一个都会建相应的表。

嗯，然后可迪克号是铁路，因为我们是那个有赞数据中台的一个部门嘛，嗯，基础中台的一个部门，所以说嗯，我们就是由我们来控制课题cos的写入啊。呃，包括查询那些API这些东西，然后我们当初做了这么一套机制来描来那个满足离线写入跟实时写入，离线的话我们是用Spark。将have表导入的，呃，然后嗯，Have table嘛，其实我们也不是完全用裸的Spark，是用了一个叫word job的一个，呃，一个开源的，国内一个开源的一个软件，它是基于Spark的嘛，嗯，大概意思就是他有一套DSL来描述这个Spark去做什么工作嘛，然后就就我们会有这么一步，就是首先我们去从我们这个代理，代理就是指刚才的那个apiicpi上面去获得。

呃，分片的信息，呃，大概就能获得一些路由的规则。然后呢，再插到相应的那个分件里面去，呃，为什么会这样呢？因为k house他其实写入的时候还要注重这么几点嘛，首先他要批量方式写入，这个刚才已经讲过的原因了，然后还有就是他建议写本地表就不要去写那个分布式表，因为写分布式表的话，那个对JK的压力啊，性能会扛不住，所以他。它那个社区推荐嘛，包括所有的分享，基本上推荐都是写本地表，那写本地表我们就需要有一个机制去获得每个分店的一个信息嘛，那我们目前的话是通过代理，呃，当然也有一个机制，你可以呃，通过他们里面的一个class的表啊也可以的，嗯，然后。

那个批量就是这样吧，然后实施也是类似，其实只是说我们把它写成flink class house think。嗯。嗯。嗯，还有一点就是写入的方式，我们是需要跟哈希这两种方式，Random的话就嗯，不多讲了，就哈希的话会在一些业务的，呃，等一下后面会讲有一个业务的话，他会需要根据某一个key进行哈希，这样的话性能会比较高。呃，这个这个截图的话，就是我们离线导入跟实时导入的一个比较简单的一个截图，然后左边的离线导入，就是你可以选还表啊这些，然后进行导入。然后右边的话，因为我们现在有在那个flink业务嘛，嗯，以前也是TR包这样去用户写代码，然后现在的话慢慢都是演变到flink circle了，呃，所以我们的Li circle也是支持house。

嗯。然后这一章是讲就是今年我们受到腾讯，腾讯QQ音乐他们的一个想法，然后我们也尝试去做这个事情啊，这个初衷点是这样的，就是业务场景他通常是写入量巨大，写多读少，而特别是离线这种场景。就是一个业务说我要用可cos，然后他表建的越来越多啊，也不大可能说我今天有三三几张表就不大可能，但写入量非常大，然后呢读呢，查询的QPS呢往往又不高，特别是像有这这种公司，他说我要做一个业务，也不是说马上啊用户都来用了这种，所以说我们为了他这个写路嘛。就只能扩分片了。只能扩分片来做这个，呃，提高写入的吞吐，然后去缩短整个写入的时间，那这种读写不分离的话，就导致资源非常浪费，呃，就是这个业务可能晚上呃写入很多，但白天CPU又很低。

然后解决方法的话，就是我们想把这个离线读写进行分离嘛。然后这边的话，可行方法我认为有两种，一种就是用K8S可迪house临时集群去写入，就因为官方它也有可迪Co operator嘛，去构建可Co集群嘛，然后我们可以先把数据写到这么一个K8S的集群里面，然后当它生成好segment的文件之后，然后我们再把那个文件搞到生产集群上面。嗯，还有一种就是用Spark构建数据文件，其实这个就有点像Spark b那个h base b load的那种嘛，但这种的话就比较难，因为cos它代码是用CC加加写的嘛，然后你要把那一块比如说抽出来，然后决定啊，这种就相对来说感觉复杂一点。

嗯，我们就是用了K8S的方案，因为比较容易实现。然后整个过程是这样的，我们会有，嗯，有有几个组件嘛，首先有个master节点，然后会有一个dataport job这么一个job，呃，它会它会呃被启动起来，然后这时候ch operator就会构建K8S临时写入集群，然后这个临时K8S的这个po呢，它会运行两个container，一个就是because server本身的container，然后还会有一个我们叫他那个click house sment的push就是这个负责等一下把数据给push到HDS上面。嗯，然后我们从正式集群拿到相关的表的STEM进行创建，然后再把再用Spark任务，就是刚才的word job吧，去把这个数据插入到这个K8S临时集群，那数据写完之后呢，我们通过push一个任务到分布式的任务队列里面。

然后CCN那个segment push选嘛，就接收到这个任务，那他就把数据进行deach。然后他值到他值的话，它会到某一个目录，然后再push这个数据到h Di上面。嗯，然后所有的cment的push处理完数据之后，它会发送到po，发送po任务到分布式任务对里，然后po任务的话，其实呃，事先我们在CH的每个节点上面都会去装这些po了，这些po了的，嗯呃，作用就是从这个HDF上面去下载这个相关的segment，然后在他提到表。呃，其中分布式队列，还有整个集群的一些，呃，就是管理吧，就可用性管理啊，这些东西我们是用那个阿PA提head，阿帕提head，其实呃，这框架其实业绩也不是非常出名啊，他是这样的，他是林肯in，林肯印做的这么一套阿帕提head，它是基于ZK的，然后他他抽象的一些概念去做这些集群管理啊，高可用啊，包括re balance的一些东西。

然后我们就借助了他这个东西去做集群的一些管理或缩容啊，并且自定义了head的re balance。去去保证相同分片的形成一个。啊，因为最后其实分那个部署在那个，诶house节点上面那些铺了嘛，他是需要感知一些嗯，一些信息的，就比如说他是分片的第一个副本，它是分片第二个副本，他不能随意来拿这个东西，所以说我们会有这么个re balance t，然后刚才有讲到那个分布式队列嘛，其实它里面也是基于JK去实现了一个分布式队列，呃，因为数据量也不大，所以基于K的分布式任务队列还是可以去实现的。

呃，然后呃，这部分就我们开始讲那个可迪cos，呃在有赞的一些业务吧，呃，这边第一个讲的就是DNPDNP人群画像系统，DNP的话大概就是嗯，广告投放啊，营销方面的。一个一个系统，它通常会有这么个业务，就是会根据一些标签去获得人群的画像。啊，通常会得到人群的一个画像，或者人群的一个预估。然后我们这边采用的方法是这样的，就静态的标签，我们预计算成正交的位图。啊，什么意思呢，如果你。如果你不这么做的话，你就就需要什么脚印啊什么，呃，这就是你各种标签的那种，呃，计算嘛，你会有非常非常复杂的circle，然后就就很慢，然后我们就采用了bit map，就可houses苏宁的人有贡献bit map，然后我们就用了这个bit map的思路，然这边大家可以看一下，这边它有一个标签用户，呃标签。

标签用户位图表嘛，然后里面就是描述了我们标签怎么存储的，比如说有个tag ID tag value，然后t bit map。啊，这个例子，比如说TID，就比如说性别t name就难，然后有一个UUID的bitma，就哪些用户是男的嘛，啊然后还有一个u ID bit map ofet，这个是这样的，如果呃，因为bit map它是32 32位的，就是如果超过32位的话，那就要用这种off set的方法去存成多个bit map进行解决，然后解决存好之后再把数据的时候进行group调印下，Group计算一下就行。然后还有一点是这边提到正交嘛，正交的意思就是说我们会根据UID进行发新这些数据，因为不这么做，我我开始尝试过，如果不这么做的话，我会得到这么一个结果，就是我一台机子甚至比三台机子跑的还慢，所以我没办法很像扩容，所以说我只能通过这个相当于说把那个UID嘛，进行哈希的一些呃预写，然后写到每个分面上面，然后每一个位图，它在自己的那个下载上面进行计算的话，它是嗯正交的，就跟别的分片是没有关系的。

嗯，然后这边还有一个是话，我们刚才有提到API嘛，所以我们这边写了一个插件去完成这种正交的计算，嗯，大概概念就是我一个请求过来之后，然后我会我这个插件会接收这个请求，然后我会转化成多个分片的一个请求去并发发。然后发完之后，他们各自在自己的分片上面进行计算，计算好之后他直接把结果进行合并，呃，举个例子，就比如说人群预估的话，我就直接把呃那个人数进行相加，如果人群就是用户画像的话，我就直接把这些UID进行简单的合并，就不用进行。

嗯，是这么个过程，嗯，当然还有一些实时标签的话，实时标签因为批量那个离线比标签就这么做了嘛，实时标签的话，你也得通过这种哈希的手段，然后转成这个明细计算。呃，然后查询之后把它转成位图，再跟刚才的静态位图进行交易。就一起再进行计算啊，这种方法确实是有利有弊吧，它的弊端在于这个其实实时标签就比较难控制，因为比如说从最最明细的那一层用户行为表嘛，这个你没法控制，说他到底这个查询复杂度是怎么样的。还有就是哈希的话，对于扩容修容也是比较有难度的。

然后scim会员的话，商品会员系统的话，现在，嗯，其实其实大概的意思就是我们会有赞，因为他是做SS的嘛，他其实现在又在努力争取各个跟大客进行合作嘛，他会针对每个大客也去专门去做，就是在商铺级别去做这方面的人群画像啊营销啊，自动化营销这方面的工作。嗯，所以这个的话就不像刚才那个这么复杂了，就这个的话，因为它基本上都是VR某一个店铺的，所以它数据量不大，所以基本上就可以用肯定house一个明细的查询就完成了这个事情。啊，但是以前卓的也不太能用，因为它他方面的话就可告明细查询的灵活性，在这方面也体现了比较大的优势。然后嗯，我们内部有个叫天网的日志监控套喷，其实他是他就是根据一些维度指标去维度进行计算一些top的指标吗？比如说一个应用的那个错误日志，商家限流服务吞吐量特性功能。

然后以前我们是用卓的，呃卓的就是预聚合嘛，然后我们现在想把它改成，呃，已经改了，就是改成flink加house，但是可house这边是使用物化视图进行聚合嘛。基本上就跟卓维的有点像了，但是就是通过肯定物化视图代替卓维的预的。那这么搞下来的话，我们会发觉可Co比卓越的在GT的整个硬件成本上面可以大大进行大大节省，然后性能也也很高。呃，这边的话性能指标大概是这样的，它是嗯，每秒100万方数据的卡夫卡，写入QPS，那肯定耗，插入的话它也性能很高，也是抵抗得住这个事情。

呃，可迪Co在有赞的未来规划嘛，然后我们是想后面可做容器化部署，然后更多的推广，还有一些更好的平台化跟故障防防范，然后卓越的到可house高电路，甚至把一些卓越的业务就移植到可house上面。嗯，最后最后一。A点就是一些个人观点就可迪告S，他现在其实也不是，也不是万能的，不是完美的，就是他有很多痛点，嗯，可题house如果在做用过课题house的人都会觉得他比较异类，他就比较简单来说，就比较手动挡，你想嘛，他有什么分布式表啊，什么本地表啊这种东西，那作为一个数据库的人，我我干嘛需要知道这些东西对吧，你告诉我一张表就行了，他非常手动的，然后比如写入，刚才要批量写入什么。

嗯，那个就本本地表写入这些东西。那觉得这些东西其实都应该官方做好嘛，对吧，不用自己去折腾对吧，然后物化视图也是这样，物化视图整一个那个。整一个也感觉比较手动的。对，然后他还没有自动re的能力，导致扩容多容运维特别麻烦，就是就是你新加一个机子，你re这很难嘛，它没有自动re balance的能力，然后又因为它是需的结构，它存储计算还是不分离的。那就更难了。然后他的join是不是采用瞎exchange的join这边就导致它数据量大的时候，Join性能就比较差，而且他的join的语法支持也不是，就是有些场景它可能嗯就性能更差，嗯行G比update delete性能性能差，这个时候olp的通病了，其实很多olvp都是没有办法，可能只有孤度啊这些会会去做这方面的trade off。

嗯，现在社区和很多大厂其实都在针对这些痛点进行相关的改造，就比如说存储计算分离的实现。然后今年慢慢的又有一个olp软件，就是进入了大家的视野嘛，就阿PA stories，然后阿PA do也在快速的发展，然后很多大厂开始试用啊，相比K奥，呃，我个人观点啊是do瑞更像一个DEMO数据库，呃，也解决了部分痛点，比如说自动平衡啊，消交易啊这种东西，但其实它最大的痛点就是单表性能，成熟度，稳定性，那确实不太跟肯定克号比还是差了。那还有选择呢，那比如说dori DB ho gras gii class，呃，这些东西呢，他们他们讲的确实就是如果按照他们讲的是蛮好的，就比如说do瑞DB嘛，他能解决。

呃，他是基于阿尔法do瑞的一个商业公司在做嘛，然后他是可以解决你说单表性能差这个情况的，他们是做的向量化，然后还有成熟度，成熟度我就不敢多说啊，就是就相对来说它可以解决一些问题嘛，然后ho gras也是阿里现在在推的一个多模数据库嘛，那能解决的问题更多了，包括ti Fla就TDB跟ti Fla。可能更多了，但这些问题就在于他是否开源就不知道了，所以呃，就未知性比较高吧。呃，就是，于是我们产生了一个想法，就是能否第结合两者，就是两者是指和迪克house跟阿帕do嘛，然后自己去尝试做做，看一个分布式的o lap数据库。然后其实阿尔法奇do瑞是基于in拉进行修改的，就是它也是基于base c加加的嘛，然后肯也是base c加加的，然后我就做了一下POCPOC，意思就是嗯，我就看看到底有没有可能把这两者结合起来。

嗯，然后很多地方可能是临时默的，比如说我写入数据，可能就是代码里面写死的，写哪些数据。然后第一步的话，我是尝试将do be的代码编到house里面啊，这个已经可以了，对，然后第二步的话，我是尝试将嗯，尝尝试解析相关的fragment，这个是什么概念，就是do的话，它有它有两层，一层的话是它叫f fe就是前端一层的话叫be。呃，Be的话，如果熟悉in拉的同学应该都知道，就是in拉算子的那一层嘛，就F1的话，他主要呃，主要做一些管理啊，那个S执行计划啊，这些这些工作嘛，然后他最终跟比通信的话，它会有一个fragment，呃，你说一个S，它有几个fragment的一个一个生成嘛，形成了一个一个circle嘛，一个执行计划，然后我现在的话就是嗯，去去做这个事情，然后尝试映射成科cos的几个算子，比较简单算子。

呃，就是比如说呃大概意思就是扫描聚合表达式，呃跑能跑一个单机circle吗？然后第三步的话，我是将呃do o的存储实现成可storage就的storage，它是有一定接口的，然后我可以用Doris去做它的一个存储。哦，这一步也验证成功，这一步验证成功的原因是因为dori它B跟f fe之间，它有一个自平衡的功能。嗯，可以让你自自于平衡这些，包括他高瑞的话，它最小的力度是table，它不是说只有物理的，所以说就这方面会更加友好一点。开house，他没有table这种概念，它会在这方面会比较难做。

然后第四步的话是最近在做，然后感觉快完成了嘛，但是还没完成，就就是长试实现do瑞STEM no的算子，就刚才讲的是单机嘛，那最后其实是需要把它那个串联起来，几个fragment几个fragment串联起来，其实就是啊，他有个think，有个exchange的node，就是一个发一个一个一个搜码这个东西，然后就就最后可以去跑一个比较简单的分布式circle，然后如果这些都成功的话，我觉得呃，我们应该下半年的话就可以正式进行开搞了。然后这个是呃，作者当中一些一些截图，就是呃，就是一些DEMO的截图，然后左边的话是do fe嘛，它其实是个Java的程序，呃，我们基本上就小改了一下，就是基本上没什么改，然后后面的话就是使用肯定模拟的do be，就do be的话，本来他是就是他自己那个程序起来嘛，我们现在就刚才想把他的代码编到可house的里面嘛，然后现在就用可house的代码。

把驱动执行起来。然后这个是左边这个的话，就是那个单机circle执行的一个结果嘛，嗯，然后右边这个的话是说刚才有讲story story olap，就是我最终其实刚才执行的这个数据嘛，就是在do里面就存成了这个。这个这些数据文件啊，索引文件啊，这些东西。啊，最后稍微扯一下，就是我觉得看数据就数据库未来的个趋势吧，首先我觉得就是云原生嘛，啊嗯，包括任何东西的云原声嘛，包括S跟那个Spark，刚才有讲serve嘛，那个云原声多租户存储基算分。嗯，并且是按需付费的，这个其实国外已经，其实觉得国外还是做了很多了，比如说现在今年很火的snowflake，然后还有big q，他们把这些称为呃，大S也或者叫SS嘛，对，就是因为他们这种他会有一些API暴露出来，然后他们很多系统之间的生态都已经是接交互起来了，就比如说我一个做什么CDP的一个系统，可能我后面就能够，呃有一个Q的接口，有有nola的接口，就是大家都会，其实它未来就是个服务，你可以理解。然后第二个是多模数据库，呃多模数据库这个东西其实必要性肯定是有的，因为我们现在面对用户经常有这样的需求，用户呢，他说我要把数据存进去，然后分析一下，然后分析一下，他说问你有什么样的分析呢，那嗯不是指标的分析呢，那你选什么TDBHS这些东西，然后指标的呢，你选卓谓的k house啊，总之跟他讲了一堆好。

像感觉在忽悠他一样的，但是其实没有办法，这东西就是未来的话，应该是会有这样啊，真正一站式的，但他不一定说最后存储啊，这种东西都是一套的，他可能是对你屏蔽嘛，但真正应该好的就是你是感受，感受不到这么麻烦的事情。

啊，并且这种一站式，他最后比如说那个他的那个比如说ETL这些东西可能也是o lat也慢慢也在这方面也做，比如snowflake，其实ETL也是可以用SQ去做一下，还有一些我这块也不是很了解，我看到有些新硬件，什么TP f p ta是能够优化的。然后我分享完。