OLAP组件选型[通俗易懂]

2022-11-17 14:10:43 浏览数 (1)

大家好，又见面了，我是你们的朋友全栈君。

OLAP组件选型

  • 一、OLAP简介
    • 1、olap准则
    • 2、OLAP场景的关键特征
    • 3、与oltp比较
  • 二、开源引擎
    • 1、Hive
    • 2、spark SQL
    • 3、presto
    • 4、kylin
    • 5、impala
    • 6、druid
    • 7、Greeplum
    • 8、clickhouse
  • 三、选型要求
    • 1、实时性要求较高，对接kafka，实时查询数据
    • 2、可以接入hive数据
    • 3、单表查询数据较多，较少的join，在数仓中完成宽表构建

一、OLAP简介

说起 OLAP 要追溯到 1993 年。

1、olap准则

  • 准则1 OLAP模型必须提供多维概念视图
  • 准则2 透明性准则
  • 准则3 存取能力准则
  • 准则4 稳定的报表能力
  • 准则5 客户/服务器体系结构
  • 准则6 维的等同性准则
  • 准则7 动态的稀疏矩阵处理准则
  • 准则8 多用户支持能力准则
  • 准则9 非受限的跨维操作
  • 准则10 直观的数据操纵
  • 准则11 灵活的报表生成
  • 准则12 不受限的维与聚集层次

2、OLAP场景的关键特征

  • 大多数是读请求
  • 数据总是以相当大的批(> 1000 rows)进行写入
  • 不修改已添加的数据
  • 每次查询都从数据库中读取大量的行，但是同时又仅需要少量的列
  • 宽表，即每个表包含着大量的列
  • 较少的查询(通常每台服务器每秒数百个查询或更少)
  • 对于简单查询，允许延迟大约50毫秒
  • 列中的数据相对较小：数字和短字符串(例如，每个URL 60个字节)
  • 处理单个查询时需要高吞吐量（每个服务器每秒高达数十亿行）
  • 事务不是必须的
  • 对数据一致性要求低
  • 每一个查询除了一个大表外都很小
  • 查询结果明显小于源数据，换句话说，数据被过滤或聚合后能够被盛放在单台服务器的内存中

3、与oltp比较

与OLAP 不同的是，

OLTP系统强调数据库内存效率，强调内存各种指标的命令率，强调绑定变量，强调并发操作，强调事务性。OLAP系统则强调数据分析，强调SQL执行时长，强调磁盘I/O，强调分区。

二、开源引擎

目前市面上主流的开源OLAP引擎包含不限于：Hive、Spark SQL、Presto、Kylin、Impala、Druid、Clickhouse、Greeplum等，可以说目前没有一个引擎能在数据量，灵活程度和性能上做到完美，用户需要根据自己的需求进行选型。

1、Hive

Hive 是基于 Hadoop 的一个数据仓库工具，可以将结构化的数据文件映射为一张数据库表，并提供完整的 sql 查询功能，可以将 sql 语句转换为 MapReduce 任务进行运行。其优点是学习成本低，可以通过类SQL语句快速实现简单的MapReduce统计，不必开发专门的MapReduce应用，十分适合数据仓库的统计分析。

2、spark SQL

Spark SQL https://spark.apache.org/sql/

SparkSQL的前身是Shark，它将 SQL 查询与 Spark 程序无缝集成,可以将结构化数据作为 Spark 的 RDD 进行查询。SparkSQL作为Spark生态的一员继续发展，而不再受限于Hive，只是兼容Hive。

Spark SQL在整个Spark体系中的位置如下：

Spark SQL对熟悉Spark的同学来说，很容易理解并上手使用：相比于Spark RDD API，Spark SQL包含了对结构化数据和在其上运算的更多信息，Spark SQL使用这些信息进行了额外的优化，使对结构化数据的操作更加高效和方便。SQL提供了一个通用的方式来访问各式各样的数据源，包括Hive, Avro, Parquet, ORC, JSON, and JDBC。Hive兼容性极好。

