數(shù)據(jù)質(zhì)量體系結(jié)構(gòu)介紹

數(shù)據(jù)質(zhì)量體系結(jié)構(gòu)介紹作者：杜紹森編譯出處：IT1682008-05-1209:14數(shù)據(jù)質(zhì)量管理過程是一個沒有終點(diǎn)的過程，也沒有統(tǒng)一架構(gòu)原則。這里提供的是一種針對數(shù)據(jù)倉庫項目可以簡單實現(xiàn)的、可擴(kuò)展的、一種相對比較完善的捕捉數(shù)據(jù)質(zhì)量事件，同時對其進(jìn)行量度和控制的方法。本文提供一個在數(shù)據(jù)倉庫項目的實施過程中，可增量添加的、可擴(kuò)展的數(shù)據(jù)質(zhì)量體系結(jié)構(gòu)，它可以保證以最小的對前期投資的影響，并增加到存在的數(shù)據(jù)倉庫和數(shù)據(jù)集成環(huán)境中。使用這個架構(gòu)，也可以實現(xiàn)項目系統(tǒng)化的向6Sigma質(zhì)量管理體系的擴(kuò)展。這個架構(gòu)的設(shè)計也是針對數(shù)據(jù)倉庫領(lǐng)域缺乏的公開的、一致的說明數(shù)據(jù)質(zhì)量的問題來進(jìn)行組織的。有三股力量已將對將數(shù)據(jù)集成、數(shù)據(jù)質(zhì)量的關(guān)注呈現(xiàn)在組織管理層優(yōu)先執(zhí)行活動中。它們是：一、普遍地認(rèn)為"如果僅能看到數(shù)據(jù)，而無法確定其質(zhì)量等級,就無法更好的管理的業(yè)務(wù)〃的認(rèn)識，正在持續(xù)增長。絕大多數(shù)的知識工作者相信對自身的工作職能來說，數(shù)據(jù)是至關(guān)重要的;二、絕大多數(shù)的全球化的，分布式的組織機(jī)構(gòu)逐步形成共識，集成分散在全球各地的業(yè)務(wù)數(shù)據(jù)是企業(yè)競爭力的必要因素;三、急劇增長法律符合性的要求也是一個重要的因素。僅這三個方面的驅(qū)動力，對于強(qiáng)調(diào)數(shù)據(jù)質(zhì)量的問題顯然還并不充分。幸運(yùn)的是，還有一股強(qiáng)大的動力正來自除了IT部門以外的業(yè)務(wù)人員。業(yè)務(wù)人員正在逐步的認(rèn)識到數(shù)據(jù)質(zhì)量問題是一個嚴(yán)重的，需要高昂的成本的問題，這樣，組織主動性地提供數(shù)據(jù)質(zhì)量就有了更大的動力。但是，多數(shù)的業(yè)務(wù)人員可能并不能完全了解數(shù)據(jù)質(zhì)量問題產(chǎn)生的原因，找到提高數(shù)據(jù)質(zhì)量的方法。有時他們認(rèn)為數(shù)據(jù)質(zhì)量問題主要是IT部門操作層面的問題。在這樣的情況下，IT部門就應(yīng)該更加認(rèn)識到：數(shù)據(jù)質(zhì)量問題不可能僅通過IT部門來單獨(dú)改善，更需要業(yè)務(wù)部門的積極、主動參與。事實上，數(shù)據(jù)質(zhì)量領(lǐng)域一個極端的看法認(rèn)為：〃數(shù)據(jù)質(zhì)量問題幾乎和IT沒有任何的關(guān)聯(lián)〃。在關(guān)注數(shù)據(jù)質(zhì)量時，如果僅僅要求前臺的操作人員在輸入數(shù)據(jù)時保持足夠的細(xì)心，或要求銷售人員在錄入訂單的客戶和產(chǎn)品信息時保持足夠的仔細(xì)顯然都是不夠的。我們還可以通過在數(shù)據(jù)的錄入界面上附加更加嚴(yán)格的技術(shù)性約束來避免和修復(fù)數(shù)據(jù)的質(zhì)量問題。這些方法提供了一些修復(fù)或避免數(shù)據(jù)質(zhì)量問題的線索，但是在采取這些技術(shù)性措施之前，我們需要用一個更大的視野關(guān)注數(shù)據(jù)質(zhì)量問

