在本章中，我们将关注范围扩大到包括那些在应对现代实时事件驱动应用日益增长的需求中浮现出的更广泛的混合系统。这些系统虽然不是我们在本书中定义的流数据库，但它们具备连接关系型、分析型和流处理工作负载的特质和功能。我们将探讨它们发展的动机、它们采用的创新技术以及使其相关的特定用例。更重要的是，我们将讨论这些其他混合数据库所涵盖的细分领域。这一理解将帮助我们揭示数据库在提供实时分析方面所跟随的趋势。

值得承认的是，流数据库也是一种混合系统的例子。混合系统涉及至少两个视角，在流数据库的情况下，这两个视角是流处理和数据库。

理解混合系统的不同视角将揭示它们尝试解决的问题及其解决方式。在本书中，我们从流处理的视角定义流数据库如下：流数据库是一个流处理器，它向客户端暴露其状态存储，以便客户端可以发起拉取查询。

从数据库的视角来看，流数据库的定义是：流数据库是一个可以消费和发出流，并且能够异步执行物化视图的数据库。

通过从这两个视角定义混合系统，你将扩大混合系统对其他工程师和用例的适用性。流处理中的一致性就是一个例子。流数据库工程师被迫从数据库的视角来观察，从而发现了一些已建立的流处理器在一致性方面的不足。

状态存储可以通过多种方式实现：键值存储、行存储和列存储。状态存储的实现决定了能够支持的用例，这些用例可以从高一致性要求到低延迟的分析查询。

有趣的是，流数据库只是新兴的混合和融合系统中的一个例子，这些系统旨在减少基础设施复杂性并提高开发人员的可访问性。

数据平面

为了更好地理解这些新兴系统，我们可以通过创建一个维恩图（图7-1）来展示实时系统目前的位置。这将有助于我们辨别不同的用例（我们将在第11章中更详细地讨论这些用例）和实时分析场景中的部署模型。

这个图示不仅能展示流处理的视角，还能展示数据库的视角。例如，我们在本章开始时对流数据库的定义是从流处理的角度出发的。我们可以将这个定义转变为数据库的角度：流数据库是一个可以消费和发出流，并且能够异步执行物化视图的数据库。

尊重所有视角还将为下一代数据库可能的样貌提供线索。

维恩图还帮助我们更好地理解流处理系统在分析生态系统中的角色。图7-1展示了我们已经知道的两个数据平面：操作平面和分析数据平面。

图中添加了第三个平面：流数据平面。这个数据平面一直存在，但从未被充分认可。它是唯一一个数据大多数处于流动中的数据平面。其他平面则处理静态数据。操作平面和分析平面与流数据平面的重叠区域就是同时存在静态数据和流动数据的地方。这就是流数据库所在的位置。我们将在本章稍后讨论重叠的其他区域。

流数据平面连接了数据处理的操作和分析方面。它捕捉和处理实时数据，使其能够无缝地流入分析平面，用于存储、分析，并为洞察和决策提供支持。因此，它充当了一个桥梁，使组织能够基于实时数据和历史数据的结合做出更快速、数据驱动的决策。

回顾一下，操作平面包含OLTP数据库，这些数据库是一致的并使用行式存储。这个平面还包含使用OLTP数据库的应用程序。分析平面包括OLAP数据库，这些数据库是列式的，并且最终一致性存储。这些OLAP数据库被优化以服务于分析查询。

流数据平面则包含将静态数据转化为流动数据的源连接器。它们还具有将流数据写入RTOLAP数据库以实现低延迟服务的接收连接器。流数据平面利用像Kafka和Kafka Connect这样的平台来复制和服务流数据。状态流处理器和流数据库也包含在流数据平面中。

让我们更详细地看一下图7-2中的流数据平面。第6章中，你了解了流处理器的一致性谱。图7-2展示了图7-1中流数据平面圆的详细版本。图7-2将严格一致的流处理器与最终一致的流处理器进行了区分，从左到右，以及存储类型从上到下。

数据在图7-2中从左到右流动，随着它从操作平面流向分析平面。请记住，连接器和流处理平台如Kafka也存在于流数据平面中。

