数仓OLAP技术
数据应用，是真正体现数仓价值的部分，包括且又不局限于 数据可视化、BI、OLAP、即席查询，实时大屏，用户画像，推荐系统，数据分析，数据挖掘，人脸识别，风控反欺诈，ABtest等等
OLAP（On-Line Analytical Processing）：在线分析处理，主要用于支持企业决策管理分析。
OLAP分类
OLAP按存储器的数据存储格式分为：
1、ROLAP（Relational OLAP）
- 完全基于关系模型进行存储数据，不需要预计算，按需即时查询。
- 明细和汇总数据都保存在关系型数据库事实表中。
- 代表技术栈有Presto、impala with Kudu、ClickHouse等
2、MOLAP（Multi-dimensional OLAP）
- 基于多维数组的存储模型，也是OLAP最初的形态，特点是对数据进行预计算，以空间换效率，明细和聚合数据都保存在cube中，但生成cube需要大量时间和空间。
- 代表技术有Kylin、Druid
3、HOLAP（Hybrid OLAP）
- 相当于是ROLAP和MOLAP混合模型，其中：这种方式相对灵活，且更加高效。
- 细节数据以ROLAP存放
- 聚合数据以MOLAP存放
可按企业业务场景和数据粒度进行取舍，没有最好，只有最适合。
OLAP数据库技术
在大数据数仓架构中，最早的架构离线以Hive为主，实时计算一般是Spark+Flink配合，消息队列Kafka一家独大，后起之秀Pulsar想要做出超越难度很大，Hbase、Redis和MySQL都在特定场景下有一席之地。唯独在OLAP领域，百家争鸣，各有所长。
OLAP引擎/工具/数据库，技术选型可有很多选择，传统公司大多以Congos、Oracle、MicroStrategy等OLAP产品，互联网公司则普遍强势拥抱开源，如：
- Presto，Druid ，Impala，SparkSQL，AnalyticDB，(Hbase)Phoenix，kudu， Kylin，Greenplum，Clickhouse, Hawq, Drill，ES等
在数据架构时，可以说目前没有一个引擎能在数据量，灵活程度和性能上（吞吐和并发）做到完美，用户需要根据自己的业务场景进行选型。
开源技术选型，MOLAP可选Kylin、Druid，ROLAP可选Presto、impala等
1、Presto
Presto 是由 Facebook 开源的大数据分布式 SQL 查询引擎，基于内存的低延迟高并发并行计算（MPP），适用于交互式分析查询。Preso特点：
- 本身并不存储数据，但是可以接入多种数据源，包括 Hive、RDBMS（Mysql、Oracle、Tidb等）、Kafka、MongoDB、Redis等
- 完全支持ANSI SQL标准，用户可以直接使用 ANSI SQL 进行数据查询和计算
- 可以混合多个catalog进行join查询和计算，支持跨数据源的级联查询
- 基于PipeLine进行设计的，流水管道式数据处理，支持数据规模GB~PB，计算中拿出一部分放在内存、计算、抛出、再拿。
- SQL on Hadoop：弥补Hive的效率性能和灵活性的不足，Presto和Spark SQL、Impala有很多异曲同工之处。
2、Druid
Druid是一个用于大数据实时查询和分析的高容错、高性能开源分布式系统，用于解决如何在大规模数据集下进行快速的、交互式的查询和分析。
数据可以实时摄入，进入到Druid后立即可查，同时数据是几乎是不可变。通常是基于时序的事实事件，事实发生后进入Druid，外部系统就可以对该事实进行查询。
Apache Druid 特点：
- 亚秒级 OLAP 查询，包括多维过滤、Ad-hoc 的属性分组、快速聚合数据等等。
- 实时的数据消费，真正做到数据摄入实时、查询结果实时。
- 高效的多租户能力，最高可以做到几千用户同时在线查询。
- 扩展性强，支持 PB 级数据、千亿级事件快速处理，支持每秒数千查询并发。
- 极高的高可用保障，支持滚动升级。
不适用的场景：
- 由于druid属于时间存储，删除操作比较繁琐，且不支持查询条件删除数据，只能根据时间范围删除数据。
- Druid能接受的数据的格式相对简单，比如不能处理嵌套结构的数据。
- 无 Join 操作：Druid 适合处理星型模型的数据，不支持关联操作。
- 数据没有 update 更新操作，只对 segment 粒度进行覆盖
- 由于时序化数据的特点，Druid 不支持数据的更新。
3、Clickhouse
Clickhouse是一个用于在线分析处理（OLAP）的列式数据库管理系统（DBMS）。
是由俄罗斯的Yandex公司为了Yandex Metrica网络分析服务而开发。它支持分析实时更新的数据，Clickhouse以高性能著称。
不适用的场景：
我以前是非常摒弃ROLAP的，因为实在是太慢了。ROLAP都是现算的，以前的套路基本都是生成一个巨复杂的sql扔到数据库里跑，那样能不慢么？但是这个ClickHouse却不一样，它最显著的特性就是快！这不科学啊！
虽然各种测评都会选择偏向自己的指标，但是这也太悬殊了吧？ClickHouse的创始人yandex公司的同事出来解释过，有点让我失望，并不是一个非常牛的算法或者方案，而是从硬件开始向上一点一点的优化。是不是特别惊讶？
所以ClickHouse另外一个特性就是独立，不需要任何组件的依赖，貌似现在都有往这方面发展的趋势，比如Doris也是不需要依赖的。我们知道Kylin是需要依赖Hbase的。这就会引起各种各样的组件版本问题。想想就头大！
ClickHouse在运行的时候，会用掉服务器的所有资源，不仅仅是内存哦！甚至你查一个简单但是数据，都会吃掉50%以上的CPU！！！
另外，CK还有以下特性：
- PB级数据处理能力
- 列式数据存储
- 优秀的数据压缩
- 多核并行处理
- 多服务器分布式处理
- SQL支持（部分语句有点怪）
- 向量化引擎
- 支持实时数据更新
- 高吞吐写入
- 近似计算
- 少依赖，上手非常容易
对比：
对比图：
Flag:
- Impala、Presto 基于内存计算的引擎，没这么多高配的机器，不考虑
- Kylin：是我们把KMS的架构用坏了还是....? 没体现出来它的高性能
- clickhouse：关注引入。
参考