数据仓库

简介

数仓是一种思想，数仓是一种规范，数仓是一种解决方案。

架构演进

离线数据仓库到实时数据仓库，从lambda架构到kappa架构、再到混合架构。

数仓分层

数仓分层，一般按ods->dw->dm整体架构。

经典四层架构：ods->dwd->dws-ads，bdl->fdl->gdl->adl等。

技术选型：

传统数仓一般以Oracle、greenplum、teradata 等。
互联网数仓一般以Hadoop生态圈为主。
- 离线以Hive为核心；
- 准实时以spark为核心；
- 实时以flink为核心构建。

数据调研

（1）业务调研，业务侧对齐，遵循关系型数据库建模方式，从概念模型（cdm）->逻辑模型（ldm）->物理模型（pdm）建模套路，是一个从抽象到具体的一个不断细化完善的分析，设计和开发的过程。

概念模型
- 最高层次的数据模型
- 业务系统核心和边界
- 包含核心业务主体和主体之间业务关系
逻辑模型
- 概念模型进一步细化
- 业务规则概念模型具体化
- 一般遵循第三范式，描述实体属性关系
物理模型
- 概念实体系统物理实现
- 对列的属性进行明确的定义

（2）需求调研，现有BI报表需求，统计需求，用户画像，推荐系统等数据应用。

（3）数据库调研，了解数据库表数据结构、数据形态，全局把握业务流程数据流向，做到真正业务流程和数据结构结合。

主题域划分

业务高度抽象，可先确定企业业务bu模块，然后可根据概念模型（cdm）进行一级主题划分，确定一致性维度和事实流程，构建总线矩阵。

按照kimball大师经典建模四步骤：选择业务过程->声明粒度->确定维度->确定事实进行维度建模。

选择业务过程
- 组织完成的微观活动：如检索、竞价、展现、点击
声明粒度
- 如何描述事实表中每个行的内容：如客户单次检索
标识维度
- 业务人员如何描述来自业务过程度量事件的数据？
标识事实
- 过程的度量是什么？时间、IP、来源、受理者等

数仓规范

设计规范
- 逻辑架构、技术架构、分层设计、主题划分、方法论
命名规范
- 各层级命名、任务命名、表命名、字段命名等
模型规范
- 建模工具、血缘关系、维度建模、维度退化、元数据管理
开发规范
- 脚本注释、字段别名、编码规范、脚本格式、数据类型、缩写规范
流程规范
- 需求流程、工程流程、上线流程、调度流程、代码review

数据治理

可从数据质量、元数据管理、数据安全、数据生命周期等方面开展实施。

（1）数据质量，必须保证完整性、准确性、一致性、时效性。每一个任务都应该配置数据质量监控，严禁任务裸奔。可建设统一数据质量告警中心从以下四个方面进行监控、预警和优化任务。

（2）元数据管理，关于数据的数据。可分为技术元数据和业务元数据。对于数仓开发和维护，模型血缘关系尤为重要。

（3）数据安全，可包含以下五方面的内容，即数据的保密性、真实性、完整性、未授权拷贝和所寄生系统的安全性。

数仓理念

从80年代到现在，数据仓库流派之争已趋于稳缓，比较经典的就是数仓大师Kimball的维度建模、数仓之父Inmon的范式(E-R)建模，另外还有Data Vault建模、Anchor模型等。

数据模型（维度建模）

对于数仓而言，模型就是命脉，好与坏直接决定企业数据存储、处理和应用。

对于维度建模，真正理解了粒度和一致性维度，也就理解了维度建模的魂。

对于建模工具，没有最好只有更好，适合业务的就是最好的。

基本概念

维度建模，是数据仓库大师Ralph Kimball提出的，是数据仓库工程领域最流行的数仓建模经典。

维度建模以分析决策的需求出发构建模型，构建的数据模型为分析需求服务，因此它重点解决用户如何更快速完成分析需求，同时还有较好的大规模复杂查询的响应性能。

它是面向分析的，为了提高查询性能可以增加数据冗余，反规范化的设计技术。

事实表

事实表产生于业务过程，存储了业务活动或事件提炼出来的性能度量。从最低的粒度级别来看，事实表行对应一个度量事件。

事实表根据粒度的角色划分不同，可分为事务事实表、周期快照事实表、累积快照事实表。

（1）事务事实表，用于承载事务数据，通常粒度比较低，它是面向事务的，其粒度是每一行对应一个事务，它是最细粒度的事实表，例如产品交易事务事实、ATM交易事务事实。

