OLTP与OLAP

业务与决策的转换

Posted by QQL on March 21, 2019

OLTP与OLAP

OLTP(在线事务处理)涉及到特定系统的操作。
OLTP的特点是大量的短在线事务(插入、更新、删除)。OLTP系统的主要重点是非常快的查询处理,在多访问环境中保持数据完整性,以及以每秒事务数来衡量效率。在OLTP数据库中有详细的和当前的数据,用于存储事务性数据库的模式是实体模型(通常是3NF)。它涉及访问个人记录的查询,如在公司数据库中更新电子邮件。 数据库:传统的关系型数据库的主要应用,主要是基本的、日常的事务处理,例如银行交易。

OLAP(在线分析处理)处理历史数据或档案数据。
OLAP的特点是交易量相对较低。查询通常非常复杂,涉及聚合。对于OLAP系统来说,响应时间是一种有效的度量。OLAP应用被数据挖掘技术广泛应用。在OLAP数据库中,有聚合的历史数据,存储在多维模式(通常是星型模式)中。有时查询需要访问管理记录中的大量数据,比如去年公司的利润。
数据仓库:数据仓库系统的主要应用主要是OLAP(On-Line Analytical Processing),支持复杂的分析操作,侧重决策支持,并且提供直观易懂的查询结果。

举例分析OLTP和OLAP

基本每家电商公司都会经历,从只需要业务数据库到要数据仓库的阶段。

  • 电商早期启动非常容易,入行门槛低。找个外包团队,做了一个可以下单的网页前端 + 几台服务器 + 一个MySQL,就能开门迎客了。这好比手工作坊时期。
  • 第二阶段,流量来了,客户和订单都多起来了,普通查询已经有压力了,这个时候就需要升级架构变成多台服务器和多个业务数据库(量大+分库分表),这个阶段的业务数字和指标还可以勉强从业务数据库里查询。初步进入工业化。
  • 第三个阶段,一般需要 3-5 年左右的时间,随着业务指数级的增长,数据量的会陡增,公司角色也开始多了起来,开始有了 CEO、CMO、CIO,大家需要面临的问题越来越复杂,越来越深入。高管们关心的问题,从最初非常粗放的:“昨天的收入是多少”、“上个月的 PV、UV 是多少”,逐渐演化到非常精细化和具体的用户的集群分析,特定用户在某种使用场景中,例如“20~30岁女性用户在过去五年的第一季度化妆品类商品的购买行为与公司进行的促销活动方案之间的关系”。

这类非常具体,且能够对公司决策起到关键性作用的问题,基本很难从业务数据库从调取出来。原因在于:

  1. 业务数据库中的数据结构是为了完成交易而设计的,不是为了而查询和分析的便利设计的。
  2. 业务数据库大多是读写优化的,即又要读(查看商品信息),也要写(产生订单,完成支付)。因此对于大量数据的读(查询指标,一般是复杂的只读类型查询)是支持不足的。

而怎么解决这个问题,此时我们就需要建立一个数据仓库了,公司也算开始进入信息化阶段了。数据仓库的作用在于:

  1. 数据结构为了分析和查询的便利;
  2. 只读优化的数据库,即不需要它写入速度多么快,只要做大量数据的复杂查询的速度足够快就行了。

那么在这里前一种业务数据库(读写都优化)的是业务性数据库,后一种是分析性数据库,即数据仓库。

区别

1、oltp面对业务,一个是对业务分析
2、oltp是3NF设计,olap是星形模型设计.最近一个新同事问我统计的时候为什么不能直接走ods,要做一些数据仓库的模型,我觉得很重要的一点就是生产库业务复杂,3nf的设计,一般人光理解这个业务都需要花很多时间,更别说使用了。因此需要能抽象出一个简单易懂的模型
3、oltp,涉及到增删改查,都是小数据量的操作,olap查询为主,分析的基数很大
4、使用者也不同,一个是面对业务人员,一个是决策人员
5、oltp强调并发性,olap查询6、oltp针对当天的数据进行操作,olap针对当前和历史数据做处理

总结

数据库比较流行的有:MySQL, Oracle, SqlServer等
数据仓库比较流行的有:AWS Redshift, Greenplum, Hive等

参考
https://www.zhihu.com/question/20623931