ch1-数据系统架构中的权衡

第 1 章 数据系统架构中的权衡

不存在所谓的解决方案，只有权衡。[……]但你要尽力争取最佳的权衡，这就是你所能期望的全部。

——托马斯·索维尔（Thomas Sowell），2005 年接受弗雷德·巴恩斯（Fred Barnes）采访

致早期发行版读者的说明

通过早期发行版电子书，你可以在作者撰写过程中获取最原始、未经编辑的内容——这样你就能在这些书籍正式发布之前，抢先掌握这些技术。

这将是本书最终版本的第 1 章。本书的 GitHub 仓库地址为：https://github.com/ept/ddia2-feedback

如果你希望积极参与本草稿的审阅和评论，请在 GitHub 上联系我们。

1.1 数据在现代应用开发中的核心地位

如今，数据已成为许多应用开发的核心。随着 Web 和移动应用、软件即服务（SaaS）以及云服务的普及，将来自众多不同用户的数据存储在共享的服务器端数据基础设施中已成为常态。用户活动、业务交易、设备和传感器产生的数据都需要被存储并用于分析。当用户与应用程序交互时，他们既会读取已存储的数据，也会生成更多数据。

少量数据可以存储和处理在单台机器上，通常相对容易处理。然而，随着数据量或查询速率的增长，数据需要分布在多台机器上，这带来了许多挑战。随着应用需求变得更加复杂，仅仅将所有内容存储在一个系统中已不再足够，可能需要组合多个提供不同功能的存储或处理系统。

如果数据管理是开发应用的主要挑战之一，我们称该应用为数据密集型应用 1。在计算密集型系统中，挑战在于并行化某些大型计算；而在数据密集型应用中，我们通常更关注以下问题：存储和处理大量数据、管理数据变更、在故障和并发情况下确保一致性，以及确保服务的高可用性。

这类应用通常由提供常用功能的标准构建模块组成。例如，许多应用需要：

  • 存储数据，以便自身或其他应用日后能够再次查找（数据库）
  • 记住昂贵操作的结果，以加速读取（缓存）
  • 允许用户通过关键词搜索数据或以各种方式过滤数据（搜索索引）
  • 在事件和数据变更发生时立即处理（流处理）
  • 定期处理大量累积数据（批处理）

在构建应用时，我们通常采用多个软件系统或服务（如数据库或 API），并通过一些应用代码将它们粘合在一起。如果你所做的正是这些数据系统为之设计的任务，那么这个过程可能相当简单。

然而，随着应用变得更加雄心勃勃，挑战也随之出现。有许多具有不同特性的数据库系统，适用于不同目的——你应该选择哪一个？有各种缓存方法、多种构建搜索索引的方式等等——你如何权衡它们的利弊？你需要找出哪些工具和方法最适合手头的任务，而当你需要完成单个工具无法独自完成的任务时，组合工具可能会很困难。

本书旨在帮助你决定使用哪些技术以及如何组合它们。如你所见，没有一种方法在根本上优于其他方法；一切都有利有弊。通过本书，你将学会提出正确的问题来评估和比较数据系统，从而找出最能满足你特定应用需求的方法。

我们将通过审视当今组织中数据的一些典型使用方式来开始我们的旅程。这里的许多思想起源于企业软件（即大型组织，如大公司和政府的软件需求和工程实践），因为从历史上看，只有大型组织才拥有需要复杂技术解决方案的大量数据。如果你的数据量足够小，你可以简单地将其保存在电子表格中！然而，最近小型公司和初创企业管理大量数据并构建数据密集型系统也变得越来越普遍。

数据系统的一个关键挑战是，不同的人需要用数据做非常不同的事情。如果你在公司工作，你和你的团队有一套优先事项，而另一个团队可能有完全不同的目标，即使你们可能在使用相同的数据集！此外，这些目标可能没有明确表达，这可能导致对正确方法的误解和分歧。

为了帮助你理解可以做出哪些选择，本章比较了几个对比鲜明的概念，并探讨了它们的权衡：

  • 操作系统和分析系统之间的区别（“分析系统与操作系统”）
  • 云服务和自建系统的优缺点（“云服务与自建托管”）
  • 何时从单节点系统转向分布式系统（“分布式与单节点系统”）
  • 平衡业务需求和用户权利（“数据系统、法律与社会”）

此外，本章还将提供我们在本书其余部分需要的术语。

术语：前端与后端

本书中讨论的许多内容都与后端开发相关。为了解释这个术语：对于 Web 应用，在 Web 浏览器中运行的客户端代码称为前端，处理用户请求的服务器端代码称为后端。移动应用类似于前端，因为它们提供用户界面，通常通过互联网与服务器端后端通信。前端有时会在用户设备上本地管理数据2，但最大的数据基础设施挑战通常在于后端：前端只需要处理一个用户的数据，而后端代表所有用户管理数据。

后端服务通常可通过 HTTP（有时是 WebSocket）访问；它通常由一些应用代码组成，这些代码在一个或多个数据库中读写数据，有时还与额外的数据系统（如缓存或消息队列，我们可以统称为数据基础设施）交互。应用代码通常是无状态的（即，当它完成处理一个 HTTP 请求后，会忘记关于该请求的所有信息），任何需要从一次请求持久化到另一次请求的信息都需要存储在客户端或服务器端数据基础设施中。

1.2 分析系统与操作系统

如果你在企业中从事数据系统工作，你可能会遇到几种不同类型使用数据的人。第一类是后端工程师，他们构建处理数据读取和更新请求的服务；这些服务通常服务于外部用户，直接或通过其他服务间接服务（参见”微服务与无服务器”）。有时服务供组织其他部分内部使用。

除了管理后端服务的团队外，通常还有另外两组人需要访问组织的数据：业务分析师，他们生成关于组织活动的报告，以帮助管理层做出更好的决策（商业智能或 BI）；以及数据科学家，他们在数据中寻找新颖见解，或创建由数据分析和机器学习/AI 支持的用户面向产品功能（例如，电商网站上的”购买 X 的人也购买了 Y”推荐、风险评分或垃圾邮件过滤等预测分析，以及搜索结果排名）。

尽管业务分析师和数据科学家倾向于使用不同的工具并以不同的方式运作，但他们有一些共同点：两者都执行分析，这意味着他们查看用户和后端服务生成的数据，但通常不会修改这些数据（除了可能修正错误）。他们可能会创建派生数据集，其中原始数据以某种方式被处理。这导致了两种系统之间的划分——我们将在本书中使用的区分：

操作系统（OLTP）分析系统（OLAP）
主要读取模式点查询（按键获取单个记录）对大量记录进行聚合
主要写入模式创建、更新和删除单个记录批量导入（ETL）或事件流
人类用户示例Web/移动应用的终端用户内部分析师，用于决策支持
机器使用示例检查操作是否被授权检测欺诈/滥用模式
查询类型应用预定义的固定查询集分析师可以进行任意查询
数据表示数据的最新状态（当前时间点）随时间发生的事件历史
数据集大小千兆字节到兆兆字节兆兆字节到千兆兆字节
  • 操作系统：由后端服务和数据基础设施组成，数据在此创建，例如通过服务外部用户。在这里，应用代码根据用户执行的操作读取和修改其数据库中的数据。
  • 分析系统：服务于业务分析师和数据科学家的需求。它们包含来自操作系统的数据的只读副本，并针对分析所需的数据处理类型进行优化。

正如我们将在下一节中看到的，操作系统和分析系统通常保持分离，这是有充分理由的。随着这些系统的成熟，两个新的专业角色应运而生：数据工程师和分析工程师。数据工程师是知道如何集成操作系统和分析系统的人，并对组织更广泛的数据基础设施负责3。分析工程师对数据进行建模和转换，使其对组织中的业务分析师和数据科学家更有用4。

许多工程师专门研究操作系统或分析系统的一方。然而，本书涵盖了操作系统和分析数据系统，因为两者在组织内数据生命周期中都发挥着重要作用。我们将深入探讨用于向内部和外部用户交付服务的数据基础设施，以便你能更好地与处于这种分工另一端的同事合作。

