Apache Doris冷熱分層技術(shù)對數(shù)據(jù)存儲有何好處

在數(shù)據(jù)分析的實際場景中，冷熱數(shù)據(jù)往往面臨著不同的查詢頻次及響應(yīng)速度要求。例如在電商訂單場景中，用戶經(jīng)常訪問近 6 個月的訂單，時間較久遠的訂單訪問次數(shù)非常少；在行為分析場景中，需支持近期流量數(shù)據(jù)的高頻查詢且時效性要求高，但為了保證歷史數(shù)據(jù)隨時可查，往往要求數(shù)據(jù)保存周期更為久遠；在日志分析場景中，歷史數(shù)據(jù)的訪問頻次很低，但需長時間備份以保證后續(xù)的審計和回溯的工作...往往歷史數(shù)據(jù)的應(yīng)用價值會隨著時間推移而降低，且需要應(yīng)對的查詢需求也會隨之銳減。而隨著歷史數(shù)據(jù)的不斷增多，如果我們將所有數(shù)據(jù)存儲在本地，將造成大量的資源浪費。

為了解決滿足以上問題，冷熱數(shù)據(jù)分層技術(shù)應(yīng)運而生，以更好滿足企業(yè)降本增效的趨勢。顧名思義，冷熱分層是將冷熱數(shù)據(jù)分別存儲在成本不同的存儲介質(zhì)上，例如熱數(shù)據(jù)存儲在成本更高的 SSD 盤上、以提高時效數(shù)據(jù)的查詢速度和響應(yīng)能力，而冷數(shù)據(jù)則存儲在相對低成本的 HDD 盤甚至更為廉價的對象存儲上，以降低存儲成本。我們還可以根據(jù)實際業(yè)務(wù)需求進行靈活的配置和調(diào)整，以滿足不同場景的要求。 冷熱分層一般適用于以下需求場景：

數(shù)據(jù)存儲周期長：面對歷史數(shù)據(jù)的不斷增加，存儲成本也隨之增加；

冷熱數(shù)據(jù)訪問頻率及性能要求不同：熱數(shù)據(jù)訪問頻率高且需要快速響應(yīng)，而冷數(shù)據(jù)訪問頻率低且響應(yīng)速度要求不高；

數(shù)據(jù)備份和恢復(fù)成本高：備份和恢復(fù)大量數(shù)據(jù)需要消耗大量的時間和資源。

.....

更高效率的冷熱分層技術(shù)

自 Apache Doris 0.12 版本引入動態(tài)分區(qū)功能，開始支持對表分區(qū)進行生命周期管理，可以設(shè)置熱數(shù)據(jù)轉(zhuǎn)冷時間以及存儲介質(zhì)標(biāo)識，通過后臺任務(wù)將熱數(shù)據(jù)從 SSD 自動冷卻到 HDD，以幫助用戶較大程度地降低存儲成本。用戶可以在建表屬性中配置參數(shù)storage_cooldown_time或者dynamic_partition.hot_partition_num來控制數(shù)據(jù)從 SSD 冷卻到 HDD，當(dāng)分區(qū)滿足冷卻條件時，Doris 會自動執(zhí)行任務(wù)。而 HDD 上的數(shù)據(jù)是以多副本的方式存儲的，并沒有做到最大程度的成本節(jié)約，因此對于冷數(shù)據(jù)存儲成本仍然有較大的優(yōu)化空間。為了幫助用戶進一步降低存儲成本，社區(qū)在已有功能上進行了優(yōu)化，并在 Apache Doris 2.0 版本中推出了冷熱數(shù)據(jù)分層的功能。冷熱數(shù)據(jù)分層功能使 Apache Doris 可以將冷數(shù)據(jù)下沉到存儲成本更加低廉的對象存儲中，同時冷數(shù)據(jù)在對象存儲上的保存方式也從多副本變?yōu)閱胃北?，存儲成本進一步降至原先的三分之一，同時也減少了因存儲附加的計算資源成本和網(wǎng)絡(luò)開銷成本。如下圖所示，在 Apache Doris 2.0 版本中支持三級存儲，分別是 SSD、HDD 和對象存儲。用戶可以配置使數(shù)據(jù)從 SSD 下沉到 HDD，并使用冷熱分層功能將數(shù)據(jù)從 SSD 或者 HDD 下沉到對象存儲中。

