第 7 关：架构师 — 设计数据架构
数据分析的上限不是算法，是架构。数据怎么存、怎么算、怎么流，决定了你能回答什么问题。
🎯 本关目标
- 解决"数据散落在各处、算得慢、算不准、扩不动"的问题
- 对应现实工程能力：数据架构设计、OLAP 选型、湖仓一体调研、容量规划
Step 1：本关资料（海量输入）
用 48h 倒推：如果 Step 5 要输出费曼讲解，现在需要储备什么弹药？
| 资料类型 | 具体资料 | 用途 | |---------|---------|------| | 系统设计 | StarRocks 官方文档 — 架构设计章节 + 存算分离章节 | 理解你正在用的系统的设计理念和限制 | | 系统设计 | ClickHouse 官方文档 — MergeTree 家族 + Materialized View | 理解另一种 OLAP 思路，做选型对比时有据可依 | | 经典书籍 | 《DDIA》Martin Kleppmann — 第 3 章（存储与检索）+ 第 9 章（一致性） | 理解"为什么"——列存为什么快、一致性为什么难 | | 官方文档 | Apache Flink 官方文档 — 流批一体 + Table API | 理解实时计算引擎的核心设计，为什么 Flink 能统一流和批 | | 开源项目 | Apache Iceberg 文档 — Architecture + Performance | 理解湖仓一体的底层设计，对比 Hudi/Delta Lake | | 一线实践 | 字节跳动技术博客 — 搜索"数据中台" / "实时数仓" | 看一线互联网公司的数据架构演进路径 | | 学术论文 | 见末尾论文阅读清单 | 深入理解数据架构的理论基础 | | 工作素材 | 你当前公司的数据架构（Flink → StarRocks + ODS/DWD/DWS + DolphinScheduler） | 画架构图、做瓶颈分析的直接对象 |
📐 数学补给站
| 数学概念 | 本关用途 | 深入参考 | |---------|---------|---------| | 图论 & DAG | 数据流水线 = 有向无环图，任务调度 = 拓扑排序 | 数学-⑤ 离散数学 | | 矩阵运算直觉 | OLAP 列式存储的数学基础（列向量压缩、SIMD 向量化） | 数学-① 线性代数 | | 拓扑排序 | DolphinScheduler/Airflow 的 DAG 调度原理 | 数学-⑤ 离散数学 | | 哈希 | 数据分片、一致性哈希 | 数学-⑤ 离散数学 |
快速自测：
- 为什么数据流水线必须是 DAG（不能有环）？
- 拓扑排序的输出是什么？在你的调度系统里对应什么？
- 列式存储为什么比行式存储快？（从向量运算的角度想）
答不上来的去对应数学模块补课。
Step 2：本关心智模型
这些模型是你做判断的"操作系统"。理解它们，不只是记住它们。
模型 1：存储-计算分离模型
- 核心思想：数据存在哪和怎么算是两回事，分开设计才能独立扩展。存储成本持续下降（S3/HDFS），计算需要弹性应对高峰（MPP/Serverless），分开才能各自优化。
- 关键变量：
- 存储格式（列式 / 行式）：分析用列式（只读需要列），写入用行式（整行写入快）
- 计算引擎（批处理 / 流处理）：T+1 报表用批，实时看板用流
- 数据新鲜度（Freshness）：业务能容忍多旧的数据？秒级 / 分钟级 / 小时级 / T+1
- 应用场景：Snowflake（存储用 S3，计算按需弹性伸缩，用户按查询量付费）；StarRocks 存算分离模式；湖仓一体（Iceberg + Trino/Flink）
- 局限性：完全分离引入了网络 IO 开销（数据从存储层传到计算层）；不是所有场景都需要分离——数据量小、查询简单的场景，存算一体反而更快（本地数据访问 > 网络传输）
- 相关资料：StarRocks 官方文档"存算分离"章节；《DDIA》第 3 章"存储与检索"；Armbrust et al. "Lakehouse"（CIDR 2021）
模型 2：数据分层模型
- 核心思想：ODS → DWD → DWS → ADS，每层解决不同问题。分层解耦了"数据采集"和"数据应用"，改需求时不用重跑原始数据。
- ODS（Operational Data Store）：原始数据，不做任何修改，"数据的事实来源"
- DWD（Data Warehouse Detail）：清洗 + 标准化，统一字段命名和格式
- DWS（Data Warehouse Summary）：业务聚合，按主题域汇总指标
- ADS（Application Data Store）：应用层，直接对接 BI / API / 报表
- 关键变量：
- 分层粒度（每层聚合到什么程度）→ ODS 最细，ADS 最粗
- 更新频率（ODS 实时 / DWD 准实时 / DWS T+1 / ADS 按需）→ 层次越高延迟越低
- 数据质量 SLA（每层的准确性、完整性、及时性要求）→ 每层有独立的 SLA
- 应用场景：字节跳动数据中台（ODS 原始日志 → DWD 清洗标准化 → DWS 聚合业务指标 → ADS 报表 API）；任何有数据仓库需求的公司
- 局限性：分层越多，ETL 链路越长，数据延迟越大；过度分层会导致维护成本爆炸（每一层都要写代码、监控、排错）；某些场景（如实时分析）可能需要跳过中间层
- 相关资料：《DDIA》第 3 章；Kimball 维度建模方法论；StarRocks 官方文档数据建模章节
模型 3：Lambda vs Kappa vs 湖仓一体模型
- 核心思想：处理实时和离线数据有三种架构范式，各有 trade-off。Lambda（批+流双链路，准确但维护成本高）→ Kappa（纯流，简单但重算成本高）→ 湖仓一体（湖上叠加仓库能力，统一存储但引入元数据复杂度）。
- 关键变量：
- 数据一致性要求（批处理结果 vs 流处理结果是否需要对齐）
- 维护复杂度（维护几套代码？团队技能栈是否匹配？）
- 数据规模和增长速度（决定了是否需要湖的弹性扩展能力）
- 应用场景：Lambda 适合对数据一致性要求高、有明确批处理和流处理需求的场景；Kappa 适合以实时为主、可以接受最终一致性的场景；湖仓一体适合数据量大、需要同时支持 BI 分析和 ML 训练的场景
- 局限性：架构范式是理想化的，实际生产中往往是混合架构；"同一个指标批处理和流处理算出来对不上"的问题不一定是架构问题，可能是数据质量或口径定义问题
- 相关资料：Marz "Lambda Architecture"（2015）；Akidau et al. "The Dataflow Model"（VLDB 2015）；Armbrust et al. "Lakehouse"（CIDR 2021）
Step 3：本关分歧点
真正的判断力不在于"知道什么是对的"，而在于"知道两边为什么吵"。
分歧 1：实时 vs 批处理——什么时候必须实时？
- A 方（实时优先）：实时数据价值随时间衰减——风控场景延迟 1 秒可能损失百万，监控场景需要秒级告警。Flink 流批一体的成熟使得实时架构的成本大幅下降。
- B 方（批处理优先）：实时系统更复杂（状态管理、exactly-once、反压）、成本更高、数据一致性更难保证。很多场景 T+1 就够了，不要为了实时而实时。过度追求实时是"架构炫技"。
- 实践倾向：根据业务需求决定。问三个问题：① 数据价值是否随时间快速衰减？② 实时的收益是否覆盖多出的成本和复杂度？③ 团队是否有能力维护实时系统？如果三个都是"是"，做实时；否则，先做好 T+1。
- 为什么重要：这是架构决策中最容易犯的错——为了技术先进性做实时，结果系统不稳定、维护成本爆炸、业务价值不明显。
分歧 2：湖仓一体 vs 传统数仓——是否需要升级？
- A 方（湖仓一体）：解决了传统数仓的弹性扩展问题（S3 无限存储）、ACID 事务（Iceberg/Hudi/Delta Lake）、Schema 演进、时间旅行。是数据架构的未来方向。
- B 方（传统数仓）：湖仓一体引入了额外复杂度——元数据管理、Compaction 调优、小文件问题。小团队（数据量 < 10TB、分析师 < 5 人）用传统数仓 + 好的建模就够了。StarRocks/ClickHouse 单机就能处理 TB 级数据。
- 实践倾向：取决于数据规模和团队能力。数据量 < 10TB、不需要 ML 训练的纯分析场景 → 传统数仓够用。数据量 > 10TB、需要同时支持 BI + ML + 数据科学 → 考虑湖仓一体。不要因为"新"而迁移。
- 为什么重要：技术选型的错误代价巨大——迁移成本、学习成本、运维成本。选错了可能要花 1-2 年纠错。
分歧 3：StarRocks vs ClickHouse vs Doris——OLAP 选型
- A 方（StarRocks）：Join 性能好、支持实时更新（Primary Key 模型）、联邦查询（外表 Join）、运维简单、MySQL 协议兼容。适合需要多表 Join + 实时更新的混合场景。
- B 方（ClickHouse）：单机查询极快、列式存储极致优化、社区生态更成熟、文档更丰富。适合单表大宽表的聚合查询场景。
- C 方（Doris）：StarRocks 的前身，百度开源，和 StarRocks 共享大量代码。社区更大（Apache 顶级项目），但某些性能特性不如 StarRocks。
- 实践倾向：没有绝对最优，取决于场景。需要频繁 Join + 实时更新 → StarRocks；单表大宽表 + 极致查询性能 → ClickHouse；已经用了 Doris 且没有明显瓶颈 → 不必迁移。但选型要考虑团队学习成本和社区活跃度。
- 为什么重要：OLAP 引擎是数据架构的核心组件，选错代价高（迁移成本巨大）且影响面广（所有分析查询都依赖它）。
Step 4：闯关任务（动手验证）
理论看完了，现在动手。以下任务按优先级排序，全部完成才算通关。
任务 1：画当前工作数据架构图 ⭐
- 用工具（Draw.io / Excalidraw / 手绘）画出你当前工作的完整数据架构
- 必须包含：数据源 → 采集 → 存储 → 计算 → 应用，每层标注技术选型
- 你的工作场景参考：Flink → StarRocks + ODS/DWD/DWS + DolphinScheduler
- 标注数据流向、依赖关系、瓶颈点
任务 2：OLAP 选型对比 ⭐
横向对比 StarRocks vs ClickHouse vs Doris：
| 维度 | StarRocks | ClickHouse | Doris | |------|-----------|------------|-------| | 查询性能 | ? | ? | ? | | 实时更新 | ? | ? | ? | | 运维复杂度 | ? | ? | ? | | 社区活跃度 | ? | ? | ? | | 适合场景 | ? | ? | ? |
- 每个维度给出你的结论 + 依据（文档/博客/实测）
- 回答：你的公司为什么选 StarRocks 而不是 ClickHouse？
任务 3：湖仓一体调研
- 对比 Iceberg vs Hudi vs Delta Lake
- 重点关注：ACID 事务支持、时间旅行（Time Travel）、Schema 演进、社区生态
- 回答：在什么场景下需要从传统数仓升级到湖仓一体？
任务 4：架构升级方案
- 场景：设备从 10 万 → 1000 万，数据量增长 100 倍
- 回答：
- 当前架构的瓶颈在哪？（存储 / 计算 / 网络 / 调度）
- 需要怎么改？（水平扩展 / 分库分表 / 冷热分离 / …）
- 改造成本估算（人力 / 时间 / 风险）
Step 4.5：💬 AI 教练对话
以下 4 个 Prompt 对应学习过程中的不同阶段。按需使用，不是顺序执行。
Prompt 1：理解问题 — 架构分析
使用时机：开始画架构图之前，理清架构层次时
我需要分析一个数据架构，请帮我理清架构层次。
我的数据架构描述：
[描述你的数据流，如"设备数据通过 MQTT 上报，Flink 消费 Kafka 做实时计算，写入 StarRocks 的 ODS 层，DolphinScheduler 调度离线任务从 ODS 聚合到 DWS，前端 BI 工具查询 ADS 层"]
请回答：
1. 这个架构属于什么类型？（Lambda / Kappa / 湖仓一体）
2. 数据从产生到可用经过了几层？每层解决什么问题？
3. 这个架构最可能的瓶颈在哪？为什么？
⚠️ 禁止直接给架构优化方案，只做分析。
Prompt 2：Debug — 查询慢 / 数据延迟
使用时机：遇到查询慢、数据延迟等性能问题时
我们的数据架构出了问题：[描述具体问题，如"StarRocks 查询一个 DWS 表需要 30 秒，业务要求 < 5 秒"]
当前架构信息：
- 数据量：[如"DWS 表 5000 万行，每天新增 50 万"]
- 查询模式：[如"按设备分组聚合，时间范围 7 天"]
- 集群配置：[如"3 节点，每节点 16C 64G"]
请帮我诊断：
1. 可能的瓶颈在哪？（存储 / 计算 / 网络 / 建模）
2. 给我 3 个排查方向，按优先级排序
3. 每个方向具体查什么？
⚠️ 禁止直接给解决方案，引导我排查。
Prompt 3：模型提取 — 存储-计算分离实践
使用时机：学完存储-计算分离模型后，分析当前架构的分离程度时
我正在学习"存储-计算分离"模型。
当前工作使用的技术栈：[如"StarRocks 存算一体，Flink 做计算，数据存 StarRocks 内部"]
请帮我分析：
1. 当前架构中，存储和计算是否真正分离？分离程度如何？
2. 如果要实现完全的存储-计算分离，需要做什么改造？
3. 分离后能带来什么好处？会引入什么新问题？
⚠️ 不要直接给架构图，引导我思考 trade-off。
Prompt 4：工程映射 — 技术选型决策
使用时机：做 OLAP 选型或湖仓一体调研时
我们需要做一个技术选型决策：[描述你的场景，如"实时 OLAP 引擎，需要在 ClickHouse 和 StarRocks 之间选择"]
业务需求：
- 查询延迟要求：[如"< 3 秒"]
- 数据更新频率：[如"每分钟"]
- 数据量级：[如"单表 1 亿行"]
- 团队技术栈：[如"熟悉 MySQL，Java 为主"]
请帮我设计一个选型决策框架：
1. 哪些维度是"硬性要求"（不满足直接淘汰）？
2. 哪些维度是"加分项"？
3. 按这个框架，你会推荐哪个？为什么？
⚠️ 不要直接给答案，帮我建立决策框架。
Step 5：关 AI 自测
⚠️ 关闭 AI 前提：先独立思考 20-30 分钟，写出自己的判断和理由，再开启 AI 做追问验证。不要边想边问。
题目 1（理解层）：数据湖 vs 数据仓库，面试官在考你什么？
面试官问：「你们公司用的数据仓库还是数据湖？能说说两者的区别吗？」
- 如果面试官追问「为什么很多公司在从数据湖往湖仓一体迁移？湖仓一体解决了什么核心问题？」
- 面试官真正在考察什么？是概念记忆，还是对架构演进的判断力？
- 如果面试官问「你工作中的 StarRocks 算数据仓库还是湖仓？」你怎么回答？
你的判断：________________ 为什么：________________
题目 2（应用层）：扫地机器人数据管道——10 万台到 100 万台
设备从 10 万台增长到 100 万台，每天埋点数据量从 5000 万条暴涨到 5 亿条。当前架构：设备 → MQTT → Kafka → Flink → StarRocks（ODS/DWD/DWS）。DWS 聚合查询从 3 秒涨到 30 秒，Flink Checkpoint 频繁超时，Kafka 磁盘快满了。
- 你会从哪些方向入手？优先级怎么排？
- 存储、计算、网络，哪个最先成为瓶颈？
- 如果只给你 1 个月的优化时间，你会先做什么？
你的判断：________________ 为什么：________________
题目 3（边界层）：Lambda 还是 Kappa？还是都不选？
你们是 Lambda 架构——批处理跑 T+1 报表，流处理跑实时监控。但同一个指标，批处理和流处理算出来的值总是对不上（偏差 0.5%-2%）。运维抱怨维护两套代码太累了。
- 如果面试问你「Lambda 和 Kappa 怎么选」，你怎么回答？
- 有没有可能你们的问题不是架构选型的问题，而是数据质量或口径定义的问题？
- 怎么判断该修架构还是修数据口径？
你的判断：________________ 为什么：________________
题目 4（决策层）：OLAP 选型——StarRocks 还是 ClickHouse？
新 IoT 数据分析平台选 OLAP 引擎。需求：50 万台设备，每天 10 亿条埋点，主要查询是按设备分组聚合 + 多表 Join + 时间范围筛选。
- StarRocks Join 性能好、运维简单；ClickHouse 单机查询极快、生态更成熟
- 团队学习成本、社区活跃度、招聘难度、未来 3 年数据增长趋势，这些"软指标"怎么量化？
- 你的决策框架是什么？
- 如果选错了，代价有多大？能不能回退？
你的判断：________________ 为什么：________________
题目 5（综合层）：费曼输出预演
假设你要向一个刚入行的数据工程师解释"为什么数据需要分层（ODS/DWD/DWS/ADS），不能直接从原始数据查"，用你自己的话，结合你工作中的实际例子，在 2 分钟内说清楚。写下来。
你的表述：________________
🤖 AI 追问 Prompt
我刚完成了数据分析第 7 关的 AI 自测，以下是我的回答：
题目 1：[你的回答]
题目 2：[你的回答]
题目 3：[你的回答]
题目 4：[你的回答]
题目 5：[你的回答]
请扮演一个持怀疑态度的资深数据架构师，对我的回答进行追问：
1. 每个场景至少追问 1 轮
2. 如果我的回答有漏洞，不要直接指出，而是用提问让我自己发现
3. 如果我的回答到位了，说"这个回答到位了"然后进入下一个场景
4. 追问要有递进性：第一轮问"为什么"，第二轮问"如果条件变了呢"，第三轮问"你确定吗？有没有反例？"
5. 不要直接给答案，永远用提问引导
6. 特别关注题目 4——架构选型没有绝对对错，我需要看到你的决策框架是否完整
Step 6：费曼输出 + 信心校准
把学到的东西用自己的话输出出来。如果你讲不清楚，说明你还没真正理解。
🎤 一句话版本
用一句话（≤ 30 字）说清楚"数据架构设计的核心原则是什么"。
我的理解：________________
📢 三分钟版本
假设你要在一个技术分享会上用 3 分钟讲清楚"存储-计算分离 + 数据分层 + OLAP 选型"的核心逻辑，面对的听众是有 1-2 年经验的数据工程师。写出来。
我的讲解：________________
🧭 场景判断表格
| 场景 | 你会怎么做 | 用到哪个模型 | 为什么 | |------|----------|------------|--------| | 数据量增长 100 倍，查询变慢 | | | | | 需要实时监控 + T+1 报表 | | | | | OLAP 引擎选型（StarRocks vs ClickHouse） | | | | | 是否需要从数仓升级到湖仓一体 | | | | | 批处理和流处理的指标对不上 | | | |
📊 信心自评
| 维度 | 信心度（1-5） | 依据 | |------|-------------|------| | 我能画出完整的数据架构图并标注瓶颈 | ⬜⬜⬜⬜⬜ | | | 我能解释存储-计算分离的 trade-off | ⬜⬜⬜⬜⬜ | | | 我能说出 ODS/DWD/DWS/ADS 每层的职责 | ⬜⬜⬜⬜⬜ | | | 我能做 OLAP 选型决策并给出理由 | ⬜⬜⬜⬜⬜ | | | 我能判断是否需要湖仓一体 | ⬜⬜⬜⬜⬜ | |
📘 精准阅读
| 资源 | 精确到 | 解决什么问题 | |------|--------|-------------| | StarRocks 官方文档 | 架构设计章节 + 存算分离章节 | 理解你正在用的系统的设计理念和限制 | | ClickHouse 官方文档 | MergeTree 家族 + Materialized View | 理解另一种 OLAP 思路，做选型对比时有据可依 | | 《DDIA》Martin Kleppmann | 第 3 章（存储与检索）+ 第 9 章（一致性） | 理解"为什么"——列存为什么快、一致性为什么难 | | Apache Flink 官方文档 | 流批一体 + Table API | 理解实时计算引擎的核心设计，为什么 Flink 能统一流和批 | | Apache Iceberg 文档 | Architecture + Performance | 理解湖仓一体的底层设计，对比 Hudi/Delta Lake | | 字节跳动技术博客 | 搜索"数据中台" / "实时数仓" | 看一线互联网公司的数据架构演进路径 |
⚠️ 常见误区
误区 1：大数据等于 Hadoop
现在很多场景用不到 Hadoop 全家桶。StarRocks / ClickHouse 单机就能处理 TB 级数据，Presto / Trino 能直接查 S3 上的数据文件。选型要匹配数据量和需求，不是越"大"越好。
误区 2：实时一定比批处理好
实时系统更复杂（状态管理、exactly-once、反压）、成本更高（需要更多资源保低延迟）、数据一致性更难保证（看到的数据可能是"部分更新"的）。很多场景 T+1 就够了，不要为了实时而实时。
误区 3：湖仓一体是银弹
湖仓一体解决了 ACID 事务和时间旅行的问题，但引入了额外复杂度（元数据管理、Compaction 调优、小文件问题）。小团队（数据量 < 10TB、分析师 < 5 人）用传统数仓 + 好的建模就够了。
误区 4：架构图是给别人看的
架构图首先是给自己理清思路用的。如果你画不出当前架构的数据流向，说明你对系统的理解还停留在"局部"。画架构图的过程就是发现瓶颈的过程。
🔗 工程映射
| 模型 | 真实场景 | 为什么会发生 | |------|---------|-------------| | 存储-计算分离 | Snowflake 架构：存储用 S3，计算按需弹性伸缩，用户按查询量付费 | 存储成本持续下降（S3），计算需要弹性应对高峰，分开才能各自优化 | | 数据分层 | 字节跳动数据中台：ODS 原始日志 → DWD 清洗标准化 → DWS 聚合业务指标 → ADS 报表 API | 分层解耦了"数据采集"和"数据应用"，改需求时不用重跑原始数据 | | OLAP 选型 | 你当前工作中的 StarRocks：为什么选它而不是 ClickHouse？ | StarRocks 支持实时更新（Primary Key 模型）+ 联邦查询（外表 Join），适合你公司的混合场景 | | 流批一体 | Flink 流批统一 API：同一套 SQL 既能做实时也能做离线 | 流和批本质都是"数据处理"，统一 API 降低维护成本，减少流批不一致问题 | | 容量规划 | 设备从 10 万到 1000 万：写入 QPS 增长 100 倍，存储增长 100 倍 | 线性扩展可能不够，需要重新设计分区策略、引入冷热分离、考虑写入合并 |
✅ 通关标准（可验证）
- [ ] 画出当前工作数据架构图，标注技术选型和瓶颈点
- [ ] 完成 OLAP 三选一对比表，能说出"为什么选 StarRocks"
- [ ] 完成湖仓一体调研，能解释 Iceberg / Hudi / Delta Lake 的核心差异
- [ ] 写出设备 10 万→1000 万的架构升级方案，包含瓶颈分析和改造计划
- [ ] 能解释"存储-计算分离"的 trade-off：好处是什么，代价是什么
📚 论文阅读清单
阅读策略
泛读（30-40 篇）：读摘要 + 图表 + 结论，3-5 分钟/篇，记一句话笔记 精读（8-10 篇）：逐段读，复现核心方法，记详细笔记 研读（2-3 篇）：跟着做实验/改参数，作为通关论文的参考
搜索渠道：Google Scholar、arXiv、Semantic Scholar、Papers With Code
🔴 必读（精读 8-10 篇）
| # | 论文 | 来源/年份 | 核心方法 | 一句话总结 | 状态 | |---|------|----------|---------|-----------|------| | 1 | Big Data: A Survey | ACM Computing Surveys 2013 (Chen et al.) | 大数据技术全景 | 从数据生成、存储、处理到分析的全景综述，是理解数据架构的地图 | ⬜ | | 2 | Lambda Architecture: How to Build Near-Real-Time Big Data Systems | （Marz, 2015） | Lambda 架构 | 批处理层 + 速度层 + 服务层三层架构，平衡了数据准确性和实时性 | ⬜ | | 3 | Lakehouse: A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics | CIDR 2021 (Armbrust et al.) | 湖仓一体 | 在数据湖上叠加仓库能力（ACID 事务 + Schema），Databricks Delta Lake 的理论基础 | ⬜ | | 4 | The Dataflow Model: A Practical Approach to Balancing Correctness, Latency, and Cost | VLDB 2015 (Akidau et al.) | 流批统一模型 | Google Dataflow 的理论框架，统一了批处理和流处理的编程模型 | ⬜ | | 5 | ClickHouse as a Statistical OLAP | （ClickHouse 官方文档/论文） | 列式 OLAP 引擎 | 列存 + 向量化执行 + 稀疏索引，是 OLAP 引擎设计的经典案例 | ⬜ | | 6 | Data Mesh: Delivering Value-Driven Decentralized Data Architecture at Scale | O'Reilly 2022 (Dehghani) | Data Mesh | 数据应该像产品一样由领域团队拥有和治理，而非集中式数据湖 | ⬜ | | 7 | StarRocks: A High-Performance Analytical Database | （搜索 VLDB/SIGMOD） | 向量化 OLAP | MPP 架构 + 向量化执行 + CBO 优化器，ClickHouse 的强力竞争者 | ⬜ | | 8 | The Log: What every software engineer should know about real-time data's unifying abstraction | （Kreps, 2013） | 事件流/日志抽象 | 理解 Kafka 等消息队列的理论基础——日志是分布式系统的核心抽象 | ⬜ | | 9 | Designing Data-Intensive Applications | O'Reilly 2017 (Kleppmann) | 数据系统设计 | 不是论文但胜似论文——从存储引擎到分布式系统，数据工程师的必读圣经 | ⬜ | | 10 | Apache Druid: A Real-time Analytical Data Store | SIGMOD 2020 (Yang et al.) | 实时 OLAP | 列存 + 倒排索引 + 预聚合，适合实时多维分析场景 | ⬜ |
🟡 推荐阅读（泛读 30-40 篇）
以下为推荐方向和关键词，自行搜索补充。目标是积累 30-40 篇的一行笔记。
搜索关键词：
- data warehouse Kimball Inmon dimensional modeling
- ETL vs ELT data pipeline patterns
- stream processing Flink Spark Structured Streaming
- data lake storage format Parquet ORC Avro
- real-time analytics OLAP engine comparison
- data pipeline orchestration Airflow Dagster
- change data capture CDC Debezium
- data catalog metadata management
泛读笔记：
| # | 论文 | 来源 | 跟我什么关系（一句话） | 状态 | |---|------|------|---------------------|------| | 1 | Apache Spark: A Unified Engine for Big Data Processing | CACM 2016 (Zaharia et al.) | Spark 是当前大数据处理的事实标准，理解其 RDD/DataFrame 抽象有助于理解分布式计算 | ⬜ | | 2 | Resilient Distributed Datasets: A Fault-Tolerant Abstraction for In-Memory Cluster Computing | NSDI 2012 (Zaharia et al.) | RDD 是 Spark 的核心抽象，理解其血缘关系和容错机制是理解 Spark 的关键 | ⬜ | | 3 | The Apache Iceberg Table Format: A Foundation for Data Lakehouse | （搜索 Apache Iceberg 文档） | Iceberg 解决了数据湖的 ACID 事务和 Schema 演进问题 | ⬜ | | 4 | （自行搜索添加） | | | ⬜ | | 5 | （自行搜索添加） | | | ⬜ |
🟢 研读候选（选 2-3 篇）
从精读中选出最有价值的 2-3 篇，作为通关论文写作的主要参考。
| # | 论文 | 为什么选这篇 | 状态 | |---|------|------------|------| | 1 | | | ⬜ | | 2 | | | ⬜ | | 3 | | | ⬜ |
💡 以上论文清单为基础推荐，请根据学习过程中发现的高质量文献自行补充。