云数据仓库的解耦

我们非常感谢云数据仓库，但它们称霸的时代即将结束。

在过去的 10 年里，Snowflake 等公司彻底改变了整个行业，该行业以前依赖于自管理部署的封闭和专有生态系统（由 Oracle、Teradata 等提供支持）。它们使组织能够将 PB 级的关键工作负载迁移到云中，从而为更广泛的集成、协作和应用程序开放这些数据集——使数据访问民主化并极大地提高了数据价值。

随着时间的推移，企业开始更仔细地检查其数据存储，同时考虑其中包含的信息的性质以及可以从中获得的潜在效用。由于组织数据现在更容易获得，开发团队从静态批处理报告转向构建交互式应用程序——用于内部使用和外部分发。

但是，正是在这里，他们开始遇到挑战。由于云数据仓库专为离线报告而设计（现在仅在云基础设施上运行），因此其架构和定价模型无法优化为交互式数据驱动应用程序的后端。因此，组织最终会遇到性能不佳（响应时间为 10 秒到几分钟，而不是亚秒级和毫秒级）、成本急剧上升（通常比替代方案高 3-5 倍）以及查询并发性低（不适合面向外部的应用程序）的问题。

因此，组织转向了实时分析数据库，这些数据库经过优化，可以为数据密集型应用程序提供支持。随着时间的推移，这些实时分析数据库的采用和运营导致了一种新的架构模式，我们将其称为实时数据仓库。下面，我们将说明为什么传统数据仓库并非为实时分析应用程序的需求而设计，以及实时数据仓库如何解决这些挑战，以及如何导致向“解耦云数据仓库”的架构转变。

传统数据仓库已经存在很多年了。它旨在统一内部业务报告，当时离线和批处理是常态，并且通常依赖于

• 用于将数据从源系统迁移的大量批处理 ETL 作业
• 大型表的巨型联接以统一分散的数据集以进行集中查询
• 不同团队使用特定数据集的静态“视图”或“集市”

然而，一旦这些数据在云中可用，就很容易模糊用例的界限，超出数据仓库的范围

由 Snowflake、BigQuery 和 Redshift 等平台引领的云数据仓库的兴起，通过提供可扩展性、便利性以及最重要的是灵活性，以及对一类非常重要的数据工作负载的开放性，帮助实现了数据仓库的现代化。然而，一旦这些数据在云中可用，就很容易模糊用例的界限，超出数据仓库的范围，将云数据仓库呈现为一种“一刀切”的方法，用于所有用例，从面向用户的分析到服务器端转换、仪表盘、可观察性、机器学习等等。这导致了反复出现的性能挑战、用户体验下降和大量失控成本，需要重新评估数据架构。

对于一个成熟的行业来说，将构建新型应用程序的趋势斥为利基市场是很诱人的。如果你问一个传统的数据仓库架构师，他们可能会告诉你“批数据摄取和报告”就可以了，但这与事实相去甚远。

现在，日常使用交互式数据驱动生产力应用程序已成为营销、销售、工程、运营以及几乎所有其他专业人士的必要条件。这些应用程序通过高度交互的方式分析海量数据来驱动。例如，如果您是营销人员，您需要实时了解谁访问了您的网站，谁在查看您的社交媒体帖子以及如何使用您的广告。如果您是财务分析师，您需要在瞬息万变的市场中快速做出多次中午和收盘决策。如果您是负责 24/7 SaaS 服务的 DevOps 工程师，您将承担越来越高的应用程序可用性要求——99.999% 的正常运行时间意味着每年只有 5 分钟的停机时间！

因此，出现了全新的行业，其需求无法通过传统数据仓库解决，而是需要实时数据仓库。

• 营销分析提供对来自多个渠道的营销活动的可见性——网络、社交、广告活动，汇总这些信息，允许营销人员运行交互式查询和报告，并主动发现数据海洋中的异常值——例如快速增长的区域、子市场或行业，并建议优化营销支出的方法。
• 销售分析显示销售区域的活动，例如按来源划分的潜在客户流、免费/试用产品的使用情况、销售周期活动、售后消费、账户健康状况和流失情况，汇总这些数据，并主动提出重要的机会或风险因素供销售专业人员采取行动——关键潜在客户和面临风险的客户。
• 电子商务和零售分析涵盖零售生命周期——从商品和库存到销售活动到履行，随着时间的推移跟踪和交互式查询这些数据，并主动建议优化运营物流的方法。
• 财务分析跟踪财务工具活动，例如买卖、看涨期权、看跌期权，并允许分析师根据多个选择条件快速调整这些信息，并建议采取行动，包括潜在的未来交易和套期保值。
• 可观察性和物联网监控从 SaaS 基础设施或制造车间和设备中摄取结构化日志、指标和跟踪事件，将其与设备和用户信息等元数据交叉引用，并随着时间的推移汇总错误和延迟信息，以及根据历史数据预测的故障区域。

此外，许多驱动 SaaS 业务核心的数据集也将由内部利益相关者用来了解其业务。因此，内部和外部用户都很重要。

