前言
OLAP百家争鸣
准则1 OLAP模型必须提供多维概念视图
准则2 透明性准则
准则3 存取能力准则
准则4 稳定的报表能力
准则5 客户/服务器体系结构
准则6 维的等同性准则
准则7 动态的稀疏矩阵处理准则
准则8 多用户支持能力准则
准则9 非受限的跨维操作
准则10 直观的数据操纵
准则11 灵活的报表生成
准则12 不受限的维与聚集层次
OLAP开源引擎
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.
传统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个以内较为固定的分析维度
支持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实时的数据消费,真正做到数据摄入实时、查询结果实时
Druid支持 PB 级数据、千亿级事件快速处理,支持每秒数千查询并发
Druid的核心是时间序列,把数据按照时间序列分批存储,十分适合用于对按时间进行统计分析的场景
Druid把数据列分为三类:时间戳、维度列、指标列
Druid不支持多表连接
Druid中的数据一般是使用其他计算框架(Spark等)预计算好的低层次统计数据
Druid不适合用于处理透视维度复杂多变的查询场景
Druid擅长的查询类型比较单一,一些常用的SQL(groupby 等)语句在druid里运行速度一般
Druid支持低延时的数据插入、更新,但是比hbase、传统数据库要慢很多
https://greenplum.org/
https://blog.csdn.net/yongshenghuang/article/details/84925941
https://www.jianshu.com/p/b5c85cadb362
支持海量数据存储和处理
支持Just In Time BI:通过准实时、实时的数据加载方式,实现数据仓库的实时更新,进而实现动态数据仓库(ADW),基于动态数据仓库,业务用户能对当前业务数据进行BI实时分析(Just In Time BI)
支持主流的sql语法,使用起来十分方便,学习成本低
扩展性好,支持多语言的自定义函数和自定义类型等
提供了大量的维护工具,使用维护起来很方便
支持线性扩展:采用MPP并行处理架构。在MPP结构中增加节点就可以线性提供系统的存储容量和处理能力
较好的并发支持及高可用性支持除了提供硬件级的Raid技术外,还提供数据库层Mirror机制保护,提供Master/Stand by机制进行主节点容错,当主节点发生错误时,可以切换到Stand by节点继续服务
支持MapReduce
数据库内部压缩
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系统能够满足各种场景的查询需求。
其本质原因是,没有一个系统能同时在数据量、性能、和灵活性三个方面做到完美,每个系统在设计时都需要在这三者间做出取舍。
联系客服