1. BI系統的沉浮

1.1 傳統BI之死

為了解決傳統早期IT系統在建設過程中“煙囪式”的發展模式，打通相互割裂的“數據孤島”，讓用戶擁有站在企業全局鳥瞰一切數據的視角，BI(商業智能)系統的概念在20世紀90年代被提出，即一種統一面向數據倉庫，專注于提供數據分析、決策類功能的系統與解決方案。人們通常用BI一詞指代這類分析系統。相對于聯機事務處理系統(OLTP)，我們把這類BI系統稱為聯機分析(OLAP)系統。

image-20210727183612222

但是傳統BI系統的實際的應用效果一直是差強人意。其原因至少有一下幾點。

• 對企業的信息化和數據化水平要求較高。需要企業有完善的信息化系統和統一的數據化倉庫來作為技術支持，否者難以實現“站在企業視角通盤分析并輔助決策"的定位。
• 狹小的受眾制約了傳統BI系統發展的生命力。如果主要受眾是企業中的管理和決策層，這些人雖然有較高的話語權于系統的參與度和使用度不高，久而久之BI系統就淪為了領導視察、演示的“特供玩具”。
• 冗長的研發過程滯后了需求的響應時效。傳統BI系統多為定制開發，需要大量IT人員的參與。一個分析Idea從需求的提出到最終實現，可能需要幾周甚至幾個月的時間，滯后性嚴重影響體驗。

1.2 互聯網大潮下的BI系統新生

互聯網和云原生SaaS化模式的興起，為BI系統的商業模式帶來了新的思路:

• 首先，部署“輕量級化”，即不再需要強制捆綁于企業數據倉庫這樣的龐然大物之上進行數據同步，可以對于多種數據源直連即用。

• 其次，使用“多元化”，即使用門檻降低，不需要IT人員的深度參與，用戶直接通過自助的形式，通過簡單拖拽、搜索就能得到自己想要的分析結果，而不用關心底層具體的實現方式和數據源類型。

• 最后，體驗“互聯網化”，即便現代BI系統必須具有快速應答、簡單易用的使用體驗。從某種角度來看，經過SaaS化這波技術普惠的洗禮，互聯網幫助傳統企業系統在易用性和用戶體驗上進行了革命性提升。

如果說互聯網和SaaS化這波技術普惠為現代BI系統帶來了新的思路與契機，那么背后的技術創新則保障了其思想的落地。

Google于2003~2006年相繼發表了三篇論文“Google File System”“Google MapReduce”和“Google Bigtable”，將大數據的處理技術帶進了大眾視野。2006年開源項目Hadoop最初指代的是分布式文件系統HDFS和MapReduce計算框架，但是它一路高歌猛進，在此基礎之上像搭積木一般快速發展成為一個龐大的生態(包括Yarn、Hive、 HBase、Spark等數十種之多)。在大量數據分析場景的解決方案中， 傳統關系型數據庫很快就被Hadoop生態所取代。數據查詢分析的手段也層出不窮，Spark、 Impala、Kylin等百花齊放。

然而世間并沒有萬全之策， 雖然Hadoop生態化的屬性帶來了諸多便利性，但生態化的另一面是臃腫和復雜。Hadoop生態下的每種組件都自成一體、相互獨立的格局顯很多場景下都過于笨重了。與此同時，隨著現代化終端系統對實效性的要求越來越高，Hadoop在海量數據和高時效性的雙重壓力下，也顯得有些力不從心了。

探索式BI的方向

探索式BI系統，在產品定位與設計上是帶有互聯網SaaS化屬性的產品，期望其包括以下特性：

• 更統一：統一的數據門戶，管理核心指標和口徑。部門內下至數百條數據的個人Excel表格，上至數億級別的企業數據，都能夠在系統內部被直接處理；統一權限管理，降低管理的復雜度，提升數據安全性。統一數據運維，確保系統穩定性。
• 更易用：面向普通用戶而非專業IT人員，通過簡單拖拽或搜索維度，就能完成初步的分析查詢。分析內容可以是自定義 的，并不需要預先固定好。
• 更實時：無論數據是什么體量級別，查詢必須在秒級時間內返回。數據分析是一個通過不斷提出假設并驗證假設的過程，只有做到快速應答，這種分析過程的路徑才算正確，這也是”探索式“BI的最大的特點。
• 更專業：需要具備專業化程度并具備智能化的提升空間，需要提供專業的數學統計方法和可視化組件。

為了滿足上述產品特性，開發人員在底層數據庫技術選型的時候可謂是絞盡腦汁，盡最大可能來選擇合適OLAP技術方案。

OLPA演進之路

OLAP領域技術發展至今可謂百花齊放，但是Mars團隊在技術調研后卻發現可能要面臨無牌可打的窘境。為了解釋這個問題，就要先說清楚OLAP的幾種常見思路。

