《資料資產管理核心技術與應用》讀書筆記-第五章:資料服務(二)

张永清發表於2024-08-26

《資料資產管理核心技術與應用》是清華大學出版社出版的一本圖書,全書共分10章,第1章主要讓讀者認識資料資產,瞭解資料資產相關的基礎概念,以及資料資產的發展情況。第2~8章主要介紹大資料時代資料資產管理所涉及的核心技術,內容包括後設資料的採集與儲存、資料血緣、資料質量、資料監控與告警、資料服務、資料許可權與安全、資料資產管理架構等。第9~10章主要從實戰的角度介紹資料資產管理技術的應用實踐,包括如何對後設資料進行管理以發揮出資料資產的更大潛力,以及如何對資料進行建模以挖掘出資料中更大的價值。

圖書介紹:資料資產管理核心技術與應用

今天主要是給大家分享一下第五章的內容:

第五章的標題為資料服務

內容思維導圖如下:

本文是接著

《資料資產管理核心技術與應用》讀書筆記-第五章:資料服務(一)

繼續往下講。

1.5、 資料服務的監控與告警

在完成了資料服務的配置後,資料服務在呼叫時,還需要進行監控,在監控到發生故障時還需要支援自動傳送告警通知資訊,這樣才能更好的保障資料服務的穩定性。在書中的資料監控與告警那一章節中,有提到資料服務的監控與告警的技術設計實現主要是透過非同步採集資料服務的呼叫日誌,然後再配合Prometheus與Grafana來完成,如下圖所示。《資料資產管理核心技術與應用》是清華大學出版社出版的一本圖書,作者為張永清等著

從圖中可以看到資料服務的監控與告警的關鍵在於資料服務的日誌資料採集,這就意味著資料服務在被呼叫時,需要輸出日誌,為了讓資料服務的監控更加準確和細緻,日誌在設計時,通常建議包含如下表6中的常見欄位。《資料資產管理核心技術與應用》是清華大學出版社出版的一本圖書,作者為張永清等著

欄位名稱

欄位描述

appId

被呼叫的資料服務的ID,這個ID代表了具體的某個資料服務的身份

requestArgs

呼叫資料服務時,傳入的請求引數

cliendIp

資料服務平臺端獲取到請求方的IP地址

requestTime

請求方呼叫資料服務時的時間戳,通常建議精確到毫秒

receiveTime

資料服務平臺端接收到請求的時間戳,通常建議精確到毫秒

responseTime

資料服務平臺處理完請求後的響應給請求方結果時的時間戳,通常建議精確到毫秒

queryDataDuration

資料服務平臺在查詢資料過程中的耗時時長

responseMessage

資料服務平臺處理完請求後響應給請求方的響應結果

exception

資料服務平臺在處理請求的過程中發生的異常資訊,如果沒有異常時,該欄位會保持為空

在輸出日誌時,可以透過JSON的格式,將表格中的欄位都包含進去,然後再透過日誌採集的方式採集到這些JSON日誌後傳送到訊息佇列中供資料處理程式做日誌資料的解析,之後再傳送到Prometheus的Pushgateway元件中。

常見的日誌採集工具如下表所示。《資料資產管理核心技術與應用》是清華大學出版社出版的一本圖書,作者為張永清等著

日誌採集工具

描述以及下載與部署地址

Flume

Apache 基金會下的開源專案,使用Java語言實現的日誌採集工具,Github地址為https://github.com/apache/logging-flume

Logstash

基於Pipeline 實現的開源日誌採集工具,Github地址為https://github.com/elastic/logstash

Fluentd

基於C/Ruby實現的可插拔開源日誌資料採集工具,Github地址為https://github.com/fluent/fluentd

Splunk

非開源的商業性質的日誌採集和處理以及儲存工具,官方網址為http://www.splunk.com/

