大資料背景

眾所周知，當前是一個數據爆炸的時代，大資料背景下的資料治理是每一個企業應該重點考慮的問題。例如金融機構、電信運營商這種“傳統”行業每日需要處理的資料量都已經十分巨大了，更不必說掌握著上千萬日活的網際網路公司。

傳統行業的資料治理

以電信運營商為例，一個省級的電信運營商在好多年前一年積累的資訊量就已經達到數個PB了，在資料爆炸的時代，我們通過移動網際網路隨時隨地就可以surfing everything，資料爆炸的程度估計可以用指數建模了。
而相比與網際網路企業，這些傳統行業企業的資料量的特點是：資料價值密度大，資料呈結構化。這是與網際網路企業業務場景的不同之處。這也就意味著，使用大資料開源專案–Hadoop等難以起到良好的效果。

資料倉庫現狀

資料倉庫與資料庫的區別大家想必早有耳聞，一個以資料分析為主，另一個以資料的增刪查改為主。資料倉庫既然以資料分析為主，沒有一個足夠的資料量談何分析？我們當前的時代，談到資料倉庫，就自然而然與大資料聯絡到一起，不然就是一個沒有價值的資料倉庫。
既然企業的資料治理這麼困難，那資料治理究竟是阿里巴巴、騰訊這樣的網際網路巨頭抑或是工行、移動、聯通這樣掌握著大量資料的500強企業們的專利呢？
答案也可以說是，也可以說不是。
所謂“是”，的原因：
前面說到，傳統行業的資料倉庫應該以結構化的資料查詢為主，在這上面可以進行BI，生成報表，資料探勘等相關操作。而結構化的資料倉庫實現起來比非結構化的資料倉庫實現起來要困難很多（我自認為）。而開源產品中主要是面向非結構化資料的，諸如greenplum這種開源的結構化資料倉庫其也只能說是一個“廣告”性質的開源產品，畢竟greenplum是靠賣資料倉庫服務而生存的。而這些商用資料倉庫的價格不菲，以teradata資料倉庫為例，每年工商銀行要支付的費用要以億為單位來計算。
高價格就意味著，結構化資料倉庫很多傳統企業用不起，另一方面也沒有足夠的資料量進行支撐，而這些企業你懂得，很多好東西到他們手中，其實並不會用，因此這個答案是“是”。
另一方面也可以說“不是”，原因是：
資料爆炸時代，每個一定規模的公司都會積累一定的資料量，“大資料，小分析”是當前提到的一個概念。每個企業要想合理規劃未來，掌握客觀規律，不進行科技投入終歸是不太可行的。諸如此類公司，最大的困難估計是沒有人會用資料倉庫。不過，隨著雲端計算的興起，資料倉庫也已經上雲了，從技術角度看，比較好的雲上資料倉庫有阿里雲和華為雲兩種可供選擇，其他的從技術角度，客觀分析要比二者效能稍差。

OLAP

提到資料倉庫，就要談論一個概念——OLAP，它的意思是聯機大規模資料處理，說白了就是進行資料分析的意思，與其相對的是OLTP概念。OLTP偏重於併發，側重CURD，OLAP偏重分析，側重查詢，資料探勘。從資料量上講，OLAP的資料量遠遠大於OLTP系統，OLAP對應著的就是資料倉庫，而OLTP對應著資料庫的類別。
現在的資料倉庫也好，資料庫也好，只要是滿足高可用場景，就不得不考慮分散式這個概念。

分散式系統

OLAP與OLTP都是分散式系統，一個是分散式的資料倉庫，一個是分散式的資料庫。通過通過分散式來保障高可用，當然，這裡面也面臨著一致性的問題需要考慮。
對於OLAP資料倉庫系統來講，我們說過，他是用來對結構化資料進行分析的，要求即席查詢秒級響應，這個要求是非常高的，感興趣的可以瞭解一下SQL on hadoop的工具Hive：去趟茅廁的功夫都搞不定。
這就要求分散式架構，同時OLAP還要進行SQL語句解析，還要涉及到多表連線這樣複雜的業務，甚至還要支援事物，這同樣是HBase等開源專案難以實現的。但是後者畢竟是NoSQL，高擴充套件性是其生存的必殺技。