Day 30｜毕业综合实战：构建 Agent-Ready 实时数据平台

课程阶段：第六阶段｜湖仓与 AI
毕业项目： 电商经营分析 + 订单 CDC + 日志检索 + 企业知识库 RAG + Doris MCP 问数
完整功能基线： Apache Doris 4.1.3
稳定兼容基线： Apache Doris 4.0.8
MCP 基线： Doris MCP Server 1.0.0，MCP 2026-07-28
验收原则： 正确性、P99、稳定性、安全、可复现五项同时达标。

一、毕业项目要证明什么

前二十九天分别学习了数据库定位、架构、表模型、导入、索引、物化视图、查询内核、存储引擎、资源治理、运维、安全、湖仓、搜索和 MCP。Day 30 的任务是把这些能力组织成一套能够运行、能够验证、能够交接的系统。

项目最终回答四个问题：

业务是否得到稳定结果。 数据进入系统后，经营看板、订单状态、日志检索和知识问答都要达到约定时效。
系统行为是否能够解释。 每一项性能结论都要有 Explain、Profile、Metrics、日志或审计证据。
故障是否能够被控制。 节点、导入、查询、对象存储、权限和 Agent 调用出现异常时，平台要有止损和恢复路径。
交付物是否能够被复现。 版本、配置、数据集、脚本、结果、已知限制和回滚条件都应进入项目包。

毕业项目强调系统协同。功能列表很容易写得很长，业务链路仍可能断裂。例如表建得很漂亮，CDC 没有 Sequence；向量索引召回很好，ACL 在应用层过滤；Dashboard 单查询很快，高并发时却挤压实时写入；MCP 能执行 SQL，结果没有行数和字节上限。Day 30 要关闭这些链路间的缝隙。

二、项目业务背景与目标

假设一家多租户电商企业已有业务库、Kafka、数据湖和内部知识文档，希望统一建设实时数据平台。平台同时服务五类用户：

经营团队查看 GMV、订单量、买家数、渠道和地区趋势；
客服与订单 API 查询单个订单当前状态；
SRE 检索应用日志并沿 trace_id 定位异常；
员工通过 RAG 查询产品、运维和制度文档；
Agent 通过 Doris MCP Server 获取 Schema、执行受限查询、查看 Profile 和诊断集群。

项目目标值如下：

业务链路	目标
数据新鲜度	业务事件进入 Doris 后 30 秒内可查
核心 Dashboard	100 并发下 p95 ≤ 2 秒、p99 ≤ 5 秒
订单 Point Query	热缓存 p99 ≤ 100 毫秒
日志检索	近 7 天关键词检索 p95 ≤ 500 毫秒
RAG	Golden Set Recall@20 ≥ 0.85，权限过滤 100% 生效
MCP	只读；单次 ≤1000 行、≤1MB、≤60 秒
可用性	月度目标 99.9%
灾备	RPO ≤15 分钟、RTO ≤30 分钟

这些数值是项目验收目标，需要在自己的硬件和并发条件下实测。官方文档提供架构和能力说明，无法替代业务压测。

三、版本锁定与两套运行配置

截至 2026 年 8 月 18 日，Apache Doris 下载页标记 4.1.3 为 Latest、4.0.8 为 Stable。毕业项目希望覆盖 4.1 的 Vector、Wide Table V3、搜索增强等能力，因此完整功能配置锁定 4.1.3；生产组织若优先使用 Stable 分支，可以选择 4.0.8 兼容配置。

3.1 4.1.3 完整配置

适合课程答辩和新能力验证：

HNSW、IVF、IVF_ON_DISK 与量化评测；
Storage Format V3；
当前 4.1 的 Cache、Variant 和 Search 增强；
Doris MCP Server 1.0 能力探测后按实际可用 Child 调用。

3.2 4.0.8 稳定兼容配置

保持相同业务模型和数据合同，同时调整：

向量检索优先使用 HNSW；
跳过 4.1-only 的 IVF、部分量化和 V3 实验；
所有参数、系统表和 SQL 重新执行版本核验；
Agent 根据 Runtime Capability Manifest 隐藏不可用 Child。

项目包必须保存 SELECT VERSION()、FE/BE 列表、配置快照和 Release Notes 评审记录。任何回归都先区分版本变化、数据变化、统计信息变化和执行计划变化。

四、总体架构：实验模式与生产参考模式

生产参考模式采用存算分离：3 个 FE 提供 SQL、Catalog、Nereids、权限和调度；Meta Service 管理数据层元数据；多个 BE 组成 cg_write、cg_query 和 cg_batch；Storage Vault 指向 S3/HDFS；本地 SSD 作为 File Cache。湖上历史通过 Hive、Iceberg、Hudi 或 Paimon Catalog 接入。

实验模式可以复用 Day 5 的单集群环境。它能够验证 DDL、Stream Load、查询、索引、MV、Search 和 MCP 读链路。Compute Group、Meta Service、FoundationDB、对象存储抖动和多节点容灾需要独立环境。

