OLAP联机分析处理介绍

本文涉及的产品
云原生数据库 PolarDB MySQL 版,通用型 2核4GB 50GB
云原生数据仓库AnalyticDB MySQL版,基础版 8ACU 100GB 1个月
云原生数据库 PolarDB PostgreSQL 版,标准版 2核4GB 50GB
简介: 作用   联机分析处理是共享多维信息的、针对特定问题的联机数据访问和分析的快速软件技术。它通过对信息的多种可能的观察形式进行快速、稳定一致和交互性的存取,允许管理决策人员对数据进行深入观察。决策数据是多维数据,多维数据就是决策的主要内容。OLAP专门设计用于支持复杂的分析操作,侧重对决策人员和高层管理人员的决策支持,可以根据分析人员的要求快速、灵活地进行大数据量的复杂查询处理,

作用

  联机分析处理是共享多维信息的、针对特定问题的联机数据访问和分析的快速软件技术。它通过对信息的多种可能的观察形式进行快速、稳定一致和交互性的存取,允许管理决策人员对数据进行深入观察。决策数据是多维数据,多维数据就是决策的主要内容。OLAP专门设计用于支持复杂的分析操作,侧重对决策人员和高层管理人员的决策支持,可以根据分析人员的要求快速、灵活地进行大数据量的复杂查询处理,并且以一种直观而易懂的形式将查询结果提供给决策人员,以便他们准确掌握企业(公司)的经营状况,了解对象的需求,制定正确的方案。联机分析处理具有灵活的分析功能、直观的数据操作和分析结果可视化表示等突出优点,从而使用户对基于大量复杂数据的分析变得轻松而高效,以利于迅速做出正确判断。它可用于证实人们提出的复杂的假设,其结果是以图形或者表格的形式来表示的对信息的总结。它并不将异常信息标记出来,是一种知识证实的方法。


起源

  联机分析处理 (OLAP) 的概念最早是由关系数据库之父E.F.Codd于1993年提出的,他同时提出了关于OLAP的12条准则。OLAP的提出引起了很大的反响,OLAP作为一类产品同联机事务处理 (OLTP) 明显区分开来。

  Codd提出OLAP的12条准则来描述OLAP系统:

  准则1 OLAP模型必须提供多维概念视图

  准则2 透明性准则

  准则3 存取能力准则

  准则4 稳定的报表能力

  准则5 客户/服务器体系结构

  准则6 维的等同性准则

  准则7 动态的稀疏矩阵处理准则

  准则8 多用户支持能力准则

  准则9 非受限的跨维操作

  准则10 直观的数据操纵

  准则11 灵活的报表生成

  准则12 不受限的维与聚集层次


分类

  当今的数据处理大致可以分成两大类:联机事务处理OLTP(on-line transaction processing)、联机分析处理OLAP(On-Line Analytical Processing)。OLTP是传统的关系型数据库的主要应用,主要是基本的、日常的事务处理,例如银行交易。OLAP是数据仓库系统的主要应用,支持复杂的分析操作,侧重决策支持,并且提供直观易懂的查询结果。下表列出了OLTP与OLAP之间的比较。

  OLTP OLAP
用户 操作人员,低层管理人员 决策人员,高级管理人员
功能 日常操作处理 分析决策
DB 设计 面向应用 面向主题
数据 当前的, 最新的细节的, 二维的分立的 历史的, 聚集的, 多维的集成的, 统一的
存取 读/写数十条记录 读上百万条记录
工作单位 简单的事务 复杂的查询
DB 大小 100MB-GB 100GB-TB


