-
让 AI Agent 真正理解业务：云器 Semantic View 如何提供统一语义与可信数据上下文
👨🏻💻 作者：云器Lakehouse 产品负责人郭天琪“上个月各区域的收入是多少？”对接企业数据库后，AI Agent 很快就能生成 SQL、返回数字，甚至附上一段分析。但对数据负责人来说，还需要追问：它用的是下单金额、实收金额，还是财务确认收入？按下单时间还是支付时间统计？退款算在哪个月？这些问题，单靠表名、字段名和数据类型回答不了。SQL 能执行，说明语法和对象引用通过了检查；业务口径是否正
-
面向 Agentic AI，NineData 适配飞腾处理器，助力多云信创数据统一治理
近日，玖章算术（浙江）科技有限公司旗下 NineData 云原生智能数据管理平台，顺利完成与飞腾处理器的产品兼容性联合认证。经过全维度测评，双方产品运行稳定、适配效果优异、整体运行高效稳定，可实现无缝集成与深度协同。
-
甲骨文的新型Lakehouse工具瞄准企业AI的盲点
甲骨文为其Lakehouse架构制定了一个雄心勃勃的发展方向。不过，仍有若干环节尚待完善。最终的考验在于：将所有这些工具整合在一起，能否真正为数据团队减轻工作负担，并使AI系统产出更可靠的结果。
-
数据库自治与 AI 运维：让数据库学会自我调优
导语：当业务规模、实例数量和参数组合一起膨胀，传统“人盯人”的数据库运维方式正在逼近人力上限。数据库自治（Autonomous Database）与 AI 运维（AIOps）试图把调优、巡检、故障定位这些重复性工作交给系统自身完成。本文梳理这一方向的核心逻辑、能力边界与落地路径。需要说明的是，本文未附带具体产品实测数据，涉及趋势判断的部分为基于公开技术方向的推演，依据现有素材判断，不构成对任何特定产品的性能承诺。 一、为什么数据库运维需要“自治” 数据库运维长期面临三个结构性矛盾： 复杂度与人力不匹配 ：一套生产数据库涉及参数配置、索引设计、执行计划、连接池、存储布局、备份策略等多个维度，可调项数量远超单个 DBA 的精力覆盖范围。 故障定位依赖经验 ：慢查询、锁等待、资源争抢往往表现为“症状在数据库、根因在上
-
数据库高可用与容灾：如何保障业务连续性？
导语 对大多数在线业务而言，数据库往往是整个系统中最难替换、也最不容有失的一环。应用服务可以水平扩容、可以快速回滚，但数据库一旦出现长时间不可用或数据丢失，业务连续性就会直接受到冲击。因此，“高可用”与“容灾”不是两个可以临时补上的运维动作，而是需要在架构设计阶段就纳入考量的基础能力。 需要说明的是，本文未附带具体产品版本、实测数据或厂商案例，以下内容为围绕主题的方法论梳理。 先厘清两个概念：高可用不等于容灾 在实际讨论中，这两个词经常被混用，但它们解决的问题并不相同。 高可用（High Availability） ：关注的是“故障发生时能否快速恢复服务”，主要应对单点故障、进程崩溃、节点宕机等局部问题，目标通常是缩短不可用时间。 容灾（Disaster Recovery） ：关注的是“大范围灾难下能否保住数据
-
中国证券登记结算有限责任公司2027年度校园招聘公告
中国证券登记结算有限责任公司2027年度校园招聘公告中国证券登记结算有限责任公司（简称“中国结算”）是经国务院同意，中国证监会批准，于2001年3月30日设立的不以营利为目的的企业法人。作为我国资本市场具有系统重要性的金融基础设施，中国结算承担中央对手方、中央登记系统、证券结算系统等核心职能，秉承安全、高效的基本原则，持续健全完善集中统一的登记结算体系，为登记结算系统各类参与者参与场内场外、公募私
-
国产数据库出海：东南亚与中东市场的技术适配难点
导语：国产数据库的国际化已从“能不能卖出去”进入“能不能稳定跑起来”的阶段。东南亚与中东是两条被反复提及的出海路线，但两地的基础设施条件、合规环境与业务负载差异显著。本文围绕技术适配这一维度，梳理国产数据库进入这两类市场时需要重点解决的问题。本文不引用具体产品版本、性能数据或客户案例，仅做技术方向的框架性讨论。 一、出海讨论的重心正在从“产品能力”转向“落地适配” 过去几年，国产数据库在国内市场的推进主要围绕替代与迁移展开，评价体系相对集中在兼容性、迁移成本和单机/集群性能上。一旦进入海外市场，评价体系会迅速扩展： 数据库不再是孤立组件，而是嵌入当地云环境、网络条件与运维体系中的一环； 客户对 SLA、数据驻留、审计能力的要求往往先于对功能特性的关注； 交付团队无法像国内一样快速到场，远程可运维性成为硬指标。
-
从数据底座到 AI 知识底座，云器在 DACon 带来了什么？｜附演讲材料
10 月 23—24 日，云器科技亮相 DataFun DACon 2026 北京站，联合创始人兼 CTO 关涛在大会主论坛分享 AI 时代的知识与本体思考，获得现场听众的积极反馈；云器同时在现场设立展位，介绍 AI Lakehouse 的产品能力与实践方向，围绕 AI 数据加工、业务语义与企业知识应用，与参会者展开交流。关涛：原始数据不等于 AI 可用的知识在《AI 时代，知识与本体的演进与思考
-
WMS库存账怎么建模：库存余额表加库存流水表的双表设计
结论：WMS里库存数量不要直接改，正确做法是“每一次出入库只写一条流水，余额由流水累计得到”，同时保留一张余额表用于快速查询。这样账实不符时才能逐笔回溯，而不是对着一个被改过的数字猜原因。一、为什么不能直接改库存数量最常见的设计是一张库存表，入库就加、出库就减。问题在于：出现差异时没有历史，无法判断是重复扫码、漏扫、还是并发覆盖。双表设计把“结果”和“过程”分开：流水表只增不改，余额表是流水汇总后
-
数据同步工具 NineData 社区版 V5.4.0：新增 16 条复制链路，增量复制性能大幅优化
NineData 社区版 V5.4.0 本次更新主要围绕：数据库 DevOps 新增 GBase 8A、Snowflake 数据源适配，敏感数据保护与 SQL 任务覆盖更多数据库类型，治理与审批体验持续增强；数据复制与对比新增 16 条链路，累计支持 715 条，Kafka 目标端支持 Debezium 格式，增量复制性能优化；AI Agent 新增结构设计与发布 Skill，ChatDBA 交互与后台任务能力增强；基础服务新增脚本自定义通知渠道，丰富告警与通知投递方式。
-
Agentic AI 时代，数据库将扮演什么角色？
导语：当 AI 从“回答问题”走向“自主完成任务”，系统的瓶颈往往不在模型本身，而在数据。数据库正从被动的存储后端，变成 Agent 感知、记忆与行动的基础设施。 一、从“调用工具”到“自主执行”，数据库的位置变了 Agentic AI 的核心特征，是模型能够围绕目标进行多步规划、调用工具、观察结果并迭代行动。这一循环对数据层提出了三类新需求： 状态与记忆需要持久化 ：多轮任务中的中间结论、用户偏好、历史决策，不能只存在于上下文窗口里。 行动需要可验证的数据接口 ：Agent 调用业务系统时，最终落地往往是读写数据库，而非仅生成文本。 过程需要可追溯 ：谁在什么时间、基于什么数据做了什么操作，必须可审计。 换句话说，数据库不再只是“应用背后的存储”，而是 Agent 与真实世界之间的接口层。 二、数据库在 Ag
-
Agentic AI 时代，用户对数据底座的需求正在发生什么变化？
导语 当 AI 从“被动回答问题”走向“主动拆解任务、调用工具、连续执行”，数据底座面对的就不再只是人和报表，而是一群会自己发起查询、自己串联步骤、自己反复试错的 Agent。需求的重心也随之迁移：从“把数据存好、查得快”，转向“让 Agent 敢用、用得对、用得住”。 需要说明的是：本文未附带具体产品数据、版本信息或实测结论，以下判断属于基于 Agentic AI 技术特征的推演性分析。 一、从“人读数据”到“Agent 调数据”，接口层先变 传统数据底座的使用者是人：分析师写 SQL、看板做展示、业务方读结论。Agentic AI 引入后，第一类高频“用户”变成了程序化的 Agent，它对数据底座提出的第一层要求是 可被机器稳定调用 。 接口要结构化、语义化 ：Agent 依赖 API、工具描述和元数据来理
-
乐观锁还是悲观锁：高并发下数据一致性的取舍逻辑
导语：并发控制的核心问题不是“哪种锁更先进”，而是“冲突概率、失败代价与系统吞吐之间如何平衡”。乐观锁与悲观锁代表了两种截然不同的假设：前者假设冲突很少，后者假设冲突随时发生。理解这两种假设背后的成本结构，才能在高并发场景下做出合理取舍。 一、两种锁，两种世界观 乐观锁与悲观锁并不是具体的数据库特性，而是两类并发控制策略的统称。 悲观锁 的假设是：并发冲突大概率会发生。因此在读取数据时就加锁，保证从读到改的整个过程中，其他事务无法介入。典型实现包括数据库的 SELECT ... FOR UPDATE 、行锁、表锁，以及分布式环境下的 Redis 分布式锁、ZooKeeper 临时节点等。 悲观锁 的代价是明确的：持锁期间其他请求被阻塞，锁的粒度越大、持有时间越长，系统的并发能力下降越明显。在极端情况下，还可能因
-
从后端架构视角看 AI 落地：向量化（Embedding）与向量数据库的工程实践
导语：在上一篇文章中，我们聊到了如何用 DAG 调度引擎把大模型接入企业级业务流。但在 RAG（检索增强生成）架构中，大模型并不是凭空知道你们公司的内部文档的。我们必须把文本“喂”给它。今天，我们就来扒一扒这条流水线的核心基石：向量化（Embedding）与向量数据库。作为传统后端老兵，我们不需要去死磕底层微积分，我们需要的是：懂原理、会选型、能扛住高并发。一、 文本怎么变成向量？（Embeddi
-
数据库+AI系列选题邀请函：“Agentic AI时代，数据底座准备好了吗?”
2026年AI Agent迎来爆发式发展，企业的数据使用模式、业务诉求发生转变，这对数据库带来了全新挑战与机遇。我们策划了数据库+AI系列选题，重点探讨Agentic AI时代的用户需求变化、数据底座变革、智能运维，诚邀数据库厂商、DBA等用户专家参与选题，一起奔赴数智未来。
-
FDE 革命：像咨询顾问一样驻场，数据库落地的新打法
导语：数据库项目失败，往往不是败在 SQL 写不出来，而是败在“技术方案”和“业务现场”之间那道看不见的沟。FDE（Forward Deployed Engineer，前置部署工程师）这一角色，正在把咨询顾问式的驻场工作方法带进数据库落地场景。本文讨论这套打法的逻辑、边界与判断标准。 一、先说清楚：本文讨论什么、不讨论什么 需要提前说明的是，本文 没有配套的客户案例、性能数据或产品版本信息 ，以下内容属于方法论层面的讨论，涉及具体效果的部分均标注为“依据现有素材判断”，不作为实证结论。 本文聚焦三个问题： 数据库落地为什么需要“驻场”这种工作方式； FDE 与传统的数据库实施顾问、售前工程师、售后支持有什么区别； 一套可操作的 FDE 工作方法应该包含哪些环节。 二、数据库落地的真实痛点：不是技术不够，是上下文
-
冷热数据分层：把钱花在真正热的那部分数据上
导语 在存储成本持续攀升、数据规模不断膨胀的今天，很多团队面临的并不是“存不下”，而是“花得不值”。大量访问频率极低的数据，长期占据着高性能、高成本的存储资源，而真正被频繁读取的热数据，反而没有得到足够的资源倾斜。冷热数据分层要解决的核心问题只有一个： 让每一份数据待在与其访问特征相匹配的存储层级上，把钱花在真正热的那部分数据上。 一、为什么需要冷热分层 数据并不是均匀“热”的。在绝大多数业务系统中，访问分布往往呈现明显的长尾特征：少数数据被高频访问，大量数据在写入后很快进入“沉睡”状态，只在审计、回溯、合规等场景下偶尔被读取。 如果所有数据都放在同一层高性能存储上，会带来两个直接后果： 成本浪费 ：为几乎不被访问的数据支付了与热数据相同的高昂单价。 资源挤占 ：冷数据占用高性能介质与缓存，间接影响热数据的读写
-
Agentic AI 时代，数据库的重要性更高了吗？
导语： 当 Agentic AI 从“会聊天”走向“会办事”，系统的瓶颈正在从模型能力转向状态、记忆与行动的一致性。数据库不再只是后台存储，而更像是智能体的“长期记忆”和“行动账本”。但这一判断需要分清场景：我们无法给出统一的量化结论，只能从架构逻辑上讨论数据库角色正在发生的变化。 一、从“无状态推理”到“有状态执行” 传统 LLM 应用大多是一次性推理：用户提问，模型生成回答，会话结束后状态基本清空。Agentic AI 则不同，它需要多步规划、调用工具、观察结果、修正计划，并在多个回合之间保持目标与上下文。 这意味着系统必须回答几个工程问题： 上一轮执行到了哪一步？ 哪些工具调用已经成功，哪些需要重试？ 中间结果如何被后续步骤引用？ 多个 Agent 或子任务之间如何共享状态？ 这些问题的本质是 状态管理
-
Agentic AI 时代，如何做好数据语义层？
导语 当 AI 从“回答问题”走向“自主执行任务”，数据语义层的角色正在发生变化。它不再只是 BI 报表背后的指标字典，也不只是数据团队内部的口径管理工具，而正在成为 Agent 理解业务、调用数据、执行动作的基础设施。 一、为什么 Agentic AI 把语义层推到台前 传统数据分析链路中，语义层主要解决“同一个指标在不同报表里口径不一致”的问题，使用者是人。而在 Agentic AI 场景下，使用者变成了会自主规划、多步调用工具的 Agent，语义层要承担三件新任务： 可发现 ：Agent 需要知道“有哪些数据、哪些指标、哪些动作可用”，而不是靠人临时指路。 可理解 ：Agent 需要拿到带业务含义的定义、维度、粒度、约束，而不只是表名和字段名。 可安全执行 ：Agent 会真正发起查询甚至写入操作，语义层
-
OLTP
OLTP 数据库的核心技术解决的是：“在极端并发下，如何用最短的时间，把一笔数据绝对安全、绝对准确地写到磁盘上，并能随时精准查出来。” 而 OLAP 解决的是：“如何从海量数据里把一堆数据捞出来做大计算。”对应到 OLTP（联机事务处理）系统，其背后的数据库核心技术是一套极其庞大且严密的体系。如果拿银行的交易系统（如核心、信贷、支付）来对标，OLTP 数据库的核心技术主要体现在以下几个层面：一、
