欢乐颂第一季,已完结小说排行榜

新聞中心

這里有您想知道的互聯(lián)網營銷解決方案

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

一、OLAP技術介紹及選型

OLAP，On-Line Analytical Processing，在線分析處理，主要用于支持企業(yè)決策管理分析。區(qū)別于OLTP，On-Line Transaction Processing，聯(lián)機事務處理。

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

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

我們常說OLTP是數(shù)據(jù)庫的應用，OLAP是數(shù)據(jù)倉庫的應用，兩者主要的區(qū)別如下圖：

1.1 OLAP基本操作

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

鉆?。壕S的層次變化，從粗粒度到細粒度，匯總數(shù)據(jù)下鉆到明細數(shù)據(jù)。eg：通過季度銷售數(shù)據(jù)鉆取每個月的銷售數(shù)據(jù)

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

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

切塊：維區(qū)間數(shù)據(jù)（剩余維三個）。eg：第一季度到第二季度銷售數(shù)據(jù)

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

1.2 OLAP分類

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

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

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

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

二、應用場景及整體方案

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

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

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

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

三、OLAP的使用優(yōu)化實踐

3.1 druid的優(yōu)化

物化視圖

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

緩存查詢

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

冷熱數(shù)據(jù)分層

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

#集群分片，不寫默認_default_tier
druid.server.tier=hot  
#查詢優(yōu)先級，不寫默認0，_default_tier分片的兩個節(jié)點為0，hot節(jié)點的都改為100。這樣，熱數(shù)據(jù)只會查hot節(jié)點的機器。
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的優(yōu)化

distributed 分布式聚合查詢

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

開啟分布式查詢優(yōu)化后的執(zhí)行圖，如圖所示，可以提前進行數(shù)據(jù)過濾，提升查詢效率：

跳數(shù)索引

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

跳數(shù)索引類型

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

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

避免使用final

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

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方式實現(xiàn)查詢去重后的數(shù)據(jù)，這樣避免使用final查詢，效率提高
SELECT
    id,
    argMax(name, age) AS namex,
    max(age) AS agex
FROM t_replacing_table
GROUP BY id

四、總結

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

網站名稱：轉轉實時OLAP分析場景技術選型與應用實踐
當前路徑：http://m.fisionsoft.com.cn/article/coesddp.html