技術文章 » 海量資料運維要給力，GaussDB(for Cassandra)來助力

海量資料運維要給力，GaussDB(for Cassandra)來助力

2023-06-01 18:00:30
摘要：應用運維管理平臺（AOM）和Cassandra是兩個不可分割的組成部分，它們共同構成了一個高效的解決方案，可以幫助企業在應用運維業務上取得巨大的優勢。在這篇文章中，我們將介紹AOM和Cassandra的優勢和特點，揭曉它們如何為企業保持市場競爭力的祕密。

本文分享自華為雲社群《海量資料運維要給力，華為雲GaussDB(for Cassandra)來助力》，作者：華為雲社群精選 。

導讀

隨著容器技術的普及，越來越多的企業通過微服務架構開發應用，業務逐漸轉變為雲上實現服務，運維也逐漸轉向雲上運維服務。在此環境下，雲上應用的運維也遭遇了新的挑戰：

  1. 運維人員技能要求高，需要同時維護多套系統，設定繁雜。分散式追蹤系統的學習和使用成本高，穩定性差，價效比低。
  2. 雲化場景下的分散式應用問題分析困難，主要表現在如何視覺化微服務間的依賴關係，如何提高應用效能體驗，如何將散落的紀錄檔進行關聯分析，以及如何快速追蹤問題。

針對以上挑戰， AOM應運而生。

AOM是什麼

AOM是由華為雲研發的雲上應用一站式立體化運維管理平臺，由應用資源管理、監控中心（可觀測性分析）、自動化運維、採集管理四個子服務構成，提供一站式可觀測性分析和自動化運維方案，支援快速從雲端和本地採集指標、紀錄檔和效能等資料，幫助使用者及時發現故障，全面掌握應用、資源及業務的實時執行狀況，提升企業海量資料運維的自動化能力和效率。

AOM優勢眾多，功能強大，其背後離不開支撐其海量資料運轉的智慧資料底座——華為雲GaussDB(for Cassandra)。

為什麼選擇GaussDB(for Cassandra)？

華為雲GaussDB(for Cassandra)是一款相容Cassandra生態的雲原生NoSQL資料庫，支援類SQL語法CQL。在華為雲高效能、高可用、高可靠、高安全、可彈性伸縮的基礎上，提供了一鍵部署、快速備份恢復、計算儲存獨立擴容、監控告警等服務能力，尤其適用於各種海量資料處理和高並行業務場景。

  • 出現資料熱點的業務。例如：某新聞時事APP需要管理大量新聞時事資料，當出現社會熱點事件時，相關新聞資料請求量急劇升高，此時需要保障APP正常運作，以及保持請求成功率穩定。
  • 需要對時序資料建模的業務。例如：某氣象站需要每分鐘採集一次溫度，並儲存該次採集結果，同時需要保障資料的時效性，自動刪除過期資料。
  • 需要對對談訊息資料建模的業務。例如：某社交APP需要儲存大量的使用者及對談訊息，需要保障使用者在不同對談訊息間切換時耗時低、成功率高、響應時間短。
  • 需要高速處理資料的業務。例如：某業務需要迅速處理來自不同裝置或感測器的資料。
  • 需要實時監測資料的業務。例如：某運維平臺需要實時監測不同維度的資料，準確採集指標，快速完成運維。
  • 需要使用社交媒體分析和推薦引擎的業務。例如：某電商APP需要分析使用者喜好商品，基於使用者喜好實現商品推薦，提升使用者體驗和產品競爭力。
  • ……

