文/通貫

【導讀】這是共四篇的資料倉庫治理系列，本文是第一篇。作者從實際經驗中，總結出了一些大型資料倉庫治理中，可能會遇到的問題。本文談到了“資料需求響應慢”的問題，大資料時代，你值得關注。

     資料倉庫是繼ERP之後失敗率最高的IT專案。在專案還沒立項的時候，會給老闆呈現各種美好。而實施到一定階段的時候，老闆會發覺太多的華而不實，要什麼沒什麼，做點變更比造航母還難。漸漸地，實施人員失去信心，老闆失去決心，減少投入。專案慢慢地陷入泥潭.....

      資料倉庫專案失敗的原因不外乎兩點：

        1）初級選型和架構不合理，不適應變化。

        2）就是缺少有效的治理。

    資料倉庫的治理就是預知和發現問題，然後控制問題不發生以及解決問題。

     大型資料倉庫治理，首當其衝的就是“資料需求響應慢”的問題。有如下場景：

     老闆把你叫過去：

    問：昨天成交額是多少

    答：我回去查一下，半小時後告訴你。

    老闆的心頓時涼了半截。這半個小時，對於你是多麼地緊迫，對於老闆確是度日如年。

    半小時後，你告訴他：數字是xxx億。

    老闆接著問：xx類目成家額是多少。

    答：半小時後....

    我們的現實情況可能比這還更糟，有些資料說不清，理還亂，一週都不一定能把資料算出來。

    資料倉庫是面向決策的，面向分析的。資料倉庫需要能快度的響應資料需求。如何解決這一問題呢？

    80%的資料需求是相對固定的，20%的需求是比較隨意的。相對固定的需求主要是業務的監控資料，例如: 某天UV多少,PV多少，收入多少。。。。，這些需求的指標是固定的，變化的只是維度組合，以及資料的粒度層次。舉個例子，以店鋪經業務為例，運營人員關心的指標無非是UV，PV，訂購人數，訂購金額，但是他們會從多個維度去看，如時間維度，店鋪星級，店鋪型別，主營類目。資料粒度指的是在某一維度上，要看到那個層次，以類目為例，是看一級類目呢還是葉子類目，以地域為例，是看省分佈呢還是到市級。我們可以將業務方常用的維度組合以及粒度層次開發成固定的報表，開發支援裁剪和鑽取的OLAP報表，提供靈活的維度和粒度組合查詢分析。

      80%的人日常工作中只關心1-2張報表，不超過10個指標。我們的資料中上有數千張報表，就算按照業務目錄查詢，找個資料都會非常困難。所以，儀表盤很重要，可以針對不同的業務開發不同的儀表盤，將使用者最關心的資料，用最直觀的方式展現出來。如果業務發展很龐大，儀表盤的使用者也很多，也會導致資料很凌亂，這時候就需要更加個性化的資料展現形式，即資料門戶。每個角色或者使用者都可以自定義自己關心的資料指標，放在一個簡潔的頁面中。

      另外20%的資料需求，沒有包含在報表，儀表盤和資料門戶中，需要case by case開發統計，費時費力。經過長期的總結會發現，這部分需求有如下的特點。首先是資料計算口徑較特別，例如月銷售額大於2000的賣家人數。其次，跨業務，例如統計訂購了小艾分析的量子使用者的銷售額區間分佈，包含了第三方產品訂購業務、量子業務，又包含淘寶主站業務。其次，依賴細粒度資料。需求的隨意性，導致必須從細粒度的資料中統計資料，需要考慮的口徑多，計算時間長。為了滿足這類需求，最好能提供一個快速自助查詢細粒度資料的平臺，將個性化的操作交給終端使用者，解放資料倉庫工程。

      上述內容，主要從資料展現產品的角度，將需求拆分為金字塔結構，分層次地提供多種資料產品，滿足資料需求。

       要實現上述目標，還需要搭建層次清晰資料倉庫模型，將資料分為細粒度、初步彙總、高度彙總的金字塔結構的資料層，分別覆蓋100%，90%，80%的資料需求。要求資料倉庫模型指標定義規範統一、層次分明、業務主題清晰、高度解耦。

來源：http://club.alibabatech.org/article_detail.htm?articleId=63