DDIA 导读 CH1 — 数据密集型系统设计的取舍

《Designing Data-Intensive Applications》一书是剑桥大学分布式系统研究员 Martin Kleppmann 于 2017 年所写的指南，在出版至今已成为系统设计入门必读的书籍之一。在 2026 年该书再版，我们将在 2026 年的 E+ 后端主题文中，逐一导读我们在每个章节读到的重点，以及从中获得的学习。

在 《Designing Data-Intensive Applications》的第一与第二版，作者都从全局的角度切入，来谈个数据密集型应用系统中，应该要关注的面向。

在第一版中，作者从可靠 (reliability)、可扩展 (scalability) 以及可维护 (maintainability) 这三个角度切入来谈 。但在第二版，则是透过「在实务系统设计中，团队的后端负责人应该做什么取舍」切入来谈。由于作者在第二版可靠、可扩展、可维护等概念融入第二章节，我们在这章会着重在第二版的内容，下一次导读才会谈那三个重要的非功能性需求概念。

回到这本书的标题，作者认为在谈数据密集型 (data-intensive) 的应用时，都应与「运算密集型」的应用做区别。对于运算密集型的应用来说，核心重点在于如何加速完成运算，所以探讨的重点会着重在运算的并行化处理等方向。

不过数据密集型的应用，着重面向则会偏向如何处理数据，包含

• 如何存数据? (在各式各样数据库中，该选哪一种来存)
• 如何加速读到数据? (例如通过缓存等手段)
• 如何让搜寻与过滤数据变快? (例如通过搜寻索引)
• 如何让同样的数据更即时被处理? (例如通过流处理)
• 如何让大量累积的数据被定时处理? (例如通过批处理)

上面这些问题，每一个都是实务上需要做判断与选择的，在后续的章节也会分别展开来谈。在第一章节则会先从整体的角度，来谈一些实务上需要做的取舍。

系统是事务型 (Operational)还是分析型 (Analytical)?

当一个数据系统所需处理的数据量还不大时，其实不太会有区分的需求，SQL 数据库的灵活性大，要做事务型或分析型任务都没问题。然而如果数据量体变大，例如电商平台有数十万商品、社群媒体有百万用户时，如果没有进一步区分事务型与分析型，而是一个系统处理所有任务，通常会遇到一些问题。

最常见的问题是，因为系统除了后端工程师会用以外，数据分析师、数据科学家也会需要用到。但如果系统大到有百万、千万级别的数据，数据分析师要调数据出来时，可能会让系统变得卡顿。这时如果不请数据分析师暂停手边的分析工作，会让用户因为卡顿而有不好的体验；但如果请数据分析师暂停，那他们没办法做分析，就没办法进一步创造商业价值。

正是因为有这种抢资源的冲突，现代的大型、数据密集型系统，多半会拆分不同系统来分别处理这两类任务。具体来说，可以大致归类为 Online Transaction Processing (简称 OLTP) 来处理事务型任务，以及 Online Analytical Processing (简称 OLAP) 来处理分析型任务。

OLTP 系统多半是由后端的不同服务组成，会依据用户的操作，来执行对应的读取与修改。OLTP 的特点是单次处理的数据量比较小，例如更新某一笔数据；此外，由于是随着用户操作来执行，OLTP 处理的数据都会是当前状态下最新的。

OLAP 则是数据科学家与分析师在使用的系统。由于需要做分析，OLAP 系统多半不会去做数据的修改，而是会聚焦在查询。同时，查询的数据范围比较大 (例如要找某个商家在过去一年的总收入，就得拉出一整年的营收数据来聚合)。业界中常见的 OLAP 包含 BigQuery、Redshift、Snowflake，或是开源的 ClickHouse 等等。

数据仓库 （Data Warehouse) 与数据湖 (Data Lake)

前面谈到，基于分析的需求，在数据密集型应用中，会在 OLTP 系统外，再多拉出另一个单独的系统处理分析需求，在这个背景下数据仓库 （Data Warehouse) 的概念被提出，也一度成为最热门的 OLAP 选项。

数据仓库是让数据科学家与分析师，可以随心所欲查询、不用担心影响到 OLTP 的操作。假如今天在整体系统中，有几个不同的 OLTP 数据库，例如处理销售相关的 Sales DB、处理仓储相关的 Inventory DB，以及处理送货路线规划的 Geo DB，可以通过 ETL 的过程 (Extract-Transform-Load 也就是截取完数据后做转换与清洗，最后再汇入) 的方式，存到数据仓库中。数据科学家与分析师，可以直接对数据仓库做查询，不用对 Sales DB 或 Inventory DB 做查询，这样就不会影响到后端工程师。

数据仓库虽然好用，但是有个必须面对的取舍。 ETL 过程会先做转换 (数据清洗、格式统一化等)，这种预先定义好数据结构再载入的方式，虽然能让查询时能用轻易用优化的 SQL 语句来查，但同时也降低了灵活性。

特别是随着试验与分析的需求变复杂，很多数据科学家想用的数据，不属于传统关联数据库的格式，为了让数据能够被各类需求都使用，数据湖 (Data Lake) 的概念被提出。数据湖的概念是 ELT，截取后就载入，载入后的数据没有强制特定的格式，仅是作为集合，在要用的时候，再转换成当下需要的格式，这样一来就能够因应各类不同的分析需求。

阅读更多

以上我们导读了 DDIA 第一章谈到的第一个取舍。除了这个取舍外，书中还有谈到两个实务上常见的取舍，完整版的导读可以在 E+ 成长计划中的主题文读到。

对更深入了解这个主题，以及其他前后端开发、软件工程、AI 工程主题感兴趣的读者，欢迎加入 E+ 成长计划一起成长 (链接)。