一、这篇到底在讲什么
从考试视角看，这一篇并不是把一堆新技术拼在一起，而是在讲两个扩张问题：
- 云原生在解决"应用怎么更快交付、更稳运行、更容易扩缩容"
- 大数据在解决"数据量上来之后怎么采集、存储、计算和服务化输出"
把它们放到一个真实场景里会更容易理解。以电商平台为例：
- 订单、支付、库存这些业务服务需要频繁发版、自动扩容、灰度发布，这是云原生问题
- 订单流、日志流、埋点流需要实时计算、离线分析、搜索检索，这是大数据问题
所以这一篇本质上是在回答两个问题：
- 应用规模扩大后，系统该怎么部署和治理
- 数据规模扩大后，系统该怎么存储和计算
二、知识点总述
1. 云原生知识点总览
云原生这一侧，案例题真正关心的知识点主要有 6 个：
| 知识点 | 核心作用 | 在案例题里的本质出题点 |
|---|---|---|
| 微服务 | 把大系统拆成可独立演进的小服务 | 为什么单体系统开始难以迭代和扩展 |
| 容器 | 统一运行环境，标准化交付 | 为什么环境不一致、部署慢、扩容慢 |
| Kubernetes | 大规模容器编排与自动化管理 | 为什么有了容器还不够 |
| 服务网格 | 统一处理服务间通信治理 | 为什么治理逻辑不能继续散在业务代码里 |
| DevOps / CI/CD | 缩短开发到上线的交付链路 | 如何把构建、测试、发布、回滚流程化 |
| 声明式 API | 用目标状态驱动平台自动收敛 | 为什么云原生强调"声明我要什么"而不是"手工执行步骤" |
这几个点不是并列孤立的，而是有因果关系的：
- 微服务让系统拆小了，但部署对象变多了
- 容器解决了部署对象怎么标准化打包
- K8s 解决了大量容器怎么自动调度和管理
- 服务网格解决了大量服务之间怎么统一治理
- DevOps 解决了这些服务怎么高频、稳定地交付
- 声明式 API 解决了平台如何按目标状态自动维护系统
也就是说，考试里如果题干同时出现"微服务 + 容器 + 自动扩缩容 + 灰度发布 + 服务治理"，本质上就是在考一个完整的云原生治理链，而不是单点名词解释。
2. 大数据知识点总览
大数据这一侧，案例题通常围绕 5 类知识点展开：
| 知识点 | 核心作用 | 在案例题里的本质出题点 |
|---|---|---|
| 分布式存储与计算 | 解决海量数据存储和并行处理 | 数据量上来后，单机为什么撑不住 |
| 批处理与流处理 | 分别解决离线分析与实时处理 | 实时性和准确性如何平衡 |
| Lambda / Kappa | 组织实时与离线链路的整体架构 | 要不要维护两套链路，如何处理重算 |
| 大数据组件选型 | 针对不同场景选择不同工具 | Kafka、HBase、ES、Spark、Flink 各自解决什么问题 |
| 数据仓库 / 数据湖 | 解决分析口径和原始数据沉淀问题 | 为什么有的场景强调建模，有的场景强调先接入 |
如果把它们串成一条数据链路，可以这样理解：
- 先有业务数据、日志数据、行为数据不断产生
- 再用消息队列或采集链路把数据接进来
- 然后落到分布式存储里保存
- 再用批处理或流处理引擎做加工计算
- 最后输出到报表、检索、推荐或实时看板
所以考试里大数据不是考"背 Hadoop 家族"，而是在考：面对不同数据特征和业务目标，架构应该怎样分层、组件应该怎么选。
3. 云原生和大数据之间的关系
很多人复习时容易把两部分分开记，但案例题里它们常常出现在同一业务背景下。
例如一个互联网平台可能同时存在：
- 业务服务层：订单、支付、库存等微服务跑在容器和 K8s 上
- 数据接入层：业务事件和日志进入 Kafka
- 实时计算层：Flink 处理订单流和监控流
- 离线计算层：Spark 生成离线分析结果
- 数据服务层：HBase 提供明细查询，ES 提供日志检索，数仓提供 BI 报表
因此你在考试里不能把"应用架构"和"数据架构"完全割裂。很多题目其实考的是：上层业务系统怎么云原生化，下层数据系统怎么大数据化，二者如何一起支撑业务增长。
4. 这一篇最重要的几个对比关系
这篇内容真正容易出题的，往往不是定义本身，而是相近方案之间的边界：
| 对比项 | 核心区别 | 案例题常见问法 |
|---|---|---|
| 容器 vs 虚拟机 | 轻量和交付效率 vs 强隔离和完整虚拟化 | 为什么新系统更适合容器化 |
| K8s vs 手工运维 | 自动编排和自愈 vs 人工管理成本高 | 为什么规模一大必须上编排平台 |
| 服务网格 vs 业务代码治理 | 治理能力下沉到基础设施 vs 每个服务重复实现 | 为什么服务多了以后治理会失控 |
| Lambda vs Kappa | 双链路兼顾实时和准确 vs 单链路简化架构 | 如何在准确性、复杂度、重算能力之间取舍 |
| HBase vs ES | 高吞吐随机读写 vs 检索与聚合分析 | 海量明细查询和日志检索该怎么选 |
| 数据仓库 vs 数据湖 | 统一口径分析 vs 原始多源沉淀 | 为什么企业往往两者并存 |
如果这些边界说不出来，案例题就容易从"知道技术名词"变成"不会落答案"。
5. 这一篇通常要求掌握到什么深度
系统架构师案例题在这一篇里，通常不要求你写源码级、协议级或底层实现级细节，但这不等于只写概念即可。它真正要考的是：你能不能把题干中的业务问题翻译成架构问题，再把架构方案翻译成卷面答案。
很多人失分，不是因为不懂 Kubernetes、Kafka、Flink 这些技术，而是因为答案停留在"知道名词"，没有继续往下写到"为什么是它、它解决什么、它的代价是什么、为什么不是另一个方案"。
所以这一篇真正要求的深度，可以拆成下面 5 个层次来理解。
5.1. 能从题干症状判断应该落到哪类架构或组件
这句话不是指"看到 Pod 就写 Kubernetes"这么简单，而是说你要能把题干里的业务现象，识别成对应的架构问题。
例如：
- 题干写"发布依赖人工、扩容慢、故障恢复慢"，你就要判断这是云原生 / 容器编排问题
- 题干写"既要实时结果又要最终准确"，你就要判断这是
Lambda / Kappa取舍问题 - 题干写"日志要支持全文检索和聚合分析"，你就要判断这是
Elasticsearch选型问题
也就是说，考试不是问你"什么是某技术"，而是在问你：这些题干信号最终指向什么架构方向。
答到位的标准是：
- 你能先说清题目暴露的核心矛盾
- 再把这个矛盾准确归到某一类架构问题
常见失分点是：
- 见到一个关键词就机械套技术名词
- 没有先解释题目问题是什么，就直接写方案
5.2. 能写出方案解决的核心问题，而不是只说"性能更高"
这是案例题里非常关键的一层。很多答案的问题不在于"错"，而在于"空"。
例如你写"Kubernetes 可以提高效率"，这句话不能说错，但得分很低，因为它没有说明到底提高了什么效率，也没有说明它是怎么解决问题的。
更有得分点的写法应该是：
Kubernetes解决的是大规模容器的自动部署、统一调度、自愈恢复和滚动更新问题- 服务网格解决的是服务间通信治理逻辑散落在业务代码中的问题
Kafka解决的是高吞吐数据接入、缓冲削峰和消息重放问题
也就是说，你写的不是"它很好"，而是"它到底替系统解决了什么原本做不到或做不好的事情"。
答到位的标准是：
- 能明确写出"原问题是什么"，"该方案通过什么能力解决这个问题"
常见失分点是：
- 只写"性能更高""效率更高""更先进"，没有说明改造前后的问题变化
5.3. 能写出至少 2 到 3 个收益和 2 到 3 个代价
这意味着你不能把答案写成单边宣传稿。
系统架构师案例题很少存在"纯收益、无代价"的方案。凡是值得考的架构，都一定有取舍。你如果只写优点，往往说明你只记了概念，没有理解架构决策。
例如：
- 上
Kubernetes的收益可以写：自动扩缩容、自愈、滚动更新、统一管理 - 上
Kubernetes的代价可以写：集群运维更复杂、网络与存储治理更复杂、平台门槛更高 - 上服务网格的收益可以写：统一治理、统一安全、统一观测、降低业务侵入
- 上服务网格的代价可以写：代理开销增加、调用链变长、平台维护成本上升
为什么这里要求"至少 2 到 3 个"？
因为只写 1 个收益、1 个代价，往往说明你理解得还不够完整。考试更希望看到你知道这不是"要不要上"的问题，而是"上了以后具体换来什么，又付出什么"的问题。
答到位的标准是：
- 收益不是一句空话，而是具体能力，例如弹性、自愈、统一治理、低延迟
- 代价也不是一句空话，而是具体成本，例如双链路维护、平台复杂度、资源开销、运维门槛
常见失分点是：
- 只写优点不写缺点
- 代价写成一句"成本更高"，但不说明高在哪
5.4. 能做相近方案比较，而不是只会单点介绍
这一层决定了你是不是在"做架构选择"，而不是"做名词解释"。
因为案例题真正喜欢考的，不是孤立问一个技术，而是让你在两个相近方案之间做判断。例如：
- 容器和虚拟机怎么选
Lambda和Kappa怎么选Spark和Flink怎么选HBase和Elasticsearch怎么选- 数据仓库和数据湖怎么选，或者为什么要同时建设
这类题如果你只是把两个概念分别解释一遍，往往还是拿不到高分。高分答案一定会出现这种句子：
- 当前场景更强调实时响应，因此更适合
Flink，而不是偏离线分析的Spark - 当前场景更强调海量明细随机读写，因此更适合
HBase，而不是偏检索分析的Elasticsearch
也就是说，你不仅要知道"它是什么"，还要知道"为什么这里选它，而不是另一个"。
答到位的标准是：
- 至少比较 2 到 3 个维度，例如实时性、复杂度、数据访问模式、治理目标
- 最后能给出明确结论，而不是模糊地说"两个都可以"
常见失分点是：
- 把两个方案各讲一遍，但没有做结论；只写"场景不同"，却不说到底哪里不同
5.5. 能把答案落到业务场景，而不是停留在口号层面
这是最后一层，也是最像系统架构师思维的一层。
因为考试最终不是在考你背了多少技术定义，而是在看你能不能把技术语言翻译成业务语言。例如：
- 说云原生，不要只写"自动化"，要落到"发布更快、恢复更快、资源利用率更高"
- 说服务网格，不要只写"治理下沉"，要落到"多团队、多语言服务可以统一治理"
- 说
Lambda，不要只写"双链路"，要落到"运营需要实时看数据，财务需要最终准确报表" - 说数据仓库，不要只写"面向主题建模"，要落到"稳定 BI 报表和统一口径分析"
也就是说，好的卷面答案应该让阅卷人看到：你不是在背术语，而是真的知道这个方案为什么会被企业采用。
答到位的标准是：
- 技术能力能对应到业务收益
- 架构代价能对应到管理成本或工程成本
常见失分点是：
- 全篇都在讲技术名词，没有一句落到业务目标
- 答案像百科词条，不像架构分析
所以，简单把这一篇的考试深度概括成一句话还不够。更准确地说，这一篇真正要求你做到的是：
- 先识别题干里的业务矛盾
- 再选择对应的架构方向
- 再说明这个方案具体解决什么问题
- 再补足收益、代价和适用边界
- 最后把技术语言翻译成业务语言
如果把这 5 步都写出来，你的答案才真正达到系统架构师案例题想要的深度。否则就很容易停留在"懂技术，但不会答题"的层面。
6. 高频题型速查表
如果你想在短时间内先建立"看到题干就知道往哪答"的感觉，可以先记下面这张表：
| 题型 | 题干高频信号 | 首先想到的答题方向 | 必须补的一层深度 |
|---|---|---|---|
| 云原生整体题 | 人工部署、环境不一致、扩容慢、恢复慢 | 传统部署向云原生演进 | 不只写自动化，还要补治理成本 |
| 容器题 | 标准化打包、迁移困难、部署慢 | 容器解决环境和交付问题 | 不只写优点，还要写为什么后续需要 K8s |
| Kubernetes 题 | Pod、Service、Deployment、自愈、扩缩容 | 容器编排与声明式管理 | 不只写概念，还要写为什么手工运维失效 |
| 服务网格题 | 重试、熔断、限流、链路追踪、安全策略难统一 | 治理能力下沉到基础设施层 | 不只写 Sidecar，还要写统一治理价值与代理代价 |
| CI/CD 题 | 发布频繁、测试慢、回滚难、上线不稳 | 构建自动化交付闭环 | 不只写效率提升，还要写测试和权限前提 |
| Lambda / Kappa 题 | 既要实时又要准确、要不要双链路、历史重算 | 准确性、复杂度、重放能力三者取舍 | 不只写定义，还要明确为什么选其一 |
| Spark / Flink 题 | 报表统计 vs 实时预警、批处理 vs 持续事件流 | 离线计算还是实时流处理 | 不只写产品名，还要落到实时性要求 |
| Kafka / HBase / ES 题 | 消息接入、明细查询、全文检索 | 按数据访问模式做组件选型 | 不只写"大数据组件"，还要写为什么不用另外两个 |
| 数仓 / 数据湖题 | 统一口径、原始沉淀、多源异构、探索分析 | 治理优先还是接入优先 | 不只写概念区别，还要写企业为什么并存建设 |
三、案例题总的考法
1. 出题人通常怎么设问
这一篇常见的出题方式大概有四类：
- 先给现有系统瓶颈，让你判断应该引入什么架构
- 先给一套目标能力，让你反推应该采用什么技术组合
- 给两个相近方案，让你比较优缺点和适用场景
- 给一条业务或数据链路，让你说明各层组件分工
所以你看到题目时，第一反应不应该是"定义是什么"，而应该是：
- 题目暴露的问题在哪里
- 出题人希望你答哪一层架构
- 这道题最可能要求你补什么取舍
2. 标准答题结构
这类题最稳的写法一般是四步：
- 先归纳问题
- 再提出方案、方案收益
- 最后补方案代价和适用边界
可以直接套成一句话：
该场景的核心问题是 xxx，因此可采用 xxx 架构或组件；它主要解决 xxx 问题，能够带来 xxx、xxx 等收益，但同时也会带来 xxx、xxx 等成本；结合题干中的 xxx、xxx、xxx，可以判断这里的出题点是 xxx。
如果你担心考场上写散，可以把这四步进一步固定成"每句对应一个动作"：
- 第一句只做诊断：题目当前的瓶颈和矛盾是什么
- 第二句只给方案：建议采用什么架构、平台或组件
- 第三句只写收益：解决什么问题、带来哪些直接能力
- 第四句只补边界：增加什么复杂度、适合什么场景、不适合什么场景
这样写的好处是，卷面结构会非常稳定，不容易漏掉"代价"和"边界"这两个高频得分点。
3. 这一篇容易失分的地方
这部分最常见的低分写法有四种：
- 只堆术语，不对应题干中的业务问题
- 只写优点，不写成本和边界
- 只说"提升性能、提升效率"，不落到具体能力
- 只说选某个组件，却不说明为什么不选其他组件
高分答案通常有三个特征：
- 先把题目的本质矛盾说出来
- 再把收益和代价写完整
- 最后把相近方案的边界讲清楚
四、云原生部分在案例题里怎么考
1. 云原生整体题
这类题一般不会直接问"什么是云原生"，而是通过现象来设问，例如：
- 系统发布依赖人工，效率低且容易出错
- 高峰期扩容慢，故障恢复依赖人工干预
- 多环境配置不一致，线上问题难复现
- 服务越来越多，部署、升级、治理变得混乱
当题干出现这些信号时，说明出题点通常落在"从传统部署走向云原生"。
可直接写成下面这种答案：
当前系统在部署与运维上主要存在人工操作多、环境不一致、扩容依赖人工、故障恢复慢等问题，传统方式已经难以支撑业务持续发布和弹性扩展。因此可引入云原生架构，对应用进行容器化封装，并基于容器编排平台实现自动部署、弹性伸缩、自愈恢复和声明式管理，从而提升交付效率、运行稳定性和资源利用率。但云原生架构也会带来集群治理、镜像管理、配置管理、监控告警和运维体系建设等额外成本，因此更适合服务规模较大、发布频繁、需要弹性扩缩容的业务场景。
如果题目问"为什么要云原生化"，答案至少要落到这 4 个得分点：
- 先点出现状问题：人工部署、多环境不一致、扩容和恢复效率低
- 再点出核心方案：容器化 + 编排平台 + 自动化交付 + 声明式管理
- 再写业务收益：发布更快、扩容更快、运行更稳、资源利用更高
- 最后补代价和边界：平台复杂度、运维门槛、治理成本会上升
最容易失分的写法是只写一句"云原生提高效率"，这类表述太空，不能直接形成卷面得分点。
2. 容器题
容器题常见信号有：
- 环境不一致
- 应用迁移困难
- 部署慢
- 扩容慢
- 服务需要标准化打包
这里案例题一般不是考 Docker 命令，而是考你是否知道容器解决什么、不解决什么。
可直接写成下面这种答案：
容器技术的核心作用是将应用程序及其依赖环境统一封装为标准化镜像，从而解决开发、测试、生产环境不一致的问题，并提高应用部署和迁移效率。与虚拟机相比，容器启动速度更快、资源开销更小，更适合微服务场景下的快速交付和弹性扩缩容。但容器的隔离性相对较弱，状态数据和持久化管理也更复杂。当业务服务数量持续增加后，仅靠容器本身无法解决调度、扩容、自愈和统一管理问题，因此通常还需要进一步引入 Kubernetes 等编排平台。
这类题最好按"价值 - 边界 - 演进方向"来写：
- 价值：统一环境、标准化交付、启动快、适合弹性部署
- 边界：隔离性弱于虚拟机，持久化和状态管理更复杂
- 演进方向：容器多了以后，必须继续解决编排和治理问题
如果答案没有写出"为什么后面还要上 K8s"，容器题通常只能拿到一半左右的分。
3. Kubernetes 题
K8s 是这篇里最稳定的高频考点之一。题干出现下面这些词时，基本就该往 K8s 上靠：
- Pod、Service、Deployment、Ingress
- 自动扩缩容、自愈、滚动更新
- 容器编排、集群调度、声明式部署
可直接写成下面这种答案：
Kubernetes 是面向生产环境的容器编排平台，主要用于解决大量容器实例的自动部署、统一调度、弹性扩缩容、故障自愈和滚动更新问题。当系统中的容器数量增多后，单纯依靠人工运维已经无法满足上线效率和运行稳定性要求，因此需要通过 Kubernetes 对容器集群进行统一管理。其中，Pod 是最小调度单元，Deployment 负责副本和升级策略，Service 提供稳定访问入口，这使系统能够在实例动态变化的情况下仍保持服务可用。与此同时，Kubernetes 也会带来网络、存储、配置、安全和监控治理复杂度上升的问题，因此适用于服务规模较大、交付频繁、需要自动化运维的场景。
K8s 题要尽量写出下面 5 个固定得分点：
- 为什么需要它：容器规模大后人工管理失效
- 它解决什么：调度、自愈、扩缩容、滚动更新、服务发现
- 为什么 Service 很重要：实例会变，访问入口不能跟着变
- 它体现什么思想：声明目标状态，由平台自动收敛
- 它的代价是什么：平台能力增强，但治理和运维复杂度明显上升
这里的高分点不是背概念，而是把"K8s 为什么会出现"讲清楚：容器解决了打包问题，但没有解决大规模运行管理问题。
4. 服务网格题
服务网格题在案例题里一般不会让你讲 Istio 的安装过程，而是通过治理问题来设问，例如：
- 重试、超时、熔断逻辑散落在各个服务里
- 多语言服务治理能力不一致
- 服务间安全、观测、流量控制难统一
- 微服务数量增长后，治理策略难维护
可直接写成下面这种答案：
当微服务数量持续增加后，重试、超时、熔断、限流、链路追踪和服务间安全等治理逻辑如果继续分散在各个业务服务中，会导致代码重复、治理策略不一致、跨语言维护困难等问题。因此可引入服务网格，将服务间通信治理能力下沉到基础设施层。其典型实现方式是 Sidecar 代理模式，即在每个业务服务旁部署代理组件，由代理统一处理流量治理、安全控制和观测能力。服务网格的核心价值在于统一治理、语言无关和降低业务代码侵入，但同时也会引入代理转发开销、调用链复杂度上升和平台维护成本增加的问题。
服务网格题最好直接写出这 4 句：
- 原问题：治理逻辑散在业务代码里，重复且难统一
- 解决方式：通过 Sidecar 代理把治理能力下沉到基础设施层
- 核心价值：统一治理、统一安全、统一观测、语言无关
- 主要代价：代理开销、链路更长、平台运维复杂
这类题最容易失分的地方，就是把服务网格写成"提升性能的技术"。这个说法不准，核心价值其实是统一治理。
5. DevOps / CI/CD 题
这类题经常和云原生一起出现。题干会强调：
- 发布频繁
- 测试和上线流程长
- 回滚困难
- 交付质量不稳定
可直接写成下面这种答案：
DevOps / CI/CD 的核心目标是打通开发、测试、发布和运维之间的交付链路，通过自动构建、自动测试、自动部署和自动回滚，减少人工操作，提高软件交付效率和上线稳定性。对于发布频繁、版本迭代快的系统，引入 CI/CD 流水线后，可以使发布过程标准化、可追踪、可回退，并与容器镜像、镜像仓库和 Kubernetes 编排平台形成自动化交付闭环。但其前提是需要建设完善的流水线、测试体系、配置管理和权限控制机制，否则自动化越强，错误扩散速度也越快。
这类题卷面上最好出现下面这些关键词：
- 自动构建
- 自动测试
- 自动部署
- 自动回滚
- 可追踪
- 可重复
这里不要只写"提升研发效率"，而要落到"构建、测试、部署、回滚、追踪"这些具体能力上。
6. 声明式管理题
声明式管理经常作为 K8s 的一个延伸考点出现。出题人真正想考的是：
- 传统方式依赖人工执行命令
- 云原生平台更强调描述目标状态
- 系统自动把当前状态收敛到目标状态
可直接写成下面这种答案：
声明式管理的核心思想不是人工逐条执行部署命令，而是先描述系统期望达到的目标状态，再由平台持续将实际状态收敛到目标状态。例如运维人员只需声明服务副本数、镜像版本和资源配置，平台即可自动完成调度、部署、失败重建和状态恢复。相较于命令式运维方式，声明式管理更适合云原生场景下的大规模自动化运维，因为它具有可配置、可版本化、可回滚和可自动收敛的特点。
这类题通常写清楚下面 3 点就够：
- 命令式是"告诉系统怎么做"
- 声明式是"告诉系统最终要什么状态"
- 平台负责持续比对现状和目标并自动纠偏
五、大数据部分在案例题里怎么考
1. 大数据整体题
大数据整体题通常不是让你背 Hadoop 生态，而是让你说明：
- 为什么单机数据库和单机计算开始不够用
- 为什么需要把采集、存储、计算、服务拆成多层
- 为什么不同业务场景要使用不同类型的组件
如果题干强调"海量数据、多源异构、实时统计、离线分析、检索查询并存"，说明它考的不是单个产品，而是整体数据架构分层能力。
可直接写成下面这种答案：
大数据架构的核心目标是解决海量、多源、异构数据的采集、存储、计算和服务化输出问题。随着业务数据规模持续增长，单机数据库和单机计算方式已经难以满足容量、性能和实时性要求，因此需要构建分层的大数据处理架构。一般可按"数据接入层、存储层、计算层、服务层"进行设计：数据首先通过日志采集或消息队列进入平台，随后存储到分布式存储系统中，再由批处理或流处理引擎进行加工计算，最后为报表分析、搜索检索、实时看板和业务查询提供数据服务。该架构的优势是能够支撑海量数据处理和多类型分析需求，但也会带来链路变长、组件增多、运维和治理复杂度上升的问题。
这类题最好按链路作答，不要散着写：
- 数据从哪里采集
- 进入什么接入层
- 存到什么存储层
- 由什么计算层处理
- 最终输出到什么服务层
2. Lambda / Kappa 题
这是这一篇里最典型的"取舍型"题目。
Lambda 题的题干常见信号是：
- 既要实时结果，又要最终准确
- 同一份数据既用于实时看板，也用于离线报表
- 历史数据需要全量重算
Kappa 题的题干常见信号是：
- 希望统一流处理链路
- 希望架构更简单
- 可以依靠消息重放处理历史数据
可直接写成下面这种对比答案：
如果业务场景既要求实时结果，又要求最终报表绝对准确，则更适合采用 Lambda 架构。Lambda 通过批处理层保证最终准确性，通过速度层提供低延迟结果，再将两部分结果进行合并，因此适合实时监控与离线校准并存的场景。但 Lambda 需要维护两套处理链路，系统复杂度和运维成本较高。
如果业务更关注统一处理链路、降低系统复杂度，并且消息系统具备较强的保留与重放能力，则可采用 Kappa 架构。Kappa 通过单一流处理链路同时承担实时计算和历史重放任务，架构更简洁，但前提是流处理能力足够成熟，且历史重算可以通过消息重放方式完成。
Lambda / Kappa 题至少要比较这 3 个维度：
- 实时性和最终准确性如何兼顾
- 是单链路还是双链路
- 历史重算靠批处理还是靠消息重放
这类题最核心的深度不是"谁更先进"，而是：当前业务到底更重视准确性、实时性，还是系统简化。
3. Spark / Flink 题
这类题常通过"实时性要求"来区分。
如果题干强调：
- 周期性离线统计
- 批量处理
- 第二天报表
- SQL 分析和离线计算
一般更容易落到 Spark。
如果题干强调：
- 毫秒级或秒级处理
- 持续事件流
- 实时监控
- 实时预警
- 复杂事件处理
一般更容易落到 Flink。
可直接写成下面这种对比答案：
Spark 更适合离线批处理、周期性统计和大规模数据分析场景，优势在于生态完整、批处理能力强、适合报表和离线计算任务。Flink 更适合实时流处理、事件驱动计算和低延迟预警场景，优势在于原生流处理能力强、延迟更低，更适用于实时监控、实时风控和实时推荐等业务。因此在选型时，不能简单比较二者谁更流行，而应根据题目中的实时性要求、处理模式和业务目标进行判断：偏离线分析一般选 Spark，偏实时事件流一般选 Flink。
Spark / Flink 题至少要答出 3 个点：
- 处理模式不同：批处理为主还是原生流为主
- 实时性要求不同：分钟小时级还是秒级毫秒级
- 业务目标不同：报表分析还是实时响应
4. Kafka / HBase / Elasticsearch 选型题
这类题在考试里非常高频，核心不是记组件定义，而是会不会按场景选型。
可以先记住三个最常见的映射关系：
- 高吞吐消息接入、事件流、消息重放，优先想到
Kafka - 海量明细、高吞吐随机读写、按 RowKey 查询，优先想到
HBase - 全文检索、日志搜索、多维聚合分析，优先想到
Elasticsearch
可直接写成下面这种选型答案：
如果题目强调高吞吐消息接入、事件流处理、消息积压缓冲和消费重放能力，应优先选择 Kafka，因为它适合承担大规模数据接入和流式传输任务。
如果题目强调海量明细数据存储、高并发随机读写、按主键快速查询，则应优先选择 HBase，因为它更适合海量稀疏数据的高吞吐存储与查询。
如果题目强调日志检索、全文搜索、关键词匹配和多维聚合分析，则应优先选择 Elasticsearch，因为它基于倒排索引，更擅长搜索和聚合分析场景。
这类题卷面上最好按下面 4 句来写：
- 先写业务需求是什么
- 再写该组件解决什么问题
- 再写为什么选它
- 最后补一句为什么不选另一个相近组件
例如可以直接这样写：
- 该场景需要承接海量日志并支持消息重放，因此应选
Kafka，因为其吞吐高、支持分区和消费位点管理，更适合作为数据接入与缓冲组件，而不是检索组件。 - 该场景需要保存海量订单明细并支持高并发随机查询，因此应选
HBase，因为其适合海量稀疏数据的高吞吐读写，而不适合复杂全文检索。 - 该场景需要支持日志关键词搜索和聚合分析，因此应选
Elasticsearch，因为其基于倒排索引，擅长搜索与聚合，而不适合作为高吞吐主存储。
这里最容易失分的点，是把三个组件都写成"适合大数据场景"。这太泛了，必须写到数据访问模式上。
5. 数据仓库 / 数据湖题
这类题考的重点，通常不是某个湖仓产品名，而是数据组织和治理思路。
如果题干强调：
- 统一主题建模
- 稳定报表口径
- BI 分析
- 结构化分析
通常偏数据仓库。
如果题干强调：
- 原始数据沉淀
- 多源异构数据汇聚
- 图片、日志、埋点、文本等多类型数据
- 探索式分析和机器学习
通常偏数据湖。
可直接写成下面这种对比答案：
数据仓库更强调面向分析主题进行建模，并在入库前完成数据清洗、整合和口径统一，因此更适合 BI 报表、经营分析和 OLAP 场景。数据湖更强调先接入和沉淀原始多源异构数据，包括结构化、半结构化和非结构化数据，因此更适合探索式分析、机器学习和原始数据留存场景。如果企业同时建设数据湖和数据仓库，通常是由数据湖负责承接原始数据、保留数据多样性，再由数据仓库负责沉淀统一主题模型和稳定分析口径，从而同时满足灵活探索和标准分析两类需求。
这类题至少要比较下面 3 组区别：
- 建模时点：仓库偏先建模，数据湖偏先接入
- 治理目标：仓库偏统一口径，数据湖偏原始沉淀
- 使用场景：仓库偏报表分析，数据湖偏探索分析和算法训练
六、这一篇答案要写到什么深度
如果你已经懂技术，复习这一篇时最重要的不是再背一遍定义，而是记住每类题的作答深度。
1. 卷面答案至少要有 4 句话
这一篇的大多数题，都可以强制自己写出下面 4 句话：
- 第一句：题目当前的问题是什么
- 第二句：建议采用什么架构或组件
- 第三句：它能带来什么收益
- 第四句：它会带来什么代价或边界
例如不能只写：
- 可采用 Kubernetes
而要写成：
- 由于容器实例数量增加后，人工运维无法满足扩缩容、自愈和滚动升级需求，因此可采用 Kubernetes 进行容器编排；它可以提供自动调度、自愈、服务发现和声明式管理能力，提高上线效率和运行稳定性；但同时也会带来集群治理、配置管理和运维复杂度上升的问题。
只有写到这个层次，才算是案例题有效答案。
2. 对比题必须补一句"为什么不用另一个"
案例题里很多分数来自比较能力。比如：
- 为什么这里选 HBase 而不是 ES
- 为什么这里选 Lambda 而不是 Kappa
- 为什么这里选服务网格而不是继续在代码里做治理
所以在卷面上最好再补一句：
与 xxx 相比，当前场景更强调 xxx，因此选择 xxx 更合适。
也就是说，考试不只看你知不知道这个方案，更看你会不会排除其他方案。
3. 不要把答案写成百科介绍
百科式答案的问题在于：
- 讲了很多定义
- 但没有对应题干矛盾
- 没有落到业务收益和工程代价
- 看起来懂很多，但得分点不集中
更好的写法始终是围绕题干中的业务目标和系统约束去写。你可以把自己每一段答案都检查一遍：有没有写出"为什么要用"、 "用了能解决什么"、 "会付出什么代价"。
4. 考场速写清单
如果你在考场上时间紧，可以在下笔前先用下面这张清单快速自检。只要能勾住其中大部分，答案通常就不会太空：
- 我有没有先写清题干的核心矛盾，而不是直接写技术名词
- 我有没有明确写出采用什么架构或组件，而不是只说"优化""改进"
- 我有没有写出该方案到底解决什么问题，而不是只写"性能更高"
- 我有没有至少写出 2 个收益和 2 个代价
- 我有没有补一句"为什么不用另一个相近方案"
- 我有没有把技术能力翻译成业务结果，例如发布更快、恢复更快、口径更统一、实时性更强
如果一段答案里只有"方案"和"优点"，没有"代价"和"边界"，那通常就还没达到系统架构师案例题想要的深度。
七、最后给一个通用答题模板
遇到这一篇的案例题，可以优先套下面这个框架：
题干反映的核心问题是 xxx，例如 xxx、xxx、xxx。针对该问题，可采用 xxx 架构或组件。该方案主要通过 xxx 机制解决 xxx 问题，能够带来 xxx、xxx、xxx 等收益。但与此同时，它也会引入 xxx、xxx 等代价或限制，因此更适用于 xxx 场景。结合题干中的 xxx、xxx、xxx 关键信号，可以判断本题考查的是 xxx。
如果是对比题，再补一句：
与 xxx 相比，xxx 更适合当前场景，因为当前业务更强调 xxx，而不是 xxx；如果题目更强调 xxx，则应优先考虑 xxx。
如果你希望在卷面上直接套用，可以再压缩成 4 句模板：
该系统当前存在 xxx 问题。
因此建议采用 xxx 架构或组件。
该方案可以解决 xxx，并带来 xxx、xxx 等收益。
但该方案也会带来 xxx、xxx 等代价，因此适用于 xxx，不适用于 xxx。
这样写出来的答案，基本就已经是"可直接上卷面"的表述，而不是泛泛的复习提示。
如果是对比型题目，可以直接在第三句和第四句之间再插一句：
与 xxx 相比，当前场景更强调 xxx，因此选择 xxx 更合适。
如果是整体架构题，可以再补最后一句收口：
该方案本质上是通过 xxx 方式，解决系统在 xxx 阶段暴露出的扩张问题。
这样一来，不管题目问的是云原生整体、大数据整体，还是具体组件选型，你都能保持答案结构统一，不容易写散。