導語 |ClickHouse是俄羅斯開源的OLAP資料庫，以彪悍的性能著稱。開源5年以來，以性能優異、簡單易用的特點，吸引了大量的用戶群體。本文是對騰訊雲ClickHouse研發負責人彭健老師在雲+社區沙龍online的分享整理，幫助大家進一步理解ClickHouse的彪悍性能。
點擊視頻，查看完整直播回放
一、 QQ音樂PB級數據實時分析帶來的挑戰
騰訊公司內部有很多業務使用 ClickHouse，比較典型的就是QQ音樂。QQ音樂在使用 ClickHouse 之前，用的是基於 Hive 構建的離線數倉，當時遇到了很多問題，主要在於以下三個方面：
第一是實效性低。基於 Hive 僅僅可以做到 T+1 定時報表的分析，但實效性對音樂服務是至關重要的，所以分析的結果隨著時間的推移價值也是降低的。
第二是易用性低。數據分析需求來源於產品、運營、市場等多個方面，基於傳統的數倉分析門檻高，產品運營市場人員無法進行自主分析，需要把任務提交給數據開發人員做排期。
第三是流程效率低，需求需要經過排期、溝通、建模、分析、可視化流程等，以周級別的時間落地，分析結果非常不及時。
相信很多朋友工作中都會遇到類似的問題。所以QQ音樂最終選擇了ClickHouse集群，集群的現狀是近萬核的規模、PB 級的存儲，十萬億級別的記錄量，每天過千億級的數據入庫，包括實時流水、中間表的計算等等。絕大部分查詢請求是數秒內完成、部分查詢請求在十秒內完成。
使用ClickHouse帶來的業務價值，一方面是實時性，複雜的分析查詢通常是秒級完成，比如營收分析、多口徑業務指標、給老闆看的大盤指標、易用性的分析等。
另一方面是易用性，利用 Superset 可以自主製作各種報表，在Superset 過萬的圖標中，超過一半是由產品、研發、運營、財務等非數據同學創建的。
二、 騰訊雲ClickHouse在QQ音樂的實戰經驗
在整個使用和運維過程中，我們也積累了很多經驗，如下：
1. 合理規劃Zookeeper的集群配置
ClickHouse 集群數據量的增長，給 ZooKeeper 集群造成的負載也成正比增長，在並發寫入量較大的情況下，ZooKeeper 的處理能力跟不上，集群的性能也會急劇下降。所以在整個運維過程中，如果集群數據規模超過 TB 級別，建議採用具有 SSD 盤的設備。
2. 數據冪等寫入
ClickHouse 的集群是按 Shard 分布的，在向 ClickHouse 導入數據的過程中，難免會遇到失敗或者超時的情況，這時需要重試寫入動作。
但這個動作經常會遇到數據不一致的情況，導入數據和原始表中數據有不一致的地方。這是因為重試的時候由於負載均衡的設置問題、連結路由的問題，導致在多個 Shard 出現重複的寫入。為了避免這種情況，在重試的時候要在相同的 Shard 上寫入。
3. 合理規劃表分區數
官方有個建議，分區數量不要超過一千。通常這個分區數對大部分業務場景都夠用，過多分區數量會導致查詢性能的降低。
通常可以將數據按天、按月做分區，根據具體情況來操作。騰訊雲的內部用戶也有按 ID 進行分區，但這樣會導致分區數量非常多，整個查詢如果設計多個 ID 會降低整體的查詢效率，這也是需要注意的地方。
4. 讀寫分離
頻繁的數據寫入請求會消耗大量的 CPU、內存、網卡資源，同時 ClickHouse 後臺線程也會進行數據合併的操作，佔用線程。通常數據在其他平臺準備好批量入庫時，如果遇到線上查詢，二者會相互影響形成惡性循環，導致集群的不可用。
在 QQ 音樂運維過程中經常會遇到這樣的問題，最終找到比較好的解決方案就是讀寫分離，藉助臨時集群，預先將準備好的數據在臨時集群中構建、寫入，等待 Merge 完成後 AB 切換，或者通過數據拷貝的方式將數據複製到在線集群的伺服器上，做到讀寫分離。
這樣操作後帶來的好處是，數據的寫入不會影響線上的查詢，或者是把影響降到最低。
5. 跨表查詢的本地化
ClickHouse 集群分布式查詢通常採用 GLOBAL IN/GLOBAL JOINS 類似的詞語，這些詞句的性能相對比較低，使用後再查詢時會生成臨時表，並跨節點讀取數據，從而降低查詢速度，也會佔用更多的內存，甚至導致查詢失敗。
這部分的經驗就是合理的組織數據，使用本地化的 IN/JOINS 代替。具體來說，如果數據沒有進行合理的組織，那在每一個 Shard 上的數據會隨機分布，導致在跨節點時造成數據的損耗。
如果對數據進行合理的組織，比如根據數據的 UN、VID 將相同 ID 的數據寫入到相同的 Shard 中，結果是等效的，但可以極大的提升性能，將複雜的操作編程定型化的操作。
三、 常見 ClickHouse 實時分析場景剖析
首先，我們看一下 ClickHouse 擅長處理哪些數據：
擅⻓處理良好結構化的流式數據、或不可改變的事件流 (SCHEMA 固定，數據追加)；
擅⻓執行靈活的實時報表查詢(秒級查詢，無需預過多預處理，AD-HOC)；
不應當作OLTP資料庫使用(無事物，very heavy UPDATEs)；
不應當作KV存儲系統使用；
不應當作文檔存儲系統使用 (官方建議單條數據不宜超過100kB)。
下面，我們通過幾個例子，一步一步說明 ClickHouse 典型的應用場景。
1. 物化視圖
第一個場景是物化視圖的應用。假設有一張明細表 users_online，這個表描述了某一款 APP 用戶登錄時間以及在上面停留時長的明細數據。
如果我需要頻繁的查詢這個用戶登錄的平均總時長以及一天中登錄的總次數，就可以通過 ClickHouse 物化視圖來完成。
ClickHouse 的物化視圖和傳統的物化視圖有一些區別，傳統的物化視圖是查詢的狀態，但 ClickHouse 視圖物化視圖做了進一步的改進，當所關聯的明細表上數據發生變化，通過物化視圖可以直接更新到目標表。
因此，通常會把物化視圖配合聚合引擎使用，比如在創建物化視圖時，我們選擇了聚合引擎。當創建完成後，可以在視圖中查詢數據已經計算完成的數據。這樣帶來的優勢是，當有非常多同類查詢時，可以通過預聚合以空間換時間的辦法節約查詢時間。
物化視圖的原理是比較簡潔的，相當於設置了一個觸發。當在明細表中插入數據便會觸發物化視圖後臺的關聯，進行預聚合計算，並將計算結果存儲在目標表裡。這裡需要注意的是創建物化視圖的時候沒有關聯目標表，便會創建一個隱藏的表，當然也可以自主指定。
2. AggregatingMergeTree
除了物化視圖的功能以外，ClickHouse 也提供了各種比較專用的表引擎。其中最著名最有特色的表引擎是 AggregatingMergeTree。
假如在上述的例子中，我們不光要查詢用戶上線的次數、時長，還要計算最早、最晚上線的時間、每次上線平均的時長，對於這種聚合的查詢就需要用專門的聚合引擎來做。
這裡我們也會用到物化視圖。首先創建一個目標表存儲我們需要預聚合的變量、欄位，然後通過 ClickHouse 提供的大量聚合函數完成常用的聚合分析，創建物化視圖將目標表、明細表關聯起來，創建完成後可將存量數據導入，導入後查詢會發現這些數據已經做了預聚合。整個過程非常迅速，時間也非常短暫。
我們在創建視圖時會用到一個聚合函數，在查詢時用的是另一個函數，兩個函數是同一個函數的兩個不同面、或者是用於不同的階段。
在導入存量數據後，明細表會有增量數據，比如通過 Kafka 或者一些其他途徑，將數據源源不斷的用增量方式寫到明細表中。這個時候後臺會自動通過聚合計算將數據保存為中間狀態，這樣任何時候去查詢聚合表都會有非常快的速度，這也是典型的空間換時間的策略。
這背後的原理，我們用 duration 來舉例。原始數據都是可見的，但在聚合表中是個二進位的中間狀態保存，是不可讀的。如果要查詢聚合數據的明細狀態，就要用到 Merge 函數。
3. Aggregate Function
第三個場景是聚合函數的應用。ClickHouse 提供了大量的聚合函數，這裡我們用 BitMap 來舉例。
在傳統的數據分析中，會經常遇到廣告投放和用戶畫像的場景，在這些場景中，我們通常要根據一定條件找出用戶的標籤或者更新一些投放標籤。
假設我們有一張上圖左側的明細表，表中有登陸的明細和一個額外的 page_id，也就是登錄的時候訪問了哪些 id。接著，我們模擬向其中插入7月29日、7月30日兩天的數據。
接著要做一件事 —— 查詢用戶存留，查詢這個平臺上昨天登錄和今天登錄的日存留。常規可能會採取 JOIN 的方法，直接找到第一天、第二天的數據，但這樣帶來的問題是 JOIN、COUNT DISTINCT 都很慢，並且很容易 OOM。
那麼如果用聚合函數 BitMap 來做的話，會是什麼樣的呢？
在 ClickHouse 提供的聚合函數中，有一種是 groupBitmap 函數，它可以提供一個位圖，我們要做的就是將數據聚合到這個位圖中。
比如我們為 7 月 29 日創造一個位圖，有用戶的登錄對應的是 1、如果沒有就是 0，7 月 30 日也如此。如果我們需要查詢兩天都在線的存留，就要對兩個 Bitmap 進行 and 操作。
首先使用聚合引擎創建聚合表，導入歷史數據，接著創建一個物化視圖將明細表聚合表關聯起來。物化視圖在這裡還有一個作用，可以做表間的數據移動，當有新的數據明細表數據不斷上報的時候會自動做聚合。
接下來我們可以查看聚合表裡數據，如圖所示，7 月 29 日有 50 個用戶，7 月 30 日我們模擬插入了 60 個用戶，然後用聚合函數做運算，再求其積數，這樣就得出連續兩天登錄的用戶數量。整個位運算非常迅速，節約內存的效果也很顯著。
我們做過一個簡單的測試，在億級別用戶的情況下，一個位圖使用的內存不會超過 50M。通常簡單的 128G 伺服器就可以進行支撐計算。這就是聚合函數的優勢，計算速度快、資源消耗小。
這裡我們再補充一個例子，看看 Bitmap 在廣告投放中是怎麼做的。
通常廣告投放有一個明細表、用戶表，會給用戶打各種標籤，比如年齡、性別、職業以及各種屬性，我們會把這些標籤存儲在數據裡，那麼在 ClickHouse 如何用 Bitmap 解決呢？
首先，我們為每個標籤創建一個 Bitmap，如果某個用戶具備這樣的屬性，他對應的用戶 ID 在 Bitmap 會置為 1，這個動作可以用物化視圖在後臺自動從明細表中配合聚合引擎一起工作，用戶沒有更多的幹涉和開發工作。
這裡我們有兩類標籤，一類是字符串形式描述的，比如性別、職業；一種是年齡，用整型來描述，簡單創建兩個表。
接著，我們會導入一些數據，這個過程和之前的例子是類似的。
假設已經有了相關數據，我們現在要在廣告投放中圈出這樣一群人：性別女、工程師，年齡超過 20 歲。
首先，我們要找到 3 個標籤的 Bitmap，然後再求積數。如果想不求積數看出 ID，也有工具函數可以把 ID 列印出來，這個過程是非常迅速的。核心的思想就是找到標籤對應的 Bitmap，根據條件做各種邏輯運算，完成人群篩選和廣告的標籤投放。
四、ClickHouse 原理 & 性能調優
目前在騰訊雲上有很多 ClickHouse 的用戶，也積累了大量運維的操作，這些操作我們非常願意分享給大家，也願意和大家一起交流，共同推動社區的發展。
它的核心部分是計算引擎、存儲引擎，大致有以下的特點：
INSERT 操作是原則的；
SELECT 操作異常快；
支持主索引/二級索引；
INSERT/SELECT 相互不影響；
後臺合併數據；
主鍵不唯一。
這是一個典型的 OLAPMergeTree 的數據結構，在 NoSQL 中應用的非常廣泛。當有新數據寫入時，快速形成一個小的數據分片。數據在分片內部是有序的，在後臺會通過後臺的限制不斷的將小的、有序的分片合併成更大的、有序的分片，並不斷的進一步的合併。
為什麼要合併呢？因為對 OLAP 引擎來說如果要提高查詢效率，數據有序是非常必要的。但同時有另一個矛盾，數據按時間進入是無序的，如果每次寫入數據都要進行全表的排序，代價是非常昂貴的，為了避免這種情況，選擇 RSM 的結構是非常的合理。
我們可以簡單創建一個表，看一下後臺的運行過程。
首先在三個欄位插入一千條數據。我們可以看到，後臺每個表都對應一個目錄，每次插入也會形成獨立的文件夾，這個文件夾一般稱為 parts 目錄。
整個數據是通過分區構成，每個表中的數據根據定義進行分區，每一個分區有自己獨立的文件夾，在一個分區內部數據通常是按 parts 構成，會隨著後臺的 Merge 不斷的聚合，有些會無效，有些會被刪除。parts 內部的數據是按列式存儲的，每一列會形成一個單獨的文件。
這裡我們定義的表有三個欄位 —— duration、user_id、when，有主線的索引文件，每個欄位除了二進位的數據文件也有 mark 文件。
具體的索引是怎麼工作的呢？首先創建表時會直接指定欄位，生成稀疏的索引，這個索引目前是可以按固定行數生成索引，或者是按照固定的數據量生成一個索引。
其次是 marks 文件。marks 文件和索引文件在行數上是對齊的，它會標記兩個 opset。第一個會標記數據文件，主鍵索引的數據在數據文件中的 opset；第二個因為數據是壓縮存儲的，解壓後的 opset 通過主索引文件和 marks 文件可以很容易定位到對應的數據。
當有查詢的時候，可以先通過主索引文件進行二分查找，找到對應行，因為行是對齊的，所以很容易找到 marks 中對應的文件，找到讀取的數據。
具體的流程是根據查詢條件確定 index 行數，然後找到 marks 文件，再切片分發給線程組。因為整個 ClickHouse 是為了提高查詢性能，後面是有線程組的，所以查詢時用了大量的 CPU。有些線程執行完會從其他的線程隊列中調取一些任務過來，線程開始讀取對應的數據，其他的也會處理。
我們舉個例子。
比如我們在 user_online 中查詢 user_id 大於 8192 小於 15000 的數據，我們只讀取相應的欄位，在主索引文件中找到對應的覆蓋這個 ID 的行數，找到 duration 對應的文件內容，這個文件就會標記出在數據文件中的位置。
在後臺，會不斷的有 parts 被合併。因為不斷有數據寫入，每次寫入會形成 parts。parts 內部有序，但 parts之間是無序的，我們會不斷的將其進行有序化，加速查詢，同時在 Merge 過程中，有些存儲引擎會做其他的動作，比如刪除數據等。
接下來我們看一下 ClickHouse 的性能調優。
我們在雲上的很多客戶，在創建集群的時候不太清楚自己需要什麼樣的配置，我們就會給出建議，通常有兩類節點、部署兩類進程。一類是 ClickHouse 的進程，一類是 ZK 的進程。
在 ClickHouse 進程中，CPU 的主頻越高越好，通常建議使用 32 以上的機型，內存越大越好，一般每個線程分配 2GB 內存差不多就夠了，當然越大的內存加速就會越明顯。
磁碟通常普通的 HDD 磁碟都可以，RAID 方面 RAID-5、RAID-10 或者 RAID-50 都可以。如果查詢數據量大、延遲要求比較低的話，使用 SSD/NVME 這些高速設備是最好的。
因為 ZK 節點不能混布，如果混布會出現很多的問題，比如相互影響導致集群無法工作，如果數據量在 TB 級別的時候，會選擇一個 SSD 盤之類的高速設備。
我們整理了一些基礎的參數：
lmax_threads: 查詢使用的線程數量，默認為核數一半；
lmax_memory_usage: 單次查詢允許使用的內存量；
lmax_memory_usage_for_all_users：ClickHouse 進程允許使用的內存量, 通常需要考慮為 OS 預留內存；
lmax_bytes_before_external_group_by: GROUP BY 操作使用內存超過該閾值後， 數據會寫入磁碟，建議設置為 max_memory_usage/2；
lmax_concurrent_queries: 最大並發數限制；
lmax_bytes_before_external_sort: order by 排序溢寫磁碟閾值；
lbackground_pool_size: 後臺線程組 。
在使用層面也有一些建議：
避免全表掃描
-查詢是需要指定分區
-避免使用 SELECT *
-GROUP BY 需要指定 LIMIT 子句
常用請求使用物化視圖預計算， 例如監控⻚面，報表大盤等
關聯查詢時慎用 JOIN，可以考慮優先使用 IN 解決
JOIN 查詢有損性能
-小表在右
-減少參與 JOIN 運算的數據量 (無謂詞下推)
數據寫入
-避免小批次寫入
-批量寫入數據中不宜包含過多分區
-適當調大後臺 merge 線程數 background_pool_size
分布式表提供查詢，代理 + 本地表提供數據寫入
合理規劃ZK集群配置以及參數調整建議
-數據規模在 TB 級別，建議使用 SSD 磁碟
-開啟自動清理數據功能
為用戶設置配額
下面我們講一下查詢方面的優化。最簡單的來說，對於一條 SQL 語句，我們要看它的延遲，如果延遲的結果不一樣，我們就會通過日誌和其他的方式來看，哪些數據被掃描了、掃描了多少數據、用到內存多少、有沒有寫出到磁碟、使用了哪些條件，甚至可以查看執行計劃，這些就是查詢優化常規的步驟。
最新版本的 ClickHouse，已經提供了 explain 命令，可以看整個查詢的執行計劃，這樣查詢語句合理不合理都可以再次調整，比以前方便很多，以前通過日誌後臺看，這對很多的其他開發者是不太友好的。
五、 騰訊雲ClickHouse現狀與規劃
騰訊雲是在今年 4 月份發布了 ClickHouse服務，提供了分鐘級別的企業級 ClickHouse 服務，支持秒級監控觸達、靈活的配置管理，這些雲上必要的功能。
預計在 8 月份會支持彈性伸縮能力，靈活增加減少計算節點，這對用戶很必要，根據業務做彈性伸縮。也提供數據自均衡服務，這是騰訊雲特有的服務，目前社區對這塊支持的工具比較完善，但是運維成本比較高。我們計劃把它自動化，做成簡單的按鈕點擊後就可以完成數據自動搬遷的功能。
預計在今年 Q4 ，我們會發布一個性能增強版，這個版本會解決 ZK 性能評級。ZK 是整個集群中比較重要的終端瓶頸，當 ZK 有問題時集群會無法寫入數據。同時也會集成 COS，方便用戶解決 COS 層的數據。還有其他的 feature 也在規劃中，會隨著比較合適的節奏會釋放出來。
參考資料：
[1] https://github.com/ClickHouse/ClickHouse
[2] https://github.com/ClickHouse/clickhouse-presentations
[3] https://cloud.tencent.com/developer/article/1637840
六、Q&A
Q：ClickHouse的優缺點？
A：ClickHouse 是一個技術相對簡單，對於 Hadoop 的依賴比較小，目前就是依賴Zookeeper 進行數據容災方面的依賴。它的性能非常強悍，底層是用 C++ 實現的，我們知道C++ 是編譯型語言，沒有像「Hadoop」大量用「JAVA」中間使用虛擬機從而帶來的性能損耗。
第二方面 ClickHouse 整個技術用得比較激進，各種先進的技術都會快速的拿來驗證，如果適用就繼續用、如果不適用就快速的換，社區更新、迭代得比較快，所以發版頻率非常高。
整個使用門檻非常低，支持 SQL ，雖然它的 SQL 有些特別，但是很容易理解，數據分析人員或者是沒有特別多的開發背景，學習成本很低。
它的缺點是整個社區時間比較短，開源到現在時間並不長，積累使用經驗並不多，隨著雲化後會積累大量的使用經驗，也樂意把經驗分享給大家，彌補這方面的不足。
Q：自動故障轉移切換時如何做？
A：ClickHouse 是支持數據容災的，可以配置多副本。整個數據級分為多個 Shard，每個 Shard 內部可以分多個副本，可以指定兩副本、三副本，對不重要的數據指定一副本，通常用兩副本用磁碟做 RAID-50 就足夠了，如果出現一個副本所在機器不可用，其他的副本就會去支撐讀寫，副本間可以看做是完全均等沒有差異的，如果整個 Shard 所有的機器都宕機了，整個集群是可以繼續提供讀寫服務的，只是讀會出現部分數據缺失，這部分數據等機器恢復會自動的回來，這是故障切換。
Q：單次查詢允許打開文件數，有這個參數嗎？
A：在配置文件中是沒有這個設置的，但是系統層面為這個進程把這個FD打開，設置更大的FD。
Q：什麼樣的數據需要存在 COS 上？
A：COS是騰訊雲提供的一個大容量、高性能的對象存儲，廣泛應用於大數據的技術棧中。我們很多用戶的數據在 COS 上，COS 上也沉澱大量的數據，如果這個數據能夠被 ClickHouse 分析將為用戶帶來很大的價值，我們也會做一些工作把數據鏈路打通，也是在規劃中。
Q：數據量大、分區多時，重啟ClickHouse很慢，有什麼優化建議嗎？
A：確實會出現這個問題，數據量比較大時重啟比較慢，特別是 IO 帶寬比較低的情況下，如果有特別重要的表，這表必須要快速的寫，建議先把節點上不重要的表先給 move 要其他的目錄，先把這個表寫入，之後再把其他的表加入。
Q：當並發的寫入數據請求數比較多時，ClickHouse會報錯，會有什麼配置優化建議？
A：首先要評估整個集群的負載是否達到了上限，如果達到建議先擴容，如果沒有達到還出現這樣的情況就看寫入方式是否合理。
首先儘量大批次的寫入，寫入的 QPS 官方建議是 1 到 2，以一秒鐘寫一個、兩個的頻度寫入，每次寫入的數據儘量多，比如 64K/條，一定是大批量。
第三個點是操作層面寫入的數據一定要做好預處理，如果是用 GBDC 自己手寫寫入，每一個 insert 中包含的數據分區儘量是同一個分區、不要跨分區。配置層面建議調大後臺的 Merge 限制數，這些都無法解決的話，可能要觀察整個系統的 LWait ，通常是磁碟開關瓶頸的問題，如果這樣情況就要去做磁碟的升級。
還有一種方案，就是 QQ 音樂做的讀寫分離，當寫請求和讀請求分離開，不需要歷史數據可以做 AB 切換的方式上線數據，如果需要歷史數據，可以通過工具把新創建好的數據拷貝過去的方式，降低對寫請求的影響。
Q：ClickHouse是否存在丟數據的情況？
A：這個問題是大家擔心的情況，大家對數據完整性要求非常高，如果絕對來說肯定會存在這樣的情況，整個機房機器全壞了、所有的集群所有節點磁碟都壞了，那肯定會出現丟數據的情況。通常這樣的小概率事件就不會考慮了。
ClickHouse 有內在的機制允許數據做多副本，可以配置兩副本、三個副本，通常是三副本已經足夠了，但大多數情況建議用兩副本，後面一些數據可以備份到 COS 上去，查詢的請求可以購買一些計算節點，通過計算節點訪問 COS 中的數據，COS 數據可以提供很高的可靠性。
Q：ZooKeeper 性能瓶頸是如何優化的？
A：ZooKeeper穩定性與可靠性對ClickHouse集群至關重要。從一下幾個方面考慮：
建議數據規模超過TB級別，採用SSD盤的機器部署ZK集群；
ZK配置上，要確保及時清理不需要的數據
騰訊雲ClickHouse服務會降低對ZK的依賴，敬請期待。
Q：物化視圖和 MergeTree 表存儲一樣的數據，查詢性能有區別嗎？
A:性能上沒有區別，如果物化視圖沒有關聯目標表，系統會創建一個隱藏的目標表，通過show tables命令也是可見的。查詢數據最終會落到關聯的目標表上。在這個上下文中，物化視相當於傳統資料庫中的觸發器。
Q：在數據量上30億的情況下，一般選擇什麼規格的機器比較好？
A:選擇機器類型，要綜合你的查詢情況。例如，如果你查詢數據量都比較少，就不需要太多機器。在騰訊雲上，我們建議採用大數據機型或者高IO機型。
Q：在深度分頁的場景下，ClickHouse 應該如何做？
A:總體而言，複雜查詢情況，儘量減少查詢所需讀取的數據量。使用索引，以及預聚合等加速查詢。
Q：兩個億行級別的表關聯查詢，怎麼寫高效？
A:QQ音樂的例子可以借鑑，能否對數據合理組織，讓數據的邏輯分片和ClickHouse的分片一致，從而將GLOBAL IN/JOINs 操作轉為節點內的IN/JOINs操作。
Q：ClickHouse在哪些數據場景下更有優勢呢？寬表多的場景呢？
A:ClickHouse 刪除處理結構化的流式數據，例如 事件數據，監控數據，日誌數據等。ClickHouses非常適合處理寬表場景。在具體使用過程中，也建議儘量使用寬表。
Q：MySQL 讀寫太慢了，遷移到 ClickHouse 是不是就會解決了？
A:可能還需要了解具體的場景，如果你的業務需要有事物支持，那麼ClickHouse無法支持。除此，ClickHouse 在性能方面具有非常明顯的優勢。
Q：Docker 容器中的 ClickHouse能用於生產嗎?
A:可以的。據我了解到，騰訊公司內部有不少業務部門的ClickHouse集群部署在容器中。
Q：ClickHouse 8123 埠 Read timed out 怎麼優化呢？
A:從2個方面來看：
ClickHouse進程所在機器負載情況如何，網卡，網卡，磁碟是否已出現瓶頸。
在客戶端，在適當調整Timeout值後，仍然出現超時，可以看看客戶端所在機器負載情況，以及到ClickHouse機器的網絡狀況。
Q：大的歷史表（T級別）方便存 ClickHouse嗎，存了後可以快速讀寫嗎？
A:有不少工具都可以用於將歷史數據寫入到ClickHouse中。例如可以使用物化視圖將數據從KAFKA導入到ClickHouse, 可以使用 clickhouse-mysql-data-reader
將MYSQL資料庫中的作存量、 增量導入。也可以使用JDBC 將其他數據源數據導入，例如 https://github.com/ClickHouse/clickhouse-jdbc。
數據導入到ClickHouse後，大部分查詢相比HIVE，SPARKSQL而言，具有非常明顯的性能優勢。在QQ音樂的案例裡，他們絕大部分查詢響應時間是小於1s的。
Q：如果做了用戶資源的配置，超出配額會產生什麼現象，拒絕連接還是查詢變慢？
A:拋出異常。
直播預告