OLTP 与 OLAP

用于管理数据的数据处理系统可以分为在线事务处理 (OLTP) 或在线分析处理 (OLAP)。虽然两者用途不同，但对于处理日常运营和为企业获取可操作的见解都至关重要。

OLTP 系统专为实时事务管理而设计，确保来自关键运营任务（如销售、订单处理和客户互动）的数据能够快速准确地捕获、存储和处理。相比之下，OLAP 系统侧重于复杂查询和分析大量历史数据，为企业提供有价值的见解，以推动决策和战略规划。然而，现代 OLAP 系统已经超越了传统的局限性。它们现在为实时分析应用程序和仪表板提供支持，支持用户场景所需的更高查询并发性。这些实时 OLAP 数据库还通过实现更高的写入吞吐量并将数据可用性延迟缩短至仅几秒钟，解决了历史限制。当 OLTP 和 OLAP 结合使用时，企业可以最大限度地发挥其数据的价值，以提高运营效率和战略洞察力。

在本指南中，我们将详细探讨这两种数据处理方法的异同，并通过用例示例来说明何时使用每种方法是合适的。我们的目标是为读者提供足够的见解，以决定何时使用 OLTP 以及何时使用 OLAP。最后，我们将介绍快速高效的 CDC 如何弥合这两种范例之间的差距。

虽然并非所有 OLTP 或 OLAP 系统都严格意义上是数据库，但大多数数据库通常可以根据其主要功能归类为 OLTP 或 OLAP。因此，我们重点介绍这些系统之间的差异，并在适当的情况下使用数据库作为示例。

在线事务处理 (OLTP) 是指旨在管理和执行来自多个并发用户的大量实时事务的系统。这些系统用于支持各行各业的日常运营，处理 ATM 取款、网上银行、电子商务购买和店内交易等任务。OLTP 系统允许实时插入、更新或删除数据集。由于多个用户同时访问相同的数据，OLTP 系统侧重于数据一致性和快速检索少量记录，例如银行交易，通常通过唯一键或一组过滤器来识别。

支持 SQL 的 OLTP 系统通常将其表示为带有 WHERE 条件的简单 SELECT。

SELECT
    addr1,
    addr2,
    street,
    locality,
    town,
    district,
    price
FROM uk.uk_price_paid
WHERE (postcode1 = 'BB1') AND (postcode2 = '6NP')

OLTP 查询，通过 ID 从英国房价支付数据检索房价

数据通过事务性保证插入到 OLTP 系统中，确保事务内的所有操作（无论是插入、更新还是删除）都可靠且一致地执行。这些系统中的事务遵循 ACID （原子性、一致性、隔离性、持久性）属性，这些属性保障数据完整性。原子性确保每个事务要么完全完成，要么完全不完成，这意味着如果事务失败，数据库将恢复到之前的状态，数据不受影响。一致性保证事务内所做的任何更改都符合数据库的约束和规则，从而维护整体结构和准确性。隔离性确保事务彼此独立运行，防止多个进程同时访问数据库时发生干扰或数据损坏。持久性确保一旦事务成功提交，更改将永久保存，即使在系统发生故障的情况下也是如此。此框架确保即使更新事务失败，现有数据仍然完整，并且任何不完整或错误的更改都将被丢弃，从而保持数据库的可靠性。

虽然每个请求读取或插入的数据在 OLTP 系统中通常很小（<5%），但总数据大小仍然可能很大 - 偶尔会达到 TB 级别。这些系统确实需要大量的水平扩展专业知识，例如分片等技术需要扩展和/或仔细的数据分配。

在 OLTP 系统中，PostgreSQL 等数据库通常用作经典示例，因为它们具有稳健性、可扩展性和强大的 ACID 合规性。PostgreSQL 擅长处理金融交易等用例中所需的大量简短、快速的查询。PostgreSQL 的关系结构允许高效的索引和查询，从而支持多个用户的实时读写操作。事务性保证确保数据完整性，Postgres 事务要么完全完成，要么在发生错误时回滚，从而保护数据库免受不一致的影响。行级锁定和对多种隔离级别的支持等功能进一步增强了其可靠性，使 PostgreSQL 成为各行各业 OLTP 应用的首选。

