1、ClickHouse與其特性
在大數(shù)據(jù)處理場景中袒餐，流處理和批處理使用到的技術大致如下：
批處理會將源業(yè)務系統(tǒng)中的數(shù)據(jù)通過數(shù)據(jù)抽取工具（例如 Sqoop）將數(shù)據(jù)抽取到 HDFS 中楣富，這個過程可以使用 MapReduce绸罗、Spark愉老、Flink 技術對數(shù)據(jù)進行 ETL 清洗處理嚷节，也可以直接將數(shù)據(jù)抽取到 Hive 數(shù)倉中硬萍，一般可以將結構化的數(shù)據(jù)直接抽取到 Hive 數(shù)據(jù)倉庫中扩所，然后使用 HiveSQL 或者 SparkSQL 進行業(yè)務指標分析，如果涉及到的分析業(yè)務非常復雜朴乖，可以使用 Hive 的自定義函數(shù)或者 Spark碌奉、Flink 進行復雜分析，這就是我們通常說的數(shù)據(jù)指標分析寒砖。分析之后的結果可以保存到 Hive赐劣、HBase、MySQL哩都、Redis等魁兼，供后續(xù)查詢使用。一般在數(shù)倉構建中漠嵌，如果指標存入Hive中咐汞，我們可以使用 Sqoop 工具將結果導入到關系型數(shù)據(jù)庫中供后續(xù)查詢。HBase 中更擅長存儲原子性非聚合查詢數(shù)據(jù)儒鹿，如果有大量結果數(shù)據(jù)后期不需要聚合查詢化撕，也可以通過業(yè)務分析處理考慮存入 HBase 中。對于一些查詢需求結果反饋非吃佳祝快的場景可以考慮將結果存入 Redis 中植阴。
對于大多數(shù)企業(yè)構建數(shù)倉之后，會將結果存入到 Hive 中的 DM 層中圾浅。DM 層數(shù)據(jù)存入的是與業(yè)務強相關的報表數(shù)據(jù)掠手，DM 層數(shù)據(jù)是由數(shù)倉中 DWS 層主題寬表聚合統(tǒng)計得到，這種報表層設計適合查詢固定的場景狸捕。對于一些查詢需求多變場景喷鸽，我們也可以使用 Impala 來直接將主題寬表數(shù)據(jù)基于內存進行交互式查詢，對 Web 或者數(shù)據(jù)分析做到交互式返回結果灸拍，使用 Impala 對內存開銷非常大做祝。還有另外一種方式是使用 Kylin 進行預計算砾省，將結果提前計算好存入 Hbase 中，以供后續(xù)交互式查詢結果混槐，Kylin 是使用空間換取時間的一種方式纯蛾，預先將各種維度組合對應的度量計算出來存入 HBase，用戶寫 SQL 交互式查詢的是 HBase 中預計算好的結果數(shù)據(jù)纵隔。最后將數(shù)據(jù)分析結果可以直接對 Web 以接口服務提供使用或者公司內部使用可視化工具展示使用翻诉。
以上無論批處理過程還是流處理過程，使用到的技術幾乎離不開 Hadoop 生態(tài)圈捌刮。
ClickHouse
ClickHouse 是一個開源的碰煌，用于聯(lián)機分析（OLAP）的列式數(shù)據(jù)庫管理系統(tǒng)（DBMS-database manager system），它是面向列的绅作，并允許使用 SQL 查詢芦圾，實時生成分析報告。ClickHouse 最初是一款名為 Yandex Metrica 的產(chǎn)品俄认，主要用于 WEB 流量分析个少。ClickHouse 的全稱是 Click Stream，Data WareHouse眯杏，簡稱 ClickHouse夜焦。
ClickHouse 不是一個單一的數(shù)據(jù)庫，它允許在運行時創(chuàng)建表和數(shù)據(jù)庫岂贩，加載數(shù)據(jù)和運行查詢茫经，而無需重新配置和重新啟動服務器。ClickHouse 同時支持列式存儲和數(shù)據(jù)壓縮萎津，這是對于一款高性能數(shù)據(jù)庫來說是必不可少的特性卸伞。一個非常流行的觀點認為，如果你想讓查詢變得更快锉屈，最簡單且有效的方法是減少數(shù)據(jù)掃描范圍和數(shù)據(jù)傳輸時的大小荤傲，而列式存儲和數(shù)據(jù)壓縮就可以幫助我們實現(xiàn)上述兩點，列式存儲和數(shù)據(jù)壓縮通常是伴生的颈渊，因為一般來說列式存儲是數(shù)據(jù)壓縮的前提遂黍。
OLAP場景的特征
絕大多數(shù)是讀請求。
數(shù)據(jù)以相當大的批次（> 1000行）更新儡炼，而不是單行更新妓湘，或者根本沒有更新查蓉。
已添加到數(shù)據(jù)庫的數(shù)據(jù)不能修改乌询。
對于讀取，從數(shù)據(jù)庫中提取相當多的行豌研，但只提取列的一小部分妹田。
寬表唬党，即每個表包含著大量的列。
查詢相對較少鬼佣，通常每臺服務器每秒查詢數(shù)百次或更少驶拱。
對于簡單查詢，允許延遲大約50毫秒晶衷。
列中的數(shù)據(jù)相對較欣陡佟：數(shù)字和短字符串，例如晌纫，每個URL 60個字節(jié)税迷。
處理單個查詢時需要高吞吐量，每臺服務器每秒可達數(shù)十億行锹漱。
事務不是必須的箭养。
對數(shù)據(jù)一致性要求低。有副本情況下哥牍，寫入一個即可毕泌，后臺自動同步。
每個查詢有一個大表嗅辣。除了他以外撼泛，其他的都很小。
查詢結果明顯小于源數(shù)據(jù)澡谭。數(shù)據(jù)經(jīng)過過濾或聚合坎弯，因此結果適合于單個服務器的RAM中。
通過以上 OLAP 場景分析特點很容易可以看出译暂，OLAP 場景與其他通常業(yè)務場景（例如 OLTP 或 K/V）有很大的不同抠忘，因此想要使用 OLTP 或 Key-Value 數(shù)據(jù)庫去高效的處理分析查詢場景，并不是非常完美的適用方案外永。例如崎脉，使用 OLAP 數(shù)據(jù)庫去處理分析請求通常要優(yōu)于使用 MongoDB 或 Redis 去處理分析請求。
1.1伯顶、完備的DBMS功能
ClickHouse 是一個數(shù)據(jù)庫管理系統(tǒng)囚灼，而不僅是一個數(shù)據(jù)庫，作為數(shù)據(jù)庫管理系統(tǒng)具備完備的管理功能：
- DDL(Data Definition Language - 數(shù)據(jù)定義語言)：可以動態(tài)地創(chuàng)建祭衩、修改或刪除數(shù)據(jù)庫灶体、表和視圖，而無須重啟服務掐暮。
- DML(Data Manipulation Language)：可以動態(tài)查詢蝎抽、插入、修改或刪除數(shù)據(jù)路克。
- 分布式管理：提供集群模式樟结，能夠自動管理多個數(shù)據(jù)庫節(jié)點养交。
- 權限控制：可以按照用戶粒度設置數(shù)據(jù)庫或者表的操作權限，保障數(shù)據(jù)的安全性瓢宦。
- 數(shù)據(jù)備份與恢復：提供了數(shù)據(jù)備份導出與導入恢復機制碎连，滿足生產(chǎn)環(huán)境的要求。
1.2驮履、列式存儲
目前大數(shù)據(jù)存儲有兩種方案可以選擇圃阳，行式存儲(Row-Based)和列式存儲(Column-Based)位岔。
- 行式存儲在數(shù)據(jù)寫入和修改上具有優(yōu)勢趴泌。行存儲的寫入是一次完成的狮惜，如果這種寫入建立在操作系統(tǒng)的文件系統(tǒng)上，可以保證寫入過程的成功或者失敗摘悴，可以保證數(shù)據(jù)的完整性峭梳。列式存儲需要把一行記錄拆分成單列保存，寫入次數(shù)明顯比行存儲多(因為磁頭調度次數(shù)多蹂喻，而磁頭調度是需要時間的葱椭，一般在1ms~10ms)，再加上磁頭需要在盤片上移動和定位花費的時間口四，實際消耗更大孵运。數(shù)據(jù)修改實際上也是一次寫入過程，不同的是蔓彩，數(shù)據(jù)修改是對磁盤上的記錄做刪除標記治笨。行存儲是在指定位置寫入一次，列存儲是將磁盤定位到多個列上分別寫入赤嚼，這個過程仍是行存儲的列數(shù)倍旷赖。所以，行式存儲在數(shù)據(jù)寫入和修改上具有很大優(yōu)勢更卒。
- 列式存儲在數(shù)據(jù)讀取和解析等孵、分析數(shù)據(jù)上具有優(yōu)勢。數(shù)據(jù)讀取時蹂空，行存儲通常將一行數(shù)據(jù)完全讀出俯萌，如果只需要其中幾列數(shù)據(jù)的情況，就會存在冗余列上枕，出于縮短處理時間的考量咐熙，消除冗余列的過程通常是在內存中進行的。列存儲每次讀取的數(shù)據(jù)是集合的一段或者全部辨萍，不存在冗余性問題棋恼。列式存儲中的每一列數(shù)據(jù)類型是相同的，不存在二義性問題，例如蘸泻，某列類型為整型琉苇，那么它的數(shù)據(jù)集合一定是整型數(shù)據(jù)嘲玫，這種情況使數(shù)據(jù)解析變得十分容易悦施。相比之下，行存儲則要復雜得多去团，因為在一行記錄中保存了多種類型的數(shù)據(jù)抡诞，數(shù)據(jù)解析需要在多種數(shù)據(jù)類型之間頻繁轉換，這個操作很消耗CPU土陪，增加了解析的時間昼汗。所以，列式存儲在數(shù)據(jù)讀取和解析數(shù)據(jù)做數(shù)據(jù)分析上更具優(yōu)勢鬼雀。
綜上所述顷窒，行存儲的寫入是一次性完成，消耗的時間比列存儲少源哩，并且能夠保證數(shù)據(jù)的完整性鞋吉，缺點是數(shù)據(jù)讀取過程中會產(chǎn)生冗余數(shù)據(jù)，如果只有少量數(shù)據(jù)励烦，此影響可以忽略谓着，數(shù)量大可能會影響到數(shù)據(jù)的處理效率。列存儲在寫入效率坛掠、保證數(shù)據(jù)完整性上都不如行存儲赊锚，它的優(yōu)勢是在讀取過程，不會產(chǎn)生冗余數(shù)據(jù)屉栓，這對數(shù)據(jù)完整性要求不高的大數(shù)據(jù)處理領域比較重要舷蒲。一般來說，一個 OLAP 類型的查詢可能需要訪問幾百萬或者幾十億行的數(shù)據(jù)友多，但是 OLAP 分析時只是獲取少數(shù)的列阿纤，對于這種場景列式數(shù)據(jù)庫只需要讀取對應的列即可，行式數(shù)據(jù)庫需要讀取所有的數(shù)據(jù)列夷陋，因此這種場景更適合列式數(shù)據(jù)庫欠拾，可以大大提高 OLAP 數(shù)據(jù)分析的效率。ClickHouse 就是一款使用列式存儲的數(shù)據(jù)庫骗绕，數(shù)據(jù)按列進行組織藐窄，屬于同一列的數(shù)據(jù)會被保存在一起，列與列之間也會由不同的文件分別保存酬土，在對 OLAP 場景分析時荆忍，效率很高。
1.3、數(shù)據(jù)壓縮
為了使數(shù)據(jù)在傳輸上更小刹枉，處理起來更快叽唱，可以對數(shù)據(jù)進行壓縮，ClickHouse 默認使用 LZ4 算法壓縮微宝，數(shù)據(jù)總體壓縮比可達 8:1棺亭。
ClickHouse 采用列式存儲，列式存儲相對于行式存儲另一個優(yōu)勢就是對數(shù)據(jù)壓縮的友好性蟋软。例如：有兩個字符串 "'ABCDE"镶摘，"BCD"，現(xiàn)在對它們進行壓縮：
- 壓縮前：
ABCDE_BCD - 壓縮后：
ABCDE_(5,3)
通過以上案例可以看到岳守，壓縮的本質是按照一定步長對數(shù)據(jù)進行匹配掃描凄敢，當發(fā)現(xiàn)重復部分的時候就進行編碼轉換。例如：(5,3) 代表從下劃線往前數(shù)5個字節(jié)湿痢，會匹配上3個字節(jié)長度的重復項涝缝，即 "BCD"。當然譬重，真實的壓縮算法比以上舉例更復雜拒逮，但壓縮的本質就是如此，數(shù)據(jù)中重復性項越多害幅，則壓縮率越高消恍，壓縮率越高，則數(shù)據(jù)體量越小以现，而數(shù)據(jù)體量越小狠怨，則數(shù)據(jù)在網(wǎng)絡中的傳輸越快，對網(wǎng)絡帶寬和磁盤IO的壓力也就越小邑遏。
列式存儲中同一個列的數(shù)據(jù)由于它們擁有相同的數(shù)據(jù)類型和現(xiàn)實語義佣赖，可能具備重復項的可能性更高，更利于數(shù)據(jù)的壓縮记盒。所以 ClickHouse 在數(shù)據(jù)壓縮上比例很大憎蛤。
1.4、向量化執(zhí)行引擎
在計算機系統(tǒng)的體系結構中纪吮，存儲系統(tǒng)是一種層次結構俩檬，典型服務器計算機的存儲層次結構如上圖，上圖表述了 CPU碾盟、CPU 三級緩存棚辽、內存、磁盤數(shù)據(jù)容量與數(shù)據(jù)讀取速度對比冰肴，我們可以看出存儲媒介距離 CPU 越近屈藐，則訪問數(shù)據(jù)的速度越快榔组。
從內存讀取數(shù)據(jù)速度比磁盤讀取數(shù)據(jù)速度要快1000倍，從 CPU 緩存中讀取數(shù)據(jù)的速度比從內存中讀取數(shù)據(jù)的速度最快要快 100 倍联逻，從 CPU 寄存器中讀取數(shù)據(jù)的速度為300ps(1納秒 = 1000皮秒)搓扯，比 CPU 緩存要快3倍還多。從寄存器中訪問數(shù)據(jù)的速度包归，是從內存訪問數(shù)據(jù)速度的300倍锨推，是從磁盤中訪問數(shù)據(jù)速度的30萬倍。
如果能從 CPU 寄存器中訪問數(shù)據(jù)對程序的性能提升意義非凡箫踩，向量化執(zhí)行就是在寄存器層面操作數(shù)據(jù)爱态，為上層應用程序的性能帶來了指數(shù)級的提升谭贪。
向量化執(zhí)行境钟，可以簡單地看作一項消除程序中循環(huán)的優(yōu)化。
為了實現(xiàn)向量化執(zhí)行俭识，需要利用 CPU 的 SIMD(Single Instruction Multiple Data) 指令慨削，即用單條指令操作多條數(shù)據(jù)。現(xiàn)代計算機系統(tǒng)概念中套媚，它是通過數(shù)據(jù)并行以提高性能的一種實現(xiàn)方式缚态，其他的還有指令級并行和線程級并行，它的原理是在 CPU 寄存器層面實現(xiàn)數(shù)據(jù)的并行操作堤瘤。
ClickHouse 列式存儲除了降低 IO 和存儲的壓力之外玫芦，還為向量化執(zhí)行做好了鋪墊，除了讀取磁盤速度快之外本辐，ClickHouse 還利用 SSE4.2 指令集實現(xiàn)向量化執(zhí)行桥帆，為處理數(shù)據(jù)提升很大效率。
1.5慎皱、關系模型與標準SQL查詢
相比 HBase 和 Redis 這類 NoSQL 數(shù)據(jù)庫老虫，ClickHouse 使用關系模型描述數(shù)據(jù)并提供了傳統(tǒng)數(shù)據(jù)庫的概念(數(shù)據(jù)庫、表茫多、視圖和函數(shù)等)祈匙。ClickHouse 完全使用 SQL 作為查詢語言(支持 GROUP BY、ORDER BY天揖、JOIN夺欲、IN 等大部分標準 SQL)，ClickHouse 提供了標準協(xié)議的 SQL 查詢接口今膊，可以與第三方分析可視化系統(tǒng)無縫集成對接些阅。在 SQL 解析方面，ClickHouse 是大小寫敏感万细，SELECT a 與 SELECT A 所代表的語義不同扑眉。
1.6纸泄、多樣化的表引擎
與 MySQL 類似，ClickHouse 也將存儲部分進行了抽象腰素，把存儲引擎作為一層獨立的接口聘裁。ClickHouse 擁有各種表引擎，每種表引擎決定不同的數(shù)據(jù)存儲方式弓千。其中每一種表引擎都有著各自的特點衡便，用戶可以根據(jù)實際業(yè)務場景的要求，選擇合適的表引擎使用洋访。將表引擎獨立設計的好處是通過特定的表引擎支撐特定的場景镣陕，十分靈活，對于簡單的場景姻政，可直接使用簡單的引擎降低成本呆抑，而復雜的場景也有合適的選擇。
1.7汁展、多線程與分布式
向量化執(zhí)行是通過數(shù)據(jù)級并行的方式提升了性能鹊碍，多線程處理是通過線程級并行的方式實現(xiàn)了性能的提升。相比基于底層硬件實現(xiàn)的向量化執(zhí)行 SIMD食绿，線程級并行通常由更高層次的軟件層面控制侈咕，目前市面上的服務器都支持多核心多線程處理能力。由于 SIMD 不適合用于帶有較多分支判斷的場景器紧，ClickHouse 也大量使用了多線程技術以實現(xiàn)提速耀销，以此和向量化執(zhí)行形成互補。ClickHouse 在數(shù)據(jù)存取方面铲汪，既支持分區(qū)(縱向擴展熊尉，利用多線程原理)，也支持分片(橫向擴展桥状，利用分布式原理)帽揪，可以說是將多線程和分布式的技術應用到了極致。
1.8辅斟、多主架構
HDFS转晰、Spark、HBase 和 ElasticSearch 這類分布式系統(tǒng)士飒，都采用了 Master-Slave 主從架構查邢，由一個管控節(jié)點作為 Leader 統(tǒng)籌全局。而 ClickHouse 則采用 Multi-Master多主架構酵幕，集群中的每個節(jié)點角色對等扰藕，客戶端訪問任意一個節(jié)點都能得到相同的效果。這種多主的架構有許多優(yōu)勢芳撒，例如對等的角色使系統(tǒng)架構變得更加簡單邓深，不用再區(qū)分主控節(jié)點未桥、數(shù)據(jù)節(jié)點和計算節(jié)點，集群中的所有節(jié)點功能相同芥备。所以它天然規(guī)避了單點故障的問題冬耿，非常適合用于多數(shù)據(jù)中心、異地多活的場景萌壳。
1.9亦镶、交互式查詢
Hive、SparkSQL袱瓮、HBase 等都支持海量數(shù)據(jù)的查詢場景缤骨，都擁有分布式架構，都支持列存尺借、數(shù)據(jù)分片绊起、計算下推等特性。ClickHouse 在設計上吸取了以上技術的優(yōu)勢褐望，例如：Hive勒庄、SparkSQL 無法保證 90% 以上的查詢在秒級內響應串前，在大數(shù)據(jù)量復雜查詢下需要至少分鐘級的響應時間瘫里，而 HBase 可以對海量數(shù)據(jù)做到交互式查詢，由于不支持標準 SQL 在對數(shù)據(jù)做 OLAP 聚合分析時顯得捉襟見肘荡碾。ClickHouse 吸取以上各個技術的優(yōu)勢谨读，在復雜查詢的場景下，它也能夠做到極快響應坛吁，且無須對數(shù)據(jù)進行任何預處理加工劳殖。
1.10、數(shù)據(jù)分片與分布式查詢
數(shù)據(jù)分片是將數(shù)據(jù)進行橫向切分拨脉，這是一種在面對海量數(shù)據(jù)的場景下哆姻，解決存儲和查詢瓶頸的有效手段，是一種分治思想的體現(xiàn)玫膀。ClickHouse 支持分片矛缨，而分片則依賴集群。每個集群由一到多個分片組成帖旨，而每個分片則對應了 ClickHouse 的一個服務節(jié)點箕昭。分片的數(shù)量上限取決于節(jié)點數(shù)量：一個分片只能對應一個服務節(jié)點。
ClickHouse 擁有高度自動化的分片功能解阅。ClickHouse 提供了 Local Table 本地表與 Distributed Table 分布式表的概念落竹。一張本地表等同于一份數(shù)據(jù)的分片。而分布式表本身不存儲任何數(shù)據(jù)货抄，它是本地表的訪問代理述召，其作用類似分庫中間件朱转。借助分布式表，能夠代理訪問多個數(shù)據(jù)分片积暖，從而實現(xiàn)分布式查詢肋拔。
這種設計類似數(shù)據(jù)庫的分庫和分表，十分靈活呀酸。例如在業(yè)務系統(tǒng)上線的初期凉蜂，數(shù)據(jù)體量并不高，此時數(shù)據(jù)表并不需要多個分片性誉。所以使用單個節(jié)點的本地表（單個數(shù)據(jù)分片）即可滿足業(yè)務需求窿吩，待到業(yè)務增長、數(shù)據(jù)量增大的時候错览，再通過新增數(shù)據(jù)分片的方式分流數(shù)據(jù)纫雁，并通過分布式表實現(xiàn)分布式查詢。
