作者 | 沄浩、士遠
來源 | 阿裡技術公衆号
一 背景
據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來解決冷熱資料定義，冷熱資料遷移，冷資料通路優化等關鍵問題。
免費領取電子書
《阿裡雲技術面試紅寶書》
本書公開30道阿裡雲技術面試真題，含雲原生、大資料、IoT、資料庫等領域，精準回顧相關知識點及考察要點，間接地與技術大牛們學習，溫故知新！
掃碼加阿裡妹好友，回複“紅寶書”擷取吧~(若掃碼無效，可直接添加alimei4、alimei5、alimei6、alimei7)