三个计算组的职责建议如下：

Compute Group	任务	资源特征
`cg_write`	CDC、Routine Load、Compaction、Schema Change	高吞吐、高 IO
`cg_query`	Dashboard、API、Point Query、Search	低延迟、稳定尾延迟
`cg_batch`	ETL、历史回算、MV Refresh	高并行、允许 Spill、峰谷弹性

组内继续使用 Workload Group 管理 CPU、内存、并发、队列和 Spill。这样形成节点级硬隔离与进程内细粒度配额两层治理。

五、数据模型：状态、事件、明细、日志和知识文档分开设计

5.1 当前状态表

fact_order、dim_user 和 dim_sku 使用 Unique Key MoW。业务主键承担唯一身份，source_seq 处理 CDC 乱序。订单更新、删除和部分列更新都围绕同一主键合同展开。

fact_order 还启用 Row Store，服务订单详情 Point Query。它保留列存分析能力，同时降低整行返回时的列重组成本。

5.2 原始事件与明细

fact_order_item、order_status_event 使用 Duplicate Key，保留每一条明细与状态变化。事件表用于审计、漏斗、时序分析和问题追踪，不能被当前状态表替代。

5.3 日志与半结构化属性

app_log 保存时间、租户、服务、级别、trace_id、message 和 VARIANT attrs。service、level、trace_id 建结构化倒排索引，message 建全文索引。attrs 用于承接动态字段，常用属性可以在后续通过 Schema Template 固定类型。

5.4 知识库文档

docs_kb 保存正文、标题、标签、tenant、acl_group、有效期、Embedding Model、Version 和 content_hash。title/body 使用倒排索引，embedding 使用 ANN Index。RAG 查询必须在数据库中先执行 tenant、ACL、文档类型和有效期过滤。

六、分区、分桶与索引设计

订单和日志按日期分区，满足三类需求：

查询裁剪；
生命周期管理；
补数、删除和恢复的管理边界。

订单按 tenant_id + order_id Hash 分桶，让主键查询和订单明细关联保持稳定分布。日志可以 Random Bucketing，避免缺少稳定分桶键时产生倾斜。Bucket 数先根据单分区压缩量、目标 Tablet 大小、BE 数量和并行度估算，再通过 POC 校正。

索引设计遵循查询模式：

fact_order.user_id/status/channel：倒排索引用于高选择性过滤；
fact_order_item.sku_id：商品维度过滤与 Join 候选缩小；
app_log.message：全文检索；
docs_kb.title/body：全文与 BM25；
docs_kb.embedding：HNSW 或 4.1 的 IVF 系列；
Prefix、ZoneMap 和 Partition Pruning 继续承担自动裁剪。

索引会增加写入 CPU、存储和 Compaction 成本。上线前必须比较索引前后导入吞吐、索引大小、查询 p95/p99 和目标并发。

七、导入体系：每条链路都有独立的一致性合同

7.1 订单 CDC

业务库通过 Streaming Job 或 Flink CDC 写入 Unique Key 表。正确性由四部分共同保证：

源端主键
+ UPSERT
+ __DORIS_DELETE_SIGN__
+ Sequence Column

验收需要模拟旧状态晚到、同一事件重复、删除后重放和 Schema 增加字段。最终 Doris 当前状态必须和源库快照一致。

7.2 Kafka 事件与日志

订单事件和应用日志通过 Routine Load 持续消费。监控 Job/Task 状态、Kafka Offset、Lag、错误率和目标表行数。坏数据达到阈值时，任务可能暂停，Runbook 要包含排查、隔离和恢复步骤。

7.3 文件与历史数据

订单明细通过 Stream Load，使用唯一 Label 保证重试幂等。远端历史文件先通过 TVF 预览和抽样，再 INSERT INTO ... SELECT。Lake Catalog 中的三年历史可以继续联邦查询，近 90 天热点回灌内部表。

7.4 文档和 Embedding

文档先切 Chunk，再生成 Embedding。写入时同时保存 content_hash 和模型版本。Embedding 失败、维度不一致、NaN、零向量或 Hash 不一致的记录进入隔离区。样例包中的 16 维向量由哈希算法生成，只验证工程链路，不能用来评价语义检索质量。

八、数据质量：技术成功、数据成功和业务成功三层验收

Stream Load 返回 SUCCESS，只说明本批事务达到技术状态。平台还要继续验证：

技术成功：事务 VISIBLE、Loaded Rows、Filtered Rows、Label、Offset；
数据成功：总量、主键、金额、状态、NULL、时间范围、删除；
业务成功：Dashboard 口径、订单状态、检索可见性、RAG 权限。

建议建立每日对账：

源库订单数 / 金额
Doris 当前状态表订单数 / 金额
订单明细聚合金额
事件最终状态
湖上历史边界

差异不能直接修表。先记录源批次、目标分区、影响范围、补数 SQL、审批人和回滚方法。补数完成后重新收集对账和 Profile 证据。

九、经营看板：Async MV、统计信息和 Profile

核心 Dashboard 按日期、租户、渠道和状态聚合。直接扫描订单事实表可以作为基线，再创建 mv_daily_sales 预计算订单量、GMV 和买家数。

Async MV 是最终一致性结构，刷新 SLA 要写入业务合同。项目示例设置 5 分钟调度和 60 秒 grace_period 作为实验起点，真实环境应根据数据新鲜度和刷新资源重新设计。

验收分四步：

运行基线 SQL，保存 Explain 和 Profile；
创建并刷新 MV；
再次 Explain，确认 Materialized View Rewrite；
在冷缓存、热缓存和 100 并发下比较 p95/p99、CPU、Scan Rows 和 Bytes。

统计信息必须在大批回灌、分区替换和数据分布明显变化后重新核验。优化器估算和 Profile 实际行数差距过大时，先修统计信息，再考虑 Hint。

十、订单 Point Query 与高并发 Serving

订单详情请求采用：

Unique Key MoW
→ Row Store
→ 完整主键等值条件
→ Short-Circuit
→ Prepared Statement
→ Row Cache

客户端开启服务端 Prepared Statement 和连接池缓存。查询模板固定为 tenant_id + order_id，避免查询缺少完整主键后退回普通扫描。

POC 需要依次比较普通路径、Row Store、Short-Circuit、Prepared Statement 和冷热 Row Cache。记录 QPS、p50/p95/p99、FE CPU、BE CPU、连接池等待和混合写入下的尾延迟。

十一、日志检索与可观测性分析

SRE 使用以下条件组合：

时间分区
+ service_name
+ level
+ trace_id
+ message MATCH
+ attrs 路径

倒排索引先得到候选 RowID，随后读取必要列。message 的 Analyzer 需要根据中英文、错误码、堆栈和服务名评测。错误码与 TraceID 更适合精确索引，自然语言消息使用 unicode/chinese 分词和短语支持。

检索结果还可以进入 OLAP 聚合：按服务、错误类型、版本和地区统计趋势。这样“找到异常”和“分析异常规模”处于同一条 SQL 链路。

十二、湖仓边界：实时热数据和长期历史共存

内部表负责近 90 天实时分析、更新、高并发和搜索；Hive/Iceberg/Hudi/Paimon 保存长期历史。统一查询使用 catalog.database.table。

湖仓查询先验证分区、Manifest、文件和 Row Group 裁剪，再观察 Data Cache、Remote Read、对象存储延迟和 Shuffle。高频结果可以回灌内部表或建立 Async MV。JDBC Catalog 只访问小维表，避免大扫描压垮业务库。

十三、知识库 RAG：关键词、语义和权限同时生效

RAG 请求包含用户身份、租户、ACL、问题和 Query Embedding。检索分两路：

倒排索引 + BM25 返回关键词 Top-N；
ANN 返回语义 Top-N。

RRF 使用排名融合，避免直接相加不同量纲的 BM25 分数和向量距离。最终结果再做文档去重、版本优先、来源权威度和邻接 Chunk 扩展。

整个过程要记录 retrieval_version、embedding_model、候选 ID、BM25 Rank、ANN Rank、RRF Rank 和最终 Chunk。Golden Query Set 同时测 Recall@K、MRR、NDCG@K、Zero-result Rate 和安全过滤。

十四、AI Functions 与数据加工

AI Functions 适合在 SQL 内执行分类、抽取、摘要、翻译、脱敏和跨行聚合。毕业项目可以选择以下轻量场景：

对日志错误文本做类别抽取；
对客服反馈做情感与原因分类；
对一批告警生成摘要；
使用 EMBED() 生成文档向量并持久化。

模型调用需要保存 Provider、Model、Prompt Version、Source Hash、Token、Latency 和 Result Status。对同一内容反复调用会增加成本，因此优先做增量处理和结果复用。Dashboard 在线查询不应逐行调用外部模型。

十五、Doris MCP Server：Agent 工具层

Doris MCP Server 1.0 把公共工具面组织为 8 个 Domain 和 55 个精确 Child Capability。Host 先发现 Domain，再获取 Child、Schema、Availability 和 manifest_version，最后发起受限调用。

Agent 请求链：

MCP Host
→ Domain Discovery
→ Child Call
→ Capability Gate
→ Query Guard
→ Request-specific Doris Identity
→ Doris RBAC / Row / Column
→ Result Envelope / Audit

毕业项目只开放查询、Catalog、Profile 和必要诊断能力。查询统一限制只读、60 秒、1000 行和 1MB。未授权 Child 隐藏，不可用能力返回 reason_code，过期 Manifest 触发重新发现。

Prompt Injection 样例会在知识文档中要求 Agent 读取全部手机号。系统必须依靠 Scope、Query Guard、Doris RBAC、ACL、结果上限和审计拒绝该请求，不能把 SQL 黑名单当作唯一防线。

毕业综合实战

Agentic Analytics 展望