Kubernetes 简介及其调度原理

前言   

Kubernetes 是一个可移植、可扩展的开源平台,用于管理容器化工作负载和服务,有助于声明式配置和自动化。它拥有庞大且快速发展的生态系统。Kubernetes 服务、支持和工具广泛可用。
Scheduler 作为kubernetes 的核心调度组件,扮演管家的角色遵从一套机制——为Pod提供调度服务,例如基于资源的公平调度、调度Pod到指定节点、或者通信频繁的Pod调度到同一节点等。本篇文章着重剖析 kube-scheduler组件的工作流程及设计模式。

 一、k8s是什么  

首先,它是一个全新的基于容器技术的分布式架构领先方案。Kubernetes(k8s)是Google开源的容器集群管理系统(谷歌内部:Borg)。在Docker技术的基础上,为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能,提高了大规模容器集群管理的便捷性。

Kubernetes是一个完备的分布式系统支撑平台,具有完备的集群管理能力,多扩多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和发现机制、內建智能负载均衡器、强大的故障发现和自我修复能力、服务滚动升级和在线扩容能力、可扩展的资源自动调度机制以及多粒度的资源配额管理能力。同时Kubernetes提供了完善的管理工具,涵盖了包括开发、部署测试、运维监控在内的各个环节。

二、k8s 组件 scheduler 简介 

kube-scheduler 是 kubernetes 的核心组件之一,主要负责整个集群资源的调度功能,根据特定的调度算法和策略,将 Pod 调度到最优的工作节点上面去,从而更加合理、更加充分地利用集群的资源。

 kube-scheduler的主要作用就是根据特定的调度算法和调度策略将 Pod 调度到合适的 Node 节点上去,是一个独立的二进制程序,启动之后会一直监听 API Server,获取到 PodSpec.NodeName 为空的 Pod,对每个 Pod 都会创建一个 binding。

 三、生产环境的挑战 

  • 如何保证全部的节点调度的公平性?并不是所有节点资源配置一定都是一样的

  • 如何保证每个节点都能被分配资源?

  • 集群资源如何能够被高效利用?

  • 集群资源如何才能被最大化使用?

  • 如何保证 Pod 调度的性能和效率?

  • 用户是否可以根据自己的实际需求定制自己的调度策略?

四、Scheduler 解析 

调度主要分为以下几个部分:

  • 首先是预选过程,过滤掉不满足条件的节点,这个过程称为`Predicates`(过滤);

  • 然后是优选过程,对通过的节点按照优先级排序,称之为`Priorities`(打分);

  • 最后从中选择优先级最高的节点,如果中间任何一个步骤有错误,就直接返回错误。

`Predicates` 阶段首先遍历全部节点(高版本可配置),过滤掉不满足条件的节点,属于`强制性`规则,这一阶段输出的所有满足要求的节点将被记录并作为第二阶段的输入,如果所有的节点都不满足条件,那么 Pod 将会一直处于 Pending 状态,直到有节点满足条件,在这期间调度器会不断的重试。

所以我们在部署应用的时候,如果发现有 Pod 一直处于 Pending 状态,那么就是没有满足调度条件的节点,这个时候可以去检查下节点资源是否可用。

`Priorities` 阶段即再次对节点进行筛选,如果有多个节点都满足条件的话,那么系统会按照节点的优先级(`priorites`)大小对节点进行排序,最后选择优先级最高的节点来部署 Pod 应用。

五、优选预选策略详解  

首先,客户端通过 API Server 的 REST API 或者 kubectl 工具创建 Pod 资源。API Server 收到用户请求后,存储相关数据到 etcd 数据库中,调度器监听 API Server 查看还未被调度(bind)的 Pod 列表,循环遍历地为每个 Pod 尝试分配节点,这个分配过程就是我们上面提到的两个阶段:

  • 预选阶段(Predicates),过滤节点,调度器用一组规则过滤掉不符合要求的 Node 节点,比如 Pod 设置了资源的 request,那么可用资源比 Pod 需要的资源少的主机显然就会被过滤掉。

  • 优选阶段(Priorities),为节点的优先级打分,将上一阶段过滤出来的 Node 列表进行打分,调度器会考虑一些整体的优化策略,比如把 Deployment 控制的多个 Pod 副本尽量分布到不同的主机上,使用最低负载的主机等等策略。