OLAP名為聯機分析，又可以稱為多維分析。 顧名思義，它指的是通過多種不同的維度審視數據，進行深層次分析。維度可以看作觀察數據的一種視角，例如人類能看到的世界是三維的，它包含長、寬、高三個維度。直接一點理解，維度就好比是一張數據表的字段，而多維分析則是基于這些字段進行聚合查詢。

image-20210727184157147

可以使用一個立方體的圖像具象化操作，如上圖所示， 對于一張銷售明細表，數據立方體可以進行如下操作。

• 下鉆：從高層次向低層次明細數據穿透；
• 上卷：和下鉆相反，從低層次向高層次匯聚；
• 切片：觀察立方體的一層，將一個或多個維度設為單個固定值， 然后觀察剩余的維度；
• 切塊：與切片類似，只是將單個固定值變成多個值。例如將商品 維度固定成“足球”“籃球”和“乒乓球”；
• 旋轉：旋轉立方體的一面，如果要將數據映射到一張二維表，那么就要進行旋轉，這就等同于行列置換。

為了實現上述這些操作，將常見的OLAP架構大致分成三類。

第一類架構稱為ROLAP(Relational OLAP，關系型OLAP)。它直接使用關系模型構建，數據模型常使用星型模型或者雪花模型。這是最先能夠想到，也是最為直接的實現方法。因為OLAP概念在最初提出的時候，就是建立在關系型數據庫之上的。多維分析的操作可以直接轉換成SQL查詢。例如，通過上卷操作查看省份的銷售額，就可以轉換成類似下面的SQL語句:

select 地區, sum(價格) from Cube group by 地區；

image-20210727183404260

但是這種架構對數據的實時處理能力要求很高。如果對一張存有上億行數據的數據表同時執行數十個字段的GROUP BY查詢，一般的關系型數據庫是難以承受的。

第二類架構稱為MOLAP(Multidimensional OLAP，多維型 OLAP)。它的出現是為了緩解ROLAP性能問題。MOLAP使用多維數組的形式保存數據，其核心思想是借助預先聚合結果，用更多的存儲空間換得查詢時間的減少。其具體的實現方式是依托立方體模型的概念：首先， 對需要分析的數據進行建模，框定需要分析的維度字段；然后通過預處理的形式，對各種維度進行組合并事先聚合；最后，將聚合結果以某種索引或者緩存的形式保存起來(通常只保留聚合后的結果，不存儲明細數據)。這樣一來，在隨后的查詢過程中，就可以直接利用結果返回數據。

但是這種架構也并不完美。維度預處理可能會導致數據膨脹。當維度數據基數較高的時候(高基數意味著重復相同的數據少)，其立方體預聚合后的數據量可能會達到10到20倍的膨脹。另外，由于使用了預處理的形式，數據立方體會有一定的滯后性，不能實時進行數據分析。而且，立方體只保留了聚合后的結果數據，導致無法查詢明細數據。

第三類架構稱為HOLAP(Hybrid OLAP，混合架構的OLAP)。這種思路可以理解成ROLAP和MOLAP兩者的集成，即預先聚合一些維度，然后在此基礎上再試試聚合計算，算是一種折中的辦法。

image-20210727183713512

在介紹了OLAP幾種主要的架構之后，再回來說說Mars技術選項。

第一種選項稱為傳統關系型數據庫。在這種選擇里，OLAP主要基于以MySQL為數據實現。在ROLAP架構下，直接使用這些數據庫作為存儲與計算的載體；在MOLAP架構下，則借助物化視圖的形式實現數據立方體。在這個時期，不論是 ROLAP還是MOLAP，在數據體量大、維度數目多的情況下都存在嚴重的性能問題。在Mars項目實戰的場景中，在數據量超過80W行后，在KDB上所搭建的Mysql集群需要30s以上才能響應結果，根本無法使用。

第二種選擇為大數據技術。以ROLAP架構為例，傳統關系型數據庫就被Hive和SparkSQL所取代。以Spark相比MySQL這類傳統數據庫而言，在面向海量數據的處理上性能要優秀很多，但是它更適合作為一個后端的查詢系統，在實時性上還是太差，動輒幾十秒甚至數分鐘的響應時間，難以滿足用戶需求。再看MOLAP架構，MOLAP背后也轉為依托MapReduce或Spark等技術，將其作為立方體的計算引擎，加速立方體的構建過程。其預聚合結果的存儲載體也轉向HBase這類高性能分布式數據庫。主流MOLAP架構已經能夠在億萬級數據的體量下實現毫秒級的查詢響應時間。盡管如此，MOLAP架構依然存在維度爆炸、數據同步實時性不高的問題。

總結而言，以Spark為代表的新一代ROLAP方案雖然可以一站式處理海量數據，但無法真正做到實時應答和高并發；而新一代的MOLAP方案雖然解決了大部分查詢性能的瓶頸問題，能夠做到實時應答，但數據膨脹和預處理等問題依然沒有被很好解決。不難發現，雖然OLAP在經歷了大數據技術的洗禮之后，其各方面性能已經有了脫胎換骨式的改觀，但不論是ROLAP還是MOLAP，仍然存在各自的痛點。