分析应用程序的内部用户包括产品、营销和业务分析师，他们一直是数据仓库系统的主要目标受众。但是，这些用户不再愿意接受缓慢的洞察时间体验。为了在各自的角色中保持竞争力，他们需要更快地做出数据驱动的决策，如果内部数据平台无法满足他们的需求，他们将提倡采用具有快速交互性能的第三方工具。

除了现有的内部用例之外，企业也越来越多地开展内部 AI/ML 计划，内部数据科学家需要查询访问相同的数据以开发更好的 ML 模型和基于 AI 的功能。数据科学家也需要交互式性能——查询速度直接关系到他们开发新机器学习模型或构建基于 AI 的功能的速度。

当用户尝试将云数据仓库用于实时分析时，他们会遇到挑战，因为传统数据仓库的架构和定价模型无法优化为交互式数据驱动应用程序的后端。

这些应用程序的要求通常包括能够

• 服务结合持续加载和历史数据（最多数年）的查询
• 服务需要高度交互式访问模式的查询，例如复杂的筛选器和聚合，并在高并发率下进行
• 实现沉浸式应用程序所需的查询延迟（理想情况下低于一秒）
• 在处理每秒数百万事件的摄取时，操作高达 TB 和 PB 的历史数据

相反，使用云数据仓库，用户面临

• 数据传播延迟。由于数据通过复杂的 ETL 管道传播导致的多小时延迟、对需要昂贵 JOIN 并减慢实时应用程序的高度非规范化数据集的依赖以及支持传统架构中实时查询性能的巨额财务成本，内部数据工程团队难以满足这些日益增长的需求。
• 查询性能缓慢。用户获得的查询性能响应时间以数十秒甚至数分钟来衡量，而不是毫秒，当他们试图通过投入更多计算来解决问题时，他们会遇到下一个问题——成本。
• 成本急剧上升。云数据仓库的用户支付 3-5 倍于替代方案的费用并不罕见，即使性能低于标准，因为他们的定价昂贵，并且他们的架构需要更多系统资源来处理相同的负载。
• 查询并发性低。查询并发性要求远高于传统数据仓库的预期——数百甚至数千个并发用户运行查询，并期望毫秒级的响应和具有交互性的查询，并且以极低的价格实现。

最终，云数据仓库只能通过在成本方面过度补偿来服务低延迟、交互式工作负载。这就像花大量的钱不断改装一辆旧车以参加一级方程式比赛，而正确且更便宜的答案是使用一辆真正的一级方程式赛车。

最终，云数据仓库只能通过在成本方面过度补偿来服务低延迟、交互式工作负载——要么为 Snowflake 中的物化视图等高级功能支付更多费用，要么投入越来越多的计算来更快地处理查询。这就像花大量的钱不断改装一辆旧车以参加一级方程式比赛，而正确且更便宜的答案是使用一辆真正的一级方程式赛车。

实时数据仓库是一个融合的数据平台，针对运行数据密集型交互式应用程序进行了优化，这些应用程序服务于内部和外部受众。

如今，企业将多个系统拼接在一起以满足围绕交互式应用程序的不断变化的需求，而无需重新思考其数据系统的整体架构。引入实时数据仓库的概念简化了数据流并减少了依赖关系的数量。

例如，以下架构对于处理大量分析数据并试图引入可以处理实时分析工作负载的组件的现代组织来说并不罕见。此架构结合了实时分析数据库（支持外部应用程序）的使用，但仍利用传统数据仓库用于其他内部用例。

高度依赖传统数据仓库的现代数据栈

实时数据仓库以不同的方式解决了这一挑战：它以统一的方式包含外部和内部交互式数据应用程序，并将离线报告（如果需要）卸载到冷归档系统——越来越普遍的是对象存储，但有时也是容量减少的传统数据仓库。

基于实时数据仓库的现代数据栈

我们将从单体云数据仓库向外的演变称为“云数据仓库的解绑”。经历这种转型的组织会仔细检查和识别构建交互式数据驱动应用程序所需的工作负载，并将这些工作负载迁移到实时数据仓库。

在此过程中，他们还会确定其余的冷数据是否应保留在传统数据仓库中，或者迁移到基于“数据湖”概念的更开放的架构中。采用数据湖具有更便宜的存储和越来越开放的标准（Parquet 数据格式之上的 Delta Lake、Iceberg 和 Hudi）等优势。这意味着对于不需要实时性能的应用程序，多个团队和应用程序可以访问相同的事实来源，而无需多次存储数据或将其保存在专有系统中。

过去三十年数据生态系统是如何演变的

这不是数据生态系统中第一次出现解绑浪潮。我们从大型机（捆绑）到关系数据库（解绑）到传统数据仓库（捆绑）到早期云提供商（解绑）到云数据仓库（捆绑）。那么这种解绑趋势会持续下去吗？

我们预测，随着时间的推移，它们中的大多数将转向更具供应商中立性的数据湖方法，并且云数据仓库供应商将开放其技术栈以包含直接在数据湖之上运行的功能。

