Skip to main content
How to enable StorageGRID in your environment
本繁體中文版使用機器翻譯,譯文僅供參考,若與英文版本牴觸,應以英文版本為準。

NetApp StorageGRID 與巨量資料分析

貢獻者

_ 作者: Angela Cheng _

NetApp StorageGRID 使用案例

NetApp StorageGRID 物件儲存解決方案提供擴充性、資料可用度、安全性及高效能。各種規模的組織、以及各行各業的組織、都會使用 StorageGRID S3 來處理各種使用案例。讓我們來探索一些典型案例:

  • 巨量資料分析: * StorageGRID S3 經常用作資料湖、企業可在其中儲存大量結構化和非結構化資料、以便使用 Apache Spark 、 Splunk Smartstore 和 Dremio 等工具進行分析。

  • 資料分層: * NetApp 客戶使用 ONTAP 的 FabricPool 功能、在高效能本機層之間自動將資料移至 StorageGRID 。分層可釋放昂貴的 Flash 儲存空間、以儲存熱資料、同時在低成本物件儲存設備上隨時提供冷資料。如此可將效能與節約效益發揮到極致。

  • 資料備份與災難恢復: * 企業可以使用 StorageGRID S3 做為可靠且具成本效益的解決方案、在發生災難時備份關鍵資料並加以恢復。

  • 應用程式的資料儲存: * StorageGRID S3 可作為應用程式的儲存後端、讓開發人員輕鬆儲存及擷取檔案、影像、影片及其他類型的資料。

  • 內容交付: * StorageGRID S3 可用於儲存靜態網站內容、媒體檔案及軟體下載、並提供給全球各地的使用者、運用 StorageGRID 的地理發佈和全球命名空間、提供快速可靠的內容交付。

  • 資料歸檔: * StorageGRID 提供不同的儲存類型、並支援分層處理至公有長期低成本儲存選項、因此是歸檔及長期保留資料的理想解決方案、這些資料必須保留以供法規遵循或歷史用途。

  • 物件儲存使用案例 *

StorageGRID 使用案例圖表、寬度 = 396 、高度 = 394

在上述情況中、巨量資料分析是最熱門的使用案例之一、其使用率也逐漸上升。

為何選擇 StorageGRID 來處理資料湖?

  • 更高的協同作業效率:大規模共用多站台、多租戶、並具備業界標準 API 存取功能

  • 降低營運成本:單一、自我修復、自動化橫向擴充架構的操作簡易性

  • 擴充性:與傳統的 Hadoop 和資料倉儲解決方案不同、 StorageGRID S3 物件儲存設備可將儲存設備與運算和資料分離、讓企業能夠隨著成長擴充儲存需求。

  • 耐用性與可靠性: StorageGRID 提供 99.999% 的耐用度、這表示儲存的資料對於資料遺失具有高度抵抗能力。它也提供高可用度、確保資料隨時可供存取。

  • 安全性: StorageGRID 提供各種安全功能、包括加密、存取控制原則、資料生命週期管理、物件鎖定和版本設定、以保護儲存在 S3 儲存區中的資料

  • StorageGRID S3 資料湖 *

StorageGRID datalake 範例、 width=614 、 height =345

以 S3 物件儲存為基準測試資料倉儲和 Lakeouses :比較研究

本文提供使用 NetApp StorageGRID 的各種資料倉儲和湖屋生態系統的完整基準。目標是判斷哪一種系統在 S3 物件儲存設備上的效能最佳。請參閱此資訊https://www.dremio.com/wp-content/uploads/2023/02/apache-Iceberg-TDG_ER1.pdf?aliId=eyJpIjoieDRUYjFKN2ZMbXhTRnFRWCIsInQiOiJIUUw0djJsWnlJa21iNUsyQURRalNnPT0ifQ%253D%253D["Apache 冰山:最終指南"]、深入瞭解資料流 / 湖屋架構和表格格式( Parquet 和冰山)。

  • 基準測試工具 - TPC-DS - https://www.tpc.org/tpcds/

  • Big Data 生態系統

    • VM 叢集、每個都有 128G RAM 和 24 個 vCPU 、系統磁碟的 SSD 儲存設備

    • Hadoop 3.3.5 搭配 Hive 3.1.3 ( 1 個名稱節點 + 4 個資料節點)

    • Delta Lake with Spark 3.2.0 ( 1 位大師 + 4 位員工)和 Hadoop 3.3.5

    • Dremio V23 ( 1 個 Cordinator + 5 個執行者)

    • Trino v438 ( 1 個協調器 + 5 個員工)

    • Starburst v453 ( 1 個 Cordinator + 5 個工作者)

  • 物件儲存

    • NetApp ^ ® ^ StorageGRID ^ ® ^ 11.8 含 3 個 SG6060 + 1 個 SG1000 負載平衡器

    • 物件保護 - 2 份複本(結果與 EC 2+1 類似)

  • 資料庫大小 1000GB

  • 每項查詢測試的所有生態系統都會使用「硬碟區」格式停用快取。對於冰山格式、我們比較了 S3 取得要求的數量、以及快取停用和啟用快取的案例之間的查詢時間總計。