在透過採集獲取到JSON的日誌資料後,經過對日誌資料的加工處理後,通常可以生成如下的核心指標資料用於監控,如下圖所示。

  • 請求處理的耗時很長時,代表資料服務的處理很慢,此時需要檢查是否是資料服務的處理能力或者伺服器資源不夠。
  • 請求中網路的耗時很長時,很可能是網路的頻寬不夠或者網路經常性的出現了抖動等,需要對網路鏈路進行排查。
  • 資料查詢的耗時很長時,代表了查詢資料庫查詢很慢,此時需要檢查資料庫中是否有慢查詢或者是資料庫的資源不夠。
  • 發生異常的次數代表了請求處理中發生了異常,如果異常次數達到了一定的閾值,那就需要排查是資料服務出現了故障還是請求方的請求引數錯誤等。
  • 呼叫次數代表了請求方的呼叫量,也是衡量請求方請求併發是否很大的一個重要指標,如果呼叫量超過了資料服務的處理能力,需要及時增加資源進行擴容或者需要及時詢問請求方為啥呼叫量會非常大的原因,同時也需要檢查是否是資料服務受到了外部的惡意攻擊導致的。

2、資料服務的效能

一個好的資料服務除了需要有好的設計外,還需要有好的效能,效能最直觀的表現就是資料的查詢能力,資料的查詢能力越快,那麼資料服務的效能肯定也會越好,通常情況下效能的最佳化主要體現在SQL最佳化、資料庫最佳化、架構設計最佳化、硬體最佳化等幾個方面,如下圖所示。

  • (一)、SQL最佳化:這個很容易理解,就是提高SQL語句的查詢效能,定位一個SQL查詢效能的常用步驟如下圖所示。《資料資產管理核心技術與應用》是清華大學出版社出版的一本圖書,作者為張永清等著

從圖中可以看到:

第一步需要儘快的找到效能查詢慢的SQL語句,可以透過查詢資料庫的慢查詢日誌或者對資料庫的查詢做監控等方式來獲取慢SQL,只有知道了慢SQL才好去做下一步分析。

第二步透過檢視SQL語句在資料庫中的執行計劃來分析SQL語句查詢慢的具體原因,一般來說,不管是什麼型別的資料庫,都可以檢視到其執行SQL語句時的執行計劃。

第三步是根據分析到的原因來對SQL語句做調優,常用的調優方式就是如果沒有索引,那就增加索引,如果是有索引,但是沒有命中索引,那就調整SQL語句的寫法讓其正確的命中相關索引。

  • (二)、資料庫最佳化:當資料量確實達到了超高的資料量級,透過SQL最佳化不能解決問題時,就需要透過資料庫最佳化來解決效能問題。資料庫最佳化的常用方式包括使用快取、讀寫分離、分庫分表等,如下所示。

A、使用快取:指的是資料庫查詢的快取,將一些常用的熱資料提前載入到快取中,通常情況下是儘可能給資料庫分配比較大的記憶體,讓資料查詢時,將資料載入到快取中,那麼下次查詢時,就不需要 從物理儲存中拉取資料了,如下圖所示。

B、讀寫分離:讀寫分離是一種從資料庫角度來進行的架構最佳化,當資料服務是“讀多寫少”時,資料庫因為資料量太大,不能扛住高併發的查詢時,可以採用讀寫分離的方式,讓更多的資料查詢從從庫的只讀節點來查詢,如下圖所示。

C、分庫分表:分庫分表是針對單表資料量過大時的一種常用解決方案,當資料量達到單表的瓶頸時,採用分表的方式來讓資料重新分佈。當資料量達到單庫的瓶頸時,採用分庫的方式來讓資料重新分佈,如下圖所示。

分庫分表的常用方式如下:

1)、按照冷熱資料分離的方式:通常將使用頻率非常高的資料稱之為熱資料,查詢頻率較低或者幾乎不被查詢的資料稱之為冷資料,冷熱資料分離後,熱資料單獨儲存,這樣熱資料的資料量量就下降下來了,查詢的效能自然也就提升了,如下圖所示。

