OLAP系統(tǒng)在大數(shù)據(jù)時(shí)代的挑戰(zhàn)

OLAP系統(tǒng) 大數(shù)據(jù) 數(shù)據(jù)分析

博客 | 2016-07-22 11:07

【數(shù)據(jù)猿導(dǎo)讀】在大數(shù)據(jù)時(shí)代,人們迫切希望在由普通機(jī)器組成的大規(guī)模集群上能實(shí)現(xiàn)高性能的OLAP,然而系統(tǒng)性能的挑戰(zhàn)巨大。在涉及具體的技術(shù)前，先想一想為什么需要OLAP這樣的系統(tǒng)，可以帶來(lái)哪些價(jià)值，是直接變現(xiàn)還是間接變現(xiàn)。如果不能回答或回答不了，那么就是一個(gè)很大的問(wèn)題，這其實(shí)意味著數(shù)據(jù)的質(zhì)...

OLAP系統(tǒng)在大數(shù)據(jù)時(shí)代的挑戰(zhàn)

轉(zhuǎn)行做數(shù)據(jù)相關(guān)的工作有近兩年時(shí)間，除了具體技術(shù)，還有許多其它思考。

數(shù)據(jù)的價(jià)值

在涉及具體的技術(shù)前，先想一想為什么需要OLAP這樣的系統(tǒng)，它有什么價(jià)值或者說(shuō)在公司或部門(mén)這是不可取代的么? 可以帶來(lái)哪些價(jià)值，是直接變現(xiàn)還是間接變現(xiàn)。如果不能回答或回答不了，那么就是一個(gè)很大的問(wèn)題，這其實(shí)意味著數(shù)據(jù)的質(zhì)量存在問(wèn)題。沒(méi)有質(zhì)量的數(shù)據(jù)，體量再大也毫無(wú)價(jià)值。

數(shù)據(jù)存儲(chǔ)

假設(shè)已經(jīng)有很好的oltp系統(tǒng)，那么oltp系統(tǒng)在數(shù)據(jù)量不大的情況下，繼續(xù)扮演olap角色也還可以。一旦業(yè)務(wù)紅火，那么oltp中的analyze部分勢(shì)必會(huì)分離出來(lái)，也就是olap和oltp相互單獨(dú)存在。

olap中存儲(chǔ)大量歷史數(shù)據(jù)，數(shù)據(jù)存儲(chǔ)成了olap中要解決的第一個(gè)也是首要問(wèn)題，這個(gè)需求的解決方案有多種，可以是HDFS，也可以是NoSQL數(shù)據(jù)庫(kù)，也可以是Distributed RDBMS，當(dāng)中的取舍要視具體情況而定。后面會(huì)涉及具體的考慮維度。

數(shù)據(jù)同步和ETL

如何將數(shù)據(jù)從oltp遷移到olap，這個(gè)同步機(jī)制需要考慮數(shù)據(jù)一致性，zero data-loss, 實(shí)時(shí)性要求等等。

數(shù)據(jù)查詢

在大量甚至是海量的歷史數(shù)據(jù)中如何快速定位到所要符合條件的記錄? 數(shù)據(jù)量如果在TB級(jí)以上，就需要考慮使用solr或是elasticsearch

數(shù)據(jù)分析

花了好多代價(jià)保存下來(lái)的海量數(shù)據(jù)，只是用了做簡(jiǎn)單明細(xì)查詢，任何老板都不能容忍，一定要在歷史的數(shù)據(jù)進(jìn)行復(fù)雜的分析才行。這時(shí)候有一個(gè)好的分布式計(jì)算引擎就很有必要了。如spark/presto/impala

數(shù)據(jù)挖掘

數(shù)據(jù)挖掘是一種比數(shù)據(jù)分析更為復(fù)雜的數(shù)據(jù)分析，呵呵，個(gè)人理解，有些繞。這個(gè)時(shí)候什么算法啦，什么機(jī)器學(xué)習(xí)啦，可以上場(chǎng)了。

big data or fast data

數(shù)據(jù)分析中還需要考慮到另一個(gè)重要約束就是時(shí)間，如果希望分析結(jié)果愈快愈好，那么就需要采用如druid這樣的系統(tǒng)。

結(jié)果

如果數(shù)據(jù)規(guī)模在10TB以下，數(shù)據(jù)包含結(jié)構(gòu)化和半結(jié)構(gòu)化數(shù)據(jù)，明細(xì)查詢中條件比較固定，不存在全文搜索。需要在比較短的時(shí)間內(nèi)如秒級(jí)得到復(fù)雜分析結(jié)果，可以考慮使用distributed rdbms.

如果數(shù)據(jù)規(guī)模遠(yuǎn)遠(yuǎn)超過(guò)10TB，那么就需要將數(shù)據(jù)存儲(chǔ)/數(shù)據(jù)查詢/數(shù)據(jù)分析交由不同的系統(tǒng)來(lái)處理，這個(gè)時(shí)候就需要組成一個(gè)技術(shù)棧來(lái)解決總量。如HDFS/solr or elasticsearch/Spark or Presto or Impala. 為了提升分析的效率，除了從distributed computing engine側(cè)進(jìn)行優(yōu)化之外，還需要從存儲(chǔ)側(cè)進(jìn)行優(yōu)化，采用先進(jìn)的存儲(chǔ)格式如parquet/orc/carbondata將會(huì)極大的提升分析性能。

來(lái)源：博客

收藏分享

聲明：數(shù)據(jù)猿尊重媒體行業(yè)規(guī)范，相關(guān)內(nèi)容都會(huì)注明來(lái)源與作者；轉(zhuǎn)載我們?cè)瓌?chuàng)內(nèi)容時(shí)，也請(qǐng)務(wù)必注明“來(lái)源：數(shù)據(jù)猿”與作者名稱，否則將會(huì)受到數(shù)據(jù)猿追責(zé)。