資料治理的坑你遇到過幾個？
朱瑞 御數坊
5月23日
資料治理是一項長期而繁雜的工作，
很多時候大家都為如何做好資料治理而感到困惑，
甚至很多時候對此失去了信心。
筆者從事企業資訊化工作有11年以上的時間了，涉及資料治理相關的工作也有7年的時間。在這些年的實踐當中有成功的經驗，當然也經歷過很多失敗的教訓，有些教訓反反覆覆的出現…
我一直在思考怎麼避免這些問題，所以今天就跟大家分享一下我們曾經遇到過的坑，希望對大家會一些指導意義。
技術部門牽頭，大而全的管理
資料治理當前大部分的立項都是資訊科技部門，原因在於業務部門往往覺得資料治理和我沒什麼關係，技術部門大多是以資料中心或者大資料平台為出發點，受限於組織範圍，不希望擴大到業務系統，只希望把自已負責的範圍管好。
這種情況呈現出的狀態，即客戶遇到了資料質量的問題，也意識到要通過資料治理來解決，很多時候，客戶所立的專案就叫資料治理，殊不知資料治理是乙個很大的概念（這裡指廣義的資料治理），包括很多內容，想在乙個專案裡就做完是不可能的，很多人認為我們只做了元資料、資料質量、資料標準，內容不算多，但其實內容真的不少。很容易導致最後哪個也做不好，用不起來。
我們仔細分析一下客戶的問題。
第一，範圍不聚焦。有時候我們認為已經減少範圍了，就拿元資料為例。元資料管理的型別很多種，業務元資料、技術元資料、管理元資料三大類，技術元資料又包括：表、字段、檢視、儲存過程、作業、資料流向關係、作業依賴關係、索引、分割槽等幾十種技術元資料。從管理範圍講，管理系統的元資料範圍又很多，包括大資料中心各層、以大資料中心的上游**系統、下游的應用分析系統，很多公司有上百個資訊系統，每個系統裡上百張表，每張表兩三百個字段，其中還涉及到人工梳理的工作。如此大量的元資料，裡面還需要涉及到怎麼管，流程、人員、工具、制度規範等。這樣多的內容想乙個專案都做了，而且還沒討論資料質量、資料標準的內容，怎麼可能都做好，沒有辦法聚焦。況且就算花了很多錢，加班加點做了許多的工作，最後，所做的工作沒辦法短期見效，也得不到領導的認可，很難再開展二期的計畫，從而失去信心。
第二、需求不明確。很多客戶看似需求明確，其實是沒有想清楚自已真正想解決的問題。從我們的經驗看，以具體的資料問題或應用需求為出發點是比較合適的切入點，例如我們可以找資料質量問題比較突出的，反饋問題比較多的業務部門，收集資料質量問題，根據問題進行分析，最後發現導致這些問題的原因有資料標準的問題、元資料的問題、主資料的問題等，然後再根據這些問題去開展資料標準，元資料、主資料等工作。所展開的工作也是有方法的，例如梳理的資料標準範圍也僅是以這次問題所涉及的資訊項去做，最後這些問題得到了解決，也獲得了業務部門的認可，總結經驗，再逐步擴大範圍。
當然，很多時候，需求並不總是清晰的，如果想不清楚需求，建議先啟動乙個小型的諮詢專案，通過專業的團隊，大家一起找到切入點，其實很多時候並不是大家沒需求，只是需求是籠統的，模糊不清晰的，而單純的請來公司做交流，企業都是抱著自已的心思來的，都是有意引導到對企業自已有利的方向中，但真正是不是適合客戶自已的情況就不一定了，結果客戶聽了很多觀點，覺得自已經搞清楚怎麼弄了，其實不知道，資料治理哪能僅靠幾次售前交流就都能弄清楚的呢。就像近幾年為什麼付費內容這麼火一樣，免費的不一定就好，付費了，企業可以花費時間和精力幫助客戶找到真正目標，這樣才不致於後續花更多的錢來交學費。
業務部門牽頭，專做流程
傳統資料治理很多是資訊科技部牽頭來做的，但是往往效果不好，於是業務部門決定牽頭來做，那是不是業務牽頭就會好了呢？業務部門提出，要做全生命週期的管理，業務部門決定從流程入手，開始建立流程，從需求、設計、開發、測試、上線，運維，將所有環節都用統一的流程來管理。結果導致流程超級複雜，為開發人員實際增加了很多任務作量，遇到緊急需求，要求當天必須上線，於是領導一紙公文，跳過流程直接上線。最終的結果是：一方面由於增加了操作人員的工作量，另一方面領導沒有見到實效，於是逐漸邊緣化，最後束之高閣。
第一、全生命週期管理不是萬金油。其實，做資料的全生命週期管理沒錯，但問題是很多時候，業務人員只是單純的知道乙個名詞，對怎麼做資料治理沒有乙個完整的認識，只是按照自已想象的去做。那麼如何避免呢，是不是完全不要流程就是效率了呢？不是的，流程還是要做的，為了效率而不考慮後續的管理，會帶來更大的低效。例如說上線時etl流向關係設計資訊缺失，參考碼值沒有維護，導致後續業務變更時，難以理解之前的設計，業務變更困難，只能重新開發。
第二、做流程不要執念線上化。其實流程工具只是手段，他並不能約束人的活動，就像我可以不走流程直接上線，流程只能是提高我們工作效率的技術工具而，因此，建議先從線下流程開始，先把流程走通，不斷獲得反饋，不斷改進，當流程穩定下來後，再去做線上化的流程工具支撐，這樣做才能真正做到務實的管理。
第三、單一部門難落地。只有業務部門或技術部門部分參與也是不行的。我們知道資料是流動的，資料的問題涉及多個部門，僅有技術部門的參與是很難推動資料治理的活動，只有讓技術和業務部門都參與進來，以業務為導向，技術部門配合，才能夠達成較好的結果。例如以某幾個關鍵業務指標為切入點，針對這幾個指標加工資料流向所涉及的方面去梳理，結果是這幾個指標的資料質量得到了大幅提高，同時也積累了治理的經驗。
完全依賴工具，唯工具論
很多公司都認為，資料治理就是買一些工具，認為工具做好了，資料治理就沒問題了。結果是：一方面功能越做越多，另一方面實際上線後，功能複雜，大家使用不起來。其實這是錯誤的想法，資料治理本身包含很多的內容，制度規範、流程、組織、工具四項缺一不可，工具只是其中一部分內容，大家在做資料治理最容易忽視的就是組織人員，所有的活動流程、制度規範都需要人來執行、落實和推動，沒有對人員的安排，後續工作很難得到保障。一方面治理推廣工作沒人做，流程能否堅持執行得不到保障。另一方面沒有相關的資料治理培訓，導致大家對資料治理的工作不重視，認為與我無關，從而導致整個資料治理專案注定會失敗。建議大家在做資料治理的時候將組織人員放在第一位，有組織的存在，就會有人去思考這方面的工作，怎麼去推動，持續把事情做好，以人為中心的資料治理工作，才更容易推廣落地。
為了做資料標準而做標準
很多公司上來就說要做資料標準，卻不知道資料標準的全面梳理，範圍很大，很難以乙個專案的方式都做完，而且就算是花很大精力梳理，也沒辦法看到效果，結果是客戶只看到了一堆文件，這是最普遍的問題。
資料標準落地困難。很多客戶覺得資料標準落地難，問我怎麼能讓業務系統改標準，其實資料標準落地有幾個方法，有源系統落地、大資料中心落地、資料介面規範落地。要不要在源系統落地是取決於具體的資料標準問題，而不是泛泛的談論落地。企業資料標準的落地，應該細化到資料標準項，再分析其必要性，涉及面、重要程度等方面，只有把這些問題都搞清楚，才能夠做出改和不改的意義。例如有些字段客戶編號，涉及多個系統範圍廣、重要程度高、影響大，因此需要針對這個標準資訊項制定乙個可行的資料標準落地方案，如此才具有可落地的可行性。
企業做資料治理切忌貪大求全，要做小而精。把乙個具體的資料標準問題，從前到後都理清楚，真正把這乙個標準項所涉及的問題都理順，這樣乙個資料標準問題才能夠得到真正的解決。同時也要注意優先順序，因為資料標準問題很多，需要根據重要性、緊迫性來進行選擇。
總結一下
◾企業做資料治理，要避免大而全，要做小而精
◾業務部門與技術部門合作，協同推進資料治理工作
◾重視資料治理組織，避免唯工具論
◾要明確需求問題，不要盲目做資料標準
作者簡介
朱瑞，資深軟體架構師， 11年以上的it從業經驗，涉及資料治理相關經驗7年，曾從事過軟體開發、產品架構設計、系統整合、資料治理等工作。參與過銀行、通訊、電力、航空、**、物流等行業資料治理專案，在資料治理領域，擁有豐富的理論與實踐工作，注重實施落地，關注成果價值。
併發工具類的「坑」，你遇到過哪些？
在我們小夥伴與同事朋友討論時，我們有時會聽到有關執行緒安全和併發工具的一些片面的觀點和結論。比如 把 hashmap 改為 concurrenthashmap，就可以解決併發問題了呀 要不我們試試無鎖的 copyonwritearraylist 吧，效能更好 和 存在併發問題？加鎖就可以了呀 等等等...
處理資料（文字）時遇到過的坑
訓練詞向量時，本來就是準備好格式一定訓練文字，然後呼叫gensim開始訓練。但是訓練過程中出現了這樣的么蛾子，編碼坑 unicodedecodeerror utf8 codec can t decode bytes in position 4229 4231 invalid continuation...
微信支付遇到過的坑
首先先來看下圖 流程如下 後台獲取訂單資訊，生成簽名 簽名必須按照簽名規範，請參照 qq簽名前字串如下 注意 用md5加密後將字母轉為大寫 3.將簽名引數和生成的簽名轉為xml格式，如下 jsapi支付測試body 10000100mch id 1add1a30ac87aa2db72f57a2375...