題。例如：在一個零售銀行，身份證號碼是空白的或者是填入了一些垃圾信息。一個不錯的想法是增加一個諸如必須滿足999-99-9999的技術(shù)限制，系統(tǒng)不接受任何不滿足格式約束的輸入信息。在這種約束下，身份證號碼可能不再為空或者任何字符數(shù)據(jù)，但前臺的數(shù)據(jù)錄入人員就會由于完成后續(xù)工作的需要而被強(qiáng)迫錄入有效的身份證號碼，但在并沒有客戶有效身份證號碼的情況下，他們只好使用了自己的身份證號碼。建立質(zhì)量傳統(tǒng)、重建運(yùn)行過程眾所周知，如果沒有來自組織高層對建立企業(yè)范圍的數(shù)據(jù)質(zhì)量體系的承諾，技術(shù)人員說明的數(shù)據(jù)質(zhì)量問題嘗試往往很難發(fā)揮作用。在日本，汽車制造商通常將控制數(shù)據(jù)質(zhì)量的態(tài)度滲透到組織的各個層面，從CEO到一線的生產(chǎn)線人員，從而保證了其準(zhǔn)確、高效的決策效率。為了說明管理層對建立數(shù)據(jù)質(zhì)量文化的重要性，我們使用一個大型的連鎖藥店作為例子來說明，在這家藥店，采購部門和數(shù)量龐大的供應(yīng)商保持合作、供應(yīng)關(guān)系。在采購部，采購助理將每一個采供來的藥物錄入到IT系統(tǒng)當(dāng)中，這些信息包含大量的屬性。這樣采購助理會面對巨大的工作量，他們不得不評估一個小時他們可以錄入多少的數(shù)據(jù)，多長時間才可以將這些信息錄入完畢。同時，采購助理也沒有清晰的概念，誰將使用那些數(shù)據(jù)，那些數(shù)據(jù)對那些使用者更加重要。有時，采購助理會由于明顯的輸入錯誤受到指責(zé)，但更麻煩的情況是，采購助理拿到的數(shù)據(jù)本身就是不完整或不可靠的。例如：對藥物的毒性水平，沒有規(guī)范化的標(biāo)注，長期以來，不同的藥品，不同的品類，這個指標(biāo)都是各不相同的。那么，這個藥店應(yīng)該如何提高數(shù)據(jù)質(zhì)量呢？這里有一個9步驟的數(shù)據(jù)質(zhì)量模版，它不僅可以用到這個藥店，也可以應(yīng)用到其他任何一個希望對數(shù)據(jù)質(zhì)量進(jìn)行管理的組織。這9個步驟包括：?獲得來自組織高層對數(shù)據(jù)質(zhì)量文化的承諾?在執(zhí)行層面上，形成保證數(shù)據(jù)質(zhì)量的工作流程?對提高數(shù)據(jù)錄入的環(huán)境有所投資?提高應(yīng)用間集成性?需要投入成本來改變存在問題的工作流程

?提高end-to-end的團(tuán)隊理解?提升部門間的協(xié)作?公開的表彰數(shù)據(jù)質(zhì)量提升的事件?提供持續(xù)的過程，不斷的量度和提升數(shù)據(jù)質(zhì)量從上面我們可以看到，在這個藥店，需要一些資金用于修改數(shù)據(jù)數(shù)據(jù)錄入系統(tǒng)，為采購助理提供一些錄入時的選擇和上下文提示。公司的管理層也需要明確地強(qiáng)調(diào)采購助理工作的重要性，指明采購助理的工作是公司各個層面決策正確、有效性的基礎(chǔ)。采購助理的辛勤工作應(yīng)該受到來自管理層的公開的表彰，并進(jìn)行獎勵。從而達(dá)到實現(xiàn)團(tuán)隊的end-to-end互相了解和欣賞。在執(zhí)行層的支持和組織框架就需之后，就需要選用特定的技術(shù)方案。后面，我們將討論如何選擇、使用恰當(dāng)?shù)募夹g(shù)來支持?jǐn)?shù)據(jù)質(zhì)量目標(biāo)。這些技術(shù)目標(biāo)包括:?早期的診斷和治療數(shù)據(jù)質(zhì)量問題?明確對源系統(tǒng)的需求，集中力量提供更高質(zhì)量的數(shù)據(jù)?明確地描述在抽取、轉(zhuǎn)換和加載過程中遇到的數(shù)據(jù)的錯誤問題?提供捕捉數(shù)據(jù)質(zhì)量問題的框架?提供精確的度量數(shù)據(jù)質(zhì)量的框架?為最終的數(shù)據(jù)提供質(zhì)量信心度量數(shù)據(jù)質(zhì)量探査的角色數(shù)據(jù)質(zhì)量探查是一種描述數(shù)據(jù)上下文、一致性、數(shù)據(jù)結(jié)構(gòu)的分析技術(shù)。某種意義上說，當(dāng)使用SELECTDISTINCT對某些字段數(shù)據(jù)查詢時，就在完成一個數(shù)據(jù)質(zhì)量探查的工作?，F(xiàn)在，已經(jīng)有很多功能強(qiáng)大的工具可以幫助完成數(shù)據(jù)質(zhì)量探查的工作。一般來說這些工具已經(jīng)提供了非常方便的接口來幫助用戶了解數(shù)據(jù)和數(shù)據(jù)間的關(guān)系。在數(shù)據(jù)倉庫項目中，數(shù)據(jù)質(zhì)量探查可以同時在戰(zhàn)略和戰(zhàn)術(shù)的的層面

