建站
咨詢
售后
建站咨詢
新聞中心
一、背景
數(shù)據(jù)治理項目通常伴隨著監(jiān)管壓力、高成本和不明確的投資回報。識別關鍵數(shù)據(jù)、管理元數(shù)據(jù)、控制數(shù)據(jù)質量和確定數(shù)據(jù)來源的程序通常耗時較長且成本高昂。比如銀行業(yè)的相關年度成本很容易超過每年 1000 萬元，有時甚至超過 1 億元。執(zhí)行過程既痛苦又緩慢，因為需要在數(shù)百個系統(tǒng)和應用程序中手動識別數(shù)千個數(shù)據(jù)元素，而這些系統(tǒng)和應用程序通常是在過去幾十年創(chuàng)建的。
武穴網(wǎng)站建設公司成都創(chuàng)新互聯(lián),武穴網(wǎng)站設計制作，有大型網(wǎng)站制作公司豐富經驗。已為武穴近千家提供企業(yè)網(wǎng)站建設服務。企業(yè)網(wǎng)站搭建\外貿營銷網(wǎng)站建設要多少錢，請找那個售后服務好的武穴做網(wǎng)站的公司定做！
也許其中最難以捉摸的是數(shù)據(jù)沿襲。一些供應商已經設法創(chuàng)建可以掃描系統(tǒng)和收集元數(shù)據(jù)的工具，但它們通常無法連接到大多數(shù)現(xiàn)有系統(tǒng)環(huán)境。由于數(shù)據(jù)流通常沒有在整個企業(yè)中進行結構性和一致的記錄，因此主要依靠供應商知識和手動映射工作來編譯它們。當供應商紛紛離開時，這種知識就會離開企業(yè)，情況也會變得更加嚴重。
此外，即使業(yè)務和技術元數(shù)據(jù)已被記錄為協(xié)調補救計劃的一部分，但由于元數(shù)據(jù)捕獲和記錄不是自動化的，大多數(shù)元數(shù)據(jù)很快就會過時。保持其最新需要持續(xù)的手動工作。
最后，組織將這些元數(shù)據(jù)共享到企業(yè)的業(yè)務部門，以實現(xiàn)除數(shù)據(jù)治理本身之外的業(yè)務目的。許多大型組織都有數(shù)據(jù)戰(zhàn)略，以某種形式闡明數(shù)據(jù)管理基礎也應該為數(shù)據(jù)科學等業(yè)務目的提供支持，但很少有人在實踐中成功實現(xiàn)這一點。
基于云的技術的出現(xiàn)帶來了可擴展性、彈性、更低的成本、快速部署和增強的數(shù)據(jù)技術兼容性的承諾。在過去幾年中，我們與各種組織就其云遷移和數(shù)據(jù)現(xiàn)代化計劃進行了合作，從設計的那一刻起就出現(xiàn)了如何智能管理數(shù)據(jù)的模式。
例如，可以為 API 定義互操作標準，以便未來數(shù)據(jù)沿襲可視化中的日志記錄和治理實現(xiàn)自動化。數(shù)據(jù)質量控制可以基于一致的數(shù)據(jù)模型創(chuàng)建并直接嵌入到新的基礎設施中。轉換期間存在的知識不會丟失或降級，因為有關數(shù)據(jù)元素及其來源的關鍵信息會輕松記錄在數(shù)據(jù)目錄中。
接下來將進一步詳細闡述數(shù)據(jù)治理設計的概念，并解釋如何通過數(shù)據(jù)資產、數(shù)據(jù)管理中心和 API 驅動架構等功能（通過稱為 Data Fabric 的數(shù)據(jù)層）實現(xiàn)數(shù)據(jù)治理。
二、框架
在基于服務的架構中，微服務連接組織的業(yè)務流程。在這樣的架構中，四個基礎組件可以共同實現(xiàn)數(shù)據(jù)管理和數(shù)據(jù)治理的設計。下面提供了一個示例：描述了一個擁有 5 個部門（風險與合規(guī)、財務、營銷、客戶管理和產品開發(fā)）的組織。每個部門創(chuàng)建并維護多個數(shù)據(jù)產品，其中一部分被歸類為“數(shù)據(jù)資產”，因為其他部門的消費者也使用它們。不同部門之間，各種API交換數(shù)據(jù)和信息。所有這一切都是根據(jù)數(shù)據(jù)基礎結構精心策劃的，并由數(shù)據(jù)管理中心掃描并提供數(shù)據(jù)管理和服務。讓我們快速瀏覽一下這些組件。
數(shù)據(jù)資產——每個域或部門通常都會生成供其他域使用的數(shù)據(jù)或信息。例如，客戶管理域可以通過入職和客戶關系管理流程收集客戶數(shù)據(jù)，以生成和維護包含客戶信息的中央數(shù)據(jù)庫。營銷團隊可以使用該數(shù)據(jù)庫來執(zhí)行銷售活動，風險部門可以使用該數(shù)據(jù)庫來確認是否遵守數(shù)據(jù)隱私法規(guī)。此類數(shù)據(jù)產品被賦予了不同的標簽，其中包括數(shù)據(jù)產品、數(shù)據(jù)資產、可信來源、權威數(shù)據(jù)源和記錄系統(tǒng)。
API 驅動的架構——不同的團隊通過 API 作為首選或唯一的數(shù)據(jù)集成方法進行連接。保持 API 優(yōu)先的理念可確保組織內部和外部的消費者都可以使用任何關鍵數(shù)據(jù)。
數(shù)據(jù)管理中心——在單獨配置的空間或環(huán)境中提供一組數(shù)據(jù)管理功能。這些功能包括元數(shù)據(jù)管理、主數(shù)據(jù)和參考數(shù)據(jù)管理以及數(shù)據(jù)質量。不必在組織的每個區(qū)域內構建這些功能，而是可以從中央數(shù)據(jù)管理進行部署。
Data Fabric— 提供跨所有系統(tǒng)和應用程序連接的線程稱為 Data Fabric。它不是一個可以憑空實例化的魔法層；相反，它由一組支持功能和經過仔細考慮的治理協(xié)議組成，這些協(xié)議共同使整個企業(yè)的數(shù)據(jù)可發(fā)現(xiàn)、編目、分類、標記、質量控制，并可通過通用的互操作性標準和渠道進行訪問。
采用數(shù)據(jù)資產理念管理
什么是數(shù)據(jù)資產
數(shù)據(jù)資產是一組準備好的數(shù)據(jù)（一般不是原始數(shù)據(jù)），可供更廣泛的消費者使用。它受到管理、貼上標簽、質量受控且易于訪問。它是可發(fā)現(xiàn)和描述的，以便為整個企業(yè)的消費者啟用自助服務。數(shù)據(jù)資產通常在整個企業(yè)中重復使用，并在給定的數(shù)據(jù)或業(yè)務域內擁有。
為什么被高度關注
鑒于數(shù)據(jù)資產被大量消費者使用，因此這是實施數(shù)據(jù)質量和治理控制的非常合乎邏輯的位置。在該受管資產中，內容被標記，數(shù)據(jù)質量受到嚴格控制，因此不必在整個企業(yè)中識別和測量這些數(shù)據(jù)，這通常會導致不一致的“事實版本”，而是有一個可信的分發(fā)點給定的數(shù)據(jù)集。例如，美國十大銀行已經啟動了一些計劃來識別這些關鍵數(shù)據(jù)源并對其進行管理。通常，大約 20 到 100 個數(shù)據(jù)資產將使組織能夠控制其所有關鍵數(shù)據(jù)，這比嘗試在 1000 個單獨系統(tǒng)中定義數(shù)據(jù)質量要有效得多。
數(shù)據(jù)資產采用
創(chuàng)建和定義數(shù)據(jù)資產還不夠。一個必要且同樣重要的步驟是管理它們的使用，因為如果消費者不使用它們，他們就無法從集中控制的數(shù)據(jù)質量中受益。因此，許多組織已經啟動了各種版本的數(shù)據(jù)資產采用計劃。通常，一方面包括共享流通，加強培育對數(shù)據(jù)資產及其使用好處的認識，另一方面包括合規(guī)標準和機制，要求只能從數(shù)據(jù)資產而不是任何地方使用別的數(shù)據(jù)。
業(yè)務用戶和影響
對于數(shù)據(jù)組織來說，除了難以衡量的價值（例如避免監(jiān)管罰款）之外，闡明它們?yōu)槠髽I(yè)增加的價值一直是一場歷史性的斗爭。數(shù)據(jù)資產在這里改變了游戲規(guī)則。僅當存在下游關鍵消耗時，數(shù)據(jù)源才能成為數(shù)據(jù)資產，因此建議記錄這些消費者及其用例。
構建數(shù)據(jù)資產和依賴于它們的用例的簡單概述可以清楚地闡明這些資產產生的影響。通過收集數(shù)據(jù)的下游需求并評估如何在受信任的分發(fā)點內控制和增強數(shù)據(jù)，也可以更有效地執(zhí)行影響評估。例如，一家領先的保險公司能夠相對精確地衡量一組增強的客戶數(shù)據(jù)如何使他們能夠更輕松地執(zhí)行和提高銷售活動的有效性。
如果沒有數(shù)據(jù)資產的識別和主動管理，結果通常是難以理解的數(shù)據(jù)流“蜘蛛網(wǎng)”，存在數(shù)據(jù)重復和不一致的情況。戰(zhàn)略性地使用數(shù)據(jù)資產，可以識別使用獨特的可重復使用的精選的數(shù)據(jù)源用例組。
三、數(shù)據(jù)資產治理
需要一個治理模型來將數(shù)據(jù)資產嵌入到 Data Fabric 中，以確保它不會被“壞”數(shù)據(jù)淹沒，其中“數(shù)據(jù)網(wǎng)格”是如何將此治理嵌入到組織中的主要方法。
數(shù)據(jù)網(wǎng)格
一個相對較新的術語是“數(shù)據(jù)網(wǎng)格”，它是一種使業(yè)務領域能夠在捕獲和維護數(shù)據(jù)的點管理其關鍵數(shù)據(jù)的方法，并由中央自助服務數(shù)據(jù)支持基礎設施。這與過去的努力形成鮮明對比，過去的組織試圖將其關鍵數(shù)據(jù)集中在數(shù)據(jù)湖和數(shù)據(jù)倉庫中。這種集中化工作通常會受到對中央數(shù)據(jù)團隊的過度期望的困擾，這些團隊沒有特定于業(yè)務的上下文來理解數(shù)據(jù)，因此無法跟上消費者所需的步伐?！芭K”數(shù)據(jù)湖是一種常見癥狀。
治理模式
某些業(yè)務或功能域可能已準備好立即管理其關鍵數(shù)據(jù)資產，但其他域可能還沒有。以銀行業(yè)為例，通常相對成熟的領域包括風險和金融，因為它們在遵守監(jiān)管數(shù)據(jù)治理準則方面擁有多年的經驗。
允許域所有者生成數(shù)據(jù)資產供其他人使用有幾個要求。首先，支持領域必須在數(shù)據(jù)管理和工程方面具備最低水平的所需技能和經驗。其次，域所有者必須在團隊內部或外部擁有所需的資源，或委派部分職責的預算。維護數(shù)據(jù)資產通常不是一項全職工作，但同時它確實意味著重大責任。
基于這些考慮，企業(yè)可以選擇適合的治理模式，每種治理模式都有各自的優(yōu)點和缺點。組織可以先選擇一種模式，但隨著時間的推移，可以發(fā)展到另一種模式。
治理建議
以下建議可以標準化任何模式的實施并降低其風險：
- 將數(shù)據(jù)資產的概念嵌入到企業(yè)變革方法中
- 制定并遵守一系列設計原則，其中包括數(shù)據(jù)資產的治理
- 堅持數(shù)據(jù)資產必須直接源自經確認的權威來源的設計原則
- 定義具有清晰描述的領域的權威企業(yè)數(shù)據(jù)模型
- 維護數(shù)據(jù)資產的中央目錄
- 堅持使用最少的所需元數(shù)據(jù)集，包括分類和其他與安全相關的元數(shù)據(jù)，以實現(xiàn)基于角色的訪問
- 定義并執(zhí)行可發(fā)現(xiàn)性和互操作標準
四、API 驅動的架構和互操作性標準
采用 API 優(yōu)先的理念以及明確定義的互操作性標準是確保未來數(shù)據(jù)流的治理和控制以及驅動自動數(shù)據(jù)沿襲捕獲、避免未來大量手動映射工作的關鍵。
API驅動架構
在 API 優(yōu)先的基礎架構中，不同的團隊通過 API 作為首選或唯一的數(shù)據(jù)集成方法進行連接。保持 API 優(yōu)先的理念可確保組織內部和外部的消費者都可以使用任何關鍵數(shù)據(jù)。如果做得正確，還應該推動對開放銀行標準等全球標準的遵守，從而為與戰(zhàn)略合作伙伴合作提供機會。
互操作標準
互操作標準由一組規(guī)則和協(xié)議組成，用于驅動不同系統(tǒng)和應用程序之間的交互和數(shù)據(jù)交換。如果我們用電來類比，您可以購買任何類型的電器，從冰箱到電燈或手機充電器，并且通常期望您可以將其連接到家中的插座。數(shù)據(jù)也類似——希望確保數(shù)據(jù)通過標準插座以商定的質量和數(shù)量提供，這些插座可供任何有權訪問房屋內不同房間的人使用。對于企業(yè)來說，就需要就接口類型以及向其提供數(shù)據(jù)的渠道達成一致。
沒有一套互操作標準適合每個組織，但有幾個維度或組件至關重要：
- 遵守數(shù)據(jù)模型以確保數(shù)據(jù)的使用和解釋的一致性，至少對于最小的一組關鍵數(shù)據(jù)而言如此
- 標準消息傳遞和有效負載格式
- 與系統(tǒng)和應用程序一起以標準化格式識別、維護和提供的最低業(yè)務和技術元數(shù)據(jù)
- 一組已確定的兼容技術
互操作工具集
擁有一套一致的互操作標準應該推動任何類型的兼容技術能夠與基礎設施交換數(shù)據(jù)。出于采用目的，建議確定至少 1 種也可能是幾種數(shù)據(jù)工程師可用于各自目的的 API 技術。
選擇哪種技術取決于組織、目標業(yè)務成果以及現(xiàn)有的技術堆棧和相應的專業(yè)知識。比如，一家區(qū)域零售組織決定采用 MuleSoft 作為其數(shù)字組織構建的首選 API 平臺，而一家大型領先制造商則選擇創(chuàng)建自己的內部構建的 API 功能。
通過 API 實現(xiàn)數(shù)據(jù)沿襲工業(yè)化
對于組織而言，存在巨大的機會來確保通過采用 API 優(yōu)先的思維方式將數(shù)據(jù)管理納入未來基礎設施的設計中：
- 可以定義 API 模式來滿足未來對數(shù)據(jù)和信息流的需求。示例模式包括異步、同步、編排和數(shù)據(jù)處理以及事件驅動模式。
- 在各種模式中，對齊與 API 一起提供的元數(shù)據(jù)腳本或文件。這些腳本應該標準化，并包含最少的業(yè)務和技術元數(shù)據(jù)集，例如源、目的地、提要頻率、包含的關鍵數(shù)據(jù)元素以及一系列指標（例如分類、PII 指標）。最佳實踐是，每次更新 API 時，這些元數(shù)據(jù)文件都會更新（如果可能，自動更新），并在 API 目錄中維護。
- 確保將 API 元數(shù)據(jù)文件推送或拉入元數(shù)據(jù)管理中。工具到位特別是數(shù)據(jù)目錄，以便可以創(chuàng)建譜系圖。
將驅動 API 作為系統(tǒng)間數(shù)據(jù)交換的主要手段與堅持最低標準相結合，推動“數(shù)據(jù)沿襲設計”。
注意：不要使元數(shù)據(jù)文件過于復雜。較小的關鍵元數(shù)據(jù)集優(yōu)于業(yè)務價值不明確的詳盡集。除了例外之外，默認情況下不需要包含詳細的數(shù)據(jù)元素級采購和轉換邏輯。
五、數(shù)據(jù)管理中心
與實施后手動執(zhí)行的治理活動相比，集中配置但本地采用的數(shù)據(jù)管理功能以更低的成本增強了數(shù)據(jù)的一致定義、治理和保護。
數(shù)據(jù)管理中心的重要性
為了通過設計推動數(shù)據(jù)管理，創(chuàng)建并提供一個單獨配置的管理中心并使其包含最低限度所需的數(shù)據(jù)功能至關重要。管理中心包含數(shù)據(jù)管理，應作為未來任何云原生業(yè)務或功能流程構建的一部分來引用和嵌入的功能。他們應該能夠從數(shù)據(jù)中自助服務這些功能，而不是讓每個轉換計劃或業(yè)務功能區(qū)域在如何確保正確使用主數(shù)據(jù)、管理元數(shù)據(jù)和監(jiān)控數(shù)據(jù)質量方面重新構建功能和標準。
數(shù)據(jù)管理需要設計
歷史上，絕大多數(shù)傳統(tǒng)數(shù)據(jù)管理投資都是在“事后”（即實施后）花費的。發(fā)現(xiàn)業(yè)務流程，識別數(shù)據(jù)元素，推斷業(yè)務需求，并根據(jù)現(xiàn)有基礎設施實施來衡量數(shù)據(jù)質量，這需要大量的人工工作和持續(xù)的紀律。
在這里的方法中，這些數(shù)據(jù)管理注意事項嵌入在設計和實施階段之前和期間。此外，稍后手動執(zhí)行的治理步驟將作為功能、非功能和技術需求集成為設計的一部分。隨著解決方案的實施，數(shù)據(jù)管理是“按設計”構建的。
“設計”功能示例
數(shù)據(jù)目錄 -正如上面針對 API 所概述的，但應用更廣泛，就應用程序及其之間的數(shù)據(jù)流而言的系統(tǒng)全面的發(fā)現(xiàn)、文檔和可視化可以自動化。
數(shù)據(jù)質量——監(jiān)控和確保數(shù)據(jù)質量和完整性的控制可以通過兩種主要方式嵌入。首先，可以在數(shù)據(jù)創(chuàng)建、捕獲和傳輸時應用特定的控制和限制。比如對接受或有效值的限制以及數(shù)據(jù)流中的協(xié)調檢查。其次，在數(shù)據(jù)資產等戰(zhàn)略位置，可以對靜態(tài)數(shù)據(jù)實施質量控制，以衡量完整性、準確性和及時性。
主數(shù)據(jù)和參考數(shù)據(jù)——數(shù)據(jù)資產的非常具體的示例，主數(shù)據(jù)和參考數(shù)據(jù)是非常強大的杠桿，可以推動在事務級別重復使用的數(shù)據(jù)的一致使用。比如MDM以確保在整個企業(yè)中，在入職、交易、客戶聯(lián)系、營銷和關系管理等流程中使用正確的客戶數(shù)據(jù)元素。同樣，提供易于訪問的參考數(shù)據(jù)（例如郵政地址標準）將推動其采用。
六、Data Fabric 作為系統(tǒng)之間的云原生粘合劑
提供跨所有系統(tǒng)和應用程序連接的線程稱為數(shù)據(jù)結構。它不是一個可以憑空實例化的魔法層；相反，它由一組支持功能和經過仔細考慮的治理協(xié)議組成，這些協(xié)議共同使整個企業(yè)的信息可發(fā)現(xiàn)、編目、分類、標記、質量控制，并可通過通用的互操作性標準和渠道進行訪問。
在很大程度上，該結構是由前面描述的數(shù)據(jù)資產、API 和數(shù)據(jù)管理中心組件啟用的。如果正確并充分地使用，它們應該形成數(shù)據(jù)結構的主要架構。但是，即使不是最低要求，也有一些互補的數(shù)據(jù)功能：
數(shù)據(jù)管道、攝取、準備、傳輸、供應和存儲——在 API 無法完成工作的情況下，替代或補充的數(shù)據(jù)交付和集成選項可以確保根據(jù)業(yè)務或業(yè)務來收集、攝取、轉換、管理和提供數(shù)據(jù)。功能要求。需要配置存儲來保存數(shù)據(jù)。
數(shù)據(jù)編排——根據(jù)目標用例和業(yè)務流程，可以應用數(shù)據(jù)編排來從各種來源獲取數(shù)據(jù)，組合和集成數(shù)據(jù)，并將其提供給數(shù)據(jù)分析工具。數(shù)據(jù)編排可以在 IaaS 或 PaaS 級別執(zhí)行，也可以使用抽象基礎設施級別活動的技術（例如 Apache Airflow、Prefect 和 Snowflake）來執(zhí)行。
數(shù)據(jù)安全和保護——監(jiān)控和確保敏感數(shù)據(jù)不丟失、不被濫用或被未經授權的用戶訪問的過程，并啟用主動保護數(shù)據(jù)資產的功能。政策和標準應規(guī)定如何保護數(shù)據(jù)以及如何共享數(shù)據(jù)。身份和訪問管理 (IAM) 可以促進基于角色的訪問，各種網(wǎng)絡和身份驗證保護措施可以保護數(shù)據(jù)免遭未經授權的訪問和操縱。
報告、分析和數(shù)據(jù)科學——可以創(chuàng)建一個或多個數(shù)據(jù)平臺來滿足報告或分析用例。具有數(shù)據(jù)資產、API 和數(shù)據(jù)管理。數(shù)據(jù)管理中心到位后，這將成為一項簡單的工作，因為數(shù)據(jù)可用、易于理解且易于獲取，并且在云原生環(huán)境中，可以按需激活相應的報告或數(shù)據(jù)科學工具，而無需大量的前期投資。
七、成功因素
讓我們以一些關于成功因素的想法來結束本文。取得成功的組織通常首先關注幾個選定的領域，從一開始就吸引業(yè)務利益相關者，確保將遵守法規(guī)和政策方面的好處與業(yè)務成果一起考慮，并堅持云優(yōu)先的設計原則。
- 從小規(guī)模開始——從組織相對良好的領域中的 1 或 2 個數(shù)據(jù)資產開始，其中物料、客戶和產品數(shù)據(jù)通常是強有力的候選者。在較小的規(guī)模上取得成功并利用聚集的動力來推動其他領域吸取的經驗教訓的實施會更容易。
- 業(yè)務參與——從一開始就包括業(yè)務代表。價值創(chuàng)造取決于它們的采用和消費，這就是為什么確保將相關要求納入數(shù)據(jù)資產和數(shù)據(jù)結構中至關重要，包括需要什么數(shù)據(jù)以及如何訪問數(shù)據(jù)。
- 效益整合——擁有強大成功案例的組織通常能夠將歷史數(shù)據(jù)治理職責與更具前瞻性的數(shù)據(jù)科學相關用例結合起來，清楚地闡明強大的數(shù)據(jù)基礎將如何為整個企業(yè)的利益相關者服務。如果數(shù)據(jù)管理，投資回報更有說服力。通過設計推動法規(guī)遵從性以及以業(yè)務為導向、洞察力驅動的用例。
- 云優(yōu)先——堅持云原生設計可以防止供應商壁壘，并允許進行無風險、無缺失的實驗，避免高額前期投資，并能夠“快速修復”，在出現(xiàn)問題時進行擴展成功。
名稱欄目：如何設計創(chuàng)新互聯(lián)數(shù)據(jù)治理方案
轉載來于：http://www.5511xx.com/article/ccceipe.html
