導讀：一次機緣巧合，在研究BI產品技術選型的時候，我接觸到了ClickHouse，瞬間就被其驚人的性能所折服。這款非Hadoop生態、簡單、自成一體的技術組件引起了我極大的好奇。那么ClickHouse好在哪呢?本文帶你做一個初步了解。

作者：朱凱

來源：大數據DT（ID：hzdashuju）

01 傳統BI系統之殤

得益于IT技術的迅猛發展，ERP、CRM這類IT系統在電力、金融等多個行業均得以實施。這些系統提供了協助企業完成日常流程辦公的功能，其應用可以看作線下工作線上化的過程，這也是IT時代的主要特征之一，通常我們把這類系統稱為聯機事務處理(OLTP)系統。

企業在生產經營的過程中，并不是只關注諸如流程審批、數據錄入和填報這類工作。站在監管和決策層面，還需要另一種分析類視角，例如分析報表、分析決策等。而IT系統在早期的建設過程中多呈煙囪式發展，數據散落在各個獨立的系統之內，相互割裂、互不相通。

為了解決數據孤島的問題，人們提出了數據倉庫的概念。即通過引入一個專門用于分析類場景的數據庫，將分散的數據統一匯聚到一處。借助數據倉庫的概念，用戶第一次擁有了站在企業全局鳥瞰一切數據的視角。

隨著這個概念被進一步完善，一類統一面向數據倉庫，專注于提供數據分析、決策類功能的系統與解決方案應運而生。最終于20世紀90年代，有人第一次提出了BI(商業智能)系統的概念。自此以后，人們通常用BI一詞指代這類分析系統。相對于聯機事務處理系統，我們把這類BI系統稱為聯機分析(OLAP)系統。

傳統BI系統的設計初衷雖然很好，但實際的應用效果卻不能完全令人滿意。我想之所以會這樣，至少有這么幾個原因。

首先，傳統BI系統對企業的信息化水平要求較高。按照傳統BI系統的設計思路，通常只有中大型企業才有能力實施。因為它的定位是站在企業視角通盤分析并輔助決策的，所以如果企業的信息化水平不高，基礎設施不完善，想要實施BI系統根本無從談起。這已然把許多潛在用戶擋在了門外。

其次，狹小的受眾制約了傳統BI系統發展的生命力。傳統BI系統的主要受眾是企業中的管理層或決策層。這類用戶雖然通常具有較高的話語權和決策權，但用戶基數相對較小。同時他們對系統的參與度和使用度不高，久而久之這類所謂的BI系統就淪為了領導視察、演示的“特供系統”了。

最后，冗長的研發過程滯后了需求的響應時效。傳統BI系統需要大量IT人員的參與，用戶的任何想法，哪怕小到只是想把一張用餅圖展示的頁面換成柱狀圖展示，可能都需要依靠IT人員來實現。一個分析需求從由用戶大腦中產生到最終實現，可能需要幾周甚至幾個月的時間。這種嚴重的滯后性仿佛將人類帶回到了飛鴿傳書的古代。

02 現代BI系統的新思潮

技術普惠是科技進步與社會發展的一個顯著特征。從FM頻段到GPS定位乃至因特網都遵循著如此的發展規律。有時我們很難想象，這些在現今社會習以為常的技術，其實在幾十年前還僅限于服務軍隊這類少數群體。

每一次技術普惠的浪潮，一方面擴展了技術的受眾，讓更多的人享受到了技術進步帶來的福利;另一方面，由于更多的人接觸到了新的技術，反過來也提升了技術的實用性和完善程度，加速了技術的成長與發展。

如果說汽車、火車和飛機是從物理上拉近了人與人之間的距離，那么隨著互聯網的興起與風靡，世界的距離從邏輯上再一次被拉近了?，F今世界的社會結構與人類行為，也已然被互聯網深度改造，我們的世界逐漸變得扁平化與碎片化，節奏也越來越快。

根據一項調查，互聯網用戶通常都沒有耐心。例如47%的消費者希望在2秒或更短的時間內完成網頁加載，40%的人放棄了加載時間超過3秒的網站，而頁面響應時間每延遲1秒就可以使轉換率降低7%。實時應答、簡單易用，已經是現代互聯網系統的必備素質。

