深度 | 數據倉庫分層存儲技術揭祕

簡介： 做者： 沄浩、士遠

一 、背景

據IDC發佈的《數據時代2025》報告顯示，全球每一年產生的數據將從2018年的33ZB增加到2025年的175ZB，平均天天約產生491EB數據。隨着數據量的不斷增加，數據存儲成本成爲企業IT預算的重要組成部分。例如1PB數據存儲一年，所有放在高性能存儲介質和所有放在低成本存儲介質二者成本差距在一個量級以上。因爲關鍵業務需高性能訪問，所以不能簡單的把全部數據存放在低速設備，企業需根據數據的訪問頻度，使用不一樣種類的存儲介質得到最小化成本和最大化效率。所以，把數據存儲在不一樣層級，並可以自動在層級間遷移數據的分層存儲技術成爲企業海量數據存儲的首選。本文介紹數據倉庫產品做爲企業中數據存儲和管理的基礎設施，在經過分層存儲技術來下降企業存儲成本時的關鍵問題和核心技術。

1. 什麼是分層存儲

分層存儲顧名思義，就是把數據分爲高頻訪問的熱數據和低頻訪問的冷數據，並分別存儲在熱數據層和冷數據層，達到性能與成本的平衡。熱數據層採用高性能存儲介質，單位成本高，爲控制預算通常容量較小，只存儲關鍵業務數據，例如ERP，CRM數據，或者最新的訂單數據等。冷數據層則存儲非關鍵業務數據，例如審計日誌，運行日誌等，或歷史沉澱數據，例如一個月前的訂單數據。此部分數據體量大，訪問頻度低，性能要求不高，所以採用單位成本低，容量大的存儲介質來下降成本。同時，隨着時間流逝，部分熱數據訪問頻度會下降（通常稱爲數據降溫），此時存儲系統可以自動遷移該部分數據到冷數據層來下降成本。

2. 數據倉庫分層存儲面臨的挑戰

數據倉庫產品在實現分層存儲能力時，面臨的幾個核心挑戰以下：

• 選擇合適的存儲介質。存儲介質既要知足性能、成本需求，還要知足可靠性、可用性、容量可擴展、運維簡單等需求。

• 業務上的冷熱數據，如何在分層存儲中定義？即如何描述哪部分是熱數據，哪部分是冷數據。

• 冷熱數據如何遷移？隨着時間流逝，業務上的熱數據降溫爲冷數據後，數據倉庫如何感知溫度的變化並執行數據遷移來下降存儲成本。

• 如何加速冷數據的訪問？冷數據仍然會被訪問，好比因法規政策要求，用戶需對三個月前數據進行修訂，或者須要對過去一年的數據進行統計分析來進行歷史回顧和趨勢分析。因爲冷數據體量大，查詢涉及的數據多，存儲介質性能低，若是不進行優化，對冷數據的元信息，內容訪問可能出現瓶頸影響業務使用。

二 、數據倉庫分層存儲關鍵技術解析

本章將以阿里雲數據倉庫AnalyticDB MySQL版（下文簡稱ADB）爲原型介紹如何在數據倉庫產品中實現分層存儲，並解決其核心挑戰。ADB的總體架構分爲三層：

• 第一層是接入層：由多個前端節點構成，主要負責接入用戶查詢，進行SQL解析、優化、調度。

• 第二層是計算引擎層：由多個計算節點組成，負責執行用戶查詢。

• 第三層是存儲引擎層：由多個存儲節點組成，用戶數據按Shard切片存儲，每一個Shard有多個副本保證高可靠和高可用。

1. 冷熱數據存儲介質的選擇

對於業務上的熱數據，需採用高性能存儲介質知足其快速查詢需求。SSD相對HDD來講，成本較高，但其具備高IOPS和高帶寬的特性，所以ADB把熱數據層創建在SSD上，並使用數據多副本機制，出現存儲節點異常時，經過切換服務節點來保證高可靠和高可用。業務上的冷數據，通常是歷史沉澱的業務數據或日誌數據，這些數據體量大，訪問頻度低，所以容量大、成本低是存儲介質的主要選擇因素。對於冷數據層，ADB選擇創建在阿里雲OSS上。阿里雲對象存儲服務OSS做爲阿里雲提供的海量、低成本、高持久性的雲存儲服務，其數據設計持久性不低於99.9999999999%，服務可用性不低於99.995%。OSS提供的這些特性知足了冷數據層對成本和可靠性的需求，同時相對於本身維護HDD磁盤，OSS自身具備容量無限擴展能力，知足海量數據存儲需求。而且OSS能夠遠程訪問，所以存儲節點的副本間能夠共享數據來進一步下降成本。