在线分析处理 (OLAP) 是指旨在对大型数据集执行复杂查询，以进行数据分析、报告和商业智能的系统。与侧重于实时事务处理的 OLTP 系统不同，OLAP 系统的构建目的是分析来自各种来源（包括但不限于 OLTP 系统）的聚合历史数据。这使企业能够快速处理多维数据，并发现诸如同比增长率、市场趋势或客户行为模式等见解。OLAP 系统对于各行各业的决策过程至关重要，为财务分析、预算编制、预测和销售优化等应用提供支持。这些系统通常存储海量数据集，范围通常从 TB 级到 PB 级。查询往往很复杂，聚合和连接多个维度的数据以汇总大量数据点。这不可避免地意味着 OLAP 系统优先考虑对大量行进行高效数据读取，使其对于需要深入分析而不是实时事务更新的任务非常宝贵。

SELECT
    town,
    district,
    count() AS c,
    round(avg(price)) AS price,
    bar(price, 0, 5000000, 100)
FROM uk_price_paid
WHERE date >= '2020-01-01'
GROUP BY
    town,
    district
HAVING c >= 100
ORDER BY price DESC
LIMIT 100

OLAP 查询，用于识别英国房价支付数据中最昂贵的城镇和地区

数据仓库是 OLAP 系统，通常依赖于 OLAP 数据库为其提供支持，但它们为跨组织管理、清理和准备用于分析的数据提供了更广泛的功能。这包括数据集成、ETL（提取、转换、加载）流程以及来自多个来源的长期数据存储等功能。数据仓库充当集中分析和报告的综合平台，通常包含数据治理、安全性和审计功能。

传统上，OLAP 系统需要以大批量加载数据，更新通常按计划的间隔（例如，每天）进行，具体取决于组织的需求。这种批量处理允许在分析之前聚合大量数据，但也会导致数据可用性延迟。然而，随着 ClickHouse 等实时 OLAP 数据库的出现，这种限制正在被消除。虽然数据仍然以批量方式加载，但通过实时变更数据捕获 (CDC)等技术，数据捕获和分析可用性之间的延迟已缩短至仅几秒钟。这种近乎实时的能力使企业能够根据更新鲜的数据做出决策。向实时分析的这种演变正在改变组织使用 OLAP 系统的方式，从而实现更快、更数据驱动的决策。

此外，OLAP 数据库传统上依赖于用户使用雪花或星型模式对数据进行建模，以优化跨多个维度的复杂查询。虽然这些模型仍然很普遍，但去规范化数据（一种 OLTP 系统中常用的技术）的趋势正在日益增长。这种转变的驱动力是减少查询时间连接的需求，尤其是在查询延迟至关重要的情况下。为了支持这一点，现代实时 OLAP 数据库（如 ClickHouse）采用字典查找功能，同时鼓励去规范化（但仍然支持连接），从而加快查询执行速度。

这种趋势与实时分析用例中对亚秒级查询时间 (<1 秒) 的日益增长的需求相关。这些用例在高度交互式应用程序中公开分析，在这些应用程序中，它们通常比历史上 OLAP 系统中看到的为更多用户提供服务。这些应用程序需要实时 OLAP 数据库提供的更快执行时间。

读者可以根据提供的描述观察到一些明显的区别，而其他区别则源于每个系统处理的特定工作负载和数据类型。在数据库的情况下，工作负载的性质通常决定了设计上的根本差异——OLTP 系统经过优化，可以检索小型、有针对性的行集。相比之下，OLAP 系统的构建目的是汇总和聚合数据集的很大一部分数据。

