OLTP与OLAP:在新IT环境下的相互结合

为了完全理解OLTP(联机事务处理)和OLAP(联机分析处理),有必要结合一些行业背景来谈。在软件技术发展的早期,数据通常存储在一个文件中。随后,IT需要解决的问题越来越大,关系数据库管理系统(DBMS)开始席卷市场。在接下来的几十年里,它几乎成为了每个企业的数据存储解决方案。

随着网络的出现,一切都发生了巨大的变化。搜索引擎和社交网络如今会在某些网域中对数据进行建模,这些数据之间的关系不容易识别,有时甚至根本不需要(例如搜索引擎索引文档)。

不过,一些传统的术语今天仍然在使用,用现代的方法来看待它们是很重要的。其中两个就是OLTP和OLAP,下面的图片显示了OLTP和OLAP之间的关系。

OLTP是一个在线交易系统;OLAP是一个在线检索和分析系统

上图强调的是,OLTP和OLAP并非解决同一问题,不存在竞争关系,而是相互补充的过程。下面是更深入的解释。

关于OLTP

OLTP,即联机事务处理,它通常会涉及到那些存储和管理与系统/公司日常运营有关数据的数据库。在过去,OLTP通常与正在运行的关系数据库相关联,其主要关注点是从给定环境正在发生的事情中收集数据。

简而言之:OLTP用于存储和管理日常运营的数据。

由于存储在OLTP数据仓库上的信息通常对业务来说至关重要,所以往往需要付出巨大的努力来确保数据的原子性、一致性、隔离性和持久性(即ACID)。根据这四个原则存储的数据会被标记为与ACID兼容,这就是关系数据库管理系统的优势所在。

但是拥有一个与ACID兼容的数据仓库并不意味着我们不需要做任何额外的工作来保证数据符合这些原则。我们处理数据的方式很重要,例如,如果在数据存储中允许冗余,我们如何保证数据的一致性?

如果我们要存储客户的地址,重要的是要确保当客户移动到另一个地方时,这个地址在任何地方都是更新的。但是,将地址存储在多个位置会使数据很难保持一致的状态。这就是为什么关系数据库常常被设计成与第五种范式(5NF)相匹配——一种避免冗余的关系数据设计方法。

正如前面所说,自从定义OLTP术语以来,世界已经发生了变化,现在很容易在非关系数据库中存储数据。这些数据存储大部分只符合ACID的四个原则中的一部分。但是,根据用例的不同,可以适当放宽这些原则中的一两个,以换取其他收益(速度、可伸缩性等)。

例如,如果我们在存储社交网络的帖子中“赞”的数量时,保证“赞”数量100%准确真的很重要吗?或者说,可不可以显示995个赞而不是准确的998个,以换取对数百万用户的更快响应?

由于OLTP指的是联机事务处理,所以我们看到它并不局限于关系数据库,甚至不完全附从ACID数据库。它只是指使用这些数据存储的方式,例如,如果我们使用文档数据存储(例如MongoDB)来存储和处理来自社交应用程序日常运营的数据(例如注册用户、存储点赞等),我们也可以说它是OLTP。

关于OLAP

OLAP,即联机分析处理,通常涉及到那些存储和管理与分析和决策相关的数据的数据库。

OLAP与商业智能(BI)紧密相关,BI是一种专门的软件开发模式,用于交付业务分析应用程序。换句话说,BI的目标是允许高层管理人员在没有IT人员参与的情况下查询和研究数据。

简而言之:OLAP用于分析数据并做出决策。

这个领域带来的最大进步是实时生成报告的能力,它不需要另外再请IT部门来定制报告,而是自动生成特定的报告。BI系统可以回答开发人员不需要提前知道的问题。

BI系统可以通过以一种名叫Hypercube(超立方体)的形式组织数据来实现,此形式会探索数据的多个维度,并允许用户通过操纵立方体的大小维度来聚合或下钻数据。

有趣的是,有了正确的接口,高层管理人员就可以在没有帮助的情况下动态生成报告。

OLAP系统可以使用关系数据库实现,这种技术通常称为ROLAP(关系OLAP)。但为此,我们需要用第三范式而不是第五范式来设计数据库。

在分析数据时,我们可以处理冗余数据,真正重要的是浏览数据维度的能力。这就是ROLAP的亮点,因为第三范式的数据库模式适合于聚合和下钻。

将它们相结合

当第一次遇到OLTP和OLAP这两个术语时,很容易产生疑问:哪个更好?实际上,我们应该问的是:他们如何互相补充?

我们现在知道:

OLTP用于存储和管理日常操作的数据;

OLAP用于分析这些数据。

这正是它们在现有业务中使用的方式。

OLTP和OLAP协同工作

上述示例中上部的数据(HR数据库、CRM、计费系统)一般是通过一个萃取、转置和加载(Extract, Transform and Load, ETL)的过程进行批量处理(通常是在夜间)。它用于从多个OLTP源收集数据并将其放入OLAP数据仓库(允许跨系统分析)。在图的下半部分,您可以看到数据在OLAP立方体中得到了正确的存储和组织。

这样,进行分析的人员就可以处理最新的信息,并及时做出决定,而不会中断操作。

原文作者:Tiago Franco 来源:ImaginaryCloud

