业务故事站
跨产品

迁移指南：从 Excel / 手工 SQL / 旧流程迁移

四类最常见的"旧世界"如何迁进这套平台：Excel 手工报表迁到 Foundry 指标口径、手写 SQL / BI 工具迁到 AIP NLQ、手工登录服务器部署迁到 Apollo GitOps、纸质 / Excel 情报整理迁到 Gotham 图谱 + 报告。每篇都给你量化对比与第一步动作。

数据工程师 业务分析师 运维工程师 情报分析员 迁移 共 4 个故事

能 / 不能速览

✅ 这套平台能做
  • Excel 多表合并 → Foundry 建模 + 指标口径，每天 2 小时报表降到分钟级
  • 手写 SQL / 拖拽 BI → AIP 一句话查数，SQL 可核对、过程有审计
  • 手工 SSH 拷包部署 → Apollo 期望状态 + DAG 门控 + 自动回滚
  • 纸质 / Excel 情报 → Gotham 图谱 + 实体解析 + 报告导出，3 天压缩到半天
⛔ 这套平台做不了
  • 没有一键"从 Excel 自动建模"：对象 / 指标仍需数据工程师配置
  • AIP 替代不了重度数据清洗：脏数据要先在数据源侧处理
  • Apollo 迁移不等同真实进程拉起：演示 Poller 仅拉取 / 上报
  • Gotham 迁移需要先建数据源与映射，不是"扔个 Excel 就出图谱"

适用角色

四类迁移分别对应四类岗位的日常工作：

  • 数据工程师：从 Excel / 脚本迁移到 Foundry 建模与管道。
  • 业务分析师：从手写 SQL / BI 报表迁移到 AIP 一句话查数。
  • 运维工程师：从手工服务器部署迁移到 Apollo GitOps。
  • 情报分析员：从纸质 / Excel 情报整理迁移到 Gotham 图谱 + 报告。

能力速览（迁移路径）

Excel → Foundry

把手工合并的报表迁成对象 + 指标口径，源头一份定义、处处复用，消灭"三份报表三个数"。

手写 SQL → AIP

把写 SQL / 拖 BI 的取数迁成自然语言，30 秒出数、SQL 可核对、审计可回溯。

手工部署 → Apollo

把 SSH 拷包迁成期望状态声明 + DAG 门控 + 自动回滚，发布从 2 小时降到 15 分钟。

纸质情报 → Gotham

把名单 / 关系的纸质与 Excel 整理迁成图谱 + 实体解析 + 报告，3 天工作量压到半天。

调整指南（迁移中怎么调整）

  • 迁移节奏：先做"影子运行"——新旧并行 2 周，用旧结果交叉验证新平台数字，再切换。
  • 口径对齐：迁移前先冻结口径定义（谁是 total_gmv、aov 怎么算），否则搬进去的口径还是乱的。
  • 权限同步：迁移账号 / 权限时逐个产品配 RBAC，别把旧系统的"全量管理员"习惯带进来。
  • 回退预案：旧文件 / 旧脚本保留只读快照至少 2 个发布周期，迁移出问题能回退。

做得好的场景

迁移指南最擅长"用数字证明值得迁"：
  • 量化对比：每天 2 小时 → 5 分钟、3 天 → 半天、2 小时发布 → 15 分钟，迁移收益可算账。
  • 低门槛起步：四类迁移都是"第一天就能做第一步"，不用大项目排期。
  • 留痕兜底：迁移过程有审计、有版本、有回退预案，老板敢批。

限制与不足

迁移要避开这几个坑：
  • 没有自动建模：Excel → 对象 / 指标需要数据工程师配置，不是上传即用。
  • AIP 不做清洗：脏数据、口径混乱要前置处理，AI 不会替你治病根。
  • Apollo 演示局限：Poller 不真实拉起进程，真环境迁移需挂载 ProcManager 并验收。
  • Gotham 需建源：情报迁移要先建数据源 + 映射 + 实体解析作业，不是扔文件出图谱。

场景故事

故事 1 财务小林：把每天 2 小时的 Excel 手工报表迁到 Foundry 指标口径
场景：报表迁移 角色：财务分析师 + 数据工程师 收益：每天 2 小时 → 5 分钟
背景
财务部小林每天要手工合并 6 张 Excel 汇总销售额：一张订单表、一张退货表、四张区域表，用 VLOOKUP 拼，月底还要再对一遍账。她觉得最痛苦的不是累，是"这个数对不对没人说得清"。
传统做法对比
以前每天 2 小时手工合并 + 月底 1 天对账，口径靠群消息对暗号，错一次改 6 张表；出了问题查不到源头。迁移后每天 5 分钟自助取数，口径一个定义，账对得上、源查得到。
角色
财务分析师（消费）+ 数据工程师（建模与指标定义）。
操作步骤
  1. 把 6 张 Excel 导出为 CSV，导入 Foundry 数据源
  2. 数据工程师在对象工作台建模 customer / order / product
  3. 指标管理定义 total_gmv、aov，统一"销售额"口径
  4. 小林用对象查询 / 语义检索自助取数，不再碰 Excel
  5. 新旧并行 2 周，用旧报表交叉验证数字
