【要約】S3上の数GBファイルをstreamingでZIP化する【smart-open】 [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
データエンジニアがS3上の巨大なCSVをZIP化する際、メモリ不足の問題に直面する。大量のデータを扱うETLパイプラインにおいて、この問題は致命的となる。
- ・
boto3の.read()は、オブジェクト全体をメモリへ展開する。 - ・
io.BytesIOの使用は、元ファイルとZIPの両方をメモリに保持させる。 - ・数GBのファイルでは、実行環境のメモリを容易に使い果たす。
- ・結果として、プロセスが強制終了（OOM）し、処理が失敗する。
// Approach
開発者は、メモリ消費を抑えるため、ストリーミング処理を全面的に採用する。メモリ使用量をチャンクサイズ程度に保つことが、本アプローチの核心である。
- ・
boto3のiter_chunks()を用い、S3から一定サイズずつ読み込む。 - ・
smart_openを利用し、S3への書き込み先をファイルライクなオブジェクトにする。 - ・
zipfileを介し、読み込んだチャンクを順次圧縮してS3へ流し込む。 - ・これにより、データをメモリに溜め込まず、連続的な処理を実現する。
// Result
この実装により、ファイルサイズに依存しない安定したメモリ管理を実現した。これにより、大規模なデータ処理パイプラインの信頼性が大幅に向上する。
- ・メモリ使用量をチャンクサイズ程度に抑制できる。
- ・数GBの巨大ファイルでも、OOMを回避できる。
- ・S3間のデータ変換において、リソース効率の高い処理が可能になる。
- ・インフラコストを抑えつつ、大規模なデータ処理を安定して実行できる。
Senior Engineer Insight
> 本手法は、大規模データ処理におけるリソース管理の定石である。
io.BytesIOによる全展開は、小規模データでは簡便だが、本番環境のスケールを考慮すると極めて危険だ。smart_openを導入することで、複雑なマルチパートアップロードの管理を隠蔽しつつ、ストリーミングを実現できる点は評価できる。ただし、ネットワーク帯域とCPU負荷のトレードオフには留意すべきだ。実戦では、チャンクサイズと並列度の最適化が次の課題となるだろう。