文章資訊
作者｜博睿資料數智中心大資料負責人-婁志強； 本文已被InfoQ發表。
背景
Bonree ONE 是博睿資料釋出的國內一體化智慧可觀測平臺。會話資料是 Bonree ONE 平臺重要的業務模組，在切換到 Clickhouse 之前是基於 ElasticSearch 進行儲存的。ElasticSearch（下文簡稱 ES）是一種基於 Lucene 的分散式全文搜尋引擎，主要使用場景在全文檢索方向。
ES儲存會話資料的痛點
會話資料的寫入量很大，而且涉及一些聯動資料，比如基於物件儲存的快照資料，查詢效率要求在秒級到亞秒級返回，在日誌場景，ES存在以下痛點：
· 寫入同步慢、寫入效率差，業務寫入會話資料到ES的同時，相關聯的快照資料寫入物件儲存系統，相對於快照資料的寫入時間，ES資料寫入返回響應需要等待至少亞秒級的延遲，導致產品上會有查詢不到資料的現象，影響體驗；
· 資料佔用儲存多，壓縮不好，隨著資料量的上漲，成本會越來越高；
· 查詢效率低，海量資料近30天經常查不出來；
· 維護成本高，IO資源開銷大，尤其私有化混部場景，對部署在同一個機器上的其他元件，影響較大；
基於Clickhouse儲存會話
ES存在的諸多問題，使得我們迫切尋找一個新的儲存方案來進行升級，解決寫入和查詢的效能問題以及叢集管理。
為什麼選擇Clickhouse
新的儲存方案需要具備高寫入吞吐、高讀取效率、叢集管理方便的特點。
寫入效率：Clickhouse寫入可以達到100M/秒，同時在延遲性上，受攢批效率的影響，實現了亞秒級別的資料寫入延遲，而且穩定性相對於ES來說更強。在ES裡，隨著資料量積累增加，索引的更新成本是在逐步增長的相對的，寫入穩定性也在受影響。
讀取效率：在會話場景裡，業務查詢資料的時間範圍以及對應的統計分析都是不確定的，Clickhouse基於高頻查詢確認主鍵欄位，基於常用高優查詢指定索引等最佳化手段，保證查詢效率穩定。而ES在應對非固定查詢的場景下，會佔用大量記憶體，同時由於索引塊換入換出的問題，會引起IO較高的問題。
叢集管理：我們自研了Clickhouse叢集的管理平臺，支援對Clickhouse服務的資料寫入、讀取、節點狀態等的監控，以及常用運維操作，比如擴縮容、資料均衡等。在ES的叢集管理上，沒有足夠的手段覆蓋到監控、資料遷移等運維操作。
易用性：Clickhouse基於sql查詢，業務接入直接基於jdbc的方式或者http的方式就可以直接使用。在ES中，大段的Json格式的查詢，有一定的學習門檻。
用Clickhouse儲存會話資料
基於ES儲存資料的架構如下：
基於Clickhouse儲存會話的架構如下：
使用基於Clickhouse的方式進行儲存，實現了多租戶管理、查詢資源管控、業務寫入追蹤和個性化調優等手段，讓業務在寫入效率和查詢效率上提升明顯。
Clickhouse關鍵的引數調優：
● parts_to_throw_insert：表分割槽之中活躍part數目超過多少，會丟擲異常。針對不同的業務量，這個數字應該是不同的，用來保證相應的資源匹配相應的寫入量級。
● max_threads：用於控制一個使用者的查詢執行緒數。
● max_execution_time：單個查詢最大執行時間。一般跟業務相關，是業務可容忍的最大查詢時間。
● background_pool_size：表引擎操作後臺的執行緒數。太大會影響cpu資源，太小會影響parts數量，從而可能觸發parts_to_throw_insert的異常。
● max_memory_usage：單個查詢最多能夠使用的記憶體大小，應對不同的硬體配置以及不同的使用者會配置不同的記憶體大小。
遇到的問題
問題一：too many parts
當寫入超過Clickhouse服務承受的上限的時候，就會出現too many parts異常。這個異常的本意是防止Clickhouse服務在超負載的情況下掛掉，同時給維護人一個訊號。因此，出現too many parts異常的時候，維護人就要關注當前服務是不是遇到超高峰資料的寫入了。此時可以關注的指標如下：
● 當前服務佔用的cpu是不是超預期了。關注merge任務是不是佔滿佇列，通常寫入超預期的情況下，parts數量也是暴漲，Clickhouse為了保證查詢效率，merge任務就會暴漲，而merge任務是消耗硬體資源的，如果資源不夠，merge任務執行緩慢，就會降低parts數量的減少效率，從而導致parts數量緩慢增加，當增加到parts_to_throw_insert的數值時，就會產生too many parts的異常。
● 關注寫入資料攢批的狀態，如果寫入頻繁，單批次數量較小，會導致parts數量增長很快，很容易觸發到merge任務執行的最大值，從而引發too many parts異常。
問題二：重啟耗時很長
當叢集容納的資料量比較多的時候，Clickhouse的重啟耗時會比較長，通常會達到幾十分鐘到小時級別不等。重啟服務時間過長，對於整個服務的高可用會挑戰很大，寫入端的穩定性、容錯性以及實時性，都會受到挑戰。Clickhouse本身在解決超大容量服務時，也提供瞭解決方案，即後設資料快取。
效果展示
用Clickhouse儲存會話模組的資料，儲存資源節省明顯，計算資源同樣收益可觀，解決了在ES儲存方案中遇到的效能瓶頸和叢集管理問題，同時在易用性上降低了門檻，讓業務更加親和地進行儲存切換。
將會話資料從ES切換到Clickhouse，總體運維成本更低，而且提升了寫入和查詢效率，在使用者進行會話資料統計分析和明細時，查詢穩定性提升明顯，使用者體驗得到大幅改善。
未來，我們會更加專注Clickhouse叢集的精細化管理和最佳化，主要聚焦在以下方向：
● merge的效率提升。
● 存算分離。
● 高併發查詢的最佳化。
以上三個方向的最佳化與完善都能夠進一步鞏固Clickhouse叢集的穩定性，幫助我們應對更多的業務場景，讓業務發展穩中提效。