文末有50＋行業報告白皮書，9大行業分析指标體系，60 名企規劃PPT等福利

2004年筆者進入公司後就從事數據倉庫的工作，伴随着中國移動經營分析系統的發展而成長，主導過多次數據倉庫的重構建設，見證了數據倉庫從ORACLE到DB2、從DB2到ASTER、從ASTER到一體機、從一體機到GBASE、從GBASE拓展到Hadoop、再從Hadoop演進到實時數據倉庫的曆程。

這其中不僅僅有技術和認知，也有自己的故事，但時間就像一個沙漏，會讓存封的記憶變成沒有記憶，在沙子漏光之前，筆者還是想努力做些回憶，将其中的片段串起來分享給大家。

2004年畢業進公司的時候，那個時候還沒有所謂的高大上的數據倉庫，公司僅僅有個基于小機的Oracle報表數據庫，主要服務于公司的報表和取數。由于CRM/BOSS等源端系統都是Oracle數據庫，因此ETL是極其簡單的，直接DBLINK。

DBLINK在那個時代真是太強大了，也真是太方便了。

每次公司業務增加了一個數據庫，我們就會要求DBA給我們一個取數用的數據庫賬号，然後建個DBLINK就可以直接取數了（後來被禁止了，因為影響源端的穩定性），也可以在淩晨基于DBLINK抽取源端數據到報表庫後再取數。

你會發現那個時代我們的取數腳本往往會出現數不清的@jf，@zw，@kf，jf是計費數據庫的意思，zw是賬務數據庫的意思，kf是客服數據庫的意思，看看下面這個配置腳本是不是很熟悉？

如果Oracle一統天下，ETL就失去了意義，數據湖這個概念都不好意思提出來，因為沒有意義。Oracle DBLINK就是簡約而不簡單的代名詞，其生命力之強大令人發指，這是真正的技術集約化提升生産力。

即使到今天，我們的數據集市還留有源端系統的DBLINK後門，因為數據獲取快捷實時，可以小而美的解決一些問題，當然源端業務數據庫變成了BC庫或者容災庫，雖然DBLINK備受耦合的罵名。

那個時候還沒有建模的概念，但公司的報表、取數前輩已經基于實踐沉澱出了很多彙總表和寬表，當你的公司業務不夠複雜、數據量還不夠大的時候，談關系建模，維度建模都沒什麼意義，前輩創建的中間表就是一切，隻要能快速的滿足報表取數需求。

有了DBLINK和寬表，那麼Oracle時代最強大的Pass是什麼呢？

當然是PL/SQL Developer這個集成開發工具，其是專門開發面向Oracle數據庫的應用，PL/SQL叫做過程化SQL語言（Procedural Language/SQL），是Oracle數據庫對SQL語句的擴展，其在普通SQL語句的使用上增加了編程語言的特點，比如把數據操作和查詢語句組織在PL/SQL代碼的過程性單元中，通過邏輯判斷、循環等操作實現複雜的功能或者計算。

直到今天我們的大數據開發管理平台的很多設計理念都是直接借鑒 PL/SQL Developer。每次我都會對DACP的産品經理說，學習下 PL/SQL Developer的功能和體驗，直接抄也行啊，大多也源于我對PL/SQL Developer的感情吧，不過它的确太優秀了。

這裡貼一段以前做ALL表時的SQL代碼，各種decode，我的代碼生涯至少做過3000個類似的腳本。

再貼一段以前的存儲過程代碼，也很方便。

即使是現在，隻要企業的源端數據庫沒有去O，Oracle作為數據集市來講也是非常合适的，況且Oracle的一體機一點不含糊，應對一般的報表取數綽綽有餘。

在我進入公司的那一年，中國移動轟轟烈烈的經營分析系統1.0建設已經開始了，關于數據倉庫采用Oracle還是DB2當時存在路線之争。

建議用Oracle其實是非常務實的，因為Oracle的生态非常好，大家也都用習慣了，當然相對保守一點。

