啟用資料價值,探究DataOps下的資料架構及其實踐丨DTVision開發治理篇

數棧DTinsight發表於2022-09-30

據中國信通院釋出,2012 年到 2021 年 10 年間,我國數字經濟規模由 12 萬億元增長到 45.5 萬億元,在整個 GDP 中的比重由 21.6% 提升至 39.8%。順應時代發展新趨勢,“資料” 成為新的生產要素已是毋庸置疑的共識。

如果說資料中臺的崛起代表著企業數字化轉型從流程驅動走向資料驅動,從數字化走向智慧化。那麼 DataOps,則是實現資料中臺的一個優秀的理念或方法論。

DataOps 的概念早在 2014 年即由 Lenny Liebmann 提出,2018 年 DataOps 正式被納入 Gartner 的資料管理技術成熟度曲線當中,標誌著 DataOps 正式被業界所接納並推廣起來。雖然目前在國內仍處於發展初期,但是 DataOps 的熱度逐年上升,在可預見的未來 2-5 年內將得到更加廣泛的實踐應用。

袋鼠雲便是其中的一位探索者。作為全鏈路數字化技術與服務提供商的袋鼠雲,從創立以來便一直深耕大資料領域。伴隨著各行各業加速數智化轉型的步伐逐年加快,對於資料治理、資料管理等方面的許多問題也逐漸顯露。

為此,在技術進步和客戶數字轉型需求的驅動下,袋鼠雲打造的一站式大資料開發與治理平臺 —— 數棧 DTinsight,基於 DataOps 理念開展資料價值化流程,實現了資料全生命週期的質量監管和資料開發流程規範,為資料治理保駕護航。

響應變化

DataOps 的核心理念之一就是及時響應需求端的變化。下面是一張很典型的企業資料架構圖:

資料從左側的源系統流入,中間環節是各類資料處理的工具,例如資料湖、資料倉儲或資料集市、AI 分析等,資料經過清洗、加工、彙總統計、資料治理等過程,最終透過 BI、定製化報表、API 等工具服務於各類需求方。

file

企業內的資料架構師或管理者,在定義平臺架構時,一般主要考慮生產環境下的極致的效能、延遲、負載管理等問題,很多計算引擎 / 資料庫都精於此道。但這種架構並沒有體現出「響應快速變化」的能力:

這就像是設計一條公路,在設計時只考慮了正常情況下的通行能力,並沒有考慮事故、堵車、暴雨等各種臨時變化,在「上線」之後發現每日疲於應對,並沒有提升太多通行能力(比如只有 2 個車道的隧道,一個小的剮蹭事故就可能把整條隧道堵住)。企業內的資料平臺也會遇到類似的情況,企業內的資料工作者,每天甚至每個小時都要響應這種變化,有時一個簡單的 SQL 變更上線甚至可能要花幾天的時間。

在設計階段考慮各種變化,可以更靈活、更穩定的響應,下面是 DataOps 視角下的資料架構。

DataOps 視角下的資料架構

資料架構師在建設伊始就提出如下一些敏捷性的標準,例如:

・任務從完成開發到釋出生產,需要在 1 小時內完成,且對生產環境無影響

・在釋出至生產環境前,及時發現資料錯誤

・重大變更,在 1 天內完成

同時需要考慮一些環境的問題,包括:

・必需維護獨立的開發、測試和生產環境,但要在一定程度上保證其一致性,至少是後設資料的一致性

・可以人工編排,或自動化的實現資料的測試、質量監控以及部署至生產環境

當架構師開始思考資料質量、快速釋出、資料的實時監控等問題時,企業就向 DataOps 邁進了一步。

DataOps 架構的分解與實踐

講完了 DataOps 視角下的資料架構,接下來來講講 DataOps 架構的分解與實踐。DataOps 具體實踐可以分解為如下幾個關鍵點:

file

多環境的管理

DataOps 的第一步從「環境管理」開始,一般是指獨立的開發、測試和生產環境,每個環境下都可以支援任務的編排、監控和自動化測試。

