轉轉實時OLAP分析場景技術選型與應用實踐

作者：汪文強 2022-12-21 08:32:34

本文主要介紹了轉轉OLAP分析架構的選型和實踐，通過引入 Druid 和 Clickhouse ，解決了公司當前場景下的多維分析需求。

一、OLAP技術介紹及選型

OLAP，On-Line Analytical Processing，在線分析處理，主要用于支持企業決策管理分析。區別于OLTP，On-Line Transaction Processing，聯機事務處理。

OLTP 主要用來記錄具體某類業務事件的發生，如交易行為，當行為產生后，數據庫會記錄這個事件是誰在什么時候什么地方做了什么事，這樣的一行（或多行）數據會以（增刪改）的方式在數據庫中進行數據的更新處理操作，要求實時性高、穩定性強、確保數據及時更新成功，常見的業務系統如商場系統，ERP，客服系統，OA等系統都是基于OLTP開發的系統。

當業務發展到一定程度，積累了一些數據的時候，對過去發生的事情做一個總結分析的需求就會產生，這類需求往往需要把過去一段時間內產生的數據拿出來進行統計分析，從中獲取我們想要的信息，為公司做決策提供支持，我們管這類場景就叫做OLAP。OLAP的優勢：豐富的數據展現方式、高效的數據查詢以及多視角多層次的數據分析。

我們常說OLTP是數據庫的應用，OLAP是數據倉庫的應用，兩者主要的區別如下圖：

1.1 OLAP基本操作

OLAP的多維分析操作包括：鉆取（Drill-down）、上卷（Roll-up）、切片（Slice）、切塊（Dice）以及旋轉（Pivot）。

★鉆取：維的層次變化，從粗粒度到細粒度，匯總數據下鉆到明細數據。eg：通過季度銷售數據鉆取每個月的銷售數據

★上卷：鉆取的逆，向上鉆取。從細粒度到粗粒度，細粒度數據到不同維層級的匯總。eg：通過每個月的銷售數據匯總季度、年銷售數據

★切片：特定維數據（剩余維兩個）。eg：只選電子產品銷售數據

★切塊：維區間數據（剩余維三個）。eg：第一季度到第二季度銷售數據

★旋轉：維位置互換（數據行列互換）。eg：通過旋轉可以得到不同視角的數據

1.2 OLAP分類

OLAP按存儲器的數據存儲格式分為ROLAP（Relational OLAP）、MOLAP（Multi-dimensional OLAP）和 HOLAP（Hybrid OLAP）。

MOLAP，基于多維數組的存儲模型，也是OLAP最初的形態，特點是對數據進行預計算，以空間換效率，明細和聚合數據都保存在cube中。但生成cube需要大量時間和空間。MOLAP的優勢在于由于經過了數據多維預處理，分析中數據運算效率高，主要的缺陷在于數據更新有一定延滯。
ROLAP，完全基于關系模型進行存儲數據，不需要預計算，按需即時查詢。明細和匯總數據都保存在關系型數據庫事實表中。ROLAP的最大好處是可以實時地從源數據中獲得最新數據更新，以保持數據實時性，缺陷在于運算效率比較低，用戶等待響應時間比較長。
HOLAP，混合模型，細節數據以ROLAP存放，聚合數據以MOLAP存放。這種方式相對靈活，且更加高效。

1.3 主流OLAP特性及適用場景分析