以公有云價格為例，云磁盤的價格通常是對象存儲的 5-10 倍，如果可以將 80% 的冷數(shù)據(jù)保存到對象存儲中，存儲成本至少可降低 70%。 我們使用以下公式計算節(jié)約的成本，設(shè)冷數(shù)據(jù)比率為 rate，對象存儲價格為 OSS，云磁盤價格為 CloudDisk

這里我們假設(shè)用戶有 100TB 的數(shù)據(jù)，我們按照不同比例將冷數(shù)據(jù)遷移到對象存儲，來計算一下如果使用冷熱分層之后，相較于全量使用普通云盤、SSD 云盤可節(jié)約多少成本。

阿里云 OSS 標(biāo)準(zhǔn)存儲成本是 120 元/ T /月

阿里云普通云盤的價格是 300 元/ T /月

阿里云 SSD 云盤的價格是 1000 元/ T /月

例如在 80% 冷數(shù)據(jù)占比的情況下，剩余 20% 使用普通云盤每月僅花費 80T*120 + 20T * 300 = 15600元，而全量使用普通云盤則需要花費 30000 元，通過冷熱數(shù)據(jù)分層節(jié)省了48%的存儲成本。如果用戶使用的是 SSD 云盤，那么花費則會從全量使用需花費的 100000 元降低到 80T*120 + 20T * 1000 = 29600元，存儲成本最高降低超過 70%！

冷熱分層使用指南

若要使用 Doris 的冷熱分層功能，首先需要準(zhǔn)備一個對象存儲的 Bucket 并獲取對應(yīng)的 AK/SK。當(dāng)準(zhǔn)備就緒之后，下面為具體的使用步驟：

1. 創(chuàng)建 Resource

可以使用對象存儲的 Bucket 以及 AK/SK 創(chuàng)建 Resource，目前支持 AWS、Azure、阿里云、華為云、騰訊云、百度云等多個云的對象存儲。

CREATE?RESOURCE?IF?NOT?EXISTS?"${resource_name}" ???
?????PROPERTIES( ???????
?????"type"="s3", ????????
????"s3.endpoint"?=?"${S3Endpoint}", ??????
??????"s3.region"?=?"${S3Region}", ??????????
??"s3.root.path"?=?"path/to/root", ???????
?????"s3.access_key"?=?"${S3AK}", ??????
??????"s3.secret_key"?=?"${S3SK}", ???????
?????"s3.connection.maximum"?=?"50", ????????
????"s3.connection.request.timeout"?=?"3000", ??????
??????"s3.connection.timeout"?=?"1000", ????????
????"s3.bucket"?=?"${S3BucketName}" ?????
???);

2. 創(chuàng)建 Storage Policy 可以通過 Storage Policy 控制數(shù)據(jù)冷卻時間，目前支持相對和絕對兩種冷卻時間的設(shè)置。

CREATE?STORAGE?POLICY?testPolicy PROPERTIES( ??"storage_resource"?=?"remote_s3", ??"cooldown_ttl"?=?"1d" ); 例如上方代碼中名為testPolicy的storage policy設(shè)置了新導(dǎo)入的數(shù)據(jù)將在一天后開始冷卻，并且冷卻后的冷數(shù)據(jù)會存放到remote_s3所表示的對象存儲的?root path下。除了設(shè)置 TTL 以外，在 Policy 中也支持設(shè)置冷卻的時間點，可以直接設(shè)置為：

CREATE?STORAGE?POLICY?testPolicyForTTlDatatime
PROPERTIES(
??"storage_resource"?=?"remote_s3",
??"cooldown_datetime"?=?"2023-06-07?2100"
);

3. 給表或者分區(qū)設(shè)置 Storage Policy 在創(chuàng)建出對應(yīng)的 Resource 和 Storage Policy 之后，我們可以在建表的時候?qū)φ麖埍碓O(shè)置 Cooldown Policy，也可以針對某個 Partition 設(shè)置 Cooldown Policy。這里以 TPCH 測試數(shù)據(jù)集中的 Lineitem 表舉例。如果需要將整張表都設(shè)置冷卻的策略，則可以直接在整張表的 Properties 中設(shè)置：