正如维恩图所示，最有趣的部分是圆圈重叠的地方。接下来，我们来看看操作平面和分析平面之间的重叠区域。

混合事务/分析数据库

流式OLTP数据库（行式存储）将流处理平面中的流处理与操作平面中的OLTP数据库相融合。这就是行式、一致的流数据库所在的区域（例如，RisingWave和Materialize）。

流式OLAP数据库（列式存储）将分析平面中OLAP数据库的特征与流数据平面中的流处理特征融合。这些数据库通过使用索引和列式存储来优化复杂的分析查询，具有最终一致性特征。Proton就属于这一领域。

操作平面与分析平面（不包括流处理）之间的重叠代表了混合事务/分析处理（HTAP）数据库（见图7-3）。这些数据库可以处理OLTP和OLAP工作负载。这一概念由Gartner在2014年提出。

HTAP是一种新兴的应用架构，它“打破了事务处理和分析之间的壁垒”。它使得更为信息化和“业务实时”决策成为可能。

你可能会问：“OLTP和OLAP工作负载最初被分开处理是有原因的吧？这个壁垒不是刻意设立的吗？”

HTAP数据库有两种存储类型：内存存储和持久存储。Gartner的HTAP数据库设计可以在“进行中的”事务（正在执行写操作的事务）上执行分析查询。HTAP数据库之所以能够处理这两种工作负载，是因为它们利用了内存数据库。对于OLTP工作负载，HTAP数据库通过事务和持久写操作来满足ACID属性。见图7-4。

暴露内存存储以服务于分析查询的方式与流式数据库的做法非常相似。不同的是，HTAP（混合事务/分析处理）数据库不支持流处理。有些HTAP数据库甚至不支持异步运行的物化视图，这进一步消除了类似流处理的功能。

HTAP数据库可以有效地服务于简单的实时分析，因为它们可以直接从内存存储中为应用程序提供查询，而应用程序进行写操作。表7-1列出了截至本书撰写时市场上存在的一些HTAP数据库。

表7-1. 市场上的HTAP数据库（截至撰写时）

名称	厂商	存储实现
Unistore	Snowflake	混合表中的所有数据同时存储在行存储和列存储中。数据更改时，会在行存储中同步更改，并异步刷新到列存储中。
SingleStoreDB	SingleStore	支持两种类型的表：磁盘上的列式存储（称为Columnstore；这是SingleStoreDB Cloud的默认表类型）和内存中的行式存储。Columnstore也被称为Universal Storage。
TiDB	PingCAP	支持事务性键值存储和列式存储。TiKV是一个分布式事务性键值数据库，提供符合ACID的事务API。TiFlash是TiDB系列中的分析扩展，通过列式存储和大规模并行处理（MPP）查询引擎驱动TiDB。
HydraDB	Hydra	开源数据库，支持事务性行式存储（称为堆表）和列式存储布局（默认布局）。

图7-4中的HTAP数据库并未遵循Gartner提出的HTAP设计。在图7-4的存储实现下，每个HTAP数据库都包含行式和列式存储，没有使用进行中的内存事务来服务分析查询。

有效使用HTAP数据库会使得对流式平面的需求显得多余——这表明你可以在HTAP数据库内完成所有实时数据工作。

HTAP数据库确实存在一些限制，使它们无法完全取代实时分析。它们是整体解决方案，无法像纯OLAP系统那样存储历史数据。历史数据可以是TB甚至PB级别的。对于不需要保留历史数据的情况，HTAP数据库是一个更好的解决方案。或者，你可以在基础设施中同时保持一个OLAP和HTAP数据库，这样你又回到了我们在本书早期讨论的数据分隔问题。

HTAP数据库可以更好地为操作平面中的应用程序提供分析服务，而不是为数据分析师运行复杂的临时分析查询。你需要从OLAP系统中提取一个聚合的历史数据，这样可以将历史数据的规模缩减到HTAP可以处理的范围。再一次，你仍然面临HTAP试图解决的数据分隔问题。

图7-5展示了维恩图中间的重叠区域。正如你所见，这些重叠区域形成了一个三瓣的“花”：HTAP、流式OLTP和流式OLAP数据库。

