大数据OLAP系统比较

结论

选择presto和clickhouse配合使用

对实时性要求不严格的数据用presto查询
对于实时性有要求的数据查询clickhouse

理由：

核心原因：clickhouse相对于Apache Kylin等预计算方案非常省机器，成本最关键(比较穷，没办法)
clickhouse的单表查询非常非常快
目前再惠的数据仍然处于并将长期处于小规模阶段(集群内存少于1T，Cpu少于200vCore)，clickhouse在小规模集群上表现优于Druid和Pinot
presto的综合性能好，在join操作时表现较好，保持目前数仓的这一套不变

OLAP整体情况

目前的大数据OLAP系统都是部分优化的，偏向于定制化系统，典型的是Clickhouse的不同表级engine
建立一个能够cover绝大多数情况的通用的大数据OLAP系统预计还需要100年
目前所有的OLAP系统都是基于两种思路设计
1. 列式数据库加索引，典型是Clickhouse
2. 预计算空间换时间：典型是Apache Kylin，所有结果预先计算好放在cube

OLAP系统比较

先大致按照OLAP的设计思路把常用的系统分下类：

列式数据库加索引

Clickhouse
Apache Pinot
Druid

预计算空间换时间

Apache Kylin
Apache Doris
Mondrian

从所有的系统中选出相对符合的再进行深入一点的比较如下：

	Clickhouse	Druid	Apache Kylin
语言	C++	Java	Java
Star	7743	8405	2275
活跃度	活跃	活跃	活跃
亚秒级响应	√	√	√
列式数据库	√	√	×
预计算	×	√	√
云存储	×	√	√
机器	省	省	费
join	√	×	√
商业公司	Altinity	Imply和Hortonworks	Kyligence

至于clickhouse/druid/pinot三者的比较可以参见这篇文章：Comparison of the Open Source OLAP Systems for Big Data: ClickHouse, Druid, and Pinot，整体写的非常好而且有深度，对比表格翻译如下：

ClickHouse	Druid/Pinot
具备C++经验的组织	具备Java经验的组织
小型集群	大型集群
少量表	大量表
单一数据集	多个不相关的数据集（多租户）
表和数据集永久驻留在集群中	表和数据集定期出现并从群集中退出
表格大小（以及它们的查询强度）在时间上是稳定的	表格随时间热度降低
查询的同质性（其类型，大小，按时间分布等）	异质性
存在可以用于分区的维度，且经过该维度分区后，几乎不会触发跨分区的数据查询	没有这样的维度，查询经常触及整个集群中的数据
不使用云，集群部署在特定的物理服务器上	群集部署在云中
无需依赖现有的Hadoop或Spark集群	Hadoop或Spark的集群已经存在并且可以使用

ClickHouse，Druid和Pinot三个系统都还不成熟。在这三个系统中，ClickHouse与Druid和Pinot略有不同，而后两者几乎完全相同，它们几乎是两个独立开发的完全相同系统的实现。

与ClickHouse相比，Druid和Pinot更适合优化大型集群的基础架构成本，并且更适合云环境。

Druid和Pinot之间唯一可持续的区别是，Pinot依赖于Helix框架并将继续依赖ZooKeeper，而德鲁伊可能会远离对ZooKeeper的依赖。另一方面，德鲁伊安装将继续依赖于某些SQL数据库的存在。

CloudFlare的选择

在CK和Druid中选择了CK，10个节点的规模CK更好

https://blog.cloudflare.com/how-cloudflare-analyzes-1m-dns-queries-per-second/

目前公司最大的单表数据为10B，也就是100亿：门店3公里内的所有门店以及经纬度数据，占用S3空间110G

各个引擎的概况

Clickhouse

项目地址：https://github.com/yandex/ClickHouse

架构概述：https://clickhouse.yandex/docs/zh/development/architecture/

支持primary key sorting，不支持inverted indexes

https://github.com/yandex/ClickHouse/issues/5125

Druid

不支持primary key sorting，支持inverted indexes

通过编写 Json 文件，以 HTTP 的方式请求 Druid

支持sql

国内使用Druid比较多，有赞，美团等

https://tech.youzan.com/realtime-olap-on-druid/

https://github.com/apache/incubator-druid

Java star 8405

Apache Pinot

项目地址：https://github.com/apache/incubator-pinot/

架构概述：https://pinot.readthedocs.io/en/latest/architecture.html

2323 star 活跃

国内使用Pinot的比较少

Apache Doris

Doris前身是Palo，Palo是百度自研的基于MPP的交互式SQL数据仓库

架构概述：https://doris.incubator.apache.org/Docs/cn/internal/metadata-design.html#id3

项目地址：https://github.com/apache/incubator-doris

1294 star 活跃

C++

来源百度

国内使用Pinot的比较少

Apache Kylin

https://github.com/apache/kylin

来源：eBay

语言：Java

2275 star 活跃

在国内广泛使用

链家使用Kylin：https://www.infoq.cn/article/lianjia-data-analysis-apache-kylin

典型的空间换时间：维度优化，预计算的结果需要存储到 Hbase

优势：

都已经预先计算好了，性能啥的都不会有啥问题
主要针对hive的离线数据做分析，属于hadoop生态圈，可以和目前的hive这一套完美结合起来
Apache Kylin v1.6.0之后支持了近实时的流计算，后续构建成为离线和实时的一站式解决方案
Apache Kylin v2.0.0 引入了一个全新的基于 Apache Spark 的构建引擎，替换MR，Cube构件时间缩短一半

代价：

需要维护一套hbase集群，空间换时间的操作会极度废机器，但是hbase数据可以存在cloud上
需要在kylin web维护针对查询提前定义维度构建cube
运维Kylin对Admin有较高的要求，首先必须了解HBase，Hive，MapReduce，Spark，HDFS，Yarn的原理；其次对MapReduce Job和Spark Job的问题排查和调优经验要丰富；然后必须掌握对Cube复杂调优的方法；最后出现问题时排查的链路较长，复杂度较高。

Apache kylin中cube的构建过程及原理分析：https://www.cnblogs.com/shibit/p/7039794.html