1. BI系統(tǒng)的沉浮
1.1 傳統(tǒng)BI之死
為了解決傳統(tǒng)早期IT系統(tǒng)在建設(shè)過程中“煙囪式”的發(fā)展模式，打通相互割裂的“數(shù)據(jù)孤島”，讓用戶擁有站在企業(yè)全局鳥瞰一切數(shù)據(jù)的視角，BI(商業(yè)智能)系統(tǒng)的概念在20世紀90年代被提出，即一種統(tǒng)一面向數(shù)據(jù)倉庫，專注于提供數(shù)據(jù)分析、決策類功能的系統(tǒng)與解決方案。人們通常用BI一詞指代這類分析系統(tǒng)。相對于聯(lián)機事務(wù)處理系統(tǒng)(OLTP)，我們把這類BI系統(tǒng)稱為聯(lián)機分析(OLAP)系統(tǒng)。
但是傳統(tǒng)BI系統(tǒng)的實際的應(yīng)用效果一直是差強人意。其原因至少有一下幾點。
- 對企業(yè)的信息化和數(shù)據(jù)化水平要求較高。需要企業(yè)有完善的信息化系統(tǒng)和統(tǒng)一的數(shù)據(jù)化倉庫來作為技術(shù)支持，否者難以實現(xiàn)“站在企業(yè)視角通盤分析并輔助決策"的定位。
- 狹小的受眾制約了傳統(tǒng)BI系統(tǒng)發(fā)展的生命力。如果主要受眾是企業(yè)中的管理和決策層，這些人雖然有較高的話語權(quán)于系統(tǒng)的參與度和使用度不高，久而久之BI系統(tǒng)就淪為了領(lǐng)導(dǎo)視察、演示的“特供玩具”。
- 冗長的研發(fā)過程滯后了需求的響應(yīng)時效。傳統(tǒng)BI系統(tǒng)多為定制開發(fā)，需要大量IT人員的參與。一個分析Idea從需求的提出到最終實現(xiàn)，可能需要幾周甚至幾個月的時間，滯后性嚴重影響體驗。
1.2 互聯(lián)網(wǎng)大潮下的BI系統(tǒng)新生
互聯(lián)網(wǎng)和云原生SaaS化模式的興起，為BI系統(tǒng)的商業(yè)模式帶來了新的思路:
首先，部署“輕量級化”，即不再需要強制捆綁于企業(yè)數(shù)據(jù)倉庫這樣的龐然大物之上進行數(shù)據(jù)同步，可以對于多種數(shù)據(jù)源直連即用。
其次，使用“多元化”，即使用門檻降低，不需要IT人員的深度參與，用戶直接通過自助的形式，通過簡單拖拽、搜索就能得到自己想要的分析結(jié)果，而不用關(guān)心底層具體的實現(xiàn)方式和數(shù)據(jù)源類型。
最后，體驗“互聯(lián)網(wǎng)化”，即便現(xiàn)代BI系統(tǒng)必須具有快速應(yīng)答、簡單易用的使用體驗。從某種角度來看，經(jīng)過SaaS化這波技術(shù)普惠的洗禮，互聯(lián)網(wǎng)幫助傳統(tǒng)企業(yè)系統(tǒng)在易用性和用戶體驗上進行了革命性提升。
如果說互聯(lián)網(wǎng)和SaaS化這波技術(shù)普惠為現(xiàn)代BI系統(tǒng)帶來了新的思路與契機，那么背后的技術(shù)創(chuàng)新則保障了其思想的落地。
Google于2003~2006年相繼發(fā)表了三篇論文“Google File System”“Google MapReduce”和“Google Bigtable”，將大數(shù)據(jù)的處理技術(shù)帶進了大眾視野。2006年開源項目Hadoop最初指代的是分布式文件系統(tǒng)HDFS和MapReduce計算框架，但是它一路高歌猛進，在此基礎(chǔ)之上像搭積木一般快速發(fā)展成為一個龐大的生態(tài)(包括Yarn、Hive、 HBase、Spark等數(shù)十種之多)。在大量數(shù)據(jù)分析場景的解決方案中， 傳統(tǒng)關(guān)系型數(shù)據(jù)庫很快就被Hadoop生態(tài)所取代。數(shù)據(jù)查詢分析的手段也層出不窮，Spark、 Impala、Kylin等百花齊放。
然而世間并沒有萬全之策， 雖然Hadoop生態(tài)化的屬性帶來了諸多便利性，但生態(tài)化的另一面是臃腫和復(fù)雜。Hadoop生態(tài)下的每種組件都自成一體、相互獨立的格局顯很多場景下都過于笨重了。與此同時，隨著現(xiàn)代化終端系統(tǒng)對實效性的要求越來越高，Hadoop在海量數(shù)據(jù)和高時效性的雙重壓力下，也顯得有些力不從心了。
探索式BI的方向
探索式BI系統(tǒng)，在產(chǎn)品定位與設(shè)計上是帶有互聯(lián)網(wǎng)SaaS化屬性的產(chǎn)品，期望其包括以下特性：
- 更統(tǒng)一：統(tǒng)一的數(shù)據(jù)門戶，管理核心指標和口徑。部門內(nèi)下至數(shù)百條數(shù)據(jù)的個人Excel表格，上至數(shù)億級別的企業(yè)數(shù)據(jù)，都能夠在系統(tǒng)內(nèi)部被直接處理；統(tǒng)一權(quán)限管理，降低管理的復(fù)雜度，提升數(shù)據(jù)安全性。統(tǒng)一數(shù)據(jù)運維，確保系統(tǒng)穩(wěn)定性。
- 更易用：面向普通用戶而非專業(yè)IT人員，通過簡單拖拽或搜索維度，就能完成初步的分析查詢。分析內(nèi)容可以是自定義 的，并不需要預(yù)先固定好。
- 更實時：無論數(shù)據(jù)是什么體量級別，查詢必須在秒級時間內(nèi)返回。數(shù)據(jù)分析是一個通過不斷提出假設(shè)并驗證假設(shè)的過程，只有做到快速應(yīng)答，這種分析過程的路徑才算正確，這也是”探索式“BI的最大的特點。
- 更專業(yè)：需要具備專業(yè)化程度并具備智能化的提升空間，需要提供專業(yè)的數(shù)學統(tǒng)計方法和可視化組件。
為了滿足上述產(chǎn)品特性，開發(fā)人員在底層數(shù)據(jù)庫技術(shù)選型的時候可謂是絞盡腦汁，盡最大可能來選擇合適OLAP技術(shù)方案。
OLPA演進之路
OLAP領(lǐng)域技術(shù)發(fā)展至今可謂百花齊放，但是Mars團隊在技術(shù)調(diào)研后卻發(fā)現(xiàn)可能要面臨無牌可打的窘境。為了解釋這個問題，就要先說清楚OLAP的幾種常見思路。
OLAP名為聯(lián)機分析，又可以稱為多維分析。 顧名思義，它指的是通過多種不同的維度審視數(shù)據(jù)，進行深層次分析。維度可以看作觀察數(shù)據(jù)的一種視角，例如人類能看到的世界是三維的，它包含長、寬、高三個維度。直接一點理解，維度就好比是一張數(shù)據(jù)表的字段，而多維分析則是基于這些字段進行聚合查詢。
可以使用一個立方體的圖像具象化操作，如上圖所示， 對于一張銷售明細表，數(shù)據(jù)立方體可以進行如下操作。
- 下鉆：從高層次向低層次明細數(shù)據(jù)穿透；
- 上卷：和下鉆相反，從低層次向高層次匯聚；
- 切片：觀察立方體的一層，將一個或多個維度設(shè)為單個固定值， 然后觀察剩余的維度；
- 切塊：與切片類似，只是將單個固定值變成多個值。例如將商品 維度固定成“足球”“籃球”和“乒乓球”；
- 旋轉(zhuǎn)：旋轉(zhuǎn)立方體的一面，如果要將數(shù)據(jù)映射到一張二維表，那么就要進行旋轉(zhuǎn)，這就等同于行列置換。
為了實現(xiàn)上述這些操作，將常見的OLAP架構(gòu)大致分成三類。
第一類架構(gòu)稱為ROLAP(Relational OLAP，關(guān)系型OLAP)。它直接使用關(guān)系模型構(gòu)建，數(shù)據(jù)模型常使用星型模型或者雪花模型。這是最先能夠想到，也是最為直接的實現(xiàn)方法。因為OLAP概念在最初提出的時候，就是建立在關(guān)系型數(shù)據(jù)庫之上的。多維分析的操作可以直接轉(zhuǎn)換成SQL查詢。例如，通過上卷操作查看省份的銷售額，就可以轉(zhuǎn)換成類似下面的SQL語句:
select 地區(qū), sum(價格) from Cube group by 地區(qū)；
但是這種架構(gòu)對數(shù)據(jù)的實時處理能力要求很高。如果對一張存有上億行數(shù)據(jù)的數(shù)據(jù)表同時執(zhí)行數(shù)十個字段的GROUP BY查詢，一般的關(guān)系型數(shù)據(jù)庫是難以承受的。
第二類架構(gòu)稱為MOLAP(Multidimensional OLAP，多維型 OLAP)。它的出現(xiàn)是為了緩解ROLAP性能問題。MOLAP使用多維數(shù)組的形式保存數(shù)據(jù)，其核心思想是借助預(yù)先聚合結(jié)果，用更多的存儲空間換得查詢時間的減少。其具體的實現(xiàn)方式是依托立方體模型的概念：首先， 對需要分析的數(shù)據(jù)進行建模，框定需要分析的維度字段；然后通過預(yù)處理的形式，對各種維度進行組合并事先聚合；最后，將聚合結(jié)果以某種索引或者緩存的形式保存起來(通常只保留聚合后的結(jié)果，不存儲明細數(shù)據(jù))。這樣一來，在隨后的查詢過程中，就可以直接利用結(jié)果返回數(shù)據(jù)。
但是這種架構(gòu)也并不完美。維度預(yù)處理可能會導(dǎo)致數(shù)據(jù)膨脹。當維度數(shù)據(jù)基數(shù)較高的時候(高基數(shù)意味著重復(fù)相同的數(shù)據(jù)少)，其立方體預(yù)聚合后的數(shù)據(jù)量可能會達到10到20倍的膨脹。另外，由于使用了預(yù)處理的形式，數(shù)據(jù)立方體會有一定的滯后性，不能實時進行數(shù)據(jù)分析。而且，立方體只保留了聚合后的結(jié)果數(shù)據(jù)，導(dǎo)致無法查詢明細數(shù)據(jù)。
第三類架構(gòu)稱為HOLAP(Hybrid OLAP，混合架構(gòu)的OLAP)。這種思路可以理解成ROLAP和MOLAP兩者的集成，即預(yù)先聚合一些維度，然后在此基礎(chǔ)上再試試聚合計算，算是一種折中的辦法。
在介紹了OLAP幾種主要的架構(gòu)之后，再回來說說Mars技術(shù)選項。
第一種選項稱為傳統(tǒng)關(guān)系型數(shù)據(jù)庫。在這種選擇里，OLAP主要基于以MySQL為數(shù)據(jù)實現(xiàn)。在ROLAP架構(gòu)下，直接使用這些數(shù)據(jù)庫作為存儲與計算的載體；在MOLAP架構(gòu)下，則借助物化視圖的形式實現(xiàn)數(shù)據(jù)立方體。在這個時期，不論是 ROLAP還是MOLAP，在數(shù)據(jù)體量大、維度數(shù)目多的情況下都存在嚴重的性能問題。在Mars項目實戰(zhàn)的場景中，在數(shù)據(jù)量超過80W行后，在KDB上所搭建的Mysql集群需要30s以上才能響應(yīng)結(jié)果，根本無法使用。
第二種選擇為大數(shù)據(jù)技術(shù)。以ROLAP架構(gòu)為例，傳統(tǒng)關(guān)系型數(shù)據(jù)庫就被Hive和SparkSQL所取代。以Spark相比MySQL這類傳統(tǒng)數(shù)據(jù)庫而言，在面向海量數(shù)據(jù)的處理上性能要優(yōu)秀很多，但是它更適合作為一個后端的查詢系統(tǒng)，在實時性上還是太差，動輒幾十秒甚至數(shù)分鐘的響應(yīng)時間，難以滿足用戶需求。再看MOLAP架構(gòu)，MOLAP背后也轉(zhuǎn)為依托MapReduce或Spark等技術(shù)，將其作為立方體的計算引擎，加速立方體的構(gòu)建過程。其預(yù)聚合結(jié)果的存儲載體也轉(zhuǎn)向HBase這類高性能分布式數(shù)據(jù)庫。主流MOLAP架構(gòu)已經(jīng)能夠在億萬級數(shù)據(jù)的體量下實現(xiàn)毫秒級的查詢響應(yīng)時間。盡管如此，MOLAP架構(gòu)依然存在維度爆炸、數(shù)據(jù)同步實時性不高的問題。
總結(jié)而言，以Spark為代表的新一代ROLAP方案雖然可以一站式處理海量數(shù)據(jù)，但無法真正做到實時應(yīng)答和高并發(fā)；而新一代的MOLAP方案雖然解決了大部分查詢性能的瓶頸問題，能夠做到實時應(yīng)答，但數(shù)據(jù)膨脹和預(yù)處理等問題依然沒有被很好解決。不難發(fā)現(xiàn)，雖然OLAP在經(jīng)歷了大數(shù)據(jù)技術(shù)的洗禮之后，其各方面性能已經(jīng)有了脫胎換骨式的改觀，但不論是ROLAP還是MOLAP，仍然存在各自的痛點。
其實，除了上述兩類方案之外，也有一種另辟蹊徑的選擇，即摒棄ROLAP和MOALP轉(zhuǎn)而使用搜索引擎來實現(xiàn)OLAP查詢，ElasticSearch是這類方案的代表。ElasticSearch支持實時更新，在百萬級別數(shù)據(jù)的場景下可以做到實時聚合查詢，但是隨著數(shù)據(jù)體量的繼續(xù)增大，它的查詢性能也將無法保證。
如果單純從模型角度考慮，很明顯ROLAP架構(gòu)更勝一籌。因為關(guān)系模型擁有最好的“群眾基礎(chǔ)”，也更簡單且容易理解。它直接面向明細數(shù)據(jù)查詢，由于不需要預(yù)處理，也就自然沒有預(yù)處理帶來的負面影響(維度組合爆炸、數(shù)據(jù)實時性、更新問題)。
那是否存在這樣一種技術(shù)，它既使用ROLAP模型，同時又擁有比肩MOLAP的性能呢? 答案就是Clickhouse
Clickhouse的橫空出世
ClickHouse 是一個用于聯(lián)機分析 (OLAP) 的列式數(shù)據(jù)庫管理系統(tǒng) (DBMS)。來俄羅斯本土搜索引擎企業(yè)Yandex 公司， 誕生之初就是為了服務(wù) Yandex 公司自家的 Web 流量分析產(chǎn)品 Yandex.Metrica，后來經(jīng)過演變，逐漸形成為現(xiàn)在的 ClickHouse，全稱是:Click Stream, Data WareHouse。
ClickHouse官網(wǎng):https://clickhouse.tech/，其具有 ROLAP、在線實時查詢、完整的 DBMS 功能支持、列式存儲、不需要任何數(shù)據(jù)預(yù)處理、支持批量更新、擁有非常完善的 SQL 持和函數(shù)、支持高可用、不依賴Hadoop復(fù)雜生態(tài)、開箱即用等許多特點。
更讓筆者印象深刻的是其查詢能力。在 1 億數(shù)據(jù)集體量的情況下，ClickHouse 的平均響應(yīng)速度是 Vertica 的 2.63 倍、InfiniDB 的 17 倍、MonetDB 的 27 倍、Hive 的 126 倍、MySQL 的 429 倍以及Greenplum 的 10 倍。詳細的測試結(jié)果可以查閱：https://clickhouse.tech/benchmark/dbms/。
ClickHouse 是近年來備受關(guān)注的開源列式數(shù)據(jù)庫，主要用于數(shù)據(jù)分析(OLAP)領(lǐng)域。目前國內(nèi)社區(qū)火熱，各個大廠紛紛跟進大規(guī)模使用:
今日頭條內(nèi)部用 ClickHouse 來做用戶行為分析，內(nèi)部一共幾千個 ClickHouse 節(jié)點，單集群最大 1200 節(jié)點，總數(shù)據(jù)量幾十 PB，日增原始數(shù)據(jù) 300TB 左右。
騰訊內(nèi)部用 ClickHouse 做游戲數(shù)據(jù)分析，并且為之建立了一整套監(jiān)控運維體系。
攜程內(nèi)部從 18 年 7 月份開始接入試用，目前 80% 的業(yè)務(wù)都跑在 ClickHouse 上。每天數(shù)據(jù)增量十多億，近百萬次查詢請求。
快手內(nèi)部也在使用 ClickHouse，存儲總量大約 10PB， 每天新增 200TB， 90% 查詢小于 3S。
正如上文所述，“世間沒有萬全策”。ClickHouse作為一款高性能OLAP數(shù)據(jù)庫，雖然足夠優(yōu)秀，但也不是萬能的。我們不應(yīng)該把它用于任何OLTP事務(wù)性操作的場景，因為它有以下幾點不足：
- 不支持事務(wù)。
- 為稀疏索引，不擅長根據(jù)主鍵按行粒度進行查詢(雖然支持)，故不應(yīng)該把ClickHouse當作Key-Value數(shù)據(jù)庫使用。
- 缺少高頻率，低延遲的修改或刪除已存在數(shù)據(jù)的能力。
這些弱點并不能視為ClickHouse的缺點，事實上其他同類高性能的OLAP數(shù)據(jù)庫同樣也不擅長上述的這些方面。因為對于一款OLAP數(shù)據(jù)庫而言，上述這些能力并不是重點，只能說這是為了極致查詢性能所做的權(quán)衡。
BI與Clickhouse的一拍即合
ClickHouse非常適用于商業(yè)智能領(lǐng)域(也就Mars所在的BI領(lǐng)域)，是因為在這個BI分析的場景下，ClickHouse的缺點都可以被規(guī)避：
- BI分析場景多為海量數(shù)據(jù)集中的高性能低延遲的單表單張大寬表聚合查詢分析，不關(guān)心數(shù)據(jù)的事務(wù)性；
- BI分析場景絕大部分場景都是范圍聚合，極少按主鍵獲取單行數(shù)據(jù)；
- BI分析分析不會去主動刪除數(shù)據(jù)，不關(guān)心刪除數(shù)據(jù)的性能；
正因Clickhouse擁有ROLAP的標準SQL模型，同時又擁有超越MOLAP的極強查詢性能，正好符合探索式BI的產(chǎn)品目標。在Clickhouse的助力下，可以實現(xiàn)基于RLOAP的實時數(shù)據(jù)分析，成功突破數(shù)據(jù)查詢能力瓶頸。根據(jù)筆者試驗，使用阿里云g5規(guī)格云服務(wù)器（2vCPUs & 8 GB），便可實現(xiàn)如下計算能力：
- 對于8000W行的數(shù)據(jù)規(guī)模，任意維度的聚合查詢可以在4s內(nèi)返回，使用索引和過濾可以在1秒以內(nèi)返回；
- 對于2億行的數(shù)據(jù)規(guī)模，任意維度的聚合查詢可以在9s內(nèi)返回，使用索引和過濾可以在3秒以內(nèi)返回；
后續(xù)筆者將會繼續(xù)介紹Clickhouse架構(gòu)設(shè)計，為大家揭秘其性能突出原因，以及mars上數(shù)據(jù)查詢的實戰(zhàn)內(nèi)容，敬請期待。