3、presto

Presto https://prestodb.github.io/https://www.cnblogs.com/tgzhu/p/6033373.html

Presto is an open source distributed SQL query engine for running interactive analytic queries against data sources of all sizes ranging from gigabytes to petabytes.Presto allows querying data where it lives, including Hive, Cassandra, relational databases or even proprietary data stores. A single Presto query can combine data from multiple sources, allowing for analytics across your entire organization.Presto is targeted at analysts who expect response times ranging from sub-second to minutes. Presto breaks the false choice between having fast analytics using an expensive commercial solution or using a slow “free” solution that requires excessive hardware.

这是Presto官方的简介。Presto 是由 Facebook 开源的大数据分布式 SQL 查询引擎，适用于交互式分析查询，可支持众多的数据源，包括 HDFS，RDBMS，KAFKA 等，而且提供了非常友好的接口开发数据源连接器。

Presto支持标准的ANSI SQL，包括复杂查询、聚合（aggregation）、连接（join）和窗口函数（window functions)。作为Hive和Pig（Hive和Pig都是通过MapReduce的管道流来完成HDFS数据的查询）的替代者，Presto 本身并不存储数据，但是可以接入多种数据源，并且支持跨数据源的级联查询。

Presto没有使用MapReduce，它是通过一个定制的查询和执行引擎来完成的。它的所有的查询处理是在内存中，这也是它的性能很高的一个主要原因。Presto和Spark SQL有很大的相似性，这是它区别于Hive的最根本的区别。

但Presto由于是基于内存的，而hive是在磁盘上读写的，因此presto比hive快很多，但是由于是基于内存的计算当多张大表关联操作时易引起内存溢出错误。

4、kylin

Kylin http://kylin.apache.org/cn/https://www.infoq.cn/article/kylin-apache-in-meituan-olap-scenarios-practice/

提到Kylin就不得不说说ROLAP和MOLAP。 传统OLAP根据数据存储方式的不同分为ROLAP（relational olap）以及MOLAP（multi-dimension olap）

  • ROLAP 以关系模型的方式存储用作多为分析用的数据，优点在于存储体积小，查询方式灵活，然而缺点也显而易见，每次查询都需要对数据进行聚合计算，为了改善短板，ROLAP使用了列存、并行查询、查询优化、位图索引等技术。
  • MOLAP 将分析用的数据物理上存储为多维数组的形式，形成CUBE结构。维度的属性值映射成多维数组的下标或者下标范围，事实以多维数组的值存储在数组单元中，优势是查询快速，缺点是数据量不容易控制，可能会出现维度爆炸的问题。

而Kylin自身就是一个MOLAP系统，多维立方体（MOLAP Cube）的设计使得用户能够在Kylin里为百亿以上数据集定义数据模型并构建立方体进行数据的预聚合。

Apache Kylin™是一个开源的分布式分析引擎，提供Hadoop/Spark之上的SQL查询接口及多维分析（OLAP）能力以支持超大规模数据，最初由eBay Inc. 开发并贡献至开源社区。它能在亚秒内查询巨大的Hive表。

Kylin的优势有：

  • 提供ANSI-SQL接口
  • 交互式查询能力
  • MOLAP Cube 的概念
  • 与BI工具可无缝整合

所以适合Kylin的场景包括：

用户数据存在于Hadoop HDFS中，利用Hive将HDFS文件数据以关系数据方式存取，数据量巨大，在500G以上 每天有数G甚至数十G的数据增量导入 有10个以内较为固定的分析维度 简单来说，Kylin中数据立方的思想就是以空间换时间，通过定义一系列的纬度，对每个纬度的组合进行预先计算并存储。有N个纬度，就会有2的N次种组合。所以最好控制好纬度的数量，因为存储量会随着纬度的增加爆炸式的增长，产生灾难性后果。

