OLAP数据存储平台的选择及规划

【摘要】 ： 过去的历史阶段，IT行业对于数据库的选择相对比较单元化，基于行式存储的关系型数据库基本一统江湖。因此OLTP & OLAP业务均以关系型数据库理论为基础来设计数据视图以及数据模型。随着数据量的爆发式发展，人们逐渐发现传统行式存储在处理特殊业务场景时候的不足，尤其是面对海量数据的处理性能问题。于是，过去曾不为人知的一些列式数据库逐渐走上历史舞台。而且在应用的过程当中，人们基于特殊的场景进行一版又一版的修改和优化，使得某些列式存储越来越适合今天的一些OLAP业务场景。今天我们就来分析分析这二者之间的内在缘由。

【关键字】 ： OLAP 、列式存储

## 1. 列式存储的特点

说起列式存储或者列式数据库，大家可能最想知道它是何方妖魔？具有何种武艺？

关于列式存储或者列式数据库，我们在专门的文章《NOSQL DB：Hbase 列式数据库七问》当中曾经以Hbase为例对其基本概念、数据结构、数据存取特点、底层存储结构、性能优势等方面进行过详细的介绍。当然列式存储还有很多种产品，比如Bigtable，Cassandra，Druid，Hypertable，MariaDB，ClickHouse。每一种产品虽然都具备列式存储的特点，但是在数据模型、存取特点、支持特性等各方面都各有千秋。本次文章当中，我们 仅从几个与OLAP业务类型相关的方面来分析。

1.1海量数据的单维度处理与精准定位数据的多维度处理。

首先，我们对比行式存储，其最大的区别就在于物理存储结构的不同，具体如下所示：

表1 .1 二维数据表

表1 .2 行式存储物理存储格式

表1 .3 列式存储物理存储格式

以上表1 .1 是我们要存储的逻辑数据，业务模型为一个二维关系表。表1 .2 是以行式存储的模型存储在物理存储页或者块儿上。表1 .3 是以列式存储的模型存储在物理存储页或者块儿上。从表1 .2 和表1 .3 的特点上我们明显可以看出列式存储是以列数据为一个一个的连续存储区域，而行式存储是以若干行数据为一个个的连续存储区域。如果我们将以上表的数量扩展到1 0 万条数据的规模，试想两个问题：

Q 1 ：如果我要查询Tile为Engineer的所有人？

Q 2 ：如果我要统计Tile为Engineer的人数比例？

对于Q 1 ，如果是行式数据库，那么多半要按照全表扫描进入内存，然后按照TiTle字段筛选，取Name字段；如果是列式数据库，那么我只需要定位到TiTle字段起始页，读取前后两个列的数据块进入内存，然后进行筛选即可。数据量越大由于行式存储要牺牲掉的IO代价越高。

对于Q 2 ，如果是行式数据库，那多半要按照全表扫描进入内存，然后按照TiTle字段排序，然后统计；

如果是列式数据库，那么我只需要定位到TiTle字段起始页，然后读取单列数据块进入内存，然后统计；对比发现这个操作节省的IO更是可观。

显然我们发现在Q1、Q 2 问题的解决上，列式存储要高效很多。我们知道所有的事物都是有利就有弊，假设换一个问题，那么效果如何呢，如Q 3 问题。

Q 3 ：如果我要查询ID =99 的人的TiTle？

对于这个问题，如果是列式数据库，那么需要根据索引定位到ID列的页表，按照偏移找到ID，然后再定位到TiTle列页表，按照偏移找到其对应的TiTle（如果字段所占空间为变长，那就更麻烦了）。如果是行式数据库，那么只需要根据索引定位到数据所在页表，然后顺序读取该行，那么所需数据就读到了。显然行式存储的处理的复杂度远远低于列式存储。

综上所述，在某些需要根据字段特点进行统计、排序、筛选的分析操作，列式存储的效率要比行式存储的效率高很多。数据量越大，这个优势越明显，到了单机资源无法处理的规模，这个优势就更加突出了。但是如果遇到需要精准定位到某一条数据，并且进行多字段处理的场景，列式存储就显得笨重很多。

1.2数据压缩。