混合数据库的出现是为了解决涉及可扩展性和优化的实时分析问题，这通常需要更多或不同的基础设施。更多的基础设施意味着在实时分析能够提供给应用程序之前，需要更多的数据集成和数据移动。

花的中心（即雌蕊）在本章中仍未明确，但我们可以开始推测实现存在于雌蕊中的数据库的意义。在此之前，还需要讨论一些其他的混合数据库，因为它们不容易与我们的维恩模型对接。

其他混合数据库

在本书的研究过程中，我们遇到了许多类似流式数据库的数据库，但它们并不完全符合我们对流式数据库或HTAP数据库的定义。这些其他混合数据库结合了独特的特性，解决了通常由流式系统解决的问题。

表7-2. 其他混合数据库

名称	混合系统	描述
PeerDB	Postgres OLTP数据库 + 流处理器	PeerDB是一个以Postgres为核心的数据移动平台，使得数据进出Postgres变得快速而简单。它支持同步、转换和加载数据到OLAP系统中。物化视图需要在OLTP数据库中创建，因此它不符合我们对流式数据库的定义，但仍属于流式OLTP数据库类别。
Epsio	Postgres OLTP数据库 + 外部异步物化视图	Epsio插入现有数据库中，并在基础数据变化时实时更新你定义的查询结果，而无需重新计算整个数据集。这种方法允许Epsio为复杂查询提供即时和始终最新的结果，同时显著降低成本。
Turso	SQLite OLTP数据库 + 流平台	Turso允许本地开发并在全球多个位置进行复制，提供同步数据访问，而不是像Kafka那样的异步访问。
Redpanda	流平台 + Apache Iceberg（数据库）	开发者可以将自己的查询引擎用于Redpanda的分层存储中的数据，而无需将数据移动到不同的系统，从而减少了分析基础设施的负担。

混合系统的动机

流处理系统/供应商希望将数据库体验引入流式处理，以帮助消除其难以采用的刻板印象。流处理常常与复杂性相关联，特别是对那些不熟悉实时数据处理细节的人。流处理系统和供应商旨在通过提供更用户友好的体验来弥合这一知识差距，使其类似于传统数据库。这包括简化API、提供用户友好的界面，并提供对更广泛用户群体更直观的工具。

流处理被认为过于复杂而不易采用的污名化，阻碍了许多组织全面接受实时数据分析。通过将数据库体验带入流处理，供应商试图降低准入门槛，使其对各种行业的企业更易于接触和采用。

熟练的数据工程师稀缺也是一个重大障碍。通过提供熟悉的数据库环境来简化流处理的采用，可以帮助组织利用实时数据分析，而无需大量的专业知识。

相反，OLTP数据库正在尝试采纳特定于OLAP数据库的功能，以便更好地服务于操作平面的分析查询。OLTP数据库也在被推动采纳流式功能，以满足对实时数据分析的日益增长的需求。这些功能避免了到分析平面的往返，许多人认为分析平面充满了复杂和不熟悉的基础设施。

许多组织在分布式环境中操作，确保跨多个数据库和系统的数据一致性可能很具挑战性。OLTP数据库正在引入流式功能，以简化数据复制和同步。通过利用流处理，它们可以实时传播变化，从而减少数据不一致的可能性。

从数据库的角度来看，数据库技术认识到这些需求，但未认识到它们是流处理的特征。

在图7-1中的维恩图中，每个混合系统的共同目标是提供实时分析，同时减少基础设施和提高工程师的可及性。

许多这些混合系统基于OLTP数据库，部分原因是它们离用户应用程序更近，因此更具实时性。实时分析的交付越来越需要将数据分析靠近操作平面，甚至完全融入其中。流式系统需要认识到这一点，以更好地理解其需求，并改善其被认为难以实现的声誉。

PostgreSQL对混合数据库的影响

许多混合数据库基于PostgreSQL（或Postgres），这是一个非常流行的OLTP数据库。Postgres及其协议被许多流行的混合数据库使用：RisingWave、Materialize、Hydra、PeerDB和Epsio。