2. 冷熱數據定義問題

業務自身對冷熱數據的定義比較明確。好比企業中一些須要高頻訪問的CRM、ERP數據均爲熱數據。而對於審計日誌，或數天前的訂單數據，其訪問頻度低，則可定義爲冷數據。核心問題是，業務上的這些數據，如何在分層存儲中描述其冷熱屬性並保證存儲位置的準確性。例如企業促銷活動，大量用戶正在線上進行業務交互，此時若是分層存儲錯誤的把客戶信息、商品信息等關鍵數據遷移到冷區，則會引發相關查詢性能受損，最終出現客戶登陸受阻，客戶點擊失敗等業務異常，致使企業受損。ADB解決這個問題的方法是在用戶建表時指定存儲策略（storage_policy）來精確關聯業務上的冷熱數據和分層存儲中的冷熱存儲，下面是示例。

全熱表

全部數據存儲在SSD而且不會降溫，適用於全表數據被頻繁訪問，且對訪問性能有較高要求的場景，好比CRM、ERP數據。

Create table t1( id int, dt datetime ) distribute by hash(id) storage_policy = 'HOT';

全冷表

全部數據存儲在OSS，適用於體量大，訪問頻度低，須要減小存儲成本的場景，好比審計日誌數據。

Create table t2( id int, dt datetime ) distribute by hash(id) storage_policy = 'COLD';

冷熱混合表
適用於數據冷熱有明顯時間窗口的場景。例如最近7天的遊戲日誌數據，廣告點擊數據等需高頻訪問，做爲熱數據存儲，而7天前的數據可降溫爲冷數據，低成本存儲。

注：冷熱混合表需配合表的分區使用。除storage_policy外，還需指定hot_partition_count屬性。hot_partition_count指按分區值倒序，取最大N個分區爲熱分區，其他爲冷分區。下例中，表按天分區，hot_partition_count = 7表示分區值最大的7個分區，也就是最近7天的數據爲熱數據。

Create table t3( id int, dt datetime ) distribute by hash(id) partition by value(date_format(dt, '%Y%m%d')) lifecycle 365 storage_policy = 'MIXED' hot_partition_count = 7;

修改冷熱策略
隨業務的變化，表的訪問特性可能發生變化，企業能夠隨時修改表的存儲策略來適應新的存儲需求。

（1）由熱表修改成冷表：

Alter table t1 storage_policy = 'COLD';

（2）修改熱分區的個數，修改成最近14天的數據爲熱數據：

Alter table t3 storage_policy = 'MIXED' hot_partition_count = 14;

3. 冷熱數據自動遷移問題

隨時間流逝，熱數據的訪問頻度下降，降溫爲冷數據。好比一些日誌數據，在數天後就不多再訪問，分層存儲需把這部分數據由熱數據層遷移到冷數據層來下降成本。這裏的核心問題是如何知道哪部分數據的溫度下降了須要遷移？下面經過一個冷熱混合表，來講明ADB解決該問題的方法。以下是一張日誌表，最近三天數據爲熱數據，知足高性能在線查詢需求，三天前數據爲冷數據，低成本存儲並知足低頻訪問需求。

Create table Event_log ( event_id bigint, dt datetime, event varchar ) distribute by hash(event_id) partition by value(date_format(dt, '%Y%m%d')) lifecycle 365 storage_policy = 'MIXED' hot_partition_count = 3;

在本例中，表首先按天分區。

partition by value(date_format(dt, '%Y%m%d')) lifecycle 365

並定義冷熱策略爲混合模式，最新3天的數據是熱數據。

storage_policy = 'MIXED' hot_partition_count = 3

