簡介： 作者： 沄浩、士遠

一 、背景

據(jù)IDC發(fā)布的《數(shù)據(jù)時代2025》報告顯示，全球每年產生的數(shù)據(jù)將從2018年的33ZB增長到2025年的175ZB，平均每天約產生491EB數(shù)據(jù)。隨著數(shù)據(jù)量的不斷增長，數(shù)據(jù)存儲成本成為企業(yè)IT預算的重要組成部分。例如1PB數(shù)據(jù)存儲一年，全部放在高性能存儲介質和全部放在低成本存儲介質兩者成本差距在一個量級以上。由于關鍵業(yè)務需高性能訪問，因此不能簡單的把所有數(shù)據(jù)存放在低速設備，企業(yè)需根據(jù)數(shù)據(jù)的訪問頻度，使用不同種類的存儲介質獲得最小化成本和最大化效率。因此，把數(shù)據(jù)存儲在不同層級，并能夠自動在層級間遷移數(shù)據(jù)的分層存儲技術成為企業(yè)海量數(shù)據(jù)存儲的首選。本文介紹數(shù)據(jù)倉庫產品作為企業(yè)中數(shù)據(jù)存儲和管理的基礎設施，在通過分層存儲技術來降低企業(yè)存儲成本時的關鍵問題和核心技術。

1. 什么是分層存儲

分層存儲顧名思義，就是把數(shù)據(jù)分為高頻訪問的熱數(shù)據(jù)和低頻訪問的冷數(shù)據(jù)，并分別存儲在熱數(shù)據(jù)層和冷數(shù)據(jù)層，達到性能與成本的平衡。熱數(shù)據(jù)層采用高性能存儲介質，單位成本高，為控制預算一般容量較小，只存儲關鍵業(yè)務數(shù)據(jù)，例如ERP，CRM數(shù)據(jù)，或者最新的訂單數(shù)據(jù)等。冷數(shù)據(jù)層則存儲非關鍵業(yè)務數(shù)據(jù)，例如審計日志，運行日志等，或歷史沉淀數(shù)據(jù)，例如一個月前的訂單數(shù)據(jù)。此部分數(shù)據(jù)體量大，訪問頻度低，性能要求不高，因此采用單位成本低，容量大的存儲介質來降低成本。同時，隨著時間流逝，部分熱數(shù)據(jù)訪問頻度會降低（一般稱為數(shù)據(jù)降溫），此時存儲系統(tǒng)能夠自動遷移該部分數(shù)據(jù)到冷數(shù)據(jù)層來降低成本。

?

2. 數(shù)據(jù)倉庫分層存儲面臨的挑戰(zhàn)

數(shù)據(jù)倉庫產品在實現(xiàn)分層存儲能力時，面臨的幾個核心挑戰(zhàn)如下：

• 選擇合適的存儲介質。存儲介質既要滿足性能、成本需求，還要滿足可靠性、可用性、容量可擴展、運維簡單等需求。

?

• 業(yè)務上的冷熱數(shù)據(jù)，如何在分層存儲中定義？即如何描述哪部分是熱數(shù)據(jù)，哪部分是冷數(shù)據(jù)。

?

• 冷熱數(shù)據(jù)如何遷移？隨著時間流逝，業(yè)務上的熱數(shù)據(jù)降溫為冷數(shù)據(jù)后，數(shù)據(jù)倉庫如何感知溫度的變化并執(zhí)行數(shù)據(jù)遷移來降低存儲成本。

?

• 如何加速冷數(shù)據(jù)的訪問？冷數(shù)據(jù)仍然會被訪問，比如因法規(guī)政策要求，用戶需對三個月前數(shù)據(jù)進行修訂，或者需要對過去一年的數(shù)據(jù)進行統(tǒng)計分析來進行歷史回顧和趨勢分析。由于冷數(shù)據(jù)體量大，查詢涉及的數(shù)據(jù)多，存儲介質性能低，如果不進行優(yōu)化，對冷數(shù)據(jù)的元信息，內容訪問可能出現(xiàn)瓶頸影響業(yè)務使用。