经过上面的阶段过滤后选择打分最高的 Node 节点和 Pod 进行 `binding` 操作,然后将结果存储到 etcd 中 最后被选择出来的 Node 节点对应的 kubelet 去执行创建 Pod 的相关操作(当然也是 watch APIServer 发现的)。

六、scheduler 调度框架 

1、Sort 扩展用于对 Pod 的待调度队列进行排序,以决定先调度哪个 Pod,Sort 扩展本质上只需要实现一个方法 Less(Pod1, Pod2) 用于比较两个 Pod 谁更优先获得调度即可。

2、Pre-filter 扩展用于对 Pod 的信息进行预处理,或者检查一些集群或 Pod 必须满足的前提条件,然后将其存入缓存中待 Filter 扩展点执行的时候使用,如果 pre-filter 返回了 error,则调度过程终止。

3、Filter 扩展用于排除那些不能运行该 Pod 的节点,对于每一个节点,调度器将按顺序执行 filter 扩展;如果任何一个 filter 将节点标记为不可选,则余下的 filter 扩展将不会被执行,调度器可以同时对多个节点执行 filter 扩展。

4、 Post-filter 是在 Filter 扩展点的全部节点都被过滤掉了,在没有合适的节点进行调度的情况下,才会执行 PostFilter 扩展点,如果启用了 Pod 抢占特性,那么会在这个扩展点进行抢占操作,可以用于 logs/metircs。

5、 PreScore 扩展会对 Score 扩展点的数据做一些预处理操作,然后将其存入缓存中待 Score 扩展点执行的时候使用。

6、 Score扩展用于为所有可选节点进行打分,调度器将针对每一个节点调用每个Score 扩展,评分结果是一个范围内的整数,代表最小和最大分数。在 normalize scoring 阶段,调度器将会把每个 score 扩展对具体某个节点的评分结果和该扩展的权重合并起来,作为最终评分结果。

7、Normalize score扩展在调度器对节点进行最终排序之前修改每个节点的评分结果,注册到该扩展点的扩展在被调用时,将获得同一个插件中的 score 扩展的评分结果作为参数,调度框架每执行一次调度,都将调用所有插件中的一个 normalize score 扩展一次。

8、 Reserve是一个通知性质的扩展点,有状态的插件可以使用该扩展点来获得节点上为 Pod 预留的资源,该事件发生在调度器将 Pod 绑定到节点之前,目的是避免调度器在等待 Pod 与节点绑定的过程中调度新的 Pod 到节点上时,发生实际使用资源超出可用资源的情况(因为绑定 Pod 到节点上是异步发生的)。这是调度过程的最后一个步骤,Pod 进入 reserved 状态以后,要么在绑定失败时触发 Unreserve 扩展,要么在绑定成功时,由 Post-bind 扩展结束绑定过程。

9、 `Permit` 扩展在每个 Pod 调度周期的最后调用,用于阻止或者延迟 Pod 与节点的绑定。Permit 扩展可以做下面三件事中的一项:

  • approve(批准):当所有的 permit 扩展都 approve 了 Pod 与节点的绑定,调度器将继续执行绑定过程;

  • deny(拒绝):如果任何一个 permit 扩展 deny 了 Pod 与节点的绑定,Pod 将被放回到待调度队列,此时将触发 `Unreserve` 扩展;

  • wait(等待):如果一个 permit 扩展返回了 wait,则 Pod 将保持在 permit 阶段,直到被其他扩展 approve,如果超时事件发生,wait 状态变成 deny,Pod 将被放回到待调度队列,此时将触发 Unreserve 扩展。

10、`WaitOnPermit`扩展与 Permit 扩展点配合使用实现延时调度功能(内部默认实现的)。

11、 `Pre-bind`扩展用于在 Pod 绑定之前执行某些逻辑。例如,pre-bind 扩展可以将一个基于网络的数据卷挂载到节点上,以便 Pod 可以使用。如果任何一个 `pre-bind` 扩展返回错误,Pod 将被放回到待调度队列,此时将触发 Unreserve 扩展。

