隐语Kuscia正式发布 1.0.0 版本,实现支持 Hive 数据源,支持 envoy 日志进行异常分析等功能
Kuscia 是一款基于 K3s 的轻量级隐私计算任务编排框架,旨在屏蔽异构基础设施和协议,并提供统一的隐私计算底座。隐语·数据可信流通技术社区是融合可信数据空间、隐私计算、数据元件等多项数据流通利用基建技术设施在内的开源社区,致力于推动前沿技术探索、技术标准体系共建与产业应用场景共创,促进高质量数据资源流通利用与价值释放。
近期隐语Kuscia 正式发布 1.0.0 版~本次更新都有哪些具体要点?一起来看看吧~
更新要点
- 新增
Delete DomainData
物理文件接口:能够有效清理长期未使用的数据,帮助用户释放宝贵的磁盘空间,提升系统存储效率。 - 支持
Hive
数据源:成功拓展了数据源类型,新增了对 Hive 数据源的支持,进一步丰富了数据接入的多样性,满足用户更广泛的数据管理需求。 - 持通过
envoy
日志对Kuscia task
进行异常分析:增强了任务异常情况下的排查功能,提供更便捷的异常诊断工具,显著简化了用户在遇到问题时进行故障排查的操作步骤,提升系统稳定性和用户体验。
Kuscia
- **[Feature] **支持 Hive 数据源(alpha版本 外部贡献 @peter5232 )
- [Feature] 新增 Delete DomainData 物理文件接口 (外部贡献 @peter5232)
- [Feature] Kuscia Task 资源及连通性前置检查(外部贡献 @MiKKiYang)
- [Feature] 支持通过 envoy 日志对 Kuscia task 进行异常分析
- ** [Feature]** Kuscia images import 支持校验镜像架构是否匹配当前 Kuscia架构(alpha版本 外部贡献 @exyb)
- ** [Feature] **KusciaDeployment 默认加上反亲和性(PodAntiAffinity)配置,多副本时,尽量部署到不同节点
- **[Feature] **Kuscia DomainData 支持 PostgreSQL 代理数据源连接参数配置
- **[Changed] **Kuscia PostgreSQL 数据源数据代理写入优化
- [Changed] runp 运行时 kill pod, agent 发送 sigterm 信号量
- **[Fixed] **Kuscia 使用 PostgreSQL 作为元数据存储时连接异常问题
- **[Dosc] **Kuscia 文档完善
欢迎点击「阅读原文」点亮 GitHub Star 🌟 ,不错过「隐语SecretFlow」的每一次发版动态。
https://github.com/secretflow/kuscia
本文由隐语社区统一发布,欢迎大家点 Star

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
-
上一篇
基于 Apache Pulsar 构建统一消息流 PaaS 平台
作者:翟佳,AscentStream 谙流科技联合创始人兼 CEO,Apache Pulsar PMC 成员,Apache软件基金会成员。 注:此篇 《基于 Apache Pulsar 构建统一消息流 PaaS 平台》为翟佳老师在 Apache PulsarMeetup 北京 2024 大会演讲的转录文字,经社区志愿者赵国瑞 ronnie 编辑修改完成,强烈推荐阅读。 Apache Pulsar 社区简介 近年来,消息流和分布式基础设施领域的进步吸引了广泛的关注。自 20 世纪 80 年代和 90 年代 IBM 等公司的早期产品,到 2000 年代初的开源项目,再到 2007 年大数据和分布式系统的兴起,消息系统经历了几轮技术革新。Kafka、RocketMQ 等分布式消息系统的崛起,正是为了满足用户日益增长和变化的需求。 在这样的技术演进背景下,Apache Pulsar 应运而生。它起源于 2012 年的雅虎实验室,并于 2017 年正式对外开源。Pulsar 的诞生恰逢云原生时代的到来,它凭借先进的设计和强大的功能,迅速赢得了开源社区和众多技术专家的青睐,成为了分布式消息系统领域...
-
下一篇
详解多智能体架构:以 Open Deep Research 项目为例
资料来源: 火山引擎-开发者社区 背景 业界 AI 大佬们最近对上下文进行了很深入的一番讨论(“争吵”): 1.Cognition 的看法:反对多智能体,推崇上下文工程 认为当前 LLM 在处理长上下文和主动沟通方面尚不成熟,强行引入 MAS 会导致上下文割裂、决策分散等风险,反而弱化系统可靠性。 主张先构建单体系统并加强上下文工程,再考虑多智能体结构。 2.Anthropic 的看法:探索并行优势,但依赖上下文工程 其多智能体研究系统采用 orchestrator‑worker 模式,多个 Agent 分工并行处理,适合用于大范围信息检索与整合任务。 但强调必须通过上下文工程实现状态共享与记忆同步,否则容易失控。 3.LangChain 的折中立场:灵活架构,任务导向选择 认为共同点是 上下文工程的重要性;而多 Agent 在“读取(Read)”型任务中效果更佳,“写入(Write)”型任务仍建议采用单 Agent。 推出 LangGraph 等编排工具,实现对 LLM 调用上下文的精细控制,支持混合架构。 | 阶段/角色 | 核心观点 | 优势 | 局限性或挑战 | | --- ...
相关文章
文章评论
共有0条评论来说两句吧...