(完整)數(shù)據(jù)中臺之結(jié)構(gòu)化大數(shù)據(jù)存儲設(shè)計_第1頁
(完整)數(shù)據(jù)中臺之結(jié)構(gòu)化大數(shù)據(jù)存儲設(shè)計_第2頁
(完整)數(shù)據(jù)中臺之結(jié)構(gòu)化大數(shù)據(jù)存儲設(shè)計_第3頁
免費預(yù)覽已結(jié)束,剩余5頁可下載查看

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認領(lǐng)

文檔簡介

1、(完整)數(shù)據(jù)中臺之結(jié)構(gòu)化大數(shù)據(jù)存儲設(shè)計(完整)數(shù)據(jù)中臺之結(jié)構(gòu)化大數(shù)據(jù)存儲設(shè)計數(shù)據(jù)中臺之結(jié)構(gòu)化大數(shù)據(jù)存儲設(shè)計一. 前言為何目前大多數(shù)企業(yè)都在構(gòu)建數(shù)據(jù)中臺的原因,數(shù)據(jù)處理的技術(shù)已經(jīng)是核心競爭力。在一個完備的技術(shù)架構(gòu) 大數(shù)據(jù)技術(shù)會逐步向輕量化和智能化方向發(fā)展,最終也會成為一個研發(fā)工程師的必備技能之一 ,而業(yè)務(wù)化:完成最基本的業(yè)務(wù)交互邏輯。規(guī)?;悍植际胶痛髷?shù)據(jù)技術(shù)的應(yīng)用,滿足業(yè)務(wù)規(guī)模增長的需求以及數(shù)據(jù)的積累. 智能化:人工智能技術(shù)的應(yīng)用,挖掘數(shù)據(jù)的價值,驅(qū)動業(yè)務(wù)的創(chuàng)新。向規(guī)?;椭悄芑陌l(fā)展,仍然存在一定的技術(shù)門檻。成熟的開源技術(shù)的應(yīng)用能讓一個大數(shù)據(jù)系統(tǒng)的搭 建變得簡單,同時大數(shù)據(jù)架構(gòu)也變得很普遍,

2、例如廣為人知的 Lambda 架構(gòu),一定程度上降低了技術(shù)的入門門的組合拼裝。每個組件各司其職,組件與組件之間進行上下游的數(shù)據(jù)交換,而不同模塊的選擇和組合是架構(gòu) 師面臨的最大的挑戰(zhàn)。本篇文章主要面向數(shù)據(jù)系統(tǒng)的研發(fā)工程師和架構(gòu)師,我們會首先對數(shù)據(jù)系統(tǒng)核心組件進行拆解,介紹每個組件下對應(yīng)的開源組件以及云上產(chǎn)品 .之后會深入剖析數(shù)據(jù)系統(tǒng)中結(jié)構(gòu)化數(shù)據(jù)的存儲技術(shù),介紹阿里云Tablestore 選擇哪種設(shè)計理念來更好的滿足數(shù)據(jù)系統(tǒng)中對結(jié)構(gòu)化數(shù)據(jù)存儲的需求。二. 數(shù)據(jù)系統(tǒng)架構(gòu)核心組件務(wù)邏輯,處理業(yè)務(wù)數(shù)據(jù)或應(yīng)用元數(shù)據(jù)等。數(shù)據(jù)系統(tǒng)主要對業(yè)務(wù)數(shù)據(jù)及其他數(shù)據(jù)進行匯總和處理,對接 BI、推薦或風(fēng)控等系統(tǒng)。整個系統(tǒng)架構(gòu)

3、中,會包含以下比較常見的幾大核心組件:關(guān)系數(shù)據(jù)庫:用于主業(yè)務(wù)數(shù)據(jù)存儲,提供事務(wù)型數(shù)據(jù)處理,是應(yīng)用系統(tǒng)的核心數(shù)據(jù)存儲。對接的核心組件,例如數(shù)據(jù)庫系統(tǒng)與緩存系統(tǒng)或搜索系統(tǒng)間的數(shù)據(jù)對接。也用于數(shù)據(jù)的實時提取,在 線存儲到離線存儲的實時歸檔。數(shù)據(jù)訪問需求。實時分析的能力.流計算:對非結(jié)構(gòu)化數(shù)據(jù)和結(jié)構(gòu)化數(shù)據(jù)進行流式數(shù)據(jù)分析,低延遲產(chǎn)出實時視圖。派生數(shù)據(jù)體系在數(shù)據(jù)系統(tǒng)架構(gòu)中,我們可以看到會存在多套存儲組件。對于這些存儲組件中的數(shù)據(jù),有些是來自應(yīng)用的直寫,有些是來自其他存儲組件的數(shù)據(jù)復(fù)制.例如業(yè)務(wù)關(guān)系數(shù)據(jù)庫的數(shù)據(jù)通常是來自業(yè)務(wù),而高速緩存和搜索引擎的數(shù)據(jù),通常是來自業(yè)務(wù)數(shù)據(jù)庫的數(shù)據(jù)同步與復(fù)制。不同用途的存儲