12、 `Bind`扩展用于将 Pod 绑定到节点上:

  • 只有所有的 pre-bind 扩展都成功执行了,bind 扩展才会执行;

  • 调度框架按照 bind 扩展注册的顺序逐个调用 bind 扩展;

  • 具体某个 bind 扩展可以选择处理或者不处理该 Pod;

  • 如果某个 bind 扩展处理了该 Pod 与节点的绑定,余下的 bind 扩展将被忽略。

13、 `Post-bind`是一个通知性质的扩展:

  • Post-bind 扩展在 Pod 成功绑定到节点上之后被动调用;

  • Post-bind 扩展是绑定过程的最后一个步骤,可以用来执行资源清理的动作。

14、 `Unreserve`是一个通知性质的扩展,如果为 Pod 预留了资源,Pod 又在被绑定过程中被拒绝绑定,则 unreserve 扩展将被调用。Unreserve 扩展应该释放已经为 Pod 预留的节点上的计算资源。在一个插件中,reserve 扩展和 unreserve 扩展应该成对出现。

以上就是本文的全部内容,如果喜欢就点个关注吧,我们会持续更新更多精彩内容!

相关推荐

企业出海,如何构建支撑全球业务的数据与 AI 平台?

当企业业务进入不同国家和地区,数据与 AI 能力也需要随之布局:当地业务产生的数据需要及时处理,AI 应用需要连接相应的数据与计算资源;总部则需要掌握全局资产、统一关键标准,并组织跨区域协作。近年来受到关注的“主权 AI”(Sovereign AI),进一步凸显了企业对 AI 部署与运行的需求。企业在建设 AI 平台时,需要统筹考虑数据管理、访问权限、治理规则、基础设施与运营管理,明确。集散架构,正是围绕这组需求展开的一种架构选择。

datacreating的博客 238

拿什么拯救你 我的画布

链路越长,人工比对的成本越高。可当这张网被放进浏览器或 App,规模一大,画布就开始吃力:打开要等,拖一下卡住,松手之后画面才缓慢跟上,内存占用也一路上涨。通过展开、拖动和搜索定位,用户可以在同一张图上从全局看到细节,不必把业务拆成多张局部图,再来回切换、拼接关系。这五层中,基础层提供页面运行和计算所需的能力,工具库层负责画布与布局,引擎层处理流程图和血缘图各自的业务规则,应用层最终呈现为项目、运维和血缘三类画布。大图性能的价值,就是让用户留在同一张图上,把整体关系看全,把关键链路看完,把具体问题查清。

datacreating的博客 236

告别“数据沼泽”,拥抱“活水湖”:数新智能基于CyberEngine与Apache Paimon的新一代数据湖仓架构

数据不再只是静态存储,它正在变成流动的“水”。今天,我们正式向大家介绍基于CyberEngine大数据平台的新一代数据湖解决方案,它为企业构建灵活、实时、统一的“活水湖”数据底座。本期聚焦基于 CyberEngine 与 Apache Paimon 的新一代数据湖仓架构,解析其如何告别数据沼泽、实现实时入湖与跨存储自由,为企业构建“活水湖”提供实践参考。在CyberEngine的加持下,基于Paimon构建的数据湖成为了一汪真正的“活水湖”,既拥有数据湖的灵活性,又具备数据仓库的高性能与事务能力。

datacreating的博客 287

DataX 深度解析:异构数据同步的核心设计与实现原理

本期我们将深度解构数新智能「开源技术」系列之——开源离线数据同步工具 DataX,其他相关文章可移步专栏合集查看。作为大数据体系建设的基础工具,DataX 以 Framework+Plugin 核心设计破解异构数据源同步的 N*N 链路难题,是企业数据治理的重要抓手。本文将从架构设计、执行流程、插件开发等维度拆解其技术内核,提炼实操要点,为技术从业者提供可落地的参考思路。

datacreating的博客 459

赋能某跨境智慧物流:基于 AWS Graviton 的全栈数据平台实现 25% 成本节省

