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

一背景

據 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 來解決冷熱數據定義，冷熱數據遷移，冷數據訪問優化等關鍵問題。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/3XyRDgoOLBzUx0f6qYW7IQ

猜你喜歡