DDIA 第一章：数据系统架构中的利弊权衡
记录 DDIA 一书的阅读笔记
核心思想：没有银弹，只有权衡
“没有解决方案，只有利弊权衡。[…] 尽你所能获取最好的利弊权衡，这是你唯一能指望的事。” - Thomas Sowell
这一章的核心思想是，在数据系统设计中，不存在绝对的“最佳”方案。每种技术选择都有其优点和缺点，需要根据具体的应用场景和需求进行权衡。本书的目标是帮助你理解这些权衡，提出正确的问题，从而做出明智的决策。
数据密集型应用 vs. 计算密集型应用
- 数据密集型应用 (Data-Intensive Applications): 主要挑战在于数据的管理，包括存储、处理、一致性、可用性等。
- 计算密集型应用 (Compute-Intensive Applications): 主要挑战在于并行化大规模计算。
大多数现代应用都是数据密集型的，因为数据是应用的核心。
数据密集型应用的常见构建块
大多数数据密集型应用都需要以下功能：
- 数据库 (Databases): 存储数据，以便稍后可以再次找到。
- 缓存 (Caches): 记住昂贵操作的结果，加速读取。
- 搜索索引 (Search Indexes): 允许用户按关键词搜索数据或以各种方式过滤。
- 流处理 (Stream Processing): 实时处理事件和数据变化。
- 批处理 (Batch Processing): 定期处理大量累积的数据。
构建应用通常涉及将这些构建块（通常是多个软件系统或服务）与应用代码结合起来。
本章主要对比概念和权衡
本章探讨了以下几个关键的对比概念，并分析了它们的利弊：
- 事务处理 vs. 分析 (Transaction Processing vs. Analytics):
- OLTP (Online Transaction Processing) vs. OLAP (Online Analytical Processing)
- 业务系统 vs. 分析系统
- 数据仓库、数据湖、数据湖仓
- 云服务 vs. 自托管 (Cloud Services vs. Self-Hosting):
- 成本、可控性、可扩展性、运营复杂性
- 云原生系统架构：分层、存储与计算分离
- 云时代的运营：DevOps/SRE、自动化、弹性
- 分布式 vs. 单节点系统 (Distributed vs. Single-Node Systems):
- 可扩展性、容错性、延迟、复杂性
- 微服务与无服务器 (Microservices and Serverless)
- 云计算与超算 (Cloud Computing and Supercomputing)
- 数据系统、法律与社会 (Data Systems, Law, and Society):
- 隐私法规 (GDPR, CCPA)
- 数据最小化原则 (Datensparsamkeit)
- 伦理考量
1. 事务处理与分析 (Transaction Processing vs. Analytics)
术语：前端与后端
- 前端 (Frontend): 客户端代码（在浏览器中运行）或移动应用，提供用户界面。
- 后端 (Backend): 服务器端代码，处理用户请求。通常包含应用代码和数据基础设施（数据库、缓存、消息队列等）。
- 后端服务通常是无状态的 (stateless)，任何需要持久化的信息都存储在客户端或服务器端的数据基础设施中。
业务系统 vs. 分析系统
- 业务系统 (Operational Systems):
- 也称为在线事务处理 (OLTP) 系统。
- 处理用户请求，读取和修改数据。
- 通常通过键查找少量记录（点查询）。
- 根据用户输入插入、更新或删除记录。
- 数据表示最新状态。
- 数据集大小：GB 到 TB。
- 分析系统 (Analytical Systems):
- 也称为在线分析处理 (OLAP) 系统。
- 服务于商业分析师和数据科学家。
- 包含来自业务系统的只读副本。
- 通常扫描大量记录，计算聚合统计数据。
- 数据表示随时间发生的事件历史。
- 数据集大小：TB 到 PB。
- 用户可以进行任意查询(分析师), 业务系统用户通常无法执行自定义SQL
表 1-1. OLTP 与 OLAP 的典型特征
| 属性 | 业务系统 (OLTP) | 分析系统 (OLAP) |
|---|---|---|
| 主要读取模式 | 点查询（按键提取个别记录） | 在大量记录上聚合 |
| 主要写入模式 | 创建、更新和删除个别记录 | 批量导入（ETL）或事件流 |
| 人类用户示例 | 网络/移动应用的终端用户 | 内部分析师，用于决策支持 |
| 机器使用示例 | 检查是否授权某项行动 | 检测欺诈/滥用模式 |
| 查询类型 | 固定的查询集合，由应用预定义 | 分析师可以进行任意查询 |
| 数据表示 | 数据的最新状态（当前时间点） | 随时间发生的事件历史 |
| 数据集大小 | 千兆字节至太字节 | 太字节至拍字节 |
数据仓库 (Data Warehouse)
- 一个独立的数据库，分析师可以尽情查询，而不影响 OLTP 操作。
- 包含公司所有各种 OLTP 系统中的数据的只读副本。
- 数据通过 ETL (Extract-Transform-Load) 过程从 OLTP 数据库提取、转换、加载到数据仓库。
- 通常使用关系数据模型，通过 SQL 查询。
数据湖 (Data Lake)
- 一个集中的数据存储库，存放可能对分析有用的任何数据。
- 通过 ETL 过程从业务系统获取数据。
- 不强加任何特定的文件格式或数据模型。
- 包含由业务系统产生的“原始”形式的数据。
- 优点：每个数据的消费者都可以将原始数据转换成最适合其需要的形式（寿司原则：“原始数据更好”）。
数据湖仓 (Data Lakehouse)
- 结合了数据湖和数据仓库的优点。
- 直接在数据湖中的文件上运行数据仓库工作负载（SQL 查询和商业分析）以及数据科学/机器学习工作负载。
- 需要一个查询执行引擎和一个元数据层来扩展数据湖的文件存储。
- 例子：Apache Hive, Spark SQL, Presto, Trino.
记录系统 vs. 衍生数据系统
- 记录系统 (Systems of Record):
- 也称为真实来源 (Source of Truth)。
- 持有某些数据的权威或规范版本。
- 每个事实只表示一次（通常是规范化的）。
- 衍生数据系统 (Derived Data Systems):
- 数据是从另一个系统获取并转换或处理的结果。
- 如果丢失，可以从原始来源重新创建。
- 例子：缓存、索引、物化视图、机器学习模型。
2. 云服务 vs. 自托管 (Cloud Services vs. Self-Hosting)
软件及其运营的类型范围
- 定制软件 (Bespoke Software): 自己编写并在内部运行。
- 现成软件 (Off-the-Shelf Software): 自己托管（开源或商业）。
- 云服务/SaaS (Cloud Services/Software as a Service): 由外部供应商实施和操作，通过 Web 界面或 API 访问。
云服务的优缺点
- 优点：
- 节省时间和金钱（取决于具体情况）。
- 更容易扩展计算资源以匹配负载。
- 外包运营可以释放团队，专注于更高层次的问题。
- 提供商从为许多客户提供服务中获得运营专长。
- 缺点：
- 对服务没有控制权。
- 如果服务出现故障或变得昂贵，将受制于供应商。
- 诊断问题困难。
- 可能存在供应商锁定问题。
云原生系统架构
- 云原生 (Cloud-Native): 一种旨在利用云服务优势的架构。
- 分层 (Layered Architecture): 构建在更低层级的云服务之上，创建更高层级的服务（例如，对象存储 -> 数据仓库）。
- 存储与计算分离 (Separation of Storage and Compute):
- 传统系统：同一台计算机负责存储和计算。
- 云原生系统：存储和计算解耦，通过网络传输数据。
- 多租户 (Multitenancy): 在同一共享硬件上处理来自多个客户的数据和计算。
云时代的运营
- 传统角色： 数据库管理员 (DBAs)、系统管理员 (Sysadmins)。
- 现代趋势： DevOps, SRE (Site Reliability Engineering)。
- DevOps/SRE 哲学：
- 自动化 (Automation)
- 短暂的虚拟机和服务 (Ephemeral VMs and Services)
- 频繁的应用更新 (Frequent Application Updates)
- 从事件中学习 (Learning from Incidents)
- 保留组织知识 (Preserving Organizational Knowledge)
- 云服务客户的运营关注点：
- 选择最适合特定任务的服务
- 将不同服务相互集成
- 从一个服务迁移到另一个服务
- 成本优化 (Cost Optimization)
- 了解资源限制或配额 (Quotas)
3. 分布式 vs. 单节点系统 (Distributed vs. Single-Node Systems)
何时需要分布式系统
- 固有的分布式系统 (Inherently Distributed Systems): 涉及多个用户和设备。
- 云服务间的请求 (Requests between Cloud Services): 数据存储在一个服务中但在另一个服务中处理。
- 容错/高可用性 (Fault Tolerance/High Availability): 使用多台机器提供冗余。
- 可扩展性 (Scalability): 将负载分散到多台机器上。
- 延迟 (Latency): 在全球各地设置服务器，减少用户请求延迟。
- 弹性(Elasticity): 云部署可以根据需求扩展或缩减
- 使用专用硬件(Using specialized hardware) 不同的硬件匹配不同的工作负载
- 法律合规(Legal compliance) 有些国家有数据居留法律
分布式系统的问题
- 网络故障： 请求可能超时，重试可能不安全。
- 延迟： 调用另一个服务比在同一进程中调用函数慢。
- 调试困难： 确定问题所在具有挑战性（可观测性技术）。
- 数据一致性： 跨多个服务维护数据一致性成为应用程序的问题（分布式事务）。
微服务与无服务器 (Microservices and Serverless)
- 微服务 (Microservices):
- 每个服务都有一个明确定义的目的。
- 每个服务都暴露一个可以通过网络调用的 API。
- 每个服务都有一个负责其维护的团队。
- 优点：独立更新、资源分配、隐藏实现细节。
- 缺点：复杂性、测试困难、API 演进挑战。
- 无服务器 (Serverless/Function-as-a-Service):
- 基础设施管理外包给云供应商。
- 自动分配和释放硬件资源。
- 按实际运行时间付费。
云计算与超算 (Cloud Computing and Supercomputing)
- 云计算 (Cloud Computing):
- 用于在线服务、商业数据系统等。
- 需要高可用性。
- 通常由商品机构建。
- 网络基于 IP 和以太网。
- 节点可以分布在多个地理位置。
- 超算 (Supercomputing/High-Performance Computing):
- 用于计算密集型的科学计算任务。
- 运行大型批处理作业。
- 通常由专用硬件构建。
- 使用专用的网络拓扑。
- 假设所有节点都靠近在一起。
4. 数据系统、法律与社会 (Data Systems, Law, and Society)
- 隐私法规：
- GDPR (General Data Protection Regulation): 欧洲。欧盟的《通用数据保护条例》。
- CCPA (California Consumer Privacy Act): 加利福尼亚。
- 欧盟人工智能法案 (EU AI Act)。
- 数据最小化原则 (Data Minimization/Datensparsamkeit):
- 只收集和存储必要的数据。强调只收集和存储为了特定目的所必需的个人数据，并且数据的保存时间不应超过实现该目的所需的时间。
- 与“大数据”哲学相悖。传统的“大数据”理念鼓励尽可能多地收集和存储数据，认为这些数据在未来可能会有用。
- 符合 GDPR。
- 伦理考量：
- 计算机系统对人和社会的影响。
- 自动化决策的偏见和歧视。
总结
本章强调了数据系统设计中的权衡，介绍了本书将使用的术语，并探讨了以下几个关键对比概念：
- 事务处理 vs. 分析
- 云服务 vs. 自托管
- 分布式 vs. 单节点系统
- 数据系统、法律与社会
理解这些权衡对于构建可靠、可扩展、高效且符合伦理的数据密集型应用至关重要。