你需要的不是实时数仓 | 你需要的是一款强大的OLAP数据库(下)
By 大数据技术与架构
对于实时数仓的狂热追求大可不必如此。
前言
本文给出了常用的开源OLAP引擎的性能测评:
https://blog.csdn.net/oDaiLiDong/article/details/86570211
OLAP百家争鸣
OLAP简介
OLAP,也叫联机分析处理(Online Analytical Processing)系统,有的时候也叫DSS决策支持系统,就是我们说的数据仓库。与此相对的是OLTP(on-line transaction processing)联机事务处理系统。联机分析处理 (OLAP) 的概念最早是由关系数据库之父E.F.Codd于1993年提出的。OLAP的提出引起了很大的反响,OLAP作为一类产品同联机事务处理 (OLTP) 明显区分开来。Codd认为联机事务处理(OLTP)已不能满足终端用户对数据库查询分析的要求,SQL对大数据库的简单查询也不能满足用户分析的需求。用户的决策分析需要对关系数据库进行大量计算才能得到结果,而查询的结果并不能满足决策者提出的需求。因此,Codd提出了多维数据库和多维分析的概念,即OLAP。OLAP委员会对联机分析处理的定义为:从原始数据中转化出来的、能够真正为用户所理解的、并真实反映企业多维特性的数据称为信息数据,使分析人员、管理人员或执行人员能够从多种角度对信息数据进行快速、一致、交互地存取,从而获得对数据的更深入了解的一类软件技术。OLAP的目标是满足决策支持或多维环境特定的查询和报表需求,它的技术核心是"维"这个概念,因此OLAP也可以说是多维数据分析工具的集合。OLAP的准则和特性
E.F.Codd提出了关于OLAP的12条准则:准则1 OLAP模型必须提供多维概念视图
准则2 透明性准则
准则3 存取能力准则
准则4 稳定的报表能力
准则5 客户/服务器体系结构
准则6 维的等同性准则
准则7 动态的稀疏矩阵处理准则
准则8 多用户支持能力准则
准则9 非受限的跨维操作
准则10 直观的数据操纵
准则11 灵活的报表生成
准则12 不受限的维与聚集层次
一言以蔽之:OLTP系统强调数据库内存效率,强调内存各种指标的命令率,强调绑定变量,强调并发操作,强调事务性;
OLAP系统则强调数据分析,强调SQL执行时长,强调磁盘I/O,强调分区。
OLAP开源引擎
组件特点和简介
Hive
https://hive.apache.org/Hive是基于Hadoop的一个数据仓库工具,可以将结构化的数据文件映射为一张数据库表,并提供完整的sql查询功能,可以将sql语句转换为MapReduce任务进行运行。其优点是学习成本低,可以通过类SQL语句快速实现简单的MapReduce统计,不必开发专门的MapReduce应用,十分适合数据仓库的统计分析。Hawq
http://hawq.apache.orghttps://blog.csdn.net/wzy0623/article/details/55047696
https://www.oschina.net/p/hawqHawq是一个Hadoop原生大规模并行SQL分析引擎,Hawq采用 MPP 架构,改进了针对 Hadoop 的基于成本的查询优化器。除了能高效处理本身的内部数据,还可通过 PXF 访问 HDFS、Hive、HBase、JSON 等外部数据源。HAWQ全面兼容 SQL 标准,能编写 SQL UDF,还可用 SQL 完成简单的数据挖掘和机器学习。无论是功能特性,还是性能表现,HAWQ 都比较适用于构建 Hadoop 分析型数据仓库应用。一个典型的Hawq集群组件如下:
Spark SQL
https://spark.apache.org/sql/SparkSQL的前身是Shark,它将 SQL 查询与 Spark 程序无缝集成,可以将结构化数据作为 Spark 的 RDD 进行查询。SparkSQL作为Spark生态的一员继续发展,而不再受限于Hive,只是兼容Hive。Spark SQL在整个Spark体系中的位置如下:相比于Spark RDD API,Spark SQL包含了对结构化数据和在其上运算的更多信息,Spark SQL使用这些信息进行了额外的优化,使对结构化数据的操作更加高效和方便。
SQL提供了一个通用的方式来访问各式各样的数据源,包括Hive, Avro, Parquet, ORC, JSON, and JDBC。
Hive兼容性极好。
Presto
https://prestodb.github.io/
https://blog.csdn.net/u012535605/article/details/83857079
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.
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结构。维度的属性值映射成多维数组的下标或者下标范围,事实以多维数组的值存储在数组单元中,优势是查询快速,缺点是数据量不容易控制,可能会出现维度爆炸的问题。
提供ANSI-SQL接口
交互式查询能力
MOLAP Cube 的概念
与BI工具可无缝整合
用户数据存在于Hadoop HDFS中,利用Hive将HDFS文件数据以关系数据方式存取,数据量巨大,在500G以上
每天有数G甚至数十G的数据增量导入
有10个以内较为固定的分析维度
Impala
https://impala.apache.org/Impala也是一个SQL on Hadoop的查询工具,底层采用MPP技术,支持快速交互式SQL查询。与Hive共享元数据存储。Impalad是核心进程,负责接收查询请求并向多个数据节点分发任务。statestored进程负责监控所有Impalad进程,并向集群中的节点报告各个Impalad进程的状态。catalogd进程负责广播通知元数据的最新信息。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不提供任何对序列化和反序列化的支持。
Impala只能读取文本文件,而不能读取自定义二进制文件。
每当新的记录/文件被添加到HDFS中的数据目录时,该表需要被刷新。这个缺点会导致正在执行的查询sql遇到刷新会挂起,查询不动。
Druid
https://druid.apache.org/https://blog.csdn.net/warren288/article/details/80629909Druid 是一种能对历史和实时数据提供亚秒级别的查询的数据存储。Druid 支持低延时的数据摄取,灵活的数据探索分析,高性能的数据聚合,简便的水平扩展。适用于数据量大,可扩展能力要求高的分析型查询系统。Druid解决的问题包括:数据的快速摄入和数据的快速查询。
所以要理解Druid,需要将其理解为两个系统,即输入系统和查询系统。Druid的架构如下:
Druid实时的数据消费,真正做到数据摄入实时、查询结果实时
Druid支持 PB 级数据、千亿级事件快速处理,支持每秒数千查询并发
Druid的核心是时间序列,把数据按照时间序列分批存储,十分适合用于对按时间进行统计分析的场景
Druid把数据列分为三类:时间戳、维度列、指标列
Druid不支持多表连接
Druid中的数据一般是使用其他计算框架(Spark等)预计算好的低层次统计数据
Druid不适合用于处理透视维度复杂多变的查询场景
Druid擅长的查询类型比较单一,一些常用的SQL(groupby 等)语句在druid里运行速度一般
Druid支持低延时的数据插入、更新,但是比hbase、传统数据库要慢很多
《Druid 在有赞的使用场景及应用实践》https://blog.csdn.net/weixin_34273481/article/details/89238947
Greeplum
https://greenplum.org/
https://blog.csdn.net/yongshenghuang/article/details/84925941
https://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
数据库内部压缩
ClickHouse
https://clickhouse.yandex/https://clickhouse.yandex/docs/zh/development/architecture/
http://www.clickhouse.com.cn/
https://www.jianshu.com/p/a5bf490247ea官网对ClickHouse的介绍:
ClickHouse is an open source column-oriented database management system capable of real time generation of analytical data reports using SQL queries.
列式存储数据库,数据压缩
关系型、支持SQL
分布式并行计算,把单机性能压榨到极限
高可用
数据量级在PB级别
实时数据更新
索引
缺少高频率,低延迟的修改或删除已存在数据的能力。仅能用于批量删除或修改数据。
没有完整的事务支持
不支持二级索引
有限的SQL支持,join实现与众不同
不支持窗口功能
元数据管理需要人工干预维护
总结
上面给出了常用的一些OLAP引擎,它们各自有各自的特点,我们将其分组:
Hive,Hawq,Impala - 基于SQL on Hadoop
Presto和Spark SQL类似 - 基于内存解析SQL生成执行计划
Kylin - 用空间换时间,预计算
Druid - 一个支持数据的实时摄入
ClickHouse - OLAP领域的Hbase,单表查询性能优势巨大
Greenpulm - OLAP领域的Postgresql
如果你的场景是基于HDFS的离线计算任务,那么Hive,Hawq和Imapla就是你的调研目标;
如果你的场景解决分布式查询问题,有一定的实时性要求,那么Presto和SparkSQL可能更符合你的期望;
如果你的汇总维度比较固定,实时性要求较高,可以通过用户配置的维度+指标进行预计算,那么不妨尝试Kylin和Druid;
ClickHouse则在单表查询性能上独领风骚,远超其他的OLAP数据库;
Greenpulm作为关系型数据库产品,性能可以随着集群的扩展线性增长,更加适合进行数据分析。
就像美团在调研Kylin的报告中所说的:
目前还没有一个OLAP系统能够满足各种场景的查询需求。
其本质原因是,没有一个系统能同时在数据量、性能、和灵活性三个方面做到完美,每个系统在设计时都需要在这三者间做出取舍。
欢迎点赞+收藏+转发朋友圈素质三连