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实现与众不同
不支持窗口功能
元数据管理需要人工干预维护

数据仓库【多维分析】相关推荐

数据仓库-多维分析展示平台Saiku
Saiku Saiku是一个轻量级的OLAP分析引擎,可以方便的扩展.嵌入和配置.Saiku通过REST API连接OLAP系统,利用其友好的界面为用户提供直观的分析数据的方式,它是基于jQuery做 ...
基于数据仓库的证券CRM系统建设
基于数据仓库的证券CRM系统规划是小柯论文网通过网络搜集,并由本站工作人员整理后发布的,基于数据仓库的证券CRM系统规划是篇质量较高的学术论文,供本站访问者学习和学术交流参考之用,不可用于其他商业目的 ...
实践篇 | 构建下一代云上数据湖，助力车企数字化转型
近几年,汽车行业全面拥抱电气化和数字化,一方面有行业先行者和政策法规的激励作用,另外一方面随着无线网络升级换代以及云计算技术越发成熟,车机端到企业端能够更加实时稳定传输丰富数据.如何利用好这些数据,为 ...
大数据学习——数据挖掘理论基础
本文学习来源于<数据挖掘理论与技术>(电子工业出版社) 数据挖掘概述数据挖掘方法可以是基于数学理论的,也可以是非数学的:可以是演绎的,也可以是归纳的.从研究的历史看,它们是数据库.人工智 ...
tp5某个字段相同的数据只取一次_多维分析数据仓库建设建议-面向主题的建模...
数仓使用数据库构建数仓的作用简单来说就是存储数据和读取数据. 绝大部分情况下,数据是结构化的,因此存储数据使用数据库,使用SQL语言进行数据处理. 多维分析多维分析是指使用数据的场景,查询时组合维 ...
RoaringBitMap在ClickHouse和Spark之间的实践-解决数据仓库预计算多维分析问题
前面在Spark多维分析去重计数场景优化案例中说了一下Spark计算在多维分析场景中的弊端,多维度分析会导致数据量指数级膨胀,搭配上去重计算字段越多,膨胀倍数也是线性增长,通过BitMap这个案例 ...
数据仓库及其体系建设
1 数据仓库的概念数据仓库( Data Warehousing )的概念最早出现于 20 世纪 80 年代.而直到 1993 年,号称"数据仓库之父"的 William H . ...
【DBMS 数据库管理系统】数据库 -＞数据仓库 ( 数据处理类型 | 传统数据库 | 数据库不适用于分析型应用 )
文章目录一.数据处理类型二.传统数据库技术三.传统数据库不适用于分析型 ( DSS 决策支持系统 ) 应用原因四.事务性处理与分析型处理性能特性不同五.数据集成问题六.数据集成 ...
数据仓库的架构与设计
https://blog.csdn.net/trigl/article/details/68944434 公司之前的数据都是直接传到Hdfs上进行操作,没有一个数据仓库,趁着最近空出几台服务器,搭了个 ...

数据仓库【多维分析】

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 基本特点

Apache Druid 具有以下特点：

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自身限制

数据仓库【多维分析】相关推荐

最新文章

热门文章