建議用DB2的則認為從全球來看其在數據倉庫領域占據領先位置（其實還有Teradata），而且Oralce畢竟不是為分析系統量身定做的，所謂OLTP和OLAP的區别。大家都會舉一個例子，DB2的count統計非常快。

我當時看到DB2這麼好的性能也挺驚訝的，覺得用DB2是正确的選擇，但後來發現如果從使用的全流程體驗來看，ORACLE性價比還是很高的，特别是當你的技術保障能力沒跟上的話，DB2就是個坑。

但無論如何，我們還是踏上了與DB2相伴的10年，愛恨情仇。

公司的第一代數據倉庫建設筆者趕上了末班車，數據倉庫采用的是2台IBM P595 DB2軟件，OLAP采用的是Hyperion Essbase（現在被Oracle收購了），BI報表是Brio，數據挖掘軟件采用的是IBM Intelligence Minner8.1。

昂貴而牛逼的P595

1、數據倉庫DB2

從實際使用情況看，如果說Oracle是個熱情的小夥子，那麼DB2肯定是個冷冰冰的小姑娘。

首先是性能，DB2跑彙總、關聯分析的确快，但它的并發不行，因為資源獨占太厲害，而且對錯誤的容忍度低，一不小心寫錯腳本就會跑挂機器，對于開發人員要求很高。

其次是ETL，自從引入了DB2，我們就開始體會ETL的繁瑣和痛苦，源端的Oralce要轉化成文本，再load進DB2，你得為他配備周邊的工具，大多要量身定做。

再次是可用性，DB2的RAC其實沒啥卵用，一個節點挂了切換到另外一個節點經常出現問題（記得不會自動切換），而且即使切換過去了性能下降起碼一半，實用性差了。

但無論如何，DB2的确是很穩定的，幾年都可以不出問題，但出了問題你就隻能去燒香了。

從技術保障的角度來看，DB2 DBA屬于稀缺人才，隻能慢慢培養，有大問題就得從上海，廣東調國内僅有的幾個IBM db2專家過來解決問題，最怕的是他們也搞不定，隻能層層打報告找美國實驗室的專家來解決，協調成本很高，這個以後再講。

最後是應用，DB2的技術特點決定了不大可能直接開放給一線人員使用，一來并發高了性能就大幅下降，二來代碼要求太高，一不小心搞塌機器，這個誰也吃不消。

DB2也沒有好用的開發管理工具，本身自帶的就不說了，好不容易找到了一個叫Quest的第三方客戶端工具，也是功能不全，然後我們重新開發了一個客戶端。

用慣了Oracle SQL的人再轉到DB2的一闆一眼的SQL，那真是欲仙欲死，學習成本太高了，取數的效率直線下降，因此基于Oracle的數據集市就興旺起來。

我們的數據倉庫從一開始其實就處于DB2和ORACLE共存狀态，核心倉庫模型跑在DB2上，而大部分亂七八糟的應用數據全部跑在ORACLE上，所謂的數據集市，包括報表庫、政企庫、地市庫、市場庫等等。

DB2是嬌貴的，Oralce是堅韌的。

2、BI工具

筆者現在用的是FineReport和FineBI，這兩個大數據分析平台對我們來說完全可以滿足需求。

以前我們長期使用Brio報表工具生成報表，圍繞Brio做了大量定制化的服務。

以前Brio報表數據的刷新是定時的，定時在9點刷新，即使數據在6點生成好了也沒用，有個合作夥伴的小夥子就把觸發式的刷新功能做出來了，厲害得很，後來跳槽了，現在在騰訊做到很高的職位。

還有就是财務部門希望每月定時把一大批報表自動導成excel推送給他們，因為要的報表太多了，不希望登錄到報表門戶一張張點開處理，這個時候就要brio做批量生成excel的功能。

我以前在文章中說，BI近年來沒多少長進，是指沒有發生什麼革命性的變化，諸如brio等早期的BI工具還有自身的特點，比如報表數據以bqy的文件方式存儲，你可以随意下載和拷貝，不需要登錄什麼服務，在任何一台有brio客戶端的電腦都能打開，然後做各種線下的拖拉鑽取報表操作。

