从业务系统到数据智能：数据分析系统的完整演进

想象一下：你站在1985年一家繁忙的零售店里。每当顾客购买商品，收银机都会立即记录交易信息——商品、价格、时间戳。这便是店铺的脉搏，是运营的脉动。现在想象一下，你试图回答以下问题：“上个季度哪些商品最畅销？”或者“我们所有门店的营收趋势如何？”突然间，这套每秒处理数千笔交易的系统却难以给出答案。这就像让一个短跑运动员去跑马拉松——同一个运动员，却要参加完全不同的比赛。

记录当下发生的事情与理解其意义之间的根本张力，推动了数据系统五十年来的创新。今天，我们将追溯这一发展历程，从最早的事务型数据库到如今能够用自然语言回答问题的AI驱动型分析平台。理解这一演变过程不仅仅是了解历史，更是我们今天做出更佳架构决策的路线图。

数据的两个世界：OLTP 与 OLAP

在深入探讨时间线之前，让我们先确定塑造之后一切的核心区别。

在线交易处理 (OLTP)系统旨在处理企业的日常运营。您可以将其想象成收银机——它们需要快速、准确，并且始终可用，以记录每一笔交易。当您在线订购商品、更新个人资料或在账户之间转账时，您就是在与 OLTP 系统交互。

另一方面，OLAP（联机分析处理）系统是为分析和报告而设计的。它们是会计人员在月末生成的综合报告，汇总成千上万甚至数百万笔交易，以揭示模式、趋势和洞察。OLTP 关注的是“刚刚发生了什么？”，而 OLAP 关注的是“这一切意味着什么？”

根本区别在于：

OLTP 系统优化目标是快速写入大量小事务并即时读取特定记录。OLAP 系统优化目标是读取海量数据、聚合数据并跨多个维度进行复杂计算。一个系统无法高效地同时完成这两项任务——正是这种认识激发了数十年的架构创新。

关键要点：OLTP 处理实时操作事务；OLAP 处理基于历史数据的分析查询。这些截然相反的需求导致了完全不同的系统设计。

OLAP 和数据立方体的兴起（20 世纪 90 年代）

到了20世纪90年代，企业迫切需要更快捷的数据分析方法。解决方案以专用OLAP系统的形式出现，该系统引入了一个革命性的概念：数据立方体。这些系统不再存储原始交易数据，而是预先聚合多个维度的数据。

可以将数据立方体想象成一个多维电子表格。例如，您可以以销售额作为衡量指标（即您要统计的数值），并设置三个维度：时间（年、季度、月）、产品（类别、品牌、SKU）和地理位置（国家、地区、城市）。立方体中的每个单元格都包含一个预先计算好的值，例如“2023 年第三季度耐克跑鞋在加利福尼亚州的总销售额”。这意味着以前需要几个小时才能完成的查询，现在只需几秒钟即可返回结果。

出现了三种架构设计方法：

Hyperion Essbase 和 IBM Cognos 等MOLAP（多维 OLAP）系统将数据存储在优化的多维数组中，实现了惊人的查询速度，但需要大量的预处理，并且难以处理非常大的数据集。

像 MicroStrategy 这样的ROLAP（关系型 OLAP）系统在现有的关系数据库之上构建了 OLAP 功能，提供了更大的灵活性和可扩展性，但查询性能较慢。

像 Microsoft Analysis Services 这样的HOLAP（混合 OLAP）试图兼顾两者的优点，将详细数据存储在关系表中，同时将聚合摘要保存在多维立方体中。

商业驱动因素很明确：

高管和分析师需要仪表盘和报表来做出数据驱动的决策。Business Objects、Cognos 和Crystal Reports 等工具成为了前端界面，而 OLAP 引擎则负责后端计算。

关键要点：OLAP 多维数据集通过跨维度的预聚合解决了分析性能问题，但需要大量的 ETL 处理，并且难以扩展到现代数据量。

数据仓库热潮（20世纪90年代末至21世纪初）

随着OLAP的价值日益凸显，各组织意识到他们需要一个专门针对分析而优化的集中式存储库。数据仓库应运而生——它是一个面向主题、集成化、时变且非易失性的数据集合，旨在支持商业智能。

规范架构由此诞生：提取、转换、加载 (ETL)管道将从多个源系统（CRM、ERP、事务数据库）中提取数据，根据业务规则对其进行清理和转换，并按照精心设计的模式将其加载到数据仓库中。

两种模式占据主导地位：

星型模式以中心事实表（例如销售表）为中心组织数据，周围环绕着维度表（例如客户表、产品表、时间表、地点表）。这种非规范化结构以牺牲存储空间为代价优化了读取性能。

Snowflake模式进一步规范化了维度表，以减少冗余，创建了一个更复杂的结构，用图表表示时类似于雪花。

