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