4、組件有不同類型的上下游數(shù)據(jù)鏈路,我們可以大概將其歸類為主存儲和輔存儲兩類,這兩類存儲有不同的設(shè)計目標,主要特征為:主存儲:數(shù)據(jù)產(chǎn)生自業(yè)務(wù)或者是計算,通常為數(shù)據(jù)首先落地的存儲。ACID 等事務(wù)特性可能是強需求, 檢索和分析做優(yōu)化。為何會有主存儲和輔存儲的存在?能不能統(tǒng)一存儲統(tǒng)一讀寫,滿足所有場景的需求呢?目前看還沒有 ,存儲引擎的實現(xiàn)技術(shù)有多種,選擇行存還是列存,選擇B+tree 還是 LSMtree,存儲的是不可變數(shù)據(jù)、頻繁更新數(shù)據(jù)還是時間分區(qū)數(shù)據(jù),是為高速隨機查詢還是高吞吐掃描設(shè)計等等。數(shù)據(jù)庫產(chǎn)品目前也是分兩類, TP 和 AP,雖然在往 HTAP 方向走,但實現(xiàn)方式仍然是底層存儲分為行存和

5、列存。數(shù)倉也是主與輔的關(guān)系,在線數(shù)據(jù)庫內(nèi)數(shù)據(jù)集中復(fù)制到數(shù)倉來提供高效的BI上圖我們可以看到幾個常見的數(shù)據(jù)復(fù)制方式:應(yīng)用層多寫這是實現(xiàn)最簡單、依賴最少的一種實現(xiàn)方式,通常采取的方式是在應(yīng)用代碼中先向主存儲寫數(shù)據(jù),后向 一是很難保證主與輔之間的數(shù)據(jù)一致性,無法處理數(shù)據(jù)寫入失效問題;二是數(shù)據(jù)寫入的消耗堆積在應(yīng)用層, 加重應(yīng)用層的代碼復(fù)雜度和計算負擔,不是一種解耦很好的架構(gòu);三是擴展性較差,數(shù)據(jù)同步邏輯固化在代 異步隊列復(fù)制這是目前被應(yīng)用比較廣的架構(gòu),應(yīng)用層將派生數(shù)據(jù)的寫入通過隊列來異步化和解耦。這種架構(gòu)下可將主 存儲和輔存儲的數(shù)據(jù)寫入都異步化,也可僅將輔存儲的數(shù)據(jù)寫入異步化.第一種方式必須接受主存儲

6、可異步 CDC(Change Data Capture)技術(shù)這種架構(gòu)下數(shù)據(jù)寫入主存儲后會由主存儲再向輔存儲進行同步 ,對應(yīng)用層是最友好的,只需要與主存儲打交道。主存儲到輔存儲的數(shù)據(jù)同步,則可以再利用異步隊列復(fù)制技術(shù)來做。不過這種方案對主存儲的能力 有很高的要求,必須要求主存儲能支持CDC 技術(shù)。一個典型的例子就是MySQL+Elasticsearch 的組合架構(gòu), ElasticsearchMySQLbinlogbinlogMySQLCDC派生數(shù)據(jù)體系是一個比較重要的技術(shù)架構(gòu)設(shè)計理念,其中CDC 技術(shù)是更好的驅(qū)動數(shù)據(jù)流動的關(guān)鍵手段。具備CDC了數(shù)據(jù)一致性設(shè)計的復(fù)雜度,從而來面向高速迭代設(shè)計???/p>

7、惜的是大多數(shù)存儲組件不具備 CDC 技術(shù),例如HBase。而阿里云 TablestoreCDC,CDCMySQL+ElasticsearchHBase+Solr大問題是,在解決CDC存儲組件的選型架構(gòu)師在做架構(gòu)設(shè)計時,最大的挑戰(zhàn)是如何對計算組件和存儲組件進行選型和組合,同類的計算引擎的 差異化相對不大,通常會優(yōu)先選擇成熟和生態(tài)健全的計算引擎,例如批量計算引擎 Spark 和流計算引擎FlinkSQL和NoSQLNoSQL下又根據(jù)各類數(shù)據(jù)模型細分為多類、對象存儲、文件存儲和高速緩存等不同類別。帶來存儲選型復(fù)雜度的 析等需求。有一些經(jīng)驗可以分享給大家:數(shù)據(jù)模型和查詢語言仍然是不同數(shù)據(jù)庫最顯著的區(qū)別