（2）周期快照事实表，按照一定的时间周期间隔(每天，每月)来捕捉业务活动的执行情况，一旦装入事实表就不会再去更新，它是事务事实表的补充。用来记录有规律的、固定时间间隔的业务累计数据，通常粒度比较高，例如账户月平均余额事实表。

（3）累积快照事实表，用来记录具有时间跨度的业务处理过程的整个过程的信息，每个生命周期一行，通常这类事实表比较少见。

注意：这里需要值得注意的是，在事实表的设计时，一定要注意一个事实表只能有一个粒度，不能将不同粒度的事实建立在同一张事实表中。

维度表

维度表，一致性维度，业务过程的发生或分析角度，主要关注下退化维度和缓慢变化维。

（1）退化维度（DegenerateDimension）

在维度类型中，有一种重要的维度称作为退化维度，亦维度退化一说。这种维度指的是直接把一些简单的维度放在事实表中。退化维度是维度建模领域中的一个非常重要的概念，它对理解维度建模有着非常重要的作用，退化维度一般在分析中可以用来做分组使用。

（2）缓慢变化维（Slowly Changing Dimensions）

维度的属性并不是始终不变的，它会随着时间的流逝发生缓慢的变化，这种随时间发生变化的维度我们一般称之为缓慢变化维（SCD）。

SCD常用的处理方式（员工部门更换）：

① TYPE1 直接覆盖原值：产品部->大数据部。

② TYPE2 增加维度行：在为维度成员增加新行时，需为其分配新的主代理键。并且，至少需要在维度行再增加三列：有效日期、截止日期、行标识。这个地方可联想拉链表设计。（产品部，time1-time2，old）->（大数据部，time2-time3，new）。

③ TYPE3 增加属性列：新增一列属性，新部门，设置为大数据部。

④ 混合方式

粒度

用于确定某一事实表中的行表示什么，是业务最小活动单元或不同维度组合，即业务细节程度。

维度建模流程

维度建模步骤：选择业务过程->声明粒度->确定维度->确定事实。旨在重点解决数据粒度、维度设计和事实表设计问题。

建模方法

数据仓库建模方法论可分为：维度建模、范式建模、Data Vault模型、Anchor模型。

维度模型

按数据组织类型划分可分为星型模型、雪花模型、星座模型。

星型模型

星型模型主要是维表和事实表，以事实表为中心，所有维度直接关联在事实表上，呈星型分布。

雪花模型

雪花模型，在星型模型的基础上，维度表上又关联了其他维度表。这种模型维护成本高，性能方面也较差，所以一般不建议使用。尤其是基于hadoop体系构建数仓，减少join就是减少shuffle，性能差距会很大。

星座模型

星座模型，是对星型模型的扩展延伸，多张事实表共享维度表。数仓模型建设后期，大部分维度建模都是星座模型。

范式模型

即实体关系（ER）模型，数据仓库之父Immon提出的，从全企业的高度设计一个3NF模型，用实体加关系描述的数据模型描述企业业务架构，在范式理论上符合3NF。此建模方法，对建模人员的能力要求非常高。

Data Vault模型

DataVault由Hub（关键核心业务实体）、Link（关系）、Satellite（实体属性）三部分组成，是Dan Linstedt发起创建的一种模型方法论，它是在ER关系模型上的衍生，同时设计的出发点也是为了实现数据的整合，并非为数据决策分析直接使用。

Anchor模型

高度可扩展的模型，所有的扩展只是添加而不是修改，因此它将模型规范到6NF，基本变成了K-V结构模型。企业很少使用。

建模工具

建模工具，一般企业以Erwin、powerdesigner、visio，甚至Excel等为主。也有些企业自行研发工具，或使用阿里等成熟套装组件产品。

ETL

ETL，是英文 Extract-Transform-Load 的缩写，用来描述将数据从来源端经过抽取(extract)、转换(transform)、加载(load)至目的端的过程。

☞ ETL同步之道 [ Sqoop、DataX、Kettle、Canal、StreamSets ]

☞ ETL之技术栈 [ 重工具 vs 开发语言 ]

☞ ETL加载策略 [ Merge、Delta、拉链 ]

数据同步

Sqoop

Sqoop，SQL-to-Hadoop 即 “SQL到Hadoop和Hadoop到SQL”。

是Apache开源的一款在Hadoop和关系数据库服务器之间传输数据的工具。主要用于在Hadoop与关系型数据库之间进行数据转移，可以将一个关系型数据库（MySQL ,Oracle等）中的数据导入到Hadoop的HDFS中，也可以将HDFS的数据导出到关系型数据库中。

