資料湖和中央資料倉儲的設計

大資料技術前線發表於2023-12-06

來源:小技術君

設計資料湖或中央資料倉儲是許多大型組織的主要職能,這些組織每天處理數百萬筆交易,並對這些交易進行進一步的報告、預測或機器學習專案分析。

為了將所有來自源系統(我們稱之為“上游”)到其他業務應用(所謂“下游”)的資料點整合在一起,已經成為資料智慧或商業智慧團隊的一個不同的工程奇蹟。在完成所有這些練習和從上游到下游的緊密依賴後,管理資料變得越來越難以透過所有資料管道進行檢查。

在大多陣列織中,我們可以看到以下資料流程是從如下所示開始的:

資料湖和中央資料倉儲的設計

新應用程式或多或少是按領域驅動設計,這些應用程式與更特定於應用程式的資料非常緊密,這給資料庫工程團隊帶來了新的挑戰,要為滿足所有方面的目的提供有組織的解決方案,如下所示:

資料湖和中央資料倉儲的設計

資料網格(Data Mesh)具有相同的功能集,以滿足領域驅動的分散化的目的。為了設計資料網格,強調遵循4個原則,並針對組織中不同團隊提供了不同的責任。

資料湖和中央資料倉儲的設計

領域資料的所有權

由於我們採用了領域驅動的分散化方法,因此在資料網格中,資料圍繞著特定的業務領域進行拆分,就像我們在微服務中所做的那樣。在資料領域中也是如此,將存在一個負責跟蹤活動性的資料領域團隊。資料領域團隊可以使用資料建立資料產品,其他資料領域團隊可以使用這些資料產品。

資料作為產品

在資料網格中,資料被視為可以由一個資料領域團隊釋出並可以被另一個資料領域團隊消費的產品。資料領域團隊必須以產品思維來考慮資料,他們對資料質量、表示和內聚性負完全責任。此外,資料領域團隊必須與資料網格啟用團隊合作,以獲取資料產品的資格。

自主驅動的資料平臺

資料網格中的所有資料都可以在公司內部任何地方使用。因此,可以在短時間內建立新的報告或資料產品,並傳播到隨後的資料產品。這帶來了治理問題,因為資料的控制可以透過治理政策進行。

聯合治理

治理透過不同的資料政策和安全政策進行處理,由資料領域團隊根據資料釋出和資料消費受到的不同合同來執行。然而,如果政策未正確定義,治理可能是資料的一個問題點。

資料網格架構

資料網格具有多種架構,可以使用不同的語言和它們的框架進行定義。這完全取決於團隊特定的實現,這些實現用於實現資料產品。

資料湖和中央資料倉儲的設計

資料網格的路線圖可以由不同團隊共同設計和實施。每個團隊都有維護資料網格的責任。

資料網格啟用團隊

啟用團隊是資料網格架構的主要團隊,用於與資料領域團隊進行連線。他們為資料產品建立原型和文件。他們指導資料領域團隊遵循定義的資料產品規則,並幫助他們為資料網格授予資料產品。

資料平臺團隊

平臺團隊主要維護基礎設施,以維護資料對資料網格的可用性。他們用於維護所有資料產品的資料目錄。資料目錄可以是其他資料領域團隊查詢資料網格並設計他們的資料產品的後設資料。資料平臺團隊還擁有資料儲存、監控和訪問資料網格的矩陣。

資料領域團隊

資料領域團隊可以是建立

應用程式或資料產品的工程或開發團隊。資料產品是運算元據、分析功能和來自其他資料產品的資料的組合。其他資料產品也可以使用類似的方式。

行業團隊

行業團隊擁有資料治理政策,並負責建立資料、安全和其他合規政策。定義政策有助於定義資料網格中資料產品的可訪問性。

資料網格是新的現代化資料架構模式,可以在不久的將來在企業級別實施。資料網格架構中有很多值得探索的地方

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/70027827/viewspace-2998728/,如需轉載,請註明出處,否則將追究法律責任。