数新智能通过将 自研的云原生数据底座CyberEngine 与 业界领先的 AWS Graviton 自研芯片 进行全栈深度集成,不仅解决了客户在成本与性能上的燃眉之急,更为其构建了面向未来的数据核心竞争力。这为整个平台奠定了高性价比的基石。我们深信,真正的技术价值,在于将底层硬件的强大潜力,通过领先的软件平台转化为切实的业务成果。数新智能的解决方案核心,是将 AWS Graviton 处理器的原生优势 与 CyberEngine 数据底座的云原生能力进行深度耦合,实现从硬件到软件的全栈协同优化。

datacreating的博客 576

数新智能 CyberData 现已全面支持 AWS Graviton 处理器

重要提示: 无论客户使用的是传统 x86 架构实例还是新一代 ARM 架构的 Graviton 实例,CyberData 都能提供完全相同的功能特性和用户体验,确保服务的一致性和可靠性。通过此次架构升级,我们能够利用 Graviton 处理器带来的卓越性价比和能效,这不仅提升了服务的整体性能,也使我们能够更可持续地运营,并长期致力于为客户提供更优质的服务。发布同步性: 所有新版本、新功能及漏洞修复均同步发布至 x86 和 ARM 架构,不存在任何发布时间差异。起始支持版本:CyberData 5.4.1。

datacreating的博客 175

CyberData 数据平台版本升级:信创深化、安全升级与全链路智能管控革新

为响应国家信创战略部署,满足企业数字化转型中的数据安全与高效管理需求,数新智能 CyberData 数据平台完成核心能力迭代升级。本次升级聚焦国产化适配深化、数据安全防护强化、建模能力拓展、标准管控智能化及资产体系重构五大核心方向,同步优化多维度操作体验,为企业提供更安全、高效、灵活的数据全生命周期管理解决方案。01 强化国产化适配,拓宽生态支持边界CyberData 持续深化与国产数据库的融合适配,完成平台信创化升级,进一步拓宽生态支持范围:· 核心数据库信创化落地:将业务底层数据库全面替换为国产主流数据

datacreating的博客 451

CyberEngine 在云上大数据计算降本方面的实践和能力

随着云计算与大数据技术的深度融合,越来越多企业选择将大数据计算负载迁移至云端,以享受弹性扩展、按需使用的核心优势。但随之而来的,是云上资源配置不当、闲置浪费导致的成本高企问题,成为制约企业数字化转型效益的关键瓶颈。作为深耕大数据与云计算领域的技术服务商,数新智能依托自研 CyberEngine 产品,构建了一套通过资源优化实现云上大数据计算降本增效的标准化能力,无需定制开发即可适配各类企业场景,本文将深度拆解其核心产品化策略与实践逻辑。

datacreating的博客 614

数新智能 CyberEngine 大数据引擎管理平台焕新升级

在平台易用性上,对平台的日志管理、资源管理等模块进行了“重组”,更加贴合运维人员使用习惯,提供便捷清爽的使用体验,另外,CyberEngine平台从诞生之日起就为国内的信创用户提供了良好的支持能力,除了支持国产的ARM架构CPU机型外,对国产的操作系统和中间件也都进行了充分的适配,此次的发布信创能力又进一步得到了提升;基于AWS平台的弹性伸缩能力:支持绑定和管理EKS集群,对EKS集群的弹性伸缩能力支持,根据业务的资源使用需求快速的完成Node的弹性扩缩容,极大的优化企业用户对于资源的利用效率。

datacreating的博客 698

倒计时3天,四大行业嘉宾携出海解决方案重磅来袭

背景亮点:曾就职于新加坡科技,康柏电脑,通用汽车,爱立信,诺基亚,Linaro 非营利组织 (Linux for ARM),Ubuntu,Vantiq 等企业。:曾就职于新加坡科技,康柏电脑,通用汽车,爱立信,诺基亚,Linaro 非营利组织 (Linux for ARM),Ubuntu,Vantiq 等企业。1 月 24 日,由数新智能、CCF、华为云联合主办「智联生态 智启全球 —— 数据为帆,AI 为舵,共创出海新路径」Data+AI 技术出海主题论坛,热度再升级!:高金 数新智能解决方案总监。

datacreating的博客 904

倒计时 5 天!Data+AI 技术赋能零售出海主题峰会嘉宾重磅官宣