上扮演重要角色。在DW項目開始時，一個數(shù)據(jù)源確定之后，就需要首先對它進(jìn)行一次快速的數(shù)據(jù)質(zhì)量探查過程來評估數(shù)據(jù)質(zhì)量，為是否才用其作為有效的數(shù)據(jù)源作為策依據(jù)。理想的情況下，這種戰(zhàn)略性的評估應(yīng)該在1,2天內(nèi)完成。早期的了解數(shù)據(jù)、揭示數(shù)據(jù)的問題是一個負(fù)責(zé)任的步驟。幾個月后才進(jìn)行這項工作，對項目的目標(biāo)有可能會是致命的。從戰(zhàn)略的角度決定將這個數(shù)據(jù)源納入到項目中后，還需要有一個詳細(xì)的戰(zhàn)術(shù)性的數(shù)據(jù)質(zhì)量探查來盡可能揭示更多的數(shù)據(jù)問題。在這個階段揭示的問題最終需要呈現(xiàn)在詳細(xì)的規(guī)格說明中來處理，處理的方式包括：1）將這些數(shù)據(jù)反饋給源系統(tǒng)，提請修正這些問題;或2）將這些問題數(shù)據(jù)的處理融合到ETL過程中。我們相信絕大多數(shù)的數(shù)據(jù)問題都可以在這兩個過程中揭示出來，并得到解決。質(zhì)量Screen質(zhì)量Screen是數(shù)據(jù)倉庫ETL架構(gòu)的心臟，在數(shù)據(jù)流圖中它擔(dān)負(fù)著數(shù)據(jù)質(zhì)量醫(yī)生的作用。質(zhì)量Screen簡化了在ETL或數(shù)據(jù)遷移過程中測試工作實踐。如果測試通過，一般不需要記錄任何事情;但是如果測試失敗，Screen必須要完成：?將錯誤事件記錄到錯誤事件主題中，并?選擇中止處理過程，將用于恢復(fù)的數(shù)據(jù)放到的臨時存儲中或者僅僅標(biāo)記錯誤的數(shù)據(jù)所有的質(zhì)量Screen在架構(gòu)上是相似的，參照J(rèn)ackOlson的分類方式，分為三個簡單類型：列Screen、結(jié)構(gòu)Screen和業(yè)務(wù)規(guī)則Screen。列Screen用于測試單一列中的數(shù)據(jù)。列Screen過程通常比較簡單，進(jìn)行一些比較明顯的測試，如：某個列包含不希望的NULL，列值超過了定義的列的精度，或列值不滿足格式的要求。結(jié)構(gòu)Screens測試跨列的數(shù)據(jù)間關(guān)系。例如：列間的層次關(guān)系、一對多的關(guān)系。結(jié)構(gòu)Screens包括測試兩個表域間的主外鍵關(guān)系，也包括對郵政地址的整個數(shù)據(jù)塊的測試。

