前幾天在數據產品經理的群里，有朋友提問“沒有數倉，沒有數據建模可以做好BI嗎”，今天把問題打開一下，不建設數倉，企業能做好數字化轉型嗎？
首先是能不能做的問題答案是可以，但不是長久之計，或者說，長遠來看做不好。企業不建設數倉，也可以使用數據。就像在大數據火爆之前，很多ERP系統也會提供基礎的數據統計分析報表。主要的做法業務系統的研發基于一些關系型的數據庫，通常為備份從庫。按照業務的指標統計邏輯進行數據加工和處理。曾經和我們公司財務部門溝通BI分析需求時，了解到他們就是這么干的。財務系統的操作數據庫是GP庫。（OLTP聯機數據處理，一般為了快速響應用戶的前端操作）為了滿足財務部門日常的數據報表需求，財務系統研發人員基于GP寫了很多的數據清洗任務，做了一堆的財務報表。
后來，財務研發找到大數據團隊，想學習大數據的處理流程和方法，因為他們過去直接基于OLTP的做法遇到了很多痛點問題。1.定制化開發數據沒法復用，需求做不完了因為每一個報表的邏輯是直接在關系型數據庫的基礎上，寫GP SQL的查詢邏輯，前端查詢時，直接輸出結果。有新的報表需求了，就要再寫一遍邏輯，或者copy一遍邏輯。2.查詢性能差，業務和老板天天吐槽技術不行最開始的時候，數據量比較小，都是內部人員使用的系統。但后來用戶量和分析的精細化，直接基于SQL邏輯進行大量的數據查詢，每次請求都要重新計算，性能非常差，可能一個報表要加載個5分鐘10分鐘。所以，在處理的數據量方面有著非常明顯的瓶頸。3.學習成本高，開發離職了沒人能接手工作直接基于OLTP的數據處理不僅在SQL邏輯上冗長復雜，而且有的是基于Java或者其他語言的代碼腳本，只有具備相關技術背景的人才能夠進行開發和維護。4.缺少數據資產沉淀，做完的需求就“不見了”因為加工邏輯是寫在接口當中，所以用戶端只能拿著輸出的報表結果進行后期分析和處理，想去更靈活的數據探查分析，幾乎是實現不了的。因為沒有結果數據沉淀下來。沒有資產沉淀，后期的智能化分析，AI應用就只能另起爐灶了，效率就非常低。5.運維成本高，業務系統迭代最痛苦比如，業務系統更新，需要調整指標統計邏輯。前端新增了一個頁面。這個時候，就要把所有涉及這個指標的報表邏輯全部去更新一遍。其次是數據倉庫能起到什么作用數據倉庫是一項基礎工程，需要花很長的時間以及人力成本進行資產的建設。有些公司的CTO或者業務團隊的管理者為了能夠快速的給老板匯報“大數據“效果，容易忽略數據基礎的建設。而只想要上層的應用。但是，經濟基礎決定上層建筑，欠的債遲早是要還的。曾經面試過一家公司，早些年的時候，為了追求業務的快速應用，忽略了數據倉庫的建設，現在還得回過頭來還技術債。因為在這個階段，數據的復用性以及數據輸出的效率已經成為數據團隊的最大痛點。’數據倉庫的主要思想是，首先需要把數據統一地從異構數據源（GP、Tidb、MySQL）等統一的匯聚，例如離線數倉一般是基于Hadoop架構的HDFS存儲。一是在數據量上，可以支持海量數據的查詢和分析，其次，數據邏輯ETL處理時，只需要學習簡單的Hive SQL即可。學習成本大大降低。甚至有的數據開發可能會覺得自己就是個寫SQL的沒啥技術含量。其次，數據按照業務的指標維度的需求加工處理后，常用的數據可以形成物理表，沉淀成數據資產，這樣不僅開發自身的可以復用，業務人員可以簡單的SQL查詢或拖拽式的分析。此外，數據倉庫的分層建設，也可以讓運維更加高效。比如，業務端新增頁面后，只需要修改最底層的ODS層的處理邏輯即可，下游的應用重跑或者第二天周期執行即可實現邏輯的自動更新。
所以，數據倉庫對數字化轉型的主要價值體現在降本和增效上。可以把散落在企業各個系統各個部門的數據匯聚，打破數據孤島。此外，隨著數據模型的完善，新增業務需求時，直接基于不同的模型進行關聯查詢，或者簡單的select from即可，可以大大的節省定制化開的時間。
數據應用和數據倉庫都不是新的名詞。不建數據倉庫也可以使用數據。但更多的是短期的應急方案。長遠來看，企業的數字化轉型響應獲得長久的成功，就必須重視數據資產的建設、數據資產管理、數據治理工作。