事务处理与分析的特征

在商业数据处理的早期，对数据库的写入通常对应于正在发生的商业交易：进行销售、向供应商下订单、支付员工工资等。随着数据库扩展到不涉及资金转移的领域，事务一词仍然保留下来，指的是形成逻辑单元的一组读取和写入。

注意 第 8 章详细探讨了我们所说的交易的含义。本章宽松地使用该术语来指代低延迟的读取和写入。

尽管数据库开始被用于许多不同类型的数据——社交媒体帖子、游戏中的移动、通讯录中的联系人等等——基本访问模式仍然类似于处理商业交易。操作系统通常通过某个键查找少量记录（这称为点查询）。根据用户输入插入、更新或删除记录。由于这些应用是交互式的，这种访问模式被称为在线事务处理（OLTP）。

然而，数据库也开始越来越多地用于分析，这与 OLTP 相比具有非常不同的访问模式。通常，分析查询会扫描大量记录，并计算聚合统计信息（如计数、总和或平均值），而不是将单个记录返回给用户。例如，超市连锁店的业务分析师可能希望回答以下分析查询：

  • 我们每家商店一月份的总收入是多少？
  • 在最近一次促销期间，我们比平常多卖了多少香蕉？
  • 哪种品牌的婴儿食品最常与 X 品牌尿布一起购买？

这些类型查询产生的报告对商业智能很重要，帮助管理层决定下一步该做什么。为了将这种使用数据库的模式与事务处理区分开来，它被称为在线分析处理（OLAP）5。OLTP 和分析之间的区别并不总是泾渭分明，但表 1-1 列出了一些典型特征。

注意 OLAP 中”在线”的含义不明确；它可能指的是查询不仅用于预定义报告，而且分析师使用 OLAP 系统进行交互式探索查询。

在操作系统中，通常不允许用户构造自定义 SQL 查询并在数据库上运行，因为这可能允许他们读取或修改他们没有权限访问的数据。此外，他们可能编写执行成本高昂的查询，从而影响其他用户的数据库性能。由于这些原因，OLTP 系统主要运行业务代码中固定的查询集，仅偶尔使用一次性自定义查询进行维护或故障排除。另一方面，分析数据库通常赋予用户自由，可以手工编写任意 SQL 查询，或使用 Tableau、Looker 或 Microsoft Power BI 等数据可视化或仪表板工具自动生成查询。

还有一种系统专为分析工作负载（聚合大量记录的查询）而设计，但嵌入到用户面向产品中。这一类别被称为产品分析或实时分析，为此类用途设计的系统包括 Pinot、Druid 和 ClickHouse6。

1.3 数据仓库

起初，相同的数据库既用于事务处理也用于分析查询。SQL 在这方面证明相当灵活：它对两种类型的查询都适用。然而，在 20 世纪 80 年代末和 90 年代初，出现了一种趋势，公司停止将 OLTP 系统用于分析目的，而是在单独的数据库系统上运行分析。这个单独的数据库被称为数据仓库。

一家大型企业可能有几十个甚至几百个在线事务处理系统：为客户面向网站提供支持的系统、控制实体店中的销售点（结账）系统、跟踪仓库库存、规划车辆路线、管理供应商、管理员工以及执行许多其他任务的系统。这些系统每个都很复杂，需要一组人来维护，因此这些系统最终大多独立运行。

业务分析师和数据科学家直接查询这些 OLTP 系统通常是不可取的，原因有几点：

  1. 数据孤岛：感兴趣的数据可能分布在多个操作系统中，使得在单个查询中组合这些数据集变得困难（这个问题被称为数据孤岛）；
  2. 模式不适配：适合 OLTP 的模式和数据布局类型不太适合分析（参见”星型与雪花型：分析模式”）；
  3. 性能影响：分析查询可能相当昂贵，在 OLTP 数据库上运行它们会影响其他用户的性能；
  4. 安全合规：OLTP 系统可能位于用户因安全或合规原因不被允许直接访问的单独网络中。

相比之下，数据仓库是一个独立的数据库，分析师可以尽情查询，而不会影响 OLTP 操作7。正如我们将在第 4 章中看到的，数据仓库通常以与 OLTP 数据库非常不同的方式存储数据，以优化分析中常见的查询类型。

数据仓库包含公司各种 OLTP 系统中数据的只读副本。数据从 OLTP 数据库中提取（使用定期数据转储或连续更新流），转换为分析友好的模式，清理，然后加载到数据仓库中。将数据导入数据仓库的这个过程称为提取-转换-加载（ETL），如图 1-1 所示。有时转换和加载步骤的顺序会互换（即，转换在数据仓库中加载后进行），结果是 ELT。

[图1-1：ETL到数据仓库的简化示意图]

在某些情况下，ETL 流程的数据源是外部 SaaS 产品，如客户关系管理（CRM）、电子邮件营销或信用卡处理系统。在这些情况下，你无法直接访问原始数据库，因为它只能通过软件供应商的 API 访问。将这些外部系统的数据引入你自己的数据仓库可以实现通过 SaaS API 无法实现的分析。SaaS API 的 ETL 通常由 Fivetran、Singer 或 AirByte 等专业数据连接器服务实现。

一些数据库系统提供混合事务/分析处理（HTAP），旨在在单个系统中实现 OLTP 和分析，而无需从一个系统 ETL 到另一个系统89。然而，许多 HTAP 系统在内部由一个 OLTP 系统和一个单独的分析系统组成，隐藏在通用接口后面——因此两者之间的区分对于理解这些系统的工作原理仍然很重要。

此外，尽管 HTAP 存在，但由于事务系统和分析系统的不同目标和需求，通常仍存在分离。特别是，每个操作系统拥有自己的数据库被认为是良好实践（参见”微服务与无服务器”），导致数百个独立的操作数据库；另一方面，企业通常只有一个数据仓库，以便业务分析师可以在单个查询中组合来自多个操作系统的数据。

因此，HTAP 并不能取代数据仓库。相反，它在同一应用需要既执行扫描大量行的分析查询，又以低延迟读取和更新单个记录的场景中很有用。欺诈检测可能涉及此类工作负载，例如10。

操作系统和分析系统之间的分离是更广泛趋势的一部分：随着工作负载变得更加苛刻，系统变得更加专业化并针对特定工作负载进行优化。通用系统可以舒适地处理小数据量，但规模越大，系统往往变得越专业化11。

从数据仓库到数据湖

数据仓库通常使用通过 SQL 查询的关系数据模型（参见第 3 章），可能使用专门的商业智能软件。这种模型适用于业务分析师需要进行的查询类型，但不太适合数据科学家的需求，他们可能需要执行以下任务：

  • 将数据转换为适合训练机器学习模型的形式；通常这需要将数据库表的行和列转换为称为特征的数值向量或矩阵。以最大化训练模型性能的方式执行此转换的过程称为特征工程，它通常需要难以用 SQL 表达的自定义代码。
  • 获取文本数据（例如产品评论）并使用自然语言处理技术尝试从中提取结构化信息（例如作者的情感，或他们提到的主题）。类似地，他们可能需要使用计算机视觉技术从照片中提取结构化信息。

尽管有人努力将机器学习操作符添加到 SQL 数据模型12，并在关系基础之上构建高效的机器学习系统13，但许多数据科学家更喜欢不在关系数据库（如数据仓库）中工作。相反，许多人更喜欢使用 Python 数据分析库（如 pandas 和 scikit-learn）、统计分析语言（如 R）以及分布式分析框架（如 Spark）14。我们将在”DataFrames、矩阵和数组”中进一步讨论这些。

因此，组织面临需要以适合数据科学家使用的形式提供数据的需求。答案是数据湖：一个集中式数据存储库，保存可能用于分析的任何数据的副本，通过 ETL 流程从操作系统获取。与数据仓库的区别在于，数据湖只包含文件，不施加任何特定的文件格式或数据模型。数据湖中的文件可能是使用 Avro 或 Parquet 等文件格式编码的数据库记录集合（参见第 5 章），但它们同样可以包含文本、图像、视频、传感器读数、稀疏矩阵、特征向量、基因组序列或任何其他类型的数据15。除了更灵活之外，这通常也比关系数据存储更便宜，因为数据湖可以使用商品化文件存储，如对象存储（参见”云原生系统架构”）。

