京東零售Color千萬級QPS實時指標監控架構背後的資料庫實踐

語言: CN / TW / HK

在墨天輪舉辦的“2022網際網路行業應用專場——國產資料庫沙龍”中,京東雲資料庫產品經理曲藝偉和大家分享了《京東零售Color 千萬級QPS實時指標監控架構背後的資料庫實踐》,主要包括什麼是Color閘道器、它面臨的考驗及最佳實踐,以及背後的雲原生資料倉庫優勢,詳細分享內容如下。

什麼是Color閘道器?

在介紹Color閘道器之前,我們先來了解一下什麼是API閘道器。

API閘道器負責接收客戶端的所有請求,並將請求路由到相應的後端服務,並提供介面聚合和協議轉換同時通過呼叫多個後端服務,並聚合結果的方式處理請求,可以達到降低接入成本、提高效率、保障安全能力的效果。

京東零售Color閘道器作為API閘道器的技術服務,承載京東日均百億的流量和呼叫,是大促保障的重要技術環節。

圖1 京東零售Color 閘道器

大促期間帶來的考驗

京東零售Color閘道器在大促期間面臨著怎樣的考驗?我總結成了以下四點。

首先是對穩定性的考驗 。面臨大促期間主站等核心業務高併發流量,閘道器作為業務流量直接承載方,需要保障各個服務介面的平穩執行。

第二點是對高可用的考驗 。閘道器承接了數以萬計的後端服務介面,服務之間如何不會相互受影響,一個介面有問題不會影響其他介面的呼叫。

第三點是對可靠性的考驗 。作為流量入口,閘道器需要通過安全防刷與流控等流量安全策略,來保障閘道器面對海量流量場景下不被沖垮。

最後一個是對高效能的挑戰 。閘道器服務的可用性很大方面通過監控系統完善,需要實時瞭解閘道器效能和請求攔截情況,最終將流量處理結果匯聚到閘道器監控,進行觀察決策。

圖2 京東大促對Color閘道器的考驗

我們可以發現 監控服務其實是京東零售Color閘道器最核心的一個技術環節 ,那麼如何去保障監控服務的一個實時性與穩定性呢?接下來就為大家介紹Color閘道器的架構。

Color閘道器架構選型與解決方案

1、原始架構 HBase的痛點

監控服務是網關係統的核心環節 ,能夠實時監控系統運營狀況、統計相關的資料指標、根據風險識別結果實時進行智慧攔截。風險識別結果資料同步在Hbase支撐監控日誌分析服務,但是我們在業務進展的過程中發現,Hbase在資料處理上存在明顯短板,主要表現在以下幾點:

  • 無法滿足多維度聚合查詢效能要求

  • 不支援時序維度處理無資料聚合能力(需要額外人工開發實現多維度聚合)

  • 存在有熱點、耗記憶體的問題

  • 資料分析效能提升空間小,滿足不了查詢結果響應時間

針對HBase所帶來的業務與效能上的問題,我們對零售Color閘道器進行了架構升級。

圖3 原始架構 HBase的痛點

2、架構升級:雲原生數倉方案

雲原生資料倉庫是京東雲基於ClickHouse 自研的一款儲存和計算分離的產品。

從下面的架構圖可以看到, 零售Color閘道器的流量治理服務分為兩類 ,一類是 全量資料 ,離線寫到結果報表裡,再存到監控日誌的服務;另一類是 實時資料 ,通過訊息佇列Kafka到flink,去推到分散式計算任務,再推到雲原生數倉,去實現實時的計算分析的服務。

圖4 升級後的雲原生數倉方案

相比較於Hbase,雲原生數倉資料的處理效能整體提高60%(原1.92億/min所產生的積壓問題在架構升級之後完美解決,同比下效能可增長至3.1億/min)。同時,由於雲原生數倉採用計算和儲存分離架構,使用者可以根據實際業務情況實現秒級擴縮容,儲存成本也有極大的下降。

3、傳統數倉遇到的問題

首先 傳統數倉面臨技術瓶頸 。傳統數倉架構複雜,有著使用成本偏高,查詢延遲高,無法做到高併發和高可用,以及實時分析難以落地,或者是“分鐘級”準實時的痛點。

第二點, 傳統數倉架構複雜 。傳統數倉的架構中元件眾多,基礎配置要求高,同時前期準備週期較長,啟動困難。

最後 使用成本偏高也是傳統數倉的問題 。硬體資源較難評估,計算和儲存成本居高不下,並且運維複雜,人力成本難以降低。

4、業務爆發性增長下,京東需要的OLAP引擎

既然傳統數倉有著諸多的問題與挑戰,那麼面對海量資料我們該如何去實現一個實時分析的需求呢?基於傳統數倉的痛點,以及實際業務中的需求,需要一款高效率、高效能、低成本的OLAP引擎來支撐,我們考慮這款引擎應該具有以下的特性與優勢。

首先是要降成本,我們採用了 存算分離的架構 。這樣的架構幫助儲存成本下降50%以上,同時達到快速彈性闊縮容的效果。

其次是 高可用與超高效能 的優勢。海量資料能做到秒壓級響應,同時滿足高可用的特性,單節點失敗不影響叢集的穩定性。