在ADB中，冷熱數據以分區爲最小粒度，即一個分區要麼在熱區，要麼在冷區，而後經過熱分區窗口來斷定某個分區是否爲熱分區（表屬性中的hot_partition_count定義了熱分區窗口的大小）。在本例中，假定當前日期是3月4日，則3月2日、3日、4日這三天的數據處於熱分區窗口中，所以是熱分區。當寫入3月5日的數據後，則3月3日、4日、5日這三天數據組成了新的熱分區窗口，3月2日數據降溫爲冷數據，後臺會自動執行熱冷遷移，把3月2日的數據由熱區遷移到冷區。經過熱分區窗口，客戶根據業務場景能夠明肯定義冷熱邊界，一旦數據降溫則自動遷移。

4. 冷數據訪問性能問題

冷數據存儲在OSS上，OSS是遠程存儲系統並經過網絡訪問，延遲較高。例如判斷文件是否存在，獲取文件長度等元信息操做，單次交互的訪問延遲在毫秒級別。同時，OSS帶寬有限，一個帳號下總體只有GB級別帶寬，提供的總體QPS也只有數十萬，超事後OSS就會限流。數據倉庫內部存儲着大量文件，若是不對OSS訪問作優化，則會出現查詢異常。例如查詢可能涉及數百萬個文件，僅僅獲取這些文件的元信息就會達到OSS的QPS上限，最終致使查詢超時等異常，所以需對OSS的訪問進行優化來保證業務的可用性並提升查詢性能。以下對元信息訪問優化和數據訪問優化分別介紹。

元信息訪問優化

ADB做爲數據倉庫，底層存儲了大量的數據文件和索引文件。ADB優化元信息訪問的方法是對文件進行歸檔，即把一個分區內的全部文件打包在一個歸檔文件中，並提供一層類POSIX的文件訪問接口，經過這個接口去讀取文件內容。

歸檔文件的Meta裏內存儲了每一個子文件的偏移和長度等元信息。讀取時，先加載歸檔文件的Meta，只須要一次交互便可拿到全部子文件元信息，交互次數下降數百倍。爲進一步加速，ADB在存儲節點的內存和SSD上分別開闢了一小塊空間緩存歸檔文件的Meta，加載過即無需再訪問OSS獲取元信息。同時，歸檔後只需一個輸入流即可讀取全部子文件數據內容，避免爲每一個子文件單獨開啓輸入流的開銷。

數據訪問優化

查詢中，不管是掃描索引，仍是讀取數據塊，都須要讀取OSS上文件的內容，而OSS不管訪問性能仍是訪問帶寬都有限。爲加速文件內容的讀取，ADB存儲節點會自動利用SSD上的一塊空間作數據Cache，且Cache的上層提供了類POSIX的文件訪問接口，數據掃描算子（Table Scanner）能夠像訪問普通文件同樣訪問Cache中的內容。

查詢中對OSS的全部訪問（索引、數據等）均可藉助SSD Cache加速，只有當數據不在Cache中時纔會訪問OSS。針對這塊Cache，ADB還作了以下優化：

• 多粒度的Cache Block，加載元信息時使用較小的Block，加載數據時使用較大的Block，以此提升Cache空間利用率。

• 元數據預熱，自動加載數據和索引的元數據到Cache中並鎖定，以實現元數據高效訪問。

• 基於冷熱訪問隊列的類LRU算法，實現無鎖化高性能換入換出。

• 自動IO合併，相鄰數據的訪問合併爲一個請求，減小與OSS的交互次數。

3、總結

---

隨着企業數據量的不斷增加，存儲成本成爲企業預算中的重要組成部分，數據倉庫做爲企業存儲和管理數據的基礎設施，經過分層存儲技術很好的解決了企業中存儲成本與性能的平衡問題。對於分層存儲技術中的關鍵挑戰，本文以雲原生數據倉庫AnalyticDB MySQL爲原型，介紹了其如何經過冷熱策略定義，熱分區窗口，文件歸檔，SSD Cache來解決冷熱數據定義，冷熱數據遷移，冷數據訪問優化等關鍵問題。

關於咱們

AnalyticDB MySQL是阿里巴巴自主研發，通過超大規模以及核心業務驗證的PB級實時OLAP數據倉庫。AnalyticDB MySQL存儲團隊致力於實現全球領先的雲原生數據倉庫存儲服務，提供雲原生、實時化、高性能、低成本、安全可靠的企業級數倉存儲能力，經過持續不斷的自研存儲技術積累和突破，幫助數以萬計的用戶享受雲原生實時化分析能力，實現數據價值在線化。
原文連接本文爲阿里雲原創內容，未經容許不得轉載。