sqoop命令的本质是转化为MapReduce程序。sqoop分为导入（import）和导出（export），策略分为table和query，模式分为增量和全量。

命令行示例：

sqoop import
--connect jdbc:mysql://172.xxx.xxx.xxx:3306/db
--username uxxx
--password pxxx
--table txxx
--columns "id,name,desc,code,value"
-m 2
--warehouse-dir /user/hive/warehouse/ods.db
--hive-import --hive-overwrit
--hive-table ods.ods_risk_syscode
--field-terminated-by '\t'

DataX

sqoop命令的本质是转化为MapReduce程序。sqoop分为导入（import）和导出（export），策略分为table和query，模式分为增量和全量。

DataX本身作为离线数据同步框架，采用Framework + plugin架构构建。将数据源读取和写入抽象成为Reader+Writer插件，纳入到整个同步框架中。

datax使用示例，核心就是编写json配置文件job：

{
    "setting":{},
    "job":{
        "setting":{
            "speed":{
                "concurrent": 2,
                "throttle": false
            },
            "errorLimit": {
                "record": 0
            }
        }
    },
    "contend":[
        {
            "reader":{},
            "writer":{}
        }
    ]
}

Kettle

Kettle，中文名：水壶，是一款国外免费开源的、可视化的、功能强大的ETL工具，纯java编写，可以在Windows、Linux、Unix上运行，数据抽取高效稳定。

Kettle家族目前包括4个产品：Spoon、Pan、CHEF、Kitchen。

Kettle的最大特点：

免费开源：基于Java免费开源软件
易配置：可跨平台，绿色无需安装
不同数据库：ETL工具集，可管理不同数据库的数据
两种脚本文件：transformation和job，transformation完成针对数据的基础转换，job则完成整个工作流的控制
图形界面设计：托拉拽，无需写代码
定时功能：在Job下的start模块，有一个定时功能，可以每日，每周等方式进行定时

canal

canal是阿里巴巴旗下的一款开源项目，纯Java开发。基于数据库增量日志解析，提供增量数据实时订阅和消费，目前主要支持了MySQL，也支持mariaDB。

很多大型的互联网项目生产环境中使用，包括阿里、美团等都有广泛的应用，是一个非常成熟的数据库同步方案，基础的使用只需要进行简单的配置即可。

canal是通过模拟成为mysql 的slave的方式，监听mysql 的binlog日志来获取数据，binlog设置为row模式以后，不仅能获取到执行的每一个增删改的脚本，同时还能获取到修改前和修改后的数据，基于这个特性，canal就能高性能的获取到mysql数据数据的变更。

StreamSets

Streamsets是一个大数据实时采集ETL工具，可以实现不写一行代码完成数据的采集和流转。通过拖拽式的可视化界面，实现数据管道(Pipelines)的设计和定时任务调度。

数据源支持MySQL、Oracle等结构化和半/非结构化，目标源支持HDFS、Hive、Hbase、Kudu、Solr、Elasticserach等。创建一个Pipelines管道需要配置数据源(Origins)、操作(Processors)、目的地(Destinations)三部分。

Streamsets的强大之处：

拖拽式可视化界面操作，No coding required 可实现不写一行代码
强大整合力，100+ Ready-to-Use Origins and Destinations，支持100+数据源和目标源
可视化内置调度监控，实时观测数据流和数据质量

ETL技术栈

工具

重工具，kettle、DataStage、Informatica 三大工具依旧牢牢稳固传统数仓三大主力位置。kettle与时俱进，在大数据数仓，如一些互联网公司也有在使用kettle。

开发语言

开发语言，传统数仓一般SQL/Shell为主，互联网数仓又对Python、Java、Scala提出了新的要求。

不管是传统数仓，还是基于Hadoop生态的构建的(hive、spark、flink)数仓，SQL虽然戏码在下降，但依然是重头戏。强大的存储过程，更是屹立不倒，这么多年都在熠熠生辉。

在大数据生态，不管哪种数据处理框架，总有一天都会孵化出强大SQL的支持。如Hive SQL，Spark SQL，Blink SQL 等。

对于SQL，基本技能也是必备技能。

各种join、嵌套/标量子查询，强大的分析/窗口函数，变化无穷的正则表达式，层次查询，扩展分组，MODEL，递归with，多维分析，排列组合，行列互转，json解析，执行计划，四大类型(dql、dml、ddl、dcl)等。

