鑽石舞台

作者：微信WeOLAP團隊&騰訊雲數據倉庫 Clickhouse 團隊

微信作為一款國民級應用，已經覆蓋了社交、支付、出行等人們生活的方方面面。海量多樣化的業務形態，對數據分析提出了新的挑戰。為了滿足業務數據分析的需求，微信 WeOLAP 團隊聯手騰訊雲，共建千台規模、數據 PB 級、批流一體的 ClickHouse 數據倉庫，實現了 10 倍以上的性能提升。下文將由淺入深，為大家揭曉微信在 ClickHouse 實時數倉實踐中積累的經驗及方法。

一般來說，微信主要的數據分析場景包含以下幾個方面：

1.科學探索：服務於數據科學家，通過即席查詢做業務上的歸因推斷；

2.看板：服務於運營和管理層，展示所關注的核心指標；

3.A/B 實驗平台：服務於算法工程師，把新的模型，放在 A/B 實驗平台上做假設檢驗，看模型是否符合預期。

除此以外，還有實時監控、日誌系統明細查詢等場景。

在所有的場景當中，使用者都有非常重要的訴求——快：希望查詢響應更快，指標開發更快完成，看板更新更及時。與此同時，微信面臨的是海量的數據，業務場景中「單表日增萬億」很常見，這就對下一代「數據分析系統」提出新的挑戰。

在使用 ClickHouse 之前，微信使用的是 Hadoop 生態為主的數倉，存在以下這些問題：

1.響應慢，基本上是分鐘級，可能到小時，導致決策過程長；

2.開發慢，由於傳統的數倉理念的多層架構，使得更新一個指標的成本很高；

3.架構臃腫，在微信業務體量規模的數據下，傳統架構很難做到流批一體。進而導致，代碼需要寫多套、數據結果難以對齊、存儲冗餘。經過十幾年的發展之後，傳統的 Hadoop 生態的架構變得非常臃腫，維護難度和成本都很大。

所以，微信一直在尋求更輕量、簡單敏捷的方案來解決這些問題。經過一番調研，在百花齊放的 OLAP 產品中，最終選定了 ClickHouse 作為微信 OLAP 的主要核心引擎。主要有兩個原因：

1.效率：在真實數據的實驗場景下，ClickHouse 要比 Hadoop 生態快 10 倍以上(2020 年底測試)；

2.開源：微信的 A/B 實驗、線上特徵等場景會有些個性化需求，需要對引擎內核做較多改動；

因此，微信嘗試在 OLAP 場景下，構建基於 ClickHouse 計算存儲為核心的「批流一體」數倉。

但是，使用原生的 ClickHouse，在真正放量階段出現了很多問題：

1.穩定性：ClickHouse 的原始穩定性並不好，比如說：在高頻寫入的場景下經常會出現 too many part 等問題，整個集群被一個慢查詢拖死，節點 OOM、DDL 請求卡死都比較常見。另外，由於 ClickHouse 原始設計缺陷，隨數據增長的依賴的 zookeeper 瓶頸一直存在，無法很好解決；微信後期進行多次內核改動，才使得它在海量數據下逐步穩定下來，部分 issue 也貢獻給了社區。

2.使用門檻較高：會用 ClickHouse 的，跟不會用 ClickHouse 的，其搭建的系統業務性能可能要差 3 倍甚至 10 倍，有些場景更需要針對性對內核優化。

此時，騰訊雲數據倉庫 Clickhouse 團隊積極深入業務，主動與微信團隊合作，雙方開始共同解決上述問題。騰訊雲數據倉庫 Clickhouse 提供全託管一站式的全面服務，使得微信團隊不需要過多關注穩定性問題。另外，雙方團隊積累了豐富查詢優化經驗，共享經驗更有利於 Clickhouse 性能極致提升。

微信跟騰訊雲數據倉庫 Clickhouse 的合作，從今年 3 月份開始，在驗證期小規模試用 ClickHouse 後，業務一直在快速增長，雙方開始共建進行穩定性和性能上的優化。主要做了兩件事：一個是建立了整個 ClickHouse OLAP 的生態，另外一個是做了的探索出貼近業務的查詢優化方法。