维度	OLTP（在线事务处理）	OLAP（在线分析处理）
目的	实时事务管理（例如，销售、更新）	复杂的数据分析和报告
数据源	来自实时事务的当前运营数据	来自多个来源（包括但不限于 OLTP 系统）的聚合历史数据
数据模型	规范化 (3NF)，以提高数据效率和完整性	星型/雪花模式或去规范化，以提高查询性能
数据量	较小的数据集（GB 到 TB）	大型数据集（TB 到 PB）
查询类型	通常很简单，在主键或索引值上进行筛选	带有聚合且可能包含连接的复杂 SELECT 查询
操作	频繁的短时更新，用于实时数据	历史上通过计划的批处理作业进行更新，但频率越来越接近秒级的批处理。
响应时间	大多数操作的响应时间为毫秒级	历史上，响应时间为秒级到小时级，具体取决于查询的复杂性。当分析在应用程序中公开时，响应时间越来越接近亚秒级。
数据加载和更新	实时进行小批量插入和更新	历史上通过批处理作业进行定期数据刷新，但是
数据库设计*	基于行，规范化，用于快速事务更新	列式，去规范化，用于高效查询
数据架构	针对快速读取和小批量写入进行优化	针对读取密集型、复杂查询和批量写入进行优化
数据视图	实时业务事务的快照	历史数据和聚合数据的多维视图
数据完整性	必须维护数据完整性约束	不太关键，因为它通常可以从备份中恢复，并且不会影响运营能力。注意：如果为面向用户的实时应用程序提供支持，则数据完整性要求更高。
备份和恢复	频繁备份，以确保任务关键型系统的业务连续性	备份频率较低；在许多情况下，数据可以从 OLTP 源恢复。
用户类型	运营用户	分析师、数据科学家和工程师、业务经理和主管
一致性保证	事务性，符合 ACID	通常最终一致，尽管事务性功能正在涌现
用户数	数千个并发用户	历史上为数十个，但随着实时工作负载的增加，用户数越来越多，达到数百个和数千个

本质上，OLTP 系统传统上支持业务的运营方面，实现日常职能，而 OLAP 系统则侧重于信息方面，帮助组织获得见解并了解其整体绩效。这体现在备份和恢复策略中，OLTP 系统对于业务运营至关重要，因此需要频繁备份和经过良好测试的恢复程序。相反，OLAP 系统虽然对于提供见解和竞争优势至关重要，但通常受到的 SLA 限制较少，并且在许多情况下可以从 OLTP 源恢复。

“我们在使用 Postgres 的经验中发现，需要高吞吐量摄取，同时还需要用户图表和统计信息中产生的低延迟分析查询。这自然使我们相信我们需要 OLAP/实时分析数据库。”

LangChain 联合创始人 Ankush Gola

尽管 OLTP 和 OLAP 的用途截然不同，但它们有几个核心相似之处，尤其是在它们都依赖 SQL 数据库来存储和管理数据方面。这两个系统都在组织的数据生态系统中发挥着关键作用，支持以结构化格式捕获、存储和检索数据。 

OLTP 和 OLAP 系统通常由数据库提供支持，该数据库将公开 SQL 接口，大多数用户将通过该接口进行交互和查询数据。虽然“SQL 风味”可能存在差异（完全符合 ANSI-SQL 标准的情况很少见），但这提供了一种通用的语言，大多数用户都将熟悉这种语言 - 从而允许在系统之间进行简单转换。

最后，OLTP 和 OLAP 系统都在随着技术进步而发展。ClickHouse 等实时 OLAP 数据库正在通过减少数据可用性延迟来模糊传统 OLTP 和 OLAP 之间的界限，从而实现更快的见解和决策。这两个系统都在不断适应不断增长的数据量和用户需求，突显了它们利用数据来改善业务成果的共同目标。

上述好处并非没有挑战。虽然最近的进展有助于解决一些问题，但用户仍然普遍面临几个关键挑战，包括

