发布于：2019-10-18

文一明工程技术25 分钟读完 (大约 3749 个字) 0次访问

OLAP系统

前言

概述

OLAP 联机分析处理（OnLine Analytical Processing）。OLAP系统是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。

OLTP 联机事务处理（Online Transaction Processing）。OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。

发展背景

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

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

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

联机分析处理的概念最早由关系数据库之父E．F．Codd于1993年提出。Codd认为，联机事务处理已不能满足终端用户对数据库查询分析的要求，SQL对大容量数据库的简单查询也不能满足用户分析的需求。用户的决策分析需要对关系数据库进行大量的计算才能得到结果，而查询的结果并不能满足决策者提出的需求。因此，Codd提出了多维数据库和多维分析的概念，即OLAP。OLAP委员会对联机分析处理的定义为：使分析人员、管理人员或执行人员能够从多种角度对从原始数据中转化出来的、能够真正为用户所理解的、并真实反映企业维特性的信息进行快速、一致、交互的存取，从而获得对数据更深入了解的一类软件技术。

OLTP和OLAP

数据处理类型	OLTP	OLAP
基本定义	联机事物系统, 管理系统数据的修改	联机数据提取和数据分析系统
数据来源	OLTP系统操作数据	多个OLTP系统的历史数据
事物	频繁并且耗时短	不频繁并且耗时较长
面向对象	业务开发人员	分析决策人员
功能实现	日常事务处理	面向分析决策
数据模型	关系模型	多维模型
数据量	几条或几十条记录	千万上亿条记录
操作类型	查询、插入、更新、删除	查询为主

OLTP和OALP的关系
ETL

应用场景

产品报表，展示业务的经营情况
Adhoc查询

技术架构

基本概念

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

OLAP的多维分析操作包括：钻取（Drill-down）、上卷（Roll-up）、切片（Slice）、切块（Dice）以及旋转（Pivot）。

Cube
数据立方体只是多维模型的一个形象的说法。立方体其本身只有三维，但多维模型不仅限于三维模型，可以组合更多的维度，但一方面是出于更方便地解释和描述，同时也是给思维成像和想象的空间；另一方面是为了与传统关系型数据库的二维表区别开来，于是就有了数据立方体的叫法。

纬度
人们观察数据的特定角度，是考虑问题时的一类属性，属性集合构成一个维（时间维、地理维等）。

指标
多维数组的取值, 如浙江区域第一季度的完单量。

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

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

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

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

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

常用技术方案

开场先来一张图

OLAP常用架构图

OLAP系统的流程：

前端将数据查询的结果以可视化方式展现出来，借助图形化的手段，让我们更加容易的去探索数据，发现数据中有价值的信息
分析师或者业务人员通过拖拽指标维度确定组合，组成自己想看的结果，结果查询出来后可以用各种合适的数据可视化图表进行展示
SQL Parser将用户对数据的描述转化为SQL并进行查询
查询引擎负责选择合适的数据库来执行SQL并返回查询结果
OLTP系统的数据和原始的日志信息，经过清洗处理最后统一存储。

影响分析师或者业务人员体验的主要有以下两点。

数据可视化图表是否丰富
不同的图表展示的信息侧重点不一样，优秀的视觉效果和丰富的图表能让用户充分的表达出想要展示的信息。

响应时间是否满足预期
在不同的场景下对响应时间的要求是不一样的，例如业务报表是对业务一周或者一段时间业务数据的展示，被展示对象希望的是打开系统就能看到报表，这种情况下响应速度可能就需要在毫秒级；如果在报表在分析有个业务数据出现了异常，就需要查询大量的数据定位问题，这种情况下响应时间越快就越能帮助分析师及时的定位问题；上线一个新业务，数据分析师需要查询大量的数据来验证业务的效果，这种情况下数据分析师对响应时间的要求可能就没那么高。

OLAP引擎选型

OLAP需求大体分为两类:

即席查询：指用户通过手写SQL来完成一些临时的数据分析需求。这类需求的SQL形式多变、逻辑复杂，对响应时间没有严格的要求。

固化查询：指对一些固化下来的取数、看数的需求，通过数据产品的形式提供给用户，从而提高数据分析和运营的效率。这类需求的SQL有固定的模式，对响应时间有比较高的要求。

OLAP引擎的主要分类：

ROLAP (Relational OLAP)

基于RDBMS技术，通过并⾏化/内存加速计算
代表：Presto / SparkSQL / Clickhouse
优势
- ⽀持任意的SQL表达
- ⽆数据冗余和预处理
不⾜
- ⼤数据量、复杂查询下分钟级响应
- 不⽀持实时数据
适⽤场景
- 对灵活性⾮常⾼的即席查询场景

MOLAP (Multi-dimensional OLAP)

预先聚合明细数据，系统中只存储汇总数据
代表：Kylin / Druid
优势
- ⽀持超⼤原始数据集
- ⾼性能、⾼并发
不⾜
- 不⽀持明细数据查询
- 需要预先定义维度、指标
适⽤场景
- 对性能要求⾮常⾼的OLAP场景

Search Engines

基于搜索引擎技术，通过索引加速计算
代表：Elasticsearch / Solr
优势
- 强⼤的明细检索功能
- 同时⽀持实时与离线数据
不⾜
- ⼤数据量、复杂查询下分钟级响应
- 不⽀持Join、⼦查询等
适⽤场景
- 中⼩数据规模的简单OLAP分析的场景

目前还没有一个OLAP引擎能够满足各种场景的查询需求。其本质原因是，没有一个系统能同时在数据量、性能、和灵活性三个方面做到完美，每个系统在设计时都需要在这三者间做出取舍。在选择OLAP引擎的时候，也需要根据下图来分析当前的业务场景，以选择最合适的引擎。

以下是几种常用的OLAP引擎对比

网约车分析门户

项目背景

我们这次重构网约车分析门户的目的是优化分析门户的体验，配合数据分析师开发新的图表。

整体架构

之前的网约车分析门户的技术架构如下图：

之前的架构主要有以下问题：

Tableau图表不能自定义，不能完全满足数据分析师的需求
通过Hive查询速度过慢，在浏览器打开页面等待时间过长，甚至超时导致完全打不开页面

我们这次的重构，主要是以解决这两个问题为主，当前系统的架构：

Superset是Airbnb贡献给Apache的一个开源项目。当分析师有新增图表或者UI需求的时候，都可以基于superset进行定制化的开发。
Clickhouse是Yandex开源的一个数据分析的数据库，性能非常强悍，但是数据需要从hive表中导入。
Presto是一个基于hive的查询引擎，性能大约是hive的10倍，可以直接从hive表中读取数据。
Kylin是一个MOLAP类型的数据库，目前在项目中还没使用，之后会接入。

总结

本篇文章对OLAP系统主要从以下几点做了一个简单的概述:

发展背景
应用场景
常见的OLAP系统架构
OLAP分析引擎类型及如何选型

之后会对常用的OLAP引擎架构做一个介绍和对比。

参考资料

#OLAP