<thead id="htxjv"><meter id="htxjv"><del id="htxjv"></del></meter></thead>
      <thead id="htxjv"></thead>
      <thead id="htxjv"></thead>

        <dfn id="htxjv"></dfn>

        <thead id="htxjv"><dfn id="htxjv"></dfn></thead>
        <meter id="htxjv"><thead id="htxjv"><del id="htxjv"></del></thead></meter>

        <mark id="htxjv"></mark>
        <th id="htxjv"></th>

        <thead id="htxjv"><menuitem id="htxjv"><ol id="htxjv"></ol></menuitem></thead>
        北京物流信息聯盟

        大數據治理統一流程模型概述和明確元數據管理策略

        IT微課堂 2021-10-04 10:31:26

        大數據治理概述


        ????????(狹義)大數據是指無法使用傳統流程或工具在合理的時間和成本內處理或分析的信息,這些信息將用來幫助企業更智慧地經營和決策。而廣義的大數據更是指企業需要處理的海量數據,包括傳統數據以及狹義的大數據。(廣義)大數據可以分為五個類型:Web 和社交媒體數據、機器對機器(M2M)數據、海量交易數據、生物計量學數據和人工生成的數據。


        • Web 和社交媒體數據:比如各種微博、博客、社交網站、購物網站中的數據和內容。


        • M2M 數據:也就是機器對機器的數據,比如 RFID 數據、GPS 數據、智能儀表、監控記錄數據以及其他各種傳感器、監控器的數據。


        • 海量交易數據:是各種海量的交易記錄以及交易相關的半結構化和非結構化數據,比如電信行業的 CDR、3G 上網記錄等,金融行業的網上交易記錄、core banking 記錄、理財記錄等,保險行業的各種理賠等。


        • 生物計量學數據:是指和人體識別相關的生物識別信息,如指紋、DNA、虹膜、視網膜、人臉、聲音模式、筆跡等。


        • 人工生成的數據:比如各種調查問卷、電子郵件、紙質文件、掃描件、錄音和電子病歷等。


        ? ? ? 在各行各業中,隨處可見因數量、速度、種類和準確性結合帶來的大數據問題,為了更好地利用大數據,大數據治理逐漸提上日程。在傳統系統中,數據需要先存儲到關系型數據庫/數據倉庫后再進行各種查詢和分析,這些數據我們稱之為靜態數據。而在大數據時代,除了靜態數據以外,還有很多數據對實時性要求非常高,需要在采集數據時就進行相應的處理,處理結果存入到關系型數據庫/數據倉庫、MPP 數據庫、hadoop 平臺、各種 NoSQL 數據庫等,這些數據我們稱之為動態數據。比如高鐵機車的關鍵零部件上裝有成百上千的傳感器,每時每刻都在生成設備狀態信息,企業需要實時收集這些數據并進行分析,當發現設備可能出現問題時及時告警。再比如在電信行業,基于用戶通信行為的精準營銷、位置營銷等,都會實時的采集用戶數據并根據業務模型進行相應的營銷活動。


        ? ? ? 大數據治理的核心是為業務提供持續的、可度量的價值。大數據治理人員需要定期與企業高層管理人員進行溝通,保證大數據治理計劃可以持續獲得支持和幫助。相信隨著時間的推移,大數據將成為主流,企業可以從海量的數據中獲得更多的價值,而大數據治理的范圍和嚴格程度也將逐步上升。為了更好地幫助企業進行大數據治理,筆者在 IBM 數據治理統一流程模型基礎上結合在電信、金融、政府等行業進行大數據治理的經驗,整理了大數據治理統一流程參考模型,整個參考模型分為必選步驟和可選步驟兩部分。


        大數據治理統一流程參考模型


        ? ? ? 如圖 1 所示,大數據治理統一流程參考模型必要步驟分為兩個方向:一條子線是在制定元數據管理策略和確立體系結構的基礎上實施全面的元數據管理,另一條子線是在定義業務問題、執行成熟度評估的基礎上定義數據治理路線圖以及定義數值治理相關的度量值。在 11 個必要步驟的基礎上,企業可以在 7 個可選步驟中選擇一個或多個途徑進行特定領域的數據治理,可選步驟為:主數據監管、(狹義)大數據監管、信息單一視圖監管、運營分析監管、預測分析監管、管理安全與隱私以及監管信息生命周期。企業需要定期對大數據治理統一流程進行度量并將結果發送給主管級發起人。


        圖 1. 大數據治理統一流程參考模型



        第一步:明確元數據管理策略


        ? ? ? 在最開始的時候,元數據(Meta Data)是指描述數據的數據,通常由信息結構的描述組成,隨著技術的發展元數據內涵有了非常大的擴展,比如 UML 模型、數據交易規則、用 Java,.NET,C++等編寫的 APIs、業務流程和工作流模型、產品配置描述和調優參數以及各種業務規則、術語和定義等 [1]。在大數據時代,元數據還應該包括對各種新數據類型的描述,如對位置、名字、用戶點擊次數、音頻、視頻、圖片、各種無線感知設備數據和各種監控設備數據等的描述等。元數據通常分為業務元數據、技術元數據和操作元數據等。業務元數據主要包括業務規則、定義、術語、術語表、運算法則和系統使用業務語言等,主要使用者是業務用戶。技術元數據主要用來定義信息供應鏈(Information Supply Chain,ISC)各類組成部分元數據結構,具體包括各個系統表和字段結構、屬性、出處、依賴性等,以及存儲過程、函數、序列等各種對象。操作元數據是指應用程序運行信息,比如其頻率、記錄數以及各個組件的分析和其它統計信息等。


        ? ? ? 從整個企業層面來說,各種工具軟件和應用程序越來越復雜,相互依存度逐年增加,相應的追蹤整個信息供應鏈各組件之間數據流動、了解數據元素含義和上下文的需求越來越強烈。在從應用議程往信息議程的轉變過程中,元數據管理也逐漸從局部存儲和管理轉向共享。從總量上來看,整個企業的元數據越來越多,光現有的數據模型中就包含了成千上萬的表,同時還有更多的模型等著上線,同時隨著大數據時代的來臨,企業需要處理的數據類型越來越多。為了企業更高效地運轉,企業需要明確元數據管理策略和元數據集成體系結構,依托成熟的方法論和工具實現元數據管理,并有步驟的提升其元數據管理成熟度。


        ? ? ? 為了實現大數據治理,構建智慧的分析洞察,企業需要實現貫穿整個企業的元數據集成,建立完整且一致的元數據管理策略,該策略不僅僅針對某個數據倉庫項目、業務分析項目、某個大數據項目或某個應用單獨制定一個管理策略,而是針對整個企業構建完整的管理策略。元數據管理策略也不是技術標準或某個軟件工具可以取代的,無論軟件工具功能多強大都不能完全替代一個完整一致的元數據管理策略,反而在定義元數據集成體系結構以及選購元數據管理工具之前需要定義元數據管理策略。


        ? ? ? 元數據管理策略需要明確企業元數據管理的愿景、目標、需求、約束和策略等,依據企業自身當前以及未來的需要確定要實現的元數據管理成熟度以及實現目標成熟度的路線圖,完成基礎本體、領域本體、任務本體和應用本體的構建,確定元數據管理的安全策略、版本控制、元數據訂閱推送等。企業需要對業務術語、技術術語中的敏感數據進行標記和分類,制定相應的數據隱私保護政策,確保企業在隱私保護方面符合當地隱私方面的法律法規,如果企業有跨國數據交換、元數據交換的需求,也要遵循涉及國家的法律法規要求。企業需要保證每個元數據元素在信息供應鏈中每個組件中語義上保持一致,也就是語義等效(semantic equivalence)。語義等效可以強也可以弱,在一個元數據集成方案中,語義等效(平均)越強則整個方案的效率越高。語義等效的強弱程度直接影響元數據的共享和重用。


        本體(人工智能和計算機科學)


        ? ? ? 本體(Ontology)源自哲學本體論,而哲學本體論則是源自哲學中“形而上學”分支。本體有時也被翻譯成本體論,在人工智能和計算機科學領域本體最早源于上世紀 70 年代中期,隨著人工智能的發展人們發現知識的獲取是構建強大人工智能系統的關鍵,于是開始將新的本體創建為計算機模型從而實現特定類型的自動化推理。之后到了上世紀 80 年代,人工智能領域開始使用本體表示模型化時間的一種理論以及知識系統的一種組件,認為本體(人工智能)是一種應用哲學。


        ? ? ? 最早的本體(人工智能和計算機科學)定義是 Neches 等人在 1991 給出的:“一個本體定義了組成主題領域的詞匯的基本術語和關系,以及用于組合術語和關系以及定義詞匯外延的規則”。而第一次被業界廣泛接受的本體定義出自 Tom Gruber,其在 1993 年提出:“本體是概念化的顯式的表示(規格說明)”。Borst 在 1997 年對 Tom Gruber 的本體定義做了進一步的擴展,認為:“本體是共享的、概念化的一個形式的規范說明”。在前人的基礎上,Studer 在 1998 年進一步擴展了本體的定義,這也是今天被廣泛接受的一個定義:“本體是共享概念模型的明確形式化規范說明”。本體提供一個共享詞匯表,可以用來對一個領域建模,具體包括那些存在的對象或概念的類型、以及他們的屬性和關系 [2]。一個簡單的本體示例發票概念及其相互關系所構成的語義網絡如圖 2 所示:


        圖 2. 簡單本體(發票)示例



        ? ? ? 隨著時間的推移和技術的發展,本體從最開始的人工智能領域逐漸擴展到圖書館學、情報學、軟件工程、信息架構、生物醫學和信息學等越來越多的學科。與哲學本體論類似,本體(人工智能和計算機科學)依賴某種類別體系來表達實體、概念、事件及其屬性和關系。本體的核心是知識共享和重用,通過減少特定領域內概念或術語上的分歧,使不同的用戶之間可以順暢的溝通和交流并保持語義等效性,同時讓不同的工具軟件和應用系統之間實現互操作。


        ? ? ? 根據研究層次可以將本體的種類劃分為“頂級本體”(top-level ontology)、應用本體(application ontology)、領域本體(domain ontology)和任務本體(task ontology),各個種類之間的層次關系如圖 3 所示。


        圖 3. 本體層次關系



        ????????頂級本體,也被稱為上層本體(upper ontolog)或基礎本體(foundation ontology),是指獨立于具體的問題或領域,在所有領域都適用的共同對象或概念所構成的模型,主要用來描述高級別且通用的概念以及概念之間的關系。

        領域本體是指對某個特定的領域建模,顯式的實現對領域的定義,確定該領域內共同認可的詞匯、詞匯業務含義和對應的信息資產等,提供對該領域知識的共同理解。領域本體所表達的是適合自己領域的術語的特定含義,缺乏兼容性,因而在其他領域往往不適用。在同一領域內,由于文化背景、語言差異、受教育程度或意識形態的差異,也可能會出現不同的本體。很多時候,隨著依賴領域本體系統的擴展,需要將不同的領域本體合并為更通用的規范說明,對并非基于同一頂級本體所構建的本體進行合并是一項非常具有挑戰的任務,很多時候需要靠手工來完成,相反,對那些基于同一頂級本體構建的領域本體可以實現自動化的合并。


        • 任務本體:是針對任務元素及其之間關系的規范說明或詳細說明,用來解釋任務存在的條件以及可以被用在哪些領域或環境中。是一個通用術語的集合用來描述關于任務的定義和概念等。


        • 應用本體: 描述依賴于特定領域和任務的概念及概念之間的關系,是用于特定應用或用途的本體,其范疇可以通過可測試的用例來指定。


        ????????從詳細程度上來分,本體又可以分為參考本體(reference ontologies)和共享本體(share ontologies),參考本體的詳細程度高,而共享本體的詳細程度低。


        本體(哲學)


        ? ? ? 哲學中的本體(ontology)也被稱為存在論,源自哲學中“形而上學”分支,主要探討存在的本質,也就是存在的存在。英文 ontology 實際上就是來源于希臘文“ον”(存在)和“λ?γο?” (學科)的組合。本體是由早期希臘哲學在公元前 6 世紀到公元前 4 世紀提出的“始基”延伸出來的。始基(Principle,又稱本原)最早由泰勒斯(米利都學派)最早提出來,認為萬物由水而生,其學生阿那克西曼德認為萬物由一種簡單的原質組成,該原質不是水 [3]。而畢達哥拉斯(學派)認為“萬物都是數”,數不僅被看作萬物的本原,而且被看作萬物的原型、世界的本體。后來巴門尼德(愛利亞學派)提出了“存在”的概念,認為存在才是唯一真正存在的真理,其創造了一種形而上學論證方式,之后的哲學一直到近時期為止,都從巴門尼德處接受了其“實體的不可毀滅性”。蘇格拉底繼承了巴門尼德的存在概念,主張“真正的善”并完善了巴門尼德弟子芝諾的辯證法,其學生柏拉圖提出了“理念論”,認為只要若干個個體擁有一個共同的名字,它們就有一個共同的理念或形式。亞里士多德(柏拉圖學生)總結了先哲們的思想,完成了《形而上學》,并將本體總結為:對世界上客觀存在事物的系統的描述,即存在論,也就是最形而上學的知識。形而上學不是指孤立、靜止之類的意思,而是指超越具體形態的抽象意思,是關于物質世界最普遍的、最一般的、最不具體的規律的學問。


        第二步:元數據集成體系結構


        ? ? ? 在明確了元數據管理策略后需要確定實現該管理策略所需的技術體系結構,即元數據集成體系結構。各個企業的元數據管理策略和元數據管理成熟度差別較大,因此元數據集成體系結構也多種多樣。大體上元數據集成體系結構可以分為點對點的元數據集成體系結構、中央輻射式元數據體系結構、基于 CWM(Common Warehouse MetaModel,公共倉庫元模型)模型驅動的點對點元數據集成體系結構、基于 CWM 模型驅動的中央存儲庫元數據集成體系結構、分布式(聯邦式)元數據集成體系結構和層次/星型元數據集成體系結構等。


        ? ? ? 針對信息供應鏈中不同的組件,為了實現跨組件的元數據交換和集成,最開始人們采用點對點的方式進行,也就是每一對組件之間通過一個獨立的元數據橋(metadata bridge)進行元數據交換,橋一般是雙向的能夠理解兩個方向的元數據映射 [4]。點對點的元數據集成體系結構幫助用戶實現了跨企業的元數據集成和元數據交換,對提升信息化水平提供了巨大幫助。這種體系結構在應用過程中,也暴露了很多問題,比如元數據橋的構建工作量和耗時都非常大,對中間件廠商、應用廠商、集成商和用戶來說都是一個巨大的挑戰,而且構建元數據橋還必須具有所有者的元數據模型和接口的詳細信息。構建完成的橋很多時候無法在構建其他元數據橋時進行重用,因此開發和維護費用大幅度增加,用戶投資回報率(ROI)不高。以動態數據倉庫為例,其點對點的元數據集成體系結構具體如圖 4 所示,信息供應鏈各組件之間的空心箭頭表示全部的數據流,實心箭頭表示不同的元數據橋和與之關聯的元數據流。


        圖 4. 點對點的元數據集成體系結構



        ? ? ? 通過使用中央元數據存儲庫(central metadata repository)取代各個工具軟件和應用程序之間的點對點連接方式,改成中央元數據存儲庫與各個工具軟件和應用程序實現元數據交換的訪問層(也是一種橋),可以有效降低總成本,減少建立點對點元數據橋的工作,提高投資回報率。信息供應鏈各組件可以從存儲庫訪問元數據,不必與其他產品進行點對點交互。這種使用中央元數據存儲庫方式進行元數據集成的方式就是中央輻射式元數據體系結構(hub-and-spoke meta data architecture),具體如圖 5 所示。由于特定的元數據存儲庫是圍繞其自身的元模型、接口和交付服務建立的,所以仍需要建立元數據橋實現與 ISC 各組件的互相訪問。


        圖 5. 中央輻射式元數據體系結構



        ? ? ? 采用模型驅動的元數據集成方法(比如使用 CWM)可以有效降低元數據集成的成本和復雜度,無論點對點元數據集成體系結構還是中央輻射式元數據集成體系結構都可以因此受益。在點對點體系結構中,通過使用基于模型的方法可以不必在每一對需要集成的產品之間構建元數據橋,每個產品只需要提供一個適配器(adapter)即可實現各個產品之間的元數據交換,適配器既了解公共的元模型也了解本產品元模型的內部實現。如圖 6 所示,基于 CWM 模型驅動點對點元數據集成體系結構使用通用元模型,不再需要在各個產品間建立元數據橋,在各個產品之間通過適配器實現了語義等價性。


        圖 6. 基于 CWM 模型驅動的點對點元數據集成體系結構


        ? ? ? 如圖 7 所示,在基于模型驅動(比如 CWM)的中央輻射式元數據體系結構中,中央存儲庫包含公共元模型和整個領域(domain)用到的該元模型的各個實例(模型)、存儲庫自身元模型及其實例、理解元模型(公共元模型和自身元模型)的適配器層,當然存儲庫也可以直接實現公共元模型的某些內部表示。


        圖 7. 基于 CWM 模型驅動的中央存儲庫元數據集成體系結構



        ? ? ? 如圖 8 所示,這種體系架構是基于 CWM 模型驅動的中央存儲庫元數據集成體系結構的一個變種,兩個中央輻射式的拓撲結構通過各自的元數據存儲庫連接起來,也被稱為分布式(Distributed)或聯邦(Federated)體系結構。兩個元數據存儲庫之間通過元數據橋連接,兩個存儲庫使用相同的元模型和接口,也可以使用不同的元模型和接口。建立分布式元數據集成體系結構的原因有很多種,比如企業基于多個區域單獨部署自己的應用,每個區域有自己的數據中心。


        圖 8. 分布式(聯邦式)元數據集成體系結構



        ? ? ? 如圖 9 所示,這種體系結構是分布式體系結構的變體,根存儲庫實現了元模型的公共部分(橫跨整個企業),葉子存儲庫實現了一個或多個特定的公共元模型子集,并只保存這些自己所對應的元數據實例。特定客戶可以主要訪問其感興趣的元數據所在的葉子存儲庫,也可以訪問其它葉子存儲庫和根存儲庫。這種體系結構被稱為層次或星型拓撲結構。


        圖 9. 層次或星型元數據集成體系結構



        結束語


        ? ? ? 本文詳細介紹了大數據治理的基本概念和統一流程參考模型,并闡述了該模型的第一步“明確元數據管理策略”和第二步“元數據集成體系結構”等內容。在第一步 “明確元數據管理策略”中講述了元數據的基本概念以及本體在人工智能/計算機科學和哲學中的含義。在第二步“元數據集成體系結構”講述了元數據集成體系結構的六種示例,分別為:點對點的元數據集成體系結構、中央輻射式元數據體系結構、基于 CWM 模型驅動的點對點元數據集成體系結構、基于 CWM 模型驅動的中央存儲庫元數據集成體系結構、分布式(聯邦式)元數據集成體系結構和層次/星型元數據集成體系結構。在本系列文章的下一部分將繼續介紹大數據治理統一流程參考模型第二步“元數據集成體系結構”,具體包括元模型、元-元模型、公共倉庫元模型(CWM)、CWM 發展史、OMG 的模型驅動體系結構(Model Driven Architecture,MDA)。


        參考文獻


        David Frankel Consulting,”Using Model Driven Architecture? to Manage Metadata”,P3;

        Fredrik Arvidsson and Annika Flycht-Eriksson,2008,Ontologies I,”An ontology provide a shared vocabulary,which can be used to model a domain,thatis,the type of objects and/or concepts thatexist,and their properties and relations”;

        更多內容請參考: [專著] /(英)伯特蘭. 羅素/著 孫紹武/主編 <<西方哲學史 >>;

        John Poole,Dan Chang,Douglas Tolbert and David Mellor,2002,Common Warehouse Metamodel,p18-32,p180-202;

        本系列文章參考了 Sunil Soares 編寫的《The IBM Data Governance Unified Process》和《Bigdata Governance》書中內容。

        IT微課堂

        專注企業信息化解決方案

        長按二維碼關注