Postgres的流行及其社区可以归因于以下几个额外因素（见表7-3）。

表7-3. Postgres的流行因素

因素	描述
可扩展性	Postgres的可扩展架构允许开发者创建自定义数据类型、操作符和函数，使其适用于广泛的应用和行业。
性能优化	社区致力于优化数据库引擎，提供竞争力的性能和高效的查询处理。
第三方生态系统	围绕Postgres发展了丰富的第三方工具、库和扩展，进一步增强了其能力和灵活性。
企业采用	许多大型组织和企业已采用Postgres进行关键应用，这提升了其信誉和流行度。
全球影响力	Postgres不局限于特定地区或行业，吸引了全球范围内广泛和多样化的用户群体。

开源原则、积极参与的社区、强大的开发实践以及功能丰富的数据库引擎的结合，使Postgres成为关系数据库领域一个流行且持久的项目。随着其受欢迎程度的不断提高，预计会有更多的混合数据库提供类似Postgres的数据库体验。

接近边缘的分析

将分析引入操作平面旨在使数据洞察对最终用户更加可访问和响应。这种方法主要是为了减少延迟，从而在实时场景中实现更快的决策。混合数据库在这一努力中发挥着关键作用，因为它们旨在提供分析能力，而无需复制整个分析平面。在许多情况下，用户不需要访问整个数据存储库，而只需获取特定的、与即时实时决策相关的数据子集。这种优化的数据交付确保了有价值的洞察能够迅速获得。

一些分析工作负载永远无法进入操作平面，因为分析工作负载通常：

• 汇总大量存储在OLAP数据库中的历史数据，这些数据可以达到PB级别，不适合操作基础设施。
• 训练需要专门系统的机器学习模型，这些系统在操作平面上不存在。
• 需要高度分布式系统来对数据进行分区以进行大规模并行处理，而操作平面并不完全支持。
• 需要灵活性来执行服务于内部用户的数据的临时查询。面向外部用户的分析通常缺乏这种灵活性，并且经常需要请求额外的指标以显示在其应用程序中。

每个实时系统的目标是找到最简单且最佳的方法，以在不大幅增加基础设施和资源成本的情况下将实时分析提供给最终用户。混合数据库具备实现这一目标的功能。实时性正在定义下一代混合数据库。随着越来越多的数据库支持实时功能，它们本质上变得更加混合。

下一代混合数据库

图7-6 提供了当前实时系统格局的可视化表示。它展示了组织当前用于满足实时数据处理需求的技术和解决方案。这些重叠区域形成的花瓣是实时分析中最新趋势和创新最为显著的地方。它们包括HTAP、流式OLTP数据库和流式OLAP数据库。

图7-6 的中心标识了下一代实时数据库。下一代数据库将具备所有三个数据平面的特性，包括：

• 有状态的流处理
• 用于分析工作负载的列式存储
• 用于操作工作负载的一致性

截至本书出版时，图7-6 中的下一代区域尚不存在任何数据库。要符合下一代数据库的标准，现有数据库需要添加相应的缺失特性。例如：

• HTAP 数据库 可以添加增量视图维护（IVM），使其表现得像一个有状态的流处理器。它们还需要与像 Kafka 这样的流平台集成。增量视图维护将在第11章中详细讨论。
• 流式 OLTP 数据库 只需提供列式存储即可。他们可以通过集成像 DuckDB 这样的嵌入式 OLAP 数据库来实现这一点。嵌入式 OLAP 数据库将在第8章中进行讨论。
• 流式 OLAP 数据库 可以向其流处理器添加一致性，以便更好地参与应用程序的实际逻辑。

现有的混合系统在实时分析领域处于前沿，为组织提供了一种多功能且更全面的方式来处理在动态和数据驱动环境中的数据需求。这些混合系统的创新精神正在推动实时分析进入新的领域，在这些领域中，关系型、分析型和流式工作负载之间的界限开始模糊，组织可以从其数据资产中提取更多的价值。

随着进一步的创新导致这些混合系统的演变，我们相信每个系统将继续沿着减少基础设施、延迟和整体复杂性的路径前进。