最後,這款OLAP引擎需要滿足“ 開箱即用 ”。可以在控制檯點選、分鐘級別建立叢集,具備視覺化監控報警與運維介面等相關功能,可以達到使用者立即投入生產的效果。

圖5 京東需要的OLAP引擎特徵

雲原生資料倉庫的優勢

1、雲原生資料倉庫ClickHouse的優勢

為了能夠應對爆發性增長的京東業務,業務需要這樣一款高效率、高效能、低成本的OLAP引擎。為此,京東雲自主設計和研發了雲原生資料倉庫ClickHouse產品,這款資料倉庫具備了京東所需要的OLAP引擎的主要優勢。

  • 極低的成本

    大幅降低儲存的成本,每PB資料下可降低儲存成本 80% 以上。

  • 極致的彈性

    計算節點可秒級的擴縮容,動態滿足業務需求,極大的提高了資源的利用率。

  • 極簡的使用

    控制檯點選建立,分鐘級別可建立PB級別例項

    提供視覺化的監控管理平臺和日誌分析平臺

圖6 雲原生資料倉庫ClickHouse的優勢

2、雲原生資料倉庫ClickHouse的架構

在資料庫管控層中,採用了儲存和計算分離的架構;雲管平臺層是前端接入控制檯的功能,是提供給使用者的介面操作,包括購買、支付、配置變更、資源申請、例項建立、例項刪除、例項變更等操作。

圖7 雲原生數倉ClickHouse產品架構

3、雲原生資料倉庫ClickHouse在計算節點與儲存節點中的優勢

首先計算節點由於採用了這個計算和儲存分層架構,它其實是一個無狀態的計算執行引擎。因此計算層是可以僅僅只專注於對計算引擎實行動態的調配,這樣可以極大提升計算資源的利用率。

圖8 雲原生數倉ClickHouse表現的計算節點的優勢

不僅如此,儲存節點也是一個無狀態的資料引擎服務。如下圖所示,儲存節點被分為若干個小組,可以同時處理多個請求,同時節點的組內會根據一定的規則對資料進行操作。

圖9 雲原生數倉ClickHouse表現的儲存節點的優勢

那麼採用這樣儲存節點組的一個好處是什麼呢?即如果磁碟的IO成為瓶頸的時候,我們可以實現對儲存節點的擴容來實現對IO的增加。不僅如此,我們還在儲存層自研了多級快取的機制,支援多級記憶體快取和磁碟快取,可以更快的實現儲存資料的訪問。

4、雲原生資料倉庫ClickHouse在秒級彈性的優勢

最後我再來介紹彈秒級彈性的優勢。使用者不需要關注資料層面的任何東西,也不需要對資料進行重新分佈,也無需關注儲存節點的資料的儲存的方式,使用者只需要關注它的計算節點算力以及業務的分析與查詢。

圖10 雲原生數倉如何實現節點擴容

5、雲原生資料倉庫ClickHouse幫助使用者降低成本

最後,我會用幾組數字來和大家說明雲原生資料倉庫ClickHouse如何在儲存和計算分離的架構下,幫助使用者去降低成本,帶大家算一筆賬。

首先 雲原生資料倉庫ClickHouse採用多副本共享儲存,幫助降低50%的成本

假設一個雙副本的傳統ClickHouse叢集的儲存成本是100%,它採用的是兩副本,它的儲存介質是雲盤儲存。

而云原生資料倉庫ClickHouse採用的是分散式儲存,也就是我們所謂的共享儲存。所有的資料都是共享儲存在我們的分散式儲存引擎裡,相當於是一副本。在儲存副本層面,雲原生數倉ClickHouse比雙副本的CK下降了50%。

其次 布式儲存的價格更低,分散式儲存的價格為雲盤/EBA的60%左右

最後 雲原生資料倉庫ClickHouse的儲存按照實際資料量計費,通常儲存量為實際的50%-80% ,這一點也幫助使用者降低成本

綜合來看,雲原生數倉ClickHouse比傳統ClickHouse無論從資料副本、儲存成本以及實際使用空間都有較大的成本節約,最多可以節省50-80%的儲存價格。

圖11 存算分離架構幫助降低成本

雲原生資料倉庫ClickHouse支撐京東業務

和大家分享一下在京東內部的業務中,採用雲原生資料倉庫業務的全景圖。主要是分為兩類,一類是實時資料的分析,另一類是離線資料的線上分析。

我們的雲原生資料倉庫ClickHouse已經支撐了京東零售,京東物流,京東科技和京東工業數十個核心的零級業務 ,包括商業智慧的大屏分析、大屏的實時展示,促銷選品的產品平臺的建設,比如精準營銷和廣告投放,以及日誌流量分析、監控分析等相關的業務。

同時雲原生資料倉庫中,儲存和計算分離的架構能夠實現在業務的高峰和低谷的計算資源,實現彈性的擴容和縮容,這也極大的幫助京東的內部使用者降低儲存的成本,僅需關注業務價值。

圖12 雲原生數倉ClickHouse現已支撐京東數十個核心業務

- End -

►►更多瞭解◄◄