我们非常感谢云数据仓库，但它们独霸天下的时代即将结束。
在过去的 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 倍，即使性能低于标准，因为他们的定价昂贵，并且他们的架构对于相同的工作负载需要更多的系统资源。
- 查询并发性低。 查询并发性要求远高于传统数据仓库的预期——成百上千的并发用户运行查询，并期望毫秒级响应的交互性和延迟，并且成本要大幅降低。
最终，云数据仓库只能通过过度补偿成本来服务于低延迟、交互式工作负载。这就像花费巨额资金不断改装旧车以参加一级方程式比赛，而正确且更便宜的答案是使用真正的 F1 赛车。
最终，云数据仓库只能通过过度补偿成本来服务于低延迟、交互式工作负载——要么为 Snowflake 中物化视图等高级功能支付更多费用，要么投入越来越多的计算来更快地处理 BigQuery 中的查询。这就像花费巨额资金不断改装旧车以参加一级方程式比赛，而正确且更便宜的答案是使用真正的 F1 赛车。
实时数据仓库简介
实时数据仓库是一个融合数据平台，经过优化，可运行为内部和外部受众提供服务的数据密集型交互式应用程序。
如今，企业将多个系统拼接在一起，以满足围绕交互式应用程序不断变化的需求，而没有重新思考其数据系统的整体架构。引入实时数据仓库的概念简化了数据流并减少了依赖项的数量。
例如，以下架构对于处理大量分析数据并尝试引入可以处理实时分析工作负载的组件的现代组织来说并不罕见。此架构结合使用了实时分析数据库（以支持外部应用程序），但仍然利用传统数据仓库进行其他内部用例。
高度依赖传统数据仓库的现代数据堆栈
实时数据仓库以不同的方式解决了这一挑战：它以统一的方式包含外部和内部交互式数据应用程序，并将离线报告（如果需要）卸载到冷归档系统——越来越常见的是对象存储，但有时也是容量减少的传统数据仓库。
基于实时数据仓库的现代数据堆栈
云数据仓库的解绑
我们将从单体云数据仓库的演变称为“云数据仓库的解绑”。经历这种转型的组织会仔细检查和识别构建交互式数据驱动应用程序所需的工作负载，并将这些工作负载迁移到实时数据仓库。
在此过程中，他们还确定其余的冷数据是应该保留在传统数据仓库中，还是应该迁移到基于“数据湖”概念的更开放的架构。采用数据湖具有诸如更便宜的存储和日益开放的标准（Parquet 数据格式之上的 Delta Lake、Iceberg 和 Hudi）等优点。这意味着对于不需要实时性能的应用程序，多个团队和应用程序可以访问相同的真值来源，而无需多次存储数据或将其保存在专有系统中。
数据生态系统在过去三十年中的演变
这并不是数据生态系统中的第一次解绑浪潮。我们经历了从大型机（捆绑）到关系数据库（解绑）到传统数据仓库（捆绑）到早期云提供商（解绑）到云数据仓库（捆绑）。那么这种解绑趋势会持续下去吗？
我们预测，随着时间的推移，他们中的大多数人将转向更供应商中立的数据湖方法，并且云数据仓库供应商将开放其技术堆栈，以包括直接在数据湖之上运行的功能。
无论答案是什么，我们都相信跨数据平台（以对象存储作为主要数据存储）分离存储和计算的趋势将发挥重要作用。我们看到它推动了跨供应商和技术的用于温存储和冷存储的数据湖的持续采用。虽然一些组织由于现有投资将在一段时间内坚持使用传统数据仓库，但我们预测，随着时间的推移，他们中的大多数人将转向更供应商中立的数据湖方法，并且云数据仓库供应商将开放其技术堆栈，以包括直接在数据湖之上运行的功能。
解绑/重新捆绑周期
如何为您的用例选择合适的实时数据仓库
为了满足交互式数据驱动应用程序的高要求以及大规模合理成本的实用性，实时数据仓库必须支持
- 来自实时数据源（例如 Apache Kafka）的交钥匙连续数据加载
- 持续更新的物化视图，即使繁重的查询也能在几秒钟内运行
- 数十亿行数据的过滤器和聚合查询的毫秒级性能
为了确保内部分析师的实用性，实时数据仓库必须支持
- 与 BI 工具（例如 Apache Superset、Grafana、Looker、Tableau）集成，供内部用户使用
- 能够归档到对象存储上的数据湖
- 能够对存储在对象存储中的数据执行即席查询
为了满足这些要求，实时数据仓库越来越需要以分离的存储和计算架构运行，并通过利用对象存储的最新功能针对实时工作负载的需求进行优化。这种架构的优势在于计算与存储的独立扩展、计算层的自动和水平扩展，这两者都导致了更好的资源动态分配，从而提高了计算的性能和成本。对于大型数据集（TB 级和 PB 级），这也大大降低了存储成本。
最后，随着越来越多的用例要求将传统分析与 AI 增强分析集成，分析数据库越来越需要支持机器学习功能，例如模型训练和向量搜索。
ClickHouse 作为实时数据仓库
这些是我们构建 ClickHouse Cloud 所依据的要求，因此，它在实时应用程序中的性能比传统数据仓库高出几个数量级。
ClickHouse Cloud 基于 ClickHouse 构建，ClickHouse 目前被认为是最流行的开源实时分析数据库。自 2016 年开源以来，它已在各种用例和行业垂直领域获得广泛采用。
ClickHouse 用作网络上最流行的 SaaS 服务的后端，跨越营销、销售、零售和电子商务分析。它也是可观察性应用程序的流行后端，被可观察性服务的 SaaS 提供商和构建自定义可观察性平台的内部团队使用。在所有这些用例中，ClickHouse 持续从 Apache Kafka 等实时数据源摄取数据，并运行高度并发的分析查询工作负载，为面向客户的应用程序提供支持。许多用户利用其超级功能之一是物化视图，它允许非常灵活的原位数据转换和大幅提高查询速度。ClickHouse 可以轻松地在数十亿行数据之上实现毫秒级的分析性能。
当涉及到面向内部的应用程序时，ClickHouse 越来越多地被用作传统数据仓库（如 Snowflake、Redshift 和 BigQuery）的替代方案，因为它具有广泛的集成生态系统，可以轻松地将数据从对象存储移动到 ClickHouse，以及直接在存储在 Parquet 和许多其他格式的对象存储中的数据之上，以及可选地由 Iceberg、Delta Lake 和 Hudi 管理的数据之上，从 ClickHouse 运行查询作为查询引擎。
ClickHouse 正在成为构建下一代 Gen AI（生成式人工智能）应用程序的数据平台。借助 ClickHouse，开发人员可以将训练数据和向量嵌入以及他们的应用程序数据和事件存储在单个数据库中，从而在一个数据存储中结合基于 AI 和基于启发式的分析。
ClickHouse Cloud 在这些基本原理的基础上进行了扩展。它为用户和管理员提供了一种交钥匙方式来部署具有存储和计算分离的 ClickHouse——这种架构具有许多优势，包括几乎无限的存储和轻松的计算水平扩展。在 ClickHouse Cloud 中，这种架构经过优化，可通过利用对象存储并行性、复杂的缓存和预取技术来运行实时工作负载。ClickHouse Cloud 配备了适用于管理员（集群管理、可观察性、备份）以及分析师（SQL 控制台、BI 工具集成、AI 辅助 SQL 查询）的内置工具。
结论
云数据仓库完成了许多人认为不可能完成的任务：将庞大的分析工作负载从专有的类似大型机的自管理解决方案转移到云端。这种演变最终导致了对如何使用仓库数据来构建日益交互式的数据驱动应用程序的仔细检查，并导致了日益增长的解绑云数据仓库的趋势，现在部署在更开放和互连的环境中。
由于这种趋势，实时数据仓库正在发展成为构建数据密集型交互式应用程序的关键架构组件。它用于为面向客户的应用程序提供支持，并使内部利益相关者能够利用相同的数据集进行业务分析和数据科学。实时数据仓库充当为实时应用程序提供支持的分析数据集的主要数据存储，并且通常与对象存储上的数据湖相结合，用于长期归档和对不需要实时性能的数据进行临时访问。
延伸阅读
要详细了解 ClickHouse 如何在这些用例中被采用，请参阅