8、,關(guān)系模型和文檔模型是相對抽象的模型,而類 那選擇范圍能縮小點。)未知需求的擴展性更重要。另外關(guān)于數(shù)據(jù)存儲架構(gòu),我認為最終的趨勢是:數(shù)據(jù)一定需要分層數(shù)據(jù)最終的歸屬地一定是OSS結(jié)構(gòu)化大數(shù)據(jù)存儲關(guān)鍵需求大規(guī)模數(shù)據(jù)存儲入和輸出,必須要能支撐PB高吞吐寫入能力ETL須能支撐高吞吐的數(shù)據(jù)寫入,通常會采用一個為寫入而優(yōu)化的存儲引擎。豐富的數(shù)據(jù)查詢能力手段就是緩存和索引,其中索引的支持是多元化的,面向不同的查詢場景提供不同類型的索引。例如面向固 B+treeRtreeBKDtree存儲和計算成本分離的大數(shù)據(jù)系統(tǒng)下,存儲計算分離才能完全發(fā)揮優(yōu)勢。存儲計算分離在分布式架構(gòu)中,最大的優(yōu)勢是能提供更 靈活的存儲和

9、計算資源管理手段,大大提高了存儲和計算的擴展性。對成本管理來說,只有基于存儲計算分離架構(gòu)實現(xiàn)的產(chǎn)品,才能做到存儲和計算成本的分離。存儲和計算成本的分離的優(yōu)勢,在大數(shù)據(jù)系統(tǒng)下會更加明顯。舉一個簡單的例子,結(jié)構(gòu)化大數(shù)據(jù)存儲的存儲量會隨著數(shù)據(jù)的積累越來越大,但是數(shù)據(jù)寫入量是相對平穩(wěn)的。所以存儲需要不斷的擴大,但是為了支撐數(shù)據(jù)寫入或臨時的數(shù)據(jù)分析而所需的計算資源,則相對來說比較固定,是按需的。數(shù)據(jù)派生能力一個完整的數(shù)據(jù)系統(tǒng)架構(gòu)下,需要有多個存儲組件并存.并且根據(jù)對查詢和分析能力的不同要求,需要在數(shù)據(jù)派生體系下對輔存儲進行動態(tài)擴展 .所以對于結(jié)構(gòu)化大數(shù)據(jù)存儲來說,也需要有能擴展輔存儲的派生能力,來擴展數(shù)

10、據(jù)處理能力。而判斷一個存儲組件是否具備更好的數(shù)據(jù)派生能力,就看是否具備成熟的 CDC 技術(shù)。計算生態(tài)數(shù)據(jù)的價值需要靠計算來挖掘,目前計算主要劃為批量計算和流計算.對于結(jié)構(gòu)化大數(shù)據(jù)存儲的要求, 一是需要能夠?qū)又髁鞯挠嬎阋?例如 SparkFlink力,將自身數(shù)據(jù)轉(zhuǎn)換為面向分析的列存格式存儲至數(shù)據(jù)湖系統(tǒng);三是自身提供交互式分析能力,更快挖掘數(shù)據(jù)價值.滿足第一個條件是最基本要求,滿足第二和第三個條件才是加分項。開源產(chǎn)品HBaseCassandra,CassandraWideColumn類別下排名 Top1 的產(chǎn)品,在國外應(yīng)用比較廣泛 .但這里我們重點提下 HBase,因為在國內(nèi)的話相比Cassa

11、ndraHBaseHDFS 的存儲計算分離架構(gòu)的WideColumn數(shù)據(jù)存儲,它的優(yōu)點為:存儲計算分離架構(gòu):底層基于 HDFSSparkLSM社區(qū)很成熟,對接幾大主流的計算引擎。HBase 有其突出的優(yōu)點,但也有幾大不可忽視的缺陷:查詢能力弱提供高效的單行隨機查詢以及范圍掃描,復(fù)雜的組合條件查詢必須使用Scan+Filter 的方式,稍不注意就HBasePhoenixMySQL合最左匹配的查詢條件才能做索引優(yōu)化,可被優(yōu)化的查詢條件非常有限。數(shù)據(jù)派生能力弱CDCHBaseCDCHBase Replication CDC 的能力,但是僅為HBaseReplicationHBase 的CDC 技術(shù),

12、例如用于和SolrLily 和機制上分析就沒法做到CDC成本高,HBaseCPU CPU要達到完全的存儲與計算成本分離,只有云上的Serverless運維復(fù)雜HBaseHadoopZookeeperHDFS,沒有專業(yè)的運維團隊幾乎無法運維。熱點處理能力差HBaseRange PartitionHash PartitionHBase 提供了大量的最佳實踐文檔來指引開發(fā)者在做表的Rowkeyhash key,salted-tableRegionSplitMove國內(nèi)的高級玩家大多會基于HBaseHBase根據(jù)自身業(yè)務(wù)查詢特色研發(fā)自己的索引方案,例如自研二級索引方案、對接 Solr 做全文索引或者是

13、針對區(qū)bitmapTablestoreTablestore 是阿里云自研的結(jié)構(gòu)化大數(shù)據(jù)存儲產(chǎn)品,具體產(chǎn)品介紹可以參考官網(wǎng)以及權(quán)威指南。Tablestore 的設(shè)計理念很大程度上顧及了數(shù)據(jù)系統(tǒng)內(nèi)對結(jié)構(gòu)化大數(shù)據(jù)存儲的需求,并且基于派生數(shù)據(jù)體系這個設(shè)計理念專門設(shè)計和實現(xiàn)了一些特色的功能。設(shè)計理念Tablestore 的設(shè)計理念一方面吸收了優(yōu)秀開源產(chǎn)品的設(shè)計思路,另一方面也是結(jié)合實際業(yè)務(wù)需求演化出了一些特色設(shè)計方向,簡單概括下Tablestore 的技術(shù)理念:存儲計算分離架構(gòu):采用存儲計算分離架構(gòu),底層基于飛天盤古分布式文件系統(tǒng),這是實現(xiàn)存儲計算成本分離的基礎(chǔ)。LSM:LSMB+treeLSM好的支持

14、數(shù)據(jù)冷熱分層。Serverless 產(chǎn)品形態(tài):基于存儲計算分離架構(gòu)來實現(xiàn)成本分離的最關(guān)鍵因素是Serverless 服務(wù)化,只有 Serverless而平時可能僅需要比較小的計算能力,計算資源要足夠的彈性.另外在派生數(shù)據(jù)體系下,主存儲和輔存儲通 資源彈性可調(diào)。多元化索引,提供豐富的查詢能力:LSM 引擎特性決定了查詢能力的短板,需要索引來優(yōu)化查詢。而不同的查詢場景需要不同類型的索引,所以 Tablestore 提供多元化的索引來滿足不同類型場景下的數(shù)據(jù)查詢需求。CDCTablestoreCDCTunnel ServiceFlink擁抱開源計算生態(tài):除了比較好的支持阿里云自研計算引擎如MaxCo

15、mputeData Lake AnalyticsFlinkSpark流批計算一體:能支持Spark 對表內(nèi)全量數(shù)據(jù)進行批計算,也能通過CDC 技術(shù)對接 Flink 來對表內(nèi)新增數(shù)據(jù)進行流計算,真正實現(xiàn)批流計算結(jié)合。多元化索引Tablestore據(jù)分析,提供基本的統(tǒng)計聚合函數(shù),兩種索引的對比和選型可參考這篇文章。通道服務(wù)通道服務(wù)是 TablestoreCDC夠被利用在異構(gòu)存儲間的數(shù)據(jù)同步、事件驅(qū)動編程、表增量數(shù)據(jù)實時訂閱以及流計算場景 .目前在云上TablestoreBlinkBlink 的stream source大數(shù)據(jù)處理架構(gòu)大數(shù)據(jù)處理架構(gòu)是數(shù)據(jù)系統(tǒng)架構(gòu)的一部分,其架構(gòu)發(fā)展演進了多年,有一些基本的核心架構(gòu)設(shè)計思路產(chǎn)LambdaLambdaKappa、Kappa+等新架構(gòu)來部分解決 Lambda 架構(gòu)中存在的一些問題 ,詳情介紹可以看下這篇文章的介紹.Tablestore 基于CDCLambda 架構(gòu)設(shè)計了一個全新的Lambda plusLambda plus 架構(gòu)Lambda邏輯分別在流和批系統(tǒng)中實現(xiàn),并且在查詢階段合并流和批的計算視圖并展示給用戶?;赥ablestore TablestoreBlinkBlinkstream so

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論