隨著數(shù)據(jù)集規(guī)模的不斷擴(kuò)大，采用 Amazon S3 和谷歌云存儲(chǔ)（ GCS ）等云存儲(chǔ)平臺(tái)變得越來越流行。盡管節(jié)點(diǎn)本地存儲(chǔ)可能會(huì)帶來更好的 IO 性能，但在數(shù)據(jù)集超過單 TB 規(guī)模后，這種方法可能變得不切實(shí)際。

在遠(yuǎn)程存儲(chǔ)是唯一實(shí)用的解決方案的情況下， PyData 生態(tài)系統(tǒng)的許多部分已經(jīng)采用文件系統(tǒng)規(guī)范（fsspec）作為通用文件系統(tǒng) API 。自從s3fs和gcsfs推出以來，fsspec已經(jīng)為用戶提供了足夠的遠(yuǎn)程存儲(chǔ)訪問權(quán)限，但內(nèi)部字節(jié)傳輸和緩存算法還沒有對(duì)拼花等高性能文件格式進(jìn)行特定于格式的優(yōu)化。

關(guān)鍵教訓(xùn)

在本文中，我們將介紹fsspec.parquet模塊，它為遠(yuǎn)程拼花文件提供了一種支持格式的字節(jié)緩存優(yōu)化。這個(gè)模塊是實(shí)驗(yàn)性的，并且僅限于一個(gè)公共 API ：open_parquet_file。

此 API 提供了更快的遠(yuǎn)程文件訪問。與 cuDF 和 cuDF 數(shù)據(jù)幀庫中的默認(rèn)read_parquet行為相比，對(duì)于大型拼花地板文件的部分 I / O （列塊和行組選擇），整體吞吐量有了一致的性能提升。

我們還討論了這個(gè)新模塊中使用的優(yōu)化，并給出了初步的性能結(jié)果。

什么是 fsspec ？

文件系統(tǒng)規(guī)范（fsspec）是一個(gè)開源項(xiàng)目，為各種后端存儲(chǔ)系統(tǒng)提供統(tǒng)一的 Python 接口。fsspec對(duì)應(yīng)于一個(gè)特定的fsspec Python 庫和一個(gè)更大的 GitHub 組織，其中包含許多特定于系統(tǒng)的存儲(chǔ)庫（例如s3fs和gcsfs）。

在基于 Python 的庫或應(yīng)用程序中使用fsspec的優(yōu)點(diǎn)是，類似于 POSIX 的文件 API 可以從遠(yuǎn)程對(duì)象和本地文件進(jìn)行讀寫。當(dāng)一個(gè)基于云的對(duì)象被一個(gè)fsspec兼容的文件系統(tǒng)打開時(shí)，底層應(yīng)用程序會(huì)得到一個(gè)AbstractBufferedFile對(duì)象，或者其他一些類似文件的對(duì)象，這些對(duì)象被設(shè)計(jì)為使用原生 Python 文件對(duì)象進(jìn)行 duck type 操作。現(xiàn)在，這些類似文件的對(duì)象可以像本地 Python 文件句柄一樣處理。

一個(gè)明顯的區(qū)別是AbstractBufferedFile對(duì)象必須在內(nèi)部使用特定于文件系統(tǒng)的命令，以便向遠(yuǎn)程存儲(chǔ)系統(tǒng)輸入和從遠(yuǎn)程存儲(chǔ)系統(tǒng)獲取字節(jié)。由于內(nèi)部數(shù)據(jù)傳輸操作的延遲通常高于本地磁盤訪問，fsspec提供了幾種緩存策略來預(yù)取數(shù)據(jù)，同時(shí)避免了許多小請(qǐng)求。

在這篇文章的后面，我們將解釋為什么對(duì)于大型拼花地板文件，默認(rèn)緩存策略通常不太理想，以及新的KnownPartsOfAFile（“部件”）選項(xiàng)如何顯著減少讀取延遲。

什么是拼花地板？

Parquet 是一種面向二進(jìn)制列的數(shù)據(jù)存儲(chǔ)格式，設(shè)計(jì)時(shí)考慮了性能、壓縮和部分 I / O 。由于與 CSV 等文本格式文件相比具有顯著的性能優(yōu)勢(shì)，自 2013 年首次發(fā)布以來，開源格式的受歡迎程度迅速增長(zhǎng)。