接下来，我们将深入探讨现有实时混合数据库可以使用的附加功能，以实现下一代状态。

下一代流式 OLTP 数据库

下一代流式 OLTP 数据库在以下三个领域可以继续改进：

1. 完善数据一致性模型：流处理中的数据一致性对于参与应用程序逻辑是必要的。随着越来越多的工程师开始理解流处理中的一致性问题以及在向用户呈现分析时对准确性的更高要求，流式 OLTP 数据库需要在其输出的分析中改进一致性。

2. 改进对变更数据或 WAL 的访问：CDC（变更数据捕获）用例需要在专用和分布式集群中运行连接器。这增加了架构的复杂性和维护量。为简化这一过程，将 CDC 事务从 WAL 发射到像 Kafka 这样的流平台是像 PeerDB 和 CockroachDB 等数据库已经利用的特性。

   通过发射变更，数据库系统消除了为每个可能的集成点构建连接器以摄取和释放数据的需要。开发这些连接器耗时且成本高昂。此外，它还将系统限制在少数几个用例中，或者直到开发一个连接器变得经济上有利为止。另外，一些 CDC 连接器通常难以管理，可能导致如内存不足或磁盘空间不足等问题。原生自发 CDC 事件可以防止使用外部 CDC 解决方案时遇到的问题。参见 图7-7。

第三，流式 OLTP 数据库将开始引入列式存储格式，以处理分析工作负载，从而向应用程序提供分析数据。这并不意味着流式 OLTP 数据库将开始存储所有历史数据。OLTP 数据库无法存储如此大量的数据。流式 OLTP 数据库需要从 OLAP 系统提供历史数据的一个子集，无论是通过流式处理还是批处理（批处理是允许的，因为数据不是实时的）。历史数据的子集将仅限于应用程序领域上下文中的数据。这种方法确保了流式 OLTP 数据库可以支持分析工作负载，而不会因为历史数据存储需求而不堪重负。

下一代流式 RTOLAP 数据库

现有的 RTOLAP 数据库目前没有流处理能力。Proton 是唯一一个将流处理和 OLAP 系统融合的解决方案。它的流处理器提供了更先进的数据摄取功能，并且可以平衡推送和拉取查询。

大多数现有的 RTOLAP 数据库严重依赖外部流处理器，这增加了整个实时架构的复杂性和维护工作。

在第4章中，我们提到数据工程师通常编写推送查询，而数据分析师编写拉取查询。这两个角色协调不佳，因为他们通常位于不同的团队。将流处理添加到数据摄取中，将使 RTOLAP 数据库减少对外部流处理器的依赖。

此外，像 Flink 这样的外部流处理器通常以多个消费者可以订阅的方式发布数据。通常，数据格式需要额外的转换，以满足下游数据分析师的特定需求。将这些特定的转换放入推送查询中，将允许流处理系统为特定的订阅者发布数据。

预计现有的 RTOLAP 数据库将通过引入流处理和提供推送查询功能，来改进数据摄取方式，以便更好地服务于数据分析师。

下一代 HTAP 数据库

下一代 HTAP 数据库将通过引入增量视图维护（IVM）来利用其混合存储能力。IVM 是一种维持物化视图的方法，它以异步的方式计算和应用增量修改，而不是重新评估整个内容。如前几章所述，异步运行的物化视图非常类似于流处理。

通过实施 IVM，HTAP 数据库可以将事务从行式转换为列式，以支持低延迟的分析查询，而无需将数据转移出去。

预计 HTAP 数据库还将具备从分析平面引入有限历史数据的能力。这将为实时分析数据提供有限的历史背景。

总结

我们全面讨论了展示实时特征的各种混合数据库，帮助您在选择适合您特定实时数据处理需求的数据库时做出明智的决策。我们在整个章节中审视的数据平面维恩图帮助说明了现有系统的独特特性及其如何融合到正确的解决方案中。

按照定义，您可能会认为系统的融合将使数据架构变得不那么分布式，而更趋向于单体化。单体系统往往较为僵化且可扩展性较差。在接下来的章节中，我们将讨论今天系统的分布方式，以及混合系统如何避免变得过于单体化。