Druid
Druid是采用預計算的方式。主要解決的是對于大量的基于時序的數據進行聚合查詢。Druid提供了實時流數據分析，以及高效實時寫入，進入到Druid后立即可查，同時數據是幾乎是不可變。通常是基于時序的事實事件，事實發生后進入Druid，外部系統就可以對該事實進行查詢。
優點：查詢延遲低，并發能力好，多租戶設計較完善。
適用場景：QPS高的預聚合查詢，不適用于明細查詢，典型適用場景：用戶行為分析，網絡流量分析。
Kylin
kylin是一個MOLAP系統，多維立方體（MOLAP Cube）的設計使得用戶能夠在Kylin里為百億以上數據集定義數據模型并構建立方體進行數據的預聚合。支持大數據生態圈的數據分析業務，主要是通過預計算的方式將用戶設定的多維度數據立方體(cube) 緩存起來，達到快速查詢的目的。應用場景應該是針對復雜sql join后的數據緩存。
優點：主要是對hive中的數據進行預計算，用戶只需提前定義好查詢維度，Kylin將會幫助我們進行計算，并將結果存儲到HBase中，為海量數據的查詢和分析提供亞秒級返回。
適用場景：適合數據量大，查詢維度多，但是業務改動不頻繁的場景。
Doris
Doris是MPP架構的查詢引擎，整體架構非常簡單，只有FE、BE兩個服務，FE負責SQL解析、規劃以及元數據存儲，BE負責SQL-Plan的執行以及數據的存儲，整體運行不依賴任何第三方系統，功能也非常豐富如支持豐富的數據更新模型、MySQL協議、智能路由等。不僅能夠在亞秒級響應時間即可獲得查詢結果，有效的支持實時數據分析，而且支持PB級別的超大數據集，對于業務線部署運維到使用都非常友好。
優點：支持標準的SQL語法，同時支持明細和聚合的高并發查詢，支持多表join和在線schema變更。
適用場景：適用于高并發的明細和多表關聯聚合查詢。典型場景：高并發分析報表、即席查詢、實時播報大屏。
Clickhouse
ClickHouse從OLAP場景需求出發，定制開發了一套全新的高效列式存儲引擎，并且實現了數據有序存儲、主鍵索引、稀疏索引、數據Sharding、數據Partitioning、TTL、主備復制等豐富功能。以上功能共同為ClickHouse極速的分析性能奠定了基礎。但是Clickhouse也有它的局限性，在OLAP技術選型的時候，應該避免把它作為多表關聯查詢(JOIN)的引擎，也應該避免把它用在期望支撐高并發數據查詢的場景，Clickhouse的執行模型決定了它會盡全力來執行一個Query，而不是同時執行很多Query。所以它更適合對時效性要求高，QPS低于1000的類似企業內部BI報表等應用，而不適合如數十萬的廣告主報表或者數百萬的淘寶店主相關報表應用。
優點：向量化SQL查詢引擎，單表查詢性能強悍、可以基于明細數據靈活聚合查詢。
適用場景：QPS中等的明細查詢及聚合查詢，不適用于qps很高的場景，也不適用于多表join的場景，典型適用場景：交易數據分析，商業數據分析。

二、應用場景及整體方案

首先是日常交易、售后業務等業務板塊的數據自助分析。運營業務側需要實時統計訂單銷量、商品庫存相關指標，估算訂單的單量、增速是否達到策略的預期效果，庫存異常波動原因、庫存及時調動補充等。售后客服側則需要根據實時指標去評估日常工作，更好的開展管理工作。

另外一個場景是大促活動期間的實時看板展示，在大型活動促銷期間需要整個供應鏈和銷售的實時數據，從用戶流量到用戶轉化到訂單、商品、庫存等漏斗分析，讓運營側可以按照當前的數據及時調整活動策略，提升轉化率。對大促活動期間的指標分析，也是一個很典型的多維分析的過程，OLAP平臺要滿足每天幾萬次的查詢調用需求，查詢的時延要保證在百毫秒級。

OLAP平臺選型時對公司多個業務團隊的需求做了調研，總結來講，大家對以下幾個點關注度會比較高，比如超大數據規模的支持，單個數據源可能每天有上十億的數據量需要錄入；查詢時延，要保證在毫秒到秒級；數據實時性，很多業務線明確提出實時數據分析的需求；另外還有高并發查詢、平臺穩定性等。

根據對用戶的調研，以及對比了各種OLAP在不同場景下的應用，我們得出了如下的OLAP分析架構圖：

三、OLAP的使用優化實踐

3.1 druid的優化

物化視圖

什么是物化視圖，假設一個數據源的原始維度有十個列，通過分析查詢請求發現，group1中的三個維度和group2中的三個維度分別經常同時出現，剩余的四個維度可能查詢頻率很低。更加嚴重的是，沒有被查詢的維度列里面有一個是高基維，就是 count district 值很大的維度，比如說像 User id 這種。這種情況下會存在很大的查詢性能問題，因為高基維度會影響 Druid 的數據預聚合效果，聚合效果差就會導致索引文件 Size 變大，進而導致查詢時的讀 IO 變大，整體查詢性能變差。針對這種 case 的優化，我們會將 group1 和 group2 這種維度分別建一個預聚合索引，然后當收到新的查詢請求，系統會先分析請求里要查詢維度集合，如果要查詢的維度集合是剛才新建的專用的索引維度集合的一個子集，則直接訪問剛才新建的索引就可以，不需要去訪問原始的聚合索引，查詢的性能會有一個比較明顯的改善，這就是物化視圖的一個設計思路，也是一個典型的用空間換時間的方案。

緩存查詢