ETL 流程已泛化为数据管道，在某些情况下，数据湖已成为从操作系统到数据仓库路径上的中间站。数据湖包含操作系统产生的”原始”形式数据，没有转换为关系数据仓库模式。这种方法的优点是每个数据消费者可以将原始数据转换为最适合其需求的形式。这被称为寿司原则：“生数据更好”16。

超越数据湖

随着分析实践的成熟，组织越来越关注分析系统和数据管道的管理和运营，例如 DataOps 宣言17所捕捉的那样。其中一部分是治理、隐私和遵守 GDPR 和 CCPA 等法规的问题，我们将在”数据系统、法律与社会”和[链接待补充]中讨论。

此外，分析数据越来越多地不仅以文件和关系表的形式提供，而且以事件流的形式提供（参见第 12 章）。使用基于文件的数据分析，你可以定期（例如每天）重新运行分析以响应数据的变化，但流处理允许分析系统更快地响应事件，在秒级。根据应用及其对时间的敏感程度，流处理方法可能很有价值，例如识别和阻止潜在的欺诈或滥用活动。

在某些情况下，分析系统的输出被提供给操作系统（这个过程有时被称为反向 ETL18）。例如，在分析系统中训练的数据上的机器学习模型可能部署到生产环境，以便为终端用户生成推荐，如”购买 X 的人也购买了 Y”。此类分析系统的部署输出也被称为数据产品19。机器学习模型可以使用 TFX、Kubeflow 或 MLflow 等专业工具部署到操作系统。

1.4 记录系统与派生数据系统

与操作系统和分析系统之间的区分相关，本书还区分了记录系统和派生数据系统。这些术语很有用，因为它们可以帮助你澄清数据通过系统的流动：

记录系统（System of Record）

也称为真相来源，保存某些数据的权威或规范版本。当新数据进入时，例如作为用户输入，首先写入这里。每个事实只表示一次（表示通常是规范化的；参见”规范化、非规范化和连接”）。如果另一个系统与记录系统之间存在任何差异，那么记录系统中的值（根据定义）是正确的。

派生数据系统（Derived Data Systems）

派生系统中的数据是获取来自另一个系统的某些现有数据并以某种方式转换或处理的结果。如果你丢失了派生数据，你可以从原始来源重新创建它。一个经典例子是缓存：如果存在，可以从缓存提供数据，但如果缓存不包含你需要的内容，你可以回退到基础数据库。非规范化值、索引、物化视图、转换后的数据表示以及在数据集上训练的模型也属于这一类别。

从技术上讲，派生数据是冗余的，因为它复制了现有信息。然而，它通常对于在读查询上获得良好性能至关重要。你可以从单个来源派生多个不同的数据集，使你能够从不同的”视角”查看数据。

分析系统通常是派生数据系统，因为它们是别处创建的数据的消费者。操作服务可能包含记录系统和派生数据系统的混合。记录系统是数据首先写入的主数据库，而派生数据系统是加速常见读取操作的索引和缓存，特别是对于记录系统无法有效回答的查询。

大多数数据库、存储引擎和查询语言本身并不是记录系统或派生系统。数据库只是一种工具：如何使用它取决于你。记录系统和派生数据系统之间的区别不在于工具，而在于你在应用中如何使用它。通过明确哪些数据是从哪些其他数据派生的，你可以为原本令人困惑的系统架构带来清晰度。

当一个系统中的数据派生自另一个系统中的数据时，你需要一个流程来在记录系统中的原始数据变更时更新派生数据。不幸的是，许多数据库是基于你的应用只需要使用那一个数据库的假设设计的，它们不便于集成多个系统以传播此类更新。在第 11 章中，我们将讨论数据管道作为数据集成的方法，它允许我们组合多个数据系统以实现单个系统无法独自完成的事情。

这就结束了我们对分析和事务处理的比较。在下一节中，我们将研究另一个你可能已经多次看到讨论的权衡。

1.5 云服务与自建托管

对于组织需要做的任何事情，首要问题之一是：应该在内部完成，还是应该外包？应该自建还是应该购买？

归根结底，这是一个关于业务优先事项的问题。公认的管理智慧是，属于你组织核心能力或竞争优势的事情应该在内部完成，而非核心、常规或 commonplace 的事情应该交给供应商20。举个极端的例子，大多数公司不会自己制造 CPU，因为从半导体制造商那里购买更便宜。

对于软件，需要做出的两个重要决定是谁构建软件以及谁部署它。有一系列可能性，每个决定将外包到不同程度，如图 1-2 所示。一个极端是你编写并在内部运行的定制软件；另一个极端是广泛使用的外部供应商实现的云服务或软件即服务（SaaS）产品，你只能通过 Web 界面或 API 访问。

[图1-2：软件类型及其操作的频谱]

中间地带是你自建托管的现成软件（开源或商业）——例如，如果你下载 MySQL 并将其安装在你控制的服务器上。这可以是在你自己的硬件上（通常称为本地部署，即使服务器实际上在租用的数据中心机架上，而不是字面意义上的在你自己的场所），或在云中的虚拟机上（基础设施即服务或 IaaS）。沿着这个频谱还有更多点，例如，采用开源软件并运行其修改版本。

与这个频谱分开的还有你如何部署服务的问题，无论是在云中还是本地——例如，你是否使用 Kubernetes 等编排框架。然而，部署工具的选择超出了本书的范围，因为其他因素对数据系统架构的影响更大。

云服务的优缺点

使用云服务，而不是自己运行类似的软件，本质上将该软件的操作外包给了云提供商。对于云服务有很好的支持和反对论点。云提供商声称，使用他们的服务比建立自己的基础设施节省时间和金钱，并允许你更快行动。

云服务是否实际上比自建托管更便宜和更容易，很大程度上取决于你的技能和系统的工作负载。如果你已经有设置和运行所需系统的经验，并且你的负载相当可预测（即，你需要的机器数量不会剧烈波动），那么购买自己的机器并在其上自行运行软件通常更便宜2122。

另一方面，如果你需要一个你尚不知道如何部署和操作的系统，那么采用云服务通常比学习自己管理该系统更容易和快捷。如果你必须专门雇佣和培训人员来维护和操作系统，那可能会非常昂贵。即使你使用云，你仍然需要一个运维团队（参见”云时代的运维”），但将基本的系统管理外包可以释放你的团队，让他们专注于更高层次的问题。

当你将系统的操作外包给一家专门运行该服务的公司时，由于提供商从向许多客户提供服务中获得运维专业知识，这可能会带来更好的服务。另一方面，如果你自己运行服务，你可以配置和调整它以在你的特定工作负载上表现良好；云服务不太可能愿意代表你进行此类定制。

如果你的系统负载随时间变化很大，云服务特别有价值。如果你配置机器以处理峰值负载，但这些计算资源大部分时间处于空闲状态，系统就变得不那么具有成本效益。在这种情况下，云服务具有优势，因为它们可以使你更容易根据需求的变化扩大或缩小计算资源。

例如，分析系统通常具有极其可变的负载：快速运行大型分析查询需要大量并行计算资源，但一旦查询完成，这些资源就会闲置，直到用户进行下一个查询。预定义查询（例如，用于每日报告）可以排队和调度以平滑负载，但对于交互式查询，你希望它们完成得越快，工作负载就变得越可变。如果你的数据集如此之大，以至于快速查询它需要大量计算资源，使用云可以省钱，因为你可以将未使用的资源返还给提供商，而不是让它们闲置。对于较小的数据集，这种差异就不那么显著。

