政务系统整合、烟草数据中台、企业知识库、异构迁移和数据库安全，看上去是五类不同项目，背后却有同一个问题：数据能力分散在不同系统、不同数据库和不同工具里，任何一次扩容、分析、迁移或审计，都要重复建设。

山东腾安信息位于济南，长期面向山东政务及企业数字化场景提供数据库产品、解决方案与运维服务。近日，在 TiDB 社区活动青岛站，山东腾安信息分享了这些能力收拢到同一条主线上的实践——让数据库从存储组件，变成可调度、可分析、可迁移、可保护的数据治理底座。

山东腾安信息科技有限公司数据库负责人 李冲

第一步不是集中数据，而是收敛治理对象

山东省政务协同平台包含公共服务、接入集成、交办事项、自动巡检、直播点播、工单、敏捷开发、会议组、工作督办、咨询聚合、工作台和全局搜索等 12 套业务系统。

• 改造前，各系统分别建设数据库及高可用方案，MySQL 主从、读写分离、单机实例以及其他数据库类型并存。监控、备份、补丁、账号、容量与应急流程都要分别维护，系统数量的增长直接放大了运维复杂度。

• 改造后，12 套系统按重要性、负载和敏感等级分组，由两个 TiDB 集群承接。集群 A 面向核心与高敏业务，配置更高等级的计算、存储和保障资源；集群 B 承接普通与弹性业务。每套集群基于 7 台虚拟机部署 TiDB Server、TiKV、PD等组件，在物理或资源层面保持必要隔离。这样做没有追求“所有系统塞进一个集群”，而是在收敛运维对象与控制故障域之间取得平衡。

  • 

统一底座并不等于平均分配资源。TiDB 资源管控能力允许平台按核心、普通、批处理等业务组配置 RU 配额、优先级与突发策略：高优先级业务获得保障配额，普通业务在稳定配额之外可以借用空闲资源，批处理则在竞争时限流或排队。平台由此能够回答“谁先用、用多少、突发时谁让路”，共享集群才从技术上的共用，变成业务上可承诺的多租户服务。

最终，运维对象从 12 套数据库收敛为 2 个集群，监控、备份、变更和技术口径得到统一，同时保留了按业务等级隔离资源的空间。真正被减少的，不只是机器数量，而是重复设计、重复配置和重复排障。

从系统整合走向实时数据服务

聊城烟草的数据中台，进一步说明了统一底座如何服务业务。机房综合监管平台、物料管理系统和门禁系统的部分数据原本分散在不同系统中，关联分析容易受数据孤岛影响。项目将这些数据采集到 TiDB，经过整合、标准化、质量校验与清洗后，为监管驾驶舱、业务查询、BI 报表和数据服务 API 提供统一数据来源。

这套架构的关键是让同一份逻辑数据承担两类工作。交易、点查和事务请求主要由 TiKV 行存承接；TiFlash 列存通过 Raft Learner 异步复制数据，用于报表、探索分析与并行计算；TiDB Server 根据查询特征统一路由。业务团队不需要自行维护从行存到列存的同步链路，也无需在交易库与分析库之间反复搬运数据。

数据库在这里不再只是系统汇总后的落库位置，而成为实时数据服务层：上游系统持续写入，治理流程统一处理，下游可以按需查询、看板展示或调用 API。数据整合与分析之间的链路被压短，平台才能从“汇总历史”转向“支撑当前决策”。

当关系数据与语义检索放在一起，知识库更容易进入业务

在同一数据底座之上，山东腾安信息建设了“眸数智能知识库”。平台覆盖“问知”“问数”、智能体和模型管理等能力，可导入文档、URL 与手工录入内容，通过 RAG 完成检索增强问答，也可以连接数据库或表格数据进行分析，并在私有化环境中对接企业内部模型与渠道。

知识库最值得关注的并非功能数量，而是关系查询与向量检索的结合。业务权限、知识库状态和用户关系适合用 SQL 过滤，语义相似度则依赖向量近邻搜索。TiDB 让两类条件作用于同一份业务数据：系统可以先按登录用户可访问的知识库类型过滤，再按语义相似度排序，而不必先查关系库、再调用另一套向量数据库接口。权限过滤也可以贯穿召回、重排和答案引用。

一次典型检索会经历问题改写与意图识别、向量与关键词双路召回、候选合并去重、Rerank 交叉重排，再把 Top 3 至 Top 5 的上下文交给大模型生成答案。底层向量搜索使用 HNSW 索引。基于这一链路，知识库不仅输出可引用、可追溯的问答，还可以生成结构化报告、PPT，调用业务 Agent，展示地图信息或按规则进行合同审查。数据库因此从“保存知识切片”走到“参与答案质量与权限控制”。

底座要可用，还必须解决迁移与安全

统一平台的前提，是旧系统能够低风险进入新架构。山东腾安信息将异构迁移拆解为连续性、异构性、一致性、可观测和可回退五个问题，并通过 TiDTS 迁移平台把一次性的专家操作编排成可重复流程。控制面统一维护源端与目标端连接、任务配置、状态和告警；结构同步负责表名、字段、类型、主键、自增与索引转换，全量通道完成历史数据搬迁，增量通道继续追平业务变化。

平台采用容器化交付，可覆盖 MySQL、MariaDB、TiDB、PostgreSQL、Oracle、SQL Server、瀚高等源端，并提供 DB2 实例接入。任务看板展示进度、延迟、同步量、失败 SQL 与日志。迁移由此不再是“把数据搬过去”，而是一条可以检查、恢复、审计和切换的交付链路。

进入统一底座后，另一个问题随之出现：每一次数据库访问是否都能被识别、约束、保护和留痕。DBNginx 将高可用网关放在人员、应用、第三方工具与数据库实例之间，把连接入口变成治理入口。网关可按身份与终端识别访问方，控制账号、表、字段、SQL 和访问频率，对敏感字段实施透明加解密与动态脱敏，对高风险语句阻断或进入审批，并记录主体、SQL、结果与处置证据。

从迁移到访问，治理逻辑形成了一条完整链路：数据如何进入、结构如何转换、增量如何追平、上线后谁能访问、能看到什么、异常如何告警，都由平台能力承接。数据库统一的意义因此不止于运维方便，更在于规则能够被一致执行。

一套底座的价值，是让能力只建设一次

从政务协同平台的 12 套系统，到聊城烟草的数据中台与知识库，再到 TiDTS 和 DBNginx，这些实践看似跨度很大，最终都落在同一套方法上：把弹性、高可用、事务、分析、向量检索、迁移编排和访问治理等共性能力下沉，让上层系统不再各自重复建设。

但“统一”从来不意味着单一。两个集群按业务等级隔离，资源组按优先级调度，TiKV 与 TiFlash 分担不同负载，关系查询与向量检索各取所长，迁移和安全又由专门的控制面与网关承接。真正成熟的数据底座，不是用一个组件包办所有事情，而是以统一规则组织不同能力，并让每一种能力都能被观测、验证和治理。

当数据库从单个应用的后台走向平台级底座，选型问题也随之改变：不再只是比较某项功能是否存在，而要判断它能否把分散的运维对象收敛起来，能否让数据在交易、分析与智能之间连续流动，能否让迁移和安全成为可重复的工程。山东腾安信息的实践提供了一个清晰答案——数据库的下一站，不只是存得更多、查得更快，而是让数据能力真正成为组织可复用的基础设施。