二 、數(shù)據(jù)倉庫分層存儲關鍵技術解析

本章將以阿里云數(shù)據(jù)倉庫AnalyticDB MySQL版（下文簡稱ADB）為原型介紹如何在數(shù)據(jù)倉庫產品中實現(xiàn)分層存儲，并解決其核心挑戰(zhàn)。ADB的整體架構分為三層：

• 第一層是接入層：由多個前端節(jié)點構成，主要負責接入用戶查詢，進行SQL解析、優(yōu)化、調度。

?

• 第二層是計算引擎層：由多個計算節(jié)點組成，負責執(zhí)行用戶查詢。

?

• 第三層是存儲引擎層：由多個存儲節(jié)點組成，用戶數(shù)據(jù)按Shard切片存儲，每個Shard有多個副本保證高可靠和高可用。

1. 冷熱數(shù)據(jù)存儲介質的選擇

對于業(yè)務上的熱數(shù)據(jù)，需采用高性能存儲介質滿足其快速查詢需求。SSD相對HDD來說，成本較高，但其具有高IOPS和高帶寬的特性，因此ADB把熱數(shù)據(jù)層建立在SSD上，并使用數(shù)據(jù)多副本機制，出現(xiàn)存儲節(jié)點異常時，通過切換服務節(jié)點來保證高可靠和高可用。業(yè)務上的冷數(shù)據(jù)，一般是歷史沉淀的業(yè)務數(shù)據(jù)或日志數(shù)據(jù)，這些數(shù)據(jù)體量大，訪問頻度低，因此容量大、成本低是存儲介質的主要選擇因素。對于冷數(shù)據(jù)層，ADB選擇建立在阿里云OSS上。阿里云對象存儲服務OSS作為阿里云提供的海量、低成本、高持久性的云存儲服務，其數(shù)據(jù)設計持久性不低于99.9999999999%，服務可用性不低于99.995%。OSS提供的這些特性滿足了冷數(shù)據(jù)層對成本和可靠性的需求，同時相對于自己維護HDD磁盤，OSS自身具有容量無限擴展能力，滿足海量數(shù)據(jù)存儲需求。并且OSS可以遠程訪問，因此存儲節(jié)點的副本間可以共享數(shù)據(jù)來進一步降低成本。

?

2. 冷熱數(shù)據(jù)定義問題

業(yè)務自身對冷熱數(shù)據(jù)的定義比較明確。比如企業(yè)中一些需要高頻訪問的CRM、ERP數(shù)據(jù)均為熱數(shù)據(jù)。而對于審計日志，或數(shù)天前的訂單數(shù)據(jù)，其訪問頻度低，則可定義為冷數(shù)據(jù)。核心問題是，業(yè)務上的這些數(shù)據(jù)，如何在分層存儲中描述其冷熱屬性并保證存儲位置的準確性。例如企業(yè)促銷活動，大量用戶正在線上進行業(yè)務交互，此時如果分層存儲錯誤的把客戶信息、商品信息等關鍵數(shù)據(jù)遷移到冷區(qū)，則會引起相關查詢性能受損，最終出現(xiàn)客戶登錄受阻，客戶點擊失敗等業(yè)務異常，導致企業(yè)受損。ADB解決這個問題的方法是在用戶建表時指定存儲策略（storage_policy）來精確關聯(lián)業(yè)務上的冷熱數(shù)據(jù)和分層存儲中的冷熱存儲，下面是示例。

?

全熱表

所有數(shù)據(jù)存儲在SSD并且不會降溫，適用于全表數(shù)據(jù)被頻繁訪問，且對訪問性能有較高要求的場景，比如CRM、ERP數(shù)據(jù)。

Create table t1(id int,dt datetime ) distribute by hash(id) storage_policy = 'HOT';

全冷表

所有數(shù)據(jù)存儲在OSS，適用于體量大，訪問頻度低，需要減少存儲成本的場景，比如審計日志數(shù)據(jù)。

