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

一 、背景

據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的交互次數。

三、總結

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

關於我們

AnalyticDB MySQL是阿里巴巴自主研發，經過超大規模以及核心業務驗證的PB級實時OLAP數據倉庫。AnalyticDB MySQL存儲團隊致力於實現全球領先的雲原生數據倉庫存儲服務，提供雲原生、實時化、高性能、低成本、安全可靠的企業級數倉存儲能力，通過持續不斷的自研存儲技術積累和突破，幫助數以萬計的用戶享受雲原生實時化分析能力，實現數據價值在線化。歡迎投遞簡歷到 [email protected]，期待與你共同打造世界一流的數據倉庫存儲。

崗位描述

1. 彈性存儲方向，研發計算存儲分離架構下分佈式強一致、冷熱分層、彈性擴縮、一寫多讀、多租戶等雲原生數據庫基礎能力。
2. 存儲引擎方向，研發高效行存、列存和智能化索引，結合近存儲計算技術探索極致分析性能。
3. 在線檢索方向，研發百萬併發毫秒級在線檢索引擎，打造核心業務鏈路的高併發、高可靠、低延遲和穩定性。
4. 數據庫前沿技術的調研分析與落地，包括新硬件、多租戶、HTAP、CloudNative數據庫架構演進等。

崗位要求

1. 熟練掌握C/C++或Java編程，熟悉計算機體系結構、Linux操作系統、數據結構及算法等基礎知識。
2. 熟悉數據庫內核架構，有數據庫存儲引擎、事務引擎、行列存及索引等內核開發經驗者優先。
3. 熟悉大數據系統，對Hadoop生態Orc/Parquet/Kudu/Spark/Hudi/Kylin中一個或者多個有深入實踐和開發經驗者優先。
4. 熟悉開源OLAP系統，對Clickhouse/Greenplum/ElasticSearch中的一個或多個有深入實踐和開發經驗者優先。
5. 對分佈式一致性有深入理解，熟悉Raft/Paxos等分佈式共識算法或有深入實踐經驗者優先。
6. 良好的溝通和團隊協作能力，有一定的深入研究能力，對技術有好奇心，對性能優化有極致的追求者優先。
7. 工作地：杭州、北京