有人說，數據倉庫搭建失敗的概率非常高，是ERP之後最不靠譜的大型項目之一。往往在項目立項的時候，我們會給老闆呈現出一幅非常美的願景圖：響應快、業務驅動、智能化……但當項目上線之後，纔會發現這個項目往往華而不實，要什麼沒什麼，慢慢的投入就會逐步減少，直到項目陷入泥潭……
那麼數據倉庫在搭建過程中，遇到的核心問題是什麼，我們又是怎樣應對這些核心問題的，今天就挑選三個代表性的問題，來進行一一的解答。
（一）痛點之一：需求響應速度慢
數據倉庫有“三多”的特點：參與人員多、業務關聯多、需求提出多，數據倉庫因爲承載了公司數據驅動的任務，往往會將所有業務的數據都接過來，進而導致了業務數據之間存在千絲萬縷的關係，變數越來越多，坑也就越來越多。爲了解決這個問題，我們會招聘很多的人，每個人獨立負責一個方向，但由於每個人的經驗背景不同，我們又需要制定一系列的開發規範，久而久之，整個數倉的規模就變的非常的龐大。
這時候，團隊已經出具規模，業務方也覺得我們應該通過數據做點事情了，於是就提過來了各種各樣的需求，壓力就來了。這裏描繪一個典型的例子：老闆提了一個需求，算一下昨天的業務成交額是多少，把你交了過去，你說：“我查一下哈，半小時後告訴你”。老闆一聽，心就涼了半截，對你而言，這半小時非常緊迫，開發任務、導出數據、測試準確性，要遵循的流程規範很多，但對於老闆，這半小時就度日如年了。半小時後，你告訴老闆，昨天成交額是XX億，老闆又問，那麼XX方向的金額是多少，你再次回答：“半小時後”，老闆吐血……現實情況可能更加魔幻，假設老闆提出了一個非常繞的問題，可能一個星期都不一定算得出數據。
那麼我們應該如何應對需求響應慢的問題呢？我認爲，這需要從需求本身出發，來分析需求的特點。
通常而言，80%的需求都是相對固定的，例如每天的各行業的PV、UV、訂單數、成交金額是多少，這些需求指標固定，只是在查詢的維度上有所不同， 那麼我們就可以將業務方常用的維度進行分析和再組合，開發固定的報表，放到DashBoard平臺上，業務方可以自助查詢。但這裏有個問題，大部分的業務方並不關心所有的數據是什麼樣子的，通常只會關心固定的十幾個指標，而我們的數據表有幾十上百張，找到想要的數據會變得十分困難。這個時候，數據的儀表盤和個性化功能就很重要了，如果業務方能夠自己定義想看的數據，再配合儀表盤直觀的展示出來，放到一個簡潔的頁面中，大家對你的評價可能就有所改變了。
針對另外20%的臨時需求，並沒有固定的查詢格式，很難放到DashBoard上，這個時候我們就需要針對這一類的需求做case by case的開發了。但這類需求通常也有一些可以分析的特點，例如計算的指標口徑比較特別、粒度比較隨意，甚至就是臨時起意的一些想法，這個時候，我們最好能工提供一種根據粒度做快速自助查詢的工具，通過sql的方式，讓業務方自己去查詢數據，解放數據工程師的人力。當然，不能直接讓老闆來查詢數據，但是可以建議老闆招聘幾個數據分析人員，同樣也是一種婉轉的解決問題思路。
爲了實現這兩種方式，我們數倉工程師要做的，就是搭建清晰的數據倉庫模型，講數據的粒度、維度、週期、過濾等基礎功能做好，並且指標統一、邏輯規範。s
（二）痛點之二：數據質量問題多
當我們基本能夠應對數據需求多的問題後，另一個問題就隨之而來了，數據質量問題多。通常這又分爲兩種情況：“數據爲什麼對不起來”、“數據是不是一定準確”。
先說“數據爲什麼對不起來”。我們經常接到業務方的質疑：今天的數據爲什麼漲了這麼多、這個數據爲什麼與後端的統計結果不一樣、今天的數據怎麼還沒有算出來……這一類的問題涉及的面比較多，一般而言有兩個問題會導致這個情況，一種是數據指標的計算過程不夠健壯，另一種是數據統計的口徑公司內沒有統一。當數據指標的計算過程不夠健壯時，數據就會發生一些波動，例如日誌新增了某種類型的數據，但ETL沒有做過濾，導致了指標統計結果偏多；再例如集羣中出現了慢SQL，導致了數據結果產出時間比平時晚很多。這裏涉及到的技術問題比較多，需要我們對數據計算的上下游有比較強的把控能力，一定做好與上下游的溝通機制，以便數據發生變化或出現異常的時候，能夠及時告知。另外，不同的數據團隊，或者是不同的業務部門，對於同一個指標的理解不同，是很正常的情況，某個過濾條件不同，就可能導致結果有比較大的差異。這個時候，除了數倉自身的標準化工作之外，也需要建立比較多元化的指標體系，例如搜索量，我們可以拆解成：直接搜索量、有廣告搜索量、有第三方廣告搜索量等多個概念，每個概念在頁面上清晰的標註統計條件和過濾方式，供需求使用方取用。
再說“數據是不是一定準確”，老闆問我們：“這個數據一定可靠嗎？我要拿出去跟投資人講。”這個時候，你可能就要猶豫許久了。這種問題要麼不出現，出現了就對於數據倉庫工程師是一種巨大的考驗，要做出堅定不移的回答，你需要如下兩方面的經驗做支撐：一個是對業務有清晰和正確的認識，時常看自己統計的數據，保持對於數據的敏感性，例如某天的成交額比平時多一些，你就要先於業務人員發現這個異常；另一個是具備良好的數據倉庫設計理念，對於統計過程有充分的信息，對於質疑數據準確性的情況，有充足的理由和完備的驗證過程，來做到“有禮、有節、有據”的迴應質疑。
（三）痛點之三：倉庫維護成本高
你能夠準時應答業務方的需求了，並且做到了數據質量可信，但某一天老闆又找到了你，這次是數據倉庫的機器成本太高了，需要削減一下，你又陷入了沉思。
不論從機房、服務器、計算資料、存儲成本各方面的維度來看，數據倉庫必然是一件高投入的事情，但是不是有高回報，卻並不取決於你的業務。因此，如何降低成本，是數據倉庫長期面臨的基本問題。爲了解決這個問題，我們需要從如下幾個方面入手：接口化、標準化及智能化。
接口化，核心思想便是，通過完善的數據倉庫結構，降低重複開發的概率，並且通過合適的接口層，對外提供統一的數據接口，對於節約機器資源非常有幫助。
標準化，即包括了開發行爲的標準化，也包括了指標計算的標準化。通常每個人針對需求，都有各自的開發方式，很容易產生慢sql等情況，影響計算資源。因此，針對常見業務指標的統計，應該有一套標準的開發方式，通過集體的力量，降低計算資源的消耗。
智能化，也指對於機器資源使用情況的統計，計算每個人、每個團隊的機器資源消耗情況，將消耗存儲資源多的表，或者是消耗計算資源多的任務拿出來，做專項優化，也是顯著降低成本的一種方式。
至於老闆一刀切的問題：“機器減半行不行？”或許可以吧……