发展背景

  随着数据库技术的广泛应用,企业信息系统产生了大量的数据,如何从这些海量数据中提取对企业决策分析有用的信息成为企业决策管理人员所面临的重要难题。传统的企业数据库系统(管理信息系统)即联机事务处理系统(On-LineTransactionProcessing,简称OLTP)作为数据管理手段,主要用于事务处理,但它对分析处理的支持一直不能令人满意。因此,人们逐渐尝试对OLTP数据库中的数据进行再加工,形成一个综合的、面向分析的、更好的支持决策制定决策支持系统(DecisionSupportSystem,简称DSS)。企业的信息系统的数据一般由DBMS管理,但决策数据库和运行操作数据库在数据来源、数据内容、数据模式、服务对象、访问方式、事务管理乃至物理存储等方面都有不同的特点和要求,因此直接在运行操作的数据库上建立DSS是不合适的。数据仓库(DataWarehouse)技术就是在这样的背景下发展起来的。数据仓库的概念提出于20世纪80年代中期,20世纪90年代,数据仓库已从早期的探索阶段走向实用阶段。业界公认的数据仓库概念创始人W.H.Inmon在《BuildingtheDataWarehouse》一书中对数据仓库的定义是:“数据仓库是支持管理决策过程的、面向主题的、集成的、随时间变化的持久的数据集合”。构建数据仓库的过程就是根据预先设计好的逻辑模式从分布在企业内部各处的OLTP数据库中提取数据并对经过必要的变换最终形成全企业统一模式数据的过程。当前数据仓库的核心仍是RDBMS管理下的一个数据库系统。数据仓库中数据量巨大,为了提高性能,RDBMS一般也采取一些提高效率的措施:采用并行处理结构、新的数据组织、查询策略、索引技术等等。

  包括联机分析处理(On-LineAnalyticalProcessing,简称OLAP)在内的诸多应用牵引驱动了数据仓库技术的出现和发展;而数据仓库技术反过来又促进了OLAP技术的发展。联机分析处理的概念最早由关系数据库之父E.F.Codd于1993年提出的。Codd认为联机事务处理(OLTP)已不能满足终端用户对数据库查询分析的要求,SQL对大数据库的简单查询也不能满足用户分析的需求。用户的决策分析需要对关系数据库进行大量计算才能得到结果,而查询的结果并不能满足决策者提出的需求。因此,Codd提出了多维数据库和多维分析的概念,即OLAP。OLAP委员会对联机分析处理的定义为:从原始数据中转化出来的、能够真正为用户所理解的、并真实反映企业多维特性的数据称为信息数据,使分析人员、管理人员或执行人员能够从多种角度对信息数据进行快速、一致、交互地存取,从而获得对数据的更深入了解的一类软件技术。OLAP的目标是满足决策支持或多维环境特定的查询和报表需求,它的技术核心是“维”这个概念,因此OLAP也可以说是多维数据分析工具的集合。


