本文围绕知识体系的核心生命周期组织：生成 → 验证 → 审批 → 存储 → 检索 → 维护 → 评测。每个阶段包含标准、实施方式和度量方法。原有决策保留编号，嵌入对应阶段。

1. 证据与置信度说明

1.1 依据性质

• 直接依据：标准、规范或官方文档明确规定或描述了相关要求、能力，且规定内容与本方案的该条设计逐项对应。
• 方向性依据：权威来源支持该设计的必要性与方向，但未规定具体结构、顺序或取值。引用此类来源时不得声称"标准如此要求"。
• 工程推导：由一个或多个可信来源组合形成的落地方案，不代表来源逐字规定了该架构。
• 自拟：本方案提出的结构，无外部来源，其有效性只能通过 §9 评测体系自证。

核心抽象

【中等】RDD、DataFrame 和 Dataset 有什么区别？⭐⭐⭐⭐

🎯 目标等级：L2-L3 ｜ ⏱ 建议用时：10 min ｜ 🏷 标签：Spark / 核心抽象

💎 关键结论

RDD 是最底层的分布式数据抽象（类型安全但无优化）；DataFrame 引入了 Schema 信息使 Catalyst 优化器可做列裁剪、谓词下推等优化（非类型安全）；Dataset 兼顾两者（类型安全 + Catalyst 优化），但仅支持 Scala/Java。生产中最常用 DataFrame（配合 Spark SQL）。

架构设计

【中等】Flink 的架构设计是怎样的？⭐⭐⭐⭐

🎯 目标等级：L2 ｜ ⏱ 建议用时：10 min ｜ 🏷 标签：Flink / 架构

💎 关键结论

Flink 采用 Master-Worker 架构：JobManager（Master）负责作业编排与资源管理，TaskManager（Worker）负责实际计算。核心设计思想是「原生流处理 + 有状态计算 + 精确一次容错」——所有数据被视为无界/有界流，批处理只是流处理的特例（有界流）。相比 Spark 的微批模型，Flink 的逐条处理天然支持更低延迟。

简介

【简单】Dubbo 是什么？为什么使用 Dubbo？⭐⭐

🎯 目标等级：L2 ｜ ⏱ 建议用时：5 min ｜ 🏷 标签：Dubbo / 概述

💎 关键结论

Dubbo 是一款高性能、轻量级的开源 Java RPC 框架，核心提供三大能力：面向接口的 RPC、智能容错与负载均衡、服务自动注册与发现。理由：它以接口粒度屏蔽远程调用细节，并提供开箱即用的微服务治理能力。

⚡ 记忆卡片

口诀：调用靠代理、流量靠均衡、服务靠注册
关键词：RPC／负载均衡／服务发现
链路：接口代理屏蔽调用细节 → 注册中心连接提供者与消费者 → 容错与负载均衡保障高可用

混合云

【困难】混合云架构中如何解决跨云数据一致性与网络延迟问题？⭐⭐⭐⭐

🎯 目标等级：L4 ｜ ⏱ 建议用时：25 min ｜ 🏷 标签：混合云 / 数据一致性 / 网络延迟

💎 关键结论

混合云跨云数据一致性的核心矛盾是网络延迟与分区容错不可消除（CAP 定理），解法是分层治理：强一致场景用同步复制 + 分布式事务（如跨云 XA/TCC），延迟敏感场景用异步最终一致 + 消息队列（如 CDC 同步 + 补偿机制），读密集场景用多活读 + 缓存一致性协议（如 Redis Cluster 跨副本）；网络延迟通过专线/SD-WAN 降低 RTT、数据就近读写（分区部署）、异步化与批量合并减少跨云往返。

【困难】如何设计现代数据湖仓（Lakehouse）架构？Iceberg / Hudi / Delta Lake 的选型依据与 schema evolution 机制？⭐⭐⭐⭐

🎯 目标等级：L4(困难) ｜ ⏱ 建议用时：25 min ｜ 🏷 标签：Lakehouse / Iceberg / Hudi / Delta Lake

💎 关键结论

湖仓一体融合数据湖的灵活性与数据仓库的 ACID 事务能力，Iceberg 适合通用分析，Hudi 擅长流式更新，Delta Lake 深度绑定 Spark 生态。

模型部署与服务化

【中等】主流的 LLM 推理框架有哪些？vLLM、TGI、Ollama、llama.cpp 各自的特点是什么？⭐⭐⭐⭐

🎯 目标等级：L2-L3 ｜ ⏱ 建议用时：10 min ｜ 🏷 标签：AI 工程化 / 推理框架

💎 关键结论

"vLLM 主打高吞吐 PagedAttention，TGI 深度集成 HuggingFace 生态，Ollama 面向本地一键部署，llama.cpp 是纯 CPU/混合推理的轻量标杆——选型需匹配场景：生产服务选 vLLM/TGI，本地开发选 Ollama，边缘设备选 llama.cpp。"

基础理论

【困难】Transformer 架构的核心组件有哪些？Self-Attention 的计算过程是怎样的？⭐⭐⭐⭐

🎯 目标等级：L3 ｜ ⏱ 建议用时：15 min ｜ 🏷 标签：LLM / Transformer

💎 关键结论

"Transformer 由 Multi-Head Self-Attention + FFN + LayerNorm + Positional Encoding 构成；Self-Attention 本质是 softmax(QKᵀ/√d)V 的加权聚合。"

高并发系统设计

【困难】如何设计秒杀库存扣减的跨层一致性方案？⭐⭐⭐⭐⭐

🎯 目标等级：L3-L4 ｜ ⏱ 建议用时：25 min ｜ 🏷 标签：Redis / MQ / DB / 一致性 / 限流

💎 关键结论

秒杀库存扣减横跨前端→网关→Redis→MQ→DB 五层，核心原则是"Redis 防超卖、MQ 保 DB、对账兜底"。前端静态页 + CDN 挡读流量，网关限流 + 答题削峰，Redis Lua 原子扣库存，扣减成功的请求才进 MQ 异步建单，DB 写入量 = 库存量而非请求量。三层对账（Redis-MQ-DB）兜底任何一层的不一致。

业务系统

【困难】如何设计一个秒杀系统？⭐⭐⭐⭐⭐

🎯 目标等级：L3-L4 ｜ ⏱ 建议用时：20 min ｜ 🏷 标签：系统设计 / 秒杀

💎 关键结论

秒杀应对的是瞬时海量请求，思路是「稳、准、快」：前端静态页 + CDN 挡读流量，答题 + 限流削峰，扣库存用 Redis + Lua 原子操作保证不超卖，只有扣减成功的请求进 MQ 异步建单。最终 DB 写入量等于库存量，而不是请求量。

⚡ 记忆卡片

• 口诀：静态挡、答题缓、限流削、Lua 扣
• 关键词：瞬时海量请求 ／ 超卖 ／ 分层过滤 ／ Redis+Lua ／ 异步建单
• 链路：前端静态 + CDN → 答题限流 → Redis Lua 扣库存 → MQ 削峰 → 异步建单 → 对账兜底