結構化大數據分析平臺設計

前言 

任何線上系統都離不開數據，有些數據是業務系統自身須要的，例如系統的帳號，密碼，頁面展現的內容等。有些數據是業務系統或者用戶實時產生的，例如業務系統的日誌，用戶瀏覽訪問的記錄，系統的購買訂單，支付信息，會員的我的資料等。大多數企業對內，對外有不少這樣的線上系統，這些數據是驅動業務發展，決策和創新最核心的東西。讓這些數據更好的支撐線上系統的是數據庫和數據分析平臺。
數據庫主要承擔的是線上系統的實時數據寫入和根據預約好的需求進行查詢，嚴格說就是數據庫中的OLTP類型數據庫。這類數據庫中最爲你們所熟知的就是Oracle和MySQL。業務系統對數據庫的要求多是多樣的，近些年也由傳統的關係型數據庫融入了NoSQL數據庫和NewSQL。業務系統中除了和業務直接相關的數據存儲在數據庫中並累積起來外，還有海量的系統監控數據，系統業務日誌產生。若是咱們但願這些數據能夠更持久的存儲而且作一些實時或者離線的分析，輔助咱們的業務作決策，提供業務大盤和報表，不少公司會構建本身的數據分析平臺。也就是時下『大數據』平臺的由來。這類平臺主要解決如下幾個問題：

1. 豐富的數據源支持和數據格式延遲綁定

豐富的數據源是由於這樣一個數據分析平臺是彙總咱們各種業務數據的地方，數據源可能來自各種數據庫例如MySQL，MongoDB，日誌源等等。這個平臺須要可以方便各種數據源便捷的入庫，例如一般你們會發現大數據架構中有一個Kafka，各種數據源會先進入Kafka，再由Kafka推送到大數據的存儲系統中。這裏Kafka就承擔瞭解耦大數據平臺的存儲接口和上游數據源的做用。數據格式延時綁定是一個很重要的概念，TP類數據庫每每須要根據業務需求預先定義Schema，也就是一般說的寫入型Schema，數據在寫入時即會作嚴格的數據字段類型檢驗。可是分析系統並不但願由於Schema約束或者限制的數據入庫，一般會採用讀取型Schema，也就是這裏的延時綁定，數據在分析時纔會根據數據類型作對應的處理。

2. 存儲和計算彈性擴展

存儲和計算彈性擴展是指大數據系統須要能支撐海量數據和保持高吞吐的讀寫。數據分析平臺會彙總接納各種線上系統中的各種數據，同時數據會隨着時間進行累積。大數據分析平臺可以支撐海量數據的存儲是必須的，並且這個規模並非預先定義好的，而是隨着數據的累積彈性增長的，這裏的存儲量可能從TB級到PB級別，甚至數百PB。同時整套架構的計算能力也同樣具有彈性，舉個直觀的例子，可能咱們在TB級別作一次全量處理須要20分鐘，是否是到了百PB級別，處理時間也翻了好幾個數量級從而致使天天的分析結果不能及時產生，從而讓大數據平臺的價值大打折扣，限制了業務的飛速發展。

3. 大規模低成本

不少大數據平臺設計之初未必會意識到成本，主要依據自身對開源方案的熟悉度，業務方對數據規模和分析實效性進行方案的選取。但當業務量真的起來後，不得不面臨一個挑戰就是大數據平臺的成本問題。這裏甚至會致使不得不進行平臺的架構改造或者數據遷移。因此對於企業的大數據平臺設計之初，咱們就須要把整套架構的成本考慮進來。這對應的就是數據的分層存儲和存儲計算引擎的選取。時下雲上的大數據平臺每每最終會選擇一個可擴展，低成本的存儲平臺落地最終的數據，例如阿里雲上的OSS或者AWS的S3，這些存儲平臺自己也支持進一步的分層存儲。這類存儲之上的計算平臺能夠選取Elastic MapReduce方案。整套架構就組成了時下火熱的『數據湖』方案。在線下用戶可能會自建一個Hadoop集羣，並使用HDFS來存儲這些彙總的數據，進而構建本身的大數據數據倉庫。