在传统的关系型数据库当中，由于我们对现实世界数据的高度抽象，使得我们可以用少量的关系型数据来表示显示世界当中的各种实体对象之间的逻辑关系，那么数据压缩似乎并不那么重要。随着数据量的线性增加，尤其是互联网产生之后，现实世界当中出现了很多非二维表能够表述的海量数据，比如说媒体类数据、传感设备数据、网页类数据等等。一方面，数据量的线性增加带来了存储空间资源的线性扩张，另外一方面，在数据库当中对海量数据处理的时候会因为耗费大量的IO操作。在这两种情况下，重复数据的压缩技术就变得非常可观，无论从存储空间还是数据处理过程当中的IO效率方面都变得非常可观。

同样，我们还是拿表1 .2&1.3 来看列式存储在这方面的特点：

表1 .2 行式存储物理存储格式

表1 .3 列式存储物理存储格式

如上所示，无论是在二维表数据当中还是其他类数据当中，我们根据数据某一属性抽象出来的字段列当中，会产生大量的重复数据。比如说TiTle为Manager的数据在TiTle字段当中可能会有3 0% 的重复数据。再比如说存储媒体数据的数据库当中，不同时间维度统计的媒体内容字段可能会有9 9% 的重复数据。这个时候如果我们以列的方式来存储数据，那么不同数据条目在列的维度就会处在连续空间，为我们以极低的代价检索到重复数据提供了便利。同样我们去看第一部分当中的第2个问题：

Q 2 ：如果我要统计Tile为Engineer的人数比例？

相对于没有压缩的列式存储结构，我们会得到以下三点益处：

Ø 数据库存储的实际数据少了，原来需要1 0 T的空间，现在可能只需要 5 T（取决于数据重复率）。

Ø 从存储扫描到内存的数据变少了，IO效率提高了。

Ø 统计效率提高了，原来通过扫描所有重复数据才能完成的统计只需读取压缩后的头信息即可。

1.3数据关联约束与分布式处理。

因该说当我们谈及关系数据库的时候，无论是OLAP还是OLTP都会涉及到数据一致性的问题，典型的场景就是外键关联的场景。当我们对其中一张表的数据进行更改的时候，如果它有相关的外键约束或者关联约束，那么必然会涉及数据库对数据一致性的检查及处理。这会带来两个问题：

1. 数据处理效率的问题，关联约束的检查及关联操作必然带来多余的操作代价。
2. 数据处理过度依赖单节点资源，无法实现分布式处理。既然我们要顾及数据之间的横向联系，那么必然导致数据无法切分，Sharding就无从谈起，分布式处理也无法保障关联约束。

而列式数据库一般的原则是要抛弃数据之间的外键关联约束，希望将数据切分为相互之间独立的数据表。这样的优势在于很多方面，首先我们可以对数据进行Sharding，无论是通过哈希算法还是通过其他算法，数据更容易切片交由不同节点分布式处理。其次，当我们对数据进行批量的插入、删除、更新的时候，我们无需付出不可估量的关联性代价。或许在数据量可观的情况下，这个优势不会被人过于关注。但是一旦当数据量的处理超过单节点资源能够完成的边界，我们唯一可以选择的就是列式存储，甚至我们不惜花费大量的开发代价去改变业务逻辑使之前下沉到数据库的关联性约束上浮到业务控制层面。

2. OLAP（联机分析）

对于 OLAP这个概念来讲，接触过数据库的人都会非常熟悉 。联机分析（OLAP）是由关系数据库之父E.F.Codd于1993年提出的一种数据动态分析模型，它允许以一种称为多维数据集的多维结构访问来自商业数据源的经过聚合和组织整理的数据。 这是一个相对抽象的概念，那么从实际应用的角度，其实我们可以从以下几个方面来看什么是 OLAP。

2.1动态多维度数据分析

我们在平时工作中，会遇到各种问题，在分析问题的时候，同样的现象，我们会从多个角度去分析考虑，并且有时候我们还会从几个角度综合起来进行分析。这就是OLAP分析最基本的概念：从多个观察角度的灵活组合来观察数据，从而发现数据内在规律。

OLAP将数据分为两种特征，一种为表现特征，比如一个销售分析模型中的销售额、毛利等 ，我们称之为度量数据 ；还有一种为角度特征，比如销售分析中的时间周期、产品类型、销售模式、销售区域等。OLAP术语称之为“维数据”。

1. 维(Dimension)：人们观察事物的视角，如时间、地理位置、年龄和性别等，是单角度概念。
2. 度量(Measure)：表示在这个维成员上的取值。

以上是在 OLAP场景当中我们需要用到数据的特征， 那么根据数据的不同维和度去对数据进行加工和分析就是我们 OLAP的核心任务了，如图2.1-2.6所示 。

