大數據治理系列

大數據治理——為業(yè)務提供持續(xù)的、可度量的價值目錄TOC\o"1-2"\h\z\u大數據治理——為業(yè)務提供持續(xù)的、可度量的價值1概述1大數據治理系列1第一局部：大數據治理統(tǒng)一流程模型概述和明確元數據管理策略2第二局部：元數據集成體系結構14第三局部：實施元數據管理24第四局部：大數據治理統(tǒng)一流程參考模型的第四步到第九步36第五局部：定義度量值和主數據監(jiān)管52第六局部：大數據監(jiān)管和信息單一視圖監(jiān)管66第七局部：分析監(jiān)管、平安與隱私管理和信息生命周期監(jiān)管79概述面對我們身邊每時每刻迅速增長的龐大數據，因為其數量大、速度快、種類多和準確性的特征，如何更好地利用大數據創(chuàng)造出有意義的價值，一直是我們探索的重要話題。而在這之前，就需要用科學正確的方法策略對大數據進行治理。大數據治理是指制定與大數據有關的數據優(yōu)化、隱私保護與數據變現的政策，是傳統(tǒng)信息治理的延續(xù)和擴展，也是大數據分析的根底，還是連接大數據科學和應用的橋梁，因此大數據治理是大數據再創(chuàng)頂峰的“必修課〞。下面我們將與您分享新鮮出爐的大數據治理方案。大數據治理系列本系列共分為七個局部，圍繞大數據治理統(tǒng)一流程參考模型，并結合實際業(yè)務問題和IBM相應的產品解決方案展開表達。第一局部：大數據治理統(tǒng)一流程模型概述和明確元數據管理策略為了更好地幫助企業(yè)進行大數據治理，筆者在IBM數據治理統(tǒng)一流程模型根底上結合在電信、金融、政府等行業(yè)進行大數據治理的經驗，整理出了大數據治理統(tǒng)一流程參考模型。本文主要介紹了大數據治理的根本概念，以及結合圖文并茂的方式講解了大數據治理統(tǒng)一流程參考模型的前兩步：“明確元數據管理策略〞和“元數據集成體系結構〞內容。大數據治理概述〔狹義〕大數據是指無法使用傳統(tǒng)流程或工具在合理的時間和本錢內處理或分析的信息，這些信息將用來幫助企業(yè)更智慧地經營和決策。而廣義的大數據更是指企業(yè)需要處理的海量數據，包括傳統(tǒng)數據以及狹義的大數據?！矎V義〕大數據可以分為五個類型：Web和社交媒體數據、機器對機器〔M2M〕數據、海量交易數據、生物計量學數據和人工生成的數據。Web和社交媒體數據：比方各種微博、博客、社交網站、購物網站中的數據和內容。M2M數據：也就是機器對機器的數據，比方RFID數據、GPS數據、智能儀表、監(jiān)控記錄數據以及其他各種傳感器、監(jiān)控器的數據。海量交易數據：是各種海量的交易記錄以及交易相關的半結構化和非結構化數據，比方電信行業(yè)的CDR、3G上網記錄等，金融行業(yè)的網上交易記錄、corebanking記錄、理財記錄等，保險行業(yè)的各種理賠等。生物計量學數據：是指和人體識別相關的生物識別信息，如指紋、DNA、虹膜、視網膜、人臉、聲音模式、筆跡等。人工生成的數據：比方各種調查問卷、電子郵件、紙質文件、掃描件、錄音和電子病歷等。在各行各業(yè)中，隨處可見因數量、速度、種類和準確性結合帶來的大數據問題，為了更好地利用大數據，大數據治理逐漸提上日程。在傳統(tǒng)系統(tǒng)中，數據需要先存儲到關系型數據庫/數據倉庫后再進行各種查詢和分析，這些數據我們稱之為靜態(tài)數據。而在大數據時代，除了靜態(tài)數據以外，還有很多數據對實時性要求非常高，需要在采集數據時就進行相應的處理，處理結果存入到關系型數據庫/數據倉庫、MPP數據庫、Hadoop平臺、各種NoSQL數據庫等，這些數據我們稱之為動態(tài)數據。比方高鐵機車的關鍵零部件上裝有成百上千的傳感器，每時每刻都在生成設備狀態(tài)信息，企業(yè)需要實時收集這些數據并進行分析，當發(fā)現設備可能出現問題時及時告警。再比方在電信行業(yè)，基于用戶通信行為的精準營銷、位置營銷等，都會實時的采集用戶數據并根據業(yè)務模型進行相應的營銷活動。大數據治理的核心是為業(yè)務提供持續(xù)的、可度量的價值。大數據治理人員需要定期與企業(yè)高層管理人員進行溝通，保證大數據治理方案可以持續(xù)獲得支持和幫助。相信隨著時間的推移，大數據將成為主流，企業(yè)可以從海量的數據中獲得更多的價值，而大數據治理的范圍和嚴格程度也將逐步上升。為了更好地幫助企業(yè)進行大數據治理，筆者在IBM數據治理統(tǒng)一流程模型根底上結合在電信、金融、政府等行業(yè)進行大數據治理的經驗，整理了大數據治理統(tǒng)一流程參考模型，整個參考模型分為必選步驟和可選步驟兩局部。大數據治理統(tǒng)一流程參考模型如圖1所示，大數據治理統(tǒng)一流程參考模型必要步驟分為兩個方向：一條子線是在制定元數據管理策略和確立體系結構的根底上實施全面的元數據管理，另一條子線是在定義業(yè)務問題、執(zhí)行成熟度評估的根底上定義數據治理路線圖以及定義數值治理相關的度量值。在11個必要步驟的根底上，企業(yè)可以在7個可選步驟中選擇一個或多個途徑進行特定領域的數據治理，可選步驟為：主數據監(jiān)管、〔狹義〕大數據監(jiān)管、信息單一視圖監(jiān)管、運營分析監(jiān)管、預測分析監(jiān)管、管理平安與隱私以及監(jiān)管信息生命周期。企業(yè)需要定期對大數據治理統(tǒng)一流程進行度量并將結果發(fā)送給主管級發(fā)起人。圖1大數據治理統(tǒng)一流程參考模型第一步：明確元數據管理策略在最開始的時候，元數據〔MetaData〕是指描述數據的數據，通常由信息結構的描述組成，隨著技術的開展元數據內涵有了非常大的擴展，比方UML模型、數據交易規(guī)那么、用Java，.NET，C++等編寫的APIs、業(yè)務流程和工作流模型、產品配置描述和調優(yōu)參數以及各種業(yè)務規(guī)那么、術語和定義等[1]。在大數據時代，元數據還應該包括對各種新數據類型的描述，如對位置、名字、用戶點擊次數、音頻、視頻、圖片、各種無線感知設備數據和各種監(jiān)控設備數據等的描述等。元數據通常分為業(yè)務元數據、技術元數據和操作元數據等。業(yè)務元數據主要包括業(yè)務規(guī)那么、定義、術語、術語表、運算法那么和系統(tǒng)使用業(yè)務語言等，主要使用者是業(yè)務用戶。技術元數據主要用來定義信息供給鏈〔InformationSupplyChain，ISC〕各類組成局部元數據結構，具體包括各個系統(tǒng)表和字段結構、屬性、出處、依賴性等，以及存儲過程、函數、序列等各種對象。操作元數據是指應用程序運行信息，比方其頻率、記錄數以及各個組件的分析和其它統(tǒng)計信息等。從整個企業(yè)層面來說，各種工具軟件和應用程序越來越復雜，相互依存度逐年增加，相應的追蹤整個信息供給鏈各組件之間數據流動、了解數據元素含義和上下文的需求越來越強烈。在從應用議程往信息議程的轉變過程中，元數據管理也逐漸從局部存儲和管理轉向共享。從總量上來看，整個企業(yè)的元數據越來越多，光現有的數據模型中就包含了成千上萬的表，同時還有更多的模型等著上線，同時隨著大數據時代的來臨，企業(yè)需要處理的數據類型越來越多。為了企業(yè)更高效地運轉，企業(yè)需要明確元數據管理策略和元數據集成體系結構，依托成熟的方法論和工具實現元數據管理，并有步驟的提升其元數據管理成熟度。為了實現大數據治理，構建智慧的分析洞察，企業(yè)需要實現貫穿整個企業(yè)的元數據集成，建立完整且一致的元數據管理策略，該策略不僅僅針對某個數據倉庫工程、業(yè)務分析工程、某個大數據工程或某個應用單獨制定一個管理策略，而是針對整個企業(yè)構建完整的管理策略。元數據管理策略也不是技術標準或某個軟件工具可以取代的，無論軟件工具功能多強大都不能完全替代一個完整一致的元數據管理策略，反而在定義元數據集成體系結構以及選購元數據管理工具之前需要定義元數據管理策略。元數據管理策略需要明確企業(yè)元數據管理的愿景、目標、需求、約束和策略等，依據企業(yè)自身當前以及未來的需要確定要實現的元數據管理成熟度以及實現目標成熟度的路線圖，完成根底本體、領域本體、任務本體和應用本體的構建，確定元數據管理的平安策略、版本控制、元數據訂閱推送等。企業(yè)需要對業(yè)務術語、技術術語中的敏感數據進行標記和分類，制定相應的數據隱私保護政策，確保企業(yè)在隱私保護方面符合當地隱私方面的法律法規(guī)，如果企業(yè)有跨國數據交換、元數據交換的需求，也要遵循涉及國家的法律法規(guī)要求。企業(yè)需要保證每個元數據元素在信息供給鏈中每個組件中語義上保持一致，也就是語義等效〔semanticequivalence〕。語義等效可以強也可以弱，在一個元數據集成方案中，語義等效〔平均〕越強那么整個方案的效率越高。語義等效的強弱程度直接影響元數據的共享和重用。本體〔人工智能和計算機科學〕本體〔Ontology〕源自哲學本體論，而哲學本體論那么是源自哲學中“形而上學〞分支。本體有時也被翻譯本錢體論，在人工智能和計算機科學領域本體最早源于上世紀70年代中期，隨著人工智能的開展人們發(fā)現知識的獲取是構建強大人工智能系統(tǒng)的關鍵，于是開始將新的本體創(chuàng)立為計算機模型從而實現特定類型的自動化推理。之后到了上世紀80年代，人工智能領域開始使用本體表示模型化時間的一種理論以及知識系統(tǒng)的一種組件，認為本體〔人工智能〕是一種應用哲學。最早的本體〔人工智能和計算機科學〕定義是Neches等人在1991給出的：“一個本體定義了組成主題領域的詞匯的根本術語和關系，以及用于組合術語和關系以及定義詞匯外延的規(guī)那么〞。而第一次被業(yè)界廣泛接受的本體定義出自TomGruber，其在1993年提出：“本體是概念化的顯式的表示〔規(guī)格說明〕〞。Borst在1997年對TomGruber的本體定義做了進一步的擴展，認為：“本體是共享的、概念化的一個形式的標準說明〞。在前人的根底上，Stude在1998年進一步擴展了本體的定義，這也是今天被廣泛接受的一個定義：“本體是共享概念模型的明確形式化標準說明〞。本體提供一個共享詞匯表，可以用來對一個領域建模，具體包括那些存在的對象或概念的類型、以及他們的屬性和關系[2]。一個簡單的本體例如發(fā)票概念及其相互關系所構成的語義網絡如圖2所示：圖2簡單本體〔發(fā)票〕例如隨著時間的推移和技術的開展，本體從最開始的人工智能領域逐漸擴展到圖書館學、情報學、軟件工程、信息架構、生物醫(yī)學和信息學等越來越多的學科。與哲學本體論類似，本體〔人工智能和計算機科學〕依賴某種類別體系來表達實體、概念、事件及其屬性和關系。本體的核心是知識共享和重用，通過減少特定領域內概念或術語上的分歧，使不同的用戶之間可以順暢的溝通和交流并保持語義等效性，同時讓不同的工具軟件和應用系統(tǒng)之間實現互操作。根據研究層次可以將本體的種類劃分為“頂級本體〞〔top-levelontology〕、應用本體〔applicationontology〕、領域本體〔domainontology〕和任務本體〔taskontology〕，各個種類之間的層次關系如圖3所示。圖3本體層次關系頂級本體，也被稱為上層本體〔upperontology〕或根底本體〔foundationontology〕，是指獨立于具體的問題或領域，在所有領域都適用的共同對象或概念所構成的模型，主要用來描述高級別且通用的概念以及概念之間的關系。領域本體是指對某個特定的領域建模，顯式的實現對領域的定義，確定該領域內共同認可的詞匯、詞匯業(yè)務含義和對應的信息資產等，提供對該領域知識的共同理解。領域本體所表達的是適合自己領域的術語的特定含義，缺乏兼容性，因而在其他領域往往不適用。在同一領域內，由于文化背景、語言差異、受教育程度或意識形態(tài)的差異，也可能會出現不同的本體。很多時候，隨著依賴領域本體系統(tǒng)的擴展，需要將不同的領域本體合并為更通用的標準說明，對并非基于同一頂級本體所構建的本體進行合并是一項非常具有挑戰(zhàn)的任務，很多時候需要靠手工來完成，相反，對那些基于同一頂級本體構建的領域本體可以實現自動化的合并。任務本體是針對任務元素及其之間關系的標準說明或詳細說明，用來解釋任務存在的條件以及可以被用在哪些領域或環(huán)境中。是一個通用術語的集合用來描述關于任務的定義和概念等。應用本體：描述依賴于特定領域和任務的概念及概念之間的關系，是用于特定應用或用途的本體，其范疇可以通過可測試的用例來指定。從詳細程度上來分，本體又可以分為參考本體〔referenceontologies〕和共享本體〔shareontologies〕，參考本體的詳細程度高，而共享本體的詳細程度低。本體〔哲學〕哲學中的本體〔ontology〕也被稱為存在論，源自哲學中“形而上學〞分支，主要探討存在的本質，也就是存在的存在。英文ontology實際上就是來源于希臘文“ον〞〔存在〕和“λ?γο?〞〔學科〕的組合。本體是由早期希臘哲學在公元前6世紀到公元前4世紀提出的“始基〞延伸出來的。始基〔Principle，又稱本原〕最早由泰勒斯〔米利都學派〕最早提出來，認為萬物由水而生，其學生阿那克西曼德認為萬物由一種簡單的原質組成，該原質不是水[3]。而畢達哥拉斯〔學派〕認為“萬物都是數〞，數不僅被看作萬物的本原，而且被看作萬物的原型、世界的本體。后來巴門尼德〔愛利亞學派〕提出了“存在〞的概念，認為存在才是唯一真正存在的真理，其創(chuàng)造了一種形而上學論證方式，之后的哲學一直到近時期為止，都從巴門尼德處接受了其“實體的不可消滅性〞。蘇格拉底繼承了巴門尼德的存在概念，主張“真正的善〞并完善了巴門尼德弟子芝諾的辯證法，其學生柏拉圖提出了“理念論〞，認為只要假設干個個體擁有一個共同的名字，它們就有一個共同的理念或形式。亞里士多德〔柏拉圖學生〕總結了先哲們的思想，完成了《形而上學》，并將本體總結為：對世界上客觀存在事物的系統(tǒng)的描述，即存在論，也就是最形而上學的知識。形而上學不是指孤立、靜止之類的意思，而是指超越具體形態(tài)的抽象意思，是關于物質世界最普遍的、最一般的、最不具體的規(guī)律的學問。第二步：元數據集成體系結構在明確了元數據管理策略后需要確定實現該管理策略所需的技術體系結構，即元數據集成體系結構。各個企業(yè)的元數據管理策略和元數據管理成熟度差異較大，因此元數據集成體系結構也多種多樣。大體上元數據集成體系結構可以分為點對點的元數據集成體系結構、中央輻射式元數據體系結構、基于CWM〔CommonWarehouseMetaModel，公共倉庫元模型〕模型驅動的點對點元數據集成體系結構、基于CWM模型驅動的中央存儲庫元數據集成體系結構、分布式〔聯邦式〕元數據集成體系結構和層次/星型元數據集成體系結構等。針對信息供給鏈中不同的組件，為了實現跨組件的元數據交換和集成，最開始人們采用點對點的方式進行，也就是每一對組件之間通過一個獨立的元數據橋〔metadatabridge〕進行元數據交換，橋一般是雙向的能夠理解兩個方向的元數據映射[4]。點對點的元數據集成體系結構幫助用戶實現了跨企業(yè)的元數據集成和元數據交換，對提升信息化水平提供了巨大幫助。這種體系結構在應用過程中，也暴露了很多問題，比方元數據橋的構建工作量和耗時都非常大，對中間件廠商、應用廠商、集成商和用戶來說都是一個巨大的挑戰(zhàn)，而且構建元數據橋還必須具有所有者的元數據模型和接口的詳細信息。構建完成的橋很多時候無法在構建其他元數據橋時進行重用，因此開發(fā)和維護費用大幅度增加，用戶投資回報率〔ROI〕不高。以動態(tài)數據倉庫為例，其點對點的元數據集成體系結構具體如圖4所示，信息供給鏈各組件之間的空心箭頭表示全部的數據流，實心箭頭表示不同的元數據橋和與之關聯的元數據流。圖4點對點的元數據集成體系結構通過使用中央元數據存儲庫〔centralmetadatarepository〕取代各個工具軟件和應用程序之間的點對點連接方式，改成中央元數據存儲庫與各個工具軟件和應用程序實現元數據交換的訪問層〔也是一種橋〕，可以有效降低總本錢，減少建立點對點元數據橋的工作，提高投資回報率。信息供給鏈各組件可以從存儲庫訪問元數據，不必與其他產品進行點對點交互。這種使用中央元數據存儲庫方式進行元數據集成的方式就是中央輻射式元數據體系結構〔hub-and-spokemetadataarchitecture〕，具體如圖5所示。由于特定的元數據存儲庫是圍繞其自身的元模型、接口和交付效勞建立的，所以仍需要建立元數據橋實現與ISC各組件的互相訪問。圖5中央輻射式元數據體系結構采用模型驅動的元數據集成方法〔比方使用CWM〕可以有效降低元數據集成的本錢和復雜度，無論點對點元數據集成體系結構還是中央輻射式元數據集成體系結構都可以因此受益。在點對點體系結構中，通過使用基于模型的方法可以不必在每一對需要集成的產品之間構建元數據橋，每個產品只需要提供一個適配器〔adapter〕即可實現各個產品之間的元數據交換，適配器既了解公共的元模型也了解本產品元模型的內部實現。如圖6所示，基于CWM模型驅動點對點元數據集成體系結構使用通用元模型，不再需要在各個產品間建立元數據橋，在各個產品之間通過適配器實現了語義等價性。圖6基于CWM模型驅動的點對點元數據集成體系結構如圖7所示，在基于模型驅動〔比方CWM〕的中央輻射式元數據體系結構中，中央存儲庫包含公共元模型和整個領域〔domain〕用到的該元模型的各個實例〔模型〕、存儲庫自身元模型及其實例、理解元模型〔公共元模型和自身元模型〕的適配器層，當然存儲庫也可以直接實現公共元模型的某些內部表示。圖7基于CWM模型驅動的中央存儲庫元數據集成體系結構如圖8所示，這種體系架構是基于CWM模型驅動的中央存儲庫元數據集成體系結構的一個變種，兩個中央輻射式的拓撲結構通過各自的元數據存儲庫連接起來，也被稱為分布式〔Distributed〕或聯邦〔Federated〕體系結構。兩個元數據存儲庫之間通過元數據橋連接，兩個存儲庫使用相同的元模型和接口，也可以使用不同的元模型和接口。建立分布式元數據集成體系結構的原因有很多種，比方企業(yè)基于多個區(qū)域單獨部署自己的應用，每個區(qū)域有自己的數據中心。圖8分布式〔聯邦式〕元數據集成體系結構如圖9所示，這種體系結構是分布式體系結構的變體，根存儲庫實現了元模型的公共局部〔橫跨整個企業(yè)〕，葉子存儲庫實現了一個或多個特定的公共元模型子集，并只保存這些自己所對應的元數據實例。特定客戶可以主要訪問其感興趣的元數據所在的葉子存儲庫，也可以訪問其它葉子存儲庫和根存儲庫。這種體系結構被稱為層次或星型拓撲結構。圖9層次或星型元數據集成體系結構結束語本文詳細介紹了大數據治理的根本概念和統(tǒng)一流程參考模型，并闡述了該模型的第一步“明確元數據管理策略〞和第二步“元數據集成體系結構〞等內容。在第一步“明確元數據管理策略〞中講述了元數據的根本概念以及本體在人工智能/計算機科學和哲學中的含義。在第二步“元數據集成體系結構〞講述了元數據集成體系結構的六種例如，分別為：點對點的元數據集成體系結構、中央輻射式元數據體系結構、基于CWM模型驅動的點對點元數據集成體系結構、基于CWM模型驅動的中央存儲庫元數據集成體系結構、分布式〔聯邦式〕元數據集成體系結構和層次/星型元數據集成體系結構。在本系列文章的下一局部將繼續(xù)介紹大數據治理統(tǒng)一流程參考模型第二步“元數據集成體系結構〞，具體包括元模型、元-元模型、公共倉庫元模型〔CWM〕、CWM開展史、OMG的模型驅動體系結構〔ModelDrivenArchitecture，MDA〕。參考文獻DavidFrankelConsulting,〞UsingModelDrivenArchitecture?toManageMetadata〞,P3;FredrikArvidssonandAnnikaFlycht-Eriksson,2023,OntologiesI,〞Anontologyprovideasharedvocabulary,whichcanbeusedtomodeladomain,thatis,thetypeofobjectsand/orconceptsthatexist,andtheirpropertiesandrelations〞;更多內容請參考:[專著]/(英)伯特蘭.羅素/著孫紹武/主編<<西方哲學史>>;JohnPoole,DanChang,DouglasTolbertandDavidMellor,2002,CommonWarehouseMetamodel,p18-32,p180-202;本系列文章參考了SunilSoares編寫的《TheIBMDataGovernanceUnifiedProcess》和《BigdataGovernance》書中內容?第二局部：元數據集成體系結構在明確了元數據管理策略后需要確定實現該管理策略所需的技術體系結構，即元數據集成體系結構。元數據集成體系結構涉及到多個概念，如元模型、元-元模型、公共倉庫元模型〔CWM〕等，本局部將繼續(xù)介紹大數據治理統(tǒng)一流程參考模型第二步“元數據集成體系結構〞的相關內容。在本系列的第一篇文章中，我們主要介紹了大數據治理的根本概念和統(tǒng)一流程參考模型，并闡述了該模型的第一步“明確元數據管理策略〞和第二步“元數據集成體系結構〞的六種例如等內容。大數據治理統(tǒng)一流程參考模型的第二步是“元數據集成體系結構〞，具體包括元模型、元-元模型、公共倉庫元模型〔CWM〕、CWM開展史、OMG的模型驅動體系結構〔ModelDrivenArchitecture，MDA〕本文將對元數據集成體系結構包含的各種模型展開表達。大數據治理統(tǒng)一流程參考模型，第二步：元數據集成體系結構元模型〔Metamodel〕模型〔Model〕是用來描述特定的系統(tǒng)、過程、事物或概念的準確而抽象的表示。例如軟件架構師可以用概要設計的形式建立一個應用系統(tǒng)的模型。本質上來說，元數據是數據的形式化模型，是數據的抽象描述，該描述準確地描述了數據。元模型〔Metamodel〕也就是模型的模型〔或者元-元數據〕，是用來描述元數據的模型。下面基于關系型表實體-關系〔ER〕模型舉例說明什么是元模型。如圖1所示，一個簡單的關系型表元模型描述了如何定義一個關系型表，規(guī)定了每個表必須有一個名字〔字符串〕，一個表可以有1到多個列，每個列必須有一個名字〔字符串〕和數據類型〔字符串〕：圖1簡單關系型表元模型如果要創(chuàng)立一個關系型表模型，基于該表元模型創(chuàng)立一個實例即可，比方創(chuàng)立一個常見的雇員表Employees表模型，具體如圖2所示，Employees表包含6個列，分別是編號、姓、名字、部門編號、經理編號和職位編號。圖2Employees表實例比方在DB2中創(chuàng)立employees表，可以很容易的從employees表模型中得到相應的DDL語句，執(zhí)行DDL語句時DB2會生成描述employees表的內部元數據并存儲在目錄〔DB2內部的元數據存儲庫〕中。清單1在DB2中創(chuàng)立employees表例如Createtableemployees(Idintegernotnull，First_nameStringnotnull，Last_nameStringnotnull，Depart_IDIntegernotnull，Manager_IDIntegernotnull，Job_IDIntegernotnull)同樣基于圖1簡單關系型表元模型創(chuàng)立另一個實例department表模型。department表包含2個列，分別是編號和部門名稱，具體如圖3所示。由于department表模型和employees表模型都是基于相同的公共元模型，其它工具和應用程序軟件〔了解關系型表的公共元模型〕可以很容易理解department表和employees表，因為它們都是同一個元模型的實例。其它工具或應用程序通過調用導入映射〔importmapping〕將該department表模型或employees表模型翻譯成自己內部的元數據實例。同樣，也可以將該軟件內部元數據翻譯成一個與平臺無關的形式化模型，也就是導出映射〔exportmapping〕，以便其他軟件使用其專有的元數據。這種基于公共元模型的集成方法就是模型驅動的元數據集成體系結構[1]。圖3department表實例元-元模型〔Meta-metamodel〕元-元模型就是元模型的模型，有時也被稱為本體〔ontology〕，是模型驅動的元數據集成體系結構的根底，其定義了描述元模型的語言，規(guī)定元模型必須依照一定的形式化規(guī)那么來建立，以便所有的軟件工具都能夠對其進行理解。元-元模型比元模型具有更高的抽象級別，一個元模型是一個元-元模型的實例，元模型比元-元模型更加精細，而元-元模型比元模型更加抽象。元數據〔模型〕那么是一個元模型的實例，遵守元模型的規(guī)定和約束。用戶對象〔或用戶數據〕那么是元數據〔或者稱為模型〕的實例。元數據層次結構具體如表1所示，共分為4層，最高層L3是元-元模型，之下是L2元模型和L1模型/元數據，最底層是L0用戶對象/用戶數據：表1元數據層次結構元層次名稱例如L3元-元模型元類、元屬性、元操作L2元模型類、屬性、操作、構件L1模型/元數據實體-關系〔ER〕圖L0用戶對象/用戶數據交易數據、ODS數據、數據倉庫數據、數據集市數據、數據中心數據等公共倉庫元模型〔CWM〕概述公共倉庫元模型〔CommonWarehouseMetaModel，CWM〕是被對象管理組織OMG〔ObjectManagementGroup〕采納的數據倉庫和業(yè)務分析領域元數據交換開放式行業(yè)標準，在數據倉庫和業(yè)務分析領域為元數據定義公共的元模型和基于XML的元數據交換〔XMI〕。CWM作為一個標準的接口，可以幫助分布式、異構環(huán)境中的數據倉庫工具，數據倉庫平臺和數據倉庫元數據存儲庫之間輕松實現數據倉庫和業(yè)務分析元數據交換。CWM提供一個框架為數據源、數據目標、轉換、分析、流程和操作等創(chuàng)立和管理元數據，并提供元數據使用的世系信息[2]。CWM是一個基于模型驅動方法的完整地描述數據倉庫和業(yè)務分析領域的元模型，提供構建元數據所需的語法和語義，由假設干個不相同又緊密相關的子元模型組成。CWM模型的目的是最大限度的重用對象模型〔ObjectModel，UML的一個子集〕，并在可能的地方共享通用模型結構。如圖4所示，CWM元模型使用包〔package〕和層次來簡化管理的復雜度并便于理解，共包含21個單獨的包，這些包被分為5個層次。對象模型層包含定義根本元模型的概念、關系和約束的包，其它CWM包都需要用到這些定義，對象模型層的包構成了其它CWM包所需要的根本元模型效勞的全部集合。對象模型層主要包括核心包〔Corepackage〕、行為包〔Behavioralpackage〕、關系包〔Relationshipspackage〕和實例包〔Instancepackage〕。數據源層〔DataResources〕：主要描述CWM元數據交換中既可作為源又可以作為目標的數據源的結構，本層含有的元模型主要描述面向對象的數據庫和應用、關系型數據庫、面向記錄的數據源〔如文件、記錄數據庫管理系統(tǒng)等〕、多維數據庫和XML數據源等。對于面向對象數據源，CWM一般情況下重用根本的對象模型〔位于對象模型層〕，如果該數據源具有對象模型層無法處理的一些特征和功能時，可以通過定義一個擴展包來解決。數據分析層〔DataAnalysis〕：本層含有的元模型主要描述數據轉換、在線分析處理OLAP、數據挖掘、信息可視化和業(yè)務術語等。倉庫管理層〔WarehouseManagement〕：本層含有的元模型主要描述數據倉庫處理和數據倉庫操作。圖4CWM1.1元模型CWM1.1是在2003年3月發(fā)布的，與之相關的OMG組織標準還有MOF、UML和XMI。CWM使用統(tǒng)一建模語言〔UML〕定義公共元數據的模型〔CWM元模型〕，使用可擴展標記語言〔XML〕生成CWM元數據交換標準〔也就是XML元數據交換，XMI〕，使用CORBA接口定義語言〔IDL〕為訪問CWM元數據生成編程語言API的標準〔依賴MOF到IDL的映射〕。UML是一種標準化、可視化、描述明確、結構化和文檔化的定義分布式對象系統(tǒng)的圖形化語言。1996年，業(yè)內三種最杰出的面向對象建模語言：GradyBooch的Booch方法、IvarJacobson的面向對象軟件工程〔OOSE〕和JimRumbaugh的對象建模技術〔OMT〕被統(tǒng)一起來發(fā)布，也就是UML0.9。2023年，發(fā)布。CWM依賴于UML標準的前三個局部，即UML語義、UML符號向導和對象約束語言標準。UML語義定義UML元模型的語義，UML元模型是層次結構并以包為單位進行組織，每個包按照抽象語言〔使用類圖〕、結構良好規(guī)那么〔采用OCL〕和語義〔采用英語〕來定義。UML符號指定表達UML元模型語義的圖形語法〔例如類圖〕。對象約束語言標準定義對象約束語言〔OCL〕的句法、語義和語法，OCL是一種表述約束的形式化語言[3]。構造塊和結構良好規(guī)那么：UML提供了組成構造塊和結構良好規(guī)那么的面向對象建模語言，根本的構造塊包括模型元素〔如類、對象、接口、組件、用例等〕、關系〔如關聯、泛化、依賴等〕和圖〔如類圖、對象圖、用例圖等〕等。UML可以為一個系統(tǒng)進行不同方面的建模，比方結構建?！灿职ㄊ褂妙悎D和對象圖的靜態(tài)結構建模、使用組件圖和部署圖實現建?！场⒂美：托袨榻５?。元數據建模只需要靜態(tài)結構建模，靜態(tài)結構的核心元素是類、對象、屬性和操作。UML用包來將模型元素組織成語義上相關聯的分組，每個包擁有其自己的模型元素，每個模型元素不能同時被多個包擁有。UML在CWM中主要作為三種角色出現[4]：1、UML作為和MOF等價的元-元模型。UML，或者局部對應MOF模型、UML符號和OCL的UML分別被用作建模語言、圖形符號和約束語言，用來定義和表示CWM。2、UML作為根底元模型。對象模型層〔ObjectModel〕與UML關系密切，是UML的一個子集。3、UML用來作為面向對象元模型。元對象框架〔MetaObjectFramework，MOF，本文以版本為例〕是一個以獨立于平臺的方式定義、操作、集成元數據和數據的、可擴展、模型驅動的分布式對象集成框架。此框架支持各種類型的元數據，還可以根據需求添加新類型的元數據。MOF包括MOF模型〔定義建立元模型的建模元素和使用規(guī)那么〕、MOF反射接口〔允許程序在不使用元模型指定接口時對元數據進行各種操作〕和MOF到IDL的映射〔定義MOF模型定義的元模型到CORBAIDL之間的標準映射〕。MOF模型是以UML的概念和結構為根底，尤其是以UML的靜態(tài)結構模型和模型管理為根底。MOF模型沒有定義自己的圖形符號和約束語言，而是采用UML的圖形符號和OCL來實現。MOF模型也是層次結構，并以包為單位進行組織。MOF支持各種類型的元數據，采用四層元數據體系結構〔也就是OMG元數據體系結構〕[5]，具體如表2所示，該體系架構將元數據〔M1〕視同為數據〔M0〕，并對之進行形式化建?！布丛Ｐ停琈2〕。元模型〔M2〕使用元-元模型〔M3〕所提供的元建模結構來表示。表2說明MOF模型〔元-元模型〕、UML元模型、用戶模型和用戶對象/數據之間的關系。表2MOF四層元數據體系結構描述例如M3MOF,i.e.thesetofconstructsusedtodefinemetamodelsMOFClass,MOFAttribute,MOFAssociation,etc.M2Metamodels,consistingof

