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

《OLAP数据存储平台的选择及规划方案.docx》由会员分享，可在线阅读，更多相关《OLAP数据存储平台的选择及规划方案.docx（17页珍藏版）》请在第一文库网上搜索。

1、O1AP数据存储平台的选择及规划方案【导读】本文介绍了列式存储和O1AP（联机分析），以及列式存储与O1AP的契合点，探讨了如何根据O1AP特点选择数据平台。【关键字】O1AP列式存储过去的历史阶段，IT行业对于数据库的选择相对比较单元化，基于行式存储的关系型数据库基本一统江湖。因此O1TP&O1AP业务均以关系型数据库理论为基础来设计数据视图以及数据模型。随着数据量的爆发式发展，人们逐渐发现传统行式存储在处理特殊业务场景时候的不足，尤其是面对海量数据的处理性能问题。于是，过去曾不为人知的一些列式数据库逐渐走上历史舞台。而且在应用的过程当中，人们基于特殊的场景进行一版又一版的修改和优化，使得某

2、些列式存储越来越适合今天的一些O1AP业务场景。今天我们就来分析分析这二者之间的内在缘由。1 .列式存储的特点说起列式存储或者列式数据库，大家可能最想知道它是何方妖魔？具有何种武艺？关于列式存储或者列式数据库，我们在专门的文章NOSQ1DB:Hbase列式数据库七问当中曾经以HbaSe为例对其基本概念、数据结构、数据存取特点、底层存储结构、性能优势等方面进行过详细的介绍。当然列式存储还有很多种产品，比如Bigtab1e,Cassandra,Druid,IIypertab1e,MariaDB,C1ickHouseo每一种产品虽然都具备列式存储的特点，但是在数据模型、存取特点、支持特性等各方面都各

3、有千秋。本次文章当中，我们仅从几个与O1AP业务类型相关的方面来分析。1.1 海量数据的单维度处理与精准定位数据的多维度处理首先，我们对比行式存储，其最大的区别就在于物理存储结构的不同，具体如下所示：表1.1二维数据表IDNameTit1e1JohnManager2Wi11iamEngineer表1.2行式存储物理存储格式1JohnManag2Wi11iEnginerameer表1.3列式存储物理存储格式12JohnWi11iManagEnginamereer以上表1I是我们要存储的逻辑数据，业务模型为一个二维关系表。表12是以行式存储的模型存储在物理存储页或者块儿上。表1.3是以列式存储的模

4、型存储在物理存储页或者块儿上。从表1.2和表1.3的特点上我们明显可以看出列式存储是以列数据为一个一个的连续存储区域，而行式存储是以若干行数据为一个个的连续存储区域。如果我们将以上表的数量扩展到10万条数据的规模，试想两个问题：Q1:如果我要查询Ti1e为Engineer的所有人？Q2：如果我要统计Ti1e为Engineer的人数比例？对于Q1,如果是行式数据库，那么多半要按照全表扫描进入内存，然后按照TiTIe字段筛选，取Name字段；如果是列式数据库，那么我只需要定位到TiTIe字段起始页，读取前后两个列的数据块进入内存，然后进行筛选即可。数据量越大由于行式存储要牺牲掉的IO代价越高。对于

5、Q2,如果是行式数据库，那多半要按照全表扫描进入内存，然后按照TiTIe字段排序,然后统计;如果是列式数据库，那么我只需要定位到TiTIe字段起始页，然后读取单列数据块进入内存，然后统计；对比发现这个操作节省的IO更是可观。显然我们发现在Q1Q2问题的解决上，列式存储要高效很多。我们知道所有的事物都是有利就有弊，假设换一个问题，那么效果如何呢，如Q3问题。Q3：如果我要查询ID=99的人的TiTIe?对于这个问题，如果是列式数据库，那么需要根据索引定位到ID列的页表，按照偏移找到ID,然后再定位到TiTIe列页表，按照偏移找到其对应的TiT1e（如果字段所占空间为变长，那就更麻烦了）。如果是行

6、式数据库，那么只需要根据索引定位到数据所在页表，然后顺序读取该行，那么所需数据就读到To显然行式存储的处理的复杂度远远低于列式存储。综上所述，在某些需要根据字段特点进行统计、排序、筛选的分析操作，列式存储的效率要比行式存储的效率高很多。数据量越大，这个优势越明显，到了单机资源无法处理的规模，这个优势就更加突出了。但是如果遇到需要精准定位到某一条数据，并且进行多字段处理的场景，列式存储就显得笨重很多。1.2数据压缩在传统的关系型数据库当中，由于我们对现实世界数据的高度抽象，使得我们可以用少量的关系型数据来表示显示世界当中的各种实体对象之间的逻辑关系，那么数据压缩似乎并不那么重要。随着数据量的线性

7、增加，尤其是互联网产生之后，现实世界当中出现了很多非二维表能够表述的海量数据，比如说媒体类数据、传感设备数据、网页类数据等等。一方面，数据量的线性增加带来了存储空间资源的线性扩张，另外一方面，在数据库当中对海量数据处理的时候会因为耗费大量的IO操作。在这两种情况下，重复数据的压缩技术就变得非常可观，无论从存储空间还是数据处理过程当中的IO效率方面都变得非常可观。同样，我们还是拿表12&13来看列式存储在这方面的特点：表1.2行式存储物理存储格式1JohnManag2Wi11iEnginerameer表13列式存储物理存储格式12JohnWi11iManagEnginamereer如上所示，无论

8、是在二维表数据当中还是其他类数据当中，我们根据数据某一属性抽象出来的字段列当中，会产生大量的重复数据。比如说TiT1e为Manager的数据在TiT1e字段当中可能会有30%的重复数据。再比如说存储媒体数据的数据库当中，不同时间维度统计的媒体内容字段可能会有99%的重复数据。这个时候如果我们以列的方式来存储数据，那么不同数据条目在列的维度就会处在连续空间，为我们以极低的代价检索到重复数据提供了便利。同样我们去看第一部分当中的第2个问题：Q2：如果我要统计TiIe为Engineer的人数比例？相对于没有压缩的列式存储结构，我们会得到以下三点益处: 数据库存储的实际数据少了，原来需要IoT的空间，

9、现在可能只需要5T（取决于数据重复率）。 从存储扫描到内存的数据变少了，IO效率提高了。 统计效率提高了，原来通过扫描所有重复数据才能完成的统计只需读取压缩后的头信息即可。1.3数据关联约束与分布式处理因该说当我们谈及关系数据库的时候，无论是O1AP还是O1TP都会涉及到数据一致性的问题，典型的场景就是外键关联的场景。当我们对其中一张表的数据进行更改的时候，如果它有相关的外键约束或者关联约束，那么必然会涉及数据库对数据一致性的检查及处理。这会带来两个问题：1 .数据处理效率的问题，关联约束的检查及关联操作必然带来多余的操作代价。2 .数据处理过度依赖单节点资源，无法实现分布式处理。既然我们要顾

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

11、辑使之前下沉到数据库的关联性约束上浮到业务控制层面。2. O1AP(联机分析)对于O1AP这个概念来讲，接触过数据库的人都会非常熟悉。联机分析(O1AP)是由关系数据库之父E.RCodd于1993年提出的一种数据动态分析模型，它允许以一种称为多维数据集的多维结构访问来自商业数据源的经过聚合和组织整理的数据。这是一个相对抽象的概念，那么从实际应用的角度，其实我们可以从以下几个方面来看什么是01AP。2.1 动杰多维度数据分析我们在平时工作中，会遇到各种问题，在分析问题的时候，同样的现象，我们会从多个角度去分析考虑，并且有时候我们还会从几个角度综合起来进行分析。这就是O1AP分析最基本的概念：从多

12、个观察角度的灵活组合来观察数据，从而发现数据内在规律。O1AP将数据分为两种特征，一种为表现特征，比如一个销售分析模型中的销售额、毛利等，我们称之为度量数据；还有一种为角度特征，比如销售分析中的时间周期、产品类型、销售模式、销售区域等。O1AP术语称之为“维数1维(DimenSiOn)：人们观察事物的视角，如时间、地理位置、年龄和性别等,是单角度概念。2.度量(MeaSUre)：表示在这个维成员上的取值。以上是在O1AP场景当中我们需要用到数据的特征，那么根据数据的不同维和度去对数据进行加工和分析就是我们O1AP的核心任务了，如图2.1-2.6所不O图2.1原始数据模型图2.2数据加工操作1数

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

14、可以看出O1AP场景当中对业务数据的几种常见操作，回到最基本的操作上就是对数据的拆分汇总，然后观察出其中的业务规律。那么这样的一些数据处理特征对应到数据库的操作是什么呢？对于这个问题，我们通过对比O1TP业务场景来看，具体如表2.1。表2.1O1AP&O1TP比00较11维TA度PP常插查规入询数、据更汇操新总作、类删分型除类比OO较11维TA度PP、筛选数自O据己1源TP查小大询而范特快围点速检的索查、询全比OO较11维TA度PP扫描插小中入而间&频表更繁、新的新特插表点入的批量比OO较11维TA度PP整表数极修据高改完，较整外少性键，要等几求约乎束没较有多完整比OO较11维TA度PP处毫分

15、理秒钟时为-间单小位时处以以理单整数个表据数、量据整为库主海比OO较11维TA度PP数据为从以上表当中，我们可以看到了不同维度上，O1AP与O1TP在数据库操作方面的区别，总结分析来看，我们认为O1AP会在以下几点有特殊的要求：1数据处理量的质变。也就是说我们处理的数据量必须是巨大的并远远超出普通查询任务。2 .数据处理的类型要以查询为基础的筛选、分类分组、拆分聚合、汇总统计绝对占比090%)o3 .数据之间的完整性约束是很少或者基本不考虑。不需要数据关联以及外键约束。3 .列式存储与O1AP的契合点通过1、2两部分的介绍，我们了解了列式存储的特点，也了解了O1AP业务的特点。那么试想如果用O1TP的关系型数据库去运行O1AP,会发生什么样的问题？首先、在业务初始，我们感觉不到瓶颈的所在，因为以G为单位的数据量，在普通的OraC1e、MySQ1、DB2数据库当中，我们很轻松可以通过SQ1当中的Se1ect*from、OrderBy、GroupBy等语句实现我们对整表或者整库数据的查询、分类分组、拆分聚合以及统计等操作，尽管时间可能会稍微多一些。接着、当运行一段时间之后，我们发现当数据量