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

    OLAP 数据存储平台的选择及规划方案     【导读】本文介绍了列式存储和OLAP（联机分析），以及列式存储与OLAP的契合点，探讨了如何根据OLAP特点选择数据平台。 【关键字】OLAP 列式存储 过去的历史阶段，IT行业对于数据库的选择相对比较单元化，基于行式存储的关系型数据库基本一统江湖。因此OLTP & OLAP业务均以关系型数据库理论为基础来设计数据视图以及数据模型。随着数据量的爆发式发展，人们逐渐发现传统行式存储在处理特殊业务场景时候的不足，尤其是面对海量数据的处理性能问题。于是，过去曾不为人知的一些列式数据库逐渐走上历史舞台。而且在应用的过程当中，人们基于特殊的场景进行一版又一版的修改和优化，使得某些列式存储越来越适合今天的一些OLAP业务场景。今天我们就来分析分析这二者之间的内在缘由。 1. 列式存储的特点 说起列式存储或者列式数据库，大家可能最想知道它是何方妖魔？具有何种武艺？ 关于列式存储或者列式数据库，我们在专门的文章《NOSQL DB：Hbase 列式数据库七问》当中曾经以Hbase为例对其基本概念、数据结构、数据存取特点、底层存储结构、性能优势等方面进行过详细的介绍。当然列式存储还有很多种产品，比如Bigtable，Cassandra，Druid，Hypertable，MariaDB，ClickHouse。每一种产品虽然都具备列式存储的特点，但是在数据模型、存取特点、支持特性等各方面都各有千秋。本次文章当中，我们 仅从几个与OLAP业务类型相关的方面来分析。 1.1 海量数据的单维度处理与精准定位数据的多维度处理 首先，我们对比行式存储，其最大的区别就在于物理存储结构的不同，具体如下所示： 表1.1 二维数据表 ID Name Title 1 John Manager 2 William Engineer … … … 表1.2 行式存储物理存储格式 1 John Manager 2 William Engineer … … … 表1.3 列式存储物理存储格式 1 2 … John William … Manager Engineer … 以上表1.1 是我们要存储的逻辑数据，业务模型为一个二维关系表。表1.2 是以行式存储的模型存储在物理存储页或者块儿上。表1.3 是以列式存储的模型存储在物理存储页或者块儿上。从表1.2 和表1.3 的特点上我们明显可以看出列式存储是以列数据为一个一个的连续存储区域，而行式存储是以若干行数据为一个个的连续存储区域。如果我们将以上表的数量扩展到1 0 万条数据的规模，试想两个问题： Q1：如果我要查询Tile为Engineer的所有人？ Q2：如果我要统计Tile为Engineer的人数比例？ 对于Q1，如果是行式数据库，那么多半要按照全表扫描进入内存，然后按照TiTle字段筛选，取Name字段；如果是列式数据库，那么我只需要定位到TiTle字段起始页，读取前后两个列的数据块进入内存，然后进行筛选即可。数据量越大由于行式存储要牺牲掉的IO代价越高。 对于Q2，如果是行式数据库，那多半要按照全表扫描进入内存，然后按照TiTle字段排序，然后统计； 如果是列式数据库，那么我只需要定位到TiTle字段起始页，然后读取单列数据块进入内存，然后统计；对比发现这个操作节省的IO更是可观。 显然我们发现在Q1、Q 2 问题的解决上，列式存储要高效很多。我们知道所有的事物都是有利就有弊，假设换一个问题，那么效果如何呢，如Q 3 问题。 Q3 ：如果我要查询ID =99 的人的TiTle？ 对于这个问题，如果是列式数据库，那么需要根据索引定位到ID列的页表，按照偏移找到ID，然后再定位到TiTle列页表，按照偏移找到其对应的TiTle（如果字段所占空间为变长，那就更麻烦了）。如果是行式数据库，那么只需要根据索引定位到数据所在页表，然后顺序读取该行，那么所需数据就读到了。显然行式存储的处理的复杂度远远低于列式存储。 综上所述，在某些需要根据字段特点进行统计、排序、筛选的分析操作，列式存储的效率要比行式存储的效率高很多。数据量越大，这个优势越明显，到了单机资源无法处理的规模，这个优势就更加突出了。但是如果遇到需要精准定位到某一条数据，并且进行多字段处理的场景，列式存储就显得笨重很多。 1.2 数据压缩 在传统的关系型数据库当中，由于我们对现实世界数据的高度抽象，使得我们可以用少量的关系型数据来表示显示世界当中的各种实体对象之间的逻辑关系，那么数据压缩似乎并不那么重要。随着数据量的线性增加，尤其是互联网产生之后，现实世界当中出现了很多非二维表能够表述的海量数据，比如说媒体类数据、传感设备数据、网页类数据等等。一方面，数据量的线性增加带来了存储空间资源的线性扩张，另外一方面，在数据库当中对海量数据处理的时候会因为耗费大量的IO操作。在这两种情况下，重复数据的压缩技术就变得非常可观，无论从存储空间还是数据处理过程当中的IO效率方面都变得非常可观。 同样，我们还是拿表1.2&1.3 来看列式存储在这方面的特点： 表1.2 行式存储物理存储格式 1 John Manager 2 William Engineer … … … 表1.3 列式存储物理存储格式 1 2 … John William … Manager Engineer … 如上所示，无论是在二维表数据当中还是其他类数据当中，我们根据数据某一属性抽象出来的字段列当中，会产生大量的重复数据。比如说TiTle为Manager的数据在TiTle字段当中可能会有3 0% 的重复数据。再比如说存储媒体数据的数据库当中，不同时间维度统计的媒体内容字段可能会有9 9% 的重复数据。这个时候如果我们以列的方式来存储数据，那么不同数据条目在列的维度就会处在连续空间，为我们以极低的代价检索到重复数据提供了便利。同样我们去看第一部分当中的第2个问题： Q2 ：如果我要统计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 比较维度 OLTP 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等语句实现我们对整表或者整库数据的查询、分类分组