概述

联机事务处理OLTP(On-line Transaction Processing)下面介绍数据立方体中最常见的五大操作:切片,切块,旋转,上卷,下钻。

image.png

  1. MPP即大规模并行处理(Massively Parallel Processor
  2. 搜索引擎架构的系统(Elasticsearch等)相对比MPP系统,在入库时将数据转换为倒排索引,采用Scatter-Gather计算模型,牺牲了灵活性换取很好的性能,在搜索类查询上能做到亚秒级响应。但是对于扫描聚合为主的查询,随着处理数据量的增加,响应时间也会退化到分钟级
  3. 预计算系统(Druid/Kylin等)则在入库时对数据进行预聚合,进一步牺牲灵活性换取性能,以实现对超大数据集的秒级响应。

在调研了市面上主流的开源OLAP引擎后发现,目前还没有一个系统能够满足各种场景的查询需求。其本质原因是,没有一个系统能同时在数据量、性能、和灵活性三个方面做到完美,每个系统在设计时都需要在这三者间做出取舍。

image.png

框架对比

Hive SparkSql/FLinkSql Kylin Impala Kudu Druid Presto Doris Clickhouse
原理划分 纯计算 纯计算 计算+存储 计算 存储 计算+存储 计算 计算+存储 计算+存储
依赖Hadoop生态
查询性能 小时,分钟级 小时,分钟级 秒/毫秒 秒/毫秒 秒/耗秒
特点 sql解析成MR Spark底层解析sql运行spark job 预计算 内存计算
一般结合Kudu使用
OLAP+OLTP 预计算
实时处理的时序性数据库
内存计算 MPP
引入向量化
向量化
优势 稳定
数据量取决于hdfs
生态对接丰富
复用spark底层优化
压秒级查询性能 高效利用cpu和内存性能>Presto>Spark 实时写入
支持update/delete
实时,批量摄入
支持kafka
生态丰富支持Redis,mysql,kafka,iceberg join能力
分析性能


单表性能最好
缺点 时间最长 多使用代码 只能针对预计算指标
浪费磁盘
指标列不能太多
内存要求高
稳定性不如hive
全局事务需要自己实现 只能针对预计算指标
不支持sql
不支持join
不支持jdbc方式】
运维复杂
同Impala 生态还在发展中 不能join
并发低

参考:
开源OLAP性能对比
主流OLAP对比