OLTP数据库就是我们常说的事务性数据库,像MySQL,Oracle等事务性数据库就属于OLTP数据库,主要的场景是需要实时处理数据,对数据的增删改查多,并且对延迟性要求高。
OLAP数据库:数据分析统计数据库,我们说的离线数仓就是属于OLAP数据库,OLAP数据库处理的数据量大,主要是面向决策分析,高吞吐量,有延迟。
| 功能 | 数据库(OLTP) | 数据仓库(OLAP) |
| 数据范围 | 当前状态数据 | 存储完整,反应历史变化的数据 |
| 数据变化 | 支持频繁的增删改查 | 可增加,查询,无更新,删除操作 |
| 应用场景 | 面向业务交易流程 | 面向分析,侧重决策分析 |
| 处理数据量 | 小批次,频繁,高并发,低延迟 | 大批量,非频繁,高吞吐,有延迟 |
| 设计理论 | 三范式,避免数据冗余 | 反范式,适当数据冗余 |
| 建模方式 | ER实体关系建模 | 范式建模+维度建模 |
一,数据范围的区别
OLTP数据库主要存储业务结果状态(如订单状态,用户余额)。像用户页面浏览,用户浏览了哪个页面,在哪个页面上停留多久...... 这些无业务强相关的数据OLTP数据库不会存储,OLTP数据库存储的一个状态,比如说用户浏览,它可能只记录了用户在线,用户退出,记录用户下线。
OLTP的存储的数据范围不利于我们做数据分析。站在数据分析的角度而言,用户的浏览路径,用户的页面浏览时长等等,这些数据为我们决策分析提供数据支持,所以我们的OLAP数据仓库存储完整的,能够反映历史变化的数据。
二,数据变化形式
OLTP数据库是业务数据库系统,用户会频繁的跟OLTP数据库交互,用户会进行正常的业务行为,业务行为就包含了数据的增删改查,所以数据库需要频繁的处理数据的增删改查。
OLAP数据仓库主要是追加和批量写入,不允许对历史明细数据进行物理删除或者直接更新,对于历史数据,通常采用缓慢变化维度(SCD)策略,如新增一个字段或者新增一个数据行来处理变化,不直接进行物理删除或直接覆盖。
三,应用场景
OLTP数据库,这个其实上面已经有提过,OLTP是一个业务数据库,它主要的场景就是面向业务过程中业务行为。假设是电商项目,那么用户的下单,加购,支付等业务行为就是一个交易流程,这些记录我们需要记录。
OLAP数据仓库,主要用于数据分析,决策分析。OLAP数据仓库为了支持数据的分析,上述存储完整,历史变化的数据就是为了给数据仓库做数据分析,为公司的决策层,业务层等提供数据支持。
四,处理的数据量
OLTP数据库中需要处理用户的业务数据,像下单的话,需要记录用户,商品,金额,时间等字段,这些数据存储在OLTP数据库中。所以OLTP的数据库处理的数据量小,但是频繁,并且是高并发式的,对于我们的延迟也有要求。
OLAP数据仓库中处理的数据, 各个OLTP数据库的数据 + 用户行为日志 的数据,所以对于OLAP数据仓库,数据是大批量的,非频繁的,高吞吐,并且允许一定的延迟。传统离线数仓(Hive/Spark批处理)延迟通常在小时级或天级;而实时数仓则另当别论。
五,设计理论和建模方式
OLTP数据库,这是事务型数据库,遵循高范式(通常是3NF)数据建模理论,使用ER实体关系模型来进行实现。我们还是以下单为例:
一个下单行为的数据分布在不同的表中,这种结构有效避免了数据的冗余,对于单表的数据维护和一致性有显著提升,得益于索引,OLTP的普通业务查询效率很高。
OLAP数据仓库,数据的高范式虽然可以减低数据的冗余度,但是对于多表关联的效率降低了,并且同一个业务过程中的存在多个中心点,下单可以关联商品表,用户表,但是商品表和用户表也可以再关联。所以,对于OLAP数据仓库场景,通常使用的是维度建模(星型/雪花/星座模型),只存在事实表和维度表。用空间换取时间,提高多表关联查询效率。
星型模型:一个事实表对应多个维度表,在OLAP数据仓库中,虽然数据存在冗余,但是大大提高的数据的关联效率。维度表存储客观的数据,基本稳定不变的数据,作为数据分析的角度。事实表存储业务过程中的客观事件。
星座模型:多个星型模型组合而成,多个事实表对应一张维度表。多个事实表共享一张维度表(一致性维度),这样可以实现跨主题(如销售+库存)的联合分析。
雪花模型:一个事实表关联一个维度表,维度表在关联维度表(跟高范式建模理论比较类似)。在大数据场景中,为了极致的查询性能,星型模型使用更普遍;雪花模型在传统的BI或对存储空间极度敏感的场景下仍有应用。
但是也不是绝对的,这还是需要根据数据仓库分层设置中每一层的作用来使用。像ODS层(贴源层),作为数据仓库的数据源,需要保持跟采集过来的数据一致,所以ODS层采用的也是ER模型。
OLTP数据库关注事务一致性(ACID),OLAP数据仓库关注查询响应(吞吐量)