OLTP数据库OLAP数据仓库

OLTP数据库就是我们常说的事务性数据库，像MySQL，Oracle等事务性数据库就属于OLTP数据库，主要的场景是需要实时处理数据，对数据的增删改查多，并且对延迟性要求高。

OLAP数据库：数据分析统计数据库，我们说的离线数仓就是属于OLAP数据库，OLAP数据库处理的数据量大，主要是面向决策分析，高吞吐量，有延迟。

一，数据范围的区别

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数据仓库关注查询响应（吞吐量）