Create table t2(id int,dt datetime ) distribute by hash(id) storage_policy = 'COLD';

冷熱混合表
適用于數(shù)據(jù)冷熱有明顯時間窗口的場景。例如最近7天的游戲日志數(shù)據(jù)，廣告點擊數(shù)據(jù)等需高頻訪問，作為熱數(shù)據(jù)存儲，而7天前的數(shù)據(jù)可降溫為冷數(shù)據(jù)，低成本存儲。

?

注：冷熱混合表需配合表的分區(qū)使用。除storage_policy外，還需指定hot_partition_count屬性。hot_partition_count指按分區(qū)值倒序，取最大N個分區(qū)為熱分區(qū)，其余為冷分區(qū)。下例中，表按天分區(qū)，hot_partition_count = 7表示分區(qū)值最大的7個分區(qū)，也就是最近7天的數(shù)據(jù)為熱數(shù)據(jù)。

?

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;

修改冷熱策略
隨業(yè)務的變化，表的訪問特性可能發(fā)生變化，企業(yè)可以隨時修改表的存儲策略來適應新的存儲需求。

（1）由熱表修改為冷表：

Alter table t1 storage_policy = 'COLD';

（2）修改熱分區(qū)的個數(shù)，修改為最近14天的數(shù)據(jù)為熱數(shù)據(jù)：

Alter table t3 storage_policy = 'MIXED' hot_partition_count = 14;

3. 冷熱數(shù)據(jù)自動遷移問題

隨時間流逝，熱數(shù)據(jù)的訪問頻度降低，降溫為冷數(shù)據(jù)。比如一些日志數(shù)據(jù)，在數(shù)天后就很少再訪問，分層存儲需把這部分數(shù)據(jù)由熱數(shù)據(jù)層遷移到冷數(shù)據(jù)層來降低成本。這里的核心問題是如何知道哪部分數(shù)據(jù)的溫度降低了需要遷移？下面通過一個冷熱混合表，來說明ADB解決該問題的方法。如下是一張日志表，最近三天數(shù)據(jù)為熱數(shù)據(jù)，滿足高性能在線查詢需求，三天前數(shù)據(jù)為冷數(shù)據(jù)，低成本存儲并滿足低頻訪問需求。

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;

在本例中，表首先按天分區(qū)。

?

partition by value(date_format(dt, '%Y%m%d')) lifecycle 365

并定義冷熱策略為混合模式，最新3天的數(shù)據(jù)是熱數(shù)據(jù)。

storage_policy = 'MIXED' hot_partition_count = 3

在ADB中，冷熱數(shù)據(jù)以分區(qū)為最小粒度，即一個分區(qū)要么在熱區(qū)，要么在冷區(qū)，然后通過熱分區(qū)窗口來判定某個分區(qū)是否為熱分區(qū)（表屬性中的hot_partition_count定義了熱分區(qū)窗口的大小）。在本例中，假定當前日期是3月4日，則3月2日、3日、4日這三天的數(shù)據(jù)處于熱分區(qū)窗口中，因此是熱分區(qū)。當寫入3月5日的數(shù)據(jù)后，則3月3日、4日、5日這三天數(shù)據(jù)組成了新的熱分區(qū)窗口，3月2日數(shù)據(jù)降溫為冷數(shù)據(jù)，后臺會自動執(zhí)行熱冷遷移，把3月2日的數(shù)據(jù)由熱區(qū)遷移到冷區(qū)。通過熱分區(qū)窗口，客戶根據(jù)業(yè)務場景可以明確定義冷熱邊界，一旦數(shù)據(jù)降溫則自動遷移。

4. 冷數(shù)據(jù)訪問性能問題