• 设置和维护的复杂性： 由于复杂的数据建模和架构，OLAP 系统需要熟练的专业人员进行实施和管理。Snowflake、BigQuery 和 Redshift 等平台领导的云数据仓库的兴起，通过外包运行仓库的许多运营挑战并提供可扩展性、便利性和灵活性，帮助实现了数据仓库的现代化。然而，这种转变也导致了将云数据仓库定位为“一刀切”解决方案的诱惑，模糊了数据仓库与其他用例（如面向用户的分析和机器学习）之间的界限。这种方法有时会导致性能瓶颈、运营复杂性增加和成本上升，突显了对更专业化解决方案和架构的需求。

• 数据延迟和新鲜度： 传统上，OLAP 系统依赖于按计划批处理更新的预聚合数据，这会导致数据可用性延迟，并使实时分析变得困难。虽然增量更新和频繁刷新可以提供帮助，但它们通常会增加系统的复杂性。然而，现代实时 OLAP 数据库越来越多地通过支持高写入吞吐量和提供与源系统的直接连接来解决此问题。借助 Kafka 和通过变更数据捕获 (CDC) 进行的 Postgres 集成等功能，这些系统能够实现近乎实时的数据摄取，从而显着减少数据延迟。这种转变确保了用于分析的更新鲜数据，并为更具交互性的实时数据驱动应用程序铺平了道路。此外，虽然物化视图在历史上一直用于提供快速查询性能，但这些视图需要计算成本高昂的定期刷新。OLAP 数据库越来越多地通过增量物化视图来应对这一挑战，这些视图会在数据插入时进行更新和维护。

• 高成本： 基于云的 OLAP 仓库最初通过分离存储和计算资源，缓解了与大规模数据处理相关的一些传统成本，使企业只需为其使用的计算能力付费。然而，随着组织扩展其实时分析需求，新的挑战也随之出现，例如性能下降、成本不断攀升以及查询并发性低。处理交互式数据驱动应用程序所需的高数据流量通常会导致效率低下，并进一步增加运营费用。现代实时 OLAP 数据库通过优化大规模分析工作负载，提高查询性能并支持更高的并发性，从而解决了这些可扩展性和成本问题。

“在 Coinhall，高效管理海量区块链数据对于我们的面向消费者的交易平台至关重要。最初，我们使用 BigQuery，但随着我们的数据增长，其成本和性能问题也随之而来。在探索了几种替代方案后，我们发现 ClickHouse 是明显的赢家。ClickHouse 的性能明显优于我们测试过的其他数据库（如 Snowflake、Rockset 和 SingleStore），并且节省了 40 倍的成本。”

首席技术官 Aaron Choo

• 数据质量和复杂性： 实时数据通常会带来错误、重复和不一致等挑战，因此在分析之前确保高数据质量至关重要。这需要强大的数据清理、验证和治理框架来维护准确性和可靠性。此外，OLAP 系统必须处理多样且复杂的数据格式 - 结构化、半结构化，有时甚至是未结构化 - 这可能会使数据建模和分析变得复杂。越来越多的系统通过灵活的架构来应对这些挑战，这些架构支持各种数据格式并与各种数据管道无缝集成。

• 可扩展性和性能： 随着数据量的增长，OLAP 系统必须扩展以处理不断增长的数据流量和复杂查询。在处理大型数据集的同时保持性能通常需要数据分区、压缩和分布式架构等策略。在分布式自管理 OLAP 环境中水平扩展计算资源可能会增加显着的复杂性和管理开销。这正是为水平可扩展性而设计的基于云的 OLAP 解决方案的优势所在。这些解决方案通过使用对象存储有效地管理 PB 级数据，从而分离存储和计算。这种架构确保用户可以独立扩展存储，同时优化计算资源以满足高查询并发性和大规模数据处理的需求。借助内置缓存层和高级压缩技术，这些系统可以在海量数据集上实现高性能。

以上内容展示了通常如何通过使用对象存储（如 S3 和 GCS）来实现存储和计算分离以进行数据持久化。这允许计算节点垂直扩展，即每个节点使用更多的 CPU 和 RAM，因为它们的本地磁盘仅用作缓存。因此，可以独立于存储调整这些节点的大小。此外，可以轻松添加节点，从而实现水平扩展。扩展的选择取决于正在服务的工作负载，例如，更多节点通常可以实现更高的查询并发性。