CREATE?TABLE?IF?NOT?EXISTS?lineitem1?(
????????????L_ORDERKEY????INTEGER?NOT?NULL,
????????????L_PARTKEY?????INTEGER?NOT?NULL,
????????????L_SUPPKEY?????INTEGER?NOT?NULL,
????????????L_LINENUMBER??INTEGER?NOT?NULL,
????????????L_QUANTITY????DECIMAL(15,2)?NOT?NULL,
????????????L_EXTENDEDPRICE??DECIMAL(15,2)?NOT?NULL,
????????????L_DISCOUNT????DECIMAL(15,2)?NOT?NULL,
????????????L_TAX?????????DECIMAL(15,2)?NOT?NULL,
????????????L_RETURNFLAG??CHAR(1)?NOT?NULL,
????????????L_LINESTATUS??CHAR(1)?NOT?NULL,
????????????L_SHIPDATE????DATEV2?NOT?NULL,
????????????L_COMMITDATE??DATEV2?NOT?NULL,
????????????L_RECEIPTDATE?DATEV2?NOT?NULL,
????????????L_SHIPINSTRUCT?CHAR(25)?NOT?NULL,
????????????L_SHIPMODE?????CHAR(10)?NOT?NULL,
????????????L_COMMENT??????VARCHAR(44)?NOT?NULL
????????????)
????????????DUPLICATE?KEY(L_ORDERKEY,?L_PARTKEY,?L_SUPPKEY,?L_LINENUMBER)
????????????PARTITION?BY?RANGE(`L_SHIPDATE`)
????????????(
????????????????PARTITION?`p202301`?VALUES?LESS?THAN?("2017-02-01"),
????????????????PARTITION?`p202302`?VALUES?LESS?THAN?("2017-03-01")
????????????)
????????????DISTRIBUTED?BY?HASH(L_ORDERKEY)?BUCKETS?3
????????????PROPERTIES?(
????????????"replication_num"?=?"3",
????????????"storage_policy"?=?"${policy_name}"
????????????)

用戶可以通過show tablets獲得每個 Tablet 的信息，其中 CooldownReplicaId 不為 -1 并且 CooldownMetaId 不為空的 Tablet 說明使用了 Storage Policy。如下方代碼，通過show tablets可以看到上面的 Table 的所有 Tablet 都設(shè)置了 ?CooldownReplicaId 和 CooldownMetaId，這說明整張表都是使用了 Storage Policy。

???????????????TabletId:?3674797
??????????????ReplicaId:?3674799
??????????????BackendId:?10162
?????????????SchemaHash:?513232100
????????????????Version:?1
??????LstSuccessVersion:?1
???????LstFailedVersion:?-1
??????????LstFailedTime:?NULL
??????????LocalDataSize:?0
?????????RemoteDataSize:?0
???????????????RowCount:?0
??????????????????State:?NORMAL
LstConsistencyCheckTime:?NULL
???????????CheckVersion:?-1
???????????VersionCount:?1
??????????????QueryHits:?0
???????????????PathHash:?8030511811695924097
????????????????MetaUrl:?http://172.16.0.16:6781/api/meta/header/3674797
???????CompactionStatus:?http://172.16.0.16:6781/api/compaction/show?tablet_id=3674797
??????CooldownReplicaId:?3674799
?????????CooldownMetaId:?TUniqueId(hi:-8987737979209762207,?lo:-2847426088899160152)

我們也可以對某個具體的 Partition 設(shè)置 Storage Policy，只需要在 Partition 的 Properties 中加上具體的 Policy Name 即可：