冷數(shù)據(jù)存儲在OSS上，OSS是遠程存儲系統(tǒng)并通過網(wǎng)絡訪問，延遲較高。例如判斷文件是否存在，獲取文件長度等元信息操作，單次交互的訪問延遲在毫秒級別。同時，OSS帶寬有限，一個賬號下整體只有GB級別帶寬，提供的整體QPS也只有數(shù)十萬，超過后OSS就會限流。數(shù)據(jù)倉庫內部存儲著大量文件，如果不對OSS訪問做優(yōu)化，則會出現(xiàn)查詢異常。例如查詢可能涉及數(shù)百萬個文件，僅僅獲取這些文件的元信息就會達到OSS的QPS上限，最終導致查詢超時等異常，因此需對OSS的訪問進行優(yōu)化來保證業(yè)務的可用性并提高查詢性能。如下對元信息訪問優(yōu)化和數(shù)據(jù)訪問優(yōu)化分別介紹。

?

元信息訪問優(yōu)化

ADB作為數(shù)據(jù)倉庫，底層存儲了大量的數(shù)據(jù)文件和索引文件。ADB優(yōu)化元信息訪問的方法是對文件進行歸檔，即把一個分區(qū)內的所有文件打包在一個歸檔文件中，并提供一層類POSIX的文件訪問接口，通過這個接口去讀取文件內容。

歸檔文件的Meta里內存儲了每個子文件的偏移和長度等元信息。讀取時，先加載歸檔文件的Meta，只需要一次交互即可拿到所有子文件元信息，交互次數(shù)降低數(shù)百倍。為進一步加速，ADB在存儲節(jié)點的內存和SSD上分別開辟了一小塊空間緩存歸檔文件的Meta，加載過即無需再訪問OSS獲取元信息。同時，歸檔后只需一個輸入流便可讀取所有子文件數(shù)據(jù)內容，避免為每個子文件單獨開啟輸入流的開銷。

?

數(shù)據(jù)訪問優(yōu)化

查詢中，無論是掃描索引，還是讀取數(shù)據(jù)塊，都需要讀取OSS上文件的內容，而OSS無論訪問性能還是訪問帶寬都有限。為加速文件內容的讀取，ADB存儲節(jié)點會自動利用SSD上的一塊空間做數(shù)據(jù)Cache，且Cache的上層提供了類POSIX的文件訪問接口，數(shù)據(jù)掃描算子（Table Scanner）可以像訪問普通文件一樣訪問Cache中的內容。

查詢中對OSS的所有訪問（索引、數(shù)據(jù)等）都可借助SSD Cache加速，只有當數(shù)據(jù)不在Cache中時才會訪問OSS。針對這塊Cache，ADB還做了如下優(yōu)化：

• 多粒度的Cache Block，加載元信息時使用較小的Block，加載數(shù)據(jù)時使用較大的Block，以此提高Cache空間利用率。

?

• 元數(shù)據(jù)預熱，自動加載數(shù)據(jù)和索引的元數(shù)據(jù)到Cache中并鎖定，以實現(xiàn)元數(shù)據(jù)高效訪問。

?

• 基于冷熱訪問隊列的類LRU算法，實現(xiàn)無鎖化高性能換入換出。

?

• 自動IO合并，相鄰數(shù)據(jù)的訪問合并為一個請求，減少與OSS的交互次數(shù)。

?

三、總結

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

?

關于我們

AnalyticDB MySQL是阿里巴巴自主研發(fā)，經(jīng)過超大規(guī)模以及核心業(yè)務驗證的PB級實時OLAP數(shù)據(jù)倉庫。AnalyticDB MySQL存儲團隊致力于實現(xiàn)全球領先的云原生數(shù)據(jù)倉庫存儲服務，提供云原生、實時化、高性能、低成本、安全可靠的企業(yè)級數(shù)倉存儲能力，通過持續(xù)不斷的自研存儲技術積累和突破，幫助數(shù)以萬計的用戶享受云原生實時化分析能力，實現(xiàn)數(shù)據(jù)價值在線化。

原文鏈接

本文為阿里云原創(chuàng)內容，未經(jīng)允許不得轉載。

總結

以上是生活随笔為你收集整理的深度 | 数据仓库分层存储技术揭秘的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。