OLTP数据库就是我们常说的事务性数据库像MySQLOracle等事务性数据库就属于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数据库关注事务一致性ACIDOLAP数据仓库关注查询响应吞吐量