炸！撩下 OLAP 數(shù)據(jù)分析的黑馬神器 ClickHouse

互聯(lián)網(wǎng)兩大巨獸，西谷歌，東炎帝！

谷歌我們都知道，全世界有名的搜索引擎公司。那么炎帝，是中國那個老祖宗-炎帝么？

搞笑，當(dāng)然不是！

炎帝是我硬翻的，英語 6 級，才疏學(xué)淺，不夠用。原詞是 Yandex, 俄羅斯的一家互聯(lián)網(wǎng)公司。做搜索業(yè)務(wù)，與谷歌齊名。

認(rèn)識這家公司，倒不是我要去俄羅斯宣傳 SQL. 而是這家公司做了款牛皮到炸天的 OLAP 分析工具 ClickHouse.

ClickHouse = Click Stream + Data Warehouse

這并不是我 YY 的單詞組合，炎帝（Yandex) , 就是這么宣傳的。

說起 OLAP，容我賣下情懷，插播一段回憶。

2008年時，昕姐(我媳婦兒）和我還在無錫華潤，做 SAP/R3 開發(fā)。

公司活少，人好，周末活動緊湊，兩個人又都是不留錢的主，每月收入 5000 塊，悉數(shù)花個精光，小日子過得忘乎所以。

也不知道昕姐哪天受了刺激，要求我開發(fā)一套家庭用的資產(chǎn)管理 MIS（management of information system).

好歹我也會點(diǎn) VFP + SQL Server. 封閉式開發(fā)了一個周末，這套資產(chǎn)管理系統(tǒng)就出來了。

現(xiàn)在想想，太特么幼稚了。5000塊，還資產(chǎn)管理，哈哈。

當(dāng)時，卻覺得蠻好玩。還在昕姐面前漲了面兒。

但，任何 MIS 投入使用，便開啟一個大坑。

首先是界面美化。當(dāng)時，前端沒有那么火和騷，一個 FORM（表單）解決問題。調(diào)調(diào)背景色和線框樣式，也就過去了。

最大的問題，來自數(shù)據(jù)分析。昕姐提出來兩個報(bào)表：

• 每日消費(fèi)統(tǒng)計(jì)圖，并可以匯總成周/月/年的統(tǒng)計(jì)
• 消費(fèi)明細(xì)統(tǒng)計(jì)圖，按照時間粒度做分計(jì)

這兩個要求，讓當(dāng)時的我，觸摸到了 OLAP 的邊。

你看，一個對象對 SQL BOY 的影響，就是這么大！

一開始，用 vfp 編程， 在表單上劃線。折線圖非常硬，特別直男的那種。沒有一點(diǎn)柔和感，粗細(xì)不好調(diào)。數(shù)據(jù)一多，那鋸齒畫面，看得我一臉緊張。還沒昕姐在 excel 上做的好。

于是想著，excel 2007 作圖居然這么好看，為什么不能用在 vfp 編程中呢。谷歌了下，發(fā)現(xiàn)一個終極難題，vfp9 終結(jié)了開發(fā)，頂多與 excel 2003 集成。想要使用 excel2007 的 DLL庫，必須用 c#.

好嘛，c# 就 c#, 反正經(jīng)過這么幾次折騰，我對 vfp 的前景，也看淡了很多。

于是，買了兩本 c# 的書，趁著月黑風(fēng)高，苦戰(zhàn)了幾個星期。把表單控件，ado.net 編程也都摸了個遍。徹底把家庭資產(chǎn)管理系統(tǒng)改寫了。

終于，報(bào)表像樣了，圖變得潤滑了，柱狀切餅圖，隨手也做掉了。我的腰板再一次硬起來了。

原以為可以喘口氣了。誰知昕姐，笑盈盈地端來了一碗熱雞湯面，同時還端來了新一輪的需求。

原來她想要的日消費(fèi)統(tǒng)計(jì)圖，是把所有的消費(fèi)記錄都拉出來。按照年一行行統(tǒng)計(jì)好，排列成柱狀圖。

