前言

任何線上系統都離不開數據，有些數據是業務系統自身需要的，例如系統的賬號，密碼，頁面展示的內容等。有些數據是業務系統或者用戶實時產生的，例如業務系統的日誌，用戶瀏覽訪問的記錄，系統的購買訂單，支付信息，會員的個人資料等。大多數企業對內，對外有很多這樣的線上系統，這些數據是驅動業務發展，決策和創新最核心的東西。讓這些數據更好的支撐線上系統的是數據庫和數據分析平臺。

數據庫主要承擔的是線上系統的實時數據寫入和根據預定好的需求進行查詢，嚴格說就是數據庫中的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擅長分析靜態文件進入分析動態數據庫源的數據，離線的數據湖逐步演進到實時數據湖。也就是方案二和三想解決的問題。

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

通過上面對比我們不難看出，每套方案都有自己擅長和不足的地方。各方案的計算模式或者計算引擎甚至可以是一個，例如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的架構讓我們的計算和存儲資源可以得到充分利用，讓數據驅動業務發展走的更遠。