OLTP 和 OLAP：企业数据处理系统

Source: Dev.to

请提供您希望翻译的正文内容（除代码块和 URL 之外），我将为您翻译成简体中文并保留原有的 Markdown 格式。

企业环境中的数据处理

企业环境中的数据处理基于两个主要范式：OLTP（Online Transaction Processing）和OLAP（Online Analytical Processing）。这些系统虽然都处理数据，但在架构和功能目标上设计不同。理解它们的差异、应用以及它们如何集成到数据基础设施中，对于企业信息系统的设计至关重要。

OLTP: 在线事务处理

定义

OLTP 是一种为管理面向应用的事务而设计的数据处理方式。其主要功能是支持组织的日常业务操作，实时处理事务，具备高可用性和一致性。

技术特性

• 容量： 大量短小事务。
• 典型操作： INSERT、UPDATE 和 DELETE，针对少量记录。
• 规范化： 使用规范化的数据库（通常为 3NF），以最小化冗余并保持参照完整性。
• 性能： 响应时间以毫秒计；针对快速读写进行优化。
• ACID： 保证原子性、一致性、隔离性和持久性。
• 并发性： 支持数百甚至数千个并发用户。
• 结构： 规范化的关系表；复杂查询可能需要多个 JOIN。

使用场景

• 银行系统： 处理金融交易、转账、ATM 取款以及余额更新。
• 电子商务： 管理商品目录、订单处理、库存更新和购物车管理。
• 预订系统： 实时提供酒店、航空公司和活动的可用性与预订。
• ERP（企业资源计划）： 会计、人力资源、供应链和制造管理。

OLTP 技术示例

PostgreSQL、MySQL、Oracle Database、Microsoft SQL Server、MongoDB（用于事务型 NoSQL 场景）。

Source: …

OLAP：在线分析处理

定义

OLAP 是一种为大规模数据上的复杂分析查询而设计的处理方法。其目的是帮助对企业信息进行多维分析，以支持战略决策。

技术特性

• 优化方式： 以读取为主的操作，写入很少（通常在批处理过程中）。
• 查询类型： 对数百万记录进行聚合、分组和分析。
• 维度建模： 采用非规范化的模式（星形 star schema 或雪花形 snowflake schema），降低对复杂 JOIN 的需求。
• 数据组织： 维度（时间、地域、产品、客户）和度量或指标（销售额、收入、数量）。
• 加速技术： 预聚合和视图物化。
• 响应时间： 根据复杂度和数据量，从秒级到分钟级不等。

使用场景

• 商业智能（BI）： 业务报告、仪表盘以及关键绩效指标（KPI）分析。
• 财务分析： 场景建模、预测、盈利能力分析和预算规划。
• 销售分析： 趋势、热销产品、客户细分以及营销活动效果分析。
• 数据挖掘： 模式发现、客户聚类、购物篮分析和异常检测。

常见 OLAP 技术

Amazon Redshift、Google BigQuery、Snowflake、Microsoft Azure Synapse Analytics、Apache Druid。

技术比较

Source: …

集成：OLTP → OLAP 管道

企业数据架构

在现代数据架构中，OLTP 与 OLAP 作为互补组件共同构成一个集成的生态系统。典型的流程如下：

1. 运营层（OLTP）

   • 事务系统实时捕获企业运营数据。
   • 数据库针对写入和快速读取单条记录进行优化。

2. 集成层（ETL / ELT）

   • 通过 ETL（Extract, Transform, Load）或 ELT（Extract, Load, Transform）过程，从多个 OLTP 源抽取数据。
   • 在此过程中对数据进行清洗、转换和合并。

3. 分析存储层（Data Warehouse）

   • 转换后的数据加载到 OLAP Data Warehouse 中，组织为面向分析的维度结构。

4. 消费层（BI / 分析）

   • 商业智能、报表和数据科学工具从 Data Warehouse 中获取数据，以生成洞察并支持决策。

摘要

• OLTP 注重运营事务的速度和一致性。
• OLAP 注重对大规模历史数据的分析查询速度。
• 通过 ETL/ELT 管道的集成，使事务数据能够供给分析仓库，构建完整且一致的数据生态系统。

介绍

商业智能和数据可视化工具 查询数据仓库以生成报告、仪表板和分析。

ETL 过程

ETL 过程是 OLTP 与 OLAP 之间的桥梁：

示例实现

OLTP 系统

一个 PostgreSQL 数据库存储每笔销售交易，使用规范化的表：

-- 主表
transactions   -- 每笔销售的明细
customers      -- 客户信息
products       -- 产品目录
stores         -- 各门店数据

每笔销售都会即时记录完整的细节。

ETL 过程

一个计划好的管道（例如使用 Apache Airflow）执行以下步骤：

1. 抽取 当天的交易数据（每日一次）。
2. 聚合 客户和产品信息。
3. 计算 如利润率等指标。
4. 转换 为维度模型。

OLAP 数据仓库

Snowflake 将数据存放在 星型模式 中：

• 维度表

  • dim_customer
  • dim_product
  • dim_time
  • dim_store

• 事实表

  • fact_sales（包含度量以及指向维度表的外键）

分析

分析师可以执行类似以下的查询：

“过去三年中，按产品类别、地区和季度划分的总销售额”

此查询在 OLTP 系统上会非常低效，但在 OLAP 数据仓库中执行速度很快。

设计考虑

• 工作负载分离
  将 OLTP 与 OLAP 分离，可避免繁重的分析查询影响关键事务操作的性能。

• 数据延迟
  根据业务需求确定数据仓库的刷新频率。

  • 实时 场景 → 流式 ETL。
  • 需求不紧急的场景 → 每日或每周更新。

• 数据治理
  在两层都实施数据质量、安全性和合规性政策。

• 可扩展性

  • OLTP：需要垂直和水平扩展以处理事务高峰。
  • OLAP：受益于分布式架构和大规模并行处理 (MPP)。