系统响应
数据源返回导入表结构数；对象创建返回 version；指标返回 formula 与 dimensions；对象查询返回统一口径下的数字（如 order 对象 5 条订单、total_gmv 可取数）。
结果洞察
两周并行验证一致后切到新流程：每天 2 小时降到 5 分钟，月底对账从 1 天降到 10 分钟。"口径对不上"的问题从"群里吵"变成"查指标定义"。
调整建议
迁移前先冻结口径定义再建模；给 region / status 加同义词提升语义检索命中。相关阅读：Foundry 入门、指标语义层。
动手试一试
尝试：Foundry 数据源导入一张自己的 CSV 表，本体工作台建对象，对象查询选它取数。预期结果：从"上传表"到"对象可查"十几分钟走通。
限制提示
没有"Excel 自动建模"，对象 / 指标需人配置；对象查询是轻量 OOL（单对象 ≤3 层）；demo 数据源每次启动重建，长期使用要接 PostgreSQL 正式源。
故事 2 数据分析师小赵：从手写 SQL / BI 工具迁到 AIP 一句话查数
场景：取数迁移 角色：业务分析师 收益：30 分钟 ~ 2 小时 → 30 秒
背景
数据分析师小赵每天要接十几个取数需求，每条要么写 SQL（30 分钟起步）、要么拖 BI 报表（学习成本高、口径各自为政）。他把高频需求迁到 AIP：业务同事直接在 /chat 问，他只在异常时出来核对 SQL。
传统做法对比
以前一条取数需求写 SQL 30 分钟 ~ 2 小时，每月口径对不上要返工 3~4 次；BI 报表要拖拽建模，新同事上手一周。现在一句话 30 秒出数，SQL 可核对不黑盒，审计可回溯。
角色
业务分析师（/chat 查询）+ 数据工程师（准备数据源与元数据）。
操作步骤
  1. 确认 aip_demo_warehouse 已注册并导入元数据
  2. 业务同事在 /chat 输入"查询所有订单"等高频问题
  3. 核对返回的 SQL 与结果，必要时修正问法
  4. 把高频问题沉淀为团队示例，新人直接点示例
  5. 定期查审计日志，统计"谁查了什么"
系统响应
返回 intent / confidence / sql / result / chart_type；异常时 SQL 一眼看出问题（如过滤条件写错）；审计记录 NLQ_QUERY 全量落库（query / sql / rows / result）。
结果洞察
取数需求从"排队等小赵"变成"自助 30 秒"，小赵的角色从"写 SQL 的"变成"核对 SQL 与治理口径的"。他每月省下约 60 小时，转而做数据质量与口径治理。
调整建议
重要数字务必核对返回 SQL；问不出就换直白关键词；把问法写进团队示例减少口径漂移。相关阅读：AIP NLQ 入门、安全治理。
动手试一试
尝试：AIP /chat 输入"查询所有订单"，看返回 SQL 与图表；再输入"查询华东地区订单的销售额"看聚合结果。预期结果：两类查询都能出数，SQL 透明可核对。
限制提示
意图识别是关键词规则，复杂 / 口语化问法命中不稳；Text2SQL 依赖外部 LLM，无 key / 离线中断；一次只查一个数据源，无跨源 JOIN。
故事 3 运维老周：从手工 SSH 拷包部署迁到 Apollo GitOps
场景：部署迁移 角色：运维工程师 收益：2 小时发布 → 15 分钟
背景
运维老周以前升级一次应用要 SSH 登录 5 台服务器，手工拷包、改配置、逐个重启，凌晨发布心惊胆战；环境被手改出漂移只能人肉 diff。他用 Apollo 把 demo-app 迁成期望状态管理，一次声明、批量分发、自动回滚。
传统做法对比
以前一次发布 2 小时、回滚靠记忆；5 台机器配置漂移只能靠人工核对，平均每月出 1~2 次"线上和预期不一样"。现在声明一次、DAG 门控分批放行、失败自动回滚、漂移自动收敛。
角色
运维工程师（期望状态登记 / 部署 / 回滚）；安全合规工程师负责 bundle 验签。
操作步骤
  1. 把应用结构写成期望状态 YAML（组件 / 依赖 DAG / 探针 / 策略）
  2. 登记 demo-app 并激活（v1.0.0）
  3. 发起部署到 spoke-01，看 DAG 分批放行（db → web）
  4. 部署失败走自动回滚；成功后漂移检测兜底
  5. 发布前对 bundle 做 SM3 + SM2 验签