<think>嗯,用户现在想要了解数据仓库的体系结构图。之前他们问过数据仓库的意义,所以我需要确保这次的回答之前的有所衔接,同时深入结构方面的内容。 首先,用户可能对数据仓库的基本概念已经有了一定了解,现在想具体知道它是如何构建的。体系结构图通常会包括数据来源、ETL过程、存储、服务层等部分。我需要把这些部分详细分解,确保每个组件的功能相互关系都解释清楚。 接下来,考虑用户可能的身份。他们可能是学生、IT从业者或者业务决策者。如果是学生,他们可能需要详细的术语解释结构图;如果是IT人员,可能更关注技术细节;如果是业务人员,可能更关心各部分的业务价值。根据之前的回答,用户提到了实例应用,比如银行、物流,所以可能需要结合实际例子来说明结构组件的作用。 用户的需求可能不仅仅是结构图本身,而是理解每个部分如何协作,以及为什么这样的设计有意义。因此,在解释体系结构时,需要强调各层之间的数据流动处理逻辑,例如ETL如何清洗数据,存储层如何管理不同数据粒度,服务层如何支持查询分析。 另外,用户可能希望有一个直观的图示,但作为文本回复,我需要用文字描述结构图,并分点说明每个层次。可能需要使用层次化的列表,并标注每个部分的关键技术或工具,比如ODS、数据仓库、数据集市等。 还要注意用户之前提到的系统级指令,比如数学公式的格式。虽然体系结构图可能不涉及太多公式,但如果有技术术语或模型名称,可能需要用LaTeX格式,比如$ODS_{操作数据存储}$,但根据之前的例子,用户可能更倾向于使用中文术语加括号说明英文缩写。 需要检查是否有遗漏的部分,比如元数据管理、数据质量、安全控制等,这些通常也是体系结构的重要组成部分。同时,用户可能想知道现代数据仓库的演进,比如大数据平台的融合,或者实时处理的能力,所以可以补充扩展说明,让回答更全面。 最后,确保结构清晰,分点明确,用例子帮助理解,比如ETL的例子,数据集市的例子,这样用户能更好地将理论实际应用结合起来。同时,保持语言简洁,避免过于技术化的术语,或者在必要时进行解释,以满足不同背景用户的需求。</think>以下是数据仓库的经典体系结构图及其核心组件解析,采用**分层架构**实现从数据源到决策支持的完整链路: --- ### **数据仓库体系结构图** (文字版分层描述,可按此逻辑绘制图示) ``` [数据源层] │ ▼ [ETL/ELT层] │ ▼ [存储层] ├── 操作数据存储(ODS) ├── 数据仓库(DW) └── 数据集市(DM) │ ▼ [服务层] ├── 元数据管理 ├── 查询引擎 └── OLAP/BI工具 │ ▼ [应用层] ``` --- ### **逐层解析关键技术** #### **1. 数据源层(Data Sources)** - **异构数据源**: - 业务系统:ERP、CRM中的$交易表_{OLTP}$ - 日志类:用户行为日志$clickstream_{JSON}$ - 外部数据:天气API、社交媒体$情感分析_{NLP}$结果 - **特点**:数据格式差异大(结构化/半结构化)、更频率高 --- #### **2. ETL/ELT层(数据加工管道)** - **核心任务**: - 抽取(Extract):增量拉取$MySQL_{binlog}$或全量同步$S3_{Parquet文件}$ - 转换(Transform):执行$数据清洗_{正则表达式}$、$维度退化_{星型模型}$ - 加载(Load):写入Hive数仓分区$dt=20240501$ - **现代演进**: - 流批一体:Flink实时处理$Kafka_{事件流}$ - 代码化配置:Airflow编排$DAG_{任务依赖}$ --- #### **3. 存储层(分层存储设计)** | 层级 | 数据粒度 | 典型技术 | 应用场景示例 | |---------------|-----------------|--------------------------|-----------------------------| | **ODS** | 原始数据 | HDFS/对象存储 | 原始日志存档 | | **DW** | 明细数据 | Hive/Spark表 | 用户全生命周期分析 | | **DM** | 聚合数据 | ClickHouse/Doris | 部门级销售日报 | - **建模方法论**: - 范式建模:$3NF_{OLTP适配}$ - 维度建模:$星型模型_{快速查询}$、$雪花模型_{节省存储}$ - 数据湖仓:Delta Lake实现ACID事务 --- #### **4. 服务层(数据交付中枢)** - **元数据管理**: - 血缘追踪:定位$报表A_{错误根源}$到源头$Hive表t_order$ - 数据字典:定义$客单价_{计算逻辑} = \frac{GMV}{订单数}$ - **查询引擎**: - 交互式查询:Presto执行$Ad-hoc_{即席查询}$ - 大规模计算:Spark SQL处理$PB级Join_{shuffle优化}$ - **OLAP引擎**: - MOLAP:Kylin预计算$Cube_{多维聚合}$ - ROLAP:Doris支持实时$漏斗分析_{UV去重}$ --- #### **5. 应用层(价值输出终端)** - **BI可视化**:Tableau生成$销售热力图_{GIS映射}$ - **数据服务API**:通过RESTful接口返回$用户画像_{标签体系}$ - **AI模型对接**:将$特征工程_{标准化处理}$后的数据输入TensorFlow --- ### **扩展:现代架构演进** 1. **湖仓一体**:Delta Lake/Iceberg替代传统EDW 2. **实时化**:Flink CDC实现MySQL→Hudi分钟级同步 3. **云原生**:Snowflake弹性扩展$计算资源_{按需付费}$ --- **架构设计原则**: - 稳定性:通过$数据分区_{dt}$$重试机制_{指数退避}$保障链路可靠 - 可扩展性:采用$微服务_{容器化}$部署ETL组件 - 安全性:列级加密$信用卡号_{AES-256}$+动态脱敏 如需具体技术栈选型建议或场景化架构案例,可进一步说明需求方向。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值