大數(shù)據(jù)中臺架構(gòu)棧(存儲版)
【正文】 到較大的應(yīng)用程序中。可能是當(dāng)時 Google 有意改善業(yè)內(nèi)落后的現(xiàn)狀，讓大家稍微跟得上他的腳步才發(fā)布的論文…這么多年過去了，不知道 Google 內(nèi)部對數(shù)據(jù)的理解和使用又到了什么樣的高度。綜上所述，Spark是多樣化工作負(fù)載處理任務(wù)的最佳選擇。目前 OLAP 的查詢技術(shù)框架大致可分為三類：1. 基于 HBase 做預(yù)聚合：如 Opentsdb, Kylin 等，均需指定預(yù)聚合的指標(biāo)，在數(shù)據(jù)接入的時候進(jìn)行聚合運(yùn)算，適合相對固定，維度較多的業(yè)務(wù)報表類需求2. 基于 Parquet 做列式存儲：如 Presto, Drill，Impala 等，基本是完全基于內(nèi)存的并行計算，Parquet 系能降低存儲空間，提高IO效率，以離線處理為主，很難提高數(shù)據(jù)寫的實(shí)時性，超大表的 Join 支持可能不夠好3. 基于 Lucene 做外部索引：如 ElasticSearch，Solr 等，能夠滿足的的查詢場景遠(yuǎn)多于傳統(tǒng)的數(shù)據(jù)庫存儲，但對于日志、行為類時序數(shù)據(jù)，所有的搜索請求都也必須搜索所有的分片，另外，對于聚合分析場景的支持也是軟肋我們以常見的事實(shí)上，對于技術(shù)能力比較強(qiáng)的團(tuán)隊(duì)，可以針對這些開源系統(tǒng)進(jìn)行魔改，比如采用 Kylin 的預(yù)計算能力+Druid 的查詢引擎，來提高查詢的速度等等。SVG 全稱叫可縮放矢量圖，跟 HTML 一樣，有自己的命名空間，使用 XML 標(biāo)簽來繪圖。在 React 項(xiàng)目中實(shí)現(xiàn)常見圖表和自定義圖表。Metabase 則比較注重非技術(shù)人員（如產(chǎn)品經(jīng)理和運(yùn)營人員）的使用體驗(yàn)，讓他們能自由地探索數(shù)據(jù)，回答自己的問題，界面相對來講更加美觀。劣勢則是不支持分組管理報表，一旦報表多了使用起來很麻煩。ECharts 有完整的圖表封裝，開箱即用，而 G2 則是一套基于可視化編碼的圖形語法，以數(shù)據(jù)驅(qū)動，具有高度的易用性和擴(kuò)展性。這種軟件需要付費(fèi)，但都具備更豐富的可視化功能并提供一些技術(shù)支持，對于那些沒有精力折騰可視化的公司會是個不錯的選擇。據(jù)說 Kylingence 在前幾天的新品發(fā)布會上已經(jīng)解決了這個問題，拭目以待下圖引自快手在 OLAP 技術(shù)選型時的評價，以供大家參考：很多時候，在計算和查詢這塊沒有明顯的邊界區(qū)分。在不久的將來，相信 Flink 會像 Spark 取代 Storm 一樣，逐漸成為大數(shù)據(jù)處理技術(shù)的主流。該技術(shù)可以將數(shù)據(jù)流視作一系列非常小的“批”，借此即可通過批處理引擎的原生語義進(jìn)行處理。其他輔助工具上圖中的其他工具是為了保證整個大數(shù)據(jù)計算存儲系統(tǒng)更加健壯和開放，如 Zookeeper 提供了穩(wěn)定服務(wù)和 failover 機(jī)制，Sqoop 則為 Hadoop 提供了方便的 RDBMS（關(guān)系型數(shù)據(jù)庫）數(shù)據(jù)導(dǎo)入功能，使得傳統(tǒng)數(shù)據(jù)庫數(shù)據(jù)向 HBase 中遷
環(huán)評公示相關(guān)推薦
鄂ICP備17016276號-1