云服务最大的缺点是你对它没有控制权：

  • 如果它缺少你需要的功能，你所能做的就是礼貌地询问供应商是否会添加它；你通常不能自己实现它。
  • 如果服务宕机，你所能做的就是等待它恢复。
  • 如果你以触发 bug 或导致性能问题的方式使用服务，你将很难诊断问题。对于自己运行的软件，你可以从操作系统获取性能指标和调试信息以帮助理解其行为，你可以查看服务器日志，但对于供应商托管的服务，你通常无法访问这些内部机制。

此外，如果服务关闭或变得过于昂贵，或者如果供应商决定以你不喜欢的方式改变他们的产品，你就任由他们摆布——继续运行旧版本的软件通常不是一个选项，因此你将被迫迁移到替代服务23。如果有暴露兼容 API 的替代服务，这种风险会得到缓解，但对于许多云服务来说，没有标准 API，这增加了切换成本，使供应商锁定成为问题。

云提供商需要被信任以保持数据安全，这可能使遵守隐私和安全法规的过程复杂化。

尽管存在所有这些风险，组织在云服务之上构建新应用或采用混合方法（将云服务用于系统的某些方面）已变得越来越流行。然而，云服务不会取代所有内部数据系统：许多旧系统早于云，对于任何具有现有云服务无法满足的专业需求的服务，内部系统仍然是必要的。例如，对延迟非常敏感的应用（如高频交易）需要完全控制硬件。

云原生系统架构

除了具有不同的经济模型（订阅服务而不是购买硬件和许可软件在其上运行）之外，云的兴起也对数据系统在技术上如何实现产生了深远影响。云原生一词用于描述旨在利用云服务的架构。

原则上，几乎任何你可以自建托管的软件也可以作为云服务提供，事实上，现在许多流行的数据系统都有这样的托管服务。然而，从一开始就设计为云原生的系统已被证明具有几个优势：在相同硬件上更好的性能、更快的故障恢复、能够快速扩展计算资源以匹配负载，以及支持更大的数据集242526。表 1-2 列出了这两种类型系统的一些示例。

类别自建系统云原生系统
操作型/OLTPMySQL、PostgreSQL、MongoDBAWS Aurora24、Azure SQL DB Hyperscale25、Google Cloud Spanner
分析型/OLAPTeradata、ClickHouse、SparkSnowflake26、Google BigQuery、Azure Synapse Analytics

云服务的分层

许多自建数据系统有非常简单的系统要求：它们在 Linux 或 Windows 等常规操作系统上运行，将数据作为文件存储在文件系统上，并通过 TCP/IP 等标准网络协议通信。少数系统依赖特殊硬件，如 GPU（用于机器学习）或 RDMA 网络接口，但总体而言，自建软件倾向于使用非常通用的计算资源：CPU、RAM、文件系统和 IP 网络。

在云中，这种类型的软件可以在基础设施即服务环境中运行，使用具有特定 CPU、内存、磁盘和网络带宽分配的一个或多个虚拟机（或实例）。与物理机器相比，云实例可以更快地配置，并且有更多种类的大小，但除此之外，它们类似于传统计算机：你可以在其上运行任何你喜欢的软件，但你需要自己管理它。

相比之下，云原生服务的关键思想是不仅使用操作系统管理的计算资源，而且构建在低级云服务之上以创建更高级的服务。例如：

  • 对象存储服务（如 Amazon S3、Azure Blob Storage 和 Cloudflare R2）存储大文件。它们提供的 API 比典型文件系统更有限（基本文件读写），但它们的优势在于隐藏了底层物理机器：服务自动将数据分布在许多机器上，因此你不必担心任何一台机器上的磁盘空间耗尽。即使某些机器或其磁盘完全故障，也不会丢失数据。
  • 许多其他服务又建立在对象存储和其他云服务之上：例如，Snowflake 是一个依赖 S3 进行数据存储的云分析数据库（数据仓库）26，一些其他服务又建立在 Snowflake 之上。

与计算中的抽象一样，对于你应该使用什么，没有一个正确的答案。作为一般规则，较高级别的抽象往往更面向特定用例。如果你的需求与较高级别系统为之设计的情况相匹配，使用现有的较高级别系统可能会比从较低级别系统自己构建提供你需要的东西，麻烦少得多。另一方面，如果没有满足你需求的较高级别系统，那么从较低级别组件自己构建是唯一的选择。

存储与计算的分离

在传统计算中，磁盘存储被视为持久的（我们假设一旦某些内容写入磁盘，就不会丢失）。为了容忍单个硬盘的故障，通常使用**RAID（独立磁盘冗余阵列）**来维护连接到同一机器的几个磁盘上的数据副本。RAID 可以由硬件执行，也可以由操作系统在软件中执行，并且对访问文件系统的应用程序是透明的。

在云中，计算实例（虚拟机）也可能连接本地磁盘，但云原生系统通常将这些磁盘更像临时缓存，而不像长期存储。这是因为如果关联实例故障，或者如果实例被替换为更大或更小的实例（在不同的物理机器上）以适应负载变化，本地磁盘将变得不可访问。

作为本地磁盘的替代，云服务还提供可以从一个实例分离并附加到另一个实例的虚拟磁盘存储（Amazon EBS、Azure 托管磁盘和 Google Cloud 中的持久磁盘）。这样的虚拟磁盘实际上不是物理磁盘，而是由一组单独的机器提供的云服务，它模拟磁盘的行为（块设备，其中每个块通常为 4 KiB 大小）。这项技术使得在云中运行基于磁盘的传统软件成为可能，但块设备模拟引入了开销，这在为云从头设计的系统中可以避免24。它也使应用对网络故障非常敏感，因为虚拟块设备上的每个 I/O 实际上都是网络调用27。

为了解决这个问题，云原生服务通常避免使用虚拟磁盘，而是构建在为特定工作负载优化的专用存储服务之上。对象存储服务（如 S3）专为数百 KB 到数 GB 大小的较大文件的长期存储而设计。数据库中存储的单个行或值通常比这小得多；因此，云数据库通常在单独的服务中管理较小的值，并将较大的数据块（包含许多单个值）存储在对象存储中2528。我们将在第 4 章中看到这样做的方法。

在传统系统架构中，同一台计算机负责存储（磁盘）和计算（CPU 和 RAM），但在云原生系统中，这两个职责已经变得有些分离或解耦9262930：例如，S3 只存储文件，如果你想分析这些数据，你必须在 S3 之外的某个地方运行分析代码。这意味着通过网络传输数据，我们将在”分布式与单节点系统”中进一步讨论。

此外，云原生系统通常是多租户的，这意味着不是为每个客户配备单独的机器，而是来自几个不同客户的数据和计算由同一服务在同一共享硬件上处理31。多租户可以实现更好的硬件利用率、更容易的可扩展性以及云提供商更容易的管理，但它也需要仔细的工程，以确保一个客户的活动不会影响其他客户的系统性能或安全32。

云时代的运维

传统上，管理组织服务器端数据基础设施的人被称为数据库管理员（DBA） 或 系统管理员（sysadmins） 。最近，许多组织试图将软件开发和运维的角色整合到对后端服务和数据基础设施共同负责的团队中；DevOps理念指导了这一趋势。站点可靠性工程师（SRE） 是 Google 对这一理念的实现33。

运维的角色是确保服务可靠地交付给用户（包括配置基础设施和部署应用），并确保稳定的生产环境（包括监控和诊断可能影响可靠性的任何问题）。对于自建系统，运维传统上涉及在单个机器层面的大量工作，如容量规划（例如，监控可用磁盘空间并在空间耗尽之前添加更多磁盘）、配置新机器、将服务从一台机器移动到另一台机器，以及安装操作系统补丁。

许多云服务呈现一个 API，隐藏了实际实现服务的单个机器。例如，云存储用计量计费取代了固定大小的磁盘，你可以在不提前规划容量需求的情况下存储数据，然后根据实际使用的空间收费。此外，许多云服务即使在单个机器故障时仍保持高可用（参见”可靠性和容错性”）。

