数仓OLAP技术

标签：spark   支持   idt   组件   性能   hbase   产品   同事   art   

 数据应用，是真正体现数仓价值的部分，包括且又不局限于 数据可视化、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以高性能著称。

不适用的场景：

 ClickHouse为什么这么火？

      我以前是非常摒弃ROLAP的，因为实在是太慢了。ROLAP都是现算的，以前的套路基本都是生成一个巨复杂的sql扔到数据库里跑，那样能不慢么？但是这个ClickHouse却不一样，它最显著的特性就是快！这不科学啊！

   虽然各种测评都会选择偏向自己的指标，但是这也太悬殊了吧？ClickHouse的创始人yandex公司的同事出来解释过，有点让我失望，并不是一个非常牛的算法或者方案，而是从硬件开始向上一点一点的优化。是不是特别惊讶？

   所以ClickHouse另外一个特性就是独立，不需要任何组件的依赖，貌似现在都有往这方面发展的趋势，比如Doris也是不需要依赖的。我们知道Kylin是需要依赖Hbase的。这就会引起各种各样的组件版本问题。想想就头大！ 

   ClickHouse在运行的时候，会用掉服务器的所有资源，不仅仅是内存哦！甚至你查一个简单但是数据，都会吃掉50%以上的CPU！！！

   另外，CK还有以下特性：

• PB级数据处理能力
• 列式数据存储
• 优秀的数据压缩
• 多核并行处理
• 多服务器分布式处理
• SQL支持（部分语句有点怪）
• 向量化引擎
• 支持实时数据更新
• 高吞吐写入
• 近似计算
• 少依赖，上手非常容易

对比：

对比图：

Flag:

• Impala、Presto 基于内存计算的引擎，没这么多高配的机器，不考虑
• Kylin：是我们把KMS的架构用坏了还是....?  没体现出来它的高性能
• clickhouse：关注引入。

参考

• https://blog.csdn.net/baichoufei90/article/details/112006582?spm=1001.2014.3001.5501

数仓OLAP技术

标签：spark   支持   idt   组件   性能   hbase   产品   同事   art   

原文地址：https://www.cnblogs.com/tgzhu/p/14527652.html