• 查询并发性： 传统上，OLAP 系统在处理高查询并发性方面一直很吃力，特别是对于需要同时为数百甚至数千个用户提供服务的交互式应用程序（即面向用户的分析）而言。这通常会导致瓶颈和重负载下的性能下降。然而，随着实时 OLAP 数据库的出现，这些限制正在得到解决。这些数据库旨在通过使用增量物化视图等功能来处理高查询并发性，非常适合需要大量用户实时访问数据的应用程序。这些系统可以有效地支持并发工作负载，而不会降低性能，使其成为营销分析、可观测性平台和 SaaS 服务等用例的理想选择，在这些用例中，快速、交互式查询性能至关重要。

“使用 Snowflake，我们使用的是标准计划、小型计算，其成本几乎是 ClickHouse Cloud 的六倍。我们获得了几秒钟的查询时间，并且没有物化视图。借助 ClickHouse Cloud 的生产实例，我们获得了亚秒级的查询时间和物化视图。对我们来说，切换到 ClickHouse Cloud 是一个不费吹灰之力的决定。”

AdGreetz 高级软件工程师 Noor Thabit

• 缺乏开放数据标准和供应商锁定： - OLAP 系统，尤其是较旧的基于云的解决方案，通常使用专有格式和封闭生态系统，导致供应商锁定并限制组织的灵活性。这使得在不产生巨额成本的情况下与其他工具集成或迁移到新平台变得困难。此外，专有存储选项可能会增加长期数据存储成本。OLAP 数据库通过采用开放数据标准和支持与使用 Iceberg 等格式的数据湖集成来解决这些挑战。通过遵守开放标准，确保了与其他系统的互操作性，从而降低了供应商锁定的风险。此外，利用更便宜的存储选项（如数据湖中的对象存储）的能力降低了长期存储成本，同时允许企业在如何管理和访问其数据方面保持灵活性。

• 数据安全： OLAP 系统通常处理敏感信息，因此数据安全是重中之重。保护这些数据免受未经授权的访问和泄露需要强大的加密、多因素身份验证以及严格遵守 GDPR 和 HIPAA 等数据保护标准。在保持强大安全性的同时保持高性能是一项重大挑战 - 云数据仓库通过集成到可扩展架构中的高级安全功能来解决这一挑战。这些解决方案使组织能够在不影响复杂分析任务所需的速度和效率的情况下有效地保护数据。

OLTP 系统旨在处理大量简短的实时事务，使其成为现代业务运营的基石。这些系统在高度一致性和即时“读后写”保证至关重要的环境中表现出色。在 OLTP 数据库中，ACID（原子性、一致性、隔离性、持久性）事务确保一旦事务（例如插入、更新或删除）提交，任何后续读取都将反映最新的更改。这种事务完整性是确保企业可以依赖准确、最新信息的关键。借助 OLTP 系统，用户可以在多个并发事务中执行频繁更新，同时仍然保持强大的数据一致性保证，确保任何读取操作在写入操作后立即检索到最新数据。这对于金融交易、订单管理和客户互动等运营任务至关重要，在这些任务中，数据准确性和及时性至关重要。

OLTP 用途的一个典型示例是在零售环境中，实时更新库存水平、销售交易和客户帐户管理至关重要。每个零售店都连接到中央 OLTP 数据库，确保库存水平和销售数据在交易发生时立即更新。此设置还用于管理客户忠诚度计划、跟踪付款和实时处理退货。OLTP 还为网上银行提供支持，客户可以在网上银行执行资金转账、账单支付和帐户更新等交易，并获得即时反馈和安全处理。