Teradata、Netezza 和 Vertica的企业级数据仓库引入了关键创新。它们采用列式存储而非行式存储——这彻底改变了数据分析的格局。在计算十亿条销售记录的平均价格时，列式存储允许您仅从磁盘读取价格列，而忽略其他所有数据。这显著提高了数据压缩率（相似的值可以很好地压缩在一起），并加快了查询速度。

他们还实现了大规模并行处理（MPP）架构，将数据和查询分布在多个协同工作的节点上。现在，您可以通过向集群添加更多机器来实现水平扩展。

但这种方法也有局限性。模式必须预先定义（写入时模式），这使得添加新的数据源或更改业务逻辑的成本很高。硬件扩展性仍然有限，而且这些系统的成本高达数十万甚至数百万美元。

关键要点：数据仓库通过列式存储和 MPP 处理集中分析，但仍然成本高昂、缺乏灵活性，并且受到硬件限制。

大数据与Hadoop时代（2000年代末至2010年代）

然后，互联网改变了一切。像谷歌、雅虎和脸书这样的公司被海量的新型数据淹没：网络日志、点击流、传感器数据、社交媒体帖子、图片、视频。这些数据不再是那种可以整齐地放入数据库表格的结构化交易数据，而是杂乱无章、半结构化的，而且数量空前庞大。

传统数据仓库无法处理这种情况。它们的设计初衷是存储具有已知模式的结构化数据，而不是用于存储原始日志文件或 JSON 文档。经济上也不可行——你根本负担不起购买足够多的 Teradata 许可证来存储 PB 级的网络爬虫数据。

谷歌曾发表论文描述其内部系统：用于分布式存储的GFS（谷歌文件系统）和用于分布式计算的MapReduce。这些系统启发了开源Hadoop生态系统的诞生，而Hadoop生态系统又成为了“大数据”运动的基础。

Hadoop引入了两个革命性的理念：

HDFS（Hadoop分布式文件系统）将数据分散存储在通用硬件上，并自动复制数据以实现容错。您可以使用数百台廉价的机器而不是昂贵的专用硬件，以低成本存储PB级数据。

MapReduce允许你编写并行计算，这些计算会自动在所有机器上运行。该框架处理了分配 任务、管理故障和聚合结果的所有复杂性。

Apache Hive等项目在 MapReduce 的基础上增加了类似 SQL 的查询功能，使分析人员能够使用熟悉的语法查询数据湖。Impala和 Presto（现为 Trino）提供了速度更快、交互性更强的 SQL 引擎。Spark凭借其内存计算模型，成为 MapReduce 更灵活、性能更高的替代方案。

这个时代引入了数据湖的概念——一个集中式存储库，以原始形式存储所有数据，采用读取时模式（schema-on-read）而非写入时模式（schema-on-write）。您可以先摄取数据，然后再考虑如何使用它。

但Hadoop在OLAP工作负载方面存在严重的局限性。查询通常需要几分钟甚至几小时。它不支持事务或更新——只能追加数据。运维复杂度极高，需要庞大的团队才能维持集群运行。

关键要点：Hadoop 利用通用硬件实现了大数据存储和处理的普及化，但其高延迟和操作复杂性使其不适合交互式分析。

云仓库和计算/存储分离（2010年代）

正当Hadoop的热度达到顶峰之际，新一代云原生数据仓库应运而生，其架构截然不同。Snowflake（2014年发布）、Google BigQuery和Amazon Redshift重新定义了云时代数据仓库的形态。

这项突破在于计算和存储的完全分离。传统的数据仓库将二者紧密耦合——数据存储在处理查询的同一台机器上。这就带来了一个两难困境：是购买足够的容量来应对高峰查询负载（大部分时间都在浪费资源），还是购买足够的容量来应对平均负载（在繁忙时段性能下降）？

云数据仓库通过将所有数据存储在廉价且持久的对象存储（例如 S3、Google Cloud Storage 和 Azure Data Lake Storage）中，并按需启动计算集群，解决了这个问题。需要运行大型报表？只需扩展到 100 个节点，几分钟内即可运行查询，然后缩减规模。您只需在查询运行时支付计算费用，而静态存储成本则非常低廉。

Snowflake率先提出了具有真正弹性的“多集群共享数据”架构。BigQuery更进一步，采用了无服务器模型，用户甚至无需配置集群——只需编写SQL语句，Google就会自动分配资源。

这些系统还带来了其他优势：

云经济学：按需付费的定价模式意味着初创公司无需巨额前期投资即可获得企业级分析服务。

即时弹性：根据工作负载在几秒钟内扩展或缩减计算规模。

零管理：无需管理任何硬件，自动备份、更新和优化。