CREATE?TABLE?IF?NOT?EXISTS?lineitem1?(
????????????L_ORDERKEY????INTEGER?NOT?NULL,
????????????L_PARTKEY?????INTEGER?NOT?NULL,
????????????L_SUPPKEY?????INTEGER?NOT?NULL,
????????????L_LINENUMBER??INTEGER?NOT?NULL,
????????????L_QUANTITY????DECIMAL(15,2)?NOT?NULL,
????????????L_EXTENDEDPRICE??DECIMAL(15,2)?NOT?NULL,
????????????L_DISCOUNT????DECIMAL(15,2)?NOT?NULL,
????????????L_TAX?????????DECIMAL(15,2)?NOT?NULL,
????????????L_RETURNFLAG??CHAR(1)?NOT?NULL,
????????????L_LINESTATUS??CHAR(1)?NOT?NULL,
????????????L_SHIPDATE????DATEV2?NOT?NULL,
????????????L_COMMITDATE??DATEV2?NOT?NULL,
????????????L_RECEIPTDATE?DATEV2?NOT?NULL,
????????????L_SHIPINSTRUCT?CHAR(25)?NOT?NULL,
????????????L_SHIPMODE?????CHAR(10)?NOT?NULL,
????????????L_COMMENT??????VARCHAR(44)?NOT?NULL
????????????)
????????????DUPLICATE?KEY(L_ORDERKEY,?L_PARTKEY,?L_SUPPKEY,?L_LINENUMBER)
????????????PARTITION?BY?RANGE(`L_SHIPDATE`)
????????????(
????????????????PARTITION?`p202301`?VALUES?LESS?THAN?("2017-02-01")?("storage_policy"?=?"${policy_name}"),
????????????????PARTITION?`p202302`?VALUES?LESS?THAN?("2017-03-01")
????????????)
????????????DISTRIBUTED?BY?HASH(L_ORDERKEY)?BUCKETS?3
????????????PROPERTIES?(
????????????"replication_num"?=?"3"
????????????)

這張 Lineitem1 設(shè)置了兩個分區(qū)，每個分區(qū) 3 個 Bucket，另外副本數(shù)設(shè)置為 3，可以計算出一共有 2*3 = 6 個 Tablet，那么副本數(shù)一共是 6*3 = 18 個 Replica，通過show tablets命令可以查看到所有的 Tablet 以及 Replica 的信息，可以看到只有部分 Tablet 的 Replica 是設(shè)置了CooldownReplicaId 和 CooldownMetaId 。用戶可以通過ADMIN SHOW REPLICA STATUS FROM TABLE PARTITION(PARTITION)查看 Partition 下的 Tablet 以及Replica，通過對比可以發(fā)現(xiàn)其中只有屬于 p202301 這個 Partition 的 Tablet 的 Replica 設(shè)置了CooldownReplicaId 和 CooldownMetaId，而屬于 p202302 這個 Partition 下的數(shù)據(jù)沒有設(shè)置，所以依舊會全部存放到本地磁盤。以上表的 Tablet 3691990 為例，該 Tablet 屬于 p202301，截取 show tablets 拿到的部分關(guān)鍵信息如下：

*****************************************************************
???????????????TabletId:?3691990
??????????????ReplicaId:?3691991
??????CooldownReplicaId:?3691993
?????????CooldownMetaId:?TUniqueId(hi:-7401335798601697108,?lo:3253711199097733258)
*****************************************************************
???????????????TabletId:?3691990
??????????????ReplicaId:?3691992
??????CooldownReplicaId:?3691993
?????????CooldownMetaId:?TUniqueId(hi:-7401335798601697108,?lo:3253711199097733258)
*****************************************************************
???????????????TabletId:?3691990
??????????????ReplicaId:?3691993
??????CooldownReplicaId:?3691993
?????????CooldownMetaId:?TUniqueId(hi:-7401335798601697108,?lo:3253711199097733258)

? 可以觀察到 3691990 的 3 個副本都選擇了 3691993 副本作為 CooldownReplica，在用戶指定的 Resource 上也只會保存這個副本的數(shù)據(jù)。

4. 查看數(shù)據(jù)信息

我們可以按照上述 3 中的 Linetem1 來演示如何查看是使用冷熱數(shù)據(jù)分層策略的 Table 的數(shù)據(jù)信息，一般可以通過show tablets from lineitem1?直接查看這張表的 Tablet 信息。Tablet 信息中區(qū)分了 LocalDataSize 和 RemoteDataSize，前者表示存儲在本地的數(shù)據(jù)，后者表示已經(jīng)冷卻并移動到對象存儲上的數(shù)據(jù)。具體信息可見下方代碼：下方為數(shù)據(jù)剛導(dǎo)入到 BE 時的數(shù)據(jù)信息，可以看到數(shù)據(jù)還全部存儲在本地。

***************************?1.?row?***************************

