數據庫架構 - 如何設計結構化數據存儲（轉）

前言 

傳統的數據系統就是所謂的『大數據』技術，這是一個被創造出來的名詞，表明着新的技術門檻。近幾年得益於產業的發展、業務的創新、數據的爆發式增加以及開源技術的普遍應用，經歷多年的磨鍊以及在廣大開發者的共建下，大數據的核心組件和技術架構日趨成熟。特別是隨着雲的發展，讓『大數據』技術的使用門檻進一步下降，愈來愈多的業務創新會由數據來驅動完成。

『大數據』技術會逐步向輕量化和智能化方向發展，最終也會成爲一個研發工程師的必備技能之一，而這個過程必須是由雲計算技術來驅動以及在雲平臺之上才能完成。應用系統和數據系統也會逐漸融合，數據系統再也不隱藏在應用系統以後，而是也會貫穿在整個業務交互邏輯。傳統的應用系統，重點在於交互。而現代的應用系統，在與你交互的同時，會慢慢地熟悉你。數據系統的發展驅動了業務系統的發展，從業務化到規模化，再到智能化。

• 業務化：完成最基本的業務交互邏輯。
• 規模化：分佈式和大數據技術的應用，知足業務規模增加的需求以及數據的積累。
• 智能化：人工智能技術的應用，挖掘數據的價值，驅動業務的創新。

向規模化和智能化的發展，仍然存在必定的技術門檻。成熟的開源技術的應用能讓一個大數據系統的搭建變得簡單，同時大數據架構也變得很廣泛，例如廣爲人知的Lambda架構，必定程度上下降了技術的入門門檻。可是對數據系統的後續維護，例如對大數據組件的規模化應用、運維管控和成本優化，須要掌握大數據、分佈式技術及複雜環境下定位問題的能力，仍然具有很高的技術門檻。

數據系統的核心組件包含數據管道、分佈式存儲和分佈式計算，數據系統架構的搭建會是使用這些組件的組合拼裝。每一個組件各司其職，組件與組件之間進行上下游的數據交換，而不一樣模塊的選擇和組合是架構師面臨的最大的挑戰。

數據系統架

上圖是一個比較典型的技術架構，包含應用系統和數據系統。這個架構與具體業務無關聯，主要用於體現一個數據應用系統中會包含的幾大核心組件，以及組件間的數據流關係。應用系統主要實現了應用的主要業務邏輯，處理業務數據或應用元數據等。數據系統主要對業務數據及其餘數據進行彙總和處理，對接BI、推薦或風控等系統。整個系統架構中，會包含如下比較常見的幾大核心組件：

• 關係數據庫：用於主業務數據存儲，提供事務型數據處理，是應用系統的核心數據存儲。
• 高速緩存：對複雜或操做代價昂貴的結果進行緩存，加速訪問。
• 搜索引擎：提供複雜條件查詢和全文檢索。
• 隊列：用於將數據處理流程異步化，銜接上下游對數據進行實時交換。異構數據存儲之間進行上下游對接的核心組件，例如數據庫系統與緩存系統或搜索系統間的數據對接。也用於數據的實時提取，在線存儲到離線存儲的實時歸檔。
• 非結構化大數據存儲：用於海量圖片或視頻等非結構化數據的存儲，同時支持在線查詢或離線計算的數據訪問需求。
• 結構化大數據存儲：在線數據庫也可做爲結構化數據存儲，但這裏提到的結構化數據存儲模塊，更偏在線到離線的銜接，特徵是能支持高吞吐數據寫入以及大規模數據存儲，存儲和查詢性能可線性擴展。可存儲面向在線查詢的非關係型數據，或者是用於關係數據庫的歷史數據歸檔，知足大規模和線性擴展的需求，也可存儲面向離線分析的實時寫入數據。
• 批量計算：對非結構化數據和結構化數據進行數據分析，批量計算中又分爲交互式分析和離線計算兩類，離線計算須要知足對大規模數據集進行復雜分析的能力，交互式分析須要知足對中等規模數據集實時分析的能力。
• 流計算：對非結構化數據和結構化數據進行流式數據分析，低延遲產出實時視圖。

對於數據存儲組件咱們再進一步分析，當前各種數據存儲組件的設計是爲知足不一樣場景下數據存儲的需求，提供不一樣的數據模型抽象，以及面向在線和離線的不一樣的優化偏向。咱們來看下下面這張詳細對比表：

 

派生數據體系 

在數據系統架構中，咱們能夠看到會存在多套存儲組件。對於這些存儲組件中的數據，有些是來自應用的直寫，有些是來自其餘存儲組件的數據複製。例如業務關係數據庫的數據一般是來自業務，而高速緩存和搜索引擎的數據，一般是來自業務數據庫的數據同步與複製。不一樣用途的存儲組件有不一樣類型的上下游數據鏈路，咱們能夠大概將其歸類爲主存儲和輔存儲兩類，這兩類存儲有不一樣的設計目標，主要特徵爲：