这种从单个机器到服务的重点转移伴随着运维角色的变化。提供可靠服务的高级目标保持不变，但流程和工具已经发展。DevOps/SRE 理念更加强调：

  • 自动化——偏好可重复流程而非手动一次性作业
  • 偏好临时虚拟机和服务而非长期运行的服务器
  • 支持频繁的应用更新
  • 从事件中学习
  • 保存组织关于系统的知识，即使个人来来去去34

随着云服务的兴起，角色出现了分化：基础设施公司的运维团队专注于向大量客户提供可靠服务的细节，而服务的客户则在基础设施上花费尽可能少的时间和精力35。

云服务的客户仍然需要运维，但他们专注于不同的方面，如为给定任务选择最合适的服务、将不同服务相互集成，以及从一个服务迁移到另一个服务。尽管计量计费消除了传统意义上的容量规划需求，但了解你将资源用于什么目的仍然很重要，这样你就不会在不需要的云资源上浪费钱：容量规划变成财务规划，性能优化变成成本优化36。此外，云服务确实有资源限制或配额（如你可以并发运行的最大进程数），你需要了解并在遇到它们之前进行规划37。

采用云服务可能比运行自己的基础设施更容易和快捷，尽管即使在这里也有学习如何使用它的成本，也许还要解决其局限性。随着越来越多的供应商提供针对不断扩大的用例范围的云服务，不同服务之间的集成成为一个特殊挑战3839。ETL（参见”数据仓库”）只是故事的一部分；操作云服务也需要相互集成。目前，缺乏促进这种集成的标准，因此它通常涉及大量手动工作。

其他无法完全外包给云服务的运维方面包括维护应用及其使用的库的安全性、管理你自己的服务之间的交互、监控服务的负载，以及追踪性能下降或中断等问题的原因。虽然云正在改变运维的角色，但对运维的需求一如既往。

1.6 分布式与单节点系统

涉及通过网络通信的多台机器的系统称为分布式系统。参与分布式系统的每个进程称为节点。你可能希望系统成为分布式的原因有多种：

分布式的原因说明
固有分布式系统如果应用涉及两个或更多交互用户，每个用户使用自己的设备，那么系统不可避免地是分布式的：设备之间的通信必须通过网络进行。
云服务之间的请求如果数据存储在一个服务中但在另一个服务中处理，它必须通过网络从一个服务传输到另一个服务。
容错/高可用如果你的应用需要即使在一台机器（或几台机器、或网络、或整个数据中心）宕机时仍能继续工作，你可以使用多台机器来提供冗余。当一台故障时，另一台可以接管。参见”可靠性和容错性”和第 6 章关于复制的内容。
可扩展性如果你的数据量或计算需求增长到单台机器无法处理的程度，你可以潜在地将负载分布在多台机器上。参见”可扩展性”。
延迟如果你有全球用户，你可能希望在世界各地拥有服务器，以便每个用户可以由地理位置靠近他们的服务器提供服务。这避免了用户必须等待网络数据包传播到世界另一端来回答他们的请求。参见”描述性能”。
弹性如果你的应用在某些时候繁忙，在其他时候空闲，云部署可以扩大或缩小以满足需求，这样你只为你正在积极使用的资源付费。这在单台机器上更困难，单台机器需要配置为处理最大负载，即使在几乎不使用的时候。
使用专用硬件系统的不同部分可以利用不同类型的硬件来匹配其工作负载。例如，对象存储可能使用磁盘多但 CPU 少的机器，而数据分析系统可能使用 CPU 和内存多但没有磁盘的机器，机器学习系统可能使用 GPU（对于训练深度神经网络和其他机器学习任务比 CPU 高效得多）。
法律合规一些国家有数据驻留法律，要求关于其管辖范围内人员的数据必须在该国地理范围内存储和处理40。这些规则的范围各不相同——例如，在某些情况下，它仅适用于医疗或财务数据，而其他情况则更广泛。在几个此类司法管辖区拥有用户的服务因此必须将数据分布在几个位置的服务器上。
可持续性如果你在何时何地运行作业方面有灵活性，你可能能够在有大量可再生电力可用的时间和地点运行它们，避免在电网紧张时运行它们。这可以减少你的碳排放，并允许你在电力便宜时利用廉价电力4142。

这些原因既适用于你自己编写的服务（应用代码），也适用于由现成软件组成的服务（如数据库）。

分布式系统的问题

分布式系统也有缺点。通过网络进行的每个请求和 API 调用都需要处理故障的可能性：网络可能中断，或服务可能过载或崩溃，因此任何请求都可能超时而没有收到响应。在这种情况下，我们不知道服务是否收到了请求，简单地重试可能不安全。我们将在第 9 章中详细讨论这些问题。

尽管数据中心网络很快，但调用另一个服务仍然比调用同一进程中的函数慢得多43。当处理大量数据时，与其将数据从存储传输到单独处理它的机器，不如将计算带到已经有数据的机器上，这样可能更快44。更多的节点并不总是更快：在某些情况下，单台计算机上的简单单线程程序可以显著优于拥有超过 100 个 CPU 核心的集群45。

对分布式系统进行故障排除通常很困难：如果系统响应缓慢，你如何找出问题所在？在可观测性4647的标题下开发了诊断分布式系统问题的技术，这涉及收集关于系统执行的数据，并允许以允许分析高级指标和单个事件的方式对其进行查询。OpenTelemetry、Zipkin 和 Jaeger 等跟踪工具允许你跟踪哪个客户端为哪个操作调用了哪个服务器，以及每个调用花费了多长时间48。

数据库提供各种机制来确保数据一致性，如我们将在第 6 章和第 8 章中看到的。然而，当每个服务都有自己的数据库时，跨这些不同服务维护数据一致性就变成了应用的问题。分布式事务是我们在第 8 章中探索的确保一致性的一种可能技术，但它们在微服务环境中很少使用，因为它们与使服务彼此独立的目标背道而驰，而且许多数据库不支持它们49。

由于所有这些原因，如果你能在单台机器上做某事，这通常比建立分布式系统简单和便宜得多224550。CPU、内存和磁盘已经变得更大、更快、更可靠。当与 DuckDB、SQLite 和 KùzuDB 等单节点数据库结合时，许多工作负载现在可以在单节点上运行。我们将在第 4 章中进一步探讨这个主题。

微服务与无服务器

将系统分布在多台机器上的最常见方式是将它们划分为客户端和服务器，并让客户端向服务器发出请求。最常用的是 HTTP 用于这种通信，如我们将在”通过服务的数据流：REST 和 RPC”中讨论的。同一进程可能既是服务器（处理传入请求）又是客户端（向其他服务发出出站请求）。

这种构建应用的方式传统上被称为面向服务的架构（SOA）；最近，这一理念被完善为微服务架构5152。在这种架构中，服务有一个明确的目的（例如，对于 S3，这将是文件存储）；每个服务暴露一个可通过网络由客户端调用的 API，每个服务有一个负责其维护的团队。因此，一个复杂的应用可以分解为多个交互服务，每个服务由单独的团队管理。

将复杂的软件分解为多个服务有几个优点：每个服务可以独立更新，减少团队之间的协调工作；每个服务可以分配其需要的硬件资源；通过将实现细节隐藏在 API 后面，服务所有者可以自由更改实现而不影响客户端。就数据存储而言，每个服务拥有自己的数据库，服务之间不共享数据库是很常见的：共享数据库实际上会使整个数据库结构成为服务 API 的一部分，然后该结构将难以更改。共享数据库还可能导致一个服务的查询对其他服务的性能产生负面影响。

另一方面，拥有许多服务本身可能滋生复杂性：每个服务都需要部署新版本的基础设施、调整分配的硬件资源以匹配负载、收集日志、监控服务健康，以及在出现问题时提醒值班工程师。Kubernetes 等编排框架已成为部署服务的流行方式，因为它们为此基础设施提供了基础。在开发期间测试服务可能很复杂，因为你还需要运行它依赖的所有其他服务。

微服务 API 可能难以演进。调用 API 的客户端期望 API 具有某些字段。随着业务需求的变化，开发人员可能希望向 API 添加或删除字段，但这样做可能导致客户端失败。更糟糕的是，这种故障通常在开发周期后期，当更新的服务 API 部署到暂存或生产环境时才被发现。OpenAPI 和 gRPC 等 API 描述标准有助于管理客户端和服务器 API 之间的关系；我们将在第 5 章中进一步讨论这些。

