主資料方法論之曆史資料梳理

主資料方法論之曆史資料梳理

主資料的曆史資料梳理工作，工作内容簡單，工作目的明确，是以部分的工作涉及的理論知識很少，需要探讨的問題也不多。但是恰恰是這部分工作占據了主資料管理項目實施工作的大部分時間。如何借助工具軟體，提高資料清洗工作效率則成為了該階段工作的重點内容，也是保證主資料管理項目利潤率的關鍵點。

資料梳理工作的對象:

每個主資料所對應的副本資料；

資料梳理工作目标:

n 一份完整的主資料；

最終得出一份完整的，沒有重複的，與現實狀況最相符的資料集合。

n 統一的副本資料

将副本資料與主資料不一緻的地方進行修改,使之與主資料保持一緻；

資料梳理手段:

n 資料排重引擎

n 人工幹預

下面介紹一個筆者在項目實施中開發的資料排重引擎，如果在公司内部應用內建項目中有應用需求，可以前來索取使用。

圖 首頁

JFrame做的東東，完全輕量化的，現在用的MySql庫。如果考慮安裝問題以後可以用一個記憶體資料庫或者直接用檔案。清洗的時候，感覺用直接用檔案做也會比較快。

圖 資料模組化

最開始的是主資料模組化了。這個小工具和UAP開發平台還不太一樣，因為主資料模型比較簡單，是以直接用模型描述了以後存在資料庫中的主資料系統資料庫中了。然後寫了一個描述引擎，把所有的主資料都轉化為内部的MDMdescrip對象和DataContener對象，這樣就可以直接在頁面使用了，不用重新開機的。因為小工具偏重排重引擎，是以沒在這方面下太大工夫，顯示模闆沒有配置，将就看吧。

圖 資料管理

預設的主資料管理頁面，實作簡單的增删改功能，沒有查詢的配置。

圖 Kettle副本資料導入

主資料注冊的時候有一個副本數量，系統預設為每一個副本生成以後存儲空間。隻要通過kettle工具将副本資料導入到清洗工具背景資料庫中就可以了。

圖 排重算法設計

排重算法設計是亮點啊，有兩個閥值，大于第一個閥值就算資料一樣了。小工具就自動處理了。第一個和第二個之間則需要人工手工幹預一下。小于第二個就算不同的資料可。可以為每個比對字段設定權值和算法。現在的算法還比較少，最近剛剛增加了一個帶分詞和語意判斷的。以後會根據項目需求随時添加，比如那個對郵件比對的，[email protected]和[email protected]就應當是一個人，這個屬于特殊情況，是以要在項目現場開發，以後通用的算法還可以有參數設定。這個算法庫以後是這個工具的最大價值。

圖 資料排重

對資料的排重，三千條資料大概用了48秒，頁面的清洗報告還不能實時滾動。而且所有的資料是一次讀到記憶體中的，碰到幾萬條的資料估計就要崩了，是以以後大資料量的要用檔案方式處理就沒問題了。

圖 排重結果處理

本身排重結果的處理應該分成兩種，一種是生成主資料，一種是副本資料與主資料一緻，這裡隻做了第一種。其實大部分情況是把處理報告導出來交給使用者去做，涉及到資料的問題都很關鍵，我們可确定不了。最後使用者處理好後，導入主資料系統就可以使用了。

轉載于:https://my.oschina.net/u/2244779/blog/322951