其實，除了上述兩類方案之外，也有一種另辟蹊徑的選擇，即摒棄ROLAP和MOALP轉而使用搜索引擎來實現OLAP查詢，ElasticSearch是這類方案的代表。ElasticSearch支持實時更新，在百萬級別數據的場景下可以做到實時聚合查詢，但是隨著數據體量的繼續增大，它的查詢性能也將無法保證。

如果單純從模型角度考慮，很明顯ROLAP架構更勝一籌。因為關系模型擁有最好的“群眾基礎”，也更簡單且容易理解。它直接面向明細數據查詢，由于不需要預處理，也就自然沒有預處理帶來的負面影響(維度組合爆炸、數據實時性、更新問題)。

那是否存在這樣一種技術，它既使用ROLAP模型，同時又擁有比肩MOLAP的性能呢? 答案就是Clickhouse

Clickhouse的橫空出世

ClickHouse 是一個用于聯機分析 (OLAP) 的列式數據庫管理系統 (DBMS)。來俄羅斯本土搜索引擎企業Yandex 公司， 誕生之初就是為了服務 Yandex 公司自家的 Web 流量分析產品 Yandex.Metrica，后來經過演變，逐漸形成為現在的 ClickHouse，全稱是:Click Stream, Data WareHouse。

ClickHouse官網:https://clickhouse.tech/，其具有 ROLAP、在線實時查詢、完整的 DBMS 功能支持、列式存儲、不需要任何數據預處理、支持批量更新、擁有非常完善的 SQL 持和函數、支持高可用、不依賴Hadoop復雜生態、開箱即用等許多特點。

更讓筆者印象深刻的是其查詢能力。在 1 億數據集體量的情況下，ClickHouse 的平均響應速度是 Vertica 的 2.63 倍、InfiniDB 的 17 倍、MonetDB 的 27 倍、Hive 的 126 倍、MySQL 的 429 倍以及Greenplum 的 10 倍。詳細的測試結果可以查閱：https://clickhouse.tech/benchmark/dbms/。

image-20210727201712054

ClickHouse 是近年來備受關注的開源列式數據庫，主要用于數據分析(OLAP)領域。目前國內社區火熱，各個大廠紛紛跟進大規模使用:

• 今日頭條內部用 ClickHouse 來做用戶行為分析，內部一共幾千個 ClickHouse 節點，單集群最大 1200 節點，總數據量幾十 PB，日增原始數據 300TB 左右。

• 騰訊內部用 ClickHouse 做游戲數據分析，并且為之建立了一整套監控運維體系。

• 攜程內部從 18 年 7 月份開始接入試用，目前 80% 的業務都跑在 ClickHouse 上。每天數據增量十多億，近百萬次查詢請求。

• 快手內部也在使用 ClickHouse，存儲總量大約 10PB， 每天新增 200TB， 90% 查詢小于 3S。

正如上文所述，“世間沒有萬全策”。ClickHouse作為一款高性能OLAP數據庫，雖然足夠優秀，但也不是萬能的。我們不應該把它用于任何OLTP事務性操作的場景，因為它有以下幾點不足：

• 不支持事務。
• 為稀疏索引，不擅長根據主鍵按行粒度進行查詢(雖然支持)，故不應該把ClickHouse當作Key-Value數據庫使用。
• 缺少高頻率，低延遲的修改或刪除已存在數據的能力。

這些弱點并不能視為ClickHouse的缺點，事實上其他同類高性能的OLAP數據庫同樣也不擅長上述的這些方面。因為對于一款OLAP數據庫而言，上述這些能力并不是重點，只能說這是為了極致查詢性能所做的權衡。

BI與Clickhouse的一拍即合

ClickHouse非常適用于商業智能領域(也就Mars所在的BI領域)，是因為在這個BI分析的場景下，ClickHouse的缺點都可以被規避：

1. BI分析場景多為海量數據集中的高性能低延遲的單表單張大寬表聚合查詢分析，不關心數據的事務性；
2. BI分析場景絕大部分場景都是范圍聚合，極少按主鍵獲取單行數據；
3. BI分析分析不會去主動刪除數據，不關心刪除數據的性能；

正因Clickhouse擁有ROLAP的標準SQL模型，同時又擁有超越MOLAP的極強查詢性能，正好符合探索式BI的產品目標。在Clickhouse的助力下，可以實現基于RLOAP的實時數據分析，成功突破數據查詢能力瓶頸。根據筆者試驗，使用阿里云g5規格云服務器（2vCPUs & 8 GB），便可實現如下計算能力：

• 對于8000W行的數據規模，任意維度的聚合查詢可以在4s內返回，使用索引和過濾可以在1秒以內返回；
• 對于2億行的數據規模，任意維度的聚合查詢可以在9s內返回，使用索引和過濾可以在3秒以內返回；

后續筆者將會繼續介紹Clickhouse架構設計，為大家揭秘其性能突出原因，以及mars上數據查詢的實戰內容，敬請期待。