无论答案是什么，我们相信跨数据平台分离存储和计算的趋势（以对象存储作为主要数据存储）将发挥重要作用。我们看到它推动了跨供应商和技术的暖存储和冷存储中数据湖的持续采用。虽然由于现有投资，一些组织会在一段时间内坚持使用传统数据仓库，但我们预测，随着时间的推移，它们中的大多数将转向更具供应商中立性的数据湖方法，并且云数据仓库供应商将开放其技术栈以包含直接在数据湖之上运行的功能。

解绑/重新捆绑周期

为了满足交互式数据驱动应用程序的高需求以及大规模合理成本的实用性，实时数据仓库必须支持

• 从实时数据源（如 Apache Kafka）进行交钥匙式持续数据加载
• 持续更新的物化视图，即使是繁重的查询也能在几秒钟内运行
• 对数十亿行数据进行筛选和聚合查询的毫秒级性能

为了确保内部分析师的实用性，实时数据仓库必须支持

• 与 BI 工具（如 Apache Superset、Grafana、Looker、Tableau）集成，供内部用户使用
• 能够归档到对象存储上的数据湖
• 能够对存储在对象存储中的数据执行 ad-hoc 查询

为了满足这些要求，实时数据仓库越来越需要在分离的存储和计算架构中运行，通过利用对象存储的最新功能针对实时工作负载的需求进行了优化。这种架构的好处导致计算与存储的独立扩展、计算层的自动和水平扩展，这两者都导致更好的动态资源分配，从而提高性能和计算成本。对于大型数据集（许多 TB 和 PB），这也会导致更合理的存储成本。

最后，随着越来越多的用例需要将传统分析与 AI 增强的分析相集成，分析数据库越来越需要为机器学习功能（如模型训练和向量搜索）提供支持。

这些是我们构建 ClickHouse Cloud 的要求，因此，它在实时应用程序中的性能比传统数据仓库高出几个数量级。

ClickHouse Cloud 基于 ClickHouse，目前被认为是最流行的开源实时分析数据库。自 2016 年开源以来，它已在各种用例和行业领域得到广泛采用。

ClickHouse 被用作网络上最流行的 SaaS 服务的后端，涵盖营销、销售、零售和电子商务分析。它也是可观察性应用程序的流行后端，由 SaaS 可观察性服务提供商和构建自定义可观察性平台的内部团队使用。在所有这些用例中，ClickHouse 从 Apache Kafka 等实时数据源持续摄取数据，并运行高度并发的分析查询工作负载，为面向客户的应用程序提供支持。它被许多用户利用的一个超级能力是物化视图，它允许真正灵活的原位数据转换和大幅提高查询速度。ClickHouse 轻松地在数十亿行数据之上实现毫秒级的分析性能。

在面向内部的应用程序方面，ClickHouse 越来越被用作传统数据仓库（如 Snowflake、Redshift 和 BigQuery）的替代方案，因为它拥有广泛的集成生态系统，使您可以轻松地将数据从对象存储移动到 ClickHouse，以及将 ClickHouse 作为查询引擎直接在存储在 Parquet 和许多其他格式中的对象存储中的数据之上运行查询，并可以选择由 Iceberg、Delta Lake 和 Hudi 管理。

ClickHouse 正在成为构建下一代 Gen AI（生成式人工智能）应用程序的数据平台。借助 ClickHouse，开发人员除了应用程序数据和事件外，还可以存储训练数据和向量嵌入，所有这些都存储在一个数据库中，在一个数据存储中结合了基于 AI 和基于启发式的分析。

ClickHouse Cloud 扩展了这些基础。它为用户和管理员提供了一种交钥匙式的方法来部署 ClickHouse，并分离存储和计算——这种架构具有许多优势，包括几乎无限的存储和轻松的计算水平扩展。在 ClickHouse Cloud 中，此架构已针对运行实时工作负载进行了优化，并利用了利用对象存储并行性、复杂的缓存和预取技术的低级优化。ClickHouse Cloud 附带用于管理员（集群管理、可观察性、备份）和分析师（SQL 控制台、BI 工具集成、AI 辅助 SQL 查询）的内置工具。

云数据仓库实现了许多人认为不可能的事情：将巨大的分析工作负载从专有的类似大型机的自管理解决方案转移到云中。这种演变最终导致人们仔细审查如何使用仓库中的数据来构建越来越多的交互式数据驱动应用程序，并导致越来越多的趋势将云数据仓库解绑，现在部署在更开放和互联的环境中。

由于这种趋势，实时数据仓库正在发展成为构建数据密集型交互式应用程序的关键架构组件。它用于为面向客户的应用程序提供支持，并使内部利益相关者能够利用相同的数据集进行商业分析和数据科学。实时数据仓库充当为实时应用程序提供支持的分析数据集的主要数据存储，并且通常与对象存储上的数据湖结合使用，用于长期归档和对不需要实时性能的数据进行 ad-hoc 访问。

要了解有关 ClickHouse 如何在这些用例中采用的更多信息，请参阅

• ClickHouse 作为实时分析的数据库后端
• ClickHouse 作为 Snowflake 的替代方案
• ClickHouse 作为 Redshift 的替代方案
• ClickHouse 作为 BigQuery 的替代方案
• ClickHouse 作为构建机器学习应用程序的平台