為了理解 Fsspec 拼花地板模塊中使用的優(yōu)化，對(duì)拼花地板規(guī)范有一個(gè)高層次的理解是很有用的。圖 1 顯示，所有拼花文件都由一組連續(xù)存儲(chǔ)的行組組成，而這些行組中的每一個(gè)都包括一組連續(xù)存儲(chǔ)的列塊。

圖 1 拼花地板文件格式的高級(jí)視覺表示

總之，拼花地板文件中的大部分字節(jié)都對(duì)應(yīng)于這些列塊。剩余的字節(jié)用于將文件元數(shù)據(jù)存儲(chǔ)在舊格式的頁腳中。此頁腳元數(shù)據(jù)包括文件中每個(gè)列塊的字節(jié)偏移量和可選統(tǒng)計(jì)信息（min、max、valid count、null count）。

由于這些重要信息整合在頁腳中，因此只需對(duì)拼花地板文件的結(jié)尾進(jìn)行采樣，即可確定文件中每個(gè)列塊的具體位置。

fsspec 新拼花模塊的用途是什么？

fsspec已經(jīng)是 Python 下加載拼花地板文件的最常用方法。新fsspec.parquet模塊的主要目的是為這項(xiàng)任務(wù)提供優(yōu)化的實(shí)用程序。

在內(nèi)部，這個(gè)新的實(shí)用程序（open_parquet_file）基本上將一個(gè)傳統(tǒng)的開放調(diào)用封裝在特定于拼花地板的邏輯中，該邏輯設(shè)計(jì)用于在用戶啟動(dòng)顯式讀取操作之前，開始將所有相關(guān)數(shù)據(jù)從遠(yuǎn)程文件傳輸?shù)奖镜貎?nèi)存。

盡管任何大小的讀取都可能受益于此新實(shí)用程序，但當(dāng)讀取操作僅針對(duì)所有列和行組的子集時(shí)，可以看到最顯著的改進(jìn)。例如，當(dāng)遠(yuǎn)程讀取使用列投影時(shí)，相同的列列表可以直接傳遞給open_parquet_file：

from fsspec.parquet import open_parquet_file import pandas as pd path = “://my-bucket/my-data” columns = [“col1”, “col2”] options = {“necessary”: ”credentials”} with open_parquet_file( path, columns=columns, storage_options=options, ) as f: df = pd.read_parquet(path, columns=columns)

如前所述，fsspec新open_parquet_file函數(shù)的主要目的是通過在AbstractBufferedFile.open中使用支持格式的緩存策略，提高大型拼花地板文件的讀取性能。

要理解拼花地板模塊使用的特定優(yōu)化為什么是有益的，首先了解簡(jiǎn)單的無緩存方法以及默認(rèn)的預(yù)讀策略是有幫助的。

了解無緩存和預(yù)讀方法

圖 2 顯示了對(duì)于 naive 和 naive 讀調(diào)用序列，無緩存文件訪問可能如何映射到read_parquet操作中的遠(yuǎn)程 get 調(diào)用（在遠(yuǎn)程文件已經(jīng)打開之后）。

圖 2 從遠(yuǎn)程拼花文件比較理想和原始數(shù)據(jù)訪問模式

在這個(gè)特定的示例中，假設(shè)拼花文件足夠大（~ 400MB +）以包含四個(gè)不同的行組，read_parquet調(diào)用的目標(biāo)是四個(gè)可用列中的兩個(gè)。這意味著AbstractBufferedFile對(duì)象最終必須將八個(gè)不同的列塊范圍以及頁腳元數(shù)據(jù)傳輸?shù)奖镜貎?nèi)存中。

在禁用緩存的情況下，經(jīng)過良好調(diào)整的拼花地板庫可以使用五個(gè)不同的請(qǐng)求僅將必要的數(shù)據(jù)移動(dòng)到本地內(nèi)存中。然而，由于fsspec的類文件接口包含state，這五個(gè)讀取調(diào)用始終是串行的，每次調(diào)用都會(huì)產(chǎn)生一整段延遲時(shí)間。

這種 ideal-access 場(chǎng)景無法利用并發(fā)性來最小化延遲，即使該策略可能會(huì)最小化文件系統(tǒng)請(qǐng)求的數(shù)量并產(chǎn)生高的總體吞吐量。對(duì)于采用 naive-access 方法且未明確最小化讀取調(diào)用數(shù)的拼花地板庫，read_parquet操作可能會(huì)出現(xiàn)高延遲和低總體吞吐量！