数据共享：轻松安全地在组织间共享数据集。

得益于列式格式、高级压缩和智能查询优化方面的创新，性能也十分出色。云数据仓库可以在几秒钟内扫描TB级数据。

你可知道？

Snowflake 由几位来自 Oracle 的数据仓库资深人士创立，他们提出了这样一个问题：“如果我们设计一个不受任何传统系统限制，完全面向云时代的数据仓库，会怎么样？” 结果是，Snowflake 成为 2020 年首家估值超过 700 亿美元的数据公司 IPO。

关键要点：云数据仓库通过解耦存储和计算，彻底改变了分析方式，实现了即时弹性，消除了运营开销，并使各种规模的组织都能获得企业级分析。

开放表格式和云查询引擎（2010年代末至2020年代）

云数据仓库功能强大，但也带来了一个新问题：数据锁定。一旦数据进入 Snowflake 或 BigQuery，就只 能使用专有格式。想用其他工具？就得复制或导出数据，成本和复杂性都会翻倍。

与此同时，数据湖以开放格式存储数据，但缺乏使数据仓库发挥作用的关键功能：ACID 事务（原子性、一致性、隔离性、持久性）、模式演化、时间旅行以及高效的更新和删除。

解决方案源于开放表格式，它将类似数据库的功能引入了数据湖：

Apache Iceberg（由 Netflix 创建）为对象存储中的数据提供完整的 ACID 事务、模式演化、隐藏分区和时间旅行功能。它将元数据与数据分开维护，从而实现高效的查询规划和分区修剪。

Delta Lake（由 Databricks 开源）提供类似的功能，并与 Spark 生态系统紧密集成。它使用事务日志来维护 ACID 特性，并支持流式写入和批量读取。

Apache Hudi（由 Uber 创建）专门用于增量数据处理和高效的 upsert 操作，使其成为变更数据捕获场景的理想选择。

这些格式都是开源且可互操作的，以 Parquet 等标准列式格式存储数据，同时保留有关事务、模式和分区的丰富元数据。

与表格格式一同出现的，还有新一代的查询引擎：

Trino（由 Presto 演变而来）可在各种数据源上提供极速 SQL——只需一次查询即可查询 S3、PostgreSQL 和 MongoDB 中的数据。

Dremio引入了数据反射（自动维护的聚合）和语义层来加速查询。

DuckDB为嵌入式场景带来卓越的分析性能，完全在进程内运行，无需任何配置。

AWS Athena和Starburst在这些开放格式之上提供托管查询服务。

最后一部分是开放元数据目录：

AWS Glue、Apache Polaris、Unity Catalog和Gravitino为整个生态系统提供集中式元数据管理、访问控制和数据治理。现在，无论哪个引擎查询数据，您都可以拥有关于数据的单一真实来源。

这种融合催生了Lakehouse 架构——它将数据湖的灵活性和开放性与数据仓库的性能和功能相结合。您无需担心厂商锁定，即可获得 OLAP 性能，并可在同一数据集上同时支持 BI 工作负载和机器学习。

关键要点：Iceberg、Delta Lake 和 Hudi 等开放表格式为数据湖带来了仓库功能，而现代查询引擎和目录则创建了 Lakehouse——一个开放、灵活的架构，具有企业级的分析性能。

新领域：人工智能驱动的分析（2020年代至今）

我们现在正进入下一个阶段：人工智能原生分析平台将从根本上改变我们与数据交互的方式。数据仓库、机器学习和商业智能之间的界限正在消失。

几个趋势正在汇合：

语义层和人工智能驱动的指标抽象化了 SQL 的复杂性。分析师无需编写复杂的连接和聚合语句，只需定义一次业务指标（例如“月度经常性收入 = 活跃订阅用户总数 * 订阅价格”），人工智能即可理解概念之间的关系。

由大型语言模型驱动的自然语言界面允许业务用户用简单的英语提问：“上个季度哪些产品的销售额下降幅度最大？”系统会自动生成、执行并解释 SQL 语句。

向量搜索和嵌入技术能够结合传统的 SQL 分析，对非结构化数据进行语义相似性搜索。现在，您可以在分析工作流程中查找“与此客户投诉相似的文档”。

统一分析平台将商业智能、数据科学和机器学习操作整合在一起：

Databricks凭借其人工智能/商业智能功能，将湖仓式存储、协作笔记本、机器学习管道和交互式仪表板整合到一个平台中。他们收购MosaicML后，将大型语言模型训练直接集成到数据平台中。

Snowflake Cortex将 AI 功能（情感分析、翻译、文本生成）直接嵌入 SQL 中，使用户可以通过熟悉的界面访问 AI 功能。

Dremio 的 Reflections利用人工智能自动识别查询模式并创建优化的聚合，同时其语义层从分析师的行为中学习。

