learning.oreilly.com
↗
原文链接
designing-data-intensive-applications
数据密集型应用的一些常见需求
Such applications are typically built from standard building blocks that provide commonly needed functionality. For example, many applications need to:
- Store data so that they, or another application, can find it again later (databases)
- Remember the result of an expensive operation, to speed up reads (caches)
- Allow users to search data by keyword or filter it in various ways (search indexes)
- Handle events and data changes as soon as they occur (stream processing)
- Periodically crunch a large amount of accumulated data (batch processing)
Operational Versus Analytical Systems 运营系统与分析系统#
OLTP vs OLAP：数据处理的分流#
OLTP也即运营系统，OLAP也即分析系统。这两种类型决定了数据库选型和架构设计。
| 特性 | OLTP (联机事务处理) | OLAP (联机分析处理) |
|---|---|---|
| 主要目标 | 支撑业务运行（如下单、支付、评论） | 商业决策与洞察（如报表、趋势预测、ML） |
| 用户 | 终端用户、后端服务（Java应用） | 业务分析师 (BI)、数据科学家 |
| 读写模式 | 点查询 (Point Query)，按Key读写，低延迟 | 全表扫描，聚合计算 (Sum, Count)，高吞吐 |
| 数据状态 | 当前最新状态 (Current State) | 历史事件流 (History of events) |
| 数据量级 | GB ~ TB | TB ~ PB |
| 典型代表 | MySQL, PostgreSQL, Oracle | Redshift, Snowflake, ClickHouse |
数据基础设施的演进#
为了解决OLTP和OLAP的冲突，架构发生了演变：
- Data Warehouse（数据仓库）
- 目的：将数据从各业务库提取出来，清洗并转换（extract-transform-load, ETL）后存入一个专门的分析数据库。
- 特点：Schema-on-write（写时模式），通常是关系型的，适合SQL和BI报表。
- Data Lake（数据湖）
- 背景：数据科学家需要非结构化数据（文本、图像）或原始数据进行机器学习，SQL不够用了。
- 特点：Schema-on-read（读时模式），存原始文件（如Parquet, Avro），符合"Sushi Principle"（raw data is better）。
数据流向：记录系统 vs 派生数据#
- System of Record (记录系统/真理源)：数据的权威版本。如果数据不一致，以此处为准。通常是你的 Java 应用连接的 OLTP 数据库。
- Derived Data Systems (派生数据系统)：通过某种方式从记录系统转换而来的数据。
- 例子：搜索索引（Elasticsearch）、缓存（Redis）、数据仓库、机器学习模型。
- 本质：它们是冗余的，如果丢失，可以从源头重建。它们的存在是为了读取性能或特定查询场景（如全文检索、分析）。