數棧目前可支援同時對接多套環境,只要網路相通,即可實現一套數棧對多個不同環境的統一對接和統一管理。數棧是透過 Console 中的「叢集」概念來進行不同環境的區分,不同的叢集可靈活對接各類不同的計算引擎,例如各類開源或發行版 Hadoop、星環 Inceptor、Greenplum、OceanBase,甚至 MySQL、Oracle 等傳統的關係型資料庫,如下圖所示:

file

任務釋出

承接上個步驟的多環境管理,在實際開發過程中,需要進行多個環境之間的任務釋出,假設存在開發、測試、生產環境,則需要在多個環境之間進行級聯形式的釋出,如下圖所示:

file

在這種多環境釋出的情況下,數棧可支援三種方式進行釋出管理:

● 一鍵釋出

當各個環境網路相通,可使用一套平臺對接各個環境,實現「一鍵釋出」。一鍵釋出過程中,僅有一定許可權的使用者才可以執行釋出動作,提升生產環境穩定性。與此同時,可自動替換一些關鍵的環境資訊,例如同步任務中的資料來源連線引數、不同環境下的算力配置等。一鍵釋出比較適合 SaaS 或內部雲平臺的管理方式。

● 匯入 / 匯出式釋出

在目前國內接觸的絕大多數場景中,客戶為了實現更高的安全等級,生產環境會採用嚴格的物理隔離。這種場景可以採用匯入匯出的方式實現任務的跨環境釋出,使用者可手動將新增、變更或刪除的任務匯入至下游環境。

● Devops 釋出

某些客戶可能已經採購或自研了公司級的線上釋出工具,此時需要數棧定製化的對接其介面,將相關變更資訊由第三方 CI 工具(例如 Jekins)代為執行釋出。  file

程式碼的版本管理

每次進行跨環境的釋出時,需要記錄每次釋出程式碼的版本,便於後期排查問題。在實際場景中,經常需要進行不同版本間的程式碼對比、版本回退等操作。

數棧除了支援對程式碼內容進行對比之外,還支援對任務相關的更多資訊進行對比,包括任務排程週期的配置、任務執行引數、環境引數等,並可以「一鍵回退」至指定的版本。

file

訪問與許可權管理

在企業內的多個環境中,一般對生產環境的要求最高,對開發和測試環境相對寬鬆。在這種情況下,即需要管理使用者在不同環境下的認證或訪問資訊。實際上為了開發和測試方便,且沒有敏感資料,在這 2 個環節,一般是普通使用者都有全部的資料許可權,並可以訪問各種工具,但在生產環境中,使用者肯定只有自己許可權範圍內的資料許可權。

根據引擎的不同,數棧可支援多種資料許可權管理方式,包括:

● Hadoop 引擎

以 Kerberos 為基礎的認證安全 + 以 Ranger/LDAP 為基礎的資料安全。可以支援庫、表、欄位級別的資料許可權控制。同時可支援資料脫敏。

file

● JDBC 類引擎

部分場景中,客戶可能並未採用 Hadoop 來建設資料平臺,而是採用一些 JDBC 類的資料庫(例如 TiDB、Doris、Greenplum),而數棧本身並不管理 JDBC 資料庫的許可權,而是採用賬號繫結的方式來控制,以此區分不同賬號的許可權,例如:

・數棧 A 賬號,繫結資料庫 root 賬號

・數棧 B 賬號,繫結資料庫 admin 賬號

● 任務編排、測試與監控

在釋出上線至生產後,數棧可將上述各個環節串連起來,使用者從開發階段可以一鍵釋出至測試環境,經測試環境驗證後,觀察任務例項、資料產出的執行情況,執行無誤後可釋出至生產環境。

寫在最後的話

DataOps 是一種最佳實踐的理念,但目前在國內還處於比較早期的階段,數棧在這方面有過一些實踐經驗,但還有不少可以最佳化的內容,比如資料質量的規則也需要跨環境釋出、任務程式碼、任務模板的匯出需要支援更多的任務型別等等,期待未來行業內有更多的 DataOps 的最佳實踐能產生。


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

相關文章