SaaS模式的興起，為傳統企業軟件系統的商業模式帶來了新的思路，這是一次新的技術普惠。一方面，SaaS模式將之前只服務于中大型企業的軟件系統放到了互聯網，擴展了它的受眾;另一方面，由于互聯網用戶的基本特征和軟件訴求，又倒逼了這些軟件系統在方方面面進行革新與升級。

技術普惠，導致現代BI系統在設計思路上發生了天翻地覆的變化。

首先，它變得“很輕”，不再需要強制捆綁于企業數據倉庫這樣的龐然大物之上，就算只根據簡單的Excel文件也能進行數據分析。

其次，它的受眾變得更加多元化，幾乎人人都可以成為數據分析師?，F代BI系統不需要IT人員的深度參與，用戶直接通過自助的形式，通過簡單拖拽、搜索就能得到自己想要的分析結果。

最后，由于經過互聯網化的洗禮，即便現代BI系統仍然私有化地部署在企業內部，只服務于企業客戶，但它也必須具有快速應答、簡單易用的使用體驗。從某種角度來看，經過SaaS化這波技術普惠的洗禮，互聯網幫助傳統企業系統在易用性和用戶體驗上進行了革命性提升。

如果說SaaS化這波技術普惠為現代BI系統帶來了新的思路與契機，那么背后的技術創新則保障了其思想的落地。在傳統BI系統的體系中，背后是傳統的關系型數據庫技術(OLTP數據庫)。

為了能夠解決海量數據下分析查詢的性能問題，人們絞盡腦汁，在數據倉庫的基礎上衍生出眾多概念，例如：對數據進行分層，通過層層遞進形成數據集市，從而減少最終查詢的數據體量;提出數據立方體的概念，通過對數據進行預先處理，以空間換時間，提升查詢性能。

然而無論如何努力，設計的局限始終是無法突破的瓶頸。OLTP技術由誕生的那一刻起就注定不是為數據分析而生的，于是很多人將目光投向了新的方向。

Google于2003～2006年相繼發表了三篇論文“Google File System”“Google MapReduce”和“Google Bigtable”，將大數據的處理技術帶進了大眾視野。三篇論文開啟了大數據的技術普惠，Hadoop生態由此開始一發不可收拾，數據分析開啟了新紀元。

2006年開源項目Hadoop的出現，標志著大數據技術普及的開始，大數據技術真正開始走向普羅大眾。長期以來受限于數據庫處理能力而苦不堪言的各路豪杰們，仿佛發現了新大陸，于是一輪波瀾壯闊的技術革新浪潮席卷而來。

從某種角度來看，以使用Hadoop生態為代表的這類非傳統關系型數據庫技術所實現的BI系統，可以稱為現代BI系統。換裝了大馬力發動機的現代BI系統在面對海量數據分析的場景時，顯得更加游刃有余。

然而Hadoop技術也不是銀彈，在現代BI系統的構建中仍然面臨諸多挑戰。在海量數據下要實現多維分析的實時應答，仍舊困難重重。(現代BI系統的典型應用場景是多維分析，某些時候可以直接使用OLAP指代這類場景。)

Hadoop最初指代的是分布式文件系統HDFS和MapReduce計算框架，但是它一路高歌猛進，在此基礎之上像搭積木一般快速發展成為一個龐大的生態(包括Yarn、Hive、HBase、Spark等數十種之多)。在大量數據分析場景的解決方案中，傳統關系型數據庫很快就被Hadoop生態所取代，我所處的BI領域就是其中之一。

傳統關系型數據庫所構建的數據倉庫，被以Hive為代表的大數據技術所取代，數據查詢分析的手段也層出不窮，Spark、Impala、Kylin等百花齊放。Hadoop發展至今，早已上升成為大數據的代名詞，仿佛一提到海量數據分析場景下的技術選型，就非Hadoop生態莫屬。

雖然Hadoop生態化的屬性帶來了諸多便利性，例如分布式文件系統HDFS可以直接作為其他組件的底層存儲(例如HBase、Hive等)，生態內部的組件之間不用重復造輪子，只需相互借力、組合就能形成新的方案。

但生態化的另一面則可以看作臃腫和復雜。Hadoop生態下的每種組件都自成一體、相互獨立，這種強強組合的技術組件有些時候顯得過于笨重了。與此同時，隨著現代化終端系統對實效性的要求越來越高，Hadoop在海量數據和高時效性的雙重壓力下，也顯得有些力不從心了。

03 一匹橫空出世的黑馬

我從2012年正式進入大數據領域，開始從事大數據平臺相關的基礎研發工作。2016年我所在的公司啟動了戰略性創新產品的規劃工作，自此我開始將工作重心轉到設計并研發一款具備現代化SaaS屬性的BI分析類產品上。為了實現人人都是分析師的最終目標，這款BI產品必須至少具備如下特征。

一站式：下至數百條數據的個人Excel表格，上至數億級別的企業數據，都能夠在系統內部被直接處理。

自服務，簡單易用：面向普通用戶而非專業IT人員，通過簡單拖拽或搜索維度，就能完成初步的分析查詢。分析內容可以是自定義的，并不需要預先固定好。

實時應答：無論數據是什么體量級別，查詢必須在毫秒至1秒內返回。數據分析是一個通過不斷提出假設并驗證假設的過程，只有做到快速應答，這種分析過程的路徑才算正確。

專業化、智能化：需要具備專業化程度并具備智能化的提升空間，需要提供專業的數學方法。

為了滿足上述產品特性，我們在進行底層數據庫技術選型的時候可謂是絞盡腦汁。

以Spark為代表的新一代ROLAP方案雖然可以一站式處理海量數據，但無法真正做到實時應答和高并發，它更適合作為一個后端的查詢系統。而新一代的MOLAP方案雖然解決了大部分查詢性能的瓶頸問題，能夠做到實時應答，但數據膨脹和預處理等問題依然沒有被很好解決。

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

難道真的是魚與熊掌不可兼得了嗎?直到有一天，在查閱一份Spark性能報告的時候，我不經意間看到了一篇性能對比的博文。

Spark的對手是一個我從來沒有見過的陌生名字，在10億條測試數據的體量下，Spark這個我心目中的絕對王者，居然被對手打得落花流水，查詢響應時間竟然比對手慢數90%之多。而對手居然只使用了一臺配有i5 CPU、16GB內存和SSD磁盤的普通PC電腦。

我揉了揉眼睛，定了定神，這不是做夢。ClickHouse就這樣進入了我的視野。

1. 天下武功唯快不破

我對ClickHouse的最初印象極為深刻，其具有ROLAP、在線實時查詢、完整的DBMS、列式存儲、不需要任何數據預處理、支持批量更新、擁有非常完善的SQL支持和函數、支持高可用、不依賴Hadoop復雜生態、開箱即用等許多特點。

特別是它那夸張的查詢性能，我想大多數剛接觸ClickHouse的人也一定會因為它的性能指標而動容。在一系列官方公布的基準測試對比中，ClickHouse都遙遙領先對手，這其中不乏一些我們耳熟能詳的名字。

所有用于對比的數據庫都使用了相同配置的服務器，在單個節點的情況下，對一張擁有133個字段的數據表分別在1000萬、1億和10億三種數據體量下執行基準測試，基準測試的范圍涵蓋43項SQL查詢。

在1億數據集體量的情況下，ClickHouse的平均響應速度是Vertica的2.63倍、InfiniDB的17倍、MonetDB的27倍、Hive的126倍、MySQL的429倍以及Greenplum的10倍。

詳細的測試結果可以查閱：

https://clickhouse.yandex/benchmark.html

2. 社區活躍

ClickHouse是一款開源軟件，遵循Apache License 2.0協議，所以它可以被免費使用。同時它的開源社區也非常躍度，其在全球范圍內約有400位貢獻者。

ClickHouse版本發布頻率驚人，基本保持著每個月發布一次版本的更新頻率。友好的開源協議、活躍的社區加上積極的響應，意味著我們可以及時獲取最新特性并得到修復缺陷的補丁。

篇幅有限，如果你想了解ClickHouse的更多細節，可以看一看《QQ音樂大數據架構技術演進》這篇文章，并關注我們后續的推送文章，還有下面這本書。