此時(shí)，我們已經(jīng)確定，在文件已經(jīng)打開進(jìn)行讀取之后， I / O 庫無法利用文件系統(tǒng)的并發(fā)性。更重要的是，當(dāng)涉及部分 I / O 時(shí)，默認(rèn)的預(yù)讀緩存策略可能會(huì)進(jìn)一步降低觀察到的性能。這是因?yàn)轭A(yù)讀緩存的固有假設(shè)是，順序文件訪問可能是連續(xù)的。

Figure 3 shows that read-ahead caching is likely to transfer about 20 MB of unnecessary data， 5 MB of read-ahead for each row-group.

圖 3 中預(yù)讀和無緩存文件訪問策略的比較 fsspec

正如您在以下性能結(jié)果中看到的，禁用緩存優(yōu)于預(yù)讀緩存的好處取決于read_parquet中使用的引擎和特定的存儲(chǔ)系統(tǒng)。

如果引擎已經(jīng)包含了支持格式的優(yōu)化，可以將必要的字節(jié)范圍移動(dòng)到本地內(nèi)存中（即pyarrow和fastparquet），那么無緩存選項(xiàng)可能是更好的選擇。當(dāng)引擎假定本地文件訪問速度很快（ cuDF ）時(shí)，某種形式的fsspec級(jí)緩存可能非常關(guān)鍵。

在這兩種情況下，引擎都無法開始傳輸所需的字節(jié)范圍，直到創(chuàng)建fsspec文件對(duì)象之后。它受到順序數(shù)據(jù)傳輸附加延遲的限制。

現(xiàn)在，我們已經(jīng)對(duì)典型的 read _ parquet 調(diào)用中的默認(rèn)和無緩存 AbstractBufferedFile 行為有了較高的理解，現(xiàn)在我們可以解釋open_parquet_file為提高總體讀取吞吐量而使用的兩種通用優(yōu)化。

優(yōu)化 1 ：使用“部件”緩存策略

默認(rèn)情況下，與AbstractBufferedFile中使用的格式無關(guān)的緩存策略不同，您可以使用新的KnownPartsOfAFile（“部件”）選項(xiàng)在文件打開之前精確緩存所需內(nèi)容。

from fsspec.parquet import open_parquet_file
import pandas as pd path = “://my-bucket/my-data”
columns = [“col1”, “col2”]
options = {“necessary”: ”credentials”} with open_parquet_file( path, columns=columns, storage_options=options,
) as f: df = pd.read_parquet(path, columns=columns)

圖 4 顯示，用于訪問read_parquet中數(shù)據(jù)的邏輯與用于遠(yuǎn)程數(shù)據(jù)訪問的get調(diào)用的數(shù)量或大小之間不再存在任何關(guān)系。從拼花引擎的角度來看，任何讀取操作幾乎都是瞬時(shí)的，因?yàn)樗斜匦璧臄?shù)據(jù)都已緩存在內(nèi)存中。

圖 4 這個(gè) fsspec 的“部件”緩存策略。在打開類似文件的對(duì)象之前，所有必要的數(shù)據(jù)都必須緩存在本地內(nèi)存中。

優(yōu)化 2 ：異步并行傳輸“部件”

盡管之前的優(yōu)化使您能夠避免read_parquet中的許多小型 get 操作和不必要的數(shù)據(jù)傳輸，但在初始化AbstractBufferedFile之前，您仍然必須填充KnownPArtsOfAFile緩存。

為了盡可能高效地執(zhí)行此操作，請(qǐng)使用cat_ranges一次性獲取所有必需的列塊，包括異步獲取和使用asyncio并行獲取。因?yàn)閷?duì)于包含多個(gè)字段或多個(gè)行組的文件，傳輸?shù)牧袎K的總數(shù)可能很大，所以只要聚合的請(qǐng)求的大小保持在上限以下，就可以聚合相鄰的字節(jié)范圍請(qǐng)求。

圖 5 顯示，這種方法最終會(huì)導(dǎo)致并發(fā)傳輸多個(gè)字節(jié)范圍的最佳大小。

圖 5中使用的數(shù)據(jù)傳輸優(yōu)化 fsspec.parquet

初步 fsspec 。拼花地板基準(zhǔn)測(cè)試結(jié)果