業(yè)務(wù)規(guī)則Screens實現(xiàn)更加復(fù)雜的、不適合列和結(jié)構(gòu)Screens的測試。例如:客戶的Profile可以進(jìn)行依賴時間的業(yè)務(wù)規(guī)則進(jìn)行測試。女如白金卡的常旅客要求至少5年，并每年至少2萬公里的飛行距離。業(yè)務(wù)規(guī)則測試也可以進(jìn)行聚合規(guī)則的闋值的測試等。錯誤事件主題模型錯誤事件主題模型是一個集中式的維主題模型，它用來在保存質(zhì)量Screens過程中拋出的錯誤事件。這個方法可以方便應(yīng)用在通常的數(shù)據(jù)集成應(yīng)用中。在下圖可以見到錯誤事件的ER模型：Data(ilmenslOHErrorevenl1^1ScreenData(ilmenslOHErrorevenl1^1ScreendlmenuonElror即汕tdafn(FK>DateattributesB^tchdhnenslotiBatchkeyElror即汕tdafn(FK>DateattributesB^tchdhnenslotiBatchkeyBatcna-HibutasError拠i|細(xì)|PK)Errorinventdat?]「K]Scr?nkey(FK?Balchkey(FKITimeofJayS^uanlysiora烘iikey|PK)立陽凹竹陽EFLmoduleScreairkkeesii嚶rie：ExceptionactiontrmrevEnldEtjiEErroreventk刃(FK/T^ble-FK)Recordid^nfifiti：7KjHeiniceihtiEi-(FK)Erri?rcoridiNongraj?-戲和ffieldinfisdi田耐&&吐圖1：錯誤事件主題模型這個模型的主表是錯誤事件事實表。它的粒度是在ETL或數(shù)據(jù)遷移時質(zhì)量Screens中拋出的錯誤事件。事實表的粒度是事實表紀(jì)錄內(nèi)容的物理描述。即，每一個質(zhì)量Screen錯誤在這表中產(chǎn)生一條記錄，表中每一條記錄對應(yīng)一個發(fā)現(xiàn)的錯誤。錯誤事件的主題模型包含的維表包括錯誤發(fā)生的日歷日期、Screen和Batch工作維。日歷日期不是用分秒表示的時間戳信息，而是提供了一種通過通用的日歷日期屬性對錯誤事件提供約束和聚合的有用信息，例如：工作日、財年的最后一天等這樣的描述信息。事實表中的Time-of-day列則是一個完整的時間戳，用

于精確的描述錯誤發(fā)生的時間。這樣格式在希望用時間做一些計算方面是非常有用的，例如計算兩次錯誤發(fā)生的時間間隔等。Batch維不僅能處理批操作，也可包含持續(xù)的操作過程。Screen維精確的描述了Screen的標(biāo)準(zhǔn)是什么，當(dāng)錯誤發(fā)生時我們應(yīng)當(dāng)做什么？（中斷處理、發(fā)出信息掛起某些操作或者僅僅對數(shù)據(jù)進(jìn)行標(biāo)記等）。錯誤事實表包含一個唯一的主鍵ErrorEventKey。和維表的主鍵一樣，這是一個用整數(shù)序列生成的代理鍵。這個鍵域是非常有必要的，保證大量的錯誤在一次操作中同時發(fā)生時，將其加入到這個事實表當(dāng)中的時候。當(dāng)然，這種錯誤情況最好不要發(fā)生。這個錯誤事件主題還包含另外一個事實表，以更加詳細(xì)的粒度紀(jì)錄這個發(fā)生的問題。在這個表中的每一條記錄標(biāo)示了數(shù)據(jù)記錄中發(fā)生錯誤的每一個域。這樣，就可以記錄和處理諸如復(fù)雜的結(jié)構(gòu)或者業(yè)務(wù)規(guī)則在更高的層面上發(fā)生的問題。這樣的錯誤有可能在EventDetail事實表中產(chǎn)生多條記錄。兩個事實表通過Errorevent域間的主外鍵關(guān)系進(jìn)行關(guān)聯(lián)。這樣ErrorEventDetail表就可以從表、記錄、域的角度精確的描述發(fā)生的問題，同樣在這個表中通過主外鍵關(guān)系繼承來自高粒度事實表的Date、Screen、Batch的信息。到目前為止，我們已經(jīng)擁有了一個可以處理復(fù)雜的多域、多錯誤的主題模型。錯誤事件細(xì)節(jié)表也可以包含精確的時間戳用于提供完整的、精確的描述在一段時間內(nèi)錯誤多個紀(jì)錄的聚合闋值問題。響應(yīng)質(zhì)量事件從上面，已經(jīng)注意到對每一個質(zhì)量Screen都需要有所應(yīng)對?？赡艿倪x擇包括：1）終止處理過程；2）設(shè)置防御性標(biāo)志掛起進(jìn)程用于后續(xù)的附加操作;3）標(biāo)記問題內(nèi)容，繼續(xù)后續(xù)的處理。這三個選項都可能不是的最佳選擇。中斷處理是一個明顯的痛苦的選項，中斷之后，我們還不得不進(jìn)行手工的干預(yù)、診斷，選擇重新啟動、從斷點(diǎn)處處理或者完全的結(jié)束這次的工作，進(jìn)行異常恢復(fù)。選擇掛起也不是一個很好的選擇，因為沒有人清楚什么時間問題可以被修復(fù)，甚至是否可以被修復(fù)。一般的推薦，對很小的數(shù)據(jù)問題，盡量不要使用掛起的策略。第三個選擇，標(biāo)記問題數(shù)據(jù)繼續(xù)進(jìn)行處理往往是比較好的。錯誤事實表的數(shù)據(jù)在下面的審

計維中會有所討論。錯誤的維數(shù)據(jù)也可以借鑒審計維的方式，同時為了以防萬一,對數(shù)據(jù)丟失或者產(chǎn)生垃圾數(shù)據(jù)，也可以用域本身對錯誤進(jìn)行標(biāo)記處理。建立審計維審計維和其他維類似，在ETL后臺處理中與事實表關(guān)聯(lián)。下圖是針對ShipmentInvoice事實表和與其相關(guān)的審計維的例子：ShipmentsFactAuditninien&ioiiOrder_d^H{FK；-T恤dit_御〔瑙Ship-ate(FK；'overallqirnlify聞it日邙_曲怕fFIQ/c*Kip5at￡nessShip佃恤厲1?tfa囲癲iiShip.to(瑞^ut-tjt-bQLindsPradiKUFK}/沉理e時tailedFramotiun/reciKdrnudifitdTerm!：(FKfStaiusWcleantin-E3t5nii>帥亦Lk斜tFK)?溯陽附Ei/nistopOrderjwm諭ETLpiastervfirsionShip.num(DO}allocatiflPversion(DD)currehi^詫「幻cmnuiriherunrtj；gm品一dolJafs山it汕臥dollarsmrEvent取川p仃陽1recordtoreachternsdoilerscistiiicl^udilcdiid^tnrevenbr.切l(wèi)Im巧reti^ri!_(lo3lars]pecbrdfweachshipmen!hr#item圖2:審計維樣例上圖中Shipment是一個典型的事實表，包含一大串的外鍵用來與維表關(guān)聯(lián),還有三個用DD標(biāo)示的退化維和6個數(shù)字的域。這是數(shù)據(jù)倉庫維模型設(shè)計中是一個典型的結(jié)構(gòu)。審計維包含事實表創(chuàng)建過程的元數(shù)據(jù)描述。數(shù)據(jù)質(zhì)量系統(tǒng)的設(shè)計人員可以選擇在錯誤發(fā)生時，保存獲得或多或少的元數(shù)據(jù)記錄。用上面的例子說明審計維表的產(chǎn)生產(chǎn)生過程。假如Shipment事實表每天以批操作的方式處理一次。今天運(yùn)行的非常好，沒有任何的錯誤紀(jì)錄或標(biāo)記。在這種情況下，只需要在審計表中生成一條審計紀(jì)錄。這樣，所有的錯誤信息對每一條事實記錄將是相同的，它的作用僅是表明今天的工作一切正常。

如果上面的假設(shè)不存在，運(yùn)行進(jìn)程或者數(shù)據(jù)常常發(fā)生問題，例如，折扣數(shù)據(jù)有問題，觸發(fā)了一個Out-of-Bound錯誤。就需要在審計維表中用一些信息來記錄發(fā)生的問題，需要考慮如何對錯誤條件和版本號選擇恰當(dāng)?shù)闹?，將錯誤問題的主外鍵關(guān)系進(jìn)行恰當(dāng)?shù)年P(guān)聯(lián)。更多的關(guān)于這方面的詳細(xì)信息請參閱《TheDataWarehouseETLToolkit2004》。在完成最終的審計報告時，看看下面的審計報表，會發(fā)現(xiàn)一些可愛的地方。如下圖：ProductShipFromOlyShippedRevenueAuonEast14^臨咖2249Instrbnifn^dRaptirl(addDut卅BoundsEndicatcrtoS￡lECT}productShipFroinO