文|傅一平

2004年筆者進入公司后就從事數(shù)據(jù)倉庫的工作，伴隨著中國移動經(jīng)營分析系統(tǒng)的發(fā)展而成長，主導過多次數(shù)據(jù)倉庫的重構建設，見證了數(shù)據(jù)倉庫從ORACLE到DB2、從DB2到ASTER、從ASTER到一體機、從一體機到GBASE、從GBASE拓展到Hadoop、再從Hadoop演進到實時數(shù)據(jù)倉庫的歷程。

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

一、2004年，Oracle的美好小時代

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

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

每次公司業(yè)務增加了一個數(shù)據(jù)庫，我們就會要求DBA給我們一個取數(shù)用的數(shù)據(jù)庫賬號，然后建個DBLINK就可以直接取數(shù)了（后來被禁止了，因為影響源端的穩(wěn)定性），也可以在凌晨基于DBLINK抽取源端數(shù)據(jù)到報表庫后再取數(shù)。

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

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

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

那個時候還沒有建模的概念，但公司的報表、取數(shù)前輩已經(jīng)基于實踐沉淀出了很多匯總表和寬表，當你的公司業(yè)務不夠復雜、數(shù)據(jù)量還不夠大的時候，談關系建模，維度建模都沒什么意義，前輩創(chuàng)建的中間表就是一切，只要能快速的滿足報表取數(shù)需求。

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

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

直到今天我們的大數(shù)據(jù)開發(fā)管理平臺的很多設計理念都是直接借鑒 PL/SQL Developer。每次我都會對DACP的產(chǎn)品經(jīng)理說，學習下 PL/SQL Developer的功能和體驗，直接抄也行啊，大多也源于我對PL/SQL Developer的感情吧，不過它的確太優(yōu)秀了。

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

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

即使是現(xiàn)在，只要企業(yè)的源端數(shù)據(jù)庫沒有去O，Oracle作為數(shù)據(jù)集市來講也是非常合適的，況且Oracle的一體機一點不含糊，應對一般的報表取數(shù)綽綽有余。

二、2005年，DB2開啟了數(shù)據(jù)倉庫時代

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

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

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

我當時看到DB2這么好的性能也挺驚訝的，覺得用DB2是正確的選擇，但后來發(fā)現(xiàn)如果從使用的全流程體驗來看，ORACLE性價比還是很高的，特別是當你的技術保障能力沒跟上的話，DB2就是個坑。

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

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

昂貴而牛逼的P595

1、數(shù)據(jù)倉庫DB2

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

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

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

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

但無論如何，DB2的確是很穩(wěn)定的，幾年都可以不出問題，但出了問題你就只能去燒香了。

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

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

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

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

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

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

2、BI工具

筆者現(xiàn)在用的是FineReport和FineBI，這兩個大數(shù)據(jù)分析平臺對我們來說完全可以滿足需求。

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

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

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

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

但是現(xiàn)在被敏捷式BI如FineBI和Tableau取代了。

3、OLAP工具Hyperion Essbase

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

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

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

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

4、清晰的三層體系架構

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

數(shù)據(jù)獲取層：將BOSS、MIS等外部數(shù)據(jù)源的數(shù)據(jù)進行清洗、轉換和加載到數(shù)據(jù)倉庫，關于ETL也有路線之爭，其實我們真正做的是ELT，復雜的轉換全部是在庫內(nèi)完成的。而且我們的ETL還有一個后門，就是數(shù)據(jù)集市Oracle直接通過DBLINK獲取源端數(shù)據(jù)，隱患還是挺大的。

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

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

5、業(yè)務為王的九大主題

數(shù)據(jù)倉庫的第一個特點是面向主題(Subject Oriented)，中國移動經(jīng)營分析系統(tǒng)業(yè)務規(guī)范1.0版本開篇所說的話很好的詮釋了對主題的理解：

“為適應日趨激烈的市場競爭環(huán)境，提升中國移動的企業(yè)核心競爭力，應充分利用業(yè)務支撐系統(tǒng)產(chǎn)生的大量寶貴的數(shù)據(jù)資源，建立移動經(jīng)營分析系統(tǒng)，實現(xiàn)對信息的智能化加工和處理，為市場經(jīng)營工作提供及時、準確、科學的決策依據(jù)”

“本業(yè)務規(guī)范包含對中國移動經(jīng)營分析系統(tǒng)過的總體說明、基本層次結構、系統(tǒng)功能、專題分析、系統(tǒng)管理、外部系統(tǒng)的接口、指標要求等方面的內(nèi)容，從功能上涵蓋了客戶發(fā)展分析、業(yè)務發(fā)展分析、收益情況分析、市場競爭分析、服務質量分析、營銷管理分析、大客戶分析、新業(yè)務及數(shù)據(jù)業(yè)務發(fā)展分析、合作服務分析九大主題”。

這九大主題對于移動業(yè)務的抽象和概括是相當?shù)娜婧途珳剩浅＞哂星罢靶裕竺嫠械念I域模型、邏輯模型、物理模型都是圍繞這九大主題展開的。

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

下圖是中國移動業(yè)務的概念模型。

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

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

現(xiàn)在很容易想明白原因，因為第一代數(shù)據(jù)倉庫基本還是技術驅動，雖然經(jīng)營分析系統(tǒng)規(guī)范有集團公司的頂層業(yè)務規(guī)劃，但到了省公司業(yè)務人員參與度就低了，規(guī)范如何跟本地業(yè)務相結合一直是數(shù)據(jù)倉庫的巨大挑戰(zhàn)。

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