TPC-DS 包含 99 個複雜的 SQL 查詢、專為基準測試而設計。我們測量了執行所有 99 項查詢所需的總時間、並透過檢查 S3 要求的類型和數量來進行詳細分析。我們的測試比較了兩種常用表格格式的效率:拼花地板和冰山。

  • 使用 Parquet 資料表格式的 TPC-DS 查詢結果 *

生態系統 Hive 德爾塔湖 夢中 Trino Starburst

TPCDS 99 查詢
總分鐘數

10841

55

47

32

28

S3 要求明細

取得

1,117,184

2,074,610

4,414,227

1,504,212

1,495,039

觀察:
全方位實現

從 32 MB 物件到 2 KB 到 2 MB 的範圍達到 80% 、每秒 50 到 100 個要求

73% 的範圍從 32 MB 物件低於 100KB 、從 1000 到 1400 個要求 / 秒

從 256 MB 物件獲得 90% 的 100 萬位元組範圍、 2000 年至 2300 個要求 / 秒

範圍取得大小:低於 100KB 50% 、約 16% 1 MB 、 27% 2Mb 至 9Mb 、 3500 至 4000 個要求 / 秒

範圍取得大小:低於 100KB 50% 、約 16% 1MB 、 27% 2Mb 至 9Mb 、 4000 至 5000 要求 / 秒

列出物件

312,053

24 、 158

240

509

512

標題
(不存在的物件)

156,027

12 、 103

192.

0

0

標題
(存在的物件)

982,126.

922,732.

1845

0

0

申請總數

2,567,390

3 、 033 、 603

4,416504..

1,504,721

1 Hive 無法完成查詢編號 72

  • TPC-DS 查詢結果、內含冰山表格格式 *

生態系統 夢中 Trino Starburst

TPCDS 99 查詢 + 總分鐘數(停用快取)

30

28

22

TPCDS 99 查詢 + 總分鐘 2 (啟用快取)

22

28

21.5

S3 要求明細

Get (快取已停用)

2,154,747

938,639

931,582

Get (啟用快取)

5,389

30,158

3,281

觀察:
全方位實現

範圍取得大小: 67% 1MB 、 15% 100KB 、 10% 500KB 、 3000 - 4000 個要求 / 秒

範圍取得大小:低於 100KB 42% 、約 17% 1 MB 、 33% 2Mb 至 9Mb 、 3500 至 4000 個要求 / 秒

範圍取得大小:低於 100KB 43% 、約 17% 1 MB 、 33% 2Mb 至 9Mb 、 4000 至 5000 個要求 / 秒

列出物件

284

0

0

標題
(不存在的物件)

284

0

0

標題
(存在的物件)

1,261

509

509

要求總數(快取停用)

2,156,578

939,148

2 Trino/Starburst 效能受到運算資源的限制;將更多 RAM 新增至叢集可縮短查詢時間。

如第一張表所示、 Hive 的速度遠低於其他現代資料湖屋生態系統。我們觀察到 Hive 傳送了大量的 S3 清單物件要求、這在所有物件儲存平台上通常都很緩慢、尤其是在處理包含許多物件的貯體時。如此可大幅增加整體查詢持續時間。此外、現代的湖屋生態系統也能同時傳送大量的 GET 要求、每秒可傳送 2 、 000 至 5 、 000 個要求、相較於 Hive 每秒 50 至 100 個要求。與 S3 物件儲存設備互動時、 Hive 和 Hadoop S3A 所提供的標準檔案系統會導致 Hive 速度緩慢。

搭配 Hive 或 Spark 使用 Hadoop (在 HDFS 或 S3 物件儲存設備上)需要對 Hadoop 和 Hive/Spark 有廣泛的瞭解、同時也需要瞭解每個服務的設定如何互動。它們一起擁有超過 1 、 000 種設定、其中許多是相互關聯的、無法分別變更。尋找設定與值的最佳組合需要大量的時間和精力。

比較 Parquet 和冰山結果時、我們發現表格格式是主要的效能因素。從 S3 要求的數量來看、冰山表格格式比 Parquet 更有效率、相較於 Parquet 格式、申請數量減少 35% 至 50% 。

Dremio 、 Trino 或 Starburst 的效能主要是由叢集的運算能力所驅動。雖然這三個系統都使用 S3A 連接器來連接 S3 物件儲存連線、但它們不需要 Hadoop 、而且這些系統也不使用 Hadoop 的 FS.s3a 設定。如此可簡化效能調校、免除學習和測試各種 Hadoop S3A 設定的需求。

從這個基準測試結果中、我們可以得出結論、針對 S3 型工作負載最佳化的大型資料分析系統是主要的效能因素。現代化的湖上環境可最佳化查詢執行、有效運用中繼資料、並提供對 S3 資料的無縫存取、因此相較於使用 S3 儲存設備時的 Hive 、效能更佳。

請參閱此 "頁面"資訊、以使用 StorageGRID 設定 Dremio S3 資料來源。

請造訪下列連結、深入瞭解 StorageGRID 和 Dremio 如何合作提供現代化且有效率的資料湖基礎架構、以及 NetApp 如何從 Hive + HDFS 移轉至 Dremio + StorageGRID 、大幅提升巨量資料分析效率。