要想比較好地解決 ClickHouse 易用性和穩定性，需要生態支撐，整體的生態方案有以下幾個重要的部分：

1.QueryServer：數據網關，負責智能緩存，大查詢攔截，限流；

2.Sinker：離線/在線高性能接入層，負責削峰、hash 路由，流量優先級，寫入控頻；

3.OP-Manager：負責集群管理、數據均衡，容災切換、數據遷移；

4.Monitor：負責監控報警，亞健康檢測，查詢健康度分析，可與 Manager 聯動；

微信 WeOLAP 團隊和騰訊雲重點在以下方面進行了合作攻堅：

1.高性能接入：微信的吞吐達到了十億級別，實時接入方面，通過令牌、反壓的方案，比較好地解決了流量洪峰的問題。另外通過 Hash 路由接入，使數據落地了之後可直接做 Join，無需 shuffle 實現的更快 Join 查詢，在接入上也實現了精確一次。離線同步方案上，微信跟大多數業界的做法基本上一致，在通過預構 Merge 成建成 Part，再送到線上的服務節點，這其實是種讀寫分離的思想，更便於滿足高一致性、高吞吐的場景要求。

2.極致的查詢優化：ClickHouse 整個的設計哲學，要求在特定的場景下，採用特定的語法，才能得到最極致的性能。為解決 ClickHouse 使用門檻高的問題，微信把相應的優化經驗落地到內部 BI 平台上，沉澱到平台後，使得小白用戶都可以方便使用 ClickHouse。通過一系列優化手段，在直播、視頻號等多個 Case 實現 10 倍以上性能提升。

基於共建的 ClickHouse 生態，在微信有以下的典型應用場景：

1.BI 分析/看板：由於科學探索是隨機的，很難通過預構建的方式來解決，之前用 Hadoop 的生態只能實現小時到分鐘的級別。目前 ClickHouse 優化完之後，在單表萬億的數據量下，大多數的查詢，P95 在 5 秒以內。數據科學家現在想做一個驗證，非常快就可以實現。

2.A/B 實驗平台：早期做 A/B 實驗的時候，前一天晚上要把所有的實驗統計結果，預先聚合好，第二天才能查詢實驗結果。在單表數據量級千億 / 天、大表實時 Join 的場景下，微信前後經歷了幾個方案，實現了近 50 倍的性能提升。從離線到實時分析的飛躍，使得 P95 響應<3S，A/B 實驗結論更加準確，實驗周期更短 ，模型驗證更快。

3.實時特徵計算：雖然大家普遍認為 ClickHouse 不太擅長解決實時相關的問題，但最終通過優化，可以做到掃描量數十億，全鏈路時延<3 秒，P95 響應近 1 秒。

目前，微信當前規模千台，數據量 PB 級，每天的查詢量上百萬，單集群 TPS 達到了億級，而查詢耗時均值僅需秒級返回。ClickHouse OLAP 的生態相對於之前的 Hadoop 生態，性能提升了 10 倍以上，通過流批一體提供更穩定可靠的服務，使得業務決策更迅速，實驗結論更準確。

ClickHouse 原始的設計和 Shard-Nothing 的架構，無法很好地實現秒級伸縮與 Join 的場景；因此下一個微信和騰訊雲數據倉庫 ClickHouse 的共建目標，是實現存算分離的雲原生數倉：

1.彈性擴容：秒級彈性能力，用戶只為使用付費，實現高峰查詢更快，低峰成本更省；

2.穩定性：無 ZK 瓶頸，讀寫易分離，異地容災；

3.易運維：數據容易均衡，存儲無狀態；

4.功能全：專注於查詢優化與 Cache 策略、支持高效多表 Join；

存算分離的雲原生數倉能力，明年將會在騰訊雲官網上線，敬請期待！

本文章由微信技術架構部-WeOLAP 團隊出品，「WeOLAP」專注於用前沿大數據技術解決微信海量數據高性能查詢問題。

騰訊雲數據倉庫 Clickhouse 10 元新客體驗活動火爆進行中 ↓↓↓

最近熱文：

Golang 編程思維和工程實戰

Linux I/O 那些事兒

開源監控系統 Prometheus 最佳實踐