上週參與了大數據築基工程對現有數據平臺的對標分析工作，各廠家要分析出自己平臺的現狀、差距以及要未來要改進的點，從而爲築基工程制定出接下來的行動計劃。
通過分析，發現公司產品在數據清洗、數據質量以及數據分析方面的覆蓋度還是挺好，但在其它諸如統一安全、統一管理、數據共享等領域，則顯得有點單薄，當然這也與總體方案對這方面的規劃本身很超前也有關係。拋開其它方面不談，產品在數據質量、數據清洗這兩方面的滿足程度，應該與這個公司的歷史淵源、實踐案例有很大的關係。這兩個產品應該是繼承自td，已經有了多年的實踐，因此可以提煉出諸如數據質量檢查模板、檢查規則等這樣具有一定抽象性的概念，讓系統既能做到靈活配置，也具有極大的可擴展性。
但在這兩個月的熟悉過程中，我也感受到了現有產品的不足，藉着這次分析，對想法做了一定的歸納，主要包括以下幾點：
- 功能分散，相互之間的聯繫鬆散。像元數據、數據標準、數據質量和數據清洗，這幾個數據治理相關的功能，缺乏有效的配合，每個功能都以子系統的形式獨立存在，沒有有效融合爲整體。比如元數據管理，其中的表、字段、ETL等的元數據都可以做到導入、管理、查詢等，但並沒有爲數據質量、數據清洗等提供支撐。
- 功能的易用性不夠，系統過於“重”。所謂的過於重，是指現有的功能多數用於項目上線後的日常生產，對於項目前期的數據質量和清洗，仍然是以“人肉”的方式去完成，現有的工具不能提供有效的支持。造成這個局面的原因，包括功能配置繁瑣，使用不划算，也包括相關功能的深度不夠，不能爲實際工作提供幫助等。
- 系統缺少對項目實踐經驗的沉澱與積累的支撐，知識仍然停留在相關個人的腦子中，不能形成有效的共享。數據治理是大數據項目中的關鍵環節，也是工作量最大的環節，對項目成員的要求很高，經驗的多少直接影響到治理的效果。現在項目中的團隊成員，有幾個資深老手，擁有多年的項目實施經驗。在實際工作當中，一般是以這幾個成員爲主，牽頭組織相關任務的開展，比如，數據建模、數據入庫等，不過由於每個人的管理素養各不相同，導致任務的執行效率存在着較大的提升空間。
對於元數據、數據標準、數據質量、數據清洗這幾個工具，下圖是我認爲的相互關係流程圖：
通過上述流程，可以實現如下幾個目標：
- 打通功能孤島，形成完整功能。現有的幾個功能，更多是完成了其本職工作，用於應標、宣講問題不大，但應該發揮更多的作用，尤其是要將無形的”經驗“沉澱爲有形的功能中，比如，數據建模是不是可以用元數據管理起來，形成一個個的領域模型，對於新實施的項目，直接可以在已有領域模型的基礎上，直接導入形成物理模型，然後進行定製化的微調；
- 引入智能化，實現自動化。數據挖掘分析不僅僅可以用於業務場景，同樣也可以用於數據治理。比如，通過對字段名稱、表數據的分析，系統自動生成初步的數據質量檢查規則和數據質量報告，經人工審覈並調整以後，系統根據內置的清洗模板生成清洗任務及清洗流程，人工修改後部署上線。這個目標的實現，既需要將清洗經驗沉澱爲系統規則，同時也要利用語義分析、聚類算法等進行智能化的分析。數據治理自動化的實現，可以讓項目實施的重點，從編寫清洗腳本轉變化數據分析、提煉規則上來，除了提升實施效率之外，也能讓數據治理的效果更加可度量。同時，也可以讓團隊成員一定程度擺脫數據清的髒活累活，從工程師晉升爲分析師和行業專家；
- 數據治理的功能要從單獨部署的產品向“SAAS+產品”的方向演進，SAAS平臺是智庫，是前端工具的大腦，本地部署的產品是定製化的工具，經過裁剪後用於各行業的數據應用，支撐客戶的數據治理需求。經過項目的實踐積累，SAAS平臺中的規則不斷豐富，最終可以讓項目的複製越來越容易，項目實施可以像搭積木一樣，由業務專家通過挑選合適的組件完成數據治理。