SQLjoin

left/rignt/full join，每一个join都是暗藏韵理，on和where也不容小觑。

分析函数

简捷高效，4类30+个分析/窗口函数。

聚合分析函数

SUM     -- 该函数计算组中表达式的累积和
COUNT   -- 对一组内发生的事情进行累积计数
MIN     -- 在一个组中的数据窗口中查找表达式的最小值
MAX     -- 在一个组中的数据窗口中查找表达式的最大值
AVG     -- 用于计算一个组和数据窗口内表达式的平均值。

排名分析函数

ROW_NUMBER    -- 正常排序[1,2,3,4] -- 必须有order_by
RANK          -- 跳跃排序[1,2,2,4] -- 必须有order_by
DENSE_RANK    -- 密集排序[1,2,2,3] -- 必须有order_by
FIRST         -- 从DENSE_RANK返回的集合中取出排在最前面的一个值的行
LAST          -- 从DENSE_RANK返回的集合中取出排在最后面的一个值的行
FIRST_VALUE   -- 返回组中数据窗口的第一个值
LAST_VALUE    -- 返回组中数据窗口的最后一个值。

数学分析函数

STDDEV    		-- 计算当前行关于组的标准偏离
STDDEV_POP		-- 该函数计算总体标准偏离，并返回总体变量的平方根
STDDEV_SAMP		-- 该函数计算累积样本标准偏离，并返回总体变量的平方根
VAR_POP    		-- 该函数返回非空集合的总体变量（忽略null）
VAR_SAMP   		-- 该函数返回非空集合的样本变量（忽略null）
VARIANCE   		-- 如果表达式中行数为1，则返回0，如果表达式中行数大于1，则返回VAR_SAMP
COVAR_POP  		-- 返回一对表达式的总体协方差
COVAR_SAMP 		-- 返回一对表达式的样本协方差
CORR     		-- 返回一对表达式的相关系数
CUME_DIST  		-- 计算一行在组中的相对位置
NTILE     		-- 将一个组分为"表达式"的散列表示（类于Hive的分桶原理）
PERCENT_RANK 	-- 和CUME_DIST（累积分配）函数类似
PERCENTILE_DISC -- 返回一个与输入的分布百分比值相对应的数据值
PERCENTILE_CONT -- 返回一个与输入的分布百分比值相对应的数据值
RATIO_TO_REPORT -- 该函数计算expression/(sum(expression))的值，它给出相对于总数的百分比
REGR_ (Linear Regression) Functions -- 这些线性回归函数适合最小二乘法回归线，有9个不同的回归函数可使用

行比较分析函数

-- 可以访问结果集中的其它行而不用进行自连接
LAG		-- LAG可以访问组中当前行之前的行
LEAD    -- LEAD与LAG相反，LEAD可以访问组中当前行之后的行

ETL加载策略

数据集成加载策略，按类型可包括快照、流水、增量、全量、拉链等。

增量

有些表巨大，需要选择增量策略，新增delta数据需要和存量数据merge合并。

Merge方式一

在传统的数据整合方案中，合并技术大多采用merge方式（update+insert）；当前流行的大数据平台基本都不支持update操作，推荐的方式是全外连接（full outer join）+ 数据全量覆盖重新加载（insert overwrite），即如日调度，则讲当天的增量数据和前一天的全量数据做全外连接，重新加载最新的全量数据。在大数据量规模下，全量更新的性能比update要高得多。如果担心数据更新错误问题，可以采用分区方式，每天保持一个最新的全量版本，保留较短的时间周期（如3~7天）。

Merge方式二

（1）只有新增数据

（2）新增+删除

全量

每天一个全量表，也可一个分区一个全量。

拉链

拉链表，记录数据生命周期，记录一条数据生命周期的开始和结束。

在设计拉链表的时候不仅要有开始时间和结束时间，最好再加一个生命状态字段，如chain_status：有效 active、失效 expired、历史 history。

全量拉链，或许会存在性能问题，故建议根据实际业务场景中进行取舍，可只和最近一个时间周期(eg:1个月)的进行拉链处理。

BI

BI（Business Intelligence）。

可视化BI工具

OLAP

概念

OLAP(OnLine Analytical Processing)，即联机分析处理。OLAP对业务数据执行多维分析，并提供复杂计算，趋势分析和复杂数据建模的能力。它主要用于支持企业决策管理分析，是许多商务智能（BI）应用程序背后的技术。OLAP使最终用户可以对多个维度的数据进行即席分析，从而获取他们所需知识，以便更好地制定决策。OLAP技术已被定义为实现“快速访问共享的多维信息”的能力。