本次演讲将聚焦 OceanBase 如何助力中国企业应对全球化挑战,实现高效、安全的跨境数据管理,实现降本增效、提升运维效率、保障业务连续性,同时更好的满足 AI 智能业务需求,为企业在国际市场的开拓筑牢数据根基。1 月 24 日,由数新智能、CCF、华为云联合主办「智联生态 智启全球 —— 数据为帆,AI 为舵,共创出海新路径」Data+AI 技术出海主题峰会,将落地杭州东新瑞莱克斯酒店!陈燕,亿企赢海外税产品总监,从事海外税十余年,曾实施过多家上市公司海外税,范围覆盖亚洲、美洲、澳洲等。

datacreating的博客 387

CyberScheduler —— 打破数据调度边界的核心引擎

作为数新智能 CyberData 产品的调度引擎, CyberScheduler 以“全场景适配、全链路可控、全架构兼容”为设计理念,从触发机制、依赖管理、统一编排、部署能力到高可用架构,构建了一套覆盖企业数据调度全生命周期的解决方案。当前,企业采用多云(阿里云、华为云、谷歌云、AWS云、私有云等)和多计算引擎(Spark、Flink、Doris、ClickHouse、MaxCompute等)架构已成常态,但不同云厂商、不同引擎的调度工具碎片化,导致数据管理效率低下、运维成本高企。

datacreating的博客 783

Compaction in Apache Iceberg

iceberg的有一个好处是,通过快照可以做 time-travel,verion rolback, 快照中的 manifest files不会被删除。job、task执行失败,可能会导致写入了部分数据,这些数据没有任何关联任何快照,因此也不能用正常的方式删除他们,因为没有任何关联关系。但流写入时,会出现很多新的小文件,删除过期文件可以将这些文件数据删除,但是处理不了 manifest 文件。除了压缩小文件,还做了排序,这意味着最小/最大过滤的好处将会更大(扫描的文件越少,速度越快)

datacreating的博客 831

CyberAI多模态数据平台焕新升级!七大核心功能解锁高效管理新体验

数新智能一站式多云AI原生数智平台升级,新增多模态数据管理功能。

datacreating的博客 848

The Life of a Read/Write Query for Apache Iceberg Tables

本文以读写查询生命周期为核心,解析 Iceberg 表的处理逻辑。当前快照中已经存在的 manifest file,跟新的一起,写入到 manifest list中,以及manifest file 的路径和统计信息。在这个 manifest list中,包含了所有 manifest file 的路径,以及每个文件的信息,如每个分区的 lower和upper等。merge-on-read,生成新的更新/删除/插入 数据文件,读取时会忽略旧的文件,只有更新的数据在内存中,占用内存会减少。

datacreating的博客 1207

Data engineering at Meta

揭秘 Meta 如何通过 UPM 流水线管理、分析库集成及自动化监控,构建支撑千亿级日活的高效数据链路,展现湖仓架构、流批融合及云原生设计的工程化落地经验,为企业数据智能建设提供可复用的技术蓝图。facebook 每天会产生 几百P 的数据,用户行为,代码变更,这个框架就用来实时分析这种变化,并提供开发人员展示。每个表都按照 ds 分区,也就是 YYYY-MM-DD 分区的,一般是数据产生的时间,也有其他方式分区的。内部维护了一个分支,做了一些定制化修改,也会定期合并开源分支,同时也会提交修改到开源。

datacreating的博客 893

Data Ingestion: Architectural Patterns

在数据驱动的时代,数据摄取是构建高效数据生态系统的基石。Data Integration Challenges,因为是一个数据库来管理 OLAP、OLTP,如果数据源种类很多,就不好处理,需要跨数据源查询,带来复杂度。Handling Push Failures,pull失败了只要重试即可,但是push失败了 分析平面感知不到,需要设计高可用,高并发的 push流系统。本质上来说,data ingestion 就是把运营平面的数据,同步到 分析平面中,这样就可以解锁 分析平面的所有能力了。

datacreating的博客 1156

“数”风流人物|从手搓Hadoop到智能数据平台构建,数新智能CTO原攀峰的“自我突破”

