OLTP 和 OLAP 那两个概念在十来年前、十几年前BI那个词还不是那么普及的时候，还经常放在一路做比力，如今已经很少再零丁拿出来做比照了，但也总仍是有人会问到，我在那里可能讲下两个概念的区别和联络。
什么是OLTP
OLTP 英文全称是 Online Transaction Processing System，在线事务处置系统。OLAP 英文全称是 Online Analytical Processing System，在线阐发处置系统。从名词上看差别就是一个是事务处置，一个是阐发处置。那个名词从英文翻译过来仍是有些生硬，换种简单的体例来理解 OLTP 就能够理解为日常的营业系统，好比像 ERP、OA、CRM 等等，那些营业系统次要是治理企业的根本营业流程，对数据的处置体例次要是以增、删、改为主。也有查询，但查询的SQL的构造相比照较简单。
CRM可视化阐发 - 派可数据贸易智能BI可视化阐发平台
什么是OLAP
OLAP就能够理解为阐发型系统，好比在BI利用中，支持到前端可视化阐发的数据仓库。BI 底层利用到的数据库凡是我们会称为数据仓库，数据仓库的次要目标一个是打通各个营业系统即OLTP的数据库，整合之后提赐与前端BI可视化阐发东西或者报表东西来利用。假设只是把BI定义为数据可视化或者可视化的东西，就有些过于狭义了。现实上BI不单单只包罗数据可视化，更应该包罗数据仓库，数据仓库是整个BI的核心部门，所以谈到OLAP的时候就必然漫谈到BI。
贸易智能BI系统 - 派可数据贸易智能BI可视化阐发平台
展开全文
OLTP与OLAP的关系
第一，在底层数据处置层面，OLTP 以SQL增删改处置为主，OLAP以SQL查询操做为主。数据来源层面，OLTP 的数据来源就是它们前端的利用，就是B/S架构或者C/S架构的 B Browser 阅读器或者 C Client，就理解为用户在各类系统上录进数据就能够了。
第二，OLAP的数据来源就是差别的 OLTP数据库，所以OLAP自己是不产生数据的，通过ETL从OLTP抽取数据到OLAP数据库即数据仓库中做整合清洗到达可阐发的数据原则。
第三，OLTP数据处置的时间相对较短，增、删、改操做，就像在页面上点击一个提交案例、下一步操做等等；但是OLAP数据处置的时间可能就会很长，好比一个大查询可能查询的数据量十分长，相对增删改时间周期会拉的更长一些，取决于OLAP数据构造的标准性以及返回数据量的大小。
第四，OLTP 也有查询操做，但查询的操做都相比照较简单；OLAP 的查询相对能够很复杂；
雪花型建模 - 派可数据贸易智能BI可视化阐发平台
第五，OLTP系统在底层数据库的设想上凡是摘用3NF设想体例，制止数据冗余，很合适频繁的增删改操做；OLAP系统次要是面向阐发型利用预备的，因而在底层数据库即数据仓库的设想上凡是会摘用反三范式的体例，好比Kimball 的维度建模体例，锐意的保留数据冗余，很合适阐发查询操做。当然，在OLAP系统底层数据仓库的架构中也有摘用3NF建模的，次要目标是为了同一营业数据原则，但实正面向阐发办事的时候仍是会在3NF的根底上再构建一套反三范式的Kimball星型模子或者雪花型模子的数据架构。
第六，OLTP因为摘用3NF建模，所以对数据的完全性要求很高，必需摘用完全性约束。但是OLAP自己就不是面向营业交易信息的，不合错误营业过程负责，而且数据也不会频繁修改，所以是没有完全性约束那一说的。好比OLTP里面一个事务没有提交胜利，或者失败了，事务是要回滚的。OLAP里面没有那种处置，跑不胜利再从头跑一遍就能够了。
CUBE是什么
各人能够想象一下，BI前端可视化阐发东西，或者报表东西从数据仓库取数往阐发展示，会不会碰着一些查询性能的问题，那些问题都是怎么来的。
简单来说，阐发页面刷新，前端阅读器不论是报表数据集形式，仍是BI阐发模子形式城市有一条SQL语句跑到办事器端往做数据查询，那个查询假设是BI的话就是到数据仓库上面往查，假设是数据集报表的话能够是从数据仓库，也能够是原始的营业系统数据库，总之有一条SQL语句要施行。
SQL - 派可数据贸易智能BI可视化阐发平台
第一种好比体例A返回的是大宽表到前端，数据量很大，前端再计算函数、渐渐衬着数据才展示出来。
第二种好比体例B返回的查询汇总之后的成果，数据量很小，前端根本上不消做什么衬着数据就出来了。
体例A的时间损耗在哪里呢？不是在数据库办事器查询上，因为SQL可能很简单，时间的损耗大部门是在从办事器端往阅读器通过有大量的汇总，时间损耗在那个处所，削减了数据的返回量，前端函数根本上不消怎么处置，页面衬着也会很快。
所以，各人看到了没有，体例B是对体例A的一种性能优化。假设把那种优化提早的好比在ETL调度中实现，头一天晚上先算好，把该聚合的数据聚合好先存到数据仓库中的某一张内外面。除了需要看明细数据的那种查询场景，其它的任何查询就间接从那张已经提早算好的内外面取数就能够了。整个的复杂的聚合过程不是在BI报表阐发的时候再来计算，而是提早算好、存储，用的时候间接把聚合后的成果拉出来利用。各人看，多了一张表、多了一份存储空间，但是却把整个查询、聚合计算的时间给省下来了，那个过程就是我们经常讲到的“空间换时间”的概念。
数据可视化 - 派可数据贸易智能BI可视化阐发平台
但是也有一个问题啊，数据聚合的成果存放到数据仓库中，那种数据的格局、形式是不是也相当于提早固化了。好比之前发过往的SQL查询返回的就是一张事实表，里面的度量是固定的，阐发的维度属性也是固定的。假设如今用户改动阐发维度或者目标呢？那张事实表就不克不及用了，新倡议的查询就得像前面体例A提到的一样来处置，如许性能就又下降了，于是又得为那种新的查询聚合成果集再提早固化一张数据集市表。如许的场景多了，庇护就十分的费事。
所以数据人员就在想，假设我们可以提早把所有可能阐发的维度和维度属性Dimension and Attribute 和所有可能阐发的度量Measure 全都组合好，全数算出来把成果提早存储起来，如许后面不管什么样的用户用什么样的维度和度量（目标）组合阐发，都不需要暂时计算，间接往成果，如许性能是不是就能够实现百倍、千倍以至万倍的提拔了？确实如斯，因为你还要考虑到并发查询的问题。
如许一做，就是一个更大范畴的用空间换时间的过程，那个过程就是OLAP CUBE多维立方体的设想思惟来源和原理。
OLAP CUBE是若何来实现的
好比时间、区域、产物和销售收进那三个维度和目标的组合。它会先跑一遍SELECT SUM（收进）FROM 表 GROUP BY 时间，接着就是SELECT SUM（收进）FROM 表 GROUP BY 时间、区域，接着就是SELECT SUM（收进）FROM 表 GROUP BY 时间、区域、产物，然后就能够是SELECT MAX（收进）FROM 表 GROUP BY 时间、区域、产物，就是把各类聚合函数、各类目标、各类维度、各类维度属性的查询SQL全都施行一遍，把成果存储起来治理起来，就酿成了一个多维立方体就是CUBE。
那个CUBE自己的描述是通过一个或者一组XML文件来构成的，把里面所有可能用到的SQL在XML文件里面组织起来。实正处置那个CUBE的时候，现实上跑的是那些SQL语句，在关系型数据库中好比数据仓库中把数据取出来停止存储。所以CUBE的空间有时比数据仓库还要大，各类数据的组合都考虑到了。
数据可视化 - 派可数据贸易智能BI可视化阐发平台
当然，现实开发中其实不会是所有的维度、所有的属性、所有的目标都有组合阐发的需要，因而还能够提早做一些设置装备摆设，把哪些认为可能组合阐发的维度、目标联系关系上就能够了。
在CUBE里面就能够很乖巧的做各类透视阐发，数据都是秒出的。但是有一些非间接通过维度和目标组合就能够出来的数据成果就需要通过查询的体例把数据给查询出来，那个时候就要用到MDX语句。在关系型数据库上的数据操做我们通过SQL语句往搞定，在多维阐发数据库CUBE上的数据操做就要利用MDX的语句往搞定。从代码量上比，MDX比SQL要少良多。好比阐发往年在TOP 10消费的客户本年不在的客户有哪些，MDX可能两句话就搞定了，但是SQL就需要写一堆。
但是从便当性上来说，MDX语法愈加复杂，三个月不写根本上就能够忘记差不多了，因为CUBE它是一个多维空间，不像关系型数据库是一个二维的、行列穿插一眼就能看大白。进修CUBE仍是需要有必然的想象力空间，跟关系型数据库取数的逻辑根究体例完全纷歧样。
CUBE在一些海量数据，特殊是大维度表，好比百万级此外维度、万万级的维度那种场景下阐发优势仍是比力明显的。
但是如今也有良多MPP数据库、列式数据库，再连系对数据仓库建模的优化，也能够处理一部门场景下的阐发性能问题。如今OLAP的引擎也已经良多了，好比ClickHouse、Impala、Doris、Kylin 等等。
Kimball - 派可数据贸易智能BI可视化阐发平台
OLAP CUBE 的数据来源一般是来自标准的数据仓库，更好是基于Kimball 维度建模的数据仓库，自己就是原则的维度和事实，CUBE处置起来就愈加的简双方便。但是在ETL调度的时候，周期就会拉的比力长，因为要先处置数据仓库的数据，再才气处置OLAP CUBE里面的数据。
OLAP 里面还有一些分类好比MOLAP、HOLAP、ROLAP，那些查查材料根本上就看大白，可能理解了就能够了。