数据仓库【多维分析】

  

目录

1、BI

1.1 BI 技术

2、OLAP基本操作和类型

2.1 OLAP基本操作

2.2 OLAP分类

3、OLAP数据库选型

3.1 Presto

3.1.1 概念

3.1.2 presto架构（master+slaver模式）

3.1.3 Presto应用场景

3.2 Druid 

3.2.1 概念

3.2.2 Druid架构

3.2.3 基本特点

3.2.4 应用场景

3.2.5 Druid案例

3.3 Kylin

3.3.1 概述

3.3.2 kylin特性

3.3.3 kylin生态圈

4、Clickhouse 

4.1 概述

4.2 场景特征

4.3 clickhouse自身限制

---

    数据应用，是真正体现数仓价值的部分，包括且又不局限于 数据可视化、BI、OLAP、即席查询，实时大屏，用户画像，推荐系统，数据分析，数据挖掘，人脸识别，风控反欺诈，ABtest等等。

​​​​​​​   ​​​​​​​ 本文侧重于数据应用之BI可视化和OLAP技术选型。

1、BI

1.1 BI 技术

    大数据时代商业智能（BI）和数据可视化诉求更为强烈，淘宝大屏更是风靡全球！数据可视化是大数据『最后一公里』。

1.2 BI分类

    统看业界可视化BI工具可大致分为：开源bi，商业bi，和传统重bi工具。

    业界目前比较流行的开源bi工具有Superset、metabase、Redash、Cboard、Spagobi等，商业bi工具有帆软、tableau、PowerBI、SmartBI、QlinkView、QuickBI等，传统企业、传统数仓，大多依然沿用重bi产品，如Congos、BIEE、BO、MicroStrategydeng等。

2、OLAP基本操作和类型

    OLAP，On-Line Analytical Processing，在线分析处理，主要用于支持企业决策管理分析。区别于OLTP，On-Line Transaction Processing，联机事务处理。

    OLAP的优势：丰富的数据展现方式、高效的数据查询以及多视角多层次的数据分析。

    数据仓库与OLAP的关系是互补的，现代OLAP系统一般以数据仓库作为基础，即从数据仓库中抽取详细数据的一个子集并经过必要的聚集存储到OLAP存储器中供前端分析工具读取。

2.1 OLAP基本操作

OLAP的多维分析操作包括：钻取（Drill-down）、上卷（Roll-up）、切片（Slice）、切块（Dice）以及旋转（Pivot）。

★钻取：维的层次变化，从粗粒度到细粒度，汇总数据下钻到明细数据。如通过季度销售数据钻取每个月的销售数据

★上卷：钻取的逆，向上钻取。从细粒度到粗粒度，细粒度数据到不同维层级的汇总。eg. 通过每个月的销售数据汇总季度、年销售数据

★切片：特定维数据（剩余维两个）。eg.  只选电子产品销售数据

★切块：维区间数据（剩余维三个）。eg. 第一季度到第二季度销售数据

★旋转：维位置互换（数据行列互换），通过旋转可以得到不同视角的数据。

2.2 OLAP分类

    OLAP按存储器的数据存储格式分为ROLAP（Relational OLAP）、MOLAP（Multi-dimensional OLAP）和 HOLAP（Hybrid OLAP）。

• MOLAP，基于多维数组的存储模型，也是OLAP最初的形态，特点是对数据进行预计算，以空间换效率，明细和聚合数据都保存在cube中。但生成cube需要大量时间和空间。
• ROLAP，完全基于关系模型进行存储数据，不需要预计算，按需即时查询。明细和汇总数据都保存在关系型数据库事实表中。
• HOLAP，混合模型，细节数据以ROLAP存放，聚合数据以MOLAP存放。这种方式相对灵活，且更加高效。可按企业业务场景和数据粒度进行取舍，没有最好，只有最适合。

3、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、ClickHouse 等。

3.1 Presto

3.1.1 概念

    Presto 是由 Facebook 开源的大数据分布式 SQL 查询引擎，基于内存的低延迟高并发并行计算（mpp），适用于交互式分析查询。首先我们先来看一下Presto官方的介绍：

    ☆ 本身并不存储数据，但是可以接入多种数据源，包括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有很多异曲同工之处。

3.1.2 presto架构（master+slaver模式）

3.1.3 Presto应用场景

3.2 Druid 

3.2.1 概念

    Druid是一个用于大数据实时查询和分析的高容错、高性能开源分布式系统，用于解决如何在大规模数据集下进行快速的、交互式的查询和分析。    

    数据可以实时摄入，进入到Druid后立即可查，同时数据是几乎是不可变。通常是基于时序的事实事件，事实发生后进入Druid，外部系统就可以对该事实进行查询。

3.2.2 Druid架构

3.2.3 基本特点

    Apache Druid 具有以下特点：

• 亚秒级 OLAP 查询，包括多维过滤、Ad-hoc 的属性分组、快速聚合数据等等。
• 实时的数据消费，真正做到数据摄入实时、查询结果实时。
• 高效的多租户能力，最高可以做到几千用户同时在线查询。
• 扩展性强，支持 PB 级数据、千亿级事件快速处理，支持每秒数千查询并发。
• 极高的高可用保障，支持滚动升级。

3.2.4 应用场景

    实时数据分析是 Apache Druid 最典型的使用场景。该场景涵盖的面很广，例如：

• 实时指标监控
• 推荐模型
• 广告平台
• 搜索模型

    Druid也有很多不足需要注意，由于druid属于时间存储，删除操作比较繁琐，且不支持查询条件删除数据，只能根据时间范围删除数据。Druid能接受的数据的格式相对简单，比如不能处理嵌套结构的数据。

3.2.5 Druid案例

    知乎：技术选型上，知乎根据不同业务场景选择了HBase 和 Redis 作为实时指标的存储引擎，在OLAP选型上，知乎选择了Druid。

    OPPO：而OPPO根据自身不同的业务场景，报表层选择了Druid，标签选择了ES，接口层选择了Hbase。

3.3 Kylin

3.3.1 概述

    Apache Kylin™是一个开源的分布式分析引擎，提供Hadoop/Spark之上的SQL查询接口及多维分析（OLAP）能力以支持超大规模数据，最初由eBay Inc. 开发并贡献至开源社区。它能在亚秒内查询巨大的Hive表。

3.3.2 kylin特性

• 可扩展超快olap引擎，Hadoop/Spark上百亿数据规模
• 提供 Hadoop ANSI SQL 接口
• 交互式查询能力，用户可以与Hadoop数据进行亚秒级交互
• 百亿以上数据集构建多维立方体（MOLAP CUBE）
• 与BI工具无缝整合，如Tableau，PowerBI/Excel，MSTR，QlikSense，Hue和SuperSet

3.3.3 kylin生态圈

4、Clickhouse 

4.1 概述

    Clickhouse是一个用于在线分析处理（OLAP）的列式数据库管理系统（DBMS）。是由俄罗斯的Yandex公司为了Yandex Metrica网络分析服务而开发。它支持分析实时更新的数据，Clickhouse以高性能著称。

4.2 场景特征

• 大多数是读请求
• 数据总是以相当大的批(> 1000 rows)进行写入
• 不修改已添加的数据
• 每次查询都从数据库中读取大量的行，但是同时又仅需要少量的列
• 宽表，即每个表包含着大量的列
• 较少的查询(通常每台服务器每秒数百个查询或更少)
• 对于简单查询，允许延迟大约50毫秒
• 列中的数据相对较小：数字和短字符串(例如，每个URL 60个字节)
• 处理单个查询时需要高吞吐量（每个服务器每秒高达数十亿行）
• 事务不是必须的
• 对数据一致性要求低
• 每一个查询除了一个大表外都很小
• 查询结果明显小于源数据，换句话说，数据被过滤或聚合后能够被盛放在单台服务器的内存中

4.3 clickhouse自身限制

• 不支持真正的删除/更新支持 不支持事务
• 不支持二级索引
• 有限的SQL支持，join实现与众不同
• 不支持窗口功能
• 元数据管理需要人工干预维护