???????????????TabletId:?2749703
??????????????ReplicaId:?2749704
??????????????BackendId:?10090
?????????????SchemaHash:?1159194262
????????????????Version:?3
??????LstSuccessVersion:?3
???????LstFailedVersion:?-1
??????????LstFailedTime:?NULL
??????????LocalDataSize:?73001235
?????????RemoteDataSize:?0
???????????????RowCount:?1996567
??????????????????State:?NORMAL
LstConsistencyCheckTime:?NULL
???????????CheckVersion:?-1
???????????VersionCount:?3
??????????????QueryHits:?0
???????????????PathHash:?-8567514893400420464
????????????????MetaUrl:?http://172.16.0.8:6781/api/meta/header/2749703
???????CompactionStatus:?http://172.16.0.8:6781/api/compaction/show?tablet_id=2749703
??????CooldownReplicaId:?2749704
?????????CooldownMetaId:

? 當(dāng)數(shù)據(jù)到達冷卻時間后，再次進行?show tablets from table可以看到對應(yīng)的數(shù)據(jù)變化。

***************************?1.?row?***************************
???????????????TabletId:?2749703
??????????????ReplicaId:?2749704
??????????????BackendId:?10090
?????????????SchemaHash:?1159194262
????????????????Version:?3
??????LstSuccessVersion:?3
???????LstFailedVersion:?-1
??????????LstFailedTime:?NULL
??????????LocalDataSize:?0
?????????RemoteDataSize:?73001235
???????????????RowCount:?1996567
??????????????????State:?NORMAL
LstConsistencyCheckTime:?NULL
???????????CheckVersion:?-1
???????????VersionCount:?3
??????????????QueryHits:?0
???????????????PathHash:?-8567514893400420464
????????????????MetaUrl:?http://172.16.0.8:6781/api/meta/header/2749703
???????CompactionStatus:?http://172.16.0.8:6781/api/compaction/show?tablet_id=2749703
??????CooldownReplicaId:?2749704
?????????CooldownMetaId:?TUniqueId(hi:-8697097432131255833,?lo:9213158865768502666)

? 除了通過上述命令查看數(shù)據(jù)信息之外，我們也可以在對象存儲上查看冷數(shù)據(jù)的信息。以騰訊云為例，可以在 Policy 指定的 Bucket 的 Path 下可以查看冷卻過后的數(shù)據(jù)的信息：

進入對應(yīng)文件后可以看到數(shù)據(jù)和元數(shù)據(jù)文件

我們可以看到在對象存儲上數(shù)據(jù)是單副本

5. 查詢

假設(shè) Table Lineitem1 中的所有數(shù)據(jù)都已經(jīng)冷卻并且上傳到對象存儲中，如果用戶在 Lineitem1 上進行對應(yīng)的查詢，Doris 會根據(jù)對應(yīng) Partition 使用的 Policy 信息找到對應(yīng)的 Bucket 的 Root Path，并根據(jù)不同 Tablet 下的 Rowset 信息下載查詢所需的數(shù)據(jù)到本地進行運算。 Doris 2.0 在查詢上進行了優(yōu)化，冷數(shù)據(jù)第一次查詢會進行完整的 S3 網(wǎng)絡(luò) IO，并將 Remote Rowset 的數(shù)據(jù)下載到本地后，存放到對應(yīng)的 Cache 之中，后續(xù)的查詢將自動命中 Cache，以此來保證查詢效率。(性能對比可見后文評測部分）。

6. 冷卻后繼續(xù)導(dǎo)入數(shù)據(jù)

在某些場景下，用戶需要對歷史數(shù)據(jù)進行數(shù)據(jù)的修正或補充數(shù)據(jù)，而新數(shù)據(jù)會按照分區(qū)列信息導(dǎo)入到對應(yīng)的 Partition中。在 Doris 中，每次數(shù)據(jù)導(dǎo)入都會產(chǎn)生一個新的 Rowset，以保證冷數(shù)據(jù)的 Rowset 在不會影響新導(dǎo)入數(shù)據(jù)的 Rowset 的前提下，滿足冷熱數(shù)據(jù)同時存儲的需求。Doris 2.0 的冷熱分層粒度是基于 Rowset 的，當(dāng)?shù)竭_冷卻時間時會將當(dāng)前滿足條件的 Rowset 全部上傳到 S3 上并刪除本地數(shù)據(jù)，之后新導(dǎo)入的數(shù)據(jù)生成的新 Rowset 會在到達冷卻時間后也上傳到 S3。

查詢性能測試

為了測試使用冷熱分層功能之后，查詢對象存儲中的數(shù)據(jù)是否占用會較大網(wǎng)絡(luò) I/O，從而影響查詢性能，因此我們以 SSB SF100 標(biāo)準(zhǔn)集為例，對冷熱分層表和非冷熱分層表進行了查詢耗時的對比測試。配置：均在 3 臺 16C 64G 的機器上部署 1FE、3BE 的集群

