人工智能在數(shù)據(jù)質(zhì)量管理有什么樣的應用

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

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

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

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

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

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

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

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

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

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

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

　　四、搭建一套數(shù)據(jù)閉環(huán)管理流程，自下而上收集問題處理問題

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

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

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

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