從Hadoop到ClickHouse現(xiàn)代BI系統(tǒng)有哪些問題？如何解決

1、01傳統(tǒng)BI系統(tǒng)之殤得益于IT技術(shù)的迅猛發(fā)展，ERP、CRM這類IT系統(tǒng)在電力、金融等多個行業(yè)均得以實(shí)施。這些系統(tǒng)提供了協(xié)助企業(yè)完成日常流程辦公的功能，其應(yīng)用可以看作線下工作線上化的過程，這也是IT時代的主要特征之一，通常我們把這類系統(tǒng)稱為聯(lián)機(jī)事務(wù)處理（OLTP）系統(tǒng)。企業(yè)在生產(chǎn)經(jīng)營的過程中，并不是只關(guān)注諸如流程審批、數(shù)據(jù)錄入和填報這類工作。站在監(jiān)管和決策層面，還需要另一種分析類視角，例如分析報表、分析決策等。而IT系統(tǒng)在早期的建設(shè)過程中多呈煙囪式發(fā)展，數(shù)據(jù)散落在各個獨(dú)立的系統(tǒng)之內(nèi)，相互割裂、互不相通。為了解決數(shù)據(jù)孤島的問題，人們提出了數(shù)據(jù)倉庫的概念。即通過引入一個專門用于分析類場景的數(shù)據(jù)庫，

2、將分散的數(shù)據(jù)統(tǒng)一匯聚到一處。借助數(shù)據(jù)倉庫的概念，用戶第一次擁有了站在企業(yè)全局鳥瞰一切數(shù)據(jù)的視角。隨著這個概念被進(jìn)一步完善，一類統(tǒng)一面向數(shù)據(jù)倉庫，專注于提供數(shù)據(jù)分析、決策類功能的系統(tǒng)與解決方案應(yīng)運(yùn)而生。最終于20世紀(jì)90年代，有人第一次提出了BI（商業(yè)智能）系統(tǒng)的概念。自此以后，人們通常用BI一詞指代這類分析系統(tǒng)。相對于聯(lián)機(jī)事務(wù)處理系統(tǒng)，我們把這類BI系統(tǒng)稱為聯(lián)機(jī)分析（OLAP）系統(tǒng)。傳統(tǒng)BI系統(tǒng)的設(shè)計初衷雖然很好，但實(shí)際的應(yīng)用效果卻不能完全令人滿意。我想之所以會這樣，至少有這么幾個原因。首先，傳統(tǒng)BI系統(tǒng)對企業(yè)的信息化水平要求較高。按照傳統(tǒng)BI系統(tǒng)的設(shè)計思路，通常只有中大型企業(yè)才有能力實(shí)施。因

3、為它的定位是站在企業(yè)視角通盤分析并輔助決策的，所以如果企業(yè)的信息化水平不高，基礎(chǔ)設(shè)施不完善，想要實(shí)施BI系統(tǒng)根本無從談起。這已然把許多潛在用戶擋在了門外。其次，狹小的受眾制約了傳統(tǒng)BI系統(tǒng)發(fā)展的生命力。傳統(tǒng)BI系統(tǒng)的主要受眾是企業(yè)中的管理層或決策層。這類用戶雖然通常具有較高的話語權(quán)和決策權(quán)，但用戶基數(shù)相對較小。同時他們對系統(tǒng)的參與度和使用度不高，久而久之這類所謂的BI系統(tǒng)就淪為了領(lǐng)導(dǎo)視察、演示的“特供系統(tǒng)”了。最后，冗長的研發(fā)過程滯后了需求的響應(yīng)時效。傳統(tǒng)BI系統(tǒng)需要大量IT人員的參與，用戶的任何想法，哪怕小到只是想把一張用餅圖展示的頁面換成柱狀圖展示，可能都需要依靠IT人員來實(shí)現(xiàn)。一個分析需

4、求從由用戶大腦中產(chǎn)生到最終實(shí)現(xiàn)，可能需要幾周甚至幾個月的時間。這種嚴(yán)重的滯后性仿佛將人類帶回到了飛鴿傳書的古代。02現(xiàn)代BI系統(tǒng)的新思潮技術(shù)普惠是科技進(jìn)步與社會發(fā)展的一個顯著特征。從FM頻段到GPS定位乃至因特網(wǎng)都遵循著如此的發(fā)展規(guī)律。有時我們很難想象，這些在現(xiàn)今社會習(xí)以為常的技術(shù)，其實(shí)在幾十年前還僅限于服務(wù)軍隊(duì)這類少數(shù)群體。每一次技術(shù)普惠的浪潮，一方面擴(kuò)展了技術(shù)的受眾，讓更多的人享受到了技術(shù)進(jìn)步帶來的福利；另一方面，由于更多的人接觸到了新的技術(shù)，反過來也提升了技術(shù)的實(shí)用性和完善程度，加速了技術(shù)的成長與發(fā)展。如果說汽車、火車和飛機(jī)是從物理上拉近了人與人之間的距離，那么隨著互聯(lián)網(wǎng)的興起與風(fēng)靡，世

5、界的距離從邏輯上再一次被拉近了。現(xiàn)今世界的社會結(jié)構(gòu)與人類行為，也已然被互聯(lián)網(wǎng)深度改造，我們的世界逐漸變得扁平化與碎片化，節(jié)奏也越來越快。根據(jù)一項(xiàng)調(diào)查，互聯(lián)網(wǎng)用戶通常都沒有耐心。例如47%的消費(fèi)者希望在2秒或更短的時間內(nèi)完成網(wǎng)頁加載，40%的人放棄了加載時間超過3秒的網(wǎng)站，而頁面響應(yīng)時間每延遲1秒就可以使轉(zhuǎn)換率降低7%。實(shí)時應(yīng)答、簡單易用，已經(jīng)是現(xiàn)代互聯(lián)網(wǎng)系統(tǒng)的必備素質(zhì)。SaaS模式的興起，為傳統(tǒng)企業(yè)軟件系統(tǒng)的商業(yè)模式帶來了新的思路，這是一次新的技術(shù)普惠。一方面，SaaS模式將之前只服務(wù)于中大型企業(yè)的軟件系統(tǒng)放到了互聯(lián)網(wǎng)，擴(kuò)展了它的受眾；另一方面，由于互聯(lián)網(wǎng)用戶的基本特征和軟件訴求，又倒逼了這些

6、軟件系統(tǒng)在方方面面進(jìn)行革新與升級。技術(shù)普惠，導(dǎo)致現(xiàn)代BI系統(tǒng)在設(shè)計思路上發(fā)生了天翻地覆的變化。首先，它變得“很輕”，不再需要強(qiáng)制捆綁于企業(yè)數(shù)據(jù)倉庫這樣的龐然大物之上，就算只根據(jù)簡單的Excel文件也能進(jìn)行數(shù)據(jù)分析。其次，它的受眾變得更加多元化，幾乎人人都可以成為數(shù)據(jù)分析師?，F(xiàn)代BI系統(tǒng)不需要IT人員的深度參與，用戶直接通過自助的形式，通過簡單拖拽、搜索就能得到自己想要的分析結(jié)果。最后，由于經(jīng)過互聯(lián)網(wǎng)化的洗禮，即便現(xiàn)代BI系統(tǒng)仍然私有化地部署在企業(yè)內(nèi)部，只服務(wù)于企業(yè)客戶，但它也必須具有快速應(yīng)答、簡單易用的使用體驗(yàn)。從某種角度來看，經(jīng)過SaaS化這波技術(shù)普惠的洗禮，互聯(lián)網(wǎng)幫助傳統(tǒng)企業(yè)系統(tǒng)在易用性和

7、用戶體驗(yàn)上進(jìn)行了革命性提升。如果說SaaS化這波技術(shù)普惠為現(xiàn)代BI系統(tǒng)帶來了新的思路與契機(jī)，那么背后的技術(shù)創(chuàng)新則保障了其思想的落地。在傳統(tǒng)BI系統(tǒng)的體系中，背后是傳統(tǒng)的關(guān)系型數(shù)據(jù)庫技術(shù)（OLTP數(shù)據(jù)庫）。為了能夠解決海量數(shù)據(jù)下分析查詢的性能問題，人們絞盡腦汁，在數(shù)據(jù)倉庫的基礎(chǔ)上衍生出眾多概念，例如：對數(shù)據(jù)進(jìn)行分層，通過層層遞進(jìn)形成數(shù)據(jù)集市，從而減少最終查詢的數(shù)據(jù)體量；提出數(shù)據(jù)立方體的概念，通過對數(shù)據(jù)進(jìn)行預(yù)先處理，以空間換時間，提升查詢性能。然而無論如何努力，設(shè)計的局限始終是無法突破的瓶頸。OLTP技術(shù)由誕生的那一刻起就注定不是為數(shù)據(jù)分析而生的，于是很多人將目光投向了新的方向。Google于20

8、032006年相繼發(fā)表了三篇論文“Google File System”“Google MapReduce”和“Google Bigtable”，將大數(shù)據(jù)的處理技術(shù)帶進(jìn)了大眾視野。三篇論文開啟了大數(shù)據(jù)的技術(shù)普惠，Hadoop生態(tài)由此開始一發(fā)不可收拾，數(shù)據(jù)分析開啟了新紀(jì)元。2006年開源項(xiàng)目Hadoop的出現(xiàn)，標(biāo)志著大數(shù)據(jù)技術(shù)普及的開始，大數(shù)據(jù)技術(shù)真正開始走向普羅大眾。長期以來受限于數(shù)據(jù)庫處理能力而苦不堪言的各路豪杰們，仿佛發(fā)現(xiàn)了新大陸，于是一輪波瀾壯闊的技術(shù)革新浪潮席卷而來。從某種角度來看，以使用Hadoop生態(tài)為代表的這類非傳統(tǒng)關(guān)系型數(shù)據(jù)庫技術(shù)所實(shí)現(xiàn)的BI系統(tǒng)，可以稱為現(xiàn)代BI系統(tǒng)。換裝了大

9、馬力發(fā)動機(jī)的現(xiàn)代BI系統(tǒng)在面對海量數(shù)據(jù)分析的場景時，顯得更加游刃有余。然而Hadoop技術(shù)也不是銀彈，在現(xiàn)代BI系統(tǒng)的構(gòu)建中仍然面臨諸多挑戰(zhàn)。在海量數(shù)據(jù)下要實(shí)現(xiàn)多維分析的實(shí)時應(yīng)答，仍舊困難重重。（現(xiàn)代BI系統(tǒng)的典型應(yīng)用場景是多維分析，某些時候可以直接使用OLAP指代這類場景。）Hadoop最初指代的是分布式文件系統(tǒng)HDFS和MapReduce計算框架，但是它一路高歌猛進(jìn)，在此基礎(chǔ)之上像搭積木一般快速發(fā)展成為一個龐大的生態(tài)（包括Yarn、Hive、HBase、Spark等數(shù)十種之多）。在大量數(shù)據(jù)分析場景的解決方案中，傳統(tǒng)關(guān)系型數(shù)據(jù)庫很快就被Hadoop生態(tài)所取代，我所處的BI領(lǐng)域就是其中之一。傳

10、統(tǒng)關(guān)系型數(shù)據(jù)庫所構(gòu)建的數(shù)據(jù)倉庫，被以Hive為代表的大數(shù)據(jù)技術(shù)所取代，數(shù)據(jù)查詢分析的手段也層出不窮，Spark、Impala、Kylin等百花齊放。Hadoop發(fā)展至今，早已上升成為大數(shù)據(jù)的代名詞，仿佛一提到海量數(shù)據(jù)分析場景下的技術(shù)選型，就非Hadoop生態(tài)莫屬。雖然Hadoop生態(tài)化的屬性帶來了諸多便利性，例如分布式文件系統(tǒng)HDFS可以直接作為其他組件的底層存儲（例如HBase、Hive等），生態(tài)內(nèi)部的組件之間不用重復(fù)造輪子，只需相互借力、組合就能形成新的方案。但生態(tài)化的另一面則可以看作臃腫和復(fù)雜。Hadoop生態(tài)下的每種組件都自成一體、相互獨(dú)立，這種強(qiáng)強(qiáng)組合的技術(shù)組件有些時候顯得過于笨重了

11、。與此同時，隨著現(xiàn)代化終端系統(tǒng)對實(shí)效性的要求越來越高，Hadoop在海量數(shù)據(jù)和高時效性的雙重壓力下，也顯得有些力不從心了。03一匹橫空出世的黑馬我從2012年正式進(jìn)入大數(shù)據(jù)領(lǐng)域，開始從事大數(shù)據(jù)平臺相關(guān)的基礎(chǔ)研發(fā)工作。2016年我所在的公司啟動了戰(zhàn)略性創(chuàng)新產(chǎn)品的規(guī)劃工作，自此我開始將工作重心轉(zhuǎn)到設(shè)計并研發(fā)一款具備現(xiàn)代化SaaS屬性的BI分析類產(chǎn)品上。為了實(shí)現(xiàn)人人都是分析師的最終目標(biāo)，這款BI產(chǎn)品必須至少具備如下特征。一站式：下至數(shù)百條數(shù)據(jù)的個人Excel表格，上至數(shù)億級別的企業(yè)數(shù)據(jù)，都能夠在系統(tǒng)內(nèi)部被直接處理。自服務(wù)，簡單易用：面向普通用戶而非專業(yè)IT人員，通過簡單拖拽或搜索維度，就能完成初步的

12、分析查詢。分析內(nèi)容可以是自定義的，并不需要預(yù)先固定好。實(shí)時應(yīng)答：無論數(shù)據(jù)是什么體量級別，查詢必須在毫秒至1秒內(nèi)返回。數(shù)據(jù)分析是一個通過不斷提出假設(shè)并驗(yàn)證假設(shè)的過程，只有做到快速應(yīng)答，這種分析過程的路徑才算正確。專業(yè)化、智能化：需要具備專業(yè)化程度并具備智能化的提升空間，需要提供專業(yè)的數(shù)學(xué)方法。為了滿足上述產(chǎn)品特性，我們在進(jìn)行底層數(shù)據(jù)庫技術(shù)選型的時候可謂是絞盡腦汁。以Spark為代表的新一代ROLAP方案雖然可以一站式處理海量數(shù)據(jù)，但無法真正做到實(shí)時應(yīng)答和高并發(fā)，它更適合作為一個后端的查詢系統(tǒng)。而新一代的MOLAP方案雖然解決了大部分查詢性能的瓶頸問題，能夠做到實(shí)時應(yīng)答，但數(shù)據(jù)膨脹和預(yù)處理等問題依

13、然沒有被很好解決。除了上述兩類方案之外，也有一種另辟蹊徑的選擇，即摒棄ROLAP和MOALP轉(zhuǎn)而使用搜索引擎來實(shí)現(xiàn)OLAP查詢，ElasticSearch是這類方案的代表。ElasticSearch支持實(shí)時更新，在百萬級別數(shù)據(jù)的場景下可以做到實(shí)時聚合查詢，但是隨著數(shù)據(jù)體量的繼續(xù)增大，它的查詢性能也將捉襟見肘。難道真的是魚與熊掌不可兼得了嗎？直到有一天，在查閱一份Spark性能報告的時候，我不經(jīng)意間看到了一篇性能對比的博文。Spark的對手是一個我從來沒有見過的陌生名字，在10億條測試數(shù)據(jù)的體量下，Spark這個我心目中的絕對王者，居然被對手打得落花流水，查詢響應(yīng)時間竟然比對手慢數(shù)90%之多。而

14、對手居然只使用了一臺配有i5 CPU、16GB內(nèi)存和SSD磁盤的普通PC電腦。我揉了揉眼睛，定了定神，這不是做夢。ClickHouse就這樣進(jìn)入了我的視野。1. 天下武功唯快不破我對ClickHouse的最初印象極為深刻，其具有ROLAP、在線實(shí)時查詢、完整的DBMS、列式存儲、不需要任何數(shù)據(jù)預(yù)處理、支持批量更新、擁有非常完善的SQL支持和函數(shù)、支持高可用、不依賴Hadoop復(fù)雜生態(tài)、開箱即用等許多特點(diǎn)。特別是它那夸張的查詢性能，我想大多數(shù)剛接觸ClickHouse的人也一定會因?yàn)樗男阅苤笜?biāo)而動容。在一系列官方公布的基準(zhǔn)測試對比中，ClickHouse都遙遙領(lǐng)先對手，這其中不乏一些我們耳熟能

15、詳?shù)拿帧Ｋ杏糜趯Ρ鹊臄?shù)據(jù)庫都使用了相同配置的服務(wù)器，在單個節(jié)點(diǎn)的情況下，對一張擁有133個字段的數(shù)據(jù)表分別在1000萬、1億和10億三種數(shù)據(jù)體量下執(zhí)行基準(zhǔn)測試，基準(zhǔn)測試的范圍涵蓋43項(xiàng)SQL查詢。在1億數(shù)據(jù)集體量的情況下，ClickHouse的平均響應(yīng)速度是Vertica的2.63倍、InfiniDB的17倍、MonetDB的27倍、Hive的126倍、MySQL的429倍以及Greenplum的10倍。詳細(xì)的測試結(jié)果可以查閱：https:/clickhouse.yandex/benchmark.html2. 社區(qū)活躍ClickHouse是一款開源軟件，遵循Apache License 2.0協(xié)議，所以它可以被免費(fèi)使用。同時它的開源社區(qū)也非常躍度，其在全球范圍內(nèi)約有400位貢獻(xiàn)者。ClickHouse版本發(fā)布頻率驚人，基本保持著每個月發(fā)布一次版本的更新頻率。友好的開源協(xié)議、活躍的社區(qū)加上積極的響應(yīng)，意味著我們可以及時獲取最新特性并得到修復(fù)缺陷的補(bǔ)丁。篇幅有限，如果你想了解ClickHouse的更多細(xì)節(jié)，可以看一看 HYPE