系统响应
部署返回组件状态（pending → ready → synced）；漂移检测返回 JSON Patch diff；回滚返回新期望状态版本；bundle 验签返回签名校验结果（signer 白名单匹配）。
结果洞察
发布从 2 小时降到 15 分钟，回滚有版本兜底，漂移有 reconcile 收敛。"声明即期望"让 5 台机器只维护一份真相，不再逐台手工对齐。
调整建议
给动态字段配 ignore_paths 减少漂移误报；每次修复发新期望状态版本（单调版本号）保留回滚点。相关阅读：GitOps 入门、回滚与部署锁。
动手试一试
尝试：Apollo 发起部署 demo-app 到 spoke-01，推进到 synced；再到漂移检测体验 detect → reconcile。预期结果：DAG 分批放行 + 漂移收敛闭环。
限制提示
演示 Poller 仅拉取 / 上报，不真实部署进程（ProcManager 未挂载时不应用）；"Git 即真相源 + 自动 PR"属 P2；监控 / 告警 / 自愈属 V2。
故事 4 合规小周：从纸质 / Excel 情报整理迁到 Gotham 图谱 + 报告
场景：情报迁移 角色：情报分析员 + 合规顾问 收益：3 天整理 → 半天
背景
合规部小周每月要把 2000 条人员关系整理成 Excel 做反洗钱链路还原：VLOOKUP 拼接关系、肉眼找共同联系人、再花 2 天做 PPT 报告。他决定把这条流水线迁到 Gotham：数据接入 → 实体解析 → 图分析 → 报告导出。
传统做法对比
以前 2000 条关系人肉比对 3 天、VLOOKUP 链路易错、报告 PPT 2 天，出了结论复核困难。现在 CSV 导入 → 实体解析归并 → 最短路径 / 中心度 → 报告一键导出，半天完成，链路可引用。
角色
情报分析员（数据接入 / 图分析）+ 合规顾问（实体解析归并审核）。
操作步骤
  1. 在数据接入建一个 file_csv 数据源，导入关系名单
  2. 映射规则：记录 → 图节点 / 边，跑一次 Ingest
  3. 跑实体解析作业，处理 0.70~0.90 待审聚类
  4. 用最短路径 / 中心度还原资金链路，圈定枢纽
  5. 从数据生成报告并导出 PDF / DOCX 归档
系统响应
Ingest 返回批次与节点 / 边数量、fingerprint 去重；实体解析返回聚类分组与分数；最短路径返回路径数组；中心度返回榜单；报告返回导出文件（HTML / PDF / DOCX）。
结果洞察
3 天整理 + 2 天报告压缩到半天，链路每一步可复核、可引用。跨源同名自动归并替代了人肉 VLOOKUP，"同一个人的不同写法"不再漏检。
调整建议
迁移前先梳理实体字段与映射规则；0.70~0.90 待审聚类必须人工过一遍，别全自动合。相关阅读：多源融合、实体解析、情报报告。
动手试一试
尝试：Gotham 数据接入建一个 file_csv 源，跑一次 Ingest；到实体解析跑作业看聚类；再从数据生成一份简报导出。预期结果：CSV 变成图节点，聚类与报告都可导出。
限制提示
实体解析 AI 增强默认关闭（仅相似度算法 + 阈值带）；图存储单机内存邻接表 + JSON 落盘，大名单需分批；报告 PDF 无中文字体时退化为 ASCII，正式排版能力有限。

常见问题

四类迁移要按什么顺序做？

建议先迁"收益最大、风险最低"的：通常先 AIP 取数（30 秒见效、不碰数据源结构），再 Foundry 口径（需要数据工程师投入），再 Apollo 部署（影响发布流程），最后 Gotham（依赖前两者准备好的数据与人员）。

迁移会不会丢历史数据？

迁移是"加新流程"不是"删旧系统"：旧 Excel / 旧脚本 / 旧服务器保留只读快照至少 2 个发布周期；平台侧数据也建议接 PostgreSQL 正式源而非演示 SQLite（演示数据每次启动重建）。

迁移后能完全依赖 AI 查数吗？

不能全依赖。AIP 的意图识别是关键词规则、Text2SQL 依赖外部 LLM，重要数字必须人工核对 SQL。迁移建议配"人机分工"：日常取数走 AIP，核心报表 / 对外数字走人工复核。

迁移收益怎么量化给老板看？

用故事里的数字：每天 2 小时 → 5 分钟（报表）、30 分钟~2 小时 → 30 秒（取数）、2 小时 → 15 分钟（发布）、3 天 → 半天（情报）。先跑 2 周影子运行拿真实对比数据，再上会。

主题小结

一句话：四类迁移的共性打法 = 量化现状 → 影子运行 → 冻结口径 → 分产品迁移 → 保留回退。Excel 迁 Foundry、手写 SQL 迁 AIP、手工部署迁 Apollo、纸质情报迁 Gotham，每类都有第一天就能做的第一步，但都要记住边界：无自动建模、AI 需人工核对、演示数据不持久。