• 主存儲：數據產生自業務或者是計算，一般爲數據首先落地的存儲。ACID等事務特性多是強需求，提供在線應用所需的低延遲業務數據查詢。
• 輔存儲：數據主要來自主存儲的數據同步與複製，輔存儲是主存儲的某個視圖，一般面向數據查詢、檢索和分析作優化。

爲什麼會有主存儲和輔存儲的存在？能不能統一存儲統一讀寫，知足全部場景的需求呢？目前看尚未，存儲引擎的實現技術有多種，選擇行存仍是列存，選擇B+tree仍是LSM-tree，存儲的是不可變數據、頻繁更新數據仍是時間分區數據，是爲高速隨機查詢仍是高吞吐掃描設計等等。數據庫產品目前也是分兩類，TP和AP，雖然在往HTAP方向走，但實現方式仍然是底層存儲分爲行存和列存。

再來看主輔存儲在實際架構中的例子，例如關係數據庫中主表和二級索引表也能夠看作是主與輔的關係，索引表數據會隨着主表數據而變化，強一致同步而且爲某些特定條件組合查詢而優化。關係數據庫與高速緩存和搜索引擎也是主與輔的關係，採用知足最終一致的數據同步方式，提供高速查詢和檢索。在線數據庫與數倉也是主與輔的關係，在線數據庫內數據集中複製到數倉來提供高效的BI分析。

這種主與輔的存儲組件相輔相成的架構設計，咱們稱之爲『派生數據體系』。在這個體系下，最大的技術挑戰是數據如何在主與輔之間進行同步與複製。

 

上圖咱們能夠看到幾個常見的數據複製方式：

• 應用層多寫：這是實現最簡單、依賴最少的一種實現方式，一般採起的方式是在應用代碼中先向主存儲寫數據，後向輔存儲寫數據。這種方式不是很嚴謹，一般用在對數據可靠性要求不是很高的場景。由於存在的問題有不少，一是很難保證主與輔之間的數據一致性，沒法處理數據寫入失效問題；二是數據寫入的消耗堆積在應用層，加劇應用層的代碼複雜度和計算負擔，不是一種解耦很好的架構；三是擴展性較差，數據同步邏輯固化在代碼中，比較難靈活添加輔存儲。 

• 異步隊列複製：這是目前被應用比較廣的架構，應用層將派生數據的寫入經過隊列來異步化和解耦。這種架構下可將主存儲和輔存儲的數據寫入都異步化，也可僅將輔存儲的數據寫入異步化。第一種方式必須接受主存儲可異步寫入，不然只能採起第二種方式。而若是採用第二種方式的話，也會遇到和上一種『應用層多寫』方案相似的問題，應用層也是多寫，只不過是寫主存儲與隊列，隊列來解決多個輔存儲的寫入和擴展性問題。

• CDC（Change Data Capture）技術：這種架構下數據寫入主存儲後會由主存儲再向輔存儲進行同步，對應用層是最友好的，只須要與主存儲打交道。主存儲到輔存儲的數據同步，則能夠再利用異步隊列複製技術來作。不過這種方案對主存儲的能力有很高的要求，必需要求主存儲能支持CDC技術。一個典型的例子就是MySQL+Elasticsearch的組合架構，Elasticsearch的數據經過MySQL的binlog來同步，binlog就是MySQL的CDC技術。

『派生數據體系』是一個比較重要的技術架構設計理念，其中CDC技術是更好的驅動數據流動的關鍵手段。具有CDC技術的存儲組件，才能更好的支撐數據派生體系，從而能讓整個數據系統架構更加靈活，下降了數據一致性設計的複雜度，從而來面向高速迭代設計。惋惜的是大多數存儲組件不具有CDC技術，例如HBase。而阿里雲Tablestore具有很是成熟的CDC技術，CDC技術的應用也推進了架構的創新。

一個好的產品，在產品內部會採用派生數據架構來不斷擴充產品的能力，能將派生的過程透明化，內部解決數據同步、一致性及資源配比問題。而現實中大多數技術架構採用產品組合的派生架構，須要本身去管理數據同步與複製等問題，例如常見的MySQL+Elasticsearch，或HBase+Solr等。這種組合一般被忽視的最大問題是，在解決CDC技術來實時複製數據後，如何解決數據一致性問題？如何追蹤數據同步延遲？如何保證輔存儲與主存儲具有相同的數據寫入能力？ 

存儲組件的選型

架構師在作架構設計時，最大的挑戰是如何對計算組件和存儲組件進行選型和組合，同類的計算引擎的差別化相對不大，一般會優先選擇成熟和生態健全的計算引擎，例如批量計算引擎Spark和流計算引擎Flink。而對於存儲組件的選型是一件很是有挑戰的事，存儲組件包含數據庫（又分爲SQL和NoSQL兩類，NoSQL下又根據各種數據模型細分爲多類）、對象存儲、文件存儲和高速緩存等不一樣類別。帶來存儲選型複雜度的主要緣由是架構師須要綜合考慮數據分層、成本優化以及面向在線和離線的查詢優化偏向等各類因素，且當前的技術發展仍是多樣化的發展趨勢，不存在一個存儲產品能知足全部場景下的數據寫入、存儲、查詢和分析等需求。有一些經驗能夠分享給你們：

