使用 Snowpipe - 加載小文件的最佳做法是什么。 例如。 每天數千個 4K 文件？

Question

問題

1. 使用 Snowpipe 加載小文件（例如 4K）比 16K、500K 或 1-10Mb（推薦的文件大小）要貴多少。 注意：這個問題意味着加載小文件比推薦的 1-10Mb 更昂貴。

2. 了解最佳做法是加載大小為 1-10Mb 的文件，但我需要近乎實時的交付（幾分鍾）。 我可以連接文件使它們變大，但在將微批次發送到 S3 和 Snowpipe 之前不能等待超過 60 秒。 我目前每 30 秒寫一次我有的任何東西，但我每 60 秒看到一次 Snowpipe 報告。 這是否意味着將文件寫入 S3 的頻率超過 60 秒沒有意義？ IE。 如果我每 30 秒發送一次文件，它實際上會減少平均延遲還是 60 秒的最小 Snowpipe 周期。

3. 加載 4K 文件（每天大約 200Mb，每個文件 4K），每 GB 花費大約 20 個積分，這是非常昂貴的。 如果我加載（例如）CSV 個 1-10Mb 范圍內的文件，使用 Snowpipe 每 GB 的成本應該是多少？ 如果我保持在 1-10Mb 范圍內，我的每 GB 成本會下降嗎？

4. 有沒有更快/更便宜的替代方法可以將數據導入 Snowflake？ 注意：目前使用 Parquet 格式的 Snowpipe 到 VARIANT，然后使用 STREAMS 和 TASKS 重組數據以進行近乎實時的分析。 了解使用 Snowpipe 比使用虛擬倉庫更便宜。 這是真的？ 我懷疑真正的答案是“視情況而定”。 但是“取決於什么”。

5. 除了我的近實時要求外，我還有許多系統提供批量提要（CSV 格式，大約每 4 小時一次，預計在 30 分鍾內延遲處理和呈現以供分析。文件大小在這里有所不同，但大多數是 1Mb到 1Gb 范圍。我應該使用相同的 Snowpipe 解決方案，還是最好從 Airflow 編排工作並使用 COPY 命令，然后在專用虛擬倉庫上使用 SQL 語句？或者實際上，您會推薦什么替代方案？

6. 我可以看到 Snowpipe 加載 4K 文件很昂貴，而且可能比更大的文件更便宜。 如果我加載超過 10Mb 的文件，這些文件會再次變得更昂貴嗎？ IE。 成本是“鍾形曲線”還是變平。

背景

1. 我正在使用 Snowpipe 提供近乎實時 (NRT) 的數據加載解決方案。
2. 我大約每 30 秒從大約 30 個表中將數據從 Kafka 復制到 S3，並且使用 Snowpipe 將其自動加載到 Snowflake。
3. 數據以 Parqet 格式傳遞給我，加載到 Variant，然后在使用 Tasks 和 SQL 重組分析之前將屬性提取到表中。
4. 在一天之內，我發現加載了 50,000 個文件，文件大小各不相同，但平均文件大小為每個文件 4K。
5. 我可以看到每分鍾加載大約 30 個文件（即每分鍾加載大約 100K）。
6. 我試圖平衡幾個非功能性需求。 a) 有效使用信用。 意識到小文件很昂貴。 b) 減少延遲（我試圖獲得從 Kafka 到儀表板的最長 2-5 分鍾的管道）。 c) 簡單 - IE。 它需要易於理解和維護，因為我希望解決方案能夠大規模增長 - IE。 從大約 20 個表到數百個表 - 都需要近實時
7. 我將（在接下來的 3 個月內）每 4 小時進行 CSV 次批量加載。 它們是完全獨立的數據源（來自 NRT），並且具有更密集的處理和 ELT。 我想知道是否應該為這些使用 Snowpipe 或 COPY。

Answer 1

1. Snowpipe 是無服務器的，並且按使用量計費。 與建立倉庫相比，無服務器方法的開銷要少得多，但仍然存在一些開銷。 因此，您發送信息的頻率越高，成本就越高。 多少？ 試試看，沒人能告訴你。
2. 我不是這方面的專家，但 Snowflake 不是為實時工作負載而構建的。 市場營銷可能會告訴您其他信息。 在最壞的情況下，您需要等待幾分鍾才能完全刷新數據。 Snowflake 擅長處理巨大的數據負載，您可以在其中等待更長的時間。
3. 再次嘗試，一個指標是您的數據攝取使倉庫繁忙的程度。 如果它運行 1 分鍾但您的查詢在 1 秒內完成，您可能會獲得 60 倍的成本降低。
4. 假設您沒有完全占用倉庫，最便宜的方法應該是您的用例的雪管。
5. 復制進去應該沒問題。
6. 我不知道。 ：） 試試看。 我想這沒什么大不了的。 您可能會遇到大文件 (1G+) 的問題。