微服务主要是针对人员问题的技术解决方案：允许不同团队独立取得进展而无需相互协调。这在大型公司中很有价值，但在团队不多的小公司中，使用微服务可能是不必要的开销，最好以最简单的方式实现应用51。

无服务器，或函数即服务（FaaS），是部署服务的另一种方法，其中基础设施的管理外包给云供应商32。使用虚拟机时，你必须明确选择何时启动或关闭实例；相比之下，使用无服务器模型，云提供商根据传入你服务的请求自动分配和释放硬件资源53。无服务器部署将更多的运维负担转移给云提供商，并通过使用而非机器实例实现灵活计费。为了提供这些好处，许多无服务器基础设施提供商对函数执行施加时间限制、限制运行时环境，并且当函数首次调用时可能启动缓慢。“无服务器”一词也可能具有误导性：每个无服务器函数执行仍然在服务器上运行，但后续执行可能在不同的服务器上运行。此外，BigQuery 和各种 Kafka 产品等基础设施已采用”无服务器”术语，以表明其服务自动扩展并按使用而非机器实例计费。

就像云存储用计量计费模型取代了容量规划（提前决定购买多少磁盘）一样，无服务器方法正在将计量计费引入代码执行：你只为你应用代码实际运行的时间付费，而不是必须提前配置资源。

云计算与超级计算

云计算不是构建大规模计算系统的唯一方式；另一种选择是高性能计算（HPC），也称为超级计算。尽管有重叠，但 HPC 通常与云计算和企业数据中心系统有不同的优先级和使用不同的技术。其中一些差异是：

  • 用途不同：超级计算机通常用于计算密集型的科学计算任务，如天气预报、气候建模、分子动力学（模拟原子和分子的运动）、复杂优化问题和求解偏微分方程。另一方面，云计算倾向于用于在线服务、业务数据系统以及需要高可用性服务用户请求的类似系统。
  • 容错方式不同：超级计算机通常运行大型批处理作业，不时将计算状态检查点到磁盘。如果节点故障，常见的解决方案是简单地停止整个集群工作负载，修复故障节点，然后从上一个检查点重新启动计算5455。对于云服务，通常不希望停止整个集群，因为服务需要持续服务用户，中断最小。
  • 通信机制不同：超级计算机节点通常通过共享内存和远程直接内存访问（RDMA）通信，支持高带宽和低延迟，但假设系统用户之间有高度的信任56。在云计算中，网络和机器通常由互不信任的组织共享，需要更强的安全机制，如资源隔离（例如，虚拟机）、加密和认证。
  • 网络拓扑不同：云数据中心网络通常基于 IP 和以太网，以 Clos 拓扑排列以提供高对分带宽——衡量网络整体性能的常用指标5457。超级计算机通常使用专门的网络拓扑，如多维网格和环面58，这为具有已知通信模式的 HPC 工作负载提供更好的性能。
  • 地理分布不同：云计算允许节点分布在多个地理区域，而超级计算机通常假设其所有节点都靠近在一起。

大规模分析系统有时与超级计算共享一些特征，这就是为什么如果你在这个领域工作，了解这些技术可能是值得的。然而，本书主要关注需要持续可用的服务，如”可靠性和容错性”中所讨论的。

1.7 数据系统、法律与社会

到目前为止，你在本章中已经看到，数据系统的架构不仅受技术目标和需求的影响，还受它们支持的组织的人类需求的影响。越来越多的数据系统工程师意识到，仅仅服务于他们自己业务的需求是不够的：我们对整个社会也负有责任。

一个特别令人担忧的问题是存储关于人们及其行为数据的系统。自 2018 年以来，《通用数据保护条例》（GDPR）赋予许多欧洲国家居民对其个人数据更大的控制和法律权利，类似的隐私法规已在世界各国的各个州采用，包括例如《加州消费者隐私法》（CCPA）。围绕 AI 的法规，如欧盟 AI 法案，对个人数据的使用施加了进一步限制。

此外，即使在不受法规直接约束的领域，人们也越来越认识到计算机系统对人和社会的影响。社交媒体改变了个人消费新闻的方式，这影响了他们的政治观点，因此可能影响选举结果。自动化系统越来越多地做出对个人有深远影响的决定，如决定谁应该获得贷款或保险，谁应该被邀请参加工作面试，或谁应该被怀疑犯罪59。

每个从事此类系统工作的人都负有考虑其道德影响并确保遵守相关法律的责任。没有必要让每个人都成为法律和伦理专家，但对法律和伦理原则的基本意识与分布式系统的一些基础知识同样重要。

法律考虑正在影响数据系统设计的基础60。例如，GDPR 赋予个人应要求删除其数据的权利（有时被称为被遗忘权）。然而，正如我们将在本书中看到的，许多数据系统依赖不可变结构（如仅追加日志）作为其设计的一部分；我们如何确保在应该不可变的文件中间删除某些数据？我们如何处理已纳入派生数据集的数据删除（参见”记录系统与派生数据系统”），如机器学习模型的训练数据？回答这些问题创造了新的工程挑战。

目前，我们还没有关于哪些特定技术或系统架构应被视为”符合 GDPR”的明确指南。法规故意不规定特定技术，因为这些技术可能随着技术进步而迅速变化。相反，法律文本设定了需要解释的高级原则。这意味着对于如何遵守隐私法规没有简单的答案，但我们将通过这一视角审视本书中的一些技术。

一般来说，我们存储数据是因为我们认为其价值大于存储成本。然而，值得记住的是，存储成本不仅仅是你为 Amazon S3 或其他服务支付的账单：成本效益计算还应考虑如果数据被泄露或被对手破坏的责任和声誉损害风险，以及如果数据的存储和处理被发现不符合法律的法律成本和罚款风险50。

政府或警察部队也可能强迫公司交出数据。当数据可能揭示被定罪的行为时（例如，几个中东和非洲国家的同性恋，或几个美国州的寻求堕胎），存储这些数据会给用户带来真正的安全风险。例如，前往堕胎诊所的旅行可能很容易通过位置数据揭示，甚至可能通过用户随时间的 IP 地址日志（指示大致位置）。

一旦考虑到所有风险，可能合理地认为某些数据根本不值得存储，因此应该删除。这种数据最小化原则（有时以德语术语Datensparsamkeit为人所知）与”大数据”的存储大量数据以备将来可能有用的哲学背道而驰61。但它符合 GDPR，该条例规定个人数据只能为特定、明确的目的收集，这些数据不得后来用于任何其他目的，并且数据不得保留超过为其收集目的所必需的时间62。

企业也注意到了隐私和安全问题。信用卡公司要求支付处理企业遵守严格的支付卡行业（PCI）标准。处理商接受独立审计师的频繁评估以验证持续合规。软件供应商也受到越来越多的审查。许多买家现在要求其供应商遵守服务组织控制（SOC）2 类标准。与 PCI 合规一样，供应商接受第三方审计以验证遵守情况。

一般来说，重要的是平衡你的业务需求与你正在收集和处理数据的人的需求。关于这个主题还有很多内容；在[链接待补充]中，我们将更深入地探讨伦理和法律合规的主题，包括偏见和歧视的问题。

1.8 本章小结

本章的主题是理解权衡：即认识到对于许多问题，没有一个正确答案，而是有几种不同的方法，每种方法都有各种优缺点。我们探讨了影响数据系统架构的一些最重要的选择，并介绍了本书其余部分需要的术语。

我们首先区分了操作（事务处理，OLTP）和分析（OLAP）系统，并看到了它们的不同特征：不仅管理具有不同访问模式的不同类型数据，而且服务于不同的受众。我们遇到了数据仓库和数据湖的概念，它们通过 ETL 从操作系统接收数据流。在第 4 章中，我们将看到操作系统和分析系统通常使用非常不同的内部数据布局，因为它们需要服务的查询类型不同。