本文是数新智能 CTO 原攀峰接受 IT168 专访的完整内容,字里行间藏着我们对 “智能数据平台” 的核心思考与落地答案。无论你是正在搭建数据平台的技术管理者,还是想探索 AI 时代数据价值的从业者,这篇深度访谈都值得一读。

datacreating的博客 163

BTrace

从动态追踪工具如 Btrace、Arthas 的 retransform 能力,到 JDB 调试,再到 JDK 内置的 VisualVM、JFR,以及 JProfiler、MAT 等性能分析工具,还有分布式监控工具、火焰图等,它们共同助力开发者高效定位问题、优化系统性能。· arthas 使用了:Instrumentation.retransformClasses(),会替换整个类,风险高。· btrace 使用了:java.lang.instrument,只是在关键函数中注入了额外信息,风险低。

datacreating的博客 480

云环境中的日志收集和处理方案

在云环境中,高效的日志收集与处理是系统监控和运维的关键。本文围绕《云环境中的日志收集和处理方案》展开,先介绍日志收集的两种方式,再聚焦处理环节,探讨写入 kafka、共享存储、S3 等路径,分析使用 raft 组日志集群及 NewSQL 的方案,最后结合 Spark 端调度进行总结,为云日志管理提供多维度技术参考。SPARK_EXECUTOR_ID ,driver端需要手动设置,executor 是自动设置上的。根据当前的节点 hash,定位到环的一个为止,然后顺时针处理,这样每段由不同节点处理。

datacreating的博客 776

PyTorch

在深度学习领域,PyTorch 以动态图机制和简洁易用的特性,成为科研与工程落地的热门框架。本文围绕《PyTorch》展开,从基础操作切入,通过 numpy 与 tensor 实例演示数据处理核心逻辑,深入解析 Torchvision 数据加载、图像处理及常用功能。结合卷积原理、损失函数设计、梯度计算等关键模块,详解网络构建与优化方法,搭配可视化工具与分布式训练技巧,为读者呈现从基础语法到高阶应用的完整知识图谱,助力快速掌握 PyTorch 核心技术栈。

datacreating的博客 912

OpenLDAP研究

在企业目录服务领域,OpenLDAP凭借开源、灵活的特性备受青睐。本文围绕《OpenLDAP研究》,从剖析其底层架构入手,详解实用命令与核心配置信息,展示web控制台便捷管理方式,还会梳理相关文档资源,助你全面掌握OpenLDAP的运行逻辑与使用技巧。这里存储的 kerberos 的 keytab 实际是。经过了 ASN.1 加密,包含了一些其他信息。树状的层级结构,比如组织的划分。按照 DNS 来划分层次。OpenLDAP系列文档。再做了 base64。

datacreating的博客 596

LevelDB SSTable模块

如果写成功,则将 pending_index_entry 设置为true,后面再写新的块,Add 流程的时候就会用到这个变量。匹配的话,则读取这个数据块,跳转到对应的位置,具体处理逻辑是一个回调函数,回调函数内处理 key,value。上一个块的最后一个 key,和当前要写入的(也就是后面一个块的第一个 key),计算这两个 key非分割。先 new 一个固定大小的buffer,然后读进去,再 CRC检查,并确定压缩类型,看是否要解压。分割的key就是 “the r”,正好比"the qu…

datacreating的博客 583

Agent 狂飙时代,真正的 “限速器” 藏在数据里:为何说Data&AI 数据基础设施是泥泞路到高速路的密钥

打造面向业务的数据服务与资产门户: 构建数据中台体系,将底层数据加工为易用的主题数据模型和数据服务,建立数据资产门户,为业务方提供数据目录、自助分析工具和统一的数据服务出口,赋能业务团队进行探索式分析和数据创新,真正实现数据驱动的业务增长。同时,高质量、易访问的数据资产更好地赋能了业务团队的自助分析和精细化运营,直接推动了海外业务收入的增长。为落实集团数字化战略,打破内部数据壁垒,充分挖掘数据价值,并通过数据赋能业务增长,集团构建了中心化的一站式数据开发治理平台,以支撑战略目标的实现。

datacreating的博客 674

LevelDB 辅助工具类

