深入分析大資料時代中的資料倉儲技術
大資料背景
眾所周知,當前是一個資料爆炸的時代,大資料背景下的資料治理是每一個企業應該重點考慮的問題。例如金融機構、電信運營商這種“傳統”行業每日需要處理的資料量都已經十分巨大了,中小型網際網路公司都已經握著上千萬日活了,就更不要說騰訊,阿里這樣的網際網路巨頭。
傳統行業的資料治理
以電信運營商為例,一個省級的電信運營商在好多年前一年積累的資訊量就已經達到數個PB了,在資料爆炸的時代,我們透過移動網際網路隨時隨地就可以surfing everything,資料爆炸的程度估計可以用指數建模了。
而相比與網際網路企業,這些傳統行業企業的資料量的特點是:資料價值密度大,資料多呈結構化。這是與網際網路企業業務場景的不同之處。這也就意味著,使用大資料開源專案例如Hadoop等難以起到良好的儲存效果。
資料倉儲現狀
的區別大家想必早有耳聞,一個以資料分析為主,另一個以資料的增刪查改為主。資料倉儲既然以資料分析為主,沒有一個足夠的資料量談何分析?我們當前的時代,談到資料倉儲,就自然而然與大資料聯絡到一起,不然就會被認為是一個沒有價值的資料倉儲。
既然企業的資料治理這麼困難,那資料治理究竟是阿里巴巴、騰訊這樣的網際網路巨頭抑或是工行、移動、聯通這樣掌握著大量資料的500強企業們的專利呢?
答案也可以說是,也可以說不是。
所謂“是”的原因:
前面說到,傳統行業的資料倉儲應該以結構化的資料查詢為主,在這上面可以進行BI,生成報表,資料探勘等相關操作。而結構化的資料倉儲實現起來比非結構化的資料倉儲實現起來要困難很多(我自認為)。而開源產品中主要是面向非結構化資料的,諸如greenplum這種開源的結構化資料倉儲其也只能說是一個“廣告”性質的開源產品,畢竟greenplum是靠賣資料倉儲服務而生存的。而這些商用資料倉儲的價格不菲,以teradata資料倉儲為例,每年工商銀行要支付的費用要以億為單位來計算。
高價格就意味著,結構化資料倉儲很多傳統企業用不起,另一方面也沒有足夠的資料量進行支撐,而這些企業你懂得,很多好東西到他們手中,其實並不會用,因此這個答案是“是”。
另一方面也可以說“不是”,原因是:
資料爆炸時代,每個一定規模的公司都會積累一定的資料量,“大資料,小分析”是當前提到的一個概念。每個企業要想合理規劃未來,掌握客觀規律,不進行科技投入終歸是不太可行的。諸如此類公司,最大的困難估計是沒有人會用資料倉儲。不過,隨著雲端計算的興起,資料倉儲也已經上雲了,從技術角度看,比較好的雲上資料倉儲有阿里雲和華為雲兩種可供選擇,其他的從技術角度,客觀分析要比二者效能差。
資料倉儲的架構
當前,資料倉儲的架構主要可以分為兩種:一種是mpp架構,另一種是nosql形式的開源產品。
當今有一句話不知道大家知不知道“Nosql退場,newsql代表未來”。雖然話不能這麼說,但是newsql確實是一個很新的概念,而newsql所採用的架構大多數就是mpp架構。所謂的mpp便是大規模並行處理的意思,mpp架構資料庫除了支援傳統資料庫的acid事物,同時也支援叢集的線性擴充套件。而Nosql最大的不足就是不支援事務或者很弱。
mpp相比較於nosql資料庫,支援事物,支援sql語錄,支援表聯接(join)等複雜查詢,技術複雜度要比nosql高很多。nosql的優點是擴充套件性更強,因為mpp架構線上性擴容之後需要做資料的重分佈,這裡面技術很複雜,感興趣的比較多的話,我以後再開專題講解。
OLAP
提到資料倉儲,就要談論一個概念——OLAP,它的意思是聯機大規模資料處理,說白了就是進行資料分析的意思,與其相對的是OLTP概念。OLTP偏重於併發,側重CURD,例如線上支付、交易場景。OLAP偏重分析,側重查詢,資料探勘。從資料量上講,OLAP的資料量遠遠大於OLTP系統,OLAP對應著的就是資料倉儲,而OLTP對應著Oracle這類的資料庫。
現在的資料倉儲也好,資料庫也好,只要是滿足高可用場景,就不得不考慮分散式這個概念。
資料庫的分散式系統
OLAP與OLTP都是分散式系統,一個是分散式的資料倉儲,一個是分散式的資料庫。透過透過分散式來保障高可用,當然,這裡面也面臨著一致性的問題需要考慮。
對於OLAP資料倉儲系統來講,我們說過,他是用來對資料進行分析的,很多場景要求即席查詢秒級響應,這個要求是非常高的,感興趣的可以瞭解一下SQL on hadoop的工具Hive:去趟茅廁的功夫都搞不定。
這就要求分散式架構,同時OLAP還要儘可能地進行SQL語句解析,還要涉及到多表連線這樣複雜的業務,甚至還要支援事物,這時候mpp架構就派上用場了,nosql就比較弱了。而這同樣是HBase等開源專案難以實現的,但是後者畢竟是NoSQL,高擴充套件性是其生存的必殺技,因為我們前面說過mpp線上性擴充套件時需要作資料的重分佈,目的是為了保障能夠雜湊對映,還是很耗時的。
總結
有關資料倉儲的架構層面技術就講解到這裡了,這裡面涉及到的技術十分複雜,尤其是mpp架構。國內在專門研究mpp架構的廠商不多,大型一點的有阿里和華為在做研究,騰訊、百度貌似也有團隊在搞。相比於mpp架構,很多公司可以選擇開源軟體來實現自己的資料倉儲,一般用得多一點的是hbase,這主要是網際網路場景儲存一些結構化比較弱的資料,實際上更像是一種kv結構。但是對傳統廠商這種資料價值密度大的業務場景,就不得不考慮使用teradata等專業的資料倉儲了。
對大資料,機器學習,系統架構等領域感興趣的,可以看一下這個課程:
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/964/viewspace-2812469/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 大資料時代,資料倉儲究竟是幹嘛的?大資料
- 構建實時資料倉儲首選,雲原生資料倉儲AnalyticDB for MySQL技術解密MySql解密
- 資料倉儲與大資料的區別大資料
- 淺談資料倉儲和大資料大資料
- Bond——大資料時代的資料交換和儲存格式大資料
- 大資料時代的資料治理!大資料
- 大資料和資料倉儲解決方案大資料
- Oracle資料倉儲的實時資料採集XSOracle
- 資料湖是下一代資料倉儲?
- 深度揭祕:大資料時代企業賣技術還是賣資料?大資料
- 資料倉儲(8)數倉事實表和維度表技術
- 用Rust 實現的現代化實時開源資料倉儲Rust
- 大資料湖倉一體架構對分散式儲存有哪些技術需求?大資料架構分散式
- 資料庫倉庫系列:(一)什麼是資料倉儲,為什麼要資料倉儲資料庫
- 圖資料庫——大資料時代的高鐵資料庫大資料
- 關於資料湖、資料倉儲的想法
- 資料湖 vs 資料倉儲 vs 資料庫資料庫
- 到底什麼是實時資料倉儲?
- 大資料技術之大資料概論大資料
- 資料湖會取代資料倉儲嗎?
- 談談資料湖和資料倉儲
- 大資料技術 - Kyuubi大資料
- 大資料技術 - SuperSQL大資料SQL
- 大資料技術 - Directus大資料
- 大資料技術 - Druid大資料UI
- 大資料技術 - Ververica大資料
- 大資料技術 - Phoenix大資料
- 大資料技術 - Azkaban大資料
- 大資料技術 - Airflow大資料AI
- 大資料技術 - DolphinScheduler大資料
- 大資料技術 - DataX大資料
- 大資料技術 - Canal大資料
- 大資料技術 - Maxwell大資料
- 大資料技術 - Zookeeper大資料
- 大資料技術 - Hive大資料Hive
- 大資料技術 - Hbase大資料
- 大資料技術 - StarRocks大資料
- 大資料技術 - StreamX大資料