特点

  在过去的二十年中,大量的企业利用关系型数据库来存储和管理业务数据,并建立相应的应用系统来支持日常业务运作。这种应用以支持业务处理为主要目的,被称为联机事务处理(OLTP,On-line Transaction Processing)应用,它所存储的数据被称为操作数据或者业务数据。

  随着市场竞争的日趋激烈,企业更加强调决策的及时性和准确性,这使得以支持决策管理分析为主要目的的应用迅速崛起,这类应用被称为联机分析处理,它所存储的数据被称为信息数据。

  联机分析处理的用户是企业中的专业分析人员及管理决策人员,他们在分析业务经营的数据时,从不同的角度来审视业务的衡量指标是一种很自然的思考模式。例如分析销售数据,可能会综合时间周期、产品类别、分销渠道、地理分布、客户群类等多种因素来考量。这些分析角度虽然可以通过报表来反映,但每一个分析的角度可以生成一张报表,各个分析角度的不同组合又可以生成不同的报表,使得IT人员的工作量相当大,而且往往难以跟上管理决策人员思考的步伐。

  联机分析处理的主要特点,是直接仿照用户的多角度思考模式,预先为用户组建多维的数据模型,在这里,维指的是用户的分析角度。例如对销售数据的分析,时间周期是一个维度,产品类别、分销渠道、地理分布、客户群类也分别是一个维度。一旦多维数据模型建立完成,用户可以快速地从各个分析角度获取数据,也能动态的在各个角度之间切换或者进行多角度综合分析,具有极大的分析灵活性。这也是联机分析处理被广泛关注的根本原因,它从设计理念和真正实现上都与旧有的管理信息系统有着本质的区别。

  事实上,随着数据仓库理论的发展,数据仓库系统已逐步成为新型的决策管理信息系统的解决方案。数据仓库系统的核心是联机分析处理,但数据仓库包括更为广泛的内容。

  -概括来说,数据仓库系统是指具有综合企业数据的能力,能够对大量企业数据进行快速和准确分析,辅助做出更好的商业决策的系统。它本身包括三部分内容:

  1、数据层:实现对企业操作数据的抽取、转换、清洗和汇总,形成信息数据,并存储在企业级的中心信息数据库中。

  2、应用层:通过联机分析处理,甚至是数据挖掘等应用处理,实现对信息数据的分析。

  3、表现层:通过前台分析工具,将查询报表、统计分析、多维联机分析和数据发掘的结论展现在用户面前。

  从应用角度来说,数据仓库系统除了联机分析处理外,还可以采用传统的报表,或者采用数理统计和人工智能等数据挖掘手段,涵盖的范围更广;就应用范围而言,联机分析处理往往根据用户分析的主题进行应用分割,例如:销售分析、市场推广分析、客户利润率分析等等,每一个分析的主题形成一个OLAP应用,而所有的OLAP应用实际上只是数据仓库系统的一部分。


逻辑概念

  OLAP展现在用户面前的是一幅幅多维视图。维(Dimension):是人们观察数据的特定角度,是考虑问题时的一类属性,属性集合构成一个维(时间维、地理维等)。

  维的层次(Level):人们观察数据的某个特定角度(即某个维)还可以存在细节程度不同的各个描述方面(时间维:日期、月份、季度、年)。

  维的成员(Member):维的一个取值,是数据项在某维中位置的描述。(“某年某月某日”是在时间维上位置的描述)。

  度量(Measure):多维数组的取值。(2000年1月,上海,笔记本电脑,0000)。

  OLAP的基本多维分析操作有钻取(Drill-up和Drill-down)、切片(Slice)和切块(Dice)、以及旋转(Pivot)等。

  钻取:是改变维的层次,变换分析的粒度。它包括向下钻取(Drill-down)和向上钻取(Drill-up)/上卷(Roll-up)。Drill-up是在某一维上将低层次的细节数据概括到高层次的汇总数据,或者减少维数;而Drill-down则相反,它从汇总数据深入到细节数据进行观察或增加新维。

  切片和切块:是在一部分维上选定值后,关心度量数据在剩余维上的分布。如果剩余的维只有两个,则是切片;如果有三个或以上,则是切块。

  旋转:是变换维的方向,即在表格中重新安排维的放置(例如行列互换)。


体系结构

  数据仓库与OLAP的关系是互补的,现代OLAP系统一般以数据仓库作为基础,即从数据仓库中抽取详细数据的一个子集并经过必要的聚集存储到OLAP存储器中供前端分析工具读取。典型的OLAP系统体系结构如下图所示:

  OLAP系统按照其存储器的数据存储格式可以分为关系OLAP(RelationalOLAP,简称ROLAP)、多维OLAP(MultidimensionalOLAP,简称MOLAP)和混合型OLAP(HybridOLAP,简称HOLAP)三种类型。

ROLAP

  ROLAP将分析用的多维数据存储在关系数据库中并根据应用的需要有选择的定义一批实视图作为表也存储在关系数据库中。不必要将每一个SQL查询都作为实视图保存,只定义那些应用频率比较高、计算工作量比较大的查询作为实视图。对每个针对OLAP服务器的查询,优先利用已经计算好的实视图来生成查询结果以提高查询效率。同时用作ROLAP存储器的RDBMS也针对OLAP作相应的优化,比如并行存储、并行查询、并行数据管理、基于成本的查询优化、位图索引、SQL的OLAP扩展(cube,rollup)等等。