然后，我们将云服务（相对较新的发展）与以前主导数据系统架构的自建软件传统范式进行了比较。这些方法中哪一种更具成本效益很大程度上取决于你的具体情况，但不可否认的是，云原生方法正在给数据系统的架构方式带来巨大变化，例如它们分离存储和计算的方式。

云系统本质上是分布式的，我们简要审视了分布式系统与使用单台机器相比的一些权衡。有些情况下你无法避免走向分布式，但如果可能将系统保持在单台机器上，建议不要急于使系统分布式。我们将在第 9 章中更详细地介绍分布式系统的挑战。

最后，我们看到数据系统架构不仅由部署系统的业务需求决定，还由保护被处理数据的人的权利的隐私法规决定——这是许多工程师容易忽视的方面。我们如何将法律要求转化为技术实现尚未被很好理解，但在我们阅读本书其余部分时，将这个问题牢记在心是很重要的。

脚注与参考文献

Footnotes

  1. Richard T. Kouzes, Gordon A. Anderson, Stephen T. Elbert, Ian Gorton, and Deborah K. Gracio. The Changing Paradigm of Data-Intensive Computing. IEEE Computer, volume 42, issue 1, January 2009. doi:10.1109/MC.2009.26 ↩

  2. Martin Kleppmann, Adam Wiggins, Peter van Hardenberg, and Mark McGranaghan. Local-first software: you own your data, in spite of the cloud. At 2019 ACM SIGPLAN International Symposium on New Ideas, New Paradigms, and Reflections on Programming and Software (Onward!), October 2019. doi:10.1145/3359591.3359737 ↩

  3. Joe Reis and Matt Housley. Fundamentals of Data Engineering. O’Reilly Media, 2022. ISBN: 9781098108304 ↩

  4. Rui Pedro Machado and Helder Russa. Analytics Engineering with SQL and dbt. O’Reilly Media, 2023. ISBN: 9781098142384 ↩

  5. Edgar F. Codd, S. B. Codd, and C. T. Salley. Providing OLAP to User-Analysts: An IT Mandate. E. F. Codd Associates, 1993. Archived at perma.cc/RKX8-2GEE ↩

  6. Chinmay Soman and Neha Pawar. Comparing Three Real-Time OLAP Databases: Apache Pinot, Apache Druid, and ClickHouse. startree.ai, April 2023. Archived at perma.cc/8BZP-VWPA ↩

  7. Surajit Chaudhuri and Umeshwar Dayal. An Overview of Data Warehousing and OLAP Technology. ACM SIGMOD Record, volume 26, issue 1, pages 65–74, March 1997. doi:10.1145/248603.248616 ↩

  8. Fatma Özcan, Yuanyuan Tian, and Pinar Tözün. Hybrid Transactional/Analytical Processing: A Survey. At ACM International Conference on Management of Data (SIGMOD), May 2017. doi:10.1145/3035918.3054784 ↩

  9. Adam Prout, Szu-Po Wang, Joseph Victor, Zhou Sun, Yongzhu Li, Jack Chen, Evan Bergeron, Eric Hanson, Robert Walzer, Rodrigo Gomes, and Nikita Shamgunov. Cloud-Native Transactions and Analytics in SingleStore. At International Conference on Management of Data (SIGMOD), June 2022. doi:10.1145/3514221.3526055 ↩ ↩2

  10. Chao Zhang, Guoliang Li, Jintao Zhang, Xinning Zhang, and Jianhua Feng. HTAP Databases: A Survey. IEEE Transactions on Knowledge and Data Engineering, April 2024. doi:10.1109/TKDE.2024.3389693 ↩

  11. Michael Stonebraker and Uğur Çetintemel. ‘One Size Fits All’: An Idea Whose Time Has Come and Gone. At 21st International Conference on Data Engineering (ICDE), April 2005. doi:10.1109/ICDE.2005.1 ↩

  12. Jeffrey Cohen, Brian Dolan, Mark Dunlap, Joseph M. Hellerstein, and Caleb Welton. MAD Skills: New Analysis Practices for Big Data. Proceedings of the VLDB Endowment, volume 2, issue 2, pages 1481–1492, August 2009. doi:10.14778/1687553.1687576 ↩

  13. Dan Olteanu. The Relational Data Borg is Learning. Proceedings of the VLDB Endowment, volume 13, issue 12, August 2020. doi:10.14778/3415478.3415572 ↩

  14. Matt Bornstein, Martin Casado, and Jennifer Li. Emerging Architectures for Modern Data Infrastructure: 2020. future.a16z.com, October 2020. Archived at perma.cc/LF8W-KDCC ↩

  15. Martin Fowler. DataLake. martinfowler.com, February 2015. Archived at perma.cc/4WKN-CZUK ↩

  16. Bobby Johnson and Joseph Adler. The Sushi Principle: Raw Data Is Better. At Strata+Hadoop World, February 2015. ↩

  17. DataKitchen, Inc. The DataOps Manifesto. dataopsmanifesto.org, 2017. Archived at perma.cc/3F5N-FUQ4 ↩

  18. Tejas Manohar. What is Reverse ETL: A Definition & Why It’s Taking Off. hightouch.io, November 2021. Archived at perma.cc/A7TN-GLYJ ↩

  19. Simon O’Regan. Designing Data Products. towardsdatascience.com, August 2018. Archived at perma.cc/HU67-3RV8 ↩

  20. Camille Fournier. Why is it so hard to decide to buy? skamille.medium.com, July 2021. Archived at perma.cc/6VSG-HQ5X ↩

  21. David Heinemeier Hansson. Why we’re leaving the cloud. world.hey.com, October 2022. Archived at perma.cc/82E6-UJ65 ↩

  22. Nima Badizadegan. Use One Big Server. specbranch.com, August 2022. Archived at perma.cc/M8NB-95UK ↩ ↩2

  23. Steve Yegge. Dear Google Cloud: Your Deprecation Policy is Killing You. steve-yegge.medium.com, August 2020. Archived at perma.cc/KQP9-SPGU ↩

  24. Alexandre Verbitski, Anurag Gupta, Debanjan Saha, Murali Brahmadesam, Kamal Gupta, Raman Mittal, Sailesh Krishnamurthy, Sandor Maurice, Tengiz Kharatishvili, and Xiaofeng Bao. Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databases. At ACM International Conference on Management of Data (SIGMOD), pages 1041–1052, May 2017. doi:10.1145/3035918.3056101 ↩ ↩2 ↩3

  25. Panagiotis Antonopoulos, Alex Budovski, Cristian Diaconu, Alejandro Hernandez Saenz, Jack Hu, Hanuma Kodavalla, Donald Kossmann, Sandeep Lingam, Umar Farooq Minhas, Naveen Prakash, Vijendra Purohit, Hugh Qu, Chaitanya Sreenivas Ravella, Krystyna Reisteter, Sheetal Shrotri, Dixin Tang, and Vikram Wakade. Socrates: The New SQL Server in the Cloud. At ACM International Conference on Management of Data (SIGMOD), pages 1743–1756, June 2019. doi:10.1145/3299869.3314047 ↩ ↩2 ↩3

  26. Midhul Vuppalapati, Justin Miron, Rachit Agarwal, Dan Truong, Ashish Motivala, and Thierry Cruanes. Building An Elastic Query Engine on Disaggregated Storage. At 17th USENIX Symposium on Networked Systems Design and Implementation (NSDI), February 2020. ↩ ↩2 ↩3 ↩4

  27. Nick Van Wiggeren. The Real Failure Rate of EBS. planetscale.com, March 2025. Archived at perma.cc/43CR-SAH5 ↩

  28. Colin Breck. Predicting the Future of Distributed Systems. blog.colinbreck.com, August 2024. Archived at perma.cc/K5FC-4XX2 ↩

  29. Gwen Shapira. Compute-Storage Separation Explained. thenile.dev, January 2023. Archived at perma.cc/QCV3-XJNZ ↩

  30. Ravi Murthy and Gurmeet Goindi. AlloyDB for PostgreSQL under the hood: Intelligent, database-aware storage. cloud.google.com, May 2022. Archived at archive.org ↩

  31. Jack Vanlightly. The Architecture of Serverless Data Systems. jack-vanlightly.com, November 2023. Archived at perma.cc/UDV4-TNJ5 ↩

  32. Eric Jonas, Johann Schleier-Smith, Vikram Sreekanti, Chia-Che Tsai, Anurag Khandelwal, Qifan Pu, Vaishaal Shankar, Joao Carreira, Karl Krauth, Neeraja Yadwadkar, Joseph E. Gonzalez, Raluca Ada Popa, Ion Stoica, David A. Patterson. Cloud Programming Simplified: A Berkeley View on Serverless Computing. arxiv.org, February 2019. ↩ ↩2

  33. Betsy Beyer, Jennifer Petoff, Chris Jones, and Niall Richard Murphy. Site Reliability Engineering: How Google Runs Production Systems. O’Reilly Media, 2016. ISBN: 9781491929124 ↩

  34. Thomas Limoncelli. The Time I Stole $10,000 from Bell Labs. ACM Queue, volume 18, issue 5, November 2020. doi:10.1145/3434571.3434773 ↩

  35. Charity Majors. The Future of Ops Jobs. acloudguru.com, August 2020. Archived at perma.cc/GRU2-CZG3 ↩

  36. Boris Cherkasky. (Over)Pay As You Go for Your Datastore. medium.com, September 2021. Archived at perma.cc/Q8TV-2AM2 ↩

  37. Shlomi Kushchi. Serverless Doesn’t Mean DevOpsLess or NoOps. thenewstack.io, February 2023. Archived at perma.cc/3NJR-AYYU ↩

  38. Erik Bernhardsson. Storm in the stratosphere: how the cloud will be reshuffled. erikbern.com, November 2021. Archived at perma.cc/SYB2-99P3 ↩

  39. Benn Stancil. The data OS. benn.substack.com, September 2021. Archived at perma.cc/WQ43-FHS6 ↩

  40. Maria Korolov. Data residency laws pushing companies toward residency as a service. csoonline.com, January 2022. Archived at perma.cc/CHE4-XZZ2 ↩

  41. Severin Borenstein. Can Data Centers Flex Their Power Demand? energyathaas.wordpress.com, April 2025. Archived at https://perma.cc/MUD3-A6FF ↩

  42. Bilge Acun, Benjamin Lee, Fiodar Kazhamiaka, Aditya Sundarrajan, Kiwan Maeng, Manoj Chakkaravarthy, David Brooks, and Carole-Jean Wu. Carbon Dependencies in Datacenter Design and Management. ACM SIGENERGY Energy Informatics Review, volume 3, issue 3, pages 21–26. doi:10.1145/3630614.3630619 ↩

  43. Kousik Nath. These are the numbers every computer engineer should know. freecodecamp.org, September 2019. Archived at perma.cc/RW73-36RL ↩

  44. Joseph M. Hellerstein, Jose Faleiro, Joseph E. Gonzalez, Johann Schleier-Smith, Vikram Sreekanti, Alexey Tumanov, and Chenggang Wu. Serverless Computing: One Step Forward, Two Steps Back. At Conference on Innovative Data Systems Research (CIDR), January 2019. ↩

  45. Frank McSherry, Michael Isard, and Derek G. Murray. Scalability! But at What COST? At 15th USENIX Workshop on Hot Topics in Operating Systems (HotOS), May 2015. ↩ ↩2

  46. Cindy Sridharan. Distributed Systems Observability: A Guide to Building Robust Systems. Report, O’Reilly Media, May 2018. Archived at perma.cc/M6JL-XKCM ↩

  47. Charity Majors. Observability — A 3-Year Retrospective. thenewstack.io, August 2019. Archived at perma.cc/CG62-TJWL ↩

  48. Benjamin H. Sigelman, Luiz André Barroso, Mike Burrows, Pat Stephenson, Manoj Plakal, Donald Beaver, Saul Jaspan, and Chandan Shanbhag. Dapper, a Large-Scale Distributed Systems Tracing Infrastructure. Google Technical Report dapper-2010-1, April 2010. Archived at perma.cc/K7KU-2TMH ↩

  49. Rodrigo Laigner, Yongluan Zhou, Marcos Antonio Vaz Salles, Yijian Liu, and Marcos Kalinowski. Data management in microservices: State of the practice, challenges, and research directions. Proceedings of the VLDB Endowment, volume 14, issue 13, pages 3348–3361, September 2021. doi:10.14778/3484224.3484232 ↩

  50. Jordan Tigani. Big Data is Dead. motherduck.com, February 2023. Archived at perma.cc/HT4Q-K77U ↩ ↩2

  51. Sam Newman. Building Microservices, second edition. O’Reilly Media, 2021. ISBN: 9781492034025 ↩ ↩2

  52. Chris Richardson. Microservices: Decomposing Applications for Deployability and Scalability. infoq.com, May 2014. Archived at perma.cc/CKN4-YEQ2 ↩

  53. Mohammad Shahrad, Rodrigo Fonseca, Íñigo Goiri, Gohar Chaudhry, Paul Batum, Jason Cooke, Eduardo Laureano, Colby Tresness, Mark Russinovich, Ricardo Bianchini. Serverless in the Wild: Characterizing and Optimizing the Serverless Workload at a Large Cloud Provider. At USENIX Annual Technical Conference (ATC), July 2020. ↩

  54. Luiz André Barroso, Urs Hölzle, and Parthasarathy Ranganathan. The Datacenter as a Computer: Designing Warehouse-Scale Machines, third edition. Morgan & Claypool Synthesis Lectures on Computer Architecture, October 2018. doi:10.2200/S00874ED3V01Y201809CAC046 ↩ ↩2

  55. David Fiala, Frank Mueller, Christian Engelmann, Rolf Riesen, Kurt Ferreira, and Ron Brightwell. Detection and Correction of Silent Data Corruption for Large-Scale High-Performance Computing, at International Conference for High Performance Computing, Networking, Storage and Analysis (SC), November 2012. doi:10.1109/SC.2012.49 ↩

  56. Anna Kornfeld Simpson, Adriana Szekeres, Jacob Nelson, and Irene Zhang. Securing RDMA for High-Performance Datacenter Storage Systems. At 12th USENIX Workshop on Hot Topics in Cloud Computing (HotCloud), July 2020. ↩

  57. Arjun Singh, Joon Ong, Amit Agarwal, Glen Anderson, Ashby Armistead, Roy Bannon, Seb Boving, Gaurav Desai, Bob Felderman, Paulie Germano, Anand Kanagala, Jeff Provost, Jason Simmons, Eiichi Tanda, Jim Wanderer, Urs Hölzle, Stephen Stuart, and Amin Vahdat. Jupiter Rising: A Decade of Clos Topologies and Centralized Control in Google’s Datacenter Network. At Annual Conference of the ACM Special Interest Group on Data Communication (SIGCOMM), August 2015. doi:10.1145/2785956.2787508 ↩

  58. Glenn K. Lockwood. Hadoop’s Uncomfortable Fit in HPC. glennklockwood.blogspot.co.uk, May 2014. Archived at perma.cc/S8XX-Y67B ↩

  59. Cathy O’Neil: Weapons of Math Destruction: How Big Data Increases Inequality and Threatens Democracy. Crown Publishing, 2016. ISBN: 9780553418811 ↩

  60. Supreeth Shastri, Vinay Banakar, Melissa Wasserman, Arun Kumar, and Vijay Chidambaram. Understanding and Benchmarking the Impact of GDPR on Database Systems. Proceedings of the VLDB Endowment, volume 13, issue 7, pages 1064–1077, March 2020. doi:10.14778/3384345.3384354 ↩

  61. Martin Fowler. Datensparsamkeit. martinfowler.com, December 2013. Archived at perma.cc/R9QX-CME6 ↩

  62. Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 (General Data Protection Regulation). Official Journal of the European Union L 119/1, May 2016. ↩