如上圖所示，在充分預(yù)熱之后(數(shù)據(jù)已經(jīng)緩存在 Cache 中)，冷熱分層表共耗時 5.799s，非冷熱分層表共耗時 5.822s，由此可知，使用冷熱分層查詢表和非冷熱分層表的查詢性能幾乎相同。這表明，使用 Doris 2.0 提供的冷熱分層功能，不會對查詢性能造成的影響。

冷熱分層技術(shù)的具體實現(xiàn)

存儲方式的優(yōu)化

在 Doris 之前的版本中，數(shù)據(jù)從 SSD 冷卻到 HDD 后，為了保證數(shù)據(jù)的高可用和可靠性，通常會將一個 Tablet 存儲多份副本在不同 BE 上，為了進一步降低成本，我們在 Apache Doris 2.0 版本引入了對象存儲，推出了冷熱分層功能。由于對象存儲本身具有高可靠高可用性，冷數(shù)據(jù)在對象存儲上只需要一份即可，元數(shù)據(jù)以及熱數(shù)據(jù)仍然保存在 BE，我們稱之為本地副本，本地副本同步冷數(shù)據(jù)的元數(shù)據(jù)，這樣就可以實現(xiàn)多個本地副本共用一份冷卻數(shù)據(jù)的目的，有效避免冷數(shù)據(jù)占用過多的存儲空間，從而降低數(shù)據(jù)存儲成本。具體而言，Doris 的 FE 會從 Tablet 的所有可用本地副本中選擇一個本地副本作為上傳數(shù)據(jù)的 Leader，并通過 Doris 的周期匯報機制同步 Leader 的信息給其它本地副本。在 Leader 上傳冷卻數(shù)據(jù)時，也會將冷卻數(shù)據(jù)的元數(shù)據(jù)上傳到對象存儲，以便其他副本同步元數(shù)據(jù)。因此，任何本地副本都可以提供查詢所需的數(shù)據(jù)，同時也保證了數(shù)據(jù)的高可用性和可靠性。

冷數(shù)據(jù) Compaction

在一些場景下會有大量修補數(shù)據(jù)的需求，在大量補數(shù)據(jù)的場景下往往需要刪除歷史數(shù)據(jù)，刪除可以通過delete where實現(xiàn)，Doris 在 Compaction 時會對符合刪除條件的數(shù)據(jù)做物理刪除?；谶@些場景，冷熱分層也必須實現(xiàn)對冷數(shù)據(jù)進行 Compaction，因此在 Doris 2.0 版本中我們支持了對冷卻到對象存儲的冷數(shù)據(jù)進行 Compaction（ColdDataCompaction）的能力，用戶可以通過冷數(shù)據(jù) Compaction，將分散的冷數(shù)據(jù)重新組織并壓縮成更緊湊的格式，從而減少存儲空間的占用，提高存儲效率。

Doris 對于本地副本是各自進行 Compaction，在后續(xù)版本中會優(yōu)化為單副本進行 Compaction。由于冷數(shù)據(jù)只有一份，因此天然的單副本做 Compaction 是最優(yōu)秀方案，同時也會簡化處理數(shù)據(jù)沖突的操作。BE 后臺線程會定期從冷卻的 Tablet 按照一定規(guī)則選出 N 個 Tablet 發(fā)起 ColdDataCompaction。與數(shù)據(jù)冷卻流程類似，只有 CooldownReplica 能執(zhí)行該 Tablet 的 ColdDataCompaction。Compaction下刷數(shù)據(jù)時每積累一定大?。J(rèn)5MB）的數(shù)據(jù)，就會上傳一個 Part 到對象，而不會占用大量本地存儲空間。Compaction 完成后，CooldownReplica 將冷卻數(shù)據(jù)的元數(shù)據(jù)更新到對象存儲，其他 Replica 只需從對象存儲同步元數(shù)據(jù)，從而大量減少對象存儲的 IO 和節(jié)點自身的 CPU 開銷。

冷數(shù)據(jù) Cache

