說實在的，這個概念有些過于高大上，從大的方面包括、、強化學習等等，而深度學習又包括圖像識別、語音識別、自然語言處理、預測分析;機器學習則包括監督學習、無監督學習、半監督學習，監督學習又細分為回歸、分類、決策樹等等。理論上人工智能什么都能做，什么都能迎合的上。

　　關鍵數據質量管理實在太接地氣了，以至于大家都理解為數據質量檢查規則定義、數據質量檢查規則腳本、檢查規則執行引擎、數據質量檢查規則執行情況監控，數據質量檢查報告;而數據質量校驗規則無非就是一致性、準確性、性、真實性、及時性、關聯性、完整性的一堆校驗，再大白話一些無非就是語句。

　　而本人面臨的還不是基于數據倉庫的數據質量管理，數據倉庫是一個面向主題的、集成的、相對穩定的、反映歷史變化的數據集合，用于支持管理決策，數據倉庫的集成性和面向主題兩個特性決定了數據是有天然血緣關系的，血緣關系的存在是數據質量追溯的前提，能夠抽絲剝繭一層層梳理，簡而言之，目的性就是為了保障端到端的數據準確性。

　　剛入職電信運營商的時候，主要負責經營分析系統的流量業務和數據業務，初步統計過經分系統有七八千張表、幾千個存儲過程，從接口層到存儲層到中間表再到匯總層再到報表層，設計上倒也很合理，在不懂業務的情況下，為了快速上手，曾經花了3個月時間去閱讀一百來張中間表的數百個存儲過程，形成了幾份人肉血緣關系文檔，再過一年基本就可以設計數據模型了，這是個笨方法，但也是最快速的辦法。

　　入職新公司后，每年推陳出新一大堆新概念，但基本上落地的很少，數據中心、數字平臺、數據平臺、數據中臺、數據湖、物聯網服務器、人工智能服務器平臺，云化重構，昨天閱讀到一篇文章，說數據湖就是懶人數據倉庫，公司非常想挖掘現有和歷史的業務數據，但是還沒有詳細的規劃如何分析。所以需要先保存數據，在考慮以后的分析，畢竟對于很多公司來說，數據就是巨大的資產。畢竟數據湖既新潮又解決不了實際問題，而且、mpp既廉價容量又大，關鍵是規避了數據質量和企業數據模型，我想大概就是這個原因吧。

　　本人要面臨的是什么呢，一大堆業務系統，一些半集中化的報表系統，ETL工具五花八門，有ETL工具，有DBLink抽取的，有ogg同步的，業務系統之間靠主數據和SOA進行數據協作，就像任何早期系統一樣，初衷設計是好的，實際落地都會大打折扣，于是出現了數據質量問題，數據質量問題又分解為技術問題和數據問題，技術問題當然是追究系統建設的原因了，當然也無法追究，畢竟上線那么多年了，數據問題要追究業務部門錄入人員和使用人員的責任，就涉及到數據認責，數據認責又牽涉到各方利益，所以巴拉巴拉的。

　　但是工作還得做啊，盡人事聽天命嘛，個人認為數據質量問題短期內解決數據同源問題，長期目標是為了解決企業數據模型問題，畢竟數據質量核查過程是了解數據的過程，了解數據的過程就是不斷熟悉業務的過程，熟悉業務自然就會站在業務人員的角度去考慮企業數據模型問題。

　　前面是講了數據質量問題的目標，當然要數據質量問題不可避免要涉及到制度機制、平臺工具、運營團隊。

　　一、基于數據管理能力成熟度和公司數據管理過程中的問題制定一系列實際可操作可落地的數據管理制度。

　　二、關于數據認責，要基于業務場景開展嘗試，而不是胡子眉毛一把抓

　　三、建立一套綜合數據質量平臺，為數據質量提供自動、自助、智能化的平臺支撐，數據還是要集中的，不集中什么都治不了

　　四、搭建一套數據閉環管理流程，自下而上收集問題處理問題

　　五、有一套數據治理組織架構，這個一般雷聲大雨點小，那就從自我做起吧，一個數據運營團隊和相關分工還是要的。

　　搞到最后，還是少不了錢，有錢不是萬能的，沒錢是萬萬不能的，制度、平臺、團隊都是靠錢的。

　　前面講了一堆數據質量的事情，怎么解決ai服務器的問題呢？其實也借鑒了一些網上的部分，當然自己也反復思考，為了工作夜不能寐。

　　數據質量的問題主要發生在源端、傳輸過程和目標端，這話說起來容易，實施起來難，幾萬張表上百萬字段估計一輩子耗進去都脫身不出來，怎么辦，靠人工智能和浪潮服務器專家的經驗。