图 2.1 原始数据模型

图 2.2 数据加工 操作

1. 数据转区(Drill down)：维度是有层次的，下探表示进入维度的下一层，将汇总数据拆分到下一层所在细节数据信息，如图从第二季度下探到看4、5、6月的明细数据。
2. 数据上卷(Drill up)： 下探的反向操作，回到更高汇聚层的汇总数据，如图上卷到季度汇总。
3. 数据切片(Slice)：切片可以理解成把立体按某一个维度进行切分，就可以看两维数据，如图中按电子产品切分，看到的是时间和地理位置关系的二维数据。
4. 数据切块(Dice)：相对于切片是按一个点切分，切块就是按一个范围(区间)来做切分。
5. 数据旋转(Pivot)：维的行列位置交换，换一个视角分析数据。

2.2数据库操作

从 2.1当中 ，我们基本可以看出 OLAP场景当中对业务数据的几种常见操作，回到最基本的操作上就是对数据的拆分汇总，然后观察出其中的业务规律 。 那么这样的一些数据处理特征对应到数据库的操作是什么呢？对于这个问题，我们通过对比 OLTP业务场景来看，具体如表2.1。

表2.1 OLAP & OLTP

从以上表当中，我们可以看到了不同维度上， OLAP与OLTP在数据库操作方面的区别，总结分析来看，我们认为OLAP会在以下几点有特殊的要求：

1. 数据处理量的质变。也就是说我们处理的数据量必须是巨大的并远远超出普通查询任务。
2. 数据处理的类型要以查询为基础的筛选、分类分组、拆分聚合、汇总统计绝对占比（>90%）。
3. 数据之间的完整性约束是很少或者基本不考虑。不需要数据关联以及外键约束。

3. 列式存储与OLAP的契合点

通过 1、2两部分的介绍，我们了解了列式存储的特点，也了解了OLAP业务的特点。那么试想 如果用 OLTP的关系型数据库去运行OLAP，会发生什么样的问题？

首先、在业务初始，我们感觉不到瓶颈的所在，因为以G为单位的数据量，在普通的Oracle、MySQL、DB2数据库当中，我们很轻松可以通过SQL当中的Select * from、Order By、Group By等语句实现我们对整表或者整库数据的查询、分类分组、拆分聚合以及统计等操作，尽管时间可能会稍微多一些。

接着、当运行一段时间之后，我们发现当数据量到达一定程度之后，原来几分钟的操作现在可能需要几个小时，于是我们开始优化索引、优化表结构、优化数据库参数使得其更符合OLAP的处理特点，尽量减少不必要的全表扫描和重复的无效操作，尽量将缓存换入换出的算法优化到更适合OLAP的特点，勉强我们可以将效率提升到几十分钟。

最后、当运行到一定阶段之后，我们发现数据库跑不动了，原来可以完成的任务居然把数据库跑Hung了。这个时候无论我们如何去优化数据库都无济于事了。为什么呢，因为随着数据量的增加，底层消耗的IO、消耗的内存、消耗的CPU时间已经超过了单机资源的限度了。

这个时候，我们不得不考虑一种新的，更适合OLAP业务的数据库的应用了，于是各种列式存储、大数据平台等等应用而生。从整个发展的过程来讲，这似乎是信息大爆炸导致的一种历史必然性，那么这种必然性一定会尤其本质上的关联性。这就是二者之间的契合点。

3.1列式存储的存储方式与批量查询之间的契合

列式存储最大的特点之一在于其数据的组织方式是以列为连续区域存储数据的。不难想象数据库在扫描物理数据的时候，面对海量数据场景，一次连续的扫描能够得到所需的大部分数据无疑是数据库的妙手回春；而OLAP恰恰是针对数据的维和度来进行数据检索的，所谓的维就是表中的字段（列）。这样的事情，在以行为组织方式的行式存储当中，无疑是一种奢望，多少次跳跃的扫描才能达到人家一次扫描所得的维（列）。

3.2列式存储的数据消重与IO效率的契合

列式存储最大特点之二在于其数据压缩的优势，因为按照现实世界的特点来看，大部分重复数据在于某一个维（列）上，那么这就给了列式存储消重最大的优势。在一片连续的物理存储空间上处理一些重复数据，总比在杂乱无序的物理存储空间上处理一些随机的重复数据要提高很多效率。这个效率的提高带来的是CPU、内存、磁盘等各个资源的代价减少。

另外一方面，当我们要对数据的维和度进行具体的OLAP分析的时候，我们需要把大量的数据读入到内存进行深度的处理，比如排序、分类、分组、筛选、统计等等。从物理存储读入数据到内存本身的效率是非常可观的，在内存当中处理少量的数据要比处理带有重复数据的大量数据要效率的多。很多事情就是因为这不同环节上的少量提高而发生了整体上的指数级别的改变，将不可能变成可能。或许我们可以通过微观和宏观的理论来解释其中的细节。

3.3分布式架构与忽略数据完整性的契合

列式存储最大特点之二在于其分布式架构的利用。或许我们可以说这个是通过牺牲了数据的完整性约束来换取的，如果业务本身没有这种需求，我们丢掉这个特性换取更伟大的特性“分布式”，又有何妨呢？很多人可能会抬出CAP理论来讲，没错我们承认CAP理论的正确性，但是在OLAP业务场景当中，我们看到的更多的是数据宏观维度的抽象属性，是基于大量数据的同纬同度分析之后的价值，而不在于单个数据之间的严格约束，所以这一点可以放弃，因为我们换来的是可以解决海量数据场景下的架构变革。

4. 如何根据OLAP特点选择数据平台

在第 2部分的时候，我们谈及了OLAP的一些业务特性以及数据库操作方面的特性 。 实际上 OLAP本身根据业务场景的差异，还会有进一步的细分，业界通常将其分为MOLAP(Multi-dimensional)、ROLAP（Relational）、HybridOLAP。

MOLAP（Multi-dimensional） ：以多维数组（Multi-dimensional Array）存储模型的OLAP，是OLAP发源最初的形态，某些方面也等同于OLAP。它的特点是数据需要预计算（pre-computaion），然后把预计算之后的结果（cube）存在多维数组里。

ROLAP（Relational）：基于关系模型存放数据，一般要求事实表（fact table）和维度表（dimensition table）按一定关系设计，它不需要预计算，使用标准SQL就可以根据需要即时查询不同维度数据。

HybridOLAP：介于MOLAP&ROLAP之间。

可以看到，以上的划分方法是基于数据模型的不同做的细分。本文不打算从以上概念上进行剖析，而是打算从业务特点方面做一些剖析。OLAP无论是哪种类型，其实最终的业务目的就在于“分析”二字。为了达到这个目的，必须做如下分析：

首先，业务数据的特征。健值？关系模型？数组模型？图谱模型？不同的数据类型决定了数据库选型上的根本差异。比如说我们的数据99%是健值数据（微博、媒体、网页、...），那么我们首选的应该是符合健值存储特征的列式数据库，比如Hbase；如果我们的数据99%都是关系型数据（金融反洗钱、监管报送、财务报表、商品智能分析、...），那么我们还最好选择能支持数仓类的关系数据库，或者能够支持SQL的列式数据库。

其次，我们要看数据操作的特征。数据处理过程复杂类型？还是查询过程复杂类型？数据查询在局部数据范围的集中程度？数据操作和查询之间的关联程度？如果是数据处理过程本身复杂，那么我们是否考虑要在中间加一个中台，利用合适的工具将数据进行首次的预处理；如果是查询过程复杂，数据关联性很强，那么除了具备列式特点，能同时支持SQL，那是最好不过，例如ClickHouse。如果在处理过程当中，数据不能集中在某一个范围，而多数情况是对全量数据的处理，那么在磁盘与内存之间的IO效率就显得尤为重要，这个时候我们不妨去研究研究能够有很好压缩去重特性的列式数据库。

当然，以上是从宏观的思路来谈我们如何根据OLAP的业务特点去考虑数据存储平台。在实际应用过程当中，需要从更细节的过程来考虑平台的选择以及平台的优化和改造。将不必要的瓶颈问题上浮到应用层面来解决。总而言之，这是一个既需要宏观指导又需要细节研究的事情。

5. 总结展望

通过对列式存储平台的特性分析以及对联机分析类业务特性的分析 ， 我们认为相比较行式存储而言，列式存储与 OLAP更具有契合度 。当然，这种契合度只是从某几个关键因素来分析得出的结论，具体实践过程当中，规划一个数据存储平台所涉及的因素远远不止这几个，这就需要我们做规划的人可以把握大局观去选择合适的平台，同时可以根据局部的非关键因素的优化改造，最终使得我们的规划选择合格合理。本文的分享为个人点滴所想，难免有偏之处，也希望更多同业能从不同维度分析讨论。