冷數(shù)據(jù) Cache 在數(shù)據(jù)查詢中具有重要的作用。冷數(shù)據(jù)通常是數(shù)據(jù)量較大、使用頻率較低的數(shù)據(jù)，如果每次查詢都需要從對象中讀取，會導(dǎo)致查詢效率低下。通過冷數(shù)據(jù) Cache 技術(shù)，可以將冷數(shù)據(jù)緩存在本地磁盤中，提高數(shù)據(jù)讀取速度，從而提高查詢效率。而 Cache 的粒度大小直接影響 Cache 的效率，比較大的粒度會導(dǎo)致 Cache 空間以及帶寬的浪費，過小粒度的 Cache 會導(dǎo)致對象存儲 IO 效率低下，Apache Doris 采用了以 Block 為粒度的 Cache 實現(xiàn)。如前文所述，Apache Doris 的冷熱分層會將冷數(shù)據(jù)上傳到對象存儲上，上傳成功后本地的數(shù)據(jù)將會被刪除。因此，后續(xù)涉及到冷數(shù)據(jù)的查詢均需要對對象存儲發(fā)起 IO 。

為了優(yōu)化性能，Apache Doris 實現(xiàn)了基于了 Block 粒度的 Cache 功能，當(dāng)遠程數(shù)據(jù)被訪問時會先將數(shù)據(jù)按照 Block 的粒度下載到本地的 Block Cache 中存儲，且 Block Cache 中的數(shù)據(jù)訪問性能和非冷熱分層表的數(shù)據(jù)性能一致（可見前文查詢性能測試）。具體來講，前文提到 Doris 的冷熱分層是在 Rowset 級別進行的，當(dāng)某個 Rowset 在冷卻后其所有的數(shù)據(jù)都會上傳到對象存儲上。而 Doris 在進行查詢的時候會讀取涉及到的 Tablet 的 Rowset 進行數(shù)據(jù)聚合和運算，當(dāng)讀取到冷卻的 Rowset 時，會把查詢需要的冷數(shù)據(jù)下載到本地 Block Cache 之中?；谛阅芸剂?，Doris 的 Cache 按照 Block 對數(shù)據(jù)進行劃分。Block Cache 本身采用的是簡單的 LRU 策略，可以保證越是使用程度較高數(shù)據(jù)越能在 Block Cache 中存放的久。

寫在最后

Apache Doris 2.0 版本實現(xiàn)了基于對象存儲的冷熱數(shù)據(jù)分層，該功能可以幫助我們有效降低存儲成本、提高存儲效率，并提高數(shù)據(jù)查詢和處理效率。未來，Apache Doris 將會基于冷熱數(shù)據(jù)分層以及彈性計算節(jié)點，為用戶提供更好的資源彈性、更低的使用成本以及更靈活的負載隔離服務(wù)。在前段時間推出的 Apache Doris 2.0 Alpha 版本中，已經(jīng)實現(xiàn)了單節(jié)點數(shù)萬 QPS 的高并發(fā)點查詢能力、高性能的倒排索引、高效穩(wěn)定的內(nèi)存管理、基于代價模型的全新查詢優(yōu)化器以及 Pipeline 執(zhí)行引擎等，與此同時， Apache Doris 2.0 Beta 版本也將于近兩周上線，除了已知功能外，還會進一步支持 Unique 模型上的部分列更新，并將 Pipeline 執(zhí)行引擎、查詢優(yōu)化器、主鍵模型 Merge-on-Write 等最新特性作為穩(wěn)定功能默認(rèn)開啟，并包含了社區(qū)近期對性能方面的諸多優(yōu)化，詳細性能測試結(jié)果敬請期待后續(xù)社區(qū)動態(tài)。

作者介紹：

楊勇強，SelectDB?聯(lián)合創(chuàng)始人、技術(shù)副總裁岳靖、程宇軒，SelectDB 存儲層研發(fā)工程師

編輯：黃飛

閱讀全文

SSD(122013) SSD(122013)
數(shù)據(jù)存儲(52845) 數(shù)據(jù)存儲(52845)

91欧美超碰AV自拍|国产成年人性爱视频免费看|亚洲日韩欧美一厂二区入|人人看人人爽人人操aV|丝袜美腿视频一区二区在线看|人人操人人爽人人爱|婷婷五月天超碰|97色色欧美亚州A√|另类A√无码精品一级av|欧美特级日韩特级

搜索歷史

Apache Doris冷熱分層技術(shù)對數(shù)據(jù)存儲有何好處

評論