• 數據模型和查詢語言仍然是不一樣數據庫最顯著的區別，關係模型和文檔模型是相對抽象的模型，而相似時序模型、圖模型和鍵值模型等其餘非關係模型是相對具象的抽象，若是場景能匹配到具象模型，那選擇範圍能縮小點。
• 存儲組件一般會劃分到不一樣的數據分層，選擇面向規模、成本、查詢和分析性能等不一樣維度的優化偏向，選型時須要考慮清楚對這部分數據存儲所要求的核心指標。
• 區分主存儲仍是輔存儲，對數據複製關係要有明確的梳理。（主存儲和輔存儲是什麼在下一節介紹）
• 創建靈活的數據交換通道，知足快速的數據搬遷和存儲組件間的切換能力，構建快速迭代能力比應對未知需求的擴展性更重要。

另外關於數據存儲架構，我認爲最終的趨勢是：

• 數據必定須要分層
• 數據最終的歸屬地必定是OSS
• 會由一個統一的分析引擎來統一分析的入口，並提供統一的查詢語言

結構化大數據存儲

定位

結構化大數據存儲在數據系統中是一個很是關鍵的組件，它起的一個很大的做用是鏈接『在線』和『離線』。做爲數據中臺中的結構化數據彙總存儲，用於在線數據庫中數據的彙總來對接離線數據分析，也用於離線數據分析的結果集存儲來直接支持在線查詢或者是數據派生。根據這樣的定位，咱們總結下對結構化大數據存儲的幾個關鍵需求。

關鍵需求

• 大規模數據存儲：結構化大數據存儲的定位是集中式的存儲，做爲在線數據庫的彙總（大寬表模式），或者是離線計算的輸入和輸出，必需要能支撐PB級規模數據存儲。
• 高吞吐寫入能力：數據從在線存儲到離線存儲的轉換，一般是經過ETL工具，T+1式的同步或者是實時同步。結構化大數據存儲須要能支撐多個在線數據庫內數據的導入，也要能承受大數據計算引擎的海量結果數據集導出。因此必須能支撐高吞吐的數據寫入，一般會採用一個爲寫入而優化的存儲引擎。
• 豐富的數據查詢能力：結構化大數據存儲做爲派生數據體系下的輔存儲，須要爲支撐高效在線查詢作優化。常見的查詢優化包括高速緩存、高併發低延遲的隨機查詢、複雜的任意字段條件組合查詢以及數據檢索。這些查詢優化的技術手段就是緩存和索引，其中索引的支持是多元化的，面向不一樣的查詢場景提供不一樣類型的索引。例如面向固定組合查詢的基於B+tree的二級索引，面向地理位置查詢的基於R-tree或BKD-tree的空間索引或者是面向多條件組合查詢和全文檢索的倒排索引。
• 存儲和計算成本分離：存儲計算分離是目前一個比較熱的架構實現，對於通常應用來講比較難體會到這個架構的優點。在雲上的大數據系統下，存儲計算分離才能徹底發揮優點。存儲計算分離在分佈式架構中，最大的優點是能提供更靈活的存儲和計算資源管理手段，大大提升了存儲和計算的擴展性。對成本管理來講，只有基於存儲計算分離架構實現的產品，才能作到存儲和計算成本的分離。
• 存儲和計算成本的分離的優點，在大數據系統下會更加明顯。舉一個簡單的例子，結構化大數據存儲的存儲量會隨着數據的積累愈來愈大，可是數據寫入量是相對平穩的。因此存儲須要不斷的擴大，可是爲了支撐數據寫入或臨時的數據分析而所需的計算資源，則相對來講比較固定，是按需的。
• 數據派生能力：一個完整的數據系統架構下，須要有多個存儲組件並存。而且根據對查詢和分析能力的不一樣要求，須要在數據派生體系下對輔存儲進行動態擴展。因此對於結構化大數據存儲來講，也須要有能擴展輔存儲的派生能力，來擴展數據處理能力。而判斷一個存儲組件是否具有更好的數據派生能力，就看是否具有成熟的CDC技術。
• 計算生態：數據的價值須要靠計算來挖掘，目前計算主要劃爲批量計算和流計算。對於結構化大數據存儲的要求，一是須要可以對接主流的計算引擎，例如Spark、Flink等，做爲輸入或者是輸出；二是須要有數據派生的能力，將自身數據轉換爲面向分析的列存格式存儲至數據湖系統；三是自身提供交互式分析能力，更快挖掘數據價值。知足第一個條件是最基本要求，知足第二和第三個條件纔是加分項。

開源產品

目前開源界比較知名的結構化大數據存儲是HBase，Cassandra和Tablestore，Cassandra是WideColumn模型NoSQL類別下排名Top-1的產品，在國外應用比較普遍，在國內的話相比Cassandra會更流行一點，Tablestore是阿里雲自研的結構化大數據存儲產品。

 

 

轉自：https://mp.weixin.qq.com/s/op8OGgJbBNwHd7A0eNLXeA ，有省略。