如果编码值 1 « 7 <= v < 1 « 14,需要两个字节编码,第一个字节使用1 + v的低7位,表示需要查看下一个字节,下一个字节使用0 + v的高7位,表示不需要查看下一个字节;首先调用 Add,将 key进去,将所有的key直接拼在一起,比如 aa、bb、cc、dd,拼在一起就是aabbccdd,中间没有分割。如果小于等于1KB,则分配一个4KB的块,插入到vector中,从4KB的块上分配相应的内存;一开始的插入会放到 lru 链表中,如果 ref++,则会放到 in_use 链表中。

datacreating的博客 789

LevelDB 多版本和压缩

VersionSet是一个版本集,里面保存了Version的一个双链表,其中有一个Version是当前版本,因为只有一个实例,还保存了其它的一些全局的元数据,Dummy Version是链表头;最后利用两层的输入文件,在不扩大level i+1输入文件的前提下,查找level i层的有key重叠的文件,结果为蓝线标准的文件,构成最终的输入文件;利用level i层的输入文件,在level i+1层找寻有key重叠的文件,结果为绿线标注的文件,构成level i,i+1层的输入文件;

datacreating的博客 578

哈尔滨工业大学教授苗东菁:AI Agent 与多模数据库

在这种方式下,我们认为随着智能体服务的实例越来越多,有7千个、8千个、1万个、100万个,数据更新的压力以及多模型的更新的压力,跟现在会是大不相同的,因为现在很多场景人工去生成数据的速度肯定不如智能体的速度。在这里面,还有在我们看到的是文档还有订单的表达的数据,还有在智能体的经验里检索的时候,有RAG的数据,同时在智能体工作的时候,还会有对这些数据反向的更新。我们在调研中看到一些资料,举一个非常有意思的真实的例子,尽管它从某种意义上来讲,还不算是特别理想的智能体,更多的还是智能工作流。

datacreating的博客 830

Building An Elastic Query Engine on Disaggregated Storage

本文探讨了在分离式存储架构上构建弹性查询引擎的关键技术。针对传统shared-nothing架构的资源利用率低、弹性不足等问题,提出了基于云环境的存储计算分离方案。系统采用四层架构:中心化服务层、计算层、分布式临时存储层和持久数据存储层。重点研究了临时存储系统设计(采用内存-SSD两级缓存)、资源弹性策略(延迟一致性hash)及多租户支持方案。实验数据显示75%的只读查询缓存命中率超过80%,验证了架构有效性。文章还讨论了未来优化方向,包括更细粒度的资源调度和多租户隔离机制。该研究为云环境下的弹性数据查询提

datacreating的博客 833

中国计算机学会杭州分部副主席朱霖潮:多模态大模型的研究进展与未来

这种交互模式本质上构建了一个动态演进的Token处理体系:环境状态被编码为输入Token,模型生成的行动指令作为输出Token,而环境反馈又形成新的输入Token,构成持续流动的交互流。技术演进表明,新一代模型正从早期的单一能力专精(如GPT系列的语言理解、DALL·E的图像生成)发展为多模态协同的智能体系,其核心优势在于实现了意图理解与内容创作的无缝衔接。相较于单模态的理解或生成任务,这种多智能体协作系统需要处理更复杂的时空约束和资源分配问题,其技术难点主要在于实时决策的准确性和多主体协调的一致性保障。

datacreating的博客 1049

华为云云服务高级顾问叶正晖:华为对多模态大模型的思考与实践

我们大模型的架构的趋势,还是要从以前的单一模态走向多模态大一统,在未来的趋势下,从2021年的Vision Transformer到2022年的Whisper大模型再到2024年的Sora,整个过程里面从以前的视觉到语音到混合,再到生成大模型的一个统一。我们把视觉认知专项打开看一下,其实视觉认知专项在原来的基础多模态大模型中,经过海量的数据的训练,10000+通用及行业实用标签,包括场景标签,关系标签、行为标签都在这里面。华为的盘古多模态大规模的模型,它是一个层次融合的一个架构。三是全模态的大模型。

datacreating的博客 1003
上一篇: 代码覆盖率最佳实践
下一篇: HBase 串行复制
数新智能
数新智能 数新智能官方账号 数新智能官方账号
博客等级 码龄5年 408粉丝 110原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值