核心概念

维度(Dimension)：维度是描述与业务主题相关的一组属性，单个属性或属性集合可以构成一个维。如时间、地理位置、年龄和性别等都是维度。

维的层次（Level of Dimension）：一个维往往可以具有多个层次，例如时间维度分为年、季度、月和日等层次，地区维可以是国家、地区、省、市等层次。这里的层次表示数据细化程度，对应概念分层。后面介绍的上卷操作就是由低层概念映射到高层概念。概念分层除了可以根据概念的全序和偏序关系确定外，还可以通过对数据进行离散化和分组实现。

维的成员(Member of Dimension)：若维是多层次的，则不同的层次的取值构成一个维成员。部分维层次同样可以构成维成员，例如“某年某季度”、“某季某月”等都可以是时间维的成员。

度量(Measure)：表示事实在某一个维成员上的取值。例如开发部门汉族男性有39人，就表示在部门、民族、性别三个维度上，企业人数的事实度量。

基本操作

OLAP的操作是以查询——也就是数据库的SELECT操作为主，但是查询可以很复杂，比如基于关系数据库的查询可以多表关联，可以使用COUNT、SUM、AVG等聚合函数。OLAP正是基于多维模型定义了一些常见的面向分析的操作类型是这些操作显得更加直观。

OLAP的多维分析操作包括：钻取（Drill-down）、上卷（Roll-up）、切片（Slice）、切块（Dice）以及旋转（Pivot），下面还是以数据立方体为例来逐一解释下：

钻取（Drill-down）：在维的不同层次间的变化，从上层降到下一层，或者说是将汇总数据拆分到更细节的数据，比如通过对2010年第二季度的总销售数据进行钻取来查看2010年第二季度4、5、6每个月的消费数据，如上图；当然也可以钻取浙江省来查看杭州市、宁波市、温州市……这些城市的销售数据。

上卷（Roll-up）：钻取的逆操作，即从细粒度数据向高层的聚合，如将江苏省、上海市和浙江省的销售数据进行汇总来查看江浙沪地区的销售数据，如上图。

切片（Slice）：选择维中特定的值进行分析，比如只选择电子产品的销售数据，或者2010年第二季度的数据。

切块（Dice）：选择维中特定区间的数据或者某批特定值进行分析，比如选择2010年第一季度到2010年第二季度的销售数据，或者是电子产品和日用品的销售数据。

旋转（Pivot）：即维的位置的互换，就像是二维表的行列转换，如图中通过旋转实现产品维和地域维的互换。

OLAP的分类

按数据存储方式分类，可分为MOLAP、ROLAP、HOLAP。

Multidimensional OLAP （MOLAP）

MOLAP是OLAP的经典形式。MOLAP将数据存储在优化的多维数组中，而不是关系数据库中。维的属性值被映射成多维数组的下标值或下标的范围，而度量数据作为多维数组的值存储在数组的单元中。

一些MOLAP工具要求对数据进行预计算和存储，这样的MOLAP工具通常利用被称为“数据立方体”的预先计算的数据集。数据立方体包含给定范围的问题的所有可能答案。因此，它们对查询的响应非常快。另一方面，根据预计算的程度，更新可能需要很长时间。预计算也可能导致所谓的数据爆炸。

Relational OLAP（ROLAP）

ROLAP将分析用的多维数据存储在关系数据库中。这种方式依赖SQL语言实现传统OLAP的切片和切块功能，本质上，切片和切块等动作都等同于在SQL语句中添加“ WHERE”子句。ROLAP工具不使用预先计算的多维数据集，而是对标准关系数据库及其表进行查询，以获取回答问题所需的数据。ROLAP工具具有询问任何问题的能力，因为该方法（SQL）不仅限于多维数据集的内容。

尽管ROLAP使用关系数据库作为底层存储，但这些数据库一般要针对ROLAP进行相应优化，比如并行存储、并行查询、并行数据管理、基于成本的查询优化、位图索引、SQL的OLAP扩展（cube,rollup）等等。专为OLTP设计的数据库不能像ROLAP数据库一样正常工作。

由于MOLAP采用了新的存储结构，从物理层实现，因此又称为物理OLAP（PhysicalOLAP）；而 ROLAP主要通过一些软件工具或中间软件实现，物理层仍采用关系数据库的存储结构，因此称为虚拟OLAP（VirtualOLAP）。

