微信 ClickHouse 實時數倉的最佳實踐

作者:微信 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 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」專注於用前沿大數據技術解決微信海量數據高性能查詢問題。

本文由 Readfog 進行 AMP 轉碼,版權歸原作者所有。
來源https://mp.weixin.qq.com/s/Hc3p2_Yx1BoSA1mR5kvNWQ