LOFTER for ipad —— 让兴趣,更有趣

点击下载 关闭

LOFTER-网易轻博

OLAP

566浏览    5参与
Data Mining

OLAP(联机分析处理)

联机分析处理OLAP全称On-line Analytical Processing

是由数据仓库提供的一种重要的数据分析工具,它使分析人员能够迅速、一致、交互地从各个方面观察信息,以达到深入理解数据的目的。

它具有FASMI(Fast Analysis of Shared Multidimensional Information),即共享多维信息的快速分析的特征。

F是快速性(Fast),指系统能在数秒内对用户的多数分析要求做出反应;

A是可分析性(Analysis),指用户无需编程就可以定义新的专门计算,将其作为分析的一部 分,并以用户所希望的方式给出报告;

M是多维性(...

联机分析处理OLAP全称On-line Analytical Processing

是由数据仓库提供的一种重要的数据分析工具,它使分析人员能够迅速、一致、交互地从各个方面观察信息,以达到深入理解数据的目的。

它具有FASMI(Fast Analysis of Shared Multidimensional Information),即共享多维信息的快速分析的特征。

F是快速性(Fast),指系统能在数秒内对用户的多数分析要求做出反应;

A是可分析性(Analysis),指用户无需编程就可以定义新的专门计算,将其作为分析的一部 分,并以用户所希望的方式给出报告;

M是多维性(Multi—dimensional),指提供对数据分析的多维视图和分析;

I是信息性(Information),指能及时获得信息,并且管理大容量信息。

 

发展背景

自20世纪80年代开始,许多企业利用关系型数据库来存储和管理业务数据,并建立相应的应用系统来支持日常的业务运作。这种应用以支持业务处理为主要目的,被称为联机事务处理(OLTP)应用,它所存储的数据被称为操作数据或者业务数据

随着数据库技术的广泛应用,企业信息系统产生了大量的业务数据,如何从这些海量的业务数据中提取出对企业决策分析有用的信息,这成为企业决策管理人员所面临的重要难题。因此,人们逐渐尝试对OLTP数据库中的数据进行再加工,以形成一个综合的、面向服务对象、访问方式、事务管理乃至物理存储等方面都有不同的特点和要求。直接在操作型数据库上建立决策支持系统是不合适的,数据仓库技术就是在这样的背景下发展起来的。

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

联机分析处理的概念最早由关系数据库之父E.F.Codd于1993年提出。Codd认为,联机事务处理已不能满足终端用户对数据库查询分析的要求,SQL对大容量数据库的简单查询也不能满足用户分析的需求。用户的决策分析需要对关系数据库进行大量的计算才能得到结果,而查询的结果并不能满足决策者提出的需求。因此,Codd提出了多维数据库和多维分析的概念,即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(RelationalOLAP,简称ROLAP)、多维OLAP(MultidimensionalOLAP,简称MOLAP)和混合型OLAP(HybridOLAP,简称HOLAP)三种类型。

 

资料来自《百度百科》

数控小J

大数据环境下的多维分析技术

引言

之前我们有一篇文章《一文读懂多维分析技术(OLAP)的进化过程》为大家介绍了多维分析技术(即联机分析处理(On-Line Analytical Processing),简称OLAP)的前世今生及发展方向。正是由于多维分析技术在业务分析系统的核心功能中的不可替代性,随着商业智能系统的深入应用,分析系统的数据量呈指数级增长,原有依赖硬盘IO处理性能(包括传统数据库、多维立方体文件)的多维分析技术遭遇到性能瓶颈。与此同时,随着服务器内存价格的下降,一种新的基于内存的OLAP技术架构出现了。这种新架构既能够保证类似于MOLAP方式的高性能,也能基于更大的数据量进行分析,还不用定期将数据库里的数...

引言

之前我们有一篇文章《一文读懂多维分析技术(OLAP)的进化过程》为大家介绍了多维分析技术(即联机分析处理(On-Line Analytical Processing),简称OLAP)的前世今生及发展方向。正是由于多维分析技术在业务分析系统的核心功能中的不可替代性,随着商业智能系统的深入应用,分析系统的数据量呈指数级增长,原有依赖硬盘IO处理性能(包括传统数据库、多维立方体文件)的多维分析技术遭遇到性能瓶颈。与此同时,随着服务器内存价格的下降,一种新的基于内存的OLAP技术架构出现了。这种新架构既能够保证类似于MOLAP方式的高性能,也能基于更大的数据量进行分析,还不用定期将数据库里的数据刷新到OLAP服务器来防止数据过期。这种新的体系架构当之无愧地成为大数据环境下搭建多维分析功能的流行选择,而IBM Cognos的Dynamic Cubes就是它的代表作。

动态立方体(Dynamic Cubes)作为一种新的技术架构最先应用在Cognos的10.2.0版本。下面我们以Cognos的11.0版本来看看怎样对动态立方体进行性能调优。

影响因素

动态立方体是以原有ROLAP技术为基础,使用服务器内存作缓存的一种新型技术架构。它的响应性能的影响因素包括。

数据仓库(数据集市):由于DynamicCubes的事实表数据都存储在数据仓库中,因此,有时数据仓库的性能好坏会影响前端多维分析查询的响应速度。在数据仓库的多维数据模型中,需要注意:

  • 维表中的连接事实表的代理键的数据类型应该采用integer类型

  • 维表中的各个层级的层级键的数据类型应该采用integer类型

2.数据库:提高数据库的查询性能,有助于提高最终多维分析展现的响应速度。

  • 有时候多维分析的性能严重依赖于数据库运行大数据量多任务查询任务的性能

  • 数据库基于的硬件资源(内存、CPU及IO)应该考虑到大数据量并行查询的性能,因此基于物理机的数据库性能当然比基于虚拟机的更优

  • 尽量少用或者不用视图,因为视图的数据不是物理存在的

  • 最好采用分析型的MPP数据库,因为多维分析都是针对大数据量的汇总查询

  • 采用列存储技术的数据库对于大量并发并联查询性能更优

  • 要确保查询性能最优化,可以通过数据库的性能分析监控、执行计划分析等工具

  • 索引的设计,对于非MPP数据库,索引的设计对于查询性能影响很大

动态立方体性能调优

1.由于动态立方体使用机器内存和CPU进行性能增强,所以在对应用服务器的硬件进行评估时应该为将来的性能扩展留一定的预留空间。硬件评估可以通过Cognos提供的建模工具Cube Designer里的“评估硬件需求”功能初步估算。如下图所示。

2.在多维立方体模型设计时,使用模型验证功能,可以知道影响性能的问题所在。可能的问题有:连接字段类型、星形模型与雪花模型、过滤器的使用、视图的使用等等。如下图所示。

3.评估模型的复杂度。如果多维模型的维度和度量很多,数据量也很大,可以通过设计聚合表或者聚合内存来提升查询性能。动态立方体会通过聚合感知技术找到最合适的聚合数据集进行查询以提高查询性能。如下图所示。

4.JVM设置。动态立方体使用Java虚拟机作为内存管理的容器载体,所以Cognos也提供了一些JVM堆设置来优化数据查询性能。你可以在Cognos Administration界面上找到Query Service服务进行参数调整。如下图所示。

5.您还可以通过Cognos的Dynamic Query Analyzer (DQA)工具来对动态立方体的查询性能进行评估并得到优化建议。在进行评估之前,记得将Dynamic Cubes的工作日志打开,如下图所示。

结束语

如需了解更多,请猛击以下链接,发现惊喜!

http://bigdata.evget.com/

更多大数据与分析相关行业资讯、解决方案、案例、教程等请点击查看>>>

详情请咨询在线客服

客服热线:023-66090381

HoH的公开课笔记

DB: Week 9: OLAP & NOSQL Systems

SQLOLTP – Online Transaction Processing 

  • Short transactions 

  • Simple queries 

  • Touch small portions of data 

  • Frequent updates

OLAP – Online Analytical Processing 

  • Long transactions 

  • Complex queries

  • Touch large portions of the data 

  • Infrequent updates

More terminology 

  • Data...

SQLOLTP – Online Transaction Processing 

  • Short transactions 

  • Simple queries 

  • Touch small portions of data 

  • Frequent updates

OLAP – Online Analytical Processing 

  • Long transactions 

  • Complex queries

  • Touch large portions of the data 

  • Infrequent updates

More terminology 

  • Data warehousing: Bring data from operational (OLTP) sources into a single “warehouse” for (OLAP) analysis 

  • Decision support system (DSS): Infrastructure for data analysis
       E.g., data warehouse tuned for OLAP

“Star Schema”  fact table references dimension tables

Fact table:   Updated frequently, often append-only, very large 

Dimension tables: Updated infrequently, not as large 

OLAP Queries

Join -> Filter -> Group -> Aggregate 

Performance 

  • Inherently very slow: special indexes, query processing techniques 

  • Extensive use of materialized views

Data Cube(a.k.a. multidimensional OLAP) 

  • Dimension data forms axes of “cube” 

  • Fact (dependent) data in cells 

  • Aggregated data on sides, edges, corner

Fact table uniqueness for data cube 

If dimension attributes not key, must aggregate
Date can be used to create key

 

Drill-down: Examining summary data, break out by dimension attribute

Roll-up: Examining data, summarize by dimension attribute

SQL Constructs

With Cube

Add to results: faces, edges, and corners using NULL values

With Rullup

For hierarchical dimensions, portion of With Cube

NoSQL Systems

Not every data management/analysit problem is best solved using a traditional DBMS

Not using traditional relation DBMS

!= "not use SQL language"

NoSQL = not only SQL

Alternative to tranditional relational DBMS

Pros: Flexible schema, Quicker/cheaper to set up, massive scalability, relaxed consistency -> higher performance and availability

Cons: 

  • No declarative query language -> more programming; 

  • Relaxed consistency -> fewer guarantees

Example #1: Web log analysis higher parallel

Example #2: Social-network graph

Example #3: Wikipedia pages

Several incarnations

  • MapReduce framework

  • Key-value stores

  • Document stores

  • Graph database systems

路过

列数据库特点

 
最早的商业列式数据库是在1995年发布的Sybase IQ , 但是一直到1999年左右才慢慢稳定到能够投入生产环境. 现在的大多数分析型数据库都是在2003-2005年从Postgresql 分支出来的. 其中尤其是Vertica 为代表的列数据库已经在大规模数据仓库环境中证明其特别为数据仓库环境设计的思路在一些领域具有竞争优势. 这篇文章解释介绍列式数据库的几大特点.
 


  • 高效的储存空间利用率 传统的行式数据库由于每个列的长度不一,为了预防更新的时候不至于出现一行数据跳到另一个block 上去, 所以往往会预留一些空间. 而面向列的数据库由于一开始就完全为分析而...

 
最早的商业列式数据库是在1995年发布的Sybase IQ , 但是一直到1999年左右才慢慢稳定到能够投入生产环境. 现在的大多数分析型数据库都是在2003-2005年从Postgresql 分支出来的. 其中尤其是Vertica 为代表的列数据库已经在大规模数据仓库环境中证明其特别为数据仓库环境设计的思路在一些领域具有竞争优势. 这篇文章解释介绍列式数据库的几大特点.
 


  • 高效的储存空间利用率 传统的行式数据库由于每个列的长度不一,为了预防更新的时候不至于出现一行数据跳到另一个block 上去, 所以往往会预留一些空间. 而面向列的数据库由于一开始就完全为分析而存在,不需要考虑少量的更新问题,所以数据完全是密集储存的.


行式数据库为了表明行的id 往往会有一个伪列rowid 的存在. 列式数据库一般不会保存rowid.
列式数据库由于其针对不同列的数据特征而发明的不同算法使其往往有比行式数据库高的多的压缩率,普通的行式数据库一般压缩率在3:1 到5:1 左右,而列式数据库的压缩率一般在8:1到30:1 左右. (InfoBright 在特别应用可以达到40:1 , Vertica 在特别应用可以达到60:1 , 一般是这么高的压缩率都是网络流量相关的)

列式数据库由于其特殊的IO 模型所以其数据执行引擎一般不需要索引来完成大量的数据过滤任务(Sybase IQ 除外) . 这又额外的减少了数据储存的空间消耗.
列式数据库不需要物化视图,行式数据库为了减少IO 一般会有两种物化视图,常用列的不聚合物化视图和聚合的物化视图. 列式数据库本身列是分散储存所以不需要第一种,而由于其他特性使其极为适合做普通聚合操作.(另外一种物化视图是不能实时刷新的,比如排名函数,不规则连接connect by 等等,这部分列数据库不包括.)
 
 

  • 不可见索引 列式数据库由于其数据的每一列都按照选择性进行排序,所以并不需要行式数据库里面的索引来减少IO 和更快的查找值的分布情况. 如下图所示: 当数据库执行引擎进行where 条件过滤的时候. 只要它发现任何一列的数据不满足特定条件,整个block 的数据就都被丢弃. 最后初步的过滤只会扫描可能满足条件的数据块.



(from InfoBright : Blazing Queries Using an Open Source Columnar Database for High Performance Analytics and Reporting )
 
另外在已经读取了可能的数据块之后,对于类似age < 65 或 job = ‘Axx’ 的,列式数据库并不需要扫描完整个block,因为数据已经排序了. 如果读到第一个age=66 或者 Job = ‘Bxx’ 的时候就会停止扫描了. 这相当与行式数据库索引里的范围扫描.
 

  • 数据迭代 (Tuple Iteration) 现在的多核CPU 提供的L2 缓存在短时间执行同一个函数很多次的时候能更好的利用CPU 的二级缓存和多核并发的特性.  而行式数据库由于其数据混在一起没法对一个数组进行同一个简单函数的调用,所以其执行效率没有列式数据库高.


 

  • 压缩算法 列式数据库由于其每一列都是分开储存的. 所以很容易针对每一列的特征运用不同的压缩算法. 常见的列式数据库压缩算法有Run Length Encoding , Data Dictionary  , Delta Compression , BitMap Index , LZO , Null Compression 等等. 根据不同的特征进行的压缩效率从10W:1 到10:1 不等. 而且数据越大其压缩效率的提升越为明显.


 

  • 延迟物化 列式数据库由于其特殊的执行引擎,在数据中间过程运算的时候一般不需要解压数据而是以指针代替运算,直到最后需要输出完整的数据时.



(from McKnight : Columnar Database : Data Does the Twist and Analytics Shout)
传统的行式数据库运算, 在运算的一开始就解压缩所有数据,然后执行后面的过滤,投影,连接,聚合操作
而列式数据库的执行计划却是这样的.


(from McKnight : Columnar Database : Data Does the Twist and Analytics Shout)
在整个计算过程中, 无论过滤,投影,连接,聚合操作,列式数据库都不解压数据直到最后数据才还原原始数据值. 这样做的好处有减少CPU 消耗,减少内存消耗,减少网络传输消耗,减少最后储存的需要.
 
 
列式数据库优缺点
列式数据库从一开始就是面向大数据环境下数据仓库的数据分析而产生,它跟行式数据库相比当然也有一些前提条件和优缺点.
列式数据库优点:
极高的装载速度 (最高可以等于所有硬盘IO 的总和,基本是极限了)
适合大量的数据而不是小数据
实时加载数据仅限于增加(删除和更新需要解压缩Block 然后计算然后重新压缩储存)
高效的压缩率,不仅节省储存空间也节省计算内存和CPU.
非常适合做聚合操作.
 
 
缺点:
不适合扫描小量数据
不适合随机的更新
批量更新情况各异,有的优化的比较好的列式数据库(比如Vertica)表现比较好,有些没有针对更新的数据库表现比较差.
不适合做含有删除和更新的实时操作.
 
 
常见误区
一个常见的误区认为如果每次扫描较多行或者全列全表扫描的时候,行式数据库比列式数据库更有优势. 事实上这只是行式数据库认识上的一个误区,即认为列式数据库的主要优势在于其列分开储存,而忽略了列式数据库上面提到的其他几大特征,这个才是列式数据库高性能的核心.
 
 
 
参考资料:
Vertica CTO 2007 年写的列数据库特点
http://www.dbms2.com/2007/03/24/mike-stonebraker-explains-column-store-data-compression/
路过

BI,ETL,OLTP,OLAP

BI确切地讲,BI并不是一项新技术,它将数据仓库(DW)、联机分析处理(OLAP)、数据挖掘(DM)等技术与客户关系管理(CRM)等结合起来应用于商业活动实际过程当中,实现了技术服务于决策的目的;Mark Hammond从管理的角度看待BI,认为BI是从“根本上帮助你把公司的运营数据转化成为高价值的可以获取的信息(或者知识),并且在恰当的时间通过恰当的手段把恰当的信息传递给恰当的人”。

ETL即数据抽取(Extract)、转换(Transform)、装载(Load)的过程。它是构建数据仓库的重要环节。数据仓库是面向主题的、集成的、稳定的且随时间不断变化的数据集合,用以支持经营管理中的决策制定过程...

BI确切地讲,BI并不是一项新技术,它将数据仓库(DW)、联机分析处理(OLAP)、数据挖掘(DM)等技术与客户关系管理(CRM)等结合起来应用于商业活动实际过程当中,实现了技术服务于决策的目的;Mark Hammond从管理的角度看待BI,认为BI是从“根本上帮助你把公司的运营数据转化成为高价值的可以获取的信息(或者知识),并且在恰当的时间通过恰当的手段把恰当的信息传递给恰当的人”。

ETL即数据抽取(Extract)、转换(Transform)、装载(Load)的过程。它是构建数据仓库的重要环节。数据仓库是面向主题的、集成的、稳定的且随时间不断变化的数据集合,用以支持经营管理中的决策制定过程。数据仓库系统中有可能存在着大量的噪声数据,引起的主要原因有:滥用缩写词、惯用语、数据输入错误、重复记录、丢失值、拼写变化等。即便是一个设计和规划良好的数据库系统,如果其中存在着大量的噪声数据,那么这个系统也是没有任何意义的,因为“垃圾进,垃圾出”(garbage in, garbage out),系统根本就不可能为决策分析系统提供任何支持。为了清除噪声数据,必须在数据库系统中进行数据清洗。目前有不少数据清洗研究和ETL研究,但是如何在ETL过程中进行有效的数据清洗并使这个过程可视化,此方面研究不多。本文主要从两个方面阐述ETL和数据清洗的实现过程:ETL的处理方式[19]和数据清洗的实现方法。
联机事务处理OLTP
联机分析处理 (OLAP) 的概念最早是由关系数据库之父E.F.Codd于1993年提出的,他同时提出了关于OLAP的12条准则。OLAP的提出引起了很大的反响,OLAP作为一类产品同联机事务处理 (OLTP) 明显区分开来。
当今的数据处理大致可以分成两大类:联机事务处理OLTP(on-line transaction processing)、联机分析处理OLAP(On-Line Analytical Processing)。OLTP是传统的关系型数据库的主要应用,主要是基本的、日常的事务处理,例如银行交易。OLAP是数据仓库系统的主要应用,支持复杂的分析操作,侧重决策支持,并且提供直观易懂的查询结果。
OLAP是使分析人员、管理人员或执行人员能够从多角度对信息进行快速、一致、交互地存取,从而获得对数据的更深入了解的一类软件技术。OLAP的目标是满足决策支持或者满足在多维环境下特定的查询和报表需求,它的技术核心是"维"这个概念。

LOFTER

让兴趣,更有趣

简单随性的记录
丰富多彩的内容
让生活更加充实

下载移动端
关注最新消息