資料管理架構:單體資料架構與分散式資料網格比較 - enyo

banq發表於2021-08-08

這篇博文將幫助讀者瞭解單體資料架構、與單體資料架構相關的挑戰,以及分散式資料網格如何幫助組織將其分析資料轉換為產品並構建高度可擴充套件、彈性和資料驅動的應用程式。目標受眾是有興趣瞭解更多關於單體資料架構和分散式資料網格的軟體工程師、資料工程師、資料科學家、MLOps 工程師、軟體開發人員和資料庫架構師。
資料管理架構控制組織如何收集、儲存、保護、排列、整合和使用資料。良好的資料管理架構可以清楚地瞭解資料的各個方面,以及企業如何充分利用資料以促進業務增長和盈利。相反,糟糕的資料管理架構會導致資料集不一致、資料孤島和資料質量問題,從而使資料毫無價值或影響組織執行分析、資料倉儲 (DW) 和商業智慧 (BI) 活動的能力,尤其是大資料.
傳統上,大多陣列織更喜歡從一箇中央資料團隊和一個整體資料管理架構開始,其中所有資料操作都在一個單一的、集中的資料平臺之間進行。雖然整體資料架構相對容易設定,並且可以在不降低效能的情況下處理小規模資料分析和儲存,但隨著時間的推移,事情會變得不堪重負。此外,隨著資料量和需求的增加,中央資料管理團隊往往會成為瓶頸。
Zha m ak Dehghani 引入:分散式資料網格提供了一種協調並有望解決與以前的資料架構相關的挑戰的方法,這些挑戰通常被資料消費者和生產者之間的資料標準化挑戰所阻礙。分散式資料網格將我們推向更強大、敏捷、精簡、多功能的團隊和領域驅動 的業務結構。它以分散的方式結合了最佳的資料管理方法,同時保持了資料即產品的觀點、自助使用者訪問、領域意識和治理。
 

單體資料架構
單體資料架構是一個框架,其中應用程式資料從單個集中式資料儲存中儲存、轉換、操作、使用、管理等。單體資料架構由一個龐大的平臺團隊管理,適用於業務領域相對簡單且資料格局不會不斷變化的小型組織,但它們對不斷髮展的工程團隊提出了一些挑戰。讓我們來看看其中的一些挑戰。

  • 擴充套件性

首先擔心的是單體資料架構不能無限擴充套件,而且大多數單體資料庫根本不能自動擴充套件。隨著應用程式工作負載和資料量呈指數級增長,單體資料庫逐漸變得緩慢、昂貴且難以維護。對於具有快速和廣泛變化的用例、多個資料來源和資料消費者的組織來說,在一個地方使用和協調由一箇中央團隊管理的無處不在的資料的能力也會減弱。
  • 響應新需求

其次,單體資料庫通常具有高延遲和高吞吐量,這是由於應用程式中不同的斷開連線的團隊和方法的併發資料庫讀取/寫入而自然產生的。對於單體資料架構,在不改變整個資料管道的情況下響應新需求也具有挑戰性。
  • 創新和實驗的空間

第三,單體資料架構缺乏模組化,技術同質化。當單體資料庫出現故障或無響應時,它會影響整個應用程式並停止所有與資料庫相關的活動。此外,如果工程團隊被迫為應用程式採用單一資料庫,那麼創新和實驗的空間就不大了。
現在您瞭解了單體資料架構的含義和侷限性。現在讓我們看看一個更最佳化的資料架構,它主要解決與單體架構相關的挑戰。
 

分散式資料網格
這是一種支援分散式高度分散的資料網格,將“資料即產品”視為產品,並支援分散式、“特定領域的資料所有者”,負責以易於使用、使用者友好的方式處理自己的資料產品和管道,同時增強不同位置的分散式資料之間的通訊。在許多方面,分散式資料網格是微服務的平臺版本
透過將整個資料架構分解為更小、面向領域和更分散的元件,並讓不同的團隊管理每個領域,工程團隊可以透過分散式資料網格輕鬆實現可擴充套件性。這樣,隨著用例數量、資料來源和訪問模型多樣性的增加,可以更輕鬆地進行橫向擴充套件。它還允許團隊構建高度可擴充套件、資料驅動的應用程式並有效地使用資料來更好地改進營銷活動、降低成本、最佳化業務運營並做出更明智的決策。
分散式資料網格具有自助式“基礎設施即平臺”和“聯合計算治理”設計,可實現域自治,併為資料產品監控和治理、資料標準化提供與域無關、可互操作和通用的方法、日誌記錄、警報、產品質量指標等。在分散式資料網格中,資料庫故障的影響大大降低,每個團隊都可以更改其資料平臺、引入新功能並部署功能更新,而無需更改其他資料儲存。
 

何時從單體資料網格過渡到去中心化資料網格
分散式資料網格並不是適合所有組織和團隊的靈丹妙藥。可以想象,單體資料架構也不會消失。在從單體式資料架構過渡到分散式資料架構之前,組織需要做好功課並確保遷移對企業來說是一個明智的決定。
以下是組織及其團隊在評估向分散資料網格過渡的準備情況時應提出的一些問題:

  • 資料團隊規模:我們的資料團隊有多少資料工程師、資料分析師、資料科學家和產品經理?
  • 資料大小:我們的資料有多大?它以什麼速度增長?
  • 資料多樣性和來源:我們有多少資料用例和來源?
  • 資料瓶頸:資料團隊多久忙於解決技術債務(因此減緩新資料產品的實施並使其成為瓶頸)?
  • 交貨時間:儘管我們的團隊規模不斷擴大,但每個團隊的成員是否相互脫節,或者他們是否缺乏領域知識?
  • 資料域的數量:有多少職能團隊依賴我們的資料儲存做出決策,我們有多少資料驅動的產品和功能?
  • 資料治理:我們組織的資料治理有多少偏好?是否存在關於誰控制的政治內訌



 

相關文章