最佳實踐：微信 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」專注於用前沿大數據技術解決微信海量數據高性能查詢問題。
責任編輯：
