深度 | 資料倉庫分層儲存技術揭秘
一 、背景
據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 365storage_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 365storage_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來解決冷熱資料定義，冷熱資料遷移，冷資料訪問最佳化等關鍵問題。
