共计 6431 个字符，预计需要花费 17 分钟才能阅读完成。
好奇 Milvus 读链路的演进？不知如何优化 Milvus？提到 Milvus 的业务场景只能靠设想？想取得其他人的部署教训？困惑于 Zilliz Cloud？
不藏了，摊牌了，对于上述的所有问题，你都能够在明天的文章中找到答案！
近期，Milvus 社区 2023 线下 Meetup 北京站圆满结束。本次流动，咱们共邀请了 5 位来自外部和内部的社区大佬进行分享。
后方干货值超标预警⚠️⚠️⚠️：
01：Milvus 读链路的演进与将来
02: 从背景到利用：汽车之家的残缺调优实际
03: 智慧树：用 Milvus 进行试题查重是一种怎么的体验？
04: 震惊！BOSS 直聘的部署运维心得竟毫无保留
05: 复盘与瞻望——你必须要晓得的 Milvus & Zilliz Cloud
目录在此，各位按需自行手动“跳转”。同时，现场完整版秘籍（PPT）可关注 Zilliz 微信公众号回复【0415】获取。
01.Milvus 读链路的演进与将来
Zilliz 高级研发工程师夏琮祺次要从 Milvus 的读链路从 2.0 到 2.3 Beta 版本的演进途程进行分享。
从 Milvus 2.0 版本开始，读链路的定位便面向云原生架构，因而从架构开始就心愿它是一个可扩大的、各个组件之间可能互相解耦合的设计。
2.0 版本的时候，Milvus 的读链路是通过 MQ 的，对于一个 Collection 的查问，须要取得整体 QueryNodes 的执行后果：
- Proxy 播送 Search/Query 申请
- QueryNode 订阅 SQ Topic，解决读申请，Produce 到 SQ Result Topic
- Proxy 订阅 SQ Result Topic，收到所有的后果后合并、返回
Milvus 2.1 版本的时候，Milvus 引入了通过 Grpc 发动读链路。Proxy 获取 Collection 所有 Channel 对应的 ShardDelegator 列表，通过 Grpc 拜访服务：
- Proxy 通过 QueryCoord 拜访获取可用 ShardDelegator 列表
- Proxy 调用 ShardDelegator 的 Search/Query 接口
- ShardDelegator 执行申请后返回
此外，Milvus 还进行了一些其余架构的调整，在 2.0 版本的时候，QueryCoord(v1) 所有的操作均进入一个调度器（scheduler）对立调度执行：
- Load/Release 操作会进入队列排队
- 对应的 Segment 散布会记录在元数据内，所有的 load/release/balance task 也会被记录
Milvus 2.2.3 版本时，QueryCoord V2 通过 Target Driven Load 的形式实时更新 Collection/Partition 的 segment、channel 列表，通过 Checker 来实现数据的正确加载和调整：
- Load/Release 仅变更 collection/partition 级别的元数据状态
- 通过 Checker 查看 query 集群的 segment 散布来生成 Load/Release task
- 通过 Target 迭代实现“handoff”
目前，Milvus master 版本对 QueryNode 进行重构，移除了开销微小的 Delta Channel。自从 Milvus 开始反对 Delete 操作后，局部 QueryNode 须要 delta channel 来获取 delete 数据，起因无外乎三点：须要额定的转发操作；MQ 的 topic 数量 *2、代价低廉；一致性等级受到 2 个 channel 的影响。
最初，夏琮祺分享了 Milvus 对于在读链路上相干的布局和瞻望：
首先是对于 Growing Segment 的优化。Growing segment 作为流式数据，在 2.2.x 版本内无奈构建索引，作为木桶效应中较短的那块木板，如果零碎中存在大量的 Growing Segments，会重大影响查问效率和吞吐。为此，Milvus 在 2.2.4 版本曾经减少了 Ignore Growing 选项，将来会反对对 Growing segments 的索引。
其次是优化 Load。QueryNode 对于 segment 的查问目前为纯内存操作，硬件昂扬。对于离线剖析场景，颇有“杀鸡用牛刀”的象征。为此，Milvus 打算优化 Load 的内存应用；引入 mmap，可能自定义 buffer manager；实现 Auto Load。
02. 从背景到利用：汽车之家的残缺调优实际
汽车之家的高级数据工程师王刚进行了《向量检索平台实际》的主题分享。
他提到，汽车之家应用 Milvus 有这样一个背景：
在调研向量检索平台之前，汽车之家的平台用户在搜广推等业务方面，曾经基于 Vearch 宽泛地应用了向量检索方面的技术，包含举荐召回、视频图片去重、文本检索。不过，这也带来了一些问题，例如保护艰难、性能问题、资源节约、向量数据接入效率低等。
在此状况下，汽车之家抉择了 Milvus。起因在于，Milvus 领有先进的架构思路，例如读、写、建索引不会相互影响；其次，Milvus 社区十分沉闷，社区用户提出的问题会有专门的人去跟进、解决，可能及时失去反馈。
在根底建设方面，汽车之家联合 Milvus 的劣势与汽车之家向量检索平台自身的需要进行适配和调整，最终搭建出一套晦涩、好用的基础设施：
王刚示意，平台的基础设施为 s3 云存储、etcd、kafka，平台反对多个 Milvus 集群，并建了一些治理性能（汇合治理、索引治理、权限治理）。再者，汽车之家对立了数据接入的入口，能够通过配置的形式间接把数据接入到 Milvus 中。同时还配置了对立的查问入口，适配了 vearch 的查问语法。在部署层面，汽车之家革新了 Milvus 的原生镜像，使其反对汽车之家流水线。此外，还将 Milvus 部署汽车之家的云 K8S 上。
后续，汽车之家依据本身需要做出的相应调整：
在接入效率方面，标准了接入形式，平台反对通过配置将数据从 Hive 间接导入 Milvus；反对 AB 表的接入模式，思路很简略，每次更新的时候都会建一张新的表，之后会告诉平台的查问接口，让其切换到新的表进行查问。
在性能方面，针对网络抖动，汽车之家进行了相应的优化，防止其带来的影响。首先是弱一致性查问的时候不会再申请全局工夫戳；其次，将同一正本的 segment 调配在雷同的 Query Node 上。
在稳定性方面，在应用 Milvus 2.1 版本时遇到 Datacoord 合并 Segment 卡住、Proxy 偶发性重启、DML Channel 记录位点谬误等问题在降级至 Milvus 2.2 版本便失去解决。
03. 智慧树：用 Milvus 进行试题查重是一种怎么的体验？
智慧树 AI 能力平台负责人张宇则从偏工程化方面分享了 Milvus 如何在智慧树进行利用落地的过程。
智慧树的定位是寰球大型的学分课程经营服务平台，平台的题库领有亿万级别的海量试题。每学期开学都有很多老师须要将不同课程不同题型的试题导入到题库中去，
因为之前没有做试题去重以及去重的形式效率比拟低，题库中存在大量的反复试题，导致数据库中存在大量的冗余数据。
随着数据量的一直减少，平台急需一个试题查重的服务，能够离线解决现有的冗余数据，还可能提供实时服务来可能在导入试题的时候就能够晋升给老师有哪些题是反复的，在数据起源就解决反复试题的问题。
但试题查重谈何容易，其中波及准确率、复杂度和效率问题。首先是准确率的问题，是否尽可能无效地找到反复的题目，不单单是字面意思的类似，还要有题目语义的类似判断。复杂度问题，不同学科课程，须要针对各自的特点采取不同的类似度查重判断的规定。效率问题，批量导入题目的时候，岂但须要跟题库里的海量试题比拟，还须要跟本次导入的题目做比拟，还要保障查重的效率性能足够高，不影响用户体验。
在此状况下，智慧树选用了基于 AI 算法向量 + Milvus 的计划进行题库试题去重：工程服务解决业务逻辑将题目的文本信息调用 AI 算法服务将题目文本转换成向量，而后在 Milvus 中通过向量去搜寻类似度大于阈值的向量，将对应向量的题目 id 返回。
有了题库试题去重的胜利业务落地之后，智慧树对向量数据的使用量也是一劳永逸。随着其 AI 业务的一直减少，更多的业务需要也随之而来，例如视频、教材、常识图谱等资源的搜寻举荐，都会大量应用到向量化的数据来检索类似度，且须要通过应用的不同的模型训练和不同的业务匹配规定。为了更好地反对业务和晋升效率，一个通用向量生产平台就变得十分重要。
张宇提到，智慧树通过不同的实时推理集群产生的实时向量和离线训练集群联合数据平台产生的离线向量数据，存储到 Milvus 的集群里，并且利用配置好的规定引擎，来解决向量的生产和类似度检索工作，大大晋升了公司的向量生产性能和效率，更好地反对了业务的应用。
04. 震惊！BOSS 直聘的部署运维心得竟毫无保留
BOSS 直聘的 AI 研发工程师马秉政分享次要从 Milvus 的部署运维方面进行了教训分享。
BOSS 直聘 Arsenal 算法平台，是面向 BOSS 直聘全厂数据 / 算法工作者的一站式 AI 开发平台，包含数据处理、模型训练、推理服务、MLOps、运行监控、平台治理和产品体验。平台在向量检索的次要应用场景是类似图片召回、类似文本召回和举荐召回。
马秉政示意，在目前公司的泛滥算法局部中，实现向量检索的伎俩各不相同，包含：在内存中暴力计算；基于 Faiss 实现索引，自建服务；应用平台提供的向量检索系统。不过，这也带来一些存在计算瓶颈、资源节约、服务稳定性有余的问题。
抉择 Milvus 的起因也很简略，包含云原生个性、存算拆散、有多样索引反对、简略易用。
随后，马秉政又从集群部署、业务指标调优以及稳定性建设方面进行了分享。
首先是集群部署。在进行部署计划的抉择时，BOSS 联合 Docker compose、Helm chart 进行部署、拆解。
那么，有没有好的部署教训？马秉政示意，让一套 Milvus 集群胜利运行的准则就是组件配置对立、失常通信。解释一下这句话的意思，Milvus 的外部无状态组件共 8 个，依赖 3 个内部服务 / 中间件，以教训来看，Milvus 的部署准则只有一个，即只有能保障各个组件的配置对立，且可能失常通信，就能使一套 Milvus 集群运行。
其次是业务指标调优。通常对于业务来讲，最关注的就是 QPS 与 TP99，依据不同的业务场景的调优计划也不同。
例如 TP99，首先间接影响查问提早的变量就是数据量了。在不思考索引的状况下，1000w 128 维的检索耗时个别在 100ms 以下，更高的数据量能够通过数据分区来升高耗时。
又如 QPS，减少 querynode 的 CPU 资源是晋升 QPS 的间接伎俩。另一个伎俩是减少正本数，Milvus 最多反对等同于 querynode 数量的正本数，用内存换 QPS，须要进行取舍。在部署 querynode 时，BOSS 通过 cpuset 绑核 + single numa 限度 CPU 在繁多的 numa node 上，保障 querynode 的资源可用性，晋升内存的拜访效率，达到晋升性能 + 查问耗时的稳定性的成果。
在稳定性建设方面，Milvus 的 backup 工具提供了 collection 的跨集群备份恢复能力。此外，团队会为每一个集群别离创立读写两个域名，这样减少了一层操作空间，当一个集群呈现写入问题时，能够先将写域名切到新集群以供数据更新，待所有数据恢复后切换读域名，这样能够让查问端无感知。而对于稳定性要求高的业务，会采取主备集群的办法，来确保呈现问题时，有肯定的缓冲空间。
此外，马秉政也提醒，Birdwatcher 是运维治理 Milvus 集群十分重要的工具。
05. 复盘与瞻望——你必须要晓得的 Milvus & Zilliz Cloud
Zilliz 合伙人、产品总监郭人通从 Zilliz 最近的重要停顿、Milvus 要害的性能个性以及 Zilliz Cloud 的产品蓝图三个方面进行了分享。
郭人通示意，过来 3 个月的工夫，Zilliz 成绩颇丰，包含：
- 和英伟达 GPU 的索引算法库进行深度集成，与 CPU 相比，HNWS 的性能大幅晋升；
- Milvus 从 2.0 版本升级至 2.2.3 后，性能晋升 4.5 倍；
- 扩展性方面，Milvus 可能解决 10 亿级别的 768 维向量；
- Milvus 要害性能方面新增反对 Range Search、Upsert 和 Bulk Insert；
- 目前 Milvus 曾经可能反对 Resource Group、Rolling Upgrade、Quota protection、Dynamic config update；
- - 针对往年来大火的 AIGC，Zilliz 在生态上做了集成，包含 OpenAI、Hugging Face、Langchain、LLaMA-Index、Nvidia Merlin。
随后，郭人通介绍了 Milvus 最近的要害性能个性。除了最近新增的个性（包含减速混合过滤的速度、新增磁盘索引）外，他着重介绍了将来 Milvus 2.3 和 2.4 版本的重要变动。
首先是 Milvus 2.3 将反对 Json 数据类型，在此基础上亦会反对 Schemaless。此前，用户在应用 Milvus 的过程中会先定一个动态 Schema，此时，如果在理论业务层面如果多了几个 feature 或者 Metadata，就意味着数据须要从新来过。经此变动后，Milvus 2.3 便可实现动静局部通过 Json 列反对。
其次，Milvus 2.3 也会反对 vector list。在实际过程中，团队发现很多用户的业务并不非以一个向量为单位，例如视频或者长页文档，可能每段都会对应一个向量，然而进行查问业务时却须要将整篇文档或整个视频作为查问对象。以视频为例，有了 vector list 当前，一个数据实例能够领有一个属性列。在这个属性列中，一个视频对应一个主键，视频间断关键帧的 vector list 对应该行的一个属性。由此便可反对这一组向量的近似查问。
Multi vector embeddings 是 Milvus 2.3 版本的另一个重要个性。同样以视频为例，视频帧的个性会有一个 embedding，而视频的题目可能还有另外的 embedding。这两套 embedding 各行其道，理论进行查问时不仅须要题目近似，内容局部也要相符合。当然，这一点与后续提及的混合查问也是强相干。
提及 Milvus 2.4 的重要个性，郭人通强调，该版本的重要个性之一便是混合查问。正如之前所言，在数据 Schema 中蕴含传统的动态 Schema 和动静 Schema，其中蕴含密集向量、稠密向量、文本相干、标签数值等。各列能够进行混合查问及属性过滤，随后会进行交融的 ranking。这个过程有点相似举荐零碎中的粗排精排。目前团队实现了一种比较简单的线性加权的形式做交融，后续会依据社区需要抉择其余解决计划。
最初一部分是 Zilliz Cloud。整体而言，Zilliz Cloud 的布局分为三个阶段，第一个阶段的次要工作是反对保护好根本的数据库操作。目前，Zilliz 曾经实现了第一阶段的布局，在云上有超过 1000 位用户，反对两朵云（AWS GCP），应用 Cluster 的部署形式，性能方面与 Milvus 2.0-2.2.3 统一，吞吐为 4.5 倍，延时升高 2.5 倍。第二阶段是实现 Zilliz Cloud 与 Milvus 要害个性的持平及稳固，笼罩阿里云，提供 Serverless 反对；第三阶段将反对微软云，实现面向云服务的 GPU 版本的资源优化。
此外，近期 AIGC 开发者的需要增长迅速，针对这部分用户对于上游大模型、模型服务提供商的生态对接需要，郭人通示意，团队正打算于 2023 年 7 月底前集成结束，包含 OpenAI、Google、国内中文大模型等。
🌟 相干链接 🌟
- OSSChat: 艾瑞巴蒂看过去！OSSChat 上线：交融 CVP，试用通道已凋谢
- GPTCache：我决定给 ChatGPT 做个缓存层 >>> Hello GPTCache
GPTCache：LLM 利用必备的【省省省】利器
- Zilliz Cloud：LLM 快人一步的秘籍 —— Zilliz Cloud，热门性能详解来啦！
本文由 mdnice 多平台公布