深度 | 数据仓库分层存储技术揭秘
簡介： 作者： 沄浩、士遠
一 、背景
據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）由熱表修改為冷表：
（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天的數據是熱數據。
在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存儲團隊致力于實現全球領先的云原生數據倉庫存儲服務，提供云原生、實時化、高性能、低成本、安全可靠的企業級數倉存儲能力，通過持續不斷的自研存儲技術積累和突破，幫助數以萬計的用戶享受云原生實時化分析能力，實現數據價值在線化。
原文鏈接
本文為阿里云原創內容，未經允許不得轉載。
總結
以上是生活随笔為你收集整理的深度 | 数据仓库分层存储技术揭秘的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 基因行业容器存储解决方案
- 下一篇： 如何快速实现精准的个性化搜索服务