要將open_parquet_file的性能與其他基于fsspec和pyarrow的文件處理方法進(jìn)行比較，請(qǐng)使用 可用 Python 腳本 ：

pyarrow-6.0.1

fastparquet-0.8.0

cudf-22.04

fsspec/s3fs/gcfs-2022.2.0

使用這個(gè)腳本，我們從一個(gè) 789M 的拼花地板文件中讀取一列，該文件共包含 10 個(gè)行組和 30 個(gè)列，具有快速壓縮，需要傳輸大約 27M 的數(shù)據(jù)。圖 6-7 中總結(jié)的 S3 和 GCS 的結(jié)果清楚地表明，當(dāng)從默認(rèn)緩存策略轉(zhuǎn)向open_parquet_file時(shí)，性能顯著提升 85% 或更高。

事實(shí)上，新功能有效地匹配了 PyArrow 的原生S3FileSystem實(shí)現(xiàn)的性能，該實(shí)現(xiàn)是專門為其鑲木地板引擎的最佳性能而設(shè)計(jì)的。在本文中，我們僅將其與 Amazon S3 基準(zhǔn)測(cè)試的本機(jī) PyArrow 文件系統(tǒng)進(jìn)行比較，因?yàn)?PyArrow 在發(fā)布時(shí)僅提供 Amazon S3 和 Hadoop 的公共支持實(shí)現(xiàn)。

圖 6 S3 存儲(chǔ)的一般基準(zhǔn)測(cè)試結(jié)果

圖 7 GCS 存儲(chǔ)的一般基準(zhǔn)測(cè)試結(jié)果

為了說明使用open_parquet_file縮放文件的好處，我們還從一個(gè) 12 GB 的拼花地板文件中讀取了一列，其中包含禁用壓縮的公共 GCS 存儲(chǔ)中 Criteo 數(shù)據(jù)集的第一天。圖 8 顯示，新的fsspec函數(shù)可以提供比默認(rèn)緩存 10 倍或更多的加速。

圖 8 地面軍事系統(tǒng)存儲(chǔ)的 Criteo 數(shù)據(jù)集基準(zhǔn)測(cè)試結(jié)果

自己測(cè)試一下

在本文中，我們介紹了fsspec.parquet模塊，它為打開遠(yuǎn)程拼花文件open_parquet_file提供了一種支持格式的字節(jié)緩存優(yōu)化。基準(zhǔn)測(cè)試清楚地表明，與fsspec中的默認(rèn)文件打開行為相比，新的優(yōu)化可以提供顯著的性能改進(jìn)，甚至可以接近 PyArrow 中針對(duì)部分 I / O 的優(yōu)化 C ++文件系統(tǒng)實(shí)現(xiàn)的性能。

自從在 2021.11.0 版本的 fsspec 中正式發(fā)布以來，open_parquet_file實(shí)用程序已經(jīng)被 RAPIDS cuDF 庫和 Dask -Dataframe 采用。

由于基于 cuDF 的工作流得到了顯著且一致的改進(jìn)，此新功能已被cudf.read_parquet和dask_cudf.read_parquet采用為默認(rèn)的文件打開方法。

對(duì)于沒有 GPU 資源的 Dask 用戶，現(xiàn)在可以通過向read_parquet傳遞open_file_options參數(shù)來選擇優(yōu)化的緩存方法。例如，以下代碼示例指示 Dask 使用parquet預(yù)緩存方法打開所有拼花地板數(shù)據(jù)文件：

import dask.dataframe as dd ddf = dd.read_parquet( path, open_file_options={“precache_options”: {“method”: “parquet”}}
)

鑒于這一早期的成功，我們希望擴(kuò)展和簡(jiǎn)化fsspec中可用的預(yù)緩存選項(xiàng)，并在所有文件打開函數(shù)中建立一個(gè)清晰的 precache_options API 。

關(guān)于作者

Rick Zamora 是 NVIDIA 在 RAPIDS 和 Dask 工作的高級(jí)軟件工程師。他有科學(xué)計(jì)算研究和并行軟件開發(fā)的背景。杜蘭特博士在牛津大學(xué)學(xué)習(xí)物理學(xué)，在多倫多學(xué)習(xí)天體物理學(xué)。他在多個(gè)波長(zhǎng)和廣泛的時(shí)間尺度上研究了脈沖星和其他緊湊型物體系統(tǒng)。

審核編輯：郭婷