除了按照圖所示的方式來做冷熱資料分離外,隨著硬體技術的發展,比如像記憶體價格的下降以及SSD固態硬碟的出現, 還可以按照如下圖所示的方式來自動做冷熱資料載入和分離,可以根據一定的規則來判斷什麼時候需要將普通硬碟中的資料預載入到SSD或者記憶體中,來加快資料查詢的效能,由於SSD和記憶體中不能儲存大量的資料,所以還需要設定一定的規則,將SSD和記憶體中不查詢的資料定期清除來釋放快取的空間。

2)、按照時間維度的方式:可以按照實時資料和歷史資料分庫分表,也可以按照年份、月份等時間區間來進行分庫分表,如下圖所示,目的是儘可能的減少單個庫表中的資料量。《資料資產管理核心技術與應用》是清華大學出版社出版的一本圖書,作者為張永清等著

3)、按照一定的演算法計算的方式:當資料都是熱資料的情況下,比如資料確實無法做冷熱分離,所有的資料都經常會被查詢,並且資料量又非常的大。此時就可以根據資料中的某個欄位做演算法計算(需要特別注意這個欄位一般是資料查詢時的檢索條件欄位),使得資料能均勻的落到不同的分表中去,查詢時再根據查詢條件中的該欄位做演算法計算就可以快速的定位到是需要到哪個表中去進行查詢,如下圖。

4)、按照時間維度的方式:可以按照實時資料和歷史資料分庫分表,也可以按照年份、月份等時間區間來進行分庫分表,如下圖所示,目的是儘可能的減少單個庫表中的資料量。

5)、按照一定的演算法計算的方式:當資料都是熱資料的情況下,比如資料確實無法做冷熱分離,所有的資料都經常會被查詢,並且資料量又非常的大。此時就可以根據資料中的某個欄位做演算法計算(需要特別注意這個欄位一般是資料查詢時的檢索條件欄位),使得資料能均勻的落到不同的分表中去,查詢時再根據查詢條件中的該欄位做演算法計算就可以快速的定位到是需要到哪個表中去進行查詢,如下圖所示。

  • (三)、架構設計最佳化:當SQL最佳化和資料庫最佳化不能解決效能問題時,就需要考慮從架構設計上來進行最佳化,常見的架構設計最佳化手段如下:

1)、透過訊息佇列削峰填谷:在呼叫量的峰值非常大時,透過訊息佇列緩衝呼叫的請求,然後讓請求非同步的處理完後,再同步給請求的呼叫方,如下圖所示。《資料資產管理核心技術與應用》是清華大學出版社出版的一本圖書,作者為張永清等著

2)、透過使用分散式資料庫來進行處理,分散式資料庫是資料庫中一種MPP(Massively Parallel Processing的簡寫)的架構實現,常見的分散式資料庫包括Doris(可以透過官網https://doris.apache.org/瞭解更多關於Doris的介紹)、Greenplum(可以透過官網https://greenplum.org/瞭解更多關於Greenplum的介紹)等。

3)、部署架構的最佳化,比如可以透過Kubernetes的方式來部署,因為Kubernetes可以支援動態的擴縮容, 在保障了資料服務的效能的同時,還可以透過彈性的伸縮來控制成本。

  • (四)、硬體最佳化:硬體最佳化的常用手段就是對硬體資源進行擴容或者提高硬體資源的效能,常見的手段如下:
    • (1)、使用I/O讀寫更快的硬體,比如使用SSD硬碟來替代普通的機械硬碟。
    • (2)、透過增加伺服器的數量或者增加伺服器的配置來對伺服器進行橫向或者縱向的擴容。
    • (3)、增加網路的頻寬或者使用頻寬更大網路裝置來提高網路通道的傳輸速度。

未完待續......《資料資產管理核心技術與應用》是清華大學出版社出版的一本圖書,作者為張永清等著

相關文章