雲棲號資訊：【點擊查看更多行業資訊】
在這裏您可以找到不同行業的第一手的上雲資訊，還在等什麼，快來！
導讀：一次機緣巧合，在研究BI產品技術選型的時候，我接觸到了ClickHouse，瞬間就被其驚人的性能所折服。這款非Hadoop生態、簡單、自成一體的技術組件引起了我極大的好奇。那麼ClickHouse好在哪呢？本文帶你做一個初步瞭解。
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定位乃至因特網都遵循着如此的發展規律。有時我們很難想象，這些在現今社會習以爲常的技術，其實在幾十年前還僅限於服務軍隊這類少數羣體。
每一次技術普惠的浪潮，一方面擴展了技術的受衆，讓更多的人享受到了技術進步帶來的福利；另一方面，由於更多的人接觸到了新的技術，反過來也提升了技術的實用性和完善程度，加速了技術的成長與發展。
如果說汽車、火車和飛機是從物理上拉近了人與人之間的距離，那麼隨着互聯網的興起與風靡，世界的距離從邏輯上再一次被拉近了。現今世界的社會結構與人類行爲，也已然被互聯網深度改造，我們的世界逐漸變得扁平化與碎片化，節奏也越來越快。
根據一項調查，互聯網用戶通常都沒有耐心。例如47%的消費者希望在2秒或更短的時間內完成網頁加載，40%的人放棄了加載時間超過3秒的網站，而頁面響應時間每延遲1秒就可以使轉換率降低7%。實時應答、簡單易用，已經是現代互聯網系統的必備素質。
SaaS模式的興起，爲傳統企業軟件系統的商業模式帶來了新的思路，這是一次新的技術普惠。一方面，SaaS模式將之前只服務於中大型企業的軟件系統放到了互聯網，擴展了它的受衆；另一方面，由於互聯網用戶的基本特徵和軟件訴求，又倒逼了這些軟件系統在方方面面進行革新與升級。
技術普惠，導致現代BI系統在設計思路上發生了天翻地覆的變化。
首先，它變得“很輕”，不再需要強制捆綁於企業數據倉庫這樣的龐然大物之上，就算只根據簡單的Excel文件也能進行數據分析。
其次，它的受衆變得更加多元化，幾乎人人都可以成爲數據分析師。現代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就這樣進入了我的視野。
- 天下武功唯快不破
我對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
- 社區活躍
ClickHouse是一款開源軟件，遵循Apache License 2.0協議，所以它可以被免費使用。同時它的開源社區也非常躍度，其在全球範圍內約有400位貢獻者。
ClickHouse版本發佈頻率驚人，基本保持着每個月發佈一次版本的更新頻率。友好的開源協議、活躍的社區加上積極的響應，意味着我們可以及時獲取最新特性並得到修復缺陷的補丁。
篇幅有限，如果你想了解ClickHouse的更多細節，可以看一看《QQ音樂大數據架構技術演進》這篇文章，並關注我們後續的推送文章，還有下面這本書。
關於作者：朱凱，ClickHouse貢獻者之一，ClickHouse佈道者，資深架構師，騰訊雲最具價值專家TVP，開源愛好者，Apache DolphinScheduler Committer，《企業級大數據平臺構建：架構與實現》作者，公衆號“ClickHouse的祕密基地”運營者。十多年IT從業經驗，對大數據領域主流技術與解決方案有深入研究，擅長分佈式系統的架構設計與整合。
本文摘編自《ClickHouse原理解析與應用實踐》，經出版方授權發佈。
【雲棲號在線課堂】每天都有產品技術專家分享！
課程地址：https://yqh.aliyun.com/zhibo立即加入社羣，與專家面對面，及時瞭解課程最新動態！
【雲棲號在線課堂 社羣】https://c.tb.cn/F3.Z8gvnK
原文發佈時間：2020-06-23
本文作者：朱凱
本文來自：“大數據DT 微信公衆號 ”，瞭解相關信息可以關注“[大數據D](https://mp.weixin.qq.com/s/YHP5Fhla2QplwrSBwokhNA）