MotherDuck将 DuckDB 的高性能带到云端，并具备智能缓存和协作功能，使分析速度更快、更易于共享。

愿景是实现自助式分析，领域专家无需依赖数据团队编写 SQL 或构建模型即可探索数据。该系统能够理解业务上下文，提出相关的分析建议，并以自然语言解释分析结果。

我们还看到流式 OLAP的兴起，在这种模式下，分析查询可以基于最新数据以亚秒级的延迟运行。像 Apache Pinot、ClickHouse 和 Apache Druid 这样的系统既能处理实时数据摄取，又能处理复杂的分析查询，模糊了 OLTP 和 OLAP 之间的界限。

你可知道？

现代人工智能辅助 SQL 生成技术能够理解对话中先前查询的上下文，记住“收入”指的是特定的计算，“上个月”应该使用交易时间戳字段，而无需您每次都明确说明。

关键要点：人工智能驱动的分析平台将机器学习、自然语言界面和语义理解直接集成到数据系统中，使每个人都能进行复杂的分析，同时统一以前分离的数据、人工智能和商业智能工作流程。

进化时间线：五十年的创新

让我们把这段历程总结成一个清晰的时间线：

1970年代至1980年代：OLTP时代

关键技术：关系型数据库（Oracle、DB2、Sybase）

架构：单体式、行式存储、单机

用例：交易处理

局限性：分析性能较差，仅支持垂直扩展

20世纪90年代：OLAP革命

关键技术：数据立方体（Essbase、Analysis Services）

架构：预聚合多维数组

应用案例：快速商业智能和报告

局限性：缺乏灵活性，需要大量的预处理，规模有限

20世纪90年代末至21世纪初：数据仓库时代

关键技术：企业DWH（Teradata、Netezza、Vertica）

架构：ETL 流水线、列式存储、MPP 集群

用例：集中式分析存储库

局限性：成本高昂、方案僵化、扩展性受限于硬件

2000年代末至2010年代：大数据时代

关键技术：Hadoop生态系统（HDFS、MapReduce、Hive、Spark）

架构：基于通用硬件的分布式存储和计算

应用场景：大规模数据湖、批量处理

局限性：延迟高、操作复杂、无交易

2010年代：云仓库时代

关键技术：云原生数据仓库（Snowflake、BigQuery、Redshift）

架构：计算与存储分离，弹性且无服务器

应用案例：可扩展、经济高效的分析即服务

局限性：专有格式，可能导致供应商锁定

2010年代末至2020年代：湖畔小屋时代

关键技术：开放表格式（Iceberg、Delta、Hudi）+ 现代查询引擎

架构：基于开放数据湖的 ACID 事务，通用目录

用例：开放、灵活的分析，提升仓库性能

局限性：仍然需要SQL专业知识，与机器学习工作流程无关

2020年代至今：人工智能原生分析

关键技术：具有语义层和LLM接口的AI驱动平台

架构：统一的数据、机器学习和商业智能，并嵌入智能

应用场景：自助式分析、自然语言查询、实时机器学习

展望未来：能够理解意图并自我优化的完全自主数据系统

展望未来

展望2025年，发展趋势清晰可见：数据系统正从需要专业知识的工具演变为能够理解意图并适应需求的平台。下一代OLAP系统不仅能更快地执行查询，还能理解您应该提出的问题。

多条新领域正在开启：

自主优化是指系统不断从查询模式中学习，自动创建索引、物化视图和缓存策略，而无需人工干预。

实时智能中，运营数据库和分析数据库之间的区别完全消失——每笔交易都会立即更新分析模型和仪表板。

联邦学习和隐私保护分析，无需共享原始数据即可在组织间提供洞察，这得益于加密技术和差分隐私。

自然语言作为主要界面，SQL 成为实现细节，数据系统与用户进行对话，以了解他们的分析需求。

贯穿五十年创新的主线始终如一：让数据转化为理解变得更加便捷、快速和经济高效。从穿孔卡片和大型机到基于开放式湖畔数据中心的自然语言查询，我们已经从“我们拥有哪些数据？”转变为“我们下一步应该做什么？”

未来十年，能够取得成功的公司和系统将是那些拥抱开放（避免被锁定）、优先考虑智能（在每一层嵌入人工智能）并始终专注于最终目标——使组织中的每个人都能够做出基于数据的决策，而无需成为数据工程师——的公司和系统。

从OLTP到AI驱动的OLAP的转变，不仅仅是一个技术故事。它讲述了我们如何学会从呈指数级增长的人类活动和自然现象记录中捕捉、组织和提取意义。而这个故事远未结束。

本文来自微信公众号“数据驱动智能”（ID：Data_0101），作者：晓晓，36氪经授权发布。