#頭條創作挑戰賽#
入門介紹與其特性
在大資料處理場景中，流處理和批處理使用到的技術大緻如下：
批處理會将源業務系統中的資料通過資料抽取工具（例如Sqoop）将資料抽取到HDFS中，這個過程可以使用MapReduce、Spark、Flink技術對資料進行ETL清洗處理，也可以直接将資料抽取到Hive數倉中，一般可以将結構化的資料直接抽取到Hive資料倉庫中，然後使用HiveSQL或者SparkSQL進行業務名額分析，如果涉及到的分析業務非常複雜，可以使用Hive的自定義函數或者Spark、Flink進行複雜分析，這就是我們通常說的資料名額分析。分析之後的結果可以儲存到Hive、HBase、MySQL、Redis等，供後續查詢使用。一般在數倉建構中，如果名額存入Hive中，我們可以使用Sqoop工具将結果導入到關系型資料庫中供後續查詢。HBase中更擅長存儲原子性非聚合查詢資料，如果有大量結果資料後期不需要聚合查詢，也可以通過業務分析處理考慮存入HBase中。對于一些查詢需求結果回報非常快的場景可以考慮将結果存入Redis中。
對于大多數企業建構數倉之後，會将結果存入到Hive中的DM層中。DM層資料存入的是與業務強相關的報表資料，DM層資料是由數倉中DWS層主題寬表聚合統計得到，這種報表層設計适合查詢固定的場景。對于一些查詢需求多變場景，我們也可以使用impala來直接将主題寬表資料基于記憶體進行互動式查詢，對web或者資料分析做到互動式傳回結果，使用impala對記憶體開銷非常大。還有另外一種方式是使用Kylin進行預計算，将結果提前計算好存入Hbase中，以供後續互動式查詢結果，Kylin是使用空間擷取時間的一種方式，預先将各種次元組合對應的度量計算出來存入HBase,使用者寫SQL互動式查詢的是HBase中預計算好的結果資料。最後将資料分析結果可以直接對web以接口服務提供使用或者公司内部使用可視化工具展示使用。
以上無論批處理過程還是流處理過程，使用到的技術幾乎離不開Hadoop生态圈。
一、什麼是ClickHouse
ClickHouse是一個開源的，用于聯機分析（OLAP）的列式資料庫管理系統（DBMS-database manager system）, 它是面向列的，并允許使用SQL查詢，實時生成分析報告。ClickHouse最初是一款名為Yandex.Metrica的産品，主要用于WEB流量分析。ClickHouse的全稱是Click Stream，Data WareHouse，簡稱ClickHouse。
ClickHouse不是一個單一的資料庫,它允許在運作時建立表和資料庫，加載資料和運作查詢，而無需重新配置和重新啟動伺服器。ClickHouse同時支援列式存儲和資料壓縮，這是對于一款高性能資料庫來說是必不可少的特性。一個非常流行的觀點認為，如果你想讓查詢變得更快，最簡單且有效的方法是減少資料掃描範圍和資料傳輸時的大小，而列式存儲和資料壓縮就可以幫助我們實作上述兩點，列式存儲和資料壓縮通常是伴生的，因為一般來說列式存儲是資料壓縮的前提。
二、OLAP場景的特征
- 絕大多數是讀請求。
- 資料以相當大的批次(> 1000行)更新，而不是單行更新;或者根本沒有更新。
- 已添加到資料庫的資料不能修改。
- 對于讀取，從資料庫中提取相當多的行，但隻提取列的一小部分。
- 寬表，即每個表包含着大量的列。
- 查詢相對較少(通常每台伺服器每秒查詢數百次或更少)。
- 對于簡單查詢，允許延遲大約50毫秒。
- 列中的資料相對較小：數字和短字元串(例如，每個URL 60個位元組)。
- 處理單個查詢時需要高吞吐量(每台伺服器每秒可達數十億行)。
- 事務不是必須的。
- 對資料一緻性要求低。有副本情況下，寫入一個即可，背景自動同步。
- 每個查詢有一個大表。除了他以外，其他的都很小。
- 查詢結果明顯小于源資料。換句話說，資料經過過濾或聚合，是以結果适合于單個伺服器的RAM中。
通過以上OLAP場景分析特點很容易可以看出，OLAP場景與其他通常業務場景(例如,OLTP或K/V)有很大的不同， 是以想要使用OLTP或Key-Value資料庫去高效的處理分析查詢場景，并不是非常完美的适用方案。例如，使用OLAP資料庫去處理分析請求通常要優于使用MongoDB或Redis去處理分析請求。
三、ClickHouse特性
1、完備的DBMS功能
ClickHouse是一個資料庫管理系統，而不僅是一個資料庫，作為資料庫管理系統具備完備的管理功能：
- DDL(Data Definition Language-資料定義語言)：可以動态地建立、修改或删除資料庫、表和視圖，而無須重新開機服務。
- DML(Data Manipulation Language)：可以動态查詢、插入、修改或删除資料。
- 分布式管理：提供叢集模式，能夠自動管理多個資料庫節點。
- 權限控制：可以按照使用者粒度設定資料庫或者表的操作權限，保障資料的安全性。
- 資料備份與恢複：提供了資料備份導出與導入恢複機制，滿足生産環境的要求。
2、列式存儲
目前大資料存儲有兩種方案可以選擇，行式存儲(Row-Based)和列式存儲(Column-Based)。
- 行式存儲在資料寫入和修改上具有優勢
行存儲的寫入是一次完成的，如果這種寫入建立在作業系統的檔案系統上，可以保證寫入過程的成功或者失敗，可以保證資料的完整性。列式存儲需要把一行記錄拆分成單列儲存，寫入次數明顯比行存儲多(因為磁頭排程次數多，而磁頭排程是需要時間的，一般在1ms~10ms)，再加上磁頭需要在盤片上移動和定位花費的時間，實際消耗更大。
資料修改實際上也是一次寫入過程，不同的是，資料修改是對磁盤上的記錄做删除标記。行存儲是在指定位置寫入一次，列存儲是将磁盤定位到多個列上分别寫入，這個過程仍是行存儲的列數倍。
是以，行式存儲在資料寫入和修改上具有很大優勢。
- 列式存儲在資料讀取和解析、分析資料上具有優勢。
資料讀取時，行存儲通常将一行資料完全讀出，如果隻需要其中幾列資料的情況，就會存在備援列，出于縮短處理時間的考量，消除備援列的過程通常是在記憶體中進行的。列存儲每次讀取的資料是集合的一段或者全部，不存在備援性問題。
列式存儲中的每一列資料類型是相同的，不存在二義性問題，例如，某列類型為整型int,那麼它的資料集合一定是整型資料，這種情況使資料解析變得十分容易。相比之下，行存儲則要複雜得多，因為在一行記錄中儲存了多種類型的資料，資料解析需要在多種資料類型之間頻繁轉換，這個操作很消耗CPU，增加了解析的時間。
是以，列式存儲在資料讀取和解析資料做資料分析上更具優勢。
綜上所述，行存儲的寫入是一次性完成，消耗的時間比列存儲少，并且能夠保證資料的完整性，缺點是資料讀取過程中會産生備援資料，如果隻有少量資料，此影響可以忽略，數量大可能會影響到資料的處理效率。列存儲在寫入效率、保證資料完整性上都不如行存儲，它的優勢是在讀取過程，不會産生備援資料，這對資料完整性要求不高的大資料處理領域比較重要。一般來說一個OLAP類型的查詢可能需要通路幾百萬或者幾十億行的資料，但是OLAP分析時隻是擷取少數的列，對于這種場景列式資料庫隻需要讀取對應的列即可，行式資料庫需要讀取所有的資料列，是以這種場景更适合列式資料庫，可以大大提高OLAP資料分析的效率。ClickHouse就是一款使用列式存儲的資料庫，資料按列進行組織，屬于同一列的資料會被儲存在一起，列與列之間也會由不同的檔案分别儲存，在對OLAP場景分析時，效率很高。
3、資料壓縮
為了使資料在傳輸上更小，處理起來更快，可以對資料進行壓縮，ClickHouse預設使用LZ4算法壓縮，資料總體壓縮比可達8:1。
ClickHouse采用列式存儲，列式存儲相對于行式存儲另一個優勢就是對資料壓縮的友好性。例如：有兩個字元串“ABCDE”，“BCD”，現在對它們進行壓縮：
壓縮前：ABCDE_BCD 壓縮後：ABCDE_(5,3)
通過以上案例可以看到，壓縮的本質是按照一定步長對資料進行比對掃描，當發現重複部分的時候就進行編碼轉換。例如：(5,3)代表從下劃線往前數5個位元組，會比對上3個位元組長度的重複項，即:“BCD”。當然，真實的壓縮算法比以上舉例更複雜，但壓縮的本質就是如此，資料中重複性項越多，則壓縮率越高，壓縮率越高，則資料體量越小，而資料體量越小，則資料在網絡中的傳輸越快，對網絡帶寬和磁盤IO的壓力也就越小。
列式存儲中同一個列的資料由于它們擁有相同的資料類型和現實語義，可能具備重複項的可能性更高，更利于資料的壓縮。是以ClickHouse在資料壓縮上比例很大。
4、向量化執行引擎
在計算機系統的體系結構中，存儲系統是一種層次結構，典型伺服器計算機的存儲層次結構如上圖，上圖表述了CPU、CPU三級緩存、記憶體、磁盤資料容量與資料讀取速度對比，我們可以看出存儲媒介距離CPU越近，則通路資料的速度越快。
注意：緩存就是資料交換的緩沖區，緩存往往都是RAM(斷電即掉的非永久儲存),它們的作用就是幫助硬體更快地響應。CPU緩存的定義為CPU與記憶體之間的臨時資料交換器，它的出現是為了解決CPU運作處理速度與記憶體讀寫速度不比對的沖突，CPU緩存一般直接跟CPU晶片內建或位于主機闆總線互連的獨立晶片上，現階段的CPU緩存一般直接內建在CPU上。CPU往往需要重複處理相同的資料、重複執行相同的指令，如果這部分資料、指令，CPU能在CPU緩存中找到，CPU就不需要從記憶體或硬碟中再讀取資料、指令，進而減少了整機的響應時間。
由上圖可知，從記憶體讀取資料速度比磁盤讀取資料速度要快1000倍，從CPU緩存中讀取資料的速度比從記憶體中讀取資料的速度最快要快100倍，從CPU寄存器中讀取資料的速度為300ps(1000ps 皮秒 = 1ns)，比CPU緩存要快3倍還多。從寄存器中通路資料的速度，是從記憶體通路資料速度的300倍，是從磁盤中通路資料速度的30萬倍。
如果能從CPU寄存器中通路資料對程式的性能提升意義非凡，向量化執行就是在寄存器層面操作資料，為上層應用程式的性能帶來了指數級的提升。
何為向量化執行？向量化執行，可以簡單地看作一項消除程式中循環的優化。這裡用一個形象的例子比喻。小胡經營了一家果汁店，雖然店裡的鮮榨蘋果汁深受大家喜愛，但客戶總是抱怨制作果汁的速度太慢。小胡的店裡隻有一台榨汁機，每次他都會從籃子裡拿出一個蘋果，放到榨汁機内等待出汁。如果有8個客戶，每個客戶都點了一杯蘋果汁，那麼小胡需要重複循環8次上述的榨汁流程，才能榨出8杯蘋果汁。如果制作一杯果汁需要5分鐘，那麼全部制作完畢則需要40分鐘。為了提升果汁的制作速度，小胡想出了一個辦法。他将榨汁機的數量從1台增加到了8台，這麼一來，他就可以從籃子裡一次性拿出8個蘋果，分别放入8台榨汁機同時榨汁。此時，小胡隻需要5分鐘就能夠制作出8杯蘋果汁。為了制作n杯果汁，非向量化執行的方式是用1台榨汁機重複循環制作n次，而向量化執行的方式是用n台榨汁機隻執行1次。
為了實作向量化執行，需要利用CPU的SIMD指令，SIMD的全稱是Single Instruction Multiple Data，即用單條指令操作多條資料。現代計算機系統概念中，它是通過資料并行以提高性能的一種實作方式(其他的還有指令級并行和線程級并行)，它的原理是在CPU寄存器層面實作資料的并行操作。
ClickHouse列式存儲除了降低IO和存儲的壓力之外，還為向量化執行做好了鋪墊，除了讀取磁盤速度快之外，ClickHouse還利用SSE4.2指令集實作向量化執行，為處理資料提升很大效率。
5、關系模型與标準SQL查詢
相比HBase和Redis這類NoSQL資料庫，ClickHouse使用關系模型描述資料并提供了傳統資料庫的概念(資料庫、表、視圖和函數等)。ClickHouse完全使用SQL作為查詢語言(支援GROUP BY、ORDER BY、JOIN、IN等大部分标準SQL)，ClickHouse提供了标準協定的SQL查詢接口，可以與第三方分析可視化系統無縫內建對接。在SQL解析方面，ClickHouse是大小寫敏感，SELECT a 和 SELECT A所代表的語義不同。
6、多樣化的表引擎
與MySQL類似，ClickHouse也将存儲部分進行了抽象，把存儲引擎作為一層獨立的接口。ClickHouse擁有各種表引擎，每種表引擎決定不同的資料存儲方式。其中每一種表引擎都有着各自的特點，使用者可以根據實際業務場景的要求，選擇合适的表引擎使用。将表引擎獨立設計的好處是通過特定的表引擎支撐特定的場景，十分靈活，對于簡單的場景，可直接使用簡單的引擎降低成本，而複雜的場景也有合适的選擇。
7、多線程與分布式
向量化執行是通過資料級并行的方式提升了性能，多線程處理是通過線程級并行的方式實作了性能的提升。相比基于底層硬體實作的向量化執行SIMD，線程級并行通常由更高層次的軟體層面控制，目前市面上的伺服器都支援多核心多線程處理能力。由于SIMD不适合用于帶有較多分支判斷的場景，ClickHouse也大量使用了多線程技術以實作提速，以此和向量化執行形成互補。ClickHouse在資料存取方面，既支援分區(縱向擴充，利用多線程原理 )，也支援分片(橫向擴充，利用分布式原理)，可以說是将多線程和分布式的技術應用到了極緻。
8、多主架構
HDFS、Spark、HBase和Elasticsearch這類分布式系統，都采用了Master-Slave主從架構，由一個管控節點作為Leader統籌全局。而ClickHouse則采用Multi-Master多主架構，叢集中的每個節點角色對等，用戶端通路任意一個節點都能得到相同的效果。這種多主的架構有許多優勢，例如對等的角色使系統架構變得更加簡單，不用再區分主要節點、資料節點和計算節點，叢集中的所有節點功能相同。是以它天然規避了單點故障的問題，非常适合用于多資料中心、異地多活的場景。
9、互動式查詢
Hive,SparkSQL,HBase等都支援海量資料的查詢場景，都擁有分布式架構，都支援列存、資料分片、計算下推等特性。ClickHouse在設計上吸取了以上技術的優勢，例如：Hive、SparkSQL無法保證90%以上的查詢在秒級内響應，在大資料量複雜查詢下需要至少分鐘級的響應時間，而HBase可以對海量資料做到互動式查詢，由于不支援标準SQL在對資料做OLAP聚合分析時顯得捉襟見肘。ClickHouse吸取以上各個技術的優勢，在複雜查詢的場景下，它也能夠做到極快響應，且無須對資料進行任何預處理加工。
10、資料分片與分布式查詢
資料分片是将資料進行橫向切分，這是一種在面對海量資料的場景下，解決存儲和查詢瓶頸的有效手段，是一種分治思想的展現。ClickHouse支援分片，而分片則依賴叢集。每個叢集由1到多個分片組成，而每個分片則對應了ClickHouse的1個服務節點。分片的數量上限取決于節點數量（1個分片隻能對應1個服務節點）。
ClickHouse擁有高度自動化的分片功能。ClickHouse提供了本地表 （Local Table）與分布式表（Distributed Table）的概念。一張本地表等同于一份資料的分片。而分布式表本身不存儲任何資料，它是本地表的通路代理，其作用類似分庫中間件。借助分布式表，能夠代理通路多個資料分片，進而實作分布式查詢。
這種設計類似資料庫的分庫和分表，十分靈活。例如在業務系統上線的初期，資料體量并不高，此時資料表并不需要多個分片。是以使用單個節點的本地表（單個資料分片）即可滿足業務需求，待到業務增長、資料量增大的時候，再通過新增資料分片的方式分流資料，并通過分布式表實作分布式查詢。