MOLAP

  MOLAP将OLAP分析所用到的多维数据物理上存储为多维数组的形式,形成“立方体”的结构。维的属性值被映射成多维数组的下标值或下标的范围,而总结数据作为多维数组的值存储在数组的单元中。由于MOLAP采用了新的存储结构,从物理层实现起,因此又称为物理OLAP(PhysicalOLAP);而ROLAP主要通过一些软件工具或中间软件实现,物理层仍采用关系数据库的存储结构,因此称为虚拟OLAP(VirtualOLAP)。

HOLAP

  由于MOLAP和ROLAP有着各自的优点和缺点(如下表所示),且它们的结构迥然不同,这给分析人员设计OLAP结构提出了难题。为此一个新的OLAP结构——混合型OLAP(HOLAP)被提出,它能把MOLAP和ROLAP两种结构的优点结合起来。迄今为止,对HOLAP还没有一个正式的定义。但很明显,HOLAP结构不应该是MOLAP与ROLAP结构的简单组合,而是这两种结构技术优点的有机结合,能满足用户各种复杂的分析请求。

  rolap molap

  沿用现有的关系数据库的技术

  专为olap所设计

  响应速度比molap慢;

  现有关系型数据库已经对olap做了很多优化,包括并行存储、并行查询、并行数据管理、基于成本的查询优化、位图索引、sql 的olap扩展(cube,rollup)等,性能有所提高

  性能好、响应速度快

  数据装载速度快

  数据装载速度慢

  存储空间耗费小,维数没有限制

  需要进行预计算,可能导致数据爆炸,维数有限;无法支持维的动态变化

  借用rdbms存储数据,没有文件大小限制

  受操作系统平台中文件大小的限制,难以达到tb 级(只能10~20g)

  可以通过sql实现详细数据与概要数据的存储

  缺乏数据模型和数据访问的标准

  –不支持有关预计算的读写操作

  –sql无法完成部分计算

  –无法完成多行的计算

  –无法完成维之间的计算

  –支持高性能的决策支持计算

  –复杂的跨维计算

  –多用户的读写操作

  –行级的计算

  维护困难

  管理简便


实现方式

  同样是仿照用户的多角度思考模式,联机分析处理有三种不同的实现方法:

  · 关系型联机分析处理(ROLAP,Relational OLAP)

  · 多维联机分析处理(MOLAP,Multi-Dimensional OLAP)

  · 前端展示联机分析处理(Desktop OLAP)

  其中,前端展示联机分析需要将所有数据下载到客户机上,然后在客户机上进行数据结构/报表格式重组,使用户能在本机实现动态分析。该方式比较灵活,然而它能够支持的数据量非常有限,严重地影响了使用的范围和效率。因此,随着时间的推移,这种方式已退居次要地位,在此不作讨论。


实施方法

  以下就ROLAP和MOLAP的具体实施方法进行讨论:

关系型联机

  顾名思义,关系型联机分析处理是以关系型数据库为基础的。唯一特别之处在于联机分析处理中的数据结构组织的方式。

  让我们考察一个例子,假设我们要进行产品销售的财务分析,分析的角度包括时间、产品类别、市场分布、实际发生与预算四方面内容,分析的财务指标包括:销售额、销售支出、毛利(=销售额-销售支出)、费用、纯利(=毛利-费用)等内容,则我们可以建立如下的数据结构:

  该数据结构的中心是主表,里面包含了所有分析维度的外键,以及所有的财务指标,可计算推导的财务指标不计在内,我们称之为事实表(Fact Table)。周围的表分别是对应于各个分析角度的维表(Dimension Table),每个维表除了主键以外,还包含了描述和分类信息。无论原来的业务数据的数据结构为何,只要原业务数据能够整理成为以上模式,则无论业务人员据此提出任何问题,都可以用SQL语句进行表连接或汇总(table join and group by)实现数据查询和解答。(当然,有一些现成的ROLAP前端分析工具是可以自动根据以上模型生成SQL语句的)。这种模式被称为星型模式(Star-Schema),可应用于不同的联机分析处理应用中。

  以下是另一个采用星型模式的例子,分析的角度和指标截然不同,但数据结构模式一样。我们看到的不是表的数据,而是表的结构。在联机分析处理的数据模型设计中,这种表达方式更为常见:

  有时候,维表的定义会变得复杂,例如对产品维,既要按产品种类进行划分,对某些特殊商品,又要另外进行品牌划分,商品品牌和产品种类划分方法并不一样。因此,单张维表不是理想的解决方案,可以采用以下方式,这种数据模型实际上是星型结构的拓展,我们称之为雪花型模式(snow-flake schema).

  无论采用星型模式还是雪花型模式,关系型联机分析处理都具有以下特点:

  · 数据结构和组织模式需要预先设计和建立;

  · 数据查询需要进行表连接,在查询性能测试中往往是影响速度的关键;

  · 数据汇总查询(例如查询某个品牌的所有产品销售额),需要进行Group by 操作,虽然实际得出的数据量很少,但查询时间变得更长;

  · 为了改善数据汇总查询的性能,可以建立汇总表,但汇总表的数量与用户分析的角度数目和每个角度的层次数目密切相关。例如,用户从8个角度进行分析,每个角度有3个汇总层次,则汇总表的数目高达3的8次方。

  可以采取对常用汇总数据建立汇总表,对不常用的汇总数据进行Group by 操作,这样来取得性能和管理复杂度之间的均衡。

