作者介紹

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

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

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

四、總結(jié)

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

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

當(dāng)業(yè)務(wù)發(fā)展到一定程度，積累了一些數(shù)據(jù)的時(shí)候，對過去發(fā)生的事情做一個(gè)總結(jié)分析的需求就會產(chǎn)生，這類需求往往需要把過去一段時(shí)間內(nèi)產(chǎn)生的數(shù)據(jù)拿出來進(jìn)行統(tǒng)計(jì)分析，從中獲取我們想要的信息，為公司做決策提供支持，我們管這類場景就叫做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ù)計(jì)算的方式。主要解決的是對于大量的基于時(shí)序的數(shù)據(jù)進(jìn)行聚合查詢。Druid提供了實(shí)時(shí)流數(shù)據(jù)分析，以及高效實(shí)時(shí)寫入，進(jìn)入到Druid后立即可查，同時(shí)數(shù)據(jù)是幾乎是不可變。通常是基于時(shí)序的事實(shí)事件，事實(shí)發(fā)生后進(jìn)入Druid，外部系統(tǒng)就可以對該事實(shí)進(jìn)行查詢。

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

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

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

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

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

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

優(yōu)點(diǎn)：支持標(biāo)準(zhǔn)的SQL語法，同時(shí)支持明細(xì)和聚合的高并發(fā)查詢，支持多表join和在線schema變更。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ClickHouse 中我們可以使用 ReplacintMergeTree 來對數(shù)據(jù)進(jìn)行去重，這個(gè)引擎可以在數(shù)據(jù)主鍵相同時(shí)根據(jù)指定的字段保留一條數(shù)據(jù)，ReplacingMergeTree  只是在一定程度上解決了數(shù)據(jù)重復(fù)問題，由于自動分區(qū)合并機(jī)制在后臺定時(shí)執(zhí)行，所以并不能完全保障數(shù)據(jù)不重復(fù)。我們需要在查詢時(shí)在最后執(zhí)行 final 關(guān)鍵字，final 執(zhí)行會導(dǎo)致后臺數(shù)據(jù)合并，查詢時(shí)如果有 final 效率將會極低，我們應(yīng)當(dā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方式實(shí)現(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)的選型和實(shí)踐，通過引入 Druid 和 Clickhouse ，解決了公司當(dāng)前場景下的多維分析需求。但目前 OLAP 能夠支持的場景還是比較受限，對于高并發(fā)的自助分析場景和多表的關(guān)聯(lián)分析等方面的支持還不友好，后續(xù)希望能做一個(gè)能夠支持明細(xì)、聚合分析，還有關(guān)聯(lián)場景的 OLAP 平臺，進(jìn)一步提升公司的實(shí)時(shí) OLAP 分析能力。