如果哪一年消費(fèi)有些高，可以點(diǎn)著那根柱狀圖，進(jìn)去看每個月，進(jìn)而可以找到哪一天，什么種類的消費(fèi)高了。

天哪，這個腦洞怎么想出來的，肯定是那幫財(cái)務(wù)分子教她的！我就說嘛，找媳婦兒不能找財(cái)務(wù)，哪怕沾點(diǎn)邊兒的，那個要求，細(xì)過出前一丁。

我一口一口扒著面，一嘴一嘴的討價(jià)還價(jià)，最終還是接了這個需求。

于是，又是一通搜索，讓我知道了 sql server cube 和 excel pivot chart 這兩樣寶貝。

cube 可以實(shí)現(xiàn)下鉆和上卷的功能，前提是按照維度和度量（組），預(yù)先生成一張大表。然后丟給 cube 服務(wù)器去跑數(shù)據(jù)。

大致的 cube 架構(gòu)如下圖：

excel pivot chart 則是承接 cube 來的數(shù)據(jù)，完成可視化操作。

如今這樣的可視化分析，到處都是，就連PowerBI，也大放異彩！

當(dāng)把最終的產(chǎn)品給昕姐做展現(xiàn)的時候，雖然沒有得到她的極力夸獎，但我內(nèi)心卻異常激動。因?yàn)楹罄m(xù)的事情，老讀者們都知道了。這項(xiàng)新研究，我把它用到公司的MES軟件中，徹底改變了我在公司IT部門的地位，也讓我拿到了薪水翻3番的新工作。

從現(xiàn)在的角度來看，當(dāng)時做的這些基礎(chǔ)的數(shù)據(jù)倉庫和BI工作，是十分初級和粗糙的。但對于大部分的制造業(yè)和服務(wù)業(yè)來說，基本上解決90%的數(shù)據(jù)統(tǒng)計(jì)問題，一點(diǎn)瓶頸都沒有。

美中不足的，有以下3個方面：

• 非實(shí)時
• 維度暴漲
• 極度呆滯

非實(shí)時

這個很好理解。類似 cube 這類預(yù)處理機(jī)制，本質(zhì)上是用空間換時間策略。把聚合的處理，放在了數(shù)據(jù)分析的前道處理工序上。

就如同下面的建模，確定4個維度和1個度量，最后送入 Cube 服務(wù)器做處理：

而這個預(yù)處理，非常耗時。首先需要確定維度和度量，經(jīng)過數(shù)據(jù)建模和ETL，把數(shù)據(jù)聚攏。預(yù)處理后，查詢速度極快。

業(yè)界稱這種處理分析方式為 MOLAP, 即 Multidiemensional OLAP. 它需要一種特殊的數(shù)據(jù)庫服務(wù)，就是聚合計(jì)算引擎。

除了 sql server cube，還有 Oracle, IBM, MySQL 都提供類似的產(chǎn)品。大數(shù)據(jù)界也有類似的產(chǎn)品，Hive, SparkSQL， Impala, Kylin 等。這些大數(shù)據(jù)產(chǎn)品的實(shí)現(xiàn)原理，也基本都衍生于 ?MapReduce.

維度暴漲

前面說到 MOLAP 的本質(zhì)是預(yù)計(jì)算，針對特定維度組合，把預(yù)計(jì)算的統(tǒng)計(jì)值，存在數(shù)組里。等到分析時，根據(jù)維度組合索引，就能快速定位到具體的統(tǒng)計(jì)值。

在下面的數(shù)據(jù)立方體(Cube)中，預(yù)先計(jì)算了聚合的值。立方體的每條邊，都視作一個維度。每個小碎格，代表了維度相交，聚合出來的度量值。立方體代表了3維，如果有更多維，則預(yù)處理會更加復(fù)雜。

但是分析的時候，我們并不是每次都需要全部的維度。有時候僅需要其中2-3個維度，但是預(yù)處理引擎卻是要把所有維度的組合，都算進(jìn)來。