但是現在被敏捷式BI如FineBI和Tableau取代了。

3、OLAP工具Hyperion Essbase

雖然那個時候企業購買了Hyperion Essbase，但對于Essbase的評價就是一句話：曲高和寡，主要體現在二個方面：

第一，多維分析不是企業使用的主要場景，有限維度的報表才是剛需，那個時候企業真正使用OLAP的人員不超過5個，這樣引入的OLAP的性價比就很低了。

第二，OLAP的确會快很多，但OLAP發布和維護的工作量有點大，比如在發布前，要有專門人員去設計CUBE打CUBE，如果增加了新維度還要重新打過，比較繁瑣。

OLAP在當時屬于那種叫的很響亮，但實際用得不咋滴的先鋒産品，生不逢時吧。

4、清晰的三層體系架構

第一代的數據倉庫體系架構如下圖所示，分為數據獲取層、存儲層和訪問層。

數據獲取層：将BOSS、MIS等外部數據源的數據進行清洗、轉換和加載到數據倉庫，關于ETL也有路線之争，其實我們真正做的是ELT，複雜的轉換全部是在庫内完成的。而且我們的ETL還有一個後門，就是數據集市Oracle直接通過DBLINK獲取源端數據，隐患還是挺大的。

數據存儲層：實現對數據倉庫中數據和元數據的集中管理，即DB2，并根據需要建立面向部門的數據集市（老的報表庫退化為數據集市），數據集市和元數據這麼早提出來也是非常有先見之明的，當然也隻是提出而已，并沒有完全落地。

數據訪問層：通過多樣化的前端展現工具，實現數據的分析，形成市場經營和決策工作所需要的業務信息和知識，采用的就是前面所說的Brio工具。

5、業務為王的九大主題

數據倉庫的第一個特點是面向主題(Subject Oriented)，中國移動經營分析系統業務規範1.0版本開篇所說的話很好的诠釋了對主題的理解：

“為适應日趨激烈的市場競争環境，提升中國移動的企業核心競争力，應充分利用業務支撐系統産生的大量寶貴的數據資源，建立移動經營分析系統，實現對信息的智能化加工和處理，為市場經營工作提供及時、準确、科學的決策依據”

“本業務規範包含對中國移動經營分析系統過的總體說明、基本層次結構、系統功能、專題分析、系統管理、外部系統的接口、指标要求等方面的内容，從功能上涵蓋了客戶發展分析、業務發展分析、收益情況分析、市場競争分析、服務質量分析、營銷管理分析、大客戶分析、新業務及數據業務發展分析、合作服務分析九大主題”。

這九大主題對于移動業務的抽象和概括是相當的全面和精準，非常具有前瞻性，後面所有的領域模型、邏輯模型、物理模型都是圍繞這九大主題展開的。

關于模型設計自己沒機會參與，因為剛進公司，啥都不懂，記得參加過幾次項目例會（亞信是當時的集成商），印象最深的就是亞信北京研發的數據模型專家在那邊讨論模型的設計方案，還有跟局方的争論，一些新的名詞不停的跳出來，什麼erwin、概念模型、邏輯模型、物理模型、ER圖，PDM等等，自己一頭霧水。

下圖是中國移動業務的概念模型。

下圖是其中的事件主題的邏輯模型。

第一代數據倉庫的建設持續了一年多，其實跟我沒多大關系，隻有使用上的一些體會，九大主題建設完成後最大的感受是可以用BI工具看報表了，但九大主題使用的人并不是很多。

現在很容易想明白原因，因為第一代數據倉庫基本還是技術驅動，雖然經營分析系統規範有集團公司的頂層業務規劃，但到了省公司業務人員參與度就低了，規範如何跟本地業務相結合一直是數據倉庫的巨大挑戰。

但無論如何，2005年是值得慶祝的一年，因為我們的數據倉庫起航了，從0到1總是有很大的意義。

首先請你評論區留言：學習，并關注轉發收藏！

然後點擊我的頭像，私信“數據治理”即可~

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!