多维联机

  多维联机分析处理实际上是用多维数组的方式对关系型数据表进行处理。下图是ROLAP与MOLAP的对比:

  图中左边是ROLAP方式,右边是MOLAP方式,两者对应的是同一个三维模型。MOLAP首先对事实表中的所有外键进行排序,并将排序后的具体指标数值一一写进虚拟的多维立方体中。当然,虚拟的多维立方体只是为了便于理解而构想的,MOLAP实际的数据存储放在数据文件(Data File)中,其数据放置的顺序与虚拟的多维立方体按x,y,z坐标展开的顺序是一致的(如上图)。同时,为了数据查找的方便,MOLAP需要预先建立维度的索引,这个索引被放置在MOLAP的概要文件(Outline)中。

  概要文件是MOLAP的核心,相当于ROLAP的数据模型设计。概要文件包括所有维的定义(包括复杂的维度结构)以及各个层次的数据汇总关系(例如在时间维,日汇总至月,月汇总至季,季汇总至年),这些定义往往从关系型维表中直接引入即可。概要文件也包括分析指标的定义,因此可以在概要文件中包含丰富的衍生指标,这些衍生指标由基础指标计算推导出来(例如ROLAP例子1中的纯利和毛利)。概要文件的结构如下图所示:

  一旦概要文件定义好,MOLAP系统可以自动安排数据存储的方式和进行数据查询。从MOLAP的数据文件与ROLAP的事实表的对比可以看出,MOLAP的数据文件完全不需要纪录维度的外键,在维度比较多的情况下,这种数据存储方式大量地节省了空间。

  但是,如果数据相当稀疏,虚拟的多维立方体中很多数值为空时,MOLAP的数据文件需要对相关的位置留空,而ROLAP的事实表却不会存储这些纪录。为了有效地解决这种情况,MOLAP采用了稀疏维和密集维相结合的处理方式,如下图。

  上图的背景是某些客户只通过某些分销渠道才购买,但是只要该客户存在,他在各个月和各个地区内均有消费(例如,华南IBM只通过熊猫国旅定购南航机票,但在华南四省在每个月均有机票订购)。则时间和地区维是密集维,客户和分销渠道是稀疏维,MOLAP将稀疏维建成索引文件(Index File),密集维所对应的数值仍然保留在数据文件中,索引文件不存储空纪录。这样保持了对空间的合理利用。我们也可以看到,如果所有维都是稀疏维,则MOLAP的索引文件就退化成ROLAP的事实表, 两者没有区别了。

  在实际应用中,不可能所有分析的维度都是密集的,也绝少存在所有分析的维度都是稀疏的,因此稀疏维和密集维并用的模式几乎主导了所有的MOLAP应用。而稀疏维和密集维的定义全部集中在概要文件中,因此,只要预先定义好概要文件,所有的数据分布就自动确定了。

  在这种模式中,密集维的组合组成了的数据块(Data Block),每个数据块是I/O读写的基础单位(如上图),所有的数据块组成了数据文件。稀疏维的组合组成了索引文件,索引文件的每一个数据纪录的末尾都带有一个指针,指向要读写的数据块。因此,进行数据查询时,系统先搜索索引文件纪录,然后直接调用指针指向的数据块进行I/O读写(如果该数据块尚未驻留内存),将相应数据块调入内存后,根据密集维的数据放置顺序直接计算出要查询的数据距离数据块头的偏移量,直接提取数据下传到客户端。因此,MOLAP 方式基本上是索引搜索与直接寻址的查询方式相结合,比起ROLAP的表/索引搜索和表连接方式,速度要快得多。

  特点

  · 需要预先定义概要文件;

  · 数据查询采用索引搜索与直接寻址的方式相结合,不需要进行表连接,在查询性能测试中比起ROLAP有相当大的优势;

  · 在进行数据汇总查询之前,MOLAP需要预先按概要文件中定义的数据汇总关系进行计算,这个计算通常以批处理方式运行。计算结果回存在数据文件中,当用户查询时,直接调用计算结果,速度非常快。

  · 无论是数据汇总还是计算衍生数据,预先计算的方式实际上是用空间来换时间。当然,用户也可以选择动态计算的方式,用查询时间来换取存储空间。MOLAP可以灵活调整时空的取舍平衡。

  · 用户难以使用概要文件中没有定义的数据汇总关系和衍生指标。

  · 在大数据量环境下,关系型数据库可以达到TB级的数据量,现有的MOLAP应用局限于基于文件系统的处理和查询方式,其性能会在100GB级别开始下降,需要进行数据分区处理,因此扩展性不如ROLAP。因此,MOLAP多数用于部门级的主题分析应用。

其它因素

  联机分析处理其他要素包括假设分析(What-if),复杂计算,数据评估等等。这些因素对用户的分析效用至关重要,但是与ROLAP和MOLAP的核心工作原理的不一定有很紧密的关系,事实上,ROLAP和MOLAP都可以在以上三方面有所建树,只不过实现的方法迥异。因此,这些因素更取决于各个厂商为他们的产品提供的外延功能。对于像IBM的DB2 OLAP Server这样一个成熟的产品来说,这三方面均有独特的优势:

假设分析

  假设分析提出了类似于以下的问题:"如果产品降价5%,而运费增加8%,对不同地区的分销商的进货成本会有什么影响?"这些问题常用于销售预测、费用预算分配、奖金制度确定等等。据此,用户可以分析出哪些角度、哪些因素的变化将对企业产生重要影响;并且,用户可以灵活调节自己手中掌握的资源(例如费用预算等),将它用到最有效的地方中去。

  假设分析要求OLAP系统能够随用户的思路调整数据,并动态反映出在调整后对其他数据的影响结果。事实上,进入OLAP的数据分两大类:事实数据和预算数据。事实数据一般情况下不容修改,而预算数据则应常常进行调整。DB2 OLAP Server通过详细的权限定义区分了数据的读写权限,允许用户对预算数据进行更改,系统可以对其他受影响的数据进行计算,以反映出"假如发生如上情况,将会引起以下结果"的结论。

