任何線上系統(tǒng)都離不開數(shù)據(jù)，有些數(shù)據(jù)是業(yè)務(wù)系統(tǒng)自身需要的，例如系統(tǒng)的賬號(hào)，密碼，頁面展示的內(nèi)容等。有些數(shù)據(jù)是業(yè)務(wù)系統(tǒng)或者用戶實(shí)時(shí)產(chǎn)生的，例如業(yè)務(wù)系統(tǒng)的日志，用戶瀏覽訪問的記錄，系統(tǒng)的購買訂單，支付信息，會(huì)員的個(gè)人資料等。大多數(shù)企業(yè)對(duì)內(nèi)，對(duì)外有很多這樣的線上系統(tǒng)，這些數(shù)據(jù)是驅(qū)動(dòng)業(yè)務(wù)發(fā)展，決策和創(chuàng)新最核心的東西。讓這些數(shù)據(jù)更好的支撐線上系統(tǒng)的是數(shù)據(jù)庫和數(shù)據(jù)分析平臺(tái)。
數(shù)據(jù)庫主要承擔(dān)的是線上系統(tǒng)的實(shí)時(shí)數(shù)據(jù)寫入和根據(jù)預(yù)定好的需求進(jìn)行查詢，嚴(yán)格說就是數(shù)據(jù)庫中的OLTP類型數(shù)據(jù)庫。這類數(shù)據(jù)庫中最為大家所熟知的就是Oracle和MySQL。業(yè)務(wù)系統(tǒng)對(duì)數(shù)據(jù)庫的要求可能是多樣的，近些年也由傳統(tǒng)的關(guān)系型數(shù)據(jù)庫融入了NoSQL數(shù)據(jù)庫和NewSQL。業(yè)務(wù)系統(tǒng)中除了和業(yè)務(wù)直接相關(guān)的數(shù)據(jù)存儲(chǔ)在數(shù)據(jù)庫中并累積起來外，還有海量的系統(tǒng)監(jiān)控?cái)?shù)據(jù)，系統(tǒng)業(yè)務(wù)日志產(chǎn)生。如果我們希望這些數(shù)據(jù)可以更持久的存儲(chǔ)并且做一些實(shí)時(shí)或者離線的分析，輔助我們的業(yè)務(wù)做決策，提供業(yè)務(wù)大盤和報(bào)表，很多公司會(huì)構(gòu)建自己的數(shù)據(jù)分析平臺(tái)。也就是時(shí)下『大數(shù)據(jù)』平臺(tái)的由來。這類平臺(tái)主要解決以下幾個(gè)問題：
1. 豐富的數(shù)據(jù)源支持和數(shù)據(jù)格式延遲綁定
豐富的數(shù)據(jù)源是因?yàn)檫@樣一個(gè)數(shù)據(jù)分析平臺(tái)是匯總我們各類業(yè)務(wù)數(shù)據(jù)的地方，數(shù)據(jù)源可能來自各類數(shù)據(jù)庫例如MySQL，MongoDB，日志源等等。這個(gè)平臺(tái)需要能夠方便各類數(shù)據(jù)源便捷的入庫，例如通常大家會(huì)發(fā)現(xiàn)大數(shù)據(jù)架構(gòu)中有一個(gè)Kafka，各類數(shù)據(jù)源會(huì)先進(jìn)入Kafka，再由Kafka推送到大數(shù)據(jù)的存儲(chǔ)系統(tǒng)中。這里Kafka就承擔(dān)了解耦大數(shù)據(jù)平臺(tái)的存儲(chǔ)接口和上游數(shù)據(jù)源的作用。數(shù)據(jù)格式延時(shí)綁定是一個(gè)很重要的概念，TP類數(shù)據(jù)庫往往需要根據(jù)業(yè)務(wù)需求預(yù)先定義Schema，也就是通常說的寫入型Schema，數(shù)據(jù)在寫入時(shí)即會(huì)做嚴(yán)格的數(shù)據(jù)字段類型檢驗(yàn)。但是分析系統(tǒng)并不希望因?yàn)镾chema約束或者限制的數(shù)據(jù)入庫，通常會(huì)采用讀取型Schema，也就是這里的延時(shí)綁定，數(shù)據(jù)在分析時(shí)才會(huì)根據(jù)數(shù)據(jù)類型做對(duì)應(yīng)的處理。
2. 存儲(chǔ)和計(jì)算彈性擴(kuò)展
存儲(chǔ)和計(jì)算彈性擴(kuò)展是指大數(shù)據(jù)系統(tǒng)需要能支撐海量數(shù)據(jù)和保持高吞吐的讀寫。數(shù)據(jù)分析平臺(tái)會(huì)匯總接納各類線上系統(tǒng)中的各類數(shù)據(jù)，同時(shí)數(shù)據(jù)會(huì)隨著時(shí)間進(jìn)行累積。大數(shù)據(jù)分析平臺(tái)能夠支撐海量數(shù)據(jù)的存儲(chǔ)是必須的，而且這個(gè)規(guī)模并不是預(yù)先定義好的，而是隨著數(shù)據(jù)的累積彈性增加的，這里的存儲(chǔ)量可能從TB級(jí)到PB級(jí)別，甚至數(shù)百PB。同時(shí)整套架構(gòu)的計(jì)算能力也一樣具備彈性，舉個(gè)直觀的例子，可能我們?cè)赥B級(jí)別做一次全量處理需要20分鐘，是不是到了百PB級(jí)別，處理時(shí)間也翻了好幾個(gè)數(shù)量級(jí)從而導(dǎo)致每天的分析結(jié)果不能及時(shí)產(chǎn)生，從而讓大數(shù)據(jù)平臺(tái)的價(jià)值大打折扣，限制了業(yè)務(wù)的飛速發(fā)展。
3. 大規(guī)模低成本
很多大數(shù)據(jù)平臺(tái)設(shè)計(jì)之初未必會(huì)意識(shí)到成本，主要依據(jù)自身對(duì)開源方案的熟悉度，業(yè)務(wù)方對(duì)數(shù)據(jù)規(guī)模和分析實(shí)效性進(jìn)行方案的選取。但當(dāng)業(yè)務(wù)量真的起來后，不得不面臨一個(gè)挑戰(zhàn)就是大數(shù)據(jù)平臺(tái)的成本問題。這里甚至?xí)?dǎo)致不得不進(jìn)行平臺(tái)的架構(gòu)改造或者數(shù)據(jù)遷移。所以對(duì)于企業(yè)的大數(shù)據(jù)平臺(tái)設(shè)計(jì)之初，我們就需要把整套架構(gòu)的成本考慮進(jìn)來。這對(duì)應(yīng)的就是數(shù)據(jù)的分層存儲(chǔ)和存儲(chǔ)計(jì)算引擎的選取。時(shí)下云上的大數(shù)據(jù)平臺(tái)往往最終會(huì)選擇一個(gè)可擴(kuò)展，低成本的存儲(chǔ)平臺(tái)落地最終的數(shù)據(jù)，例如阿里云上的OSS或者AWS的S3，這些存儲(chǔ)平臺(tái)本身也支持進(jìn)一步的分層存儲(chǔ)。這類存儲(chǔ)之上的計(jì)算平臺(tái)可以選取Elastic MapReduce方案。整套架構(gòu)就組成了時(shí)下火熱的『數(shù)據(jù)湖』方案。在線下用戶可能會(huì)自建一個(gè)Hadoop集群，并使用HDFS來存儲(chǔ)這些匯總的數(shù)據(jù)，進(jìn)而構(gòu)建自己的大數(shù)據(jù)數(shù)據(jù)倉庫。
4. 在線業(yè)務(wù)和分析業(yè)務(wù)隔離
隔離是因?yàn)榉治鰳I(yè)務(wù)往往需要掃描較多的數(shù)據(jù)進(jìn)行分析，這類大流量的掃描如果是發(fā)生在在線庫，可能會(huì)影響線上服務(wù)的SLA。同時(shí)分析流量的訪問模式和在線模式未必相同，在線庫數(shù)據(jù)的存儲(chǔ)分布和格式也未必適合分析系統(tǒng)。所以一般典型的大數(shù)據(jù)平臺(tái)會(huì)有自己的一份存儲(chǔ)，數(shù)據(jù)分布，格式和索引會(huì)面向分析需求而做相應(yīng)的優(yōu)化。例如典型的TP類引擎的存儲(chǔ)格式往往是行存，分析的時(shí)候會(huì)轉(zhuǎn)變成列存。
介紹到這里，希望引導(dǎo)大家來思考這樣一個(gè)問題，不論是傳統(tǒng)的數(shù)據(jù)倉庫，還是云上的數(shù)據(jù)湖，我們最終還是希望可以有效的解決業(yè)務(wù)中數(shù)據(jù)存儲(chǔ)和分析的問題。那究竟業(yè)務(wù)需求是什么，尤其是當(dāng)我們希望分析數(shù)據(jù)源是數(shù)據(jù)庫，日志監(jiān)控這類結(jié)構(gòu)化或者半結(jié)構(gòu)化數(shù)據(jù)時(shí)，對(duì)大數(shù)據(jù)平臺(tái)的需求是什么呢？我想這里大家可以先思考一下，后面我們會(huì)和大家一起看看時(shí)下一些主流的開源方案和云上的構(gòu)建方案，然后再來總結(jié)下結(jié)構(gòu)化大數(shù)據(jù)存儲(chǔ)和分析的需求。
開源大數(shù)據(jù)存儲(chǔ)分析平臺(tái)架構(gòu)
前面我們提及線上業(yè)務(wù)的實(shí)現(xiàn)離不開OLTP數(shù)據(jù)庫的支持，來實(shí)現(xiàn)實(shí)時(shí)的數(shù)據(jù)讀寫。這一章我們一起看看，開源和云上一些主流的組合數(shù)據(jù)庫和大數(shù)據(jù)分析平臺(tái)的架構(gòu)。
Hadoop大數(shù)據(jù)方案
方案一：Uber Hadoop大數(shù)據(jù)架構(gòu)
我們以Uber的一套大數(shù)據(jù)架構(gòu)為例，圖中展示了各類數(shù)據(jù)庫通過Kafka推送到Hadoop集群中進(jìn)行全量批計(jì)算，結(jié)果集合會(huì)再寫入幾類存儲(chǔ)引擎中進(jìn)行結(jié)果查詢展示。
在傳統(tǒng)的Hadoop架構(gòu)中，各類結(jié)構(gòu)化數(shù)據(jù)例如日志數(shù)據(jù)通過采集管道進(jìn)入Kafka，Spark 可以實(shí)時(shí)的消費(fèi)Kafka的數(shù)據(jù)寫入集群內(nèi)的HDFS中。數(shù)據(jù)庫例如RDS中的數(shù)據(jù)會(huì)使用Spark定期全量掃表同步到HDFS，通常周期是一天一次，在業(yè)務(wù)低峰期進(jìn)行同步。這樣使用HDFS存儲(chǔ)匯總了用戶的數(shù)據(jù)，對(duì)數(shù)據(jù)庫數(shù)據(jù)而言其實(shí)是一個(gè)定期的snapshot。例如每天的凌晨會(huì)把行為日志與數(shù)據(jù)庫中用戶的信息進(jìn)行聯(lián)合的分析，產(chǎn)生當(dāng)天的分析報(bào)告比如包含當(dāng)天訪問量匯總，用戶的消費(fèi)傾向等報(bào)表數(shù)據(jù)，給業(yè)務(wù)負(fù)責(zé)人決策使用。架構(gòu)中之所以說RDS的數(shù)據(jù)是全量入庫，主要原因是HDFS本身只是一個(gè)分布式文件存儲(chǔ)，對(duì)Record級(jí)別的更新刪除并不友好。所以為了簡(jiǎn)化這些數(shù)據(jù)庫中的合并修改刪除邏輯，在數(shù)據(jù)規(guī)模不大的情況下會(huì)選擇全量掃描。當(dāng)數(shù)據(jù)庫數(shù)據(jù)較大時(shí)，例如Uber的架構(gòu)中，基于HDFS開發(fā)了一套存儲(chǔ)引擎來支持修改和刪除。
這套方案的特點(diǎn)是，分析時(shí)數(shù)據(jù)已經(jīng)是靜態(tài)，借助于Hadoop集群的高并發(fā)能力，可以較為容易的實(shí)現(xiàn)百TB到PB量級(jí)行為數(shù)據(jù)的離線計(jì)算和處理，同時(shí)數(shù)據(jù)大塊的存儲(chǔ)在HDFS上，綜合存儲(chǔ)成本也相對(duì)較低。美中不足的是數(shù)據(jù)是定期入庫，數(shù)據(jù)計(jì)算的時(shí)效性通常是T+1。如果業(yè)務(wù)方有近實(shí)時(shí)推薦的需求，這時(shí)架構(gòu)會(huì)從離線計(jì)算升級(jí)到『Lambda架構(gòu)』。架構(gòu)如下圖:
Lambda架構(gòu)
具體細(xì)節(jié)可以參考Lambda介紹。
通過HDFS全量存儲(chǔ)和Kafka存儲(chǔ)增量來實(shí)現(xiàn)離線和實(shí)時(shí)兩類計(jì)算需求。本質(zhì)上HDFS存儲(chǔ)的全量仍然是T+1式的。但是通過Kafka對(duì)接流計(jì)算彌補(bǔ)實(shí)時(shí)計(jì)算的需求。也就是多了一份存儲(chǔ)和計(jì)算邏輯實(shí)現(xiàn)業(yè)務(wù)實(shí)時(shí)性的需求。
不論是傳統(tǒng)離線分析架構(gòu)還是Lambda架構(gòu)，結(jié)果集合可能仍然比較大，需要持久化在一個(gè)結(jié)構(gòu)化存儲(chǔ)系統(tǒng)中。此時(shí)的存儲(chǔ)主要做為結(jié)果集合進(jìn)行查詢，例如實(shí)時(shí)大盤，報(bào)表，BI業(yè)務(wù)決策人員的即席查詢等。所以主流的做法是把結(jié)果寫入RDS然后同步至Elasticsearch或者直接寫入Elasticsearch，這里主要希望借助于ES強(qiáng)大的全文檢索和多字段組合查詢能力。
分布式NoSQL數(shù)據(jù)庫方案
方案二：基于分布式NoSQL數(shù)據(jù)庫Hbase的大數(shù)據(jù)架構(gòu)
之前的架構(gòu)我們不難發(fā)現(xiàn)，RDS在做批計(jì)算的時(shí)候需要同步至HDFS形成靜態(tài)數(shù)據(jù)做批計(jì)算。這樣的架構(gòu)可能會(huì)遇到一個(gè)場(chǎng)景，全量數(shù)據(jù)很大，每天全量同步，時(shí)效性很差甚至如果資源不夠會(huì)同步不完，如何優(yōu)化這個(gè)問題呢？我們不難想到如果數(shù)據(jù)倉庫本身就是一個(gè)數(shù)據(jù)庫，直接支持CRUD操作，那豈不是不需要同步全量！甚至部分在線數(shù)據(jù)可以直接寫入這個(gè)海量數(shù)據(jù)庫中，沒錯(cuò)業(yè)界很多開源方案會(huì)基于分布式的NoSQL數(shù)據(jù)庫例如Hbase來打造這個(gè)架構(gòu)。上圖就是一個(gè)簡(jiǎn)單的實(shí)例。Hbase schema free以及支持實(shí)時(shí)的CRUD操作，大大簡(jiǎn)化了數(shù)據(jù)源數(shù)據(jù)的實(shí)時(shí)寫入，同步問題。同時(shí)可以跨數(shù)據(jù)源打造大寬表，大寬表會(huì)大大降低計(jì)算時(shí)通過join構(gòu)建完整數(shù)據(jù)的復(fù)雜度。同時(shí)Hbase組合Kafka也可以實(shí)現(xiàn)Lambda支持批和流兩類需求。那這種架構(gòu)是完美的么？可以完全替換方案一么？
答案肯定不是，一方面Hbase為了支持好實(shí)時(shí)的數(shù)據(jù)寫入，是采用了LSM存儲(chǔ)引擎，新數(shù)據(jù)通過追加的方式入庫，數(shù)據(jù)更新和合并依賴后臺(tái)的合并優(yōu)化減少讀操作。這類支持?jǐn)?shù)據(jù)引擎的數(shù)據(jù)讀寫成本是要高于直接讀寫HDFS靜態(tài)文件。另一方面Hbase數(shù)據(jù)落盤的存儲(chǔ)格式是按行進(jìn)行組織，也就是我們通常說的行存儲(chǔ)。行存儲(chǔ)在數(shù)據(jù)的壓縮和支持批量掃描計(jì)算上的能力遠(yuǎn)不如列存，方案一中的HDFS往往會(huì)選擇Parquet或者Orc這類列存。所以當(dāng)數(shù)據(jù)量增長(zhǎng)到PB甚至數(shù)百PB時(shí)，全量使用Hbase存儲(chǔ)進(jìn)行批量分析，在性能和成本上有可能會(huì)遇到瓶頸。所以主流的Hbase方案也會(huì)結(jié)合方案一，使用HDFS加速Hbase的方式來存儲(chǔ)各類結(jié)構(gòu)化數(shù)據(jù)，從而來控制整套架構(gòu)的成本和提升擴(kuò)展能力。但這樣的組合也同時(shí)帶來一個(gè)問題，組件增多運(yùn)維難度會(huì)加大。同時(shí)Hbase和HDFS中的數(shù)據(jù)數(shù)冷熱分層，還是按照業(yè)務(wù)需求來劃分。如果是分層場(chǎng)景，Hbase中的數(shù)據(jù)如何方便的流入HDFS，這些都是很實(shí)際的挑戰(zhàn)。
數(shù)據(jù)庫結(jié)合AP分析引擎方案
前面說的NoSQL方案本質(zhì)上并沒有解決數(shù)據(jù)結(jié)果集合的即席查詢問題，Hbase本身可以支撐基于Rowkey查詢，但是對(duì)于多字段的即席查詢支持較為費(fèi)力。一些高級(jí)玩家，大廠會(huì)基于Hbase對(duì)接Solr或者自己二次開發(fā)定制各類索引來加速查詢，再對(duì)接Phoenix實(shí)現(xiàn)分布式的計(jì)算能力。這一套復(fù)雜的開發(fā)，多組件整合后本質(zhì)上是希望賦予一個(gè)TP數(shù)據(jù)庫AP的能力。這也自然的把我們的架構(gòu)引入TP引擎結(jié)合AP引擎實(shí)現(xiàn)完整的分析架構(gòu)。
方案三：基于ClickHouse的實(shí)時(shí)分析平臺(tái)
例如上圖所示，通過構(gòu)建一套基于ClickHouse分析引擎的集群，各類結(jié)構(gòu)化數(shù)據(jù)同步到分析引擎后可以很便捷的進(jìn)行交互分析。這套架構(gòu)相比之前的架構(gòu)看上去簡(jiǎn)化了一些步驟，主要原因是這類引擎自身提供了類似數(shù)據(jù)庫的讀寫能力的同時(shí)也自帶一套完善的分析引擎。
業(yè)界主流的分布式AP引擎有很多，例如Druid，ClickHouse，Piont，Elasticsearch或者列存版本hbase--Kudu。這類系統(tǒng)也各有側(cè)重，有擅長(zhǎng)Append場(chǎng)景支持?jǐn)?shù)據(jù)的預(yù)聚合再分析的例如Druid，也有以實(shí)現(xiàn)各類索引，通過索引的強(qiáng)大filter能力減少IO次數(shù)來加速分析的Elasticsearch，像Kudu直接是為了優(yōu)化Hbase批量掃描能力同時(shí)保留了它的單行操作能力，把持久化的格式轉(zhuǎn)成了列存。這些系統(tǒng)的共同點(diǎn)是數(shù)據(jù)都基于列存，部分引擎引入倒排索引，Bitmap索引等進(jìn)一步加速查詢。這套架構(gòu)的好處是直接拋開了傳統(tǒng)離線大數(shù)據(jù)架構(gòu)，希望借助存儲(chǔ)引擎本身良好的存儲(chǔ)格式和計(jì)算下推的支持實(shí)現(xiàn)實(shí)時(shí)批量計(jì)算，實(shí)時(shí)展現(xiàn)計(jì)算結(jié)果。這套架構(gòu)在GB到100TB級(jí)別，相比之前的架構(gòu)有了很大的提升，此時(shí)實(shí)時(shí)計(jì)算甚至和批量離線計(jì)算的界限都變得模糊起來，TB級(jí)別的數(shù)據(jù)aggregation在秒到分鐘級(jí)就可以響應(yīng)，BI人員無需再像傳統(tǒng)大數(shù)據(jù)架構(gòu)下等待一個(gè)T+1的數(shù)據(jù)同步時(shí)延后再進(jìn)行分鐘級(jí)甚至小時(shí)級(jí)的離線計(jì)算才能拿到最終的結(jié)果，大幅加快了數(shù)據(jù)為商業(yè)帶來價(jià)值的步伐。那這套架構(gòu)會(huì)是結(jié)構(gòu)化大數(shù)據(jù)處理的終結(jié)者么？當(dāng)然短時(shí)間內(nèi)看未必，原因是這套架構(gòu)雖然具備良好的擴(kuò)展能力，但是相比Hadoop方案離線處理百PB來說，在擴(kuò)展能力，復(fù)雜計(jì)算場(chǎng)景和存儲(chǔ)成本上還是相對(duì)弱一些。例如全索引的Elasticsearch，索引本身通常會(huì)帶來三倍的存儲(chǔ)空間膨脹，通常還需要依賴SSD這樣的存儲(chǔ)介質(zhì)。其他方面這類架構(gòu)會(huì)把計(jì)算需要的所有數(shù)據(jù)加載進(jìn)內(nèi)存做實(shí)時(shí)計(jì)算，很難支持兩個(gè)大表的Join場(chǎng)景，如果有較重的計(jì)算邏輯也可能會(huì)影響計(jì)算的時(shí)效性。TB級(jí)以上級(jí)別數(shù)據(jù)的ETL場(chǎng)景也不是這類引擎所擅長(zhǎng)的。
云上的數(shù)據(jù)湖Datalake方案
方案四：AWS 基于S3的數(shù)據(jù)湖方案
AWS的這套數(shù)據(jù)湖方案可以理解為是傳統(tǒng)Hadoop方案的云上落地和升級(jí)，同時(shí)借助于云原生存儲(chǔ)引擎S3，在保留了自建HDFS集群的分布式存儲(chǔ)可靠性和高吞吐能力外，借助于自身強(qiáng)大的管道能力例如Kinesis Firehose和Glue來實(shí)現(xiàn)各類數(shù)據(jù)快速便捷的入數(shù)據(jù)湖，進(jìn)一步降低了傳統(tǒng)方案的運(yùn)維和存儲(chǔ)成本。這套架構(gòu)示例還對(duì)大數(shù)據(jù)平臺(tái)的使用者做了區(qū)分和定義，針對(duì)不同的使用場(chǎng)景，數(shù)據(jù)的使用方式，分析復(fù)雜度和時(shí)效性也會(huì)有不同，這也和我們前面提到方案一和二互補(bǔ)是相同情況。當(dāng)然這套數(shù)據(jù)湖方案本身并沒有解決傳統(tǒng)方案的所有痛點(diǎn)，例如如何保證數(shù)據(jù)湖中的數(shù)據(jù)質(zhì)量做到數(shù)據(jù)入庫原子性，或者如何高效支持?jǐn)?shù)據(jù)更新和刪除。
Delta Lake
云上希望通過數(shù)據(jù)湖概念的引入，把數(shù)據(jù)進(jìn)行匯總和分析。同時(shí)借助于云上分布式存儲(chǔ)的技術(shù)紅利，在保證數(shù)據(jù)的可靠性前提下大幅降低匯總數(shù)據(jù)持久化存儲(chǔ)的成本。同時(shí)這樣一個(gè)集中式的存儲(chǔ)也使得我們的大數(shù)據(jù)分析框架自然演進(jìn)到了存儲(chǔ)計(jì)算分離的架構(gòu)。存儲(chǔ)計(jì)算分離對(duì)分析領(lǐng)域的影響要遠(yuǎn)大于OLTP數(shù)據(jù)庫，這個(gè)也很好理解，數(shù)據(jù)隨著時(shí)間不斷累積，而計(jì)算是根據(jù)業(yè)務(wù)需求彈性變化，谷歌三駕馬車中的GFS也是為了解決這個(gè)問題。數(shù)據(jù)湖同時(shí)很好的滿足了計(jì)算需要訪問不同的數(shù)據(jù)源的需求。但是數(shù)據(jù)湖中的數(shù)據(jù)源畢竟有不同，有日志類數(shù)據(jù)，靜態(tài)的非結(jié)構(gòu)化數(shù)據(jù)，數(shù)據(jù)庫的歷史歸檔和在線庫的實(shí)時(shí)數(shù)據(jù)等等。當(dāng)我們的數(shù)據(jù)源是數(shù)據(jù)庫這類動(dòng)態(tài)數(shù)據(jù)時(shí)，數(shù)據(jù)湖面臨了新的挑戰(zhàn)，數(shù)據(jù)更新如何和原始的數(shù)據(jù)合并呢？當(dāng)用戶的賬號(hào)刪除，我們希望把數(shù)據(jù)湖中這個(gè)用戶的數(shù)據(jù)全部清除，如何處理呢？如何在批量入庫的同時(shí)保證數(shù)據(jù)一致性呢。Spark商業(yè)化公司Databricks近期提出了基于數(shù)據(jù)湖之上的新方案『Delta Lake』。Delta Lake本身的存儲(chǔ)介質(zhì)還是各類數(shù)據(jù)湖，例如自建HDFS或者S3，但是通過定義新的格式，使用列存來存base數(shù)據(jù)，行的格式存儲(chǔ)新增delta數(shù)據(jù)，進(jìn)而做到支持?jǐn)?shù)據(jù)操作的ACID和CRUD。并且完全兼容Spark的大數(shù)據(jù)生態(tài)，從這個(gè)角度看Databricks希望引入Delta Lake的理念，讓傳統(tǒng)Hadoop擅長(zhǎng)分析靜態(tài)文件進(jìn)入分析動(dòng)態(tài)數(shù)據(jù)庫源的數(shù)據(jù)，離線的數(shù)據(jù)湖逐步演進(jìn)到實(shí)時(shí)數(shù)據(jù)湖。也就是方案二和三想解決的問題。
介紹了這些結(jié)構(gòu)化數(shù)據(jù)平臺(tái)的架構(gòu)后，我們?cè)賮碜鲆幌驴偨Y(jié)，其實(shí)每套架構(gòu)都有自己擅長(zhǎng)的方案和能力：
通過上面對(duì)比我們不難看出，每套方案都有自己擅長(zhǎng)和不足的地方。各方案的計(jì)算模式或者計(jì)算引擎甚至可以是一個(gè)，例如Spark，但是它們的場(chǎng)景和效率確相差很大，原因是什么呢？區(qū)別在于存儲(chǔ)引擎。這里我們不難看出大數(shù)據(jù)的架構(gòu)拋開計(jì)算引擎本身的性能外，比拼的根本其實(shí)是存儲(chǔ)引擎，現(xiàn)在我們可以總結(jié)一下大數(shù)據(jù)分析平臺(tái)的需求是什么：在線和分析庫的隔離，數(shù)據(jù)平臺(tái)需要具備自己的存儲(chǔ)引擎，不依賴于在線庫的數(shù)據(jù)，避免對(duì)線上庫產(chǎn)生影響。有靈活的schema支持，數(shù)據(jù)可以在這里進(jìn)行打?qū)捄喜?，支持?jǐn)?shù)據(jù)的CRUD，全量數(shù)據(jù)支持高效批量計(jì)算，分析結(jié)果集可以支持即席查詢，實(shí)時(shí)寫入支持實(shí)時(shí)流計(jì)算。
綜上所述，架構(gòu)的區(qū)別源自于存儲(chǔ)引擎，那是否有一些解決方案可以融合上面的各類存儲(chǔ)引擎的優(yōu)點(diǎn)，進(jìn)一步整合出一套更加全面，可以勝任各類業(yè)務(wù)場(chǎng)景，也能平衡存儲(chǔ)成本的方案呢？ 下面我們就來一起看看構(gòu)建在阿里云上的一款云原生結(jié)構(gòu)化大數(shù)據(jù)存儲(chǔ)引擎：Tablestore如何解決這些場(chǎng)景和需求。
Tablestore的存儲(chǔ)分析架構(gòu)
Tablestore是阿里云自研的結(jié)構(gòu)化大數(shù)據(jù)存儲(chǔ)產(chǎn)品，具體產(chǎn)品介紹可以參考官網(wǎng)以及權(quán)威指南。Tablestore的設(shè)計(jì)理念很大程度上顧及了數(shù)據(jù)系統(tǒng)內(nèi)對(duì)結(jié)構(gòu)化大數(shù)據(jù)存儲(chǔ)的需求，并且基于派生數(shù)據(jù)體系這個(gè)設(shè)計(jì)理念專門設(shè)計(jì)和實(shí)現(xiàn)了一些特色的功能，也通過派生數(shù)據(jù)能力打通融合了各類存儲(chǔ)引擎。Tablestore的基本設(shè)計(jì)理念可以參考這篇文章的剖析。
大數(shù)據(jù)設(shè)計(jì)理念
說了這些理念基于Tablestore我們可以較為輕松的構(gòu)建下面四套架構(gòu)，具體的架構(gòu)選型可以結(jié)合業(yè)務(wù)場(chǎng)景，同時(shí)可以很方便的做到動(dòng)態(tài)方案切換：
組合Tablestore的寬表，Tablestore Tunnel的CDC技術(shù)，索引分析引擎，這套架構(gòu)類似方案2和3的融合，在具備寬表合并高吞吐低成本存儲(chǔ)的同時(shí)，可以提供TB級(jí)別數(shù)據(jù)即席查詢和分析的能力。這套架構(gòu)的最大優(yōu)勢(shì)就是無需過度依賴額外的計(jì)算引擎，實(shí)現(xiàn)高效實(shí)時(shí)分析能力。
Tablestore 分析引擎方案
組合Tablestore的寬表，Tablestore Tunnel的數(shù)據(jù)派生CDC技術(shù)，Spark Streaming和DeltaLake，構(gòu)建類似開源方案1或者4的架構(gòu)。通過CDC技術(shù)，EMR集群中的Spark Streaming實(shí)時(shí)訂閱Tablestore Tunnel中的增量數(shù)據(jù)寫入EMR集群中的DeltaLake，借助于DeltaLake對(duì)數(shù)據(jù)CRUD的合并能力，實(shí)現(xiàn)數(shù)據(jù)湖支持?jǐn)?shù)據(jù)修改和刪除。借助于Spark集群的分析能力進(jìn)行高吞吐的批量計(jì)算。
Tablestore DeltaLake 方案
組合Tablestore的寬表，Tablestore Tunnel的CDC技術(shù)，OSS和DLA，低成本全托管的構(gòu)建方案1的架構(gòu)。數(shù)據(jù)實(shí)時(shí)寫入Tablestore，通過CDC技術(shù)，Tablestore會(huì)全托管的把數(shù)據(jù)定期或者同步的推送到OSS中，OSS中的數(shù)據(jù)可以借助于Spark來實(shí)現(xiàn)高吞吐的批量計(jì)算處理。這套方案的最大優(yōu)勢(shì)是存儲(chǔ)和運(yùn)維的成本都相對(duì)較低。
Table數(shù)據(jù)湖方案
組合Tablestore的寬表，CDC技術(shù)，多元分析引擎，同時(shí)冷數(shù)據(jù)自動(dòng)歸檔DeltaLake/OSS。這套架構(gòu)熱數(shù)據(jù)實(shí)現(xiàn)寬表合并，秒級(jí)別即席查詢和分析能力，冷數(shù)據(jù)提供離線高吞吐批量計(jì)算能力。這樣的架構(gòu)可以在冷熱數(shù)據(jù)的存儲(chǔ)成本和計(jì)算延時(shí)上有一個(gè)很好的平衡。
Tablestore大數(shù)據(jù)架構(gòu)
總結(jié)一下，基于Tablestore的大數(shù)據(jù)架構(gòu)，數(shù)據(jù)寫入都是Tablestore的寬表行存引擎，通過統(tǒng)一寫來簡(jiǎn)化整個(gè)寫入鏈路的一致性和寫入邏輯，降低寫入延時(shí)。大數(shù)據(jù)的分析查詢的需求是多樣化的，通過數(shù)據(jù)派生驅(qū)動(dòng)打通不同引擎，業(yè)務(wù)可以根據(jù)需求靈活組合派生引擎是勢(shì)不可擋的趨勢(shì)。同時(shí)強(qiáng)調(diào)數(shù)據(jù)的冷熱分層，讓熱數(shù)據(jù)盡可能的具備最豐富的查詢和分析能力，冷數(shù)據(jù)在不失基本批量計(jì)算能力的同時(shí)盡可能的減少存儲(chǔ)成本和運(yùn)維成本。這里說的大數(shù)據(jù)架構(gòu)主要說批計(jì)算和交互分析這部分，如果是實(shí)時(shí)流計(jì)算需求，可以參考我們的云上Lambda Plus架構(gòu)。
存儲(chǔ)引擎方面Tablestore，基于分布式NoSQL數(shù)據(jù)庫也就是行存做為主存儲(chǔ)，利用數(shù)據(jù)派生CDC技術(shù)整合了分布式分析型數(shù)據(jù)庫支持列存和倒排，并結(jié)合Spark生態(tài)打造Delta Lake以及基于OSS數(shù)據(jù)湖。在計(jì)算查詢方面，Tablestore自身通過多維分析引擎或者DLA支持MPP，借助于Spark實(shí)現(xiàn)傳統(tǒng)MapReduce大數(shù)據(jù)分析。未來我們也會(huì)規(guī)劃在查詢側(cè)打通計(jì)算引擎的讀取，可以做到基于查詢語句選取最佳的計(jì)算引擎，例如點(diǎn)查命中主鍵索引則請(qǐng)求訪問行存，批量load分析熱數(shù)據(jù)則訪問數(shù)據(jù)庫列存，復(fù)雜字段組合查詢和分析訪問數(shù)據(jù)庫列存和倒排，歷史數(shù)據(jù)定期大批量掃描走DeltaLake或者OSS。我們相信一套可以基于CDC技術(shù)統(tǒng)一讀寫的融合存儲(chǔ)引擎會(huì)成為未來云上大數(shù)據(jù)方案的發(fā)展趨勢(shì)。
總結(jié)和展望
本篇文章我們談了典型的開源結(jié)構(gòu)化大數(shù)據(jù)架構(gòu)，并重點(diǎn)分析了各套架構(gòu)的特點(diǎn)。通過總結(jié)和沉淀現(xiàn)有的分析架構(gòu)，我們引出云上結(jié)構(gòu)化存儲(chǔ)平臺(tái)Tablestore在大數(shù)據(jù)分析方面具備和即將支持的能力。希望通過這套CDC驅(qū)動(dòng)的大數(shù)據(jù)平臺(tái)可以把TP類數(shù)據(jù)和各類AP需求做到最好的全托管融合，整套Serverless的架構(gòu)讓我們的計(jì)算和存儲(chǔ)資源可以得到充分利用，讓數(shù)據(jù)驅(qū)動(dòng)業(yè)務(wù)發(fā)展走的更遠(yuǎn)。
作者：宇珩
聯(lián)系客服
