前言
今天突然想了想這事，后面正好也在群里有了討論。所以這篇文章大體是做個(gè)總結(jié)。
夜間漫談
目前來(lái)看，從數(shù)據(jù)本身進(jìn)行各種轉(zhuǎn)換和查詢，大致分成三個(gè)類型：
- 明細(xì)查詢
- 聚合統(tǒng)計(jì)
- 關(guān)鍵字檢索
明細(xì)查詢大體是橫向行的查詢，聚合統(tǒng)計(jì)依托于列的縱向查詢。關(guān)鍵字檢索則是有別于1，2的一種數(shù)據(jù)獲取分析方式，作為人類三大信息來(lái)源之一的文字，關(guān)鍵字檢索是一個(gè)非常重要的從海量數(shù)據(jù)獲取自己想要的數(shù)據(jù)的方式。就目前我的感覺(jué)，人們通過(guò)關(guān)鍵字獲取到數(shù)據(jù)集之后可以在走1，2進(jìn)一步對(duì)數(shù)據(jù)做處理。
目前ElasticSearch可以覆蓋三類了，但是聚合統(tǒng)計(jì)還很弱，而且不支持SQL。CarbonData覆蓋前兩類,Parquet則只有第二類。
而就目前的使用熱度而言，理論上該是 ES> CarbonData > Parquet。 實(shí)際情況是，ElasticSearch當(dāng)之無(wú)愧是王者，其次是Parquet/ORC。CarbonData 則是新起之秀。
從對(duì)時(shí)間響應(yīng)的要求而言，又可以分成兩種：
- 傳統(tǒng)的BI報(bào)表以預(yù)計(jì)算為主，偏離線，對(duì)時(shí)間響應(yīng)要求并不高。
- 交互式查詢則更適合數(shù)據(jù)的探索，如果夠快，也可以作為BI報(bào)表的后端。
交互式查詢，我之前寫過(guò)一篇內(nèi)容，大體是說(shuō)如何秒級(jí)，甚至是毫秒級(jí)對(duì)海量數(shù)據(jù)進(jìn)行查詢是我們一直追求的一個(gè)夢(mèng)想。