复杂计算

  分析人员往往需要分析复杂的衍生数据,诸如:同期对比、期初/期末余额、百分比份额计算、资源分配(按从顶向下的结构图逐级分配)、移动平均、均方差等等。对这些要求,DB2 OLAP Server提供丰富的功能函数以便用户使用。因为只有在无需编程的环境下,商业用户才能更好地灵活利用这些功能进行复杂的真实世界模拟。

数据评估

  数据评估包括两方面内容,有效性评估和商业意义评估。在有效性评估方面,数据抽取、清洗和转换的规则的定义是至关重要的。而合理的数据模型设计能有效防止无效数据的进入。例如在ROLAP中,如果维表没有采用范式设计(normalise design),可能会接受如下的维表:

  机构代码 机构名称 所属区县 所属城市 所属省份

  001 越秀支行 越秀区 广州 广东

  002 祖庙支行 佛山 广州 广东

  003 翠屏支行 佛山 南海 广东

  004 。。。 。。。 。。。 。。。

  显然,002中显示的佛山属于广州市,与003中显示的佛山属于南海市是矛盾的。这显示出数据源有问题,但是如果采用星型模式设计,ROLAP无法自动发现数据源的问题!

  在类似情况下,MOLAP的表现稍占优势。因为MOLAP需要预先定义概要文件,而概要文件会详细分析维度的层次关系,因此生成概要文件时会反映数据源的错误。因此,在DB2 OLAP Server中,记录003会被拒收,并纪录在出错日志中,供IT人员更正。

  但是,OLAP对数据源有效性的验证能力毕竟是有限的,因此,数据有效性必须从源数据一级和数据抽取/清洗/转换处理一级来进行保障。

  对用户而言,数据的商业含义评估更有意义。在商业活动中,指标数值的取值范围是比较稳定的,如果指标数值突然发生变化,或者在同期比较、同类比较中有特殊表现,意味着该指标代表的方方面面具有特别的分析意义。普通的OLAP往往需要用户自己去观察发现异常指标,而DB2 OLAP Server的OLAP Minor(多维数据挖掘功能)能为用户特别地指出哪些条件下的哪些指标偏离常值,从而引起用户的注意和思考。例如:12月份南部的圣诞礼品销售额不到同期类似区域(东部、中部、西部)的50%。

  综上所述,无论ROLAP还是MOLAP,都能够实现联机分析处理的基本功能,两者在查询效率,存储空间和扩展性方面各有千秋。IT人员在选择OLAP系统时,既要考虑产品内部的实现机制,同时也应考虑假设分析,复杂计算,数据评估方面的功能,为实现决策管理信息系统打下坚实的基础。