5、impala

https://impala.apache.org/

Impala也是一个SQL on Hadoop的查询工具，底层采用MPP技术，支持快速交互式SQL查询。与Hive共享元数据存储。Impalad是核心进程，负责接收查询请求并向多个数据节点分发任务。statestored进程负责监控所有Impalad进程，并向集群中的节点报告各个Impalad进程的状态。catalogd进程负责广播通知元数据的最新信息。

impala架构图如下：

Impala的特性包括：

  • 支持Parquet、Avro、Text、RCFile、SequenceFile等多种文件格式
  • 支持存储在HDFS、HBase、Amazon S3上的数据操作
  • 支持多种压缩编码方式：Snappy、Gzip、Deflate、Bzip2、LZO
  • 支持UDF和UDAF
  • 自动以最有效的顺序进行表连接
  • 允许定义查询的优先级排队策略
  • 支持多用户并发查询
  • 支持数据缓存
  • 提供计算统计信息（COMPUTE STATS）
  • 提供窗口函数（聚合 OVER PARTITION, RANK, LEAD, LAG, NTILE等等）以支持高级分析功能
  • 支持使用磁盘进行连接和聚合，当操作使用的内存溢出时转为磁盘操作
  • 允许在where子句中使用子查询
  • 允许增量统计——只在新数据或改变的数据上执行统计计算
  • 支持maps、structs、arrays上的复杂嵌套查询
  • 可以使用impala插入或更新HBase 同样，Impala经常会和Hive、Presto放在一起做比较，Impala的劣势也同样明显：
  • Impala不提供任何对序列化和反序列化的支持。
  • Impala只能读取文本文件，而不能读取自定义二进制文件。
  • 每当新的记录/文件被添加到HDFS中的数据目录时，该表需要被刷新。这个缺点会导致正在执行的查询sql遇到刷新会挂起，查询不动。

6、druid

https://druid.apache.org/https://blog.csdn.net/warren288/article/details/80629909

Druid 是一种能对历史和实时数据提供亚秒级别的查询的数据存储。Druid 支持低延时的数据摄取，灵活的数据探索分析，高性能的数据聚合，简便的水平扩展。适用于数据量大，可扩展能力要求高的分析型查询系统。

Druid解决的问题包括：数据的快速摄入和数据的快速查询。所以要理解Druid，需要将其理解为两个系统，即输入系统和查询系统。

Druid的特点包括：

  • Druid实时的数据消费，真正做到数据摄入实时、查询结果实时
  • Druid支持 PB 级数据、千亿级事件快速处理，支持每秒数千查询并发
  • Druid的核心是时间序列，把数据按照时间序列分批存储，十分适合用于对- 按时间进行统计分析的场景
  • Druid把数据列分为三类：时间戳、维度列、指标列
  • Druid不支持多表连接
  • Druid中的数据一般是使用其他计算框架(Spark等)预计算好的低层次统计数据
  • Druid不适合用于处理透视维度复杂多变的查询场景
  • Druid擅长的查询类型比较单一，一些常用的SQL(groupby 等)语句在druid里运行速度一般
  • Druid支持低延时的数据插入、更新，但是比hbase、传统数据库要慢很多
  • 与其他的时序数据库类似，Druid在查询条件命中大量数据情况下可能会有性能问题，而且排序、聚合等能力普遍不太好，灵活性和扩展性不够，比如缺乏Join、子查询等。

我个人对Druid的理解在于，Druid保证数据实时写入，但查询上对SQL支持的不够完善(不支持Join)，适合将清洗好的记录实时录入，然后迅速查询包含历史的结果，在我们目前的业务上没有实际应用。

Druid的应用可以参考：《Druid 在有赞的使用场景及应用实践》https://blog.csdn.net/weixin_34273481/article/details/89238947

7、Greeplum

https://greenplum.org/https://blog.csdn.net/yongshenghuang/article/details/84925941https://www.jianshu.com/p/b5c85cadb362