此外，華為雲GaussDB(for Cassandra)特性豐富，適用於廣泛業務場景。

  • 巨量資料應用：GaussDB(for Cassandra)可以處理海量資料，支援高吞吐量和低延遲的讀寫操作，因此適合巨量資料應用場景。
  • 網際網路應用：GaussDB(for Cassandra)可以處理高並行的讀寫請求，支援多資料中心部署，因此適合網際網路應用場景。
  • 時間序列資料：GaussDB(for Cassandra)支援時間序列資料的儲存和查詢，因此適合需要儲存和查詢時間序列資料的應用場景，如物聯網、紀錄檔分析等。
  • 高可用性業務。GaussDB(for Cassandra)採用多副本複製的方式來保證資料的可用性和可靠性。當一個節點出現故障時，系統可以自動將資料從其他節點中恢復，從而保證資料的完整性和一致性。
  • 可伸縮性業務。GaussDB(for Cassandra)可以輕鬆地擴充套件到數百個節點，處理PB級別的資料集，同時還支援動態新增和刪除節點，可以根據實際需求靈活地調整系統的規模和效能。
  • 分散式儲存應用。GaussDB(for Cassandra)採用分散式儲存的方式，將資料分散儲存在多個節點上，每個節點都可以獨立地處理讀寫請求。這種方式可以有效地提高資料的可用性和可靠性，同時也可以提高系統的吞吐量和擴充套件性。
  • 分散式查詢應用：GaussDB(for Cassandra)支援分散式查詢，可以將查詢請求分發到多個節點上並行處理，從而提高查詢的效率和響應速度。
  • ……

綜上所述，GaussDB(for Cassandra)非常適合巨量資料分析、實時資料處理、社群網路、物聯網、分散式儲存和查詢等應用場景。

真實場景解讀——資料熱點問題

AOM功能強大，涉及多種典型業務場景，如資料熱點、時序資料、實時監測等，因此選擇GaussDB(for Cassandra)作為底層資料支撐引擎。接下來就資料熱點問題作為切入點，揭祕GaussDB(for Cassandra)如何保障AOM在發生資料熱點時穩定執行。

場景復現：

監控運維海量資料時，表中特定資料存取頻率驟升，部分分割區產生熱點流量。表中主鍵設定不合理，某個分割區下的業務量驟增，流量衝擊會集中在一個分割區上，導致該分割區對應的token所在節點的CPU持續居高不下。

問題根因：

GaussDB(for Cassandra)是一個面向巨量資料場景的高度可延伸的高效能分散式資料庫，可用於管理海量的結構化資料。在業務使用的過程中，隨著業務量和資料流量的持續增長，一些業務的設計弊端逐漸暴露出來，降低了叢集的穩定性和可用性。例如主鍵設計不合理、單個分割區的記錄數或資料量過大、出現超大分割區鍵等問題，導致了節點負載不均衡、叢集穩定性下降等現象，這一類問題統稱為大key問題。產生大key的最主要原因是主鍵設計不合理，導致單個分割區的記錄數或資料量過大。一旦某個分割區存在海量資料時，對該分割區的存取會導致分割區所在server的負載變高，嚴重時甚至會導致節點OOM等後果。

在日常生活中，經常會發生各種熱門事件，例如應用中對某熱點新聞進行上萬次的點選瀏覽和評論時，會形成一個較大的請求量，這種情況下會在短時間內對同一個key頻繁操作，導致該key所在節點的CPU負載飆高，從而影響該節點上的其他請求，導致業務成功率下降。諸如此類的還有熱門商品促銷，網紅直播等場景，這些典型的讀多寫少的場景也會產生資料熱點問題。當某個key的請求在某一主機上的存取超過server極限時，會導致熱key問題的產生。大key往往是熱key問題的間接原因。熱key會造成以下危害：流量集中，達到物理網路卡上限；請求過多，快取分片服務被擊垮；資料庫擊穿，引起業務雪崩等。

在上述場景中，主要是表中主鍵結構不合理，從而導致大key和熱key的產生，表結構如下所示。movie表儲存了短視訊的相關資訊，分割區鍵為movieid，並且儲存了使用者資訊（uid）。如果movieid對應的視訊是一個熱門短視訊，有幾千萬甚至上億使用者點贊此短視訊，則該熱門短視訊所在的分割區非常大。

CREATE TABLE movie (
movieid text, 
appid int, 
uid bigint, 
accessstring text, 
moviename text, 
access_time timestamp, 
PRIMARY KEY (movieid, appid, uid, accessstring, moviename) 
)