OLTP 数据库为面向消费者的应用程序中的度假预订、送餐和短信服务等服务提供支持。这些服务依赖于 OLTP 提供实时可用性检查、安全支付处理和无缝用户体验的能力。因此，消费者可以从建立在 OLTP 技术基础上的快速可靠的服务中受益。

OpenMeter 是 OLTP 实际应用的一个真实示例，该公司专门为 AI 和云公司提供实时、基于使用量的计费解决方案。OpenMeter 利用 Postgres 安全有效地存储和管理事务数据，确保准确和实时地跟踪客户使用情况。在此处阅读更多信息此处。

OLAP 系统对于分析大型数据集和提取有价值的见解至关重要，从而使企业能够做出明智的、数据驱动的决策。与侧重于实时事务处理的 OLTP 不同，OLAP 系统擅长执行复杂的查询，例如聚合和连接，从而帮助各行各业的企业从历史趋势、模式和绩效指标中获得见解。无论是财务预测、市场分析还是客户行为研究，OLAP 系统都为深入分析任务提供了支持，这些任务为长期战略和优化提供信息。

医疗保健、制造业和广告等行业利用 OLAP 系统来推动决策过程。例如，在医疗保健领域，OLAP 使提供商能够对患者结果进行深入分析，从住院时长、诊断或人口统计信息等各种维度中发现见解。制造公司使用 OLAP 进行供需预测、生产优化和盈利能力分析，方法是根据客户、产品或地区对数据进行细分。在广告领域，OLAP 工具帮助公司分析客户参与度和行为，通过深入的数据细分来改进广告系列定位和客户生命周期价值。

OpenMeter提供了一个真实世界的示例，说明 OLAP 如何为高级分析提供支持。OpenMeter 使用 Postgres 存储来自其计量系统的事务数据，需要一个 OLAP 系统来处理每秒分析数百万计费事件的高吞吐量要求。

“随着 AI 和基于使用量的定价模式的日益普及，计量已成为为计费、成本和收入运营提供支持的关键”

OpenMeter 首席执行官兼联合创始人 Peter Marton

通过使用 OLAP 数据库 ClickHouse，OpenMeter 构建了一个稳健、可扩展的系统，用于聚合基于使用量的计费的实时数据。

“我们开发了一个可扩展、稳健的计量系统，能够处理每秒数百万计费事件，该系统构建在 ClickHouse Cloud 之上”

OpenMeter 首席执行官兼联合创始人 Peter Marton

ClickHouse 使 OpenMeter 能够实时收集、清理和分析海量计量数据，这对于提供基于使用量定价模式的企业至关重要。凭借其 OLAP 功能，OpenMeter 通过面向客户的仪表板提供可操作的见解，使企业能够有效地监控实时使用量和成本。

LangChain 在其 LangSmith 平台中利用 OLAP，该平台为 LLM（大型语言模型）应用提供可观测性和评估。LangChain 最初依赖 Postgres 进行应用引导，后来转而使用 ClickHouse 作为其分析数据库，以管理高吞吐量的数据摄取并支持低延迟查询。

“最终，我们清楚地意识到，我们需要添加另一个数据库来补充 Postgres 以满足我们的用例，并为我们的用户解锁实时洞察。”

LangChain 联合创始人 Ankush Gola

ClickHouse 为 LangSmith 提供实时分析能力，使开发人员能够跟踪关键指标、评估模型变更并可视化 LLM 应用的追踪信息。这种转变使 LangChain 能够处理大量的日志和追踪数据，同时为用户提供快速、交互式的体验，从而显著改善开发人员的工作流程。

Instacart 使用 OLAP 通过名为 Yoda 的实时欺诈检测系统来打击平台上的欺诈行为。该系统依赖 ClickHouse 来存储和分析从交易和事件中生成的大量实时数据。Instacart 团队解释说：

“ClickHouse 的设计和优化明确针对分析查询。这完美契合了需要持续分析数据以查找可能指示欺诈的模式的应用需求。”

在此处阅读更多内容

