1.概述
Clickhouse是一個開源的列式儲存資料庫，其主要場景用於線上分析處理查詢（OLAP），能夠使用SQL查詢實時生成分析資料包告。今天，筆者就為大家介紹如何使用Clickhouse來構建實時數倉，來滿足一些實時性要求較高的使用場景。
2.內容
2.1 什麼是OLAP場景
在介紹Clickhouse構建實時數倉之前，我們先來了解一下OLAP的使用場景，通常OLAP的使用場景包含如下特徵：
- 絕大多數是讀取請求；
- 資料以相當大的Batch進行更新；
- 已儲存的資料不能隨意修改；
- 對於讀取，從資料儲存中提取相當多的行，但是隻提取列的一小部分；
- 大寬表，即每個表包含著大量的列；
- 查詢相對較少（QPS很小）；
- 對於簡單查詢，允許有較低的延遲，比如50ms~100ms；
- 列中的資料相對較小，比如字串長度很短；
- 處理單個查詢時需要高吞吐量；
- 事務非必須；
- 對資料一致性要求低；
- 每一個查詢有一個大表，除了它其他都是很小的；
- 查詢結果明顯小於源資料。
通過觀察這些特徵，我們可以看出，對於OLAP場景與其他業務場景（比如OLTP、KV等）有所不同，因此想要使用OLTP或者KV來高效的處理資料分析查詢場景，並不是非常完美的解決方案。
2.2 Clickhouse更適合OLAP的原因
Clickhouse更適合OLAP場景，對於大多數查詢而言，處理速度至少提高了100倍，下面我們可以通過圖片來詳細瞭解其中的原因：
2.2.1 行式
2.2.2 列式
接下來，給大家分析一下這2張圖發生了什麼。
2.2.3 輸入與輸出
- 針對分析類查詢，通常只需要讀取表的一小部分列。在列式資料庫中你可以只讀取你需要的資料。例如，如果只需要讀取100列中的5列，這將幫助你最少減少20倍的 I/O 消耗；
- 由於資料總是打包成批量讀取的，所以壓縮是非常容易的。同時資料按列分別儲存這也更容易壓縮。這進一步降低了 I/O 的體積；
- 由於 I/O 的降低，這將幫助更多的資料被系統快取。
例如，查詢 “統計每個廣告平臺的記錄數量” 需要讀取 “廣告平臺ID” 這一列，它在未壓縮的情況下需要 1 個位元組進行儲存。如果大部分流量不是來自廣告平臺，那麼這一列至少可以以 10 倍的壓縮率被壓縮。當採用快速壓縮演算法，它的解壓速度至少在 10 億位元組（未壓縮資料）每秒。換而言之，這個查詢可以在單個伺服器上以每秒大約幾十億行的速度進行處理。這實際上是當前實現的速度。
2.2.4 CPU
由於執行一個查詢需要處理大量的行，因此在整個向量上執行所有操作將比在每一行執行所有操作更加高效。同時，這將有助於實現一個幾乎沒有呼叫成本的查詢引擎。如果你不這樣來操作，使用任何一個機械硬碟，查詢引擎都不可避免的停止CPU進行等待。所以，在資料按列儲存並且按列執行是很有意義的。
這裡有兩種方法可以來實現這一點，它們分別是：
- 向量引擎：所有的操作都是為向量而不是為單個值編寫的。這意味著多個操作之間不再需要頻繁的呼叫，並且呼叫的成本基本可以忽略不計。操作程式碼包含一個優化的內部迴圈；
- 程式碼生成：生成一段程式碼，包含查詢中的所有操作。
這是不應該在一個通用資料庫中實現的，因為這在執行簡單查詢時是沒有意義的。但是也有例外，比如，MemSQL使用程式碼生成來減少處理SQL查詢的延遲（這裡只是為了比較，分析型資料庫通常需要優化的是吞吐而不是延遲）。
這裡需要注意，為了提高CPU效率，查詢語言必須是宣告型的（SQL或者MDX），或者至少一個向量（J，K）。查詢應該只包含隱式迴圈，允許進行優化。
2.3 Clickhouse構建實時數倉的場景
一般來說，使用Clickhouse構建實時數倉的場景，主要包含如下：
- 資料探索：通過即席查詢做業務上的歸因推測；
- 資料看板：展示所關注的核心指標；
- 資料實驗：將新的演算法模型，放在 A/B 實驗平臺上做假設驗證，看模型是否符合預期；
- 實時監控：對業務指標進行實時監控，觀察實時效果。
在上述場景中，使用者都非常看重實時性，希望查詢響應速度快。
在引入Clickhouse之前，我們通常使用主流的Hadoop生態來構建數倉，但是，Hadoop生態構建的數倉會有些痛點：
- 時效性差：基本上是分鐘級別，甚至是小時級別，導致分析過程偏長；
- 開發週期長：由於傳統架構數倉理念的多層架構，使得更新一個指標的成本代價會很高。
- 架構複雜：在一套成熟執行很久的系統框架下，難以實現流批一體，間接導致模組無法複用，程式碼需要寫多套，資料口徑難以收斂，資料儲存冗餘。
經過對業界的主流技術進行調研對比，使用Clickhouse作為OLAP的主要核心引擎，其原因如下：
- 效率：真實資料的實驗場景下，Clickhouse要比傳統的Hadoop生態（比如Hive）要快很多；
- 開源：資料實驗、演算法特徵等場景的個性化需求，能夠對Clickhouse進行引擎層面的改動。
在使用原生Clickhouse時，在資料流量增大時會有很多問題：
- 穩定性：原生的Clickhouse存在設計缺陷，分散式下的Clickhouse叢集對Zookeeper存在依賴，隨著資料的增長（體量非常大的情況下）Zookeeper會成為Clickhouse瓶頸；
- 門檻較高：需要對Clickhouse有較深的經驗積累，對於經驗不足和經驗豐富的兩類人員，部署出來的Clickhouse叢集的效能差別會很大。
2.4 ClickHouse生態建設
想要比較好的解決Clickhouse的易用性和穩定性，需要生態來支撐，整體的生態方案有以下幾個重要部分，它們分別是：
- 資料閘道器：用來管理請求，智慧分配；
- 資料分流：緩衝大流量資料，讀寫控制；
- 叢集管理：整體叢集的資料遷移、資料均衡、容災切換等；
- 資料監控：查詢耗時監控、慢查詢分析、異常指標監控等。
基於Clickhouse生態建設，有以下幾個典型的應用場景：
1. BI分析與看板
由於資料探索是隨機的，很難通過預構建的方式來解決，如果使用Hadoop的生態只能實現小時到分鐘的級別。在引入Clickhouse後，在單表千億級別的資料量下，大多數查詢都是很快的，對於資料分析師來說是非常友好的。
2. 實驗平臺
使用Hadoop生態做 A/B 實驗的時候，前一天要把所有的實驗資料統計出來，做好預聚合。第二天才能查詢實驗效果。使用Clickhouse來做實時JOIN，效果非常的好。
3. 實時特徵計算
雖然實時特徵計算不是Clickhouse的強項，但是通過相關優化，還是可以實現。
4.總結
Clickhouse OLAP的生態相對於Hadoop生態，效能提升是比較明顯的，通過流批一體提供更加穩定可靠的服務，使得業務決策更加迅速，實驗結論更加準確。
5.結束語
這篇部落格就和大家分享到這裡，如果大家在研究學習的過程當中有什麼問題，可以加群進行討論或傳送郵件給我，我會盡我所能為您解答，與君共勉！
另外，博主出書了《Hadoop大資料探勘從入門到進階實戰》，喜歡的朋友或同學， 可以在公告欄那裡點選購買連結購買博主的書進行學習，在此感謝大家的支援。