解決方案：

  • 調整表結構。GaussDB(for Cassandra)與其他資料庫相比，具有更加靈活的資料結構，支援主鍵和分割區鍵的靈活設定，通過合理設定主鍵和分割區鍵，調整表結構與查詢語句，對錶中資料進行劃分，能夠有效優化查詢速度，提升運維效率。在上述場景中，movie表的主鍵設定不合理，查詢資料量十分龐大，耗時久。建立新表為如下所示表結構時，表中資料量顯著減少。新表用於儲存熱門短視訊資訊，只保留短視訊公共資訊，不包含使用者資訊，確保該表不會產生大的分割區鍵。
CREATE TABLE hotmovieaccess ( 
movieid text, 
appid int, 
accessstring text, 
access time timestamp, 
PRIMARY KEY (movieid, appid)
)
  • 使用快取。快取可以提高讀操作的響應性，需要使用額外的記憶體來儲存資料，從而儘可能減少必須完成的磁碟讀。隨著快取大小的增加，可以從記憶體提供服務的「命中」數也會增加。GaussDB(for Cassandra)內建的快取包括鍵快取和行快取等型別。鍵快取儲存了分割區鍵與行索引之間的一個對映，以便於更快地存取儲存在磁碟上的SSTable；行快取可以為每個分割區快取一定的行，提高頻繁存取的行的讀取速度。

在上述場景中，可以使用快取來緩解流量衝擊。業務應用先從快取中讀取熱點資訊，沒有查詢到則從資料庫中查詢，減少資料庫查詢次數。整體邏輯流程如下所示。

資料熱點檢測工具：

資料熱點會給業務帶來壓力，影響業務正常執行。出現資料熱點後再去解決為時已晚，因此需要預知資料熱點問題，提前設計解決方法，保證業務正常執行。為此，GaussDB(for Cassandra)為業務提供了大key和熱key的檢測和預警工具。

    • 大key檢測。通過大規模業務觀察學習，GaussDB(for Cassandra)定義超過以下任意閾值的key即為大key：1. 單個分割區鍵的行數不能超過10萬行；2. 單個分割區的大小不超過100MB。
    • 熱key檢測。通過大規模業務觀察學習，GaussDB(for Cassandra)定義存取頻率大於100000次/min的key即為熱key。

GaussDB(for Cassandra)支援大key和熱key的檢測和告警工具，客戶可根據實際業務需求，在產品介面設定範例的大key和熱key告警。同時，在發生大key和熱key事件時，系統會第一時間傳送預警通知，客戶可在產品介面檢視監控事件資料，及時處理相關告警，避免業務波動。

總結：

針對資料熱點問題，GaussDB(for Cassandra) 提供了大key和熱key的實時檢測，以幫助業務進行合理的方案設計，規避業務穩定性風險；提供了大key和熱key的實時監控，確保第一時間感知業務風險；提供了大key和熱key的解決方案，在面對巨量資料量洪峰場景時，增強了叢集的穩定性與可用性，為客戶業務持續穩定執行保駕護航。

綜上所述，線上業務在使用GaussDB(for Cassandra)時，必須執行相關的開發規則和使用規範，在開發設計階段就降低使用風險。一般按照「制定規範」→「接入評審」→「定期巡檢」→「優化規則」的治理流程進行。合理的設計一般會降低大部分風險發生的概率，對於業務來說，任何表的設計都要考慮是否會導致大key和熱key的產生、是否會造成負載傾斜的問題。另外需要建立資料老化機制，表中的資料不能無限制的增長而不刪除或者老化。針對讀多寫少的場景，要增加快取機制，來應對讀熱點問題，提升查詢效能；針對每個分割區鍵以及每行資料，要控制其大小，超出限制後要及時優化，否則將影響效能和穩定性。

結論

AOM和GaussDB(for Cassandra)的組合成功打造了一套高效、可延伸、高效能、靈活和可客製化的海量資料監控運維平臺，可以幫助企業更好地管理和利用監控資料，提高運維效率，助力企業在不斷變化的市場環境中保持競爭優勢。

 

點選關注，第一時間瞭解華為雲新鮮技術~