☞ 01.可视化BI工具 [ 开源BI，商业BI，传统BI ]
☞ 02.OLAP科普 [ ROLAP MOLAP HOLAP ]
☞ 03.OLAP引擎 [ Kylin Druid Presto Impala Kudu ADB ES .. ]
本文之前，先来回顾一下本系列前三篇文章：
▼ 系列 | 漫谈数仓第一篇NO.1 『基础架构』架构规范
▼ 系列 | 漫谈数仓第二篇NO.2 『数仓建模』维度建模
▼ 系列 | 漫谈数仓第三篇NO.3 『数据清洗』ETL之道
今天是我们漫谈数仓系列第四篇NO.4 『数据应用』。
数据应用，是真正体现数仓价值的部分，包括且又不局限于 数据可视化、BI、OLAP、即席查询，实时大屏，用户画像，推荐系统，数据分析，数据挖掘，人脸识别，风控反欺诈等等。
数据仓库架构图
本文侧重于数据应用之BI可视化和OLAP。
一、BI可视化工具
1.1 BI现状
大数据时代商业智能（BI）和数据可视化诉求更为强烈，淘宝大屏更是风靡全球！数据可视化是大数据『最后一公里』。
BI唤醒沉睡的数据。
传统型BI力求大而全的统一综合型报表和分析平台，侧重传统式报表开发，俨然一把屠龙刀。现互联网公司快速迭代的业务发展，需要的却是倚天剑，促使自助式BI和敏捷BI得以迅速发展。
时代召唤，传统BI巨头也逐渐向自助式BI和云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等。
详细每一款bi工具，我们前面文章有详细介绍。如果你感兴趣，或正在调研开BI工具选型，可移步：大数据可视化BI工具，呕血总结，通幽洞微（点击链接即可跳转）
二、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存放。这种方式相对灵活，且更加高效。可按企业业务场景和数据粒度进行取舍，没有最好，只有最适合。
三、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等
Presto
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有很多异曲同工之处。
presto架构（master slaver模式）：
Presto应用场景：
Druid
Druid是一个用于大数据实时查询和分析的高容错、高性能开源分布式系统，用于解决如何在大规模数据集下进行快速的、交互式的查询和分析。
数据可以实时摄入，进入到Druid后立即可查，同时数据是几乎是不可变。通常是基于时序的事实事件，事实发生后进入Druid，外部系统就可以对该事实进行查询。
Druid架构
基本特点
Apache Druid 具有以下特点：
- 亚秒级 OLAP 查询，包括多维过滤、Ad-hoc 的属性分组、快速聚合数据等等。
- 实时的数据消费，真正做到数据摄入实时、查询结果实时。
- 高效的多租户能力，最高可以做到几千用户同时在线查询。
- 扩展性强，支持 PB 级数据、千亿级事件快速处理，支持每秒数千查询并发。
- 极高的高可用保障，支持滚动升级。
应用场景
实时数据分析是 Apache Druid 最典型的使用场景。该场景涵盖的面很广，例如：
- 实时指标监控
- 推荐模型
- 广告平台
- 搜索模型
Druid也有很多不足需要注意，由于druid属于时间存储，删除操作比较繁琐，且不支持查询条件删除数据，只能根据时间范围删除数据。Druid能接受的数据的格式相对简单，比如不能处理嵌套结构的数据。
Druid案例
知乎：技术选型上，知乎根据不同业务场景选择了HBase 和 Redis 作为实时指标的存储引擎，在OLAP选型上，知乎选择了Druid。
OPPO：而OPPO根据自身不同的业务场景，报表层选择了Druid，标签选择了ES，接口层选择了Hbase。
Kylin
Apache Kylin™是一个开源的分布式分析引擎，提供Hadoop/Spark之上的SQL查询接口及多维分析（OLAP）能力以支持超大规模数据，最初由eBay Inc. 开发并贡献至开源社区。它能在亚秒内查询巨大的Hive表。
kylin特性：
- 可扩展超快olap引擎，Hadoop/Spark上百亿数据规模
- 提供 Hadoop ANSI SQL 接口
- 交互式查询能力，用户可以与Hadoop数据进行亚秒级交互
- 百亿以上数据集构建多维立方体（MOLAP CUBE）
- 与BI工具无缝整合，如Tableau，PowerBI/Excel，MSTR，QlikSense，Hue和SuperSet
kylin生态圈：
Clickhouse
Clickhouse是一个用于在线分析处理（OLAP）的列式数据库管理系统（DBMS）。
是由俄罗斯的Yandex公司为了Yandex Metrica网络分析服务而开发。它支持分析实时更新的数据，Clickhouse以高性能著称。
先看一下官方定义：
ClickHouse is a column-oriented database management system (DBMS) for online analytical processing of queries (OLAP).
场景特征：
- 大多数是读请求
- 数据总是以相当大的批(> 1000 rows)进行写入
- 不修改已添加的数据
- 每次查询都从数据库中读取大量的行，但是同时又仅需要少量的列
- 宽表，即每个表包含着大量的列
- 较少的查询(通常每台服务器每秒数百个查询或更少)
- 对于简单查询，允许延迟大约50毫秒
- 列中的数据相对较小：数字和短字符串(例如，每个URL 60个字节)
- 处理单个查询时需要高吞吐量（每个服务器每秒高达数十亿行）
- 事务不是必须的
- 对数据一致性要求低
- 每一个查询除了一个大表外都很小
- 查询结果明显小于源数据，换句话说，数据被过滤或聚合后能够被盛放在单台服务器的内存中
clickhouse自身限制：
- 不支持真正的删除/更新支持 不支持事务
- 不支持二级索引
- 有限的SQL支持，join实现与众不同
- 不支持窗口功能
- 元数据管理需要人工干预维护
ClickHouse开源的出现让许多想做大数据并且想做大数据分析的很多公司和企业耳目一新。ClickHouse 正是以不依赖Hadoop 生态、安装和维护简单、查询速度快、可以支持SQL等特点在大数据分析领域披荆斩棘越走越远。
ADB（AnalyticDB for MySQL）
分析型数据库MySQL版（AnalyticDB for MySQL），是阿里巴巴自主研发的海量数据实时高并发在线分析（Realtime OLAP）云计算服务，使得您可以在毫秒级针对千亿级数据进行即时的多维分析透视和业务探索。
adb优势和特性
- 超大规模：极致弹性轻松扩展至PB级规模
- 简单易用：全面兼容MySQL协议和BI工具
- 实时化分析：通过实时同步，报表延时1分钟内
- 查询速度快：传统关系型数据库的5-10倍性能
基于adb实时数仓架构
通过数据传输服务DTS（Data Transmission Service），您可以将RDS for MySQL同步到AnalyticDB for MySQL，帮助您快速构建企业内部BI、交互查询、实时报表等系统。
adb数据化链路架构
四、数据挖掘
分类、聚类、预测、关联
本文不多做介绍，对于这一块，后面会专门写一篇文章介绍。
五、本文结束语
☆☞ 对于数据架构，不管是数据仓库、数据湖，还是数据中台，数据应用才是数据价值体现所在
☆☞ 对于可视化BI工具，通幽洞微，建议熟练掌握2-3款即可，理解工具思想和实现方式
☆☞ 对于OLAP数据库，没有一个引擎能同时在数据量、性能、和灵活性三个方面做到完美，每个系统在设计时都需要在这三者间做出取舍。