假設(shè)有 n 個維度，需要組合計(jì)算的種類，就有 2^n 個。比如 10個維度，那么維度組合就有1024種，這會是個巨大無比的集合。

顯然，這不僅浪費(fèi)資源，還容易拖累查詢速度。

極度呆滯

在數(shù)據(jù)被送入 cube 處理之前，需要對表結(jié)構(gòu)做特殊處理。這種處理方式，就是大家經(jīng)常聽到的維度建模。

在 cube 引擎中，流淌的不是一行行數(shù)據(jù)，而是一個個維度和基于這些維度組合附加的度量。這么說肯定很抽象，什么是維度，什么是度量？聽上去和表結(jié)構(gòu)似乎沒什么關(guān)系，初學(xué)者也很難搞清楚。

再舉個栗子，就拿籃球運(yùn)動員奧尼爾來說，年齡，身高，帶球速度，就是他的維度；而打過多少場球賽，勝多少場，平多少場，輸多少場，就是他的度量。比如20歲，以216公分身高，147公斤體重，搶得籃板球2個，勝3場球賽。這樣一條記錄，可以為其建模為：

age?height??weight??board_score?win_time
20??216?????147?????2???????????3

這樣一來，維度和度量，其實(shí)非常明確。年齡，身高，體重是維度，籃板個數(shù)，勝負(fù)數(shù)是度量。

數(shù)據(jù)被整理成這種格式后，就可以送入 cube 做處理。但，也因?yàn)槭沁@樣的預(yù)整理模式，束縛了 cube 的計(jì)算能力。

我們要增加一維，比如教練，就需要重新整理數(shù)據(jù)表，而 cube 也需要重新做一次全處理，而不是增量處理。全處理，意味著需要把整張表掃描，根據(jù)維度組合，生成預(yù)聚合。

很顯然，這樣的預(yù)處理，對于維度經(jīng)常變動的數(shù)據(jù)，是沒有優(yōu)勢的，缺少靈活性。如今的互聯(lián)網(wǎng)形態(tài)，每分鐘數(shù)據(jù)都有新的維度產(chǎn)生，因此cube的處理方式，變得力不從心。

此時， 黑馬 Clickhouse 出場了。它帶著新型的處理方式，來了。他來了，她終于來了。

它摒棄預(yù)處理方式，以實(shí)時維度組合，閃電般地計(jì)算聚合。增加維度，一維，兩維，三維，都不需要做任何延遲計(jì)算，在數(shù)據(jù)表生成的那一剎那，查詢既結(jié)果。它是真正的 ROLAP. 意味著，不需要多一層像 cube 一樣的多維數(shù)據(jù)庫引擎，來加快查詢速度。

它解決了傳統(tǒng) cube 的所有缺點(diǎn)。

以上的分享，靈感來自于這本書《ClickHouse原理解析與應(yīng)用實(shí)踐》。感謝機(jī)械工業(yè)出版社華章趙靜編輯的贈書。這是國內(nèi)第一本詳細(xì)介紹clickhouse的書，作者也是 clickhouse 代碼的貢獻(xiàn)者，非常值得一看。

迫不及待，我已經(jīng)在春節(jié)期間，開始本次CH之旅。

全書總共分為11章:

第1章 介紹ClickHouse的由來、發(fā)展歷程、核心特點(diǎn)與核心特點(diǎn)。

第2~6章 介紹了ClickHouse基礎(chǔ)使用部分，包括整體架構(gòu)、如何安裝、數(shù)據(jù)定義、數(shù)據(jù)引擎、數(shù)據(jù)查詢和函數(shù)的特性和使用方法。

第7~9章介紹了ClickHouse高級特性部分，包括數(shù)據(jù)庫管理操作，數(shù)據(jù)分片、數(shù)據(jù)副本和高可用的特性和使用方法。

第10~11章介紹了如果自己手動實(shí)現(xiàn)ClickHouse中間件的思路和示例，同時也介紹了幾款可視化工具與ClickHouse集成的方法。