Hybrid OLAP（HOLAP）

由于MOLAP和ROLAP有着各自的优点和缺点，且它们的结构迥然不同，这给分析人员设计OLAP结构提出了难题。为此一个新的OLAP 结构——混合型OLAP（HOLAP）被提出，这种工具通过允许同时使用多维数据库（MDDB）和关系数据库（RDBMS）作为数据存储来弥合这两种产品的技术差距。它允许模型设计者决定将哪些数据存储在MDDB中，哪些存储在RDBMS中，例如，将大量详单数据存储在关系表中，而预先计算的聚合数据存储在多维数据集中。目前整个行业对于“混合OLAP”的还没有达成明确的共识。

MOLAP与ROLAP对比

对比项	MOLAP	ROLAP
存储方式	转为OLAP设计和优化的存储，支持多维索引和缓存	沿用现有的关系数据库的技术
查询性能	具有较高的查询性能，响应速度快。	响应速度一般比MOLAP慢。
数据装载	数据装载速度慢。	加载速度通常比MOLAP加载要快得多。
维数限制	需要进行预计算，可能导致数据爆炸，维数有限制。	存储空间耗费小，维数没有限制。
访问接口	缺乏数据模型和数据访问的标准接口。	可以通过SQL实现详细数据与汇总数据的查询，并且可以由任何SQL报告工具访问。
冗余存储	MOLAP方法引入了数据冗余。	没有冗余数据。可与数据仓库共享同一份数据。
计算支撑	支持高性能的决策支持计算。	由于依赖数据库来执行计算，因此专用功能上有更多限制。
操作维护	维护困难。	管理简便。

OLAP与OLTP

两者设计的目标是完全不同的：

OLTP（On-Line Transaction Processing），联机事务处理，一般用于业务系统。OLTP对事务性处理的要求非常高，一般都是高可用的在线系统，主要基于传统的关系型数据库。其上的应用，一般以小的事务以及小的查询为主。评估其系统的时候，一般看其每秒执行的Transaction以及SQL的数量。在这样的系统中，单个数据库每秒处理的Transaction（增、删、改）往往达到几百上千个，Select查询语句的执行量每秒几千甚至几万个。典型的OLTP系统有电子商务系统、银行交易系统、证券交易系统等。
OLAP，一般用于分析系统。其上的应用，一般以大数据量的查询为主，修改和删除的操作较少。在这样的系统中，SQL语句的执行量不是考核指标，因为一条语句的执行时间可能会很长，读取的数据也非常多。所以，评估其系统的时候，往往是看系统的吞吐量、复杂查询响应时间、数据装载性能等。

OLAP与即席查询

Ad hoc是一个拉丁文常用短语，意思是“特设的、特定目的的（地）、临时的、专案的”。即席查询（Ad Hoc Queries）是指用户根据自己的需求动态创建的查询，与预定义查询相反。

即席查询对数据模型没有要求，只要能提供动态查询的能力即可；而OLAP系统，一般要求数据模型是多维数据模型。对于ROLAP系统，通常都能提供即席查询能力，二者之间差别很小，所以经常混用。

开源组件

开源大数据OLAP组件，可以分为MOLAP和ROLAP两类。ROLAP中又可细分为MPP数据库和SQL引擎两类。对于SQL引擎又可以再细分为基于MPP架构的SQL引擎和基于通用计算框架的SQL引擎。

MOLAP一般对数据存储有优化，并且进行部分预计算，因此查询性能最高。但通常对查询灵活性有限制。
MPP数据库是个完整的数据库，通常数据需要导入其中才能完成OLAP功能。MPP数据库在数据入库时对数据分布可以做优化，虽然入库效率有一定下降，但是对后期查询性能的提高有很大帮助。MPP数据库可以提供灵活的即席查询能力，但一般对查询数据量有一定限制，无法支撑特别大的数据量的查询。
SQL引擎只提供SQL执行的能力，本身一般不负责数据存储，通常可以对接多种数据储存，如HDFS、HBase、MySQL等。有的还支持联邦查询能力，可以对多个异构数据源进行联合分析。SQL引擎中，基于MPP架构的SQL引擎，一般对在线查询场景有特殊优化，所以端到端查询性能一般要高于基于通用计算框架的SQL引擎；但是在容错性和数据量方面又会逊于基于通用计算框架的SQL引擎。

总之，可以说没有一个OLAP系统能同时在处理规模，灵活性和性能这三个方面做到完美，用户需要基于自己的需求进行取舍和选型。