instancesofMOFconstructs.UMLClass,UMLAssociation,UMLAttribute,UMLState,UMLActivity,etc.CWMTable,CWMColumn,etc.M1Models,consistingofinstances

ofM2metamodelconstructs.Class“Customer〞,Class“Account〞

Table“Employee〞,Table“Vendor〞,etc.M0Objectsanddata,i.e.instancesofM1modelconstructsCustomerJaneSmith,CustomerJoeJones,Account2989,Account2344,EmployeeA3949,Vendor78988,etc.XML元數據交換〔XMI〕是在工具軟件、應用程序之間進行元數據交換的XML語言，整合了UML、MOF和XML三種技術，允許MOF元數據〔即遵從MOF或基于MOF的元模型的元數據〕以流或文件的形式按照XML的標準格式進行交換。XMI是OMG在元數據交換方面的標準之一，同時也是W3C認可的標準。本質上，XMI是W3C的XML和MOF之間，以及XML文檔和MOF元數據之間的一對平行映射。2023年8月，XML發(fā)布了。CWM開展史其實早在上世紀80年代末90年代初，很多企業(yè)就嘗試使用一種元模型實現元數據集成以整合分布于各個業(yè)務豎井中的元數據，但最終失敗了，因為很多的利益相關者各自擁有不同的觀點，且需要不同的模型結構。1997年，OMG將UML采納為標準，為CWM標準制定打下了第一個根底。同樣在1997年，MOF被OMG采納為標準，為CWM的產生打下了第二個根底。1999年初，OMG采納XMI作為標準，為CWM的出現打下了第三個根底。1998年5月，IBM、ORACLE和Unisys向OMG提交了公共倉庫元數據交換〔CommonWarehouseMetadataInterchange，CWMI〕征求意見稿〔RFP〕，同年9月OMG發(fā)布了該征求意見稿，經過8個公司〔IBM、Unisys、Oracle、Hyperion、UBS、NCR、Genesis和DimensionEDI〕2年半的努力和協(xié)作，OMG于2001年4月正式采納CWM為標準。在CWM開展的同時，其他一些元數據標準的制定也在進行中。最早在1993年，電子信息組織就發(fā)布了計算機輔助工程數據交換格式〔CASEDataInterchangeFormat，CDIF〕并得到了一定的認可。1995年10月，元數據聯盟〔MetaDataCoalition，MDC〕成立，并與1996年4月發(fā)布了元數據交換標準1.0〔MetaDataInterchangeSpecification，MDIS〕，與CWM相比，MDIS涉及的范疇少很多，且其標準和交換語言都是自身獨有的。此時微軟也在和其他一些合作者一起開發(fā)開放信息模型〔OpenInformationModel，OIM〕，該模型于1996年10月成形，采用UML作為其標準語言。1998年11月，微軟參加MDC并提交OIM標準，1999年7月MDC發(fā)布了OIMv1.0版本，由此業(yè)內面臨著兩種元數據集成標準的競爭局面，之后考慮到業(yè)內對CWM的認可，MDC于2000年9月決定終止其OIM后續(xù)工作，將其元數據標準歸入到OMG中，從此CWM影響力和范圍持續(xù)擴大并得到了業(yè)內的統(tǒng)一認可。OMG的模型驅動體系結構〔ModelDrivenArchitecture，MDA〕OMG組織成立不久制定了對象管理體系結構〔ObjectManagementArchitecture，OMA〕參考模型，描述了OMG標準所遵循的概念化的根底結構。OMA是由對象請求代理〔ObjectRequestBroker，ORB〕、對象效勞、公共設施、域接口和應用接口等幾個局部組成，其核心是對象請求代理〔ORB〕。對象請求代理〔ORB〕是公共對象請求代理體系結構〔CommonObjectRequestBrokerArchitecture，CORBA〕的核心組件，提供了識別和定位對象、處理連接管理、傳送數據和請求通信所需的框架結構。OMA和CORBA被定位為軟件框架，用來指導基于OMG標準的技術開發(fā)。從1995年開始，OMG開始非正式的采用針對特定行業(yè)〔“領域〞，Domain〕的技術標準，為了保持擴張重點，OMG在2001年正式采用第二個框架，模型驅動體系架構〔ModelDrivenArchitecture，MDA〕。與OMA和CORBA不一樣，MDA不是部署分布式系統(tǒng)的框架，而是在軟件開發(fā)中基于模型驅動的方法。為了實現MDA，OMG隨后制定了一系列標準如UML、MOF、XMI和CWM等，解決了MDA的模型建立、擴展、交換等幾個方面的問題。模型驅動體系結構源自眾所周知的和長期建立的思想：“將系統(tǒng)操作標準從系統(tǒng)利用底層平臺能力的細節(jié)中別離出來〞。MDA提供了一種方法〔基于相關工具〕來標準化一個平臺獨立的系統(tǒng)，為系統(tǒng)選擇一個特定的實現平臺，并把系統(tǒng)標準轉換到特定的實現平臺。MDA的首要三個目標是：可移植性、互操作性和可重用性。MDA三個視角〔viewpoint〕[6]分別是：計算無關視角〔ComputationIndependentViewpoint〕：側重系統(tǒng)環(huán)境和系統(tǒng)需求；系統(tǒng)結構和流程細節(jié)被隱藏或尚未確定。其對應的是計算無關模型〔ComputationIndependentModel，CIM〕。平臺無關視角〔PlatformIndependentViewpoint〕：側重系統(tǒng)的操作，同時隱藏用于特定平臺的必要細節(jié)。其對應的是平臺無關模型〔PlatformIndependentModel，PIM〕，PIM是抽出技術和具體工程細節(jié)之后的模型。平臺相關視角〔PlatformSpecificViewpoint〕：結合平臺無關系視角和系統(tǒng)所使用的特定平臺細節(jié)。其對應的是平臺相關模型〔PlatformSpecificViewpointModel，PSM〕，PSM是包含技術和具體工程細節(jié)的模型。OMG模型驅動體系結構如圖5所示：圖5OMG模型驅動體系架構CWM元模型、標準以及生成的產品同MDA非常契合，從技術平臺角度來說，所有的平臺相關模型〔CWMXML、CWMIDL和CWMJava等〕都是自動地從平臺無關模型〔CWM元模型和標準〕中產生的；從產品平臺角度來說，平臺相關模型〔比方DB2、ORACLE、SQLSERVER等〕都是人工從平臺無關模型〔CWM元模型和標準〕中構造出來的。結束語本文詳細介紹了大數據治理統(tǒng)一流程參考模型第二步“元數據集成體系結構〞的后續(xù)內容，主要包括元模型、元-元模型、公共倉庫元模型〔CWM〕、CWM開展史、對象管理組織OMG的模型驅動體系結構〔ModelDrivenArchitecture，MDA〕。在本系列文章的下一局部將重點介紹大數據治理統(tǒng)一流程參考模型的第三步：“實施元數據管理〞，講述在大數據時代如何實施元數據管理，如何使用元數據管理成熟度模型，以及IBM在元數據管理方面的產品：業(yè)務元數據管理工具IBMInfoSphereBusinessGlossary、業(yè)務詞匯表小工具InfoSphereBusinessGlossaryAnywhere和技術元數據管理工具InfoSphereMetadataWorkbench。參考文獻更多信息請參考:OMGModelDrivenArchitecture:

;OMG,CommonWarehouseMetamodel(CWM)Specificationv1.1,P44;JohnPoole,DanChang,DouglasTolbertandDavidMellor,2002,CommonWarehouseMetamodel,p48-53,p58-63;OMG,CommonWarehouseMetamodel(CWM)Specificationv1.1,P45;DavidFrankelConsulting,〞UsingModelDrivenArchitecture?toManageMetadata〞,P46;OMG,2003,MDAGuideVersion1.0.1,p11-12,P15-16;第三局部：實施元數據管理了解了元數據管理策略和元數據集成體系結構之后，企業(yè)可以根據需要選擇適宜的業(yè)務元數據和技術元數據管理工具，并制定相應的元數據管理制度進行全面的元數據管理。本局部主要介紹大數據治理統(tǒng)一流程參考模型第三步“實施元數據管理〞，元數據管理成熟度模型、IBM元數據管理相關工具等內容。第三步：實施元數據管理在明確了元數據管理策略和元數據集成體系結構之后，企業(yè)可以根據需要選擇適宜的業(yè)務元數據和技術元數據管理工具，并制定相應的元數據管理制度進行全面的元數據管理。比方可以使用IBMInfoSphereBusinessGlossary進行業(yè)務元數據的管理，使用IBMInfoSphereMetadataWorkbench作為元數據管理統(tǒng)一工具并進行圖形化的元數據分析。大數據擴大了數據的容量、速度和多樣性，給元數據管理帶來了新的挑戰(zhàn)。在構建關系型數據倉庫、動態(tài)數據倉庫和關系型數據中心時進行元數據管理，有助于保證數據被正確地使用、重用并滿足各種規(guī)定。同樣，對大數據來說，元數據管理過程中出現的任何錯誤，都會導致數據重復、數據質量差和無法訪問關鍵信息等問題[1]。隨著大數據技術在企業(yè)中的應用越來越廣泛，企業(yè)需要在原有的元數據管理策略中增加大數據相關的內容。通常，大數據分析是受用例驅動的，企業(yè)可以通過梳理大數據用例的方式逐步完善大數據的元數據管理。針對大數據的業(yè)務元數據，依舊可以通過構建根底本體、領域本體、任務本體和應用本體等的方式來實現。通過構建根底本體，實現對級別且通用的概念以及概念之間關系的描述；通過構建領域本體，實現對于領域的定義，并確定該領域內共同認可的詞匯、詞匯業(yè)務含義和對應的信息資產等，提供對該領域知識的共同理解；通過構建任務本體，實現任務元素及其之間關系的標準說明或詳細說明；通過構建應用本體，實現對特定應用的概念描述，其是依賴于特定領域和任務的。這樣就通過構建各種本體，在整個企業(yè)范圍提供一個完整的共享詞匯表，保證每個元數據元素在信息供給鏈中每個組件的語義上保持一致，實現是語義等效。為了實現信息供給鏈中各個組件元數據的交互和集成，大數據平臺的元數據集成體系結構依然可以采用基于模型驅動的中央輻射式元數據體系結構。對大數據平臺中的結構化數據的元數據管理可以遵循公共倉庫元模型〔CWM〕構建元數據體系結構，以便方便的實現各個組件間元數據的交互；對大數據平臺中的半結構化和非結構化數據的元數據管理，因為業(yè)內還沒有通用的公共元模型，企業(yè)可以嘗試采用基于自定義模型驅動的方式構建中央輻射式元數據體系結構。簡單來說，企業(yè)可以嘗試以下步驟進行大數據的元數據管理：1、考慮到企業(yè)可以獲取數據的容量和多樣性，應該創(chuàng)立一個表達關鍵大數據業(yè)務術語的業(yè)務定義詞庫〔本體〕，該業(yè)務定義詞庫不僅僅包含結構化數據，還可以將半結構化和非結構化數據納入其中。2、及時跟進和理解各種大數據技術中的元數據，提供對其連續(xù)、及時地支持，比方MPP數據庫、流計算引擎、ApacheHadoop/企業(yè)級Hadoop、NoSQL數據庫以及各種數據治理工具如審計/平安工具、信息生命周期管理工具等。3、對業(yè)務術語中的敏感大數據進行標記和分類，并執(zhí)行相應的大數據隱私政策。4、將業(yè)務元數據和技術元數據進行鏈接，可以通過操作元數據〔如流計算或ETL工具所生成的數據〕監(jiān)測大數據的流動；可以通過數據世系分析〔血緣分析〕在整個信息供給鏈中實現數據的正向追溯或逆向追溯，了解數據都經歷了哪些變化，查看字段在信息供給鏈各組件間轉換是否正確等；可以通過影響分析可以了解具體某個字段的變更會對信息供給鏈中其他組件中的字段造成哪些影響等。5、擴展企業(yè)現有的元數據管理角色，以適應大數據治理的需要，比方可以擴充數據治理管理者、元數據管理者、數據主管、數據架構師以及數據科學家的職責，參加大數據治理的相關內容。在實施元數據管理的過程中，可以參照元數據管理的成熟度模型確定企業(yè)當前元數據管理所在層次，并根據業(yè)務需要制定路線圖實現元數據管理水平的提升。元數據管理成熟度模型具體如圖1所示：圖1元數據管理成熟度模型根據元數據管理的成熟度，大體可以分成6個級別，具體如圖1所示：L0:初始狀態(tài)元數據分散于日常的業(yè)務和職能管理中，由某個人或某一組人員在局部產生或獲取，并在局部使用，其他人如果想獲得該元數據需要找到相應的人進行溝通獲取。L1:附屬于業(yè)務系統(tǒng)在這個階段，隨著各個業(yè)務系統(tǒng)自動化構建完成，相應的元數據也隨著需求整理、設計、開發(fā)、實施和維護等過程被各個業(yè)務系統(tǒng)孤立的全部或局部管理起來。業(yè)務元數據可能分散在各種業(yè)務規(guī)章、流程規(guī)定、需求、需求分析和概要設計等文檔以及業(yè)務系統(tǒng)中，技術元數據可能分散在詳細設計、模型設計和部署方案等各種文檔和各種中間件以及業(yè)務系統(tǒng)中。由于各個業(yè)務系統(tǒng)處于一個個豎井之中，元數據之間互通互聯困難，如果需要獲取其他系統(tǒng)的元數據，除了調閱各種文檔外，對分散在各種中間件和業(yè)務系統(tǒng)中的技術元數據需要通過橋〔bridge〕的方式實現互通互聯。L2：元數據統(tǒng)一存儲元數據依然在局部產生和獲取，但會集中到中央存儲庫進行存儲，業(yè)務元數據會手工錄入到中央存儲庫中，技術元數據分散在文檔中的局部也通過手工錄入到中央存儲庫中，而散落在各個中間件和業(yè)務系統(tǒng)中的技術元數據那么通過橋〔bridge〕的方式被讀取到中央存儲庫中。業(yè)務元數據和技術元數據之間全部或局部通過手工方式做了關聯。中央存儲庫的構建，使得元數據在整個企業(yè)層面可被感知和搜索，極大地方便了企業(yè)獲取和查找元數據。缺點是，元數據仍然在各業(yè)務系統(tǒng)上維護，然后更新到中央存儲庫，各業(yè)務豎井之間仍然使用不同的命名法，經常會造成相同的名字代表不同意義的事情，而同一件事情那么使用了多個不同的名字，有些沒有納入業(yè)務系統(tǒng)管理的元數據那么容易缺失。元數據沒有有效的權限管理，局部元數據更改后也不自動通知其他人。L3:元數據集中管理在L2的根底上做了改良，增強了元數據的集中控制，局部業(yè)務單元或開發(fā)小組如不事先通知其他人，將無法對元數據進行修改。局部元數據的修改完成后將被播送給其他人。和其他中間件和應用系統(tǒng)的交互，仍然通過橋〔bridge〕的方式進行，中央存儲庫中的業(yè)務元數據和技術元數據之間還是通過手工方式進行映射。L4：元模型驅動管理在L3的根底上，通過構建元模型以及元元模型，優(yōu)化各業(yè)務單元之間的各種沖突和各種副本，創(chuàng)立、管理和共享業(yè)務詞匯表和分類系統(tǒng)〔基于主題領域的層次結構〕。業(yè)務詞匯表〔業(yè)務元數據〕包含與企業(yè)相關的詞匯、詞匯業(yè)務含義以及詞匯與信息資產〔技術元數據〕的關系，可以有效幫助企業(yè)用戶了解其業(yè)務元數據和技術元數據對應的業(yè)務含義。分類是基于主題領域的層次結構，用以對業(yè)務術語歸類。和其他中間件和應用系統(tǒng)的交換，通過基于CWM的適配器方式進行連接。L5:元數據管理自動化在L5元數據管理是高度自動化的，當邏輯層次元數據變更時，會被傳播到物理層次，同樣物理層次變更時邏輯層次將被更新。元數據中的任何變化將觸發(fā)業(yè)務工作流，以便其他業(yè)務系統(tǒng)進行相應的修改。由于各個業(yè)務系統(tǒng)遵照相同的業(yè)務詞匯表和分類系統(tǒng)〔元模型〕，他們之間的關系可以通過知識本體進行推斷，因此各個應用系統(tǒng)之間的數據格式的映射自動產生。IBMInfoSphereInformationServer元數據管理組件介紹IBMInfoSphereInformationServer可以幫助組織從分散在其系統(tǒng)中的各種復雜信息中獲取更多價值。它讓組織能夠整合分散的數據，在需要的地方和時間，按順序和關聯關系把可信的信息交付給特定的人員、應用程序和流程。InfoSphereInformationServer幫助業(yè)務人員和IT人員進行協(xié)作，理解來自任何來源的任何類型的信息的含義、結構和內容。它可以顯著提高在整個企業(yè)內一致且平安地清理、轉換和交付信息的生產力和效率，這樣就可以以新的方式訪問和使用信息，從而促進創(chuàng)新、提高運營效率并降低風險。InfoSphereInformationServer讓客戶可以跨分析、運營和事務環(huán)境應用一致的可重復的流程以解決企業(yè)級數據問題，不受數據量、復雜性或延遲的限制。InfoSphereInformationServer的每個核心產品可以作為集成平臺的一局部使用，也可以作為單獨的集成產品使用。這些產品由一個全面的集成效勞平臺支持，提供全程數據集成、元數據管理、任何數據源與任何平臺上的任何應用程序之間的連接以及通過并行處理技術無限制地擴展?？梢园慈魏闻渲貌渴疬@些功能以支持事件驅動或按時間表執(zhí)行的處理。還可以通過InfoSphereInformationServicesDirector交付根底設施“隨需〞使用InfoSphereInformationServer數據集成功能，從而補充EnterpriseApplicationIntegration(EAI)、BusinessProcessManagement(BPM)、EnterpriseInformationIntegration(EII)和ApplicationServers集成根底設施。InfoSphereInformationServer提供一個全面的模塊化解決方案，可以根據業(yè)務需求和客戶預算擴展。客戶既可以部署完整的InfoSphereInformationServer以處理整個企業(yè)數據集成生命周期，也可以使用單獨的集成產品并根據需要添加其他組件。這種靈活的方式讓客戶既可以通過完整的InfoSphereInformationServer實現全面集成，也可以通過購置一個或更多組件的許可證實現局部集成，以后可以添加其他組件以創(chuàng)立單一的集成解決方案。InfoSphereInformationServer可以提高從事數據集成工程的開發(fā)團隊的生產力，改良這些開發(fā)團隊之間以及開發(fā)人員與提出需求的業(yè)務用戶之間的協(xié)作，促進工程團隊內部和之間的重用，這些都會產生價值。為SAP、Oracle、PeopleSoft、Siebel、SalesForce等公司的企業(yè)應用程序預先構建的接口擴展了InfoSphereInformationServer的功能范圍。這些包幫助公司通過企業(yè)數據倉庫或ERP廠商業(yè)務智能化解決方案集成來自這些企業(yè)應用程序的數據，構建分析解決方案。InfoSphereInformationServer提供一套統(tǒng)一的可單獨購置的產品模塊(即套件組件)，可以解決多種類型的業(yè)務問題?？梢钥绻こ讨赜眯畔z驗、訪問和處理規(guī)那么，這會提高一致性、增強對數據的管控并提高IT工程的效率。IBMInformationServer讓企業(yè)能夠實現5種關鍵的集成功能：連接任何數據或內容，無論它駐留在什么地方：大型機或分布式系統(tǒng)，內部或外部；了解并分析信息，理解數據源的內容、質量和結構，從而在整個企業(yè)中集成和傳播數據之前全面了解數據；清理數據，確保數據的質量和一致性，讓公司可以訪問任何個人或業(yè)務實體及其關系的權威且一致的視圖；轉換大量數據，從而有效且高效地從原數據源向目標提供豐富的有針對性的信息；交付數據，讓人員、流程和應用程序可以像訪問單一資源一樣訪問和集成不同類型的數據和內容，無論信息駐留在什么地方。這些功能的根底是一個共用的元數據和并行處理根底設施，它為整個平臺提供支持和自動化。產品組合中的每個產品還可以連接許多數據和內容源，能夠通過多種機制交付信息。另外，可以通過便于發(fā)布的共享效勞在面向效勞架構中使用這些功能。IBMInformationServer提供：最廣泛的訪問信息源的能力；最全面的集成功能，包括聯合、ETL、內聯轉換、復制和事件發(fā)布；在使用這些功能的方式方面的靈活性，包括支持面向效勞架構、事件驅動的處理、按時間表執(zhí)行的批處理以及SQL和Java等標準API平臺的功能廣度和靈活性讓它能夠解決許多類型的業(yè)務問題，滿足許多類型的工程的需求。這可以增加重用的時機，加快工程的速度，提高信息的一致性，增強信息治理。IBMInfoSphereInformationServer由以下組件組成:元數據效勞InfoSphereBusinessGlossaryInfoSphereBusinessGlossaryAnywhereInfoSphereMetadataWorkbenchInfoSphereInformationAnalyzerIBMInformationServerFastTrackInfoSphereQualityStageInfoSphereDataStageInfoSphereInformationServicesDirectorInfoSphereChangeDataDeliveryforInformationServerInfoSphereFederationServer元數據效勞是IBMInformationServer所基于的平臺的組成局部?？梢酝ㄟ^使用元數據效勞訪問數據以及完成分析、建模、清理和轉換等數據集成任務。IBMInformationServer的主要元數據效勞組件是InfoSphereBusinessGlossary、InfoSphereMetadataServer以及InfoSphereMetaBrokers和橋。InfoSphereBusinessGlossary是一個基于web的交互式工具，可以幫助用戶創(chuàng)立、管理和共享業(yè)務詞匯表和分類系統(tǒng)。業(yè)務詞匯和技術信息資產保持一致可以促進業(yè)務和IT群體的協(xié)作，有助于更有效地治理數據。另外，這個工具的數據專員功能可以提升責任感，支持數據治理策略。InfoSphereMetadataWorkbench允許以基于web的方式查看IBMInfoSphereInformationServer和其他第三方應用程序生成和使用的信息資產。這個瀏覽工具可以提高對最重要的信息的信任程度。另外，InfoSphereMetadataWorkbench向IT人員提供健壯的查詢功能和全面且靈活的數據世系報告，讓他們可以深入了解環(huán)境中使用的數據，還可以監(jiān)視數據集成活動。在處理數據集成工程中的變動時，強大的影響分析工具可以幫助數據分析師和開發(fā)人員做出更好的決策。InfoSphereBusinessGlossary介紹BusinessGlossary是用來管理和展示企業(yè)業(yè)務元數據的基于Web的交互式工具，支持用戶創(chuàng)立、管理和共享業(yè)務詞匯表和分類系統(tǒng)〔基于主題領域的層次結構〕。業(yè)務詞匯表〔業(yè)務元數據〕包含與企業(yè)相關的詞匯、詞匯業(yè)務含義以及詞匯與信息資產〔技術元數據〕的關系，可以有效幫助企業(yè)用戶了解其業(yè)務元數據和技術元數據的對應的業(yè)務含義。BusinessGlossary可以使所有用戶協(xié)同管理業(yè)務元數據比方元數據定義、同義詞、樣例和分類等，并提供多種查詢方式，比方報表、條件查詢、影響分析等。元數據應該由了解信息資產對業(yè)務的意義和重要性的人員進行管理。InfoSphereBusinessGlossary設計用于協(xié)作授權，使用戶能夠共享關于數據的見解和體驗。產品為用戶提供關于數據資源的以下信息：數據的商業(yè)意義和說明；數據和流程的管家；保證的業(yè)務等級；獲準使用的術語；用戶可根據可控詞匯表定義的語義來組織并查找InfoSphereBusinessGlossary，您可使用Web控制臺來創(chuàng)立可控詞匯表。IBMBusinessGlossary業(yè)務術語管理分類如圖2所示，通過業(yè)務術語管理可以實現：定義權威性的含義；增加對整個企業(yè)機構的業(yè)務理解；建立職責和可追溯的制度；描繪業(yè)務層次；記錄業(yè)務描述，例如縮寫和同義詞；查找相關的信息資產；鼓勵使用、重用和更正業(yè)務術語；讓IT與業(yè)務目標更有效地結合；提供業(yè)務內容與IT資產的對應聯系；建立職責和數據管控的政策。圖2IBMInfoSphereBusinessGlossary業(yè)務術語管理分類通過使用BusinessGlossary解決方案可以幫企業(yè)帶來很多價值，比方：獲取業(yè)務術語并進行分類，基于Web的業(yè)務元數據生成、管理和共享；把業(yè)務術語及其分類與IT資產關聯，為信息技術資產提供業(yè)務環(huán)境；識別數據使用者讓業(yè)務術語可被訪問，讓每個用戶可立刻訪問有內涵的信息；讓IT工程向數據管理看齊，創(chuàng)立和管理業(yè)務術語及關系，同時鏈接到物理數據源。加強業(yè)務與IT人員的通力合作，確立責任和義務，使IT部門的工作與業(yè)務部門的目標保持一致。BusinessGlossary與InformationServer其他組件以及第三方產品交互如圖3所示，BusinessGlossary負責對業(yè)務元數據進行管理，MetadataServer作為中央共享元數據庫負責存儲業(yè)務、技術和操作元數據，InformationServer組件的各種開發(fā)和運行元數據將會自動存儲在MetadataServer中，通過import/exportmanager還可以將第三方各種元數據與MetadataServer進行元數據交互，MetadataServer還支持導入CSV、XML、Glossaryarchive和InfoSphereDataArchitect等內容。MetadataWorkbench允許用戶瀏覽、分析和管理在MetadataServer中的元數據并為企業(yè)用戶提供信息供給鏈全程的數據流報告、數據沿襲和依賴性分析等。InformationServer其他組件〔如FastTrack/InformationAnalyzer/InfoSphereDataArchitect等〕可以直接訪問MetadataServer獲取元數據，DataStage和QualityStage可以通過DataStageConnectors訪問MetadataServer。如右下方所示，訪問業(yè)務元數據的方法有多種，可以通過BusinessGlossary瀏覽器瀏覽和搜索詞匯表，可以通過BusinessGlossaryAnywhere客戶機瀏覽詞匯表內容并支持屏幕取詞功能，可以通過BusinessGlossaryRESTAPI〔RepresentationalStateTransfer應用程序編程接口〕編寫自己的程序來訪問和修改業(yè)務詞匯表內容，還可以通過BusinessGlossaryClientforEclipse插件讓基于Eclipse的應用程序直接訪問詞匯表內容。BusinessGlossary還支持與CognosBI和IBMIndustryModels等集成。圖3元數據管理體系結構圖InfoSphereBusinessGlossaryAnywhere介紹IBMInfoSphereBusinessGlossaryAnywhere可以從在MicrosoftWindows計算機上翻開的任何文本文件直接訪問業(yè)務詞匯表。另外，InfoSphereBusinessGlossaryAnywhere附帶IBMInfoSphereBusinessGlossaryClientforEclipse和IBMInfoSphereBusinessGlossaryRESTAPI。通過使用IBMInfoSphereBusinessGlossaryAnywhere，用戶可以在執(zhí)行其他基于計算機的任務的同時搜索業(yè)務詞匯表，不會喪失上下文或分散注意力。用戶可以通過鼠標或鍵盤操作在MicrosoftWindows桌面上翻開的文檔中捕捉單詞或短語，然后在業(yè)務詞匯表內容中搜索它。用戶不必另外翻開并登錄InfoSphereBusinessGlossary，就可以使用大多數業(yè)務詞匯表信息。InfoSphereMetadataWorkbench介紹IBMInfoSphereMetadataWorkbench是基于Web界面的元數據管理工具，對MetadaServer中的業(yè)務元數據和技術元數據提供完整的管理并提供元數據的完整視圖，提供多種元數據導入導出功能。InfoSphereMetadataWorkbench可以在整個數據集成工程中跟蹤和維護信息的關系，從而提高IT對業(yè)務人員的透明性和IT的響應能力。使用InfoSphereInformationServer產品中不同的模塊用戶，可以通過InfoSphereMetadataWorkbench查看InfoSphereInformationServer元數據存儲庫中的元數據和數據資產。MetadataWorkbench可以提供豐富的元數據分析，為整個信息供給鏈的元數據提供全程的數據流報告，提供基于字段或作業(yè)的數據沿襲〔也就是數據世系分析或血緣分析〕、影響分析和系統(tǒng)相關性分析等。例如某電信公司在前端展示工具CognosReportStudio中展示的掉話率指標明顯和實際不符，可以通過MetadataWorkbench使用血緣分析上溯到數據源〔數據倉庫、ODS、ETL、網管系統(tǒng)、EOMS〕并圖形化的顯示出該路徑上的所有對象，方便查找在哪個環(huán)節(jié)出現問題。數據流報告顯示數據從最開始的業(yè)務系統(tǒng)〔粒度到列級別〕、復制、ETL、ODS或數據倉庫到前端展示報告或Dashboad完整的轉移路徑，包括其中對數據執(zhí)行的處理的類型等。數據流報告方便業(yè)務人員了解信息的起源以及具體的轉移過程，有助于進行數據世系分析，滿足法律遵從性和可審計性需求。比方可以方便的找出前端展示報告中的某個字段的來源，某個Datastage作業(yè)將數據移動到什么位置等。數據世系分析可以跟蹤整個企業(yè)的數據流〔即便數據沒有保存在MetadataServer中〕，可以通過創(chuàng)立擴展映射和擴展數據源來跟蹤數據流，為數據流中的任何資產創(chuàng)立擴展的數據世系分析報告。結束語本文詳細介紹了大數據治理統(tǒng)一流程參考模型的第三步：“實施元數據管理〞，并詳細講述了在大數據時代如何實施元數據管理，隨后介紹了元數據管理成熟度模型，幫助企業(yè)可以參考該模型衡量自己當前元數據管理水平，最后簡單介紹了IBM在元數據管理方面的產品：業(yè)務元數據管理工具IBMInfoSphereBusinessGlossary、業(yè)務詞匯表小工具InfoSphereBusinessGlossaryAnywhere和技術元數據管理工具InfoSphereMetadataWorkbench。在本系列文章的下一局部將重點介紹大數據治理統(tǒng)一流程參考模型第四步“定義業(yè)務問題〞、第五步“獲得主管支持〞、第六步“執(zhí)行成熟度評估〞、第七步“構建路線圖〞、第八步“建立組織藍圖〞和第九步“了解數據〞等內容，并繼續(xù)介紹IBM信息效勞器中的InfoSphereInformationAnalyze、InfoSphereFederationServer、InfoSphereReplicationServer和InfoSphereChangeDataCapture等。InfoSphereInformationAnalyze是一款數據質量分析工具軟件，用來在工程初期對數據源進行數據質量分析，以便真正地了解源數據的結構、質量和數據分布等，提早發(fā)現數據的缺失、錯誤、重復和不一致等問題，為后面的數據復制、ETL等過程提供支持，以便降低工程實施風險。參考文獻SunilSoares,“BigDataGovernance〞,Part7；本章參考了IBM相關產品的信息中心、白皮書、方案建議書以及其他各種資料。第四局部：大數據治理統(tǒng)一流程參考模型的第四步到第九步如果想要成功地實施大數據治理方案，需要了解信息供給鏈中的各個環(huán)節(jié)的數據模型、主外鍵關系等。本局部主要介紹大數據治理統(tǒng)一流程參考模型第四步“定義業(yè)務問題〞、第五步“獲得主管支持〞、第六步“執(zhí)行成熟度評估〞、第七步“構建路線圖〞、第八步“建立組織藍圖〞和第九步“了解數據〞等內容。第四步：定義業(yè)務問題如何準確的定義和描述業(yè)務問題是數據治理方案成功的關鍵，企業(yè)可以從對特定問題或領域進行數據治理的緊迫程度以及數據治理能夠帶來的價值來綜合衡量，對排名靠前的問題或領域優(yōu)先進行數據治理，這樣能充分獲得業(yè)務職能部門以及IT部門的支持，從而保證數據治理方案的成功。數據治理初始范圍確定后，執(zhí)行具體的數據治理工作，等成功后再考慮擴展至其他領域?？偨Y以往很多企業(yè)進行數據治理失敗的原因時可以發(fā)現很多經常出現的病癥，比方：企業(yè)未從數據治理中獲得任何價值；數據治理過于長期，和企業(yè)專注短期目標不符；IT部門應對數據質量負責；IT部門認為數據治理過于復雜，無法順利落地；企業(yè)為數據管理員分配了其他職責。分析以上問題出現的根源，可以發(fā)現數據治理方案失敗的根本原因在于與業(yè)務價值缺乏關聯，IT部門單獨進行數據治理，沒有和相關業(yè)務部門進行聯動。數據治理需要所有利益相關方參與，可以從業(yè)務角度〔而不是技術角度〕總結出各種數據治理的價值，從而吸引相關業(yè)務領域高層領導的支持，從而保證數據治理可以獲得更高的業(yè)務收益。舉例說明如何定義業(yè)務問題，很多上市公司財報都被監(jiān)管機構要求提供其數據來源并證明其數據可信，而報告本身所使用的數據流經信息供給鏈多個組件〔如立方體、數