但是在資料分析的領域，我們面臨的實際需求：
1. 存在大量業務資料來源，既有多個業務系統，也有業務系統的不同元件；
2. 既有結構化資料，也有半結構化、非結構化資料，存在著複雜的資料標準的問題；
3. 既有離線分析的需求，也有實時性分析的需求；
4. 預測性分析的需求；
5. 創造新的業務體驗的需求。
經常出現的局面是：
6. 資料採集反覆進行，給業務系統帶來巨大困擾；
7. 資料來源不完整，這幾乎是無法避免的現象；
8. 業務系統廠家配合度一般非常耗時，甚至已經不存在或人員不存在，設計文件交付缺失，一般無法精細化資料相關性；
9. 如果客戶需要新的分析結果，原有模型不能滿足時，就需要對理論上已經採集完成的資料進行再次建模和分析，此時無法保證資料一致性，最後不得不再去要求業務廠家的配合；
10. 開發階段，對於運維和資料的再利用考慮很少，業務開發人員一般不懂得資料分析的需要，也不具備資料分析能力，因此其資料組織形態可能較為原始，很少標註完善。
為了解決上述問題，需要建設“資料中臺”、“資料大腦”，這個和基本上屬於硬體能力建設的資料中心不是一碼事。
我們來看一下資料大腦DataOPS如何定義和實施：
FIG.1分析業務資料規律
如Fig1所示，業務系統所有產生的資料，可以分為兩類：業務記錄資料和系統執行的輔助性資料。輔助資料伴隨業務發生而建立，但往往是缺失的、間接的、不可逆的，分析起來很難搞。但是業務記錄資料則不會。如同人體，業務資料可看作是206塊骨骼、主動靜脈血管、八大系統，而輔助執行資料相當於毛細血管。我們可以設定一個小目標，或者是基礎目標，先把這個基礎目標達成。
再看FIG2，在業務系統依然線上執行、資料庫正常記錄的情況下，透過自動化分析“基礎設施-業務實體—資料記錄”三元相關性，採集資料，並同時完成自動化標註。
Fig2自動分析三元相關性
如此一來，在採集資料的同時，也完成了自動化標註，即同時完成了“資料預處理”。這就基本明確了資料大腦的技術架構。即肯定是資料庫+檔案系統的組合。這個資料庫不是業務資料的記錄，而是經過自動化標註的資料相關性倉庫。如fig3、fig4所示：
Fig.3
Fig.4
上述完整過程，類似於對業務資料記錄的“自動化解密”過程，建立起“特徵符號-資料”的關聯關係。從現代密碼學看，已經大量使用了高算力的自動化解密技術，因此是可行的。
DataOps本身應輸出完善的視覺化分析過程：
1. 採集了哪些系統（可能採取編號規則，不使用具體名稱）；
2. 每個時間週期（小時、天）採集了多少量，採集任務報警，很重要，否則無法保證資料連續性、一致性，後面的分析就無從談起；
3. 標註反覆出現的符號，實際上會是使用者ID、業務欄位、分組、業務類別等，這些都是系統開發時形成的。也可能出現升級改版時欄位變化的情況，但一般應該會把歷史資料繼承到新的欄位下，如果沒有繼承，也說明歷史資料業務上已經丟棄，那麼分析也不用管。業務人員可以協助資料分析師對結果進行確認和標註；
4. 何時不再發現重複性欄位、分組符號，此時表現為自動化分析過程完成了100%，應輸出完成報告；
5. 每個重複性欄位的資料通量趨勢、總量、變化速度；
6. 必要的資料型別轉換，如統一時間格式為相對時間等，以提高分析效率、減少記憶體佔用；
7. 具備搜尋引擎功能，需要把非結構化資料建立標籤，當然這是個相對獨立的功能需求，如果從相關性看，不是完全必要，但是資料大腦一般也會需要提供內容檢索的能力，因此有必要提供；
8. 空間佔用報告；
9. 資料開放能力，為開發各種微應用提供資料資源支援，這些微應用終於不再需要面對業務系統了！
10. 發現垃圾資料，如不再產生與重複符號關聯的資料增量，如測試使用者、測試資料、冗餘欄位。
結論：
自動化分析過程結束後，仍然可以定期執行。實際上這個過程是越來越快的，只是初始化分析會比較耗時。這樣建設的資料中臺，真正集自動化採集、自動化標註（預處理）、自動化建立相關性（Data Relevance）、資料有序儲存（注：不是自然儲存）、資料開放能力為一體。因此資料中臺的建設是必要的，但因為處於非常關鍵的位置，必須有科學的方法論，否則資料中心，成了“渾水”，只能倒掉、重新來過。
現在資料分析技術和業務系統開發還比較分離，這是有很大問題的。資料驅動應該是在業務系統設計階段就要採用的核心理念：在開發設計的階段，面向資料考慮問題，對資料輸出和資料展現進行深度研究，然後才是業務流程。這個方法論發展很快，也出現了一些設計工具。並對業務系統進行“左右腦設計”，左腦專管業務流程，右腦專管資料監控和分析，這個以資料驅動設計思想就很容易做到“建、維、分一體”，做到“系統智慧執行”，而不是固定流程的執行，對提升使用者體驗、改進系統、智慧運維三個方面都會有質的提高，成本也能節約三分之二以上，時間越長越是明顯。