? ? ? ?在我從事數據這個專業多年以后，發現一個奇怪的現象，就是大多數搞數據管理的人，都在OLAP領域，而在浩瀚的OLTP領域，少有專業的搞數據管理的人，為什么？也許跟OLTP和OLAP的使命相關。企業為實現價值創造，從輸入客戶要求開始到交付產品及服務給客戶獲得客戶滿意并實現企業自身價值的E2E（端對端）業務過程是業務流。業務流是客觀存在的，每家公司在設計自身業務流程時都是想辦法要找到真實合理的業務流，去適配這個業務流。IT承載和使能的就是業務流，這里的IT就是OLTP，OLTP得讓流程順利run起來，而數據只是銜接流程各個環節的媒介，對于OLTP來說，業務流的治理是第一位的，至少開始的時候是這樣。OLTP說得最多的就是業務管理，本質就是確保業務流run起來的業務規則的管理，而數據的治理則無足輕重。OLAP即聯機分析處理，其要run起來跟業務流無關，只跟業務流記錄的數據有關，數據就是OLAP的生命線，為了讓數據分析的準確高效，OLTP需要高質量的數據，因此，OLAP說得最多的是數據管理，DAMA通過對數據管理活動的總結，形成了數據管理的方法論。

? ? ? ?自然而然的，數據倉庫成了數據管理方法實踐的最佳場所，你會發現，當前國內大多數企業的數據管理實踐，都發生在數據倉庫領域，從元數據、數據質量管理、參考數據、數據標準、數據開發、數據應用、數據安全再到數據架構，不一而足，甚至連主數據管理，大家都想的是在數據倉庫里搞一個，然后對外去提供服務。數據管理也好，數據治理也好，成了OLAP的專屬品。可惜的是，數據管理光有OLAP的參與，不僅是缺了一半的，而且先天不足，為什么？數據創造價值分為三個階段：數據產生，數據處理及數據消費，后面兩個跟OLAP相關，而第一個，只跟OLTP相關。很多公司數據價值創造過程受阻，不是OLAP不行，而是OLTP不行，因此，無論后端怎么努力，都是事倍功半，因為是根子出了問題。

? ? ? ?以數據架構為例：無論是數據模型、數據分布或是數據標準，OLTP當前都缺乏有效的管理，OLAP系統為了匯聚數據，只能一次又一次的采取項目化的方式對OLTP的系統進行梳理，并通過主題域、概念模型、邏輯模型、物理模型等模型來實現OLTP業務的重新抽象，美其名曰，OLAP是從分析角度看問題，需要不同的建模方式。但這些工作按道理是OLTP本身就該干的事情啊，業務理解永遠是老大，你離業務越遠，做事就越事倍功半。數據倉庫以前經常幾年要推倒重來一次，為啥呀，因為OLTP變了啊，OLAP以前的抽象不行了啊。現在OLTP領域DDD設計的興起，無論是領域，子域、限界上下文，實體、值對象等等，其實都是為了解決OLTP領域抽象太差的問題。差到什么程度？阻礙OLTP架構演進，影響了碼農的開發效率，但這種抽象，數據倉庫可一直都在做。

? ? ? ?又比如以數據質量為例：OLTP以業務流為核心的管理原則導致其幾乎不用關注自己留存的數據是否符合質量六性（完整性、及時性、準確性、一致性、唯一性和有效性），只要流程能運轉下去，業務繼續能開展，那數據質量就是最后需要考慮的事情，“垃圾數據進垃圾數據出”每天都在OLTP和OLAP中演繹。下游的OLAP除了擦屁股，也沒啥辦法，只能在報表指標上不斷內卷，除非指標數據爆了大雷。?

? ? ? ?OLTP在數據管理上的不作為不僅影響到了下游OLAP，隨著OLTP自身的發展，也開始對自身流程的運營效率產生影響。雖然每一段的OLTP流程都可以做到最優，但每一段的OLTP的流程也有自己的上游和下游，如果上游交付給你的數據不清晰，你就開始罵娘，因為要做大量的映射和轉換，但你在罵娘的同時，卻也很少想到要為你的下游交付清晰的數據。最后公司發現，從全局的角度看，這個業務流并不是最優的，流程存在大量的堵點卡點，最終影響了運營效率。

? ? ? ?可以看到，數據管理缺位的OLTP，不僅對下游的OLAP產生影響，而且開始反噬自身，更要命的是，在數字化的背景下，OLTP還需要OLAP給其變革的動力，這是很滑稽的事情。天下苦OLTP久矣！《華為數據之道》這本書的價值，并不在于技術牛逼，而在于頂層設計牛逼，其給出了全新的數據管理視角，可以這么說，它就是來解決OLTP的不作為而生的。為了克服OLTP基因的缺陷，那么好，就制定一本覆蓋所有領域的數據法律，確立一些數據管理的原則，比如華為數據管理總綱第一條：建立企業級信息架構，統一數據語言；第二條：所有變革項目須遵從數據管控要求，對于不遵從管控要求的變革項目，數據管控組織擁有一票否決權。

? ? ? ?OLTP既然事不關己高高掛起，那么好，就設立領域數據owner的角色，明確領域數據owner要為OLTP系統的信息架構、數據質量、數據入湖等負責，這意味著OLTP不僅要關注自己業務跑的爽不爽，也要關注別人爽不爽，無論是上下游的流程還是OLAP，這補齊了數據管理缺失的另一半。 OLTP的信息架構是數據管理的關鍵，那么好，就把信息架構的要求明確告訴你，即運營好數據目錄、數據模型、數據標準和數據分布四大組件，信息架構的構建方法論也告訴你，即基于業務對象進行信息架構的設計和落地。OLTP既然是很多數據管理問題的根源，那么好，數據管理的手段就盡量往OLTP前移。比如數據質量不是經常出現問題吧，干脆，把傳統的數據質量評估方法改了，除了執行階段數據質量的評估，將信息架構的設計質量也納入數據質量評估的范疇。比如匯聚數據不是不及時嗎，干脆，我給你制定一些入湖的規范，入湖的動作OLTP自己做吧，因為你最清楚數據的變更。既然OLTP對數據管理這么重要，在華為之前難道沒人知道這個道理嗎？當然不是，自己就曾經為推進OLTP系統的數據字典建立做過努力，但OLTP有理由不做，因為那個時候的業務流是老大。

? ? ? ?為什么現在華為提了，大家更多的會去思考這個問題了呢？原因可能有3個：第一、數據成生產要素了，大家對數據價值的認識更深刻了，OLAP的地位同步在提升，話語權在增加。 第二、數字化大勢所趨，OLTP要自我革命。 第三、華為給了一個最佳實踐，告訴大家，可以向OLTP開炮。