為了提升整體查詢速度，我們引入了 Redis 作為緩存，如果只是簡單的按照每次查詢 sql 結果進行緩存的話則存在一個問題，每次不同用戶查詢的時間周期不一致，導致命中緩存的比例較低，查詢性能提升不是很明顯。為了提高緩存復用率，我們需要增加一套新的緩存機制：我們按照拆解表的最細時間粒度，按照天和小時進行數據的緩存。當用戶進行查詢的如果只是部分時間跨度的結果命中 redis ，則只查詢未命中的時間跨度，然后將查詢的結果和 redis 中的緩存數據拼接返回給用戶，進而提升查詢效率。

冷熱數據分層

通過配置每個節點的數據分配策略，讓高頻查詢的數據盡量多的分散在不同的broker，減少單個節點的查詢壓力，調整 History Node配置參數。

#集群分片，不寫默認_default_tier
druid.server.tier=hot  
#查詢優先級，不寫默認0，_default_tier分片的兩個節點為0，hot節點的都改為100。這樣，熱數據只會查hot節點的機器。
druid.server.priority=100
#processing.buff，默認是1G
processing.buff = 4G
#processing.numThreads:默認是繁忙時core-1做process，剩余的1個進程做與zk通信和拉取seg等。
druid.processing.buffer.sizeBytes=1073741824
druid.processing.numThreads=30

3.2 clickhouse的優化

distributed 分布式聚合查詢

在 ClickHouse 的聚合查詢中，每個機器都會把自己的聚合的中間狀態返回給分布式節點，也就是說，即使你只是想要Top100，每臺機器也會把自己所擁有的所有枚舉值都返回給分布式節點進行進一步的聚合。ClickHouse 的聚合過程大致如下圖：

開啟分布式查詢優化后的執行圖，如圖所示，可以提前進行數據過濾，提升查詢效率：

跳數索引

clickhouse 數據庫為列式數據庫，其本身并沒傳統關系型數據庫中所指的二級索引，clickhouse 提供了一種適用于列存檢索的跳數索引算法來替代二級索引。

跳數索引類型

minmax
這種輕量級索引類型不需要參數。它存儲每個塊的索引表達式的最小值和最大值(如果表達式是一個元組，它分別存儲元組元素的每個成員的值)。對于傾向于按值松散排序的列，這種類型非常理想。在查詢處理期間，這種索引類型的開銷通常是最小的。
set
這種輕量級索引類型接受單個參數max_size，即每個塊的值集 (0允許無限數量的離散值) 。這個集合包含塊中的所有值 (如果值的數量超過max_size則為空) 。這種索引類型適用于每組顆粒中基數較低 (本質上是“聚集在一起”) 但總體基數較高的列。
Bloom Filter Types
Bloom filter是一種數據結構，它允許對集合成員進行高效的是否存在測試，但代價是有輕微的誤報。在跳數索引的使用場景，假陽性不是一個大問題，因為惟一的問題只是讀取一些不必要的塊。潛在的假陽性意味著索引表達式應該為真，否則有效的數據可能會被跳過。

在生產中只對枚舉值比較多的字段諸如訂單id，商品id用 bloom_filter 跳數索引，其他索引沒有使用，因為 bloom_filter 的索引文件不至于太大，同時對于值比較多的列又能起到比較好的過濾效果。

避免使用final

ClickHouse 中我們可以使用 ReplacintMergeTree 來對數據進行去重，這個引擎可以在數據主鍵相同時根據指定的字段保留一條數據，ReplacingMergeTree 只是在一定程度上解決了數據重復問題，由于自動分區合并機制在后臺定時執行，所以并不能完全保障數據不重復。我們需要在查詢時在最后執行 final 關鍵字，final 執行會導致后臺數據合并，查詢時如果有 final 效率將會極低，我們應當避免使用 final 查詢，那么不使用 final 我們可以通過自己寫SQL方式查詢出想要的數據，舉例如下：

create table t_replacing_table(
id UInt8,
name String,
age UInt8
) engine = ReplacingMergeTree(age)
order by id;

insert into t_replacing_table values (1,'張三',18),(2,'李四',19),(3,'王五',20);
insert into t_replacing_table values (1,'張三',20),(2,'李四',15);

#自己寫SQL方式實現查詢去重后的數據，這樣避免使用final查詢，效率提高
SELECT
    id,
    argMax(name, age) AS namex,
    max(age) AS agex
FROM t_replacing_table
GROUP BY id

四、總結

本文主要介紹了轉轉OLAP分析架構的選型和實踐，通過引入 Druid 和 Clickhouse ，解決了公司當前場景下的多維分析需求。但目前 OLAP 能夠支持的場景還是比較受限，對于高并發的自助分析場景和多表的關聯分析等方面的支持還不友好，后續希望能做一個能夠支持明細、聚合分析，還有關聯場景的 OLAP 平臺，進一步提升公司的實時 OLAP 分析能力。

責任編輯：武曉燕來源：轉轉技術