作者:微信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」專注于用前沿大數據技術解決微信海量數據高性能查詢問題。
騰訊云數據倉庫 Clickhouse 10元新客體驗活動火爆進行中↓↓
