作者介紹

一、OLAP技術(shù)介紹及選型

二、應(yīng)用場景及整體方案

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

四、總結(jié)

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

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

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

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

Druid是采用預(yù)計算的方式。主要解決的是對于大量的基于時序的數(shù)據(jù)進行聚合查詢。Druid提供了實時流數(shù)據(jù)分析，以及高效實時寫入，進入到Druid后立即可查，同時數(shù)據(jù)是幾乎是不可變。通常是基于時序的事實事件，事實發(fā)生后進入Druid，外部系統(tǒng)就可以對該事實進行查詢。

優(yōu)點：查詢延遲低，并發(fā)能力好，多租戶設(shè)計較完善。

適用場景：QPS高的預(yù)聚合查詢，不適用于明細查詢，典型適用場景：用戶行為分析，網(wǎng)絡(luò)流量分析。

kylin是一個MOLAP系統(tǒng)，多維立方體（MOLAP Cube）的設(shè)計使得用戶能夠在Kylin里為百億以上數(shù)據(jù)集定義數(shù)據(jù)模型并構(gòu)建立方體進行數(shù)據(jù)的預(yù)聚合。支持大數(shù)據(jù)生態(tài)圈的數(shù)據(jù)分析業(yè)務(wù)，主要是通過預(yù)計算的方式將用戶設(shè)定的多維度數(shù)據(jù)立方體(cube) 緩存起來，達到快速查詢的目的。應(yīng)用場景應(yīng)該是針對復(fù)雜sql join后的數(shù)據(jù)緩存。

優(yōu)點：主要是對hive中的數(shù)據(jù)進行預(yù)計算，用戶只需提前定義好查詢維度，Kylin將會幫助我們進行計算，并將結(jié)果存儲到HBase中，為海量數(shù)據(jù)的查詢和分析提供亞秒級返回。

適用場景：適合數(shù)據(jù)量大，查詢維度多，但是業(yè)務(wù)改動不頻繁的場景。

Doris是MPP架構(gòu)的查詢引擎，整體架構(gòu)非常簡單，只有FE、BE兩個服務(wù)，F(xiàn)E負責SQL解析、規(guī)劃以及元數(shù)據(jù)存儲，BE負責SQL-Plan的執(zhí)行以及數(shù)據(jù)的存儲，整體運行不依賴任何第三方系統(tǒng)，功能也非常豐富如支持豐富的數(shù)據(jù)更新模型、MySQL協(xié)議、智能路由等。不僅能夠在亞秒級響應(yīng)時間即可獲得查詢結(jié)果，有效的支持實時數(shù)據(jù)分析，而且支持PB級別的超大數(shù)據(jù)集，對于業(yè)務(wù)線部署運維到使用都非常友好。

優(yōu)點：支持標準的SQL語法，同時支持明細和聚合的高并發(fā)查詢，支持多表join和在線schema變更。

適用場景：適用于高并發(fā)的明細和多表關(guān)聯(lián)聚合查詢。典型場景：高并發(fā)分析報表、即席查詢、實時播報大屏。

ClickHouse從OLAP場景需求出發(fā)，定制開發(fā)了一套全新的高效列式存儲引擎，并且實現(xiàn)了數(shù)據(jù)有序存儲、主鍵索引、稀疏索引、數(shù)據(jù)Sharding、數(shù)據(jù)Partitioning、TTL、主備復(fù)制等豐富功能。以上功能共同為ClickHouse極速的分析性能奠定了基礎(chǔ)。但是Clickhouse也有它的局限性，在OLAP技術(shù)選型的時候，應(yīng)該避免把它作為多表關(guān)聯(lián)查詢(JOIN)的引擎，也應(yīng)該避免把它用在期望支撐高并發(fā)數(shù)據(jù)查詢的場景，Clickhouse的執(zhí)行模型決定了它會盡全力來執(zhí)行一個Query，而不是同時執(zhí)行很多Query。所以它更適合對時效性要求高，QPS低于1000的類似企業(yè)內(nèi)部BI報表等應(yīng)用，而不適合如數(shù)十萬的廣告主報表或者數(shù)百萬的淘寶店主相關(guān)報表應(yīng)用。

優(yōu)點：向量化SQL查詢引擎，單表查詢性能強悍、可以基于明細數(shù)據(jù)靈活聚合查詢。

適用場景：QPS中等的明細查詢及聚合查詢，不適用于qps很高的場景，也不適用于多表join的場景，典型適用場景：交易數(shù)據(jù)分析，商業(yè)數(shù)據(jù)分析。

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

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

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

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

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

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

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

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

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

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

這種輕量級索引類型不需要參數(shù)。它存儲每個塊的索引表達式的最小值和最大值(如果表達式是一個元組，它分別存儲元組元素的每個成員的值)。對于傾向于按值松散排序的列，這種類型非常理想。在查詢處理期間，這種索引類型的開銷通常是最小的。

這種輕量級索引類型接受單個參數(shù)max_size，即每個塊的值集 (0允許無限數(shù)量的離散值) 。這個集合包含塊中的所有值 (如果值的數(shù)量超過max_size則為空) 。這種索引類型適用于每組顆粒中基數(shù)較低 (本質(zhì)上是“聚集在一起”) 但總體基數(shù)較高的列。

Bloom filter是一種數(shù)據(jù)結(jié)構(gòu)，它允許對集合成員進行高效的是否存在測試，但代價是有輕微的誤報。在跳數(shù)索引的使用場景，假陽性不是一個大問題，因為惟一的問題只是讀取一些不必要的塊。潛在的假陽性意味著索引表達式應(yīng)該為真，否則有效的數(shù)據(jù)可能會被跳過。

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

ClickHouse 中我們可以使用 ReplacintMergeTree 來對數(shù)據(jù)進行去重，這個引擎可以在數(shù)據(jù)主鍵相同時根據(jù)指定的字段保留一條數(shù)據(jù)，ReplacingMergeTree  只是在一定程度上解決了數(shù)據(jù)重復(fù)問題，由于自動分區(qū)合并機制在后臺定時執(zhí)行，所以并不能完全保障數(shù)據(jù)不重復(fù)。我們需要在查詢時在最后執(zhí)行 final 關(guān)鍵字，final 執(zhí)行會導(dǎo)致后臺數(shù)據(jù)合并，查詢時如果有 final 效率將會極低，我們應(yīng)當避免使用 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)查詢?nèi)ブ睾蟮臄?shù)據(jù)，這樣避免使用final查詢，效率提高SELECT    id,    argMax(name, age) AS namex,    max(age) AS agexFROM t_replacing_tableGROUP BY id

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