相关实践学习
AnalyticDB MySQL海量数据秒级分析体验
快速上手AnalyticDB MySQL,玩转SQL开发等功能!本教程介绍如何在AnalyticDB MySQL中,一键加载内置数据集,并基于自动生成的查询脚本,运行复杂查询语句,秒级生成查询结果。
阿里云云原生数据仓库AnalyticDB MySQL版 使用教程
云原生数据仓库AnalyticDB MySQL版是一种支持高并发低延时查询的新一代云原生数据仓库,高度兼容MySQL协议以及SQL:92、SQL:99、SQL:2003标准,可以对海量数据进行即时的多维分析透视和业务探索,快速构建企业云上数据仓库。 了解产品 https://www.aliyun.com/product/ApsaraDB/ads
目录
相关文章
|
存储 SQL 前端开发
【DBMS 数据库管理系统】OLTP 联机事务处理 与 OLAP 联机分析处理 ( 数据仓库 与 OLAP | OLAP 联机分析处理 | OLTP 与 OLAP 区别 )
【DBMS 数据库管理系统】OLTP 联机事务处理 与 OLAP 联机分析处理 ( 数据仓库 与 OLAP | OLAP 联机分析处理 | OLTP 与 OLAP 区别 )
620 0
|
30天前
|
人工智能 自然语言处理 关系型数据库
阿里云云原生数据仓库 AnalyticDB PostgreSQL 版已完成和开源LLMOps平台Dify官方集成
近日,阿里云云原生数据仓库 AnalyticDB PostgreSQL 版已完成和开源LLMOps平台Dify官方集成。
|
20天前
|
人工智能 分布式计算 数据管理
阿里云位居 IDC MarketScape 中国实时湖仓评估领导者类别
国际数据公司( IDC )首次发布了《IDC MarketScape: 中国实时湖仓市场 2024 年厂商评估》,阿里云在首次报告发布即位居领导者类别。
|
21天前
|
SQL 分布式计算 数据挖掘
加速数据分析:阿里云Hologres在实时数仓中的应用实践
【10月更文挑战第9天】随着大数据技术的发展,企业对于数据处理和分析的需求日益增长。特别是在面对海量数据时,如何快速、准确地进行数据查询和分析成为了关键问题。阿里云Hologres作为一个高性能的实时交互式分析服务,为解决这些问题提供了强大的支持。本文将深入探讨Hologres的特点及其在实时数仓中的应用,并通过具体的代码示例来展示其实际应用。
115 0
|
4月前
|
数据采集 运维 Cloud Native
Flink+Paimon在阿里云大数据云原生运维数仓的实践
构建实时云原生运维数仓以提升大数据集群的运维能力,采用 Flink+Paimon 方案,解决资源审计、拓扑及趋势分析需求。
18501 54
Flink+Paimon在阿里云大数据云原生运维数仓的实践
|
2月前
|
存储 机器学习/深度学习 监控
阿里云 Hologres OLAP 解决方案评测
随着大数据时代的到来,企业面临着海量数据的挑战,如何高效地进行数据分析和决策变得尤为重要。阿里云推出的 Hologres OLAP(在线分析处理)解决方案,旨在为用户提供快速、高效的数据分析能力。本文将深入探讨 Hologres OLAP 的特点、优势以及应用场景,并针对方案的技术细节、部署指导、代码示例和数据分析需求进行评测。
119 7
|
2月前
|
运维 数据挖掘 OLAP
阿里云Hologres:一站式轻量级OLAP分析平台的全面评测
在数据驱动决策的今天,企业对高效、灵活的数据分析平台的需求日益增长。阿里云的Hologres,作为一站式实时数仓引擎,提供了强大的OLAP(在线分析处理)分析能力。本文将对Hologres进行深入评测,探讨其在多源集成、性能、易用性以及成本效益方面的表现。
98 7
|
3月前
|
分布式计算 安全 OLAP
7倍性能提升|阿里云AnalyticDB Spark向量化能力解析
AnalyticDB Spark如何通过向量化引擎提升性能?
|
3月前
|
人工智能 分布式计算 数据管理
阿里云位居 IDC MarketScape 中国实时湖仓评估领导者类别
国际数据公司(IDC)首度发布《IDC MarketScape: 中国实时湖仓市场 2024 年厂商评估》,阿里云荣登领导者地位。报告评估了13家厂商,涵盖互联网、云服务及大数据领域。阿里云凭借其在实时湖仓领域的创新能力,特别是Apache Paimon及与Flink的集成,实现了高效流批处理和AI增强功能,为企业提供了一体化的湖仓解决方案,支持多种数据管理和AI应用场景,展现出了强大的市场领导力和技术实力。
133 8
|
4月前
|
存储 SQL 缓存
【报名中】阿里云 x StarRocks:极速湖仓第二季—上海站
阿里云 x StarRocks:极速湖仓第二季,7月20日阿里巴巴上海徐汇滨江园区,现场签到丰富奖品等你拿,不见不散!
313 7
【报名中】阿里云 x StarRocks:极速湖仓第二季—上海站