雲栖号資訊：【 點選檢視更多行業資訊】
在這裡您可以找到不同行業的第一手的上雲資訊，還在等什麼，快來！
導讀：一次機緣巧合，在研究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）