1. 实时数据分析平台需求分析与架构目标
在动手搭建任何一套实时数据分析平台之前，最重要的一步不是选组件、写代码，而是把"业务到底要什么"翻译成"平台必须满足什么"。Databricks 提供了 Spark Structured Streaming、Delta Live Tables、Lakeflow、Unity Catalog、Photon 引擎等一整套能力，但这些能力只有在明确的需求约束下才能被正确组合。本章的目标是建立一套可落地的需求分析方法，把模糊的业务诉求转化为可度量、可验证的平台设计目标与关键指标。
一、从业务场景出发，而不是从技术出发
实时分析平台的起点是业务场景。常见的场景大致可以分为几类：实时风控与反欺诈、实时推荐与个性化、实时监控与告警、实时运营看板、IoT 设备遥测处理、实时计费与账务核对。不同场景对平台的要求差异极大。例如实时风控通常要求端到端延迟在数百毫秒到 2 秒之间，且对数据准确性要求极高，因为一次误判可能直接造成资金损失；而实时运营看板往往可以接受 10 秒到 1 分钟的延迟，但对吞吐量和并发查询能力要求更高。
因此第一步是明确"谁在用、用来做什么、做错或做慢会怎样"。建议用一句话描述核心场景，例如："为风控团队提供交易事件的实时特征计算与规则判定，端到端延迟不超过 2 秒，单日处理 3 亿笔交易，误判率低于 0.1%。"这句话里已经包含了用户、用途、延迟、吞吐量和质量约束五个关键要素。
二、五类核心需求维度
把业务诉求拆解为可度量的需求，通常需要覆盖以下五个维度：
- 延迟要求：区分数据采集延迟、处理延迟、写入延迟和查询延迟。端到端延迟是它们的总和，不能只看其中一段。常见分级为：亚秒级（<1s）、秒级（1–5s）、分钟级（1–5min）、准实时（5–60min）。
- 吞吐量：包括峰值事件速率（events/s）、平均速率、日增量数据量（GB/天）、并发查询数（QPS）。峰值通常是平均值的 3–10 倍，必须按峰值设计。
- 数据源类型：消息队列（Kafka、Kinesis、Event Hubs）、CDC 变更流（Debezium、Delta CDF）、文件落地（S3、ADLS、GCS）、API 拉取、数据库直连。不同源的接入方式、顺序保证和幂等策略不同。
- SLA 与可用性：平台可用性目标（如 99.9%）、数据新鲜度承诺、故障恢复时间（RTO）、可接受的数据丢失窗口（RPO）。
- 成本约束：月度预算、单位数据处理成本（元/百万条）、存储与计算的比例、是否允许弹性伸缩带来的成本波动。
这五个维度不是孤立的。提高吞吐量往往需要更多计算资源，从而推高成本；降低延迟可能需要放弃微批而改用连续处理，进而影响吞吐和成本。需求分析的本质是在这些约束之间找到可行解，而不是每一项都取最优。
三、把需求转化为平台设计目标
需求是"业务要什么"，设计目标是"平台要做到什么"。二者之间需要一次翻译。例如业务说"看板要实时"，翻译为设计目标就是"从事件产生到 Delta 表可查询的端到端延迟 P95 ≤ 5 秒"。业务说"不能丢数据"，翻译为"在 Kafka 保留期内，平台需保证至少一次处理语义，并通过幂等写入实现端到端精确一次"。
设计目标应当满足 SMART 原则：具体、可度量、可达成、相关、有时限。下面给出一份示例性的设计目标表，用于说明如何把需求落到指标上。表中数值为教学示例，实际项目需根据业务重新测算。
| 需求维度 | 业务诉求 | 设计目标（示例） | 验证方式 |
|---|---|---|---|
| 延迟 | 风控判定要快 | 端到端 P95 ≤ 2s，P99 ≤ 5s | 埋点时间戳差值统计 |
| 吞吐 | 大促期间交易激增 | 峰值 50,000 events/s，持续 30 分钟 | 压测 + 监控指标 |
| 数据源 | 交易、用户、设备三类流 | Kafka 三主题，CDC 接入用户库 | 接入清单核对 |
| SLA | 风控不可长时间中断 | 可用性 99.9%，RTO ≤ 15min，RPO ≤ 1min | 故障演练 |
| 成本 | 预算可控 | 单位处理成本 ≤ 0.8 元/百万条 | 账单与用量核算 |
四、关键指标与容量估算
设计目标确定后，需要进一步估算容量，判断目标是否现实。容量估算的核心是"数据量 × 处理复杂度 × 冗余系数"。以示例场景为例：日均 3 亿笔交易，峰值系数取 5，则峰值约 17,400 events/s；每条事件平均 1KB，则峰值吞吐约 17MB/s，日增量约 300GB。若保留 90 天，热数据约 27TB，加上 Delta 表的多版本和索引开销，实际存储可能达到 40–50TB。
计算侧，若每条事件需要 3 次特征关联和 1 次规则判定，单核处理能力按 5,000 events/s 估算，则峰值需要约 4 个核心用于处理，但考虑到反压、状态管理和容错开销，实际建议预留 3–5 倍余量，即 12–20 个核心。这些数字不是精确值，而是用于判断"这个目标是否可行、成本是否可接受"的初步依据。
五、需求到架构目标的映射关系
下面这张图把本节的核心逻辑可视化：左侧是业务场景与五类需求输入，中间经过需求翻译与容量估算，右侧输出平台设计目标与关键指标，并最终约束到 Databricks 的架构选型上。图中同时标出了各维度之间的相互影响关系，帮助理解为什么需求分析不能孤立地看某一项。
六、常见误区与检查清单
在需求分析阶段，有几个高频误区值得警惕。第一，只问"要多快"而不问"多快算够"。延迟目标过高会显著推高成本，很多场景 5 秒和 500 毫秒对业务价值没有区别。第二，忽略峰值。按平均值规划资源，大促或故障恢复时的流量尖峰会导致严重积压。第三，把数据源当成静态清单。数据源会新增、会变更 schema、会调整分区策略，需求分析时要预留扩展位。第四，SLA 只写可用性不写数据质量。数据延迟到达、重复、乱序都是实时场景的常态，必须明确平台如何处理。
可以用下面这份检查清单快速自查需求分析是否完整：
- 是否用一句话说清了核心场景、用户、用途和失败后果？
- 延迟是否拆分为采集、处理、写入、查询四段，并给出 P95/P99 目标？
- 吞吐是否区分平均与峰值，峰值系数是否合理？
- 数据源是否列出类型、协议、顺序保证、schema 变更频率？
- SLA 是否包含可用性、RTO、RPO 和数据质量承诺？
- 成本是否给出月度预算和单位处理成本上限？
- 是否做过容量估算，并判断目标在预算内是否可行？
- 设计目标是否可度量、可验证，并有明确的验证方式？