Greenplum是一个开源的大规模并行数据分析引擎。借助MPP架构，在大型数据集上执行复杂SQL分析的速度比很多解决方案都要快。

GPDB完全支持ANSI SQL 2008标准和SQL OLAP 2003 扩展；从应用编程接口上讲，它支持ODBC和JDBC。完善的标准支持使得系统开发、维护和管理都大为方便。支持分布式事务，支持ACID。保证数据的强一致性。做为分布式数据库，拥有良好的线性扩展能力。GPDB有完善的生态系统，可以与很多企业级产品集成，譬如SAS，Cognos，Informatic，Tableau等；也可以很多种开源软件集成，譬如Pentaho,Talend 等。

GreenPulm的技术特点如下：

  • 支持海量数据存储和处理
  • 支持Just In Time BI：通过准实时、实时的数据加载方式，实现数据仓库的- 实时更新，进而实现动态数据仓库（ADW），基于动态数据仓库，业务用户- 能对当前业务数据进行BI实时分析（Just In Time BI）
  • 支持主流的sql语法，使用起来十分方便，学习成本低
  • 扩展性好，支持多语言的自定义函数和自定义类型等
  • 提供了大量的维护工具，使用维护起来很方便
  • 支持线性扩展：采用MPP并行处理架构。在MPP结构中增加节点就可以线性提供系统的存储容量和处理能力
  • 较好的并发支持及高可用性支持除了提供硬件级的Raid技术外，还提供数据库层Mirror机制保护，提供Master/Stand by机制进行主节点容错，当主节点发生错误时，可以切换到Stand by节点继续服务
  • 支持MapReduce
  • 数据库内部压缩 一个重要的信息：Greenplum基于Postgresql，也就是说GreenPulm和TiDB的定位类似，想要在OLTP和OLAP上进行统一。

8、clickhouse

https://clickhouse.yandex/https://clickhouse.yandex/docs/zh/development/architecture/http://www.clickhouse.com.cn/https://www.jianshu.com/p/a5bf490247ea Clickhouse由俄罗斯yandex公司开发。专为在线数据分析而设计。Yandex是俄罗斯搜索引擎公司。官方提供的文档表名，ClickHouse 日处理记录数”十亿级”。

特性:采用列式存储；数据压缩；支持分片，并且同一个计算任务会在不同分片上并行执行，计算完成后会将结果汇总；支持SQL；支持联表查询；支持实时更新；自动多副本同步；支持索引；分布式存储查询。

大家都Nginx不陌生吧，战斗民族开源的软件普遍的特点包括：轻量级，快。

ClickHouse最大的特点就是快，快，快，重要的话说三遍！与Hadoop、Spark这些巨无霸组件相比，ClickHouse很轻量级，其特点：

  • 列式存储数据库，数据压缩
  • 关系型、支持SQL
  • 分布式并行计算，把单机性能压榨到极限
  • 高可用
  • 数据量级在PB级别
  • 实时数据更新
  • 索引 使用ClickHouse也有其本身的限制，包括：
  • 缺少高频率，低延迟的修改或删除已存在数据的能力。仅能用于批量删除或修改数据。
  • 没有完整的事务支持
  • 不支持二级索引
  • 有限的SQL支持，join实现与众不同
  • 不支持窗口功能
  • 元数据管理需要人工干预维护

三、选型要求

1、实时性要求较高，对接kafka，实时查询数据

2、可以接入hive数据

3、单表查询数据较多，较少的join，在数仓中完成宽表构建

可选组件为druid、clickhouse，考虑到druid时间窗问题，最好需要离线数据同步更新昨天druid中的数据，

因此选定为clickhouse

版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。

发布者：全栈程序员栈长，转载请注明出处：https://javaforall.cn/234236.html原文链接：https://javaforall.cn

数据分析 https hive spark 网络安全

0 人点赞