选择 OLAP 还是 OLTP 取决于您的业务需求，特别是您处理的数据类型、您执行的操作以及您与数据的交互方式。OLTP 系统非常适合实时事务处理，其中即时数据更新和准确性至关重要。相比之下，OLAP 系统在需要复杂查询、聚合历史数据以及生成用于战略决策的见解的情况下表现出色。

在许多情况下，企业可以从同时使用这两种系统中获益。OLTP 系统可以捕获日常事务并立即更新数据，而 OLAP 系统可以处理这些数据以进行更深入的分析和报告。是否使用 OLAP 或 OLTP（或两者都使用）的决定应以查询复杂性、所需的响应时间以及可扩展性考虑因素为指导。

这很少是一个必须做出妥协的二元决策过程。OLAP 有望在涉及复杂聚合和连接的查询中提供更快的查询性能，并且通常在数据集很大（例如，数 TB）的情况下更受欢迎。但是，这要求用户做出一些妥协。用例很少能完美分类，但需要用户根据其工作负载最重要的属性做出决定。

如果您需要处理大量简短、快速的事务（例如，销售订单、付款或客户互动），那么 OLTP 将是最佳选择。它可以确保运营任务的即时一致性和最新的数据。如果您期望更大的数据量，并且您能够放宽这些要求并接受最终一致性语义，那么您可能会更倾向于 OLAP 系统。此外，如果您有许多必须以事务方式更新并在几毫秒内可用的小更新，那么该工作负载是天然的 OLTP 工作负载，但如果可以容忍几秒钟，则可以使用 OLAP 实现。

对于涉及分析大量数据（即 > 1TB）的任务，例如生成报告、识别趋势或进行财务预测，OLAP 系统提供处理复杂、多维查询所需的功能。此外，如果您需要分析查询的快速响应，尤其是在涉及实时分析或仪表板的场景中，现代实时 OLAP 数据库（如 ClickHouse）旨在即使在大型数据集上也能提供低延迟性能。这些数据库还提供高写入吞吐量性能，并能够在几秒钟内使数据可用。

在许多现代业务架构中，同时拥有无缝协作的 OLTP 和 OLAP 系统至关重要。OLTP 系统充当运营数据的权威来源，实时事务在此处处理，数据不断更新。然而，涉及对大型数据集进行复杂查询的分析工作负载最好由 OLAP 系统处理。

因此，组织越来越多地寻求部署这两种系统作为“默认数据堆栈”。但是，这要求每个系统都具有一致的数据视图，OLTP 提供权威视图，而繁重的分析查询则卸载到 OLAP 系统。弥合这一差距需要保持这两个系统的同步，对 OLTP 系统的更新应尽快反映在 OLAP 系统中。这个问题通过称为变更数据捕获 (CDC) 的过程来解决。

请注意，习惯于 OLTP 系统的用户在采用 OLAP 系统时，通常需要熟悉略有不同的数据建模挑战。OLAP 供应商（例如 ClickHouse）越来越多地提供指南来帮助完成此过程。

现代 CDC 解决方案使企业能够在近乎实时的状态下同步其 OLTP 和 OLAP 系统之间的数据，确保分析查询基于最新的可用数据。这些解决方案捕获来自 OLTP 系统的更改，例如插入、更新和删除，然后有效地将这些更改发送到 OLAP 系统。此处的目的是最大程度地减少数据交付的延迟，同时避免完整数据加载的沉重负担和源 OLTP 系统上的高资源开销。这种持续同步对于确保决策者和分析系统能够访问最新鲜的数据，而不会给 OLTP 系统增加过多的负载至关重要。

传统的数据捕获方法（例如批处理）以固定的时间间隔将大量数据从 OLTP 系统移动到 OLAP 系统。但是，此方法引入了多个挑战，包括高延迟、未更改数据的低效处理以及源系统上增加的负载。这些缺点使批处理不适合需要实时洞察的现代应用程序。

CDC 通过监控和仅捕获实时对数据所做的更改来解决这些限制。这种事件驱动的方法确保仅将修改后的数据传输到 OLAP 系统，从而显著减少处理的数据量并确保最小的延迟。此外，CDC 确保记录中间更改，这意味着捕获每个状态更改，而不仅仅是最终状态，而最终状态在批处理中经常被遗漏。

有几种方法可以实施 CDC，具体取决于所涉及系统的特定要求、数据的复杂性和用例。

在拉取式方法中，OLAP 系统定期从 OLTP 系统拉取更改。这通常使用时间戳或单调递增的 ID 来实现，其中 OLAP 系统查询自上次更新以来所做的更改。这种方法通常更简单，但由于数据提取的周期性，可能会引入延迟。它适用于近乎实时数据就足够的工作负载。

例如，一个简单的 cron 计划的 PostgreSQL 函数可能会定期从 OLTP 数据库拉取数据并将其发送到 ClickHouse，使用时间戳来识别更改。

但是，拉取式 CDC 可能会增加 OLTP 系统上的负载，特别是如果更改查询频繁，并且它需要直接访问源数据库，这对于生产环境而言可能并不理想。

在推送式 CDC 方法中，OLTP 系统在数据更改发生时立即主动将数据更改发送到 OLAP 系统，通常是实时的。这确保 OLAP 系统几乎始终与 OLTP 系统的最新数据同步。为了实现可靠的数据交付，此方法通常涉及事件流平台，例如 Apache Kafka。

在此模型中，OLTP 系统中所做的每个更改（例如，插入、更新、删除）都会被捕获并通过消息队列推送到 OLAP 系统，从而确保最小的延迟。然后，事件流由 OLAP 系统使用，该系统近乎实时地处理这些更改。

此方法提供高可扩展性，非常适合需要在 OLTP 和 OLAP 系统之间实现近乎瞬时更新的用例。例如，Kafka 确保消息（即数据更改）可靠交付，并且如果在 OLAP 系统中发生任何问题，消息队列将保留数据，直到可以处理为止。

实时 OLAP 数据库（例如 ClickHouse）专门设计用于处理高吞吐量的数据摄取，使其成为与 CDC 管道集成的理想选择。CDC 使从 OLTP 系统到 OLAP 系统的更新能够持续流动，从而确保分析查询在最新的可用数据上执行。但是，虽然将 CDC 与 Kafka 集成可以提供可靠的端到端交付保证和缓冲，但它可能会引入额外的延迟和架构复杂性，这对于需要近乎即时数据更新的应用程序而言可能并不理想。

对于需要更快、更优化的交付系统的场景，PeerDB 等工具为实时数据捕获提供了一种更简化的方法，尤其是在 PostgreSQL 和 ClickHouse 之间。PeerDB 专注于通过提供极速快照来最大限度地减少延迟，从而将典型的 Postgres 到 ClickHouse 的传输时间从数小时缩短到数分钟，而不会给源系统带来沉重负载。这在需要高效同步 TB 级数据集的较大用例中尤其重要。通过仔细管理查询成本、架构演变和重新同步，PeerDB 确保变更数据捕获过程对关键 OLTP 数据库保持非侵入性。

“我们已经使用 PeerDB 将 Postgres 到 ClickHouse 的快照时间从 10 多个小时缩短到 15 分钟。将 ClickHouse 强大的原生分析能力与 PeerDB 的实时数据捕获能力相结合，将大大简化我们的数据处理工作流程。”

Javier Erro Garcia，Vueling Airlines 云架构经理

与依赖 Kafka 进行数据流式传输的系统相比，PeerDB 与 ClickHouse 的直接集成允许构建更优化的数据管道，并显著减少延迟。这对于需要实时洞察而又不想因传统缓冲系统引入延迟的企业至关重要。

通过提供高效的 CDC 集成，PeerDB 和 ClickHouse 使企业能够无缝地融合 OLTP 的事务完整性和 OLAP 的分析能力，确保关键数据快速高效地从运营系统流向分析平台。这种集成使组织能够以最小的延迟做出及时的、数据驱动的决策。