4. 在線業務和分析業務隔離

隔離是由於分析業務每每須要掃描較多的數據進行分析，這類大流量的掃描若是是發生在在線庫，可能會影響線上服務的SLA。同時分析流量的訪問模式和在線模式未必相同，在線庫數據的存儲分佈和格式也未必適合分析系統。因此通常典型的大數據平臺會有本身的一份存儲，數據分佈，格式和索引會面向分析需求而作相應的優化。例如典型的TP類引擎的存儲格式每每是行存，分析的時候會轉變成列存。

介紹到這裏，但願引導你們來思考這樣一個問題，不管是傳統的數據倉庫，仍是雲上的數據湖，咱們最終仍是但願能夠有效的解決業務中數據存儲和分析的問題。那究竟業務需求是什麼，尤爲是當咱們但願分析數據源是數據庫，日誌監控這類結構化或者半結構化數據時，對大數據平臺的需求是什麼呢？我想這裏你們能夠先思考一下，後面咱們會和你們一塊兒看看時下一些主流的開源方案和雲上的構建方案，而後再來總結下結構化大數據存儲和分析的需求。

開源大數據存儲分析平臺架構

前面咱們說起線上業務的實現離不開OLTP數據庫的支持，來實現實時的數據讀寫。這一章咱們一塊兒看看，開源和雲上一些主流的組合數據庫和大數據分析平臺的架構。

Hadoop大數據方案

方案一：Uber Hadoop大數據架構

咱們以Uber的一套大數據架構爲例，圖中展現了各種數據庫經過Kafka推送到Hadoop集羣中進行全量批計算，結果集合會再寫入幾類存儲引擎中進行結果查詢展現。

在傳統的Hadoop架構中，各種結構化數據例如日誌數據經過採集管道進入Kafka，Spark 能夠實時的消費Kafka的數據寫入集羣內的HDFS中。數據庫例如RDS中的數據會使用Spark按期全量掃表同步到HDFS，一般週期是一天一次，在業務低峯期進行同步。這樣使用HDFS存儲彙總了用戶的數據，對數據庫數據而言實際上是一個按期的snapshot。例如天天的凌晨會把行爲日誌與數據庫中用戶的信息進行聯合的分析，產生當天的分析報告好比包含當天訪問量彙總，用戶的消費傾向等報表數據，給業務負責人決策使用。架構中之因此說RDS的數據是全量入庫，主要緣由是HDFS自己只是一個分佈式文件存儲，對Record級別的更新刪除並不友好。因此爲了簡化這些數據庫中的合併修改刪除邏輯，在數據規模不大的狀況下會選擇全量掃描。當數據庫數據較大時，例如Uber的架構中，基於HDFS開發了一套存儲引擎來支持修改和刪除。

這套方案的特色是，分析時數據已是靜態，藉助於Hadoop集羣的高併發能力，能夠較爲容易的實現百TB到PB量級行爲數據的離線計算和處理，同時數據大塊的存儲在HDFS上，綜合存儲成本也相對較低。美中不足的是數據是按期入庫，數據計算的時效性一般是T+1。若是業務方有近實時推薦的需求，這時架構會從離線計算升級到『Lambda架構』。架構以下圖:

Lambda架構

具體細節能夠參考Lambda介紹。
經過HDFS全量存儲和Kafka存儲增量來實現離線和實時兩類計算需求。本質上HDFS存儲的全量仍然是T+1式的。可是經過Kafka對接流計算彌補實時計算的需求。也就是多了一份存儲和計算邏輯實現業務實時性的需求。
不管是傳統離線分析架構仍是Lambda架構，結果集合可能仍然比較大，須要持久化在一個結構化存儲系統中。此時的存儲主要作爲結果集合進行查詢，例如實時大盤，報表，BI業務決策人員的即席查詢等。因此主流的作法是把結果寫入RDS而後同步至Elasticsearch或者直接寫入Elasticsearch，這裏主要但願藉助於ES強大的全文檢索和多字段組合查詢能力。

分佈式NoSQL數據庫方案

方案二：基於分佈式NoSQL數據庫Hbase的大數據架構

以前的架構咱們不難發現，RDS在作批計算的時候須要同步至HDFS造成靜態數據作批計算。這樣的架構可能會遇到一個場景，全量數據很大，天天全量同步，時效性不好甚至若是資源不夠會同步不完，如何優化這個問題呢？咱們不難想到若是數據倉庫自己就是一個數據庫，直接支持CRUD操做，那豈不是不須要同步全量！甚至部分在線數據能夠直接寫入這個海量數據庫中，沒錯業界不少開源方案會基於分佈式的NoSQL數據庫例如Hbase來打造這個架構。上圖就是一個簡單的實例。Hbase schema free以及支持實時的CRUD操做，大大簡化了數據源數據的實時寫入，同步問題。同時能夠跨數據源打造大寬表，大寬表會大大下降計算時經過join構建完整數據的複雜度。同時Hbase組合Kafka也能夠實現Lambda支持批和流兩類需求。那這種架構是完美的麼？能夠徹底替換方案一麼？

答案確定不是，一方面Hbase爲了支持好實時的數據寫入，是採用了LSM存儲引擎，新數據經過追加的方式入庫，數據更新和合並依賴後臺的合併優化減小讀操做。這類支持數據引擎的數據讀寫成本是要高於直接讀寫HDFS靜態文件。另外一方面Hbase數據落盤的存儲格式是按行進行組織，也就是咱們一般說的行存儲。行存儲在數據的壓縮和支持批量掃描計算上的能力遠不如列存，方案一中的HDFS每每會選擇Parquet或者Orc這類列存。因此當數據量增加到PB甚至數百PB時，全量使用Hbase存儲進行批量分析，在性能和成本上有可能會遇到瓶頸。因此主流的Hbase方案也會結合方案一，使用HDFS加速Hbase的方式來存儲各種結構化數據，從而來控制整套架構的成本和提高擴展能力。但這樣的組合也同時帶來一個問題，組件增多運維難度會加大。同時Hbase和HDFS中的數據數冷熱分層，仍是按照業務需求來劃分。若是是分層場景，Hbase中的數據如何方便的流入HDFS，這些都是很實際的挑戰。

數據庫結合AP分析引擎方案

前面說的NoSQL方案本質上並無解決數據結果集合的即席查詢問題，Hbase自己能夠支撐基於Rowkey查詢，可是對於多字段的即席查詢支持較爲費力。一些高級玩家，大廠會基於Hbase對接Solr或者本身二次開發定製各種索引來加速查詢，再對接Phoenix實現分佈式的計算能力。這一套複雜的開發，多組件整合後本質上是但願賦予一個TP數據庫AP的能力。這也天然的把咱們的架構引入TP引擎結合AP引擎實現完整的分析架構。

方案三：基於ClickHouse的實時分析平臺

例如上圖所示，經過構建一套基於ClickHouse分析引擎的集羣，各種結構化數據同步到分析引擎後能夠很便捷的進行交互分析。這套架構相比以前的架構看上去簡化了一些步驟，主要緣由是這類引擎自身提供了相似數據庫的讀寫能力的同時也自帶一套完善的分析引擎。

業界主流的分佈式AP引擎有不少，例如Druid，ClickHouse，Piont，Elasticsearch或者列存版本hbase--Kudu。這類系統也各有側重，有擅長Append場景支持數據的預聚合再分析的例如Druid，也有以實現各種索引，經過索引的強大filter能力減小IO次數來加速分析的Elasticsearch，像Kudu直接是爲了優化Hbase批量掃描能力同時保留了它的單行操做能力，把持久化的格式轉成了列存。這些系統的共同點是數據都基於列存，部分引擎引入倒排索引，Bitmap索引等進一步加速查詢。這套架構的好處是直接拋開了傳統離線大數據架構，但願藉助存儲引擎自己良好的存儲格式和計算下推的支持實現實時批量計算，實時展示計算結果。這套架構在GB到100TB級別，相比以前的架構有了很大的提高，此時實時計算甚至和批量離線計算的界限都變得模糊起來，TB級別的數據aggregation在秒到分鐘級就能夠響應，BI人員無需再像傳統大數據架構下等待一個T+1的數據同步時延後再進行分鐘級甚至小時級的離線計算才能拿到最終的結果，大幅加快了數據爲商業帶來價值的步伐。那這套架構會是結構化大數據處理的終結者麼？固然短期內看未必，緣由是這套架構雖然具有良好的擴展能力，可是相比Hadoop方案離線處理百PB來講，在擴展能力，複雜計算場景和存儲成本上仍是相對弱一些。例如全索引的Elasticsearch，索引自己一般會帶來三倍的存儲空間膨脹，一般還須要依賴SSD這樣的存儲介質。其餘方面這類架構會把計算須要的全部數據加載進內存作實時計算，很難支持兩個大表的Join場景，若是有較重的計算邏輯也可能會影響計算的時效性。TB級以上級別數據的ETL場景也不是這類引擎所擅長的。

雲上的數據湖Datalake方案

方案四：AWS 基於S3的數據湖方案

AWS的這套數據湖方案能夠理解爲是傳統Hadoop方案的雲上落地和升級，同時藉助於雲原生存儲引擎S3，在保留了自建HDFS集羣的分佈式存儲可靠性和高吞吐能力外，藉助於自身強大的管道能力例如Kinesis Firehose和Glue來實現各種數據快速便捷的入數據湖，進一步下降了傳統方案的運維和存儲成本。這套架構示例還對大數據平臺的使用者作了區分和定義，針對不一樣的使用場景，數據的使用方式，分析複雜度和時效性也會有不一樣，這也和咱們前面提到方案一和二互補是相同狀況。固然這套數據湖方案自己並無解決傳統方案的全部痛點，例如如何保證數據湖中的數據質量作到數據入庫原子性，或者如何高效支持數據更新和刪除。

Delta Lake

雲上但願經過數據湖概念的引入，把數據進行彙總和分析。同時藉助於雲上分佈式存儲的技術紅利，在保證數據的可靠性前提下大幅下降彙總數據持久化存儲的成本。同時這樣一個集中式的存儲也使得咱們的大數據分析框架天然演進到了存儲計算分離的架構。存儲計算分離對分析領域的影響要遠大於OLTP數據庫，這個也很好理解，數據隨着時間不斷累積，而計算是根據業務需求彈性變化，谷歌三駕馬車中的GFS也是爲了解決這個問題。數據湖同時很好的知足了計算須要訪問不一樣的數據源的需求。可是數據湖中的數據源畢竟有不一樣，有日誌類數據，靜態的非結構化數據，數據庫的歷史歸檔和在線庫的實時數據等等。當咱們的數據源是數據庫這類動態數據時，數據湖面臨了新的挑戰，數據更新如何和原始的數據合併呢？當用戶的帳號刪除，咱們但願把數據湖中這個用戶的數據所有清除，如何處理呢？如何在批量入庫的同時保證數據一致性呢。Spark商業化公司Databricks近期提出了基於數據湖之上的新方案『Delta Lake』。Delta Lake自己的存儲介質仍是各種數據湖，例如自建HDFS或者S3，可是經過定義新的格式，使用列存來存base數據，行的格式存儲新增delta數據，進而作到支持數據操做的ACID和CRUD。而且徹底兼容Spark的大數據生態，從這個角度看Databricks但願引入Delta Lake的理念，讓傳統Hadoop擅長分析靜態文件進入分析動態數據庫源的數據，離線的數據湖逐步演進到實時數據湖。也就是方案二和三想解決的問題。

介紹了這些結構化數據平臺的架構後，咱們再來作一下總結，其實每套架構都有本身擅長的方案和能力：

	適合場景	數據規模	存儲格式	數據導入模式	成本	計算方式	方案運維複雜度	數據變動性
傳統Hadoop	海量數據離線處理
Append爲主的場景	大	列存	批量離線	低	MapReduce	較高	不可更新
靜態文件
分佈式NoSQL數據庫	海量數據，支持實時CRUD
批量離線處理，能夠部分作方案一的結果存儲集	中上	行存	實時在線	中	MapReduce	中	可更新
分佈式分析型數據庫	實時/近實時入庫，即席查詢分析，常常作爲方案一的結果存儲集	中	行列混合	實時/近實時	高	MPP	中	可更新
數據湖/DeltaLake	海量數據離線處理，實時流計算
具有ACID和CRUD能力	大	行列混合	批量離線/近實時	低	MapReduce	中	可更新

經過上面對比咱們不難看出，每套方案都有本身擅長和不足的地方。各方案的計算模式或者計算引擎甚至能夠是一個，例如Spark，可是它們的場景和效率確相差很大，緣由是什麼呢？區別在於存儲引擎。這裏咱們不難看出大數據的架構拋開計算引擎自己的性能外，比拼的根本實際上是存儲引擎，如今咱們能夠總結一下大數據分析平臺的需求是什麼：在線和分析庫的隔離，數據平臺須要具有本身的存儲引擎，不依賴於在線庫的數據，避免對線上庫產生影響。有靈活的schema支持，數據能夠在這裏進行打寬合併，支持數據的CRUD，全量數據支持高效批量計算，分析結果集能夠支持即席查詢，實時寫入支持實時流計算。

綜上所述，架構的區別源自於存儲引擎，那是否有一些解決方案能夠融合上面的各種存儲引擎的優勢，進一步整合出一套更加全面，能夠勝任各種業務場景，也能平衡存儲成本的方案呢？ 下面咱們就來一塊兒看看構建在阿里雲上的一款雲原生結構化大數據存儲引擎：Tablestore如何解決這些場景和需求。

Tablestore的存儲分析架構

Tablestore是阿里雲自研的結構化大數據存儲產品，具體產品介紹能夠參考官網以及權威指南。Tablestore的設計理念很大程度上顧及了數據系統內對結構化大數據存儲的需求，而且基於派生數據體系這個設計理念專門設計和實現了一些特點的功能，也經過派生數據能力打通融合了各種存儲引擎。Tablestore的基本設計理念能夠參考這篇文章的剖析。

大數據設計理念

• 存儲計算分離架構：採用存儲計算分離架構，底層基於飛天盤古分佈式文件系統，這是實現存儲計算成本分離的基礎。
• CDC技術：CDC即數據變動捕獲，Tablestore的CDC技術名爲Tunnel Service，支持全量和增量的實時數據訂閱，而且能無縫對接Flink流計算引擎來實現表內數據的實時流計算。基於CDC技術能夠很便捷的打通Tablestore內的各種引擎以及雲上的其餘存儲引擎。
• 多存儲引擎支持：理想的數據平臺但願能夠擁有數據庫類的行存，列存引擎，倒排引擎，也能支持數據湖方案下的HDFS或者DeltaLake，熱數據採用數據庫的存儲引擎，冷全量數據採用更低成本數據湖方案。整套數據的熱到冷能夠作到全託管，根據業務場景定製數據在各引擎的生命週期。Tablestore上游基於Free Schema的行存，下游經過CDC技術派生支持列存，倒排索引，空間索引，二級索引以及雲上DeltaLake和OSS，實現同時具有上述四套開源架構方案的能力。
• 數據最終的落地歸檔必然是數據湖OSS：這裏很好理解，當咱們的熱數據隨着時間推移變成冷數據，數據必然會逐漸歸檔進入OSS，甚至是歸檔OSS存儲中。這樣可讓咱們的PB級別數據實現最低成本的高可用存儲。同時面對極爲偶爾的全量分析場景，也能夠以一個相對穩定高效的速率吞吐出想要的文件。因此在Tablestore平臺上的大數據最終咱們會推薦歸檔進入OSS。

說了這些理念基於Tablestore咱們能夠較爲輕鬆的構建下面四套架構，具體的架構選型能夠結合業務場景，同時能夠很方便的作到動態方案切換：

1. 附加值較高的數據，但願具有高併發點查詢，即席查詢分析能力（9月已發佈）：

組合Tablestore的寬表，Tablestore Tunnel的CDC技術，索引分析引擎，這套架構相似方案2和3的融合，在具有寬表合併高吞吐低成本存儲的同時，能夠提供TB級別數據即席查詢和分析的能力。這套架構的最大優點就是無需過分依賴額外的計算引擎，實現高效實時分析能力。

Tablestore 分析引擎方案

1. 海量數據，非高頻率更新的數據，擁有云上EMR集羣（即將支持敬請期待）：

組合Tablestore的寬表，Tablestore Tunnel的數據派生CDC技術，Spark Streaming和DeltaLake，構建相似開源方案1或者4的架構。經過CDC技術，EMR集羣中的Spark Streaming實時訂閱Tablestore Tunnel中的增量數據寫入EMR集羣中的DeltaLake，藉助於DeltaLake對數據CRUD的合併能力，實現數據湖支持數據修改和刪除。藉助於Spark集羣的分析能力進行高吞吐的批量計算。

Tablestore DeltaLake 方案

1. 海量數據，更新較少的數據，有明顯分區維度屬性的數據（例如可用屬性中的時間戳作數據分層）：

組合Tablestore的寬表，Tablestore Tunnel的CDC技術，OSS和DLA，低成本全託管的構建方案1的架構。數據實時寫入Tablestore，經過CDC技術，Tablestore會全託管的把數據按期或者同步的推送到OSS中，OSS中的數據能夠藉助於Spark來實現高吞吐的批量計算處理。這套方案的最大優點是存儲和運維的成本都相對較低。

Table數據湖方案

1. 全引擎融合方案：

組合Tablestore的寬表，CDC技術，多元分析引擎，同時冷數據自動歸檔DeltaLake/OSS。這套架構熱數據實現寬表合併，秒級別即席查詢和分析能力，冷數據提供離線高吞吐批量計算能力。這樣的架構能夠在冷熱數據的存儲成本和計算延時上有一個很好的平衡。

Tablestore大數據架構

總結一下，基於Tablestore的大數據架構，數據寫入都是Tablestore的寬錶行存引擎，經過統一寫來簡化整個寫入鏈路的一致性和寫入邏輯，下降寫入延時。大數據的分析查詢的需求是多樣化的，經過數據派生驅動打通不一樣引擎，業務能夠根據需求靈活組合派生引擎是勢不可擋的趨勢。同時強調數據的冷熱分層，讓熱數據儘量的具有最豐富的查詢和分析能力，冷數據在不失基本批量計算能力的同時儘量的減小存儲成本和運維成本。這裏說的大數據架構主要說批計算和交互分析這部分，若是是實時流計算需求，能夠參考咱們的雲上Lambda Plus架構。

存儲引擎方面Tablestore，基於分佈式NoSQL數據庫也就是行存作爲主存儲，利用數據派生CDC技術整合了分佈式分析型數據庫支持列存和倒排，並結合Spark生態打造Delta Lake以及基於OSS數據湖。在計算查詢方面，Tablestore自身經過多維分析引擎或者DLA支持MPP，藉助於Spark實現傳統MapReduce大數據分析。將來咱們也會規劃在查詢側打通計算引擎的讀取，能夠作到基於查詢語句選取最佳的計算引擎，例如點查命中主鍵索引則請求訪問行存，批量load分析熱數據則訪問數據庫列存，複雜字段組合查詢和分析訪問數據庫列存和倒排，歷史數據按期大批量掃描走DeltaLake或者OSS。咱們相信一套能夠基於CDC技術統一讀寫的融合存儲引擎會成爲將來雲上大數據方案的發展趨勢。

總結和展望

本篇文章咱們談了典型的開源結構化大數據架構，並重點分析了各套架構的特色。經過總結和沉澱現有的分析架構，咱們引出雲上結構化存儲平臺Tablestore在大數據分析方面具有和即將支持的能力。但願經過這套CDC驅動的大數據平臺能夠把TP類數據和各種AP需求作到最好的全託管融合，整套Serverless的架構讓咱們的計算和存儲資源能夠獲得充分利用，讓數據驅動業務發展走的更遠。

---

本文做者：宇珩

閱讀原文

本文爲雲棲社區原創內容，未經容許不得轉載。