大家好,我是Zillis的高级研究员易晓蒙很高兴有机会在这里给大家分享我们公司的一个主要的一个产品MuOS 2.0的一个最新的进展和我们的一些想法和经验今天我的报告的题目是MuOS 2.0一个云原生的相量数据库我报告的内容有以下的四部分组成首先的话我会介绍一下MuOS这个产品这个项目主要会讲我们对MuOS定位是什么我们为什么要做MuOS以及MuOS现在的一些发展的信息然后接下来的话我们会简单的回顾一下MuOS 1.0的设计然后借此进一步的去给大家介绍我们MuOS 2.0的一些架构上的一些新的设计和想法最后的话我们会讲像MuOS的一个roadmap和我们的一些开发的一些方便MuOS使用的一些工具第一部分就是讲我们的MuOS的介绍我们对MuOS的定位的话是认为它是一个面向非节目化数据分析和搜索的一个开源的数据库系统然后首先我们需要讲一下就是我们为什么关注非节目化数据分析和搜索这一点随着我们说的大数据或者是说IT技术的发展我们可以看到就是我们周围的数据是我们周边的数据是越来越多的成一个爆炸的一个趋势的发展然后另外的话我们可以看到另外的一个趋势就是我们周围的数据也越来越多的从传统的结构化的数据再往非结构化的数据去变化传统的话我们可能接触到的主要的数据类型包括什么int 整形 浮点 包括自付串对他们这种日期这种格式但是我们随着这种时代的发展我们现在我们能看到的周边的越来越多的信息的话更多的想这种文本 Jason格式的这种非结构化或者半结构化这种数据以及这种图片 声音 以及蛋白色结构时空数据 社交网络以及用户画像这种完全是非结构化数据的这种信息然后非结构化数据整体而言是以一个越来越大的比例在我们的生活中出现然后我们根据IDC的报道在2020年 也就是去年的时候就是全球产生的80%的数据都是非结构化数据然后对于产生的这么多的非结构化数据而言就是他们的这种分析和检索的方式也和传统的结构化数据是不完全一样的我们从这一页可以简单的给一个例子就是说我们非结构化数据的话它分析的一个很主流的一个方式就是通过这种深度神经网络的形式不管是图片 视频 或者文本各种各样的非结构化数据它先映射到一个高维的一个相量空间里面让它变成一个相量然后在这个相量的空间里面做分析和检索举个简单的例子就是以图片检索而言我们做图片检索的时候我们会使用这种各种卷机神经网络把我们抵护的这些图片依次的转化成一个高维的相量然后当一个查询请求来的时候一般来说我们也是同样的把它用同样的神经网络转化成一个高维的相量然后我们在这个高维的相量空间里面看就是我们请求的图片对应的相量和抵护里面的这些相量的一个相似度我们找最相似的这些抵护的相量然后把他们对应的那些原始的图片作为结果返回给用户这样就完成了一个图片检索的一个功能相同的在一些其他的场景包括一些智能的问答包括这种生物药里面的这种什么分子结构的搜索什么其实做的方式也是一个比较类似的总的而言就是我们认为非结构化数据处理就是大的层面上看可能是一个这张图里面的这个样子从底下往上看的话就是底下的数据可能结构化数据 非结构化数据都有然后我们其中一部分通过神经网络把它变成了这种Inviting成这种相量数据然后另外的话也有一些数据因为相量数据它有可能不能完全的处理所有的这种查询分析的任务所以我们有一部分像ES这一类的系统它也可以对这种传统的就是对这种原始数据非结构化数据作为一个这种原始数据做搜索和分析的这一类工具所以说我们认为就是实际上的这个之后的这个数据分析应该是结合着相量搜索和一些协助协助相量搜索的一些其他的这种原始数据处理的系统协同进行查询的然后当一个查询请求来的时候从这个图上面看的话就是每个请求过来的时候我们可能对这个请求做解析然后通过相量和非相量的引擎协同去查找最后得到一个最终的答案然后我们Muoss的定位其实就对应了虚线框里面框起来的这一部分内容接下来就讲一下我们Muoss的一个发展的情况Muoss是去年的就是20年的3月份以这个幅画项目的这个作为幅画项目加入了这个LFAI and Data这个基金会然后在今年的上半年的其实已经从这个基金会里面毕业了作为一个毕业的项目现在是Muoss社区的一些初步的信息我们可以一些数据我们可以看一下就是到我做视频的这个时候现在的话就是我们Muoss总共有11000个commit然后GitHubStar大概有8600多个然后contributor的数量是目前是173个然后目前大大小小的版本发行了大概有71个我们目前的全球范围里的用户数量大概是1000多家的样子以下的这张图我们就是简单的列出来一些我们知道的一些比较重要的一些Muoss的一些用户然后我们可以看到几乎是各个行业里面的都有一些这种知名的这种企业厂商都在使用Muoss来解决他们的一些业务上的一些问题我们下面就是按照这个应用场景业务场景分类就是简单的列出来Muoss可以支持的一些业务我们这里就是主要列出了就是我们最主要的5个场景在电子商务的场景主要就是Muoss的这种功能主要支撑可以支撑一些像这种智能客服商品推荐这一类的各种各样的这种业务然后在这种互联网的服务我们可以做一些包括图片检索视频查宠包括用户画像这一类的等等这一类的功能然后生物治药方面的话更多的可能就是这种小分子药物的筛选蛋白质结构的预测以及这种我们说的DNA系列的比对这一类的业务然后金融行业的话更多的可能主要是这种反欺诈或者保险的分析这一类的业务然后对这种信息安全领域的话我们支撑的业务可能以这种病毒的检测和对比分析以及这种什么垃圾邮件的检测然后入侵的检测为主这是从另外一个视角就是从数据类型的视角来对我们Muoss支持的业务进行了一些分类然后具体的内容其实是跟上页差不多的只是组织的方式不一样然后我们可以看到的话就是不管是图片视频自然语言音频以及这种用户行为画像然后结构化的这种数据的分析就是在各种各样的领域其实Muoss都能够支撑这种数据的分析和查询的接下来的话我们就简单的讲一下就是我们Muoss 1.0的这种当时的设计Muoss 1.0的话我们当时主要是希望在1.0里面支持完整的相量数据的插入19化构建索影查询然后通过一些简单的这种不是简单是比较易用的这种API的方式能够让用户的很好的去快速的上手的去使用我们的系统然后通过这种用户的反馈我们可能就是去了解用户现在的最主要的需求是什么然后更好地设计我们下一步的产品也就是我们现在的2.0然后接下来我简单的介绍一下1.0是1.0的价格以及它是怎么运转的在1.0里面就是我们的Muoss有一个叫Request Handler的一个组件它用来负责接收和处理所有从用户测应用这边发过来的请求然后首先讲一下数据插入的请求是怎么做的就是当有数据插入的请求来的时候我们一般是先在内存里面做一个以Memory Table的形式去把数据缓存下来然后当Memory Table的数量或者是大小达到一定程度的时候我们把它以持久化的形式存储在这种磁盘里面然后随着时间的推进的话磁盘上的这种数据我们把Memory Table刷下来叫Segments随着小的Segments越来越多的话我们会进一步的对Segments做这种数据的整合和合并让它变成比较大的Segments然后从进一步的看大的Segments里面的数据组织的形式大概是这样的我们是一个按列存储的形式我们可以想象一下数据库的表里面我们每一列的数据是连续的存在一块的然后我们可以技能支持相量化的数据存储也能支持这种传统的属性列的数据进行存储然后当一个Segments它达到一个足够的指定的大小的时候我们会把Segments给封闭起来然后根据Segments里面的数据建立一些这种縮影然后使得它能够在查询的时候能够更高的支持用户的查询请求然后当查询请求来的时候我们有一个组件叫查询处理的组件然后我们把所有的这种数据查询的算法以及我们的这种加速的优化的这种策略都实现在Cury Processing的这个组件里面然后由于现在的话就是大部分的这种相量检索的策略它都是假设就是所有的数据都是存储在这个注流在内存里面的所以我们会有一个BufferPort一个缓冲区的一个机制就是我们把所有的这个和查询相关可能相关的数据我们都全都漏得到这个内存里面去然后方便这个查询MuOS这个1.0的系统它是一个单机的系统然后它的大体的这个框架大概就是像刚才描述的一样然后简单的话我们下面去进一步的介绍我们MuOS的1.0的一些简单的特性第一个特性的话就是说我们其实支持了一些对一个计算的支持我们除了我们在传统的CPU上面支持了这种CMD的这种指令级的支持然后通过相量化之行的话去加速这个数据的查询然后另外的话我们也对包括GPU、FPGA、甚至ARM指令级下面的一些芯片做了一些处理和支持然后另外的话就是我们MuOS 1.0里面尝试着支持了一些可能就是标准的一些数据库的一些功能包括什么数据的Partition、数据的芯片以及我们基于这种属性的一些这种查询然后在相量减锁功能这一部分的话我们基于一些现有的一些开源的库和算法这些算法的话做了进一步的这种性能的提升然后最终的话我们是支持了多语言的这种API然后我们支持的这种方便各种不同用户的这种使用的需求然后我们主要支持的API的语言有Python、C++、Java和Go我们1.0产品大概是今年3月份左右发布的然后我们1.0发布之后我们也广泛的收集了一些我们的一些主要的一些用户的反馈然后从我们得到的反馈来看就是用户的在有1.0之后主要的这个需求集中在这种数据规模大大到单击可能没有办法用单击去进行处理的这种规模然后以及是这种负载的多样性有一些用户的负载可能更偏向于这种数据插入更新有一些可能是一个更偏向于静态的数据集的一个查询就是负载是多种多样的以及是对这种数据的持久化、弹性这种的要求所以整个来说就是我们Mewos 2.0的话我们是设计一个就是一个设计的目标是一个分布式的然后能够自动弹性的一个这种组建之间结偶的一个分布式的一个框架然后我们2.0的话设计的一个最主要的一个思想就是拿这个日制序列的分发和订阅作为一个作为我们系统的一个主干然后我们整个来看就是我们数据库里面有一套这种中心式的也不知道中心式就是一个主干的这种日制分发订阅系统然后其他的各个组建的话它其实都是对日制系统的一些发布和日制序列的发布和订阅这样的一种模式它可以带来两方面的好处第一方面的话就是我们的数据的这种持久化变得比较容易我们通过就是将所有的数据的操作以及系统的状态都写到日制里面去然后通过日制的持久化来达到整个数据库状态和数据内容的一个持久化就是我们当任何的节点或者数据系统我们的系统故障之后重新齐起来的时候我们只要重新读这些持久化的日制里面的内容我们就可以知道我们系统的运转的状态到了什么地方然后我们可以根据日制进行这种各个组建甚至整个系统的恢复另外的话就是我们通过日制系统的方式把各个逻辑功能的这种组建进行节偶和关联然后这样的话就是我们所有的内部的组建只需要通过这种主要是通过日制的分发和订阅就是去发布自己带来的这种比如说数据的一些变更然后去订阅和自己比较相关的一些日制内容的这种方式去完成更新的各个组建的状态和它的完成相应的任务然后在这个过程里面就是我们用户不是用户就是我们的组建的话主要是只要通过日制订阅就可以完成它的功能所以这样的话组建之间的偶和度是比较低的然后我们这样就允许我们能够在对每一个组建做独立的功能升级然后随着我们系统的功能这种扩展的需求来到的时候我们也可以通过这种增加新的组建然后让新的组建也去分发和订阅日制的这种方式达到一个很快速的系统能力扩展的一个目标下面这张图简单的就是成立了我们Mios2.0架构里面的所有的系统组建然后大体来说可以分成四个部分其中第一个部分是我们的accessory就是它的介入层然后其他的还有包括coordinator service包括work node以及我们负责存储的像原数据存储消息存储以及这个19化就是这种存量数据的存储的组建我们接下来对这些组建逐一的进行介绍首先的话就是accessory我们的介入层然后介入层的其实主要的工作就是把用户的请求接收之后做一个转发到对应的日制的通道里面去然后分发给对应的不同的这种系统的组建然后我们在Mios2.0里面我们仿照传统的secal语言就是把数据操作分为了DDL,DML,DQL这些类型DDL的话主要就是像这种数据库然后表的创建和删除这一类的功能然后DML更多的是像具体的某张表或者某个数据库里面的数据的插入删除更新这一部分的操作然后查询的话就是有点像类似我们secal就是说对原来的对数据库里面的数据进行一个搜索或者是检索的这一个功能然后在我们的Mios里面因为是一个分布式的设计所以它每个组建它其实都有可能有多个节点同时在工作然后我们的coordinator这一层的话其实就是负责底下的这些组建同一个组建内部的各个节点的这种协同主要是比如说任务的分发以及是负载均衡这方面的内容然后我们的coordinator其实分了四个不同的针对不同的功能逻辑我们分了四种不同的coordinatorrootcoordinator的话它其实主要是负责刚才说的DDO那一部分什么创建数据库键表山表这一类的操作就是维护的是数据库里面的一些关于数据表的一些原数据信息然后datacoordinator的话主要是负责数据的插入以及持久化的这一部分功能的一些协调然后curycoordinator主要是负责查询的功能的协调然后indexcoordinator主要是负责这种存量数据里面构建所有的这一部分然后worklayer就是相对于coordinator那一层的话其他其实就是一个实际完成任务的一个干活的一个角色然后主要的做的更多的数据的更新查找这一部分的功能然后data node的话就是对于刚才的data coordinator主要就是用于完成数据的插入和持久化index node的话就是负责这种实际的构建所有cury node就是做负责数据的查询然后需要注意的就是我们把这个通过这个coordinator和work这个设置就是把这个work的节点都做成了无状态的而所有的状态信息都维护在coordinator里面这样的话我们不管是扩缩容或者是这种故障处理的时候我们这个work其实都比较容易就是我们其实只要把这个相应的work起起来然后去coordinator那边去问一下就是我们就是当前的这个起起来的work需要做什么事情就是它需要做哪些任务然后把数据导上来就可以直接进行工作了而不需要做一些很复杂的一些这种状态恢复这一类的工作然后最后的话就是存储层然后存储层其实是由三个比较独立的部分构成一个是Lock Broker就是我们的日制序列的主干的分发订阅的这个十九化存储然后另外的话就是我们的这个表里面的就是我们coordinator里面数据的这种系统里面系统状态的原数据存储以及我们对这种存量数据的这种十九化的存储三个部分讲完了我们没有系统的大体的价格之后我们就是进一步讨论一下就是我们基于日制的这种基于日制的这种数据库的话它可能遇到的一个问题就是我们查询的时候可能会比较慢因为我们需要把整个日制里面的数据整个都过一遍之后我们才知道哪些数据和查询相关然后进行相应的查询然后在mouse里面我们为了解决这样的一个问题我们其实是做了一个存量和增量数据的一个分别的处理就是每隔一段时间的时候我们会把日制里面的数据就是日制里面的这些数据就是增量的数据转化成一个存量的形式然后对存量的这种数据通过构建所有的这种方式去让它能够支持更快速的查询然后每次当用户的这种查询请求来的时候我们只对日制序列里面少量的这种增量数据以及大量的存量数据分开进行查询由于增量的这种日制序列它增量数据通常来说规模都比较小所以那一部分的查询开销其实还是比较可控的然后存量数据虽然规模大但是我们通过构建所有的方式也可以有效的提高它的处理效率然后最后我们把两边的查询结果进行统一的整合就得到最终的结果再返回给用户这样的话就可以比较好的处理就是查询比较慢的问题另外的话就是我们刚才说的基于日制的主干的架构设计还带来一个好处就是系统的扩展比较好做因为我们现在做飞机化数据处理的话其实用户的业务场景其实也是不算在迭代和快速发展然后为了能够满足用户不断的迭代的业务上迭代的能力的话我们系统也需要同时能够做到就是比较快的扩展和增加新的功能然后在基于之前的就是我们刚才说的Background日制的骨干的模式的下面我们如果在系统里面增加新的功能的话其实我们只要提供一些新的一些组件然后去订阅日制里面相关的一些和这些组件功能相关的这些日制内容就可以很容易的把这些组件接入到系统里面去然后我们需要额外处理的一部分内容是查询这一遍就是我们需要对新功能的查询做这种解析以及各个传统的这些现有功能和新功能之间的这种查询分析引擎之间的协作和执行方式选择的话就是这一部分我们需要做一个工作去做一个合理的安排接下来的话就是介绍一下MuOS的Roadmap和我们开发的一些就是辅助性的工具MuOS是从2018年10月我们开始做的然后在19年的4月份我们发布了最早的版本0.1版然后19年的6月我们就找到了发现了有第一批的我们的用户然后19年的10月份我们正式的进行开源去年3月份我们就作为这个复发项目加入了LFA and Data的基金会今年的话3月份我们1.0的版本发布然后2.0版本的RCE版本是今年6月份发布的然后接下来的话MuOS最值得期待的一个mouse stone的话就是我们的2.0的JA版本应该是在今年的12月份如果进度比较理想的话也有可能今年的11月份就会发布了然后我们为了方便不同需求的用户更加容易去使用MuOS的话我们开发了就是我们的一个前端的一个可视的图形界面然后可以从图形界面上做这种MuOS的集群管理原数据的管理数据的查询以及这种组建状态的诊断然后同时我们也做了这种命令行的界面然后这两个界面的话我们都已经开源出来了大家感兴趣的话也可以在github上去关注一下然后另外的话我们在系统里面就是MuOS2.0是可以通过KBS这一套对我们的系统的安装部署甚至擴缩容进行统一的管理这样也方便了用户的对我们的这种系统的使用和运萎的成本也会有所下架好的我这次的报告主要就是以上内容感谢大家的观看