數據應用，是真正體現數倉價值的部分，包括且又不局限于 數據可視化、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工具有帆軟FineBI、tableau、PowerBI、等，傳統企業、傳統數倉，大多依然沿用重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數據庫，沒有一個引擎能同時在數據量、性能、和靈活性三個方面做到完美，每個系統在設計時都需要在這三者間做出取舍。

總結

以上是生活随笔為你收集整理的从BI到OLAP，数据仓库最终到底能干什么？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。