ClickHouse-簡談OLAP與ClickHouse

ClickHouse-簡談OLAP與ClickHouse
ClickHouse簡述
架構和選型分析
OLAP及場景特徵比較
列式數據庫特點及更適合OLAP系統的原因
ClickHouse簡述
俄羅斯的Yandex公司（被譽爲俄羅斯的google）在2016年開源了ClickHouse（C++）。
在第一屆易觀OLAP大賽中，在用戶行爲分析轉化漏斗場景裏，ClickHouse比Spark快了近10倍。在隨後幾年的大賽中，面對各類新的大數據引擎的挑戰， ClickHouse一直穩穩地坐在冠軍寶座上。同時在各種OLAP查詢引擎評測中，ClickHouse單表查詢的速度力壓現在流行的各大數據庫引擎，尤其是Ad-hoc查詢速度一直遙遙領先，因此被國內大量用戶和愛好者廣泛用在即席查詢場景當中。

我們可以在以下網址看到clickhouse與其他常用查詢分析引擎的benchmark性能測試
ClickHouse的性能測試https://clickhouse.tech/benchmark/dbms/

clickhouse 是OLAP的列式數據庫，vertica是商業的數據倉庫，greenplum 是用來做MPP數據分析。

架構和選型分析
隨着數據科技的進步，數據分析師早已不再滿足於傳統的T+1式報表或需要提前設置好維度與指標的 OLAP查詢。數據分析師更希望使用可以支持任意指標、任意維度並秒級給出反饋的大數據Ad-hoc查詢 系統。這對大數據技術來說是一項非常大的挑戰，傳統的大數據查詢引擎根本無法做到這一點。

在使用hadoop生態構建海量數據下用戶行爲軌跡分析場景時，常用到以下架構：

架構目標:
1、海量數據
2、實時導入
3、實時查詢
4、多維聚合分析

架構缺點：
1、數據的實效性:中間過程經過Kafka、ETL、調度處理，報表的實效性不理想
2、即席分析性能:Hive存儲是hdfs文件系統，hdfs不支持隨機讀寫，查詢效率不高，不適合即席查詢
3、涉及Hadoop組件多:涉及Flume、Kafka、HDFS等等，數據冗餘過多，同時需要深厚的知識儲備
4、數據鏈路長:數據鏈路處理流程長，繁瑣容錯也不好

針對不同數據量的選型建議：
少量數據:單機程序
中級數據:ES MySQL的分庫分表
海量數據:druid, kylin, doris, clickhouse, kudu等

OLAP及場景特徵比較
OLTP + OLAP:
T:transaction 事務處理 側重於增刪改
A : analysis 分析 Select大批量數據的聚合查詢

目前常用的技術中OLAP和OLTP同時滿足又能做到高效處理的很少很少，一般都是偏向於事務處理或者數據分析。

mysql和Hive、ClickHouse的設計目的是不同的
MySQL: insert update delete
Hive ClickHouse: Select 查詢分析的高效

讀模式和寫模式 ：
OLAP一般都是讀模式(例如hive，寫數據不校驗，讀數據會校驗報錯)， OLTP是寫模式 （寫入時校驗格式）。

海量數據做查詢分析高效的特點:
1、列式數據庫
2、寫模式(保證同一列的數據類型是一樣的: 方便壓縮)
3、排序

OLAP場景特徵：

1、讀多於寫
不同於事務處理(OLTP)的場景，比如電商場景中加購物車、下單、支付等需要在原地進行大量 insert、update、delete操作，數據分析(OLAP)場景通常是將數據批量導入後，進行任意維度的靈 活探索、BI工具洞察、報表製作等。
數據一次性寫入後，分析師需要嘗試從各個角度對數據做挖掘、分析，直到發現其中的商業價值、業務 變化趨勢等信息。這是一個需要反覆試錯、不斷調整、持續優化的過程，其中數據的讀取次數遠多於寫 入次數。這就要求底層數據庫爲這個特點做專門設計，而不是盲目採用傳統數據庫的技術架構。

2、大寬表，讀大量行但是少量列，結果集較小
在OLAP場景中，通常存在一張或是幾張多列的大寬表，列數高達數百甚至數千列。對數據分析處理 時，選擇其中的少數幾列作爲維度列、其他少數幾列作爲指標列，然後對全表或某一個較大範圍內的數 據做聚合計算。這個過程會掃描大量的行數據，但是隻用到了其中的少數列。而聚合計算的結果集相比 於動輒數十億的原始數據，也明顯小得多。

select department, count(id) as total from student group by department;

3、數據批量寫入，且數據不更新或少更新
OLTP類業務對於延時(Latency)要求更高，要避免讓客戶等待造成業務損失;而OLAP類業務，由於 數據量非常大，通常更加關注寫入吞吐(Throughput)，要求海量數據能夠儘快導入完成。一旦導入 完成，歷史數據往往作爲存檔，不會再做更新、刪除操作。
更新:修改 和 刪除
批量:導入 和 導出
mysql: insert update delete , source
clickouse: 單條記錄的增刪改 批量導入導出 多

4、無需事務，數據一致性要求低
OLAP類業務對於事務需求較少，通常是導入歷史日誌數據，或搭配一款事務型數據庫並實時從事務型
數據庫中進行數據同步。多數OLAP系統都支持最終一致性。

5、靈活多變，不適合預先建模
分析場景下，隨着業務變化要及時調整分析維度、挖掘方法，以儘快發現數據價值、更新業務指標。而 數據倉庫中通常存儲着海量的歷史數據，調整代價十分高昂。預先建模技術雖然可以在特定場景中加速計算，但是無法滿足業務靈活多變的發展需求，維護成本過高。

大寬表:100個字段，用戶使用其中的任意多個字段作爲組合條件進行查詢分析
kylin: 做預聚合! clichouse 也能實現這個功能:預聚合 (在數據聚合上的預)
hive: 離線分析:預聚合(在時間上的預)

在ClickHouse官網中給出的場景特徵（https://clickhouse.tech/docs/zh/#olapchang-jing-de-guan-jian-te-zheng）：

01、絕大多數請求都是讀請求
02、數據以相當大的批次(>1000行)更新，而不是單行更新;或者它根本沒有更新
03、數據已添加到數據庫，但不會進行修改
04、對於讀取，每次查詢都從數據庫中讀取大量的行，但是同時又僅需要少量的列
05、表格“寬”，意味着它們包含大量列
06、查詢相對較少(通常每臺服務器數百個查詢或每秒更少)
07、對於簡單查詢，允許延遲大約50毫秒
08、列中的數據相對較小:一般來說，都是數字和短字符串(例如，每個URL 60個字節)
09、處理單個查詢時需要高吞吐量(每個服務器每秒最多數十億行)
10、Transactions不是必需的
11、對數據一致性要求低
12、每個查詢有一個大表。所有其他表都很小，除了這個大表 13、查詢結果明顯小於源數據。換句話說，數據被過濾或聚合後能夠被盛放在單臺服務器的內存中

很容易看出OLAP 場景與其他流行場景(例如OLTP或鍵值訪問)非常不同。 因此，如果希望獲得不錯 的性能，嘗試使用 OLTP 或 鍵值DB 來處理分析查詢是沒有意義的。 例如，如果嘗試使用 MongoDB 或 Redis 進行分析，則與OLAP數據庫相比，性能會非常差。

比較：
mysql:少量結構化數據的針對單條記錄的增刪改查
hbase:針對海量數據的key-value增刪改查
redis:基於內存的針對key-value類型的增刪改查，熱數據的緩存
mongodb:文檔數據庫
elasticsearch: 針對文件做全文檢索的(倒排索引)
clickhouse: 針對海量數據的大量行少量列的聚合查詢分析的請求

列式數據庫特點及更適合OLAP系統的原因
行式和列式數據庫結構：
行式存儲:一行數據接着一行數據做存儲，一行數據中的多個字段的值都是物理相鄰的。
列式存儲:一列數據單獨存儲，多行數據的相同列的值，在物理存儲上是相鄰的

與行存將每一行的數據連續存儲不同，列存將每一列的數據連續存儲。示例圖如下:

列式數據庫更適合於OLAP場景(對於大多數查詢而言，處理速度至少提高了100倍)，下面詳細解釋了原因(通過圖片更有利於直觀理解)：

行式：

列式：

輸入/輸出 ：ClickHouse官網闡述:https://clickhouse.tech/docs/zh/#inputoutput
針對分析類查詢，通常只需要讀取表的一小部分列。在列式數據庫中你可以只讀取你需要的數據。例如，如果只需要讀取100列中的5列，這將幫助你最少減少20倍的I/O消耗。
由於數據總是打包成批量讀取的，所以壓縮是非常容易的。同時數據按列分別存儲這也更容易壓縮。這進一步降低了I/O的體積。
由於I/O的降低，這將幫助更多的數據被系統緩存。

例如，查詢«統計每個廣告平臺的記錄數量»需要讀取«廣告平臺ID»這一列，它在未壓縮的情況下需要1個字節進行存儲。如果大部分流量不是來自廣告平臺，那麼這一列至少可以以十倍的壓縮率被壓縮。當採用快速壓縮算法，它的解壓速度最少在十億字節(未壓縮數據)每秒。換句話說，這個查詢可以在單個服務器上以每秒大約幾十億行的速度進行處理。這實際上是當前實現的速度。

相比於行式存儲，列式存儲在分析場景下有着許多優良的特性。

1、分析類場景：在行存模式下，數據按行連續存儲，所有列的 數據都存儲在一個block中，不參與計算的列在IO時也要全部讀出，讀取操作被嚴重放大。而列存模式下，只 需要讀取參與計算的列即可，極大的減低了IO cost，加速了查詢。

2、同一列中的數據屬於同一類型，壓縮效果顯著。列存往往有着高達十倍甚至更高的壓縮比，節省了大量的 存儲空間，降低了存儲成本。

3、更高的壓縮比意味着更小的data size，從磁盤中讀取相應數據耗時更短。

4、自由的壓縮算法選擇。不同列的數據具有不同的數據類型，適用的壓縮算法也就不盡相同。可以針對不同
列類型，選擇最合適的壓縮算法。

5、高壓縮比，意味着同等大小的內存能夠存放更多數據，系統cache效果更好。

分析類查詢，通常只需要讀取表的一小部分列。在列式數據庫中可以只讀取需要的數據。數據總是打包 成批量讀取的，所以壓縮是非常容易的。同時數據按列分別存儲這也更容易壓縮。這進一步降低了I/O 的體積。由於I/O的降低，這將幫助更多的數據被系統緩存。
————————————————