基于大数据的OLAP技术4个角度一篇讲明白.docx

《基于大数据的OLAP技术4个角度一篇讲明白.docx》由会员分享，可在线阅读，更多相关《基于大数据的OLAP技术4个角度一篇讲明白.docx（7页珍藏版）》请在第壹文秘上搜索。

1、在线分析处理(OnIineAnaIytiCaIPrOCeSSing,OLAP)技术是大数据技术中快速解决多维分析问题的方法之一。由于OLAP需要快速读取大量数据，因此它对数据的读取吞吐量和计算效率有很高的要求。目前，基于大数据的OLAP技术一般从面向读的存储优化、预计算、支持灵活分析等方面不断提高，近几年出现了很多令人激动的产品。OlOLAP技术介绍OLAP技术让用户能够从多个角度交互地分析多维数据，从中发现规律，用来做决策支持。在分析过程中，用户需要获取和处理历史数据(一段时期内)，有时也需要获取和处理实时数据，此时查询吞吐量和相应时间是关键性能指标。1、OLAP分析操作OLAP分析一般需要

2、设计数据立方体，立方体由分析的维度(dimension).层级(level)和指标(metric)来定义，支持上卷(ro-up)、钻取(drilldown)、切片(slicing)和切块(dicing)等分析操作。- 上卷：将数据按一个或多个维度向更高层级策合，例如基于县级销售额统计市级销售额。- 钻取：上卷的反向操作。- 切片和切块：从OLAP多维数据集中按选择维度的特定数值选取出一组特定的数据，例如一季度的所有数据。- 切块：从OLAP多维数据集中按选择维度的特定数值区间选取出一组特定的数据，例如2月到5月的所有数据。2、与OLTP的区别与OLAP相对的是OLTP。OLTP的全称是联机事务

3、处理(OnlineTransactionProcessing),是传统关系型数据库的主要应用。OLTP的特点是实现插入、更新、IH除等事务的在线处理，但系统需要保证事务的完整性，满足AClD原则。在OLTP中，事务的吞吐量是关键性能指标，以每秒事务数来衡量效率。由于严格的约束限制，支持OLTP的数据系统通常无法满足OLAP大规模数据读取与处理的需求，二者对数据读取的吞吐量要求相差不止一个量级，因此OLAP系统的技术选型一般与OLTP不同，数据的组织方式也不同。02实时OLAP系统的两种架构模型随着DT时代的到来，越来越多的业务需求要求大数据系统既能处理历史数据，又能进行实时计算，同时越来越要求

4、运营的时效性，以便即时评估运营活动效果，即时调整策略。针对实时大数据统计分析系统，有两种架构设计路线:Lambda和KappaoLambda架构包含三层：批处理层(BatchLayer)、速度层(SPeedLayer)和服务层(ServingLayer)o批处理层对历史数据进行预处理，速度层处理新增实时数据，服务层实现上述两层处理结果的融合，将其合并为统一视图，为用户提供全时域数据分析查询。每层可以分别选择合适的大数据组件来构建系统，比如用SPark构建批处理层、用Flink构建速度层。-KaPPa架构在Lambda架构的基础上去掉了批处理层，对速度层进行了改进，使其既能够支持实时数据处理，又

5、能够支持历史数据处理。KaPPa架构只有实时层和服务层。Kappa架构通常是将流式框架中的数据通道替换成消息队列(如Kafka),可以设定一定的保留期限，如分析逻辑改变，重新从消息队列消费数据处理即可。实时OLAP系统的两种架构模型对比如图1所示。图1实时OLAP的两种架构模型对比两种架构模型的优缺点对比如下： Lambda架构具有很好的灵活性、可扩展性和容错性，但分别处理历史数据与实时数据时常常出现处理逻辑或计算结果不一致的情况，另外系统建设和维护复杂。 KaPPa架构只需维护一套代码，可以做到数据处理逻辑与计算结果的一致性。KaPPa架构并不是Lambda架构的替代品，二者的应用场景不同。

6、K叩Pa架构由于全部采用流式处理，数据处理吞吐量不如Lambda架构，处理资源成本也较高。03OLAP相关技术分类按照数据模型可将OLAP相关技术分为MOLAP.ROLAP和HOLAP3种类型： MOLAP表示MUltidimenSiOnalOLAP（多维型OLAP）,一般是基于预计算生成多维数据立方体； ROLAPRelationalOLAP（关系型OLAP）,一般不进行预计算，直接关联事实表与维度表进行查询； HOLAP是指HybridOLAP（混合型OLAP）,是混合利用MoLAP和RoLAP方法，综合二者的优缺点。按照实现的技术方法可将OLAP相关技术分为MPP架构、预计算和搜索引擎三

7、类。- MPP架构：最常见的OLAP引擎架构，MPP架构具有完全的可伸缩性、高可用、高性能、高性价比等优势。此类又分两种，一种是MPP数据库，它基于关系数据模型建立数据仓库的主要技术选型，是大数据场景ROLAP的实现方法，典型的产品是GreenPIUm、CliCkHOuse;另一种是MPP分析引擎，它仅基于MPP架构实现计算功能，数据存储则依赖于其他存储系统（如HDFS）,典型的产品有PreSto、ImPala。- 预计算：基于定义的数据立方体，在明细表上进行预计算，在多维分析时仅执行查询操作，是实现MoLAP的典型方法。优点是查询时如果命中预计算结果则几乎没有延迟，适合对超大原始数据集的分析

8、，可实现秒级响应；缺点是预计算量大、不灵活、支持维度有限（否则存在维度灾难）、查询延迟时间不稳定（取决于是否命中预计算结果）。典型的产品如APaCheKyIin,也有产品通过控制预计算的程度以避免预计算量太大，如Druido- 搜索引擎：在入库时将数据转换为倒排索引，在搜索类查询上能做到亚秒级响应，但是对于扫描聚合为主的查询，随着处理数据量的增加，响应时间也会退化到分钟级。另外，搜索引擎对存储消耗很大。典型的产品如ElasticsearchSolro三种技术方法的优缺点及适用场景对比如表1所示。表1三种技术方法的优缺点及适用场景对比技术方法MPP架构预计算搜索引擎优点支持任意的SQL表达.无数

9、据冗余和预处理支持超大原始数据集，高性能、高并发强大的明细检索功能,同时支持实时与离线数据缺点大数据量、复杂查询下分钟级响应,不支持实时数据不支持明细数据查询，需要预先定义维度、指标大数据量、复杂查询下分钟级响应,不支持JOIN、子查询等适用场景对灵活性非常高的即席查询场景对性能要求非常高的OLAP场景中小数据规模的简单OLAP分析场景针对这三种技术实现方法，该如何做技术选型呢？OLAP技术需要考虑系统的数据量、性能和灵活性三个方面，但是目前还没有种方法能同时在这三个方面做到完美，在设计时需要在这三个方面之间做出取舍。比如MPP架构，它有很好的数据量和灵活性的支持，但是它的性能无法保证，随着计

10、算量和复杂度的增加，响应时间可能从秒级变为分钟级甚至小时级。而预计算系统和搜索引擎技术方法则是通过牺牲灵活性来换取高性能。另外，还要考虑是否需要查询明细数据等辅助需求。04OLAP技术典型流行产品示例本节介绍两个Hadoop体系兼容的OLAP产品，一个是基于MPP架构的OLAP引擎一Impala,一个是基于预计算方法的OLAP引擎一KyIino1、ImpalaImpala属于SQLonHadoop的开源MPP分析引擎，可在Hadoop集群上运行。它由ClOUdera公司主导开发，作为HiVe的高性能替代品，用于大数据实时查询分析。ImPaIa提高了APaChCHadooP的SQL查询性能，同时

11、保留了熟悉的HiVe用户体验，采用SQL语法(HiVeSQL),使得HiVe的用户可以顺畅地迁移到ImPaIa上。ImPala采用与基础数据存储引擎分离的设计，使用HDFS和HBaSe作为数据存储，并从HiVe获取元数据，这是它与传统关系型数据库系统的主要区别。传统关系数据的查询引擎与存储引擎是紧密耦合的。为了避免延迟，Impala避开了MaPRedUce,通过专门实现的分布式查询引擎直接访问数据，比HiVe快几个数量级。Impala的优点如下所示。- 在数据所在节点对数据进行本地处理，避免网络传输瓶颈；支持线性扩展；- 与HadOoP体系使用相同的基础设施，直接利用HadoOP体系的元数据、

12、安全和资源管理；- 直接读取HadOOP系统中的数据，无须进行高成本的数据格式转换；- 所有数据均可立即查询。ImPaIa由三个服务组成成mala主进程(Impaladaemon)、StateStOre进程和Catalog进程。 Impala主进程：负责接收客户端的查询请求，协调请求在集群中的执行，并负责执行一个查询片段。ImPaIa主进程包含三个子模块：QUeryPIanner、QueryCoordinatorQueryExecEngineo每台服务器上会运行一个ImPaIa主进程（与HDFS的DataNOde在同一个主机上运行），所有的ImPaIa主进程都是对等的。ImPaIa主程序与St

13、ateStore进程保持持续通信，以确认哪些节点的主进程是健康的并可以接收新工作。 StateStore进程:充当ImPaIa的CataIOg储存库和元数据访问网关,会检查集群中所有Impala主进程的运行状况，并将发现结果不断传递给每个主进程。 Catalog进程：将ImpalaSQL语句的元数据更改传递到集群的所有ImPala主进程中。Impala架构示意图如图2所示。通用HiVeSQL和接口统一的元数据StatcStoreSQLAppHDFSNNODBCQueryPlannerQueryPlannerQueryCrdinatorQueryCoordinatorQueryCrdinator

14、QueryExccEngineQueryExccEngineAQUCrYExcc EngineHDFSDNHBascHDFSHBasc完全MPP分布式HiveMetastorcAHDFSDN本地直接读取 1图2ImPala架构QucrPlannerHBasc2、KylinApacheKylin是一个开源的分布式分析引擎，提供Hadoop、Spark之上的SQL查询接口及多维分析能力以支持超大规模数据，最初由eBay开发并贡献至开源社区。Kylin通过三步支持查询。 模型定义：定义数据集的星形或雪花形模型。 预计算：通过数据立方体计算引擎(CubeBuildEngine)组件对明细数据进行离线计算，生成用于查询的数据立方体(OLAPCube),并将CUbe数据存储于HBase中。 在线查询：在线查询时通过标准SQL或RESTfUIAPL查询引擎(QueryEngine)首先对预计算的数据立方体进行查询，如果命中缓存，则可以实现秒级响应，如果没有命中缓存，则进行实时计算，延迟会比较高。Kylin原理示意图如图3所示。图3Kylin原理ApacheKylin的特性如下所示。 能够处理百亿规模数据，可扩展，预计算生成数据立方体，在线查询亚秒级响应。 兼容Hadoop体系C 提供标准SQL,支持大部分查询功能。 能与Bl工具的无缝整合，如TabIeau。