上一章把 Doris 的存储与执行机制摆完，这一章换到使用侧：一个 SaaS 会员运营平台要拿 Doris 做人群圈选，建表的每个参数该怎么定、标签回流怎么灌、圈选查询为什么跑得动却不对。全文以一个 2 亿会员、500 家商户的示例场景为底座，所有耗时与体积数字来自作者本机 Apache Doris 2.1.11 单 FE 单 BE 集群的实测，机制解释以 2.1 官方文档为准；场景参数是示例设定，不是某个生产系统的真实数据。
一个分析型数据库要回答两件事：数据怎么存，数据怎么算。Doris 的架构分 FE 与 BE 两层——FE 管元数据与查询编排，BE 同时承担存储与计算（存算一体）。正文先铺全貌，再分别把「数据的存」（列存、排序键与前缀索引、分区/分桶、副本与 Compaction）和「数据的算」（MPP 并行、向量化执行、Pipeline/PipelineX、优化器）讲清，然后停在存与算之间的契约——数据模型——上，说明它为什么同时约束存储语义和查询能力，最后把 Stream Load 如何把数据「存」进来走一遍。全文以 Apache Doris 2.1.x 为准，机制均来自 2.1 官方文档；3.x 起的存算分离等新形态不在本文范围内。
上一次 Run 停下来之后，进程退出、内存清空，第二天用户回来说「确认」，凭什么找回那份纲领、对应到哪个动作、恢复到哪个进度？checkpoint 持久化、审批绑定到不可变动作版本、业务幂等键防重放——三条缺一条都恢复不了。
从一次退货咨询出发，亲手把查询和政策片段变成向量，计算余弦相似度并取 Top-K，理解语义检索能解决什么、又不能替你保证什么。
Agent 会调用模型和工具，但用户怎样实时看到它正在做什么？从 HTTP、SSE 与 WebSocket 的边界出发，亲手跑通一条 Agent Run 事件流。
赚到钱靠机会，守住选择权需要现金流、资产与风险管理。
从退货政策问题出发，跑通企业 RAG 知识助手的最小链路。
AI 让答案变廉价，真正稀缺的是提出好问题的能力。
AI 时代追不上新工具并不可怕，重要的是保住判断、实践与连接。
RAG 答非所问，往往从文档分块就已经埋下了问题。
