Englishから翻訳 • 原文を読む こんにちは!私の名前は陳紫宇です。Colorkrewのフルスタックエンジニアです。データエンジニアリングについて学び、執筆するのが大好きです。
本日はSparkにおけるトランスフォーメーションとアクションについて議論したいと思います。もちろん、Sparkの世界に飛び込んでETLプロセスを実行することは可能ですが、それらが互いにどう違うのかを知らずに。しかし、既存のETLプロセスを最適化したり、新しいものを一から構築したりする責任を負うと、その違いを理解しないと、作成したETLプロセスの効率が損なわれる可能性があります。最終的には、平凡に設計された非効率なETLプロセスは、組織の運用コストを増加させる可能性さえあります。したがって、Sparkを使って高性能なETLプロセスを構築したいなら、トランスフォーメーションとアクションの本質を徹底的に理解することが不可欠になります。
まずは変換とアクションの簡単な紹介から始めましょう。変換は、実際のデータを表現するDataFrames、Datasets、またはRDDを返すSpark操作です。変換はデータ表現のみを生成するため、計算資源は少ないです。一方、アクションはデータを読み込んだり外部ストレージに保存したりするSpark操作です。アクションは実際のデータを抽出・読み込むため、変換よりも計算負荷が高いです。したがって、可能な限りアクションの使用は避けたほうが良いでしょう。
次に、いくつかの例を見てみましょう。map()、filter()、intersection()などのメソッドは変換です。Mapは元のDataFrameの行を変換し、同じ行数の新しいDataFrameを返します。Filterは条件に合致する行を含む新しいDataFrameを返します。Intersectionは2つのDataFrameを組み合わせ、両方の元のDataFrameに存在する行を含む新しいDataFrameを返します。機能の違いはありますが、同じ返りタイプはDataFrameを共有しています。
アクションについては、count()、collect()、write()などの例があります。countはDataFrame内の行数を取得します。CollectはDataFrame内のすべてのデータを返します。writeはDataFrameで表現されたデータを保存します。それぞれ異なるものの、すべて実際のデータを取得する必要があり、表現よりも時間がかかり計算集約的です。
変換はさらに狭義変換と広い変換の2つのカテゴリーに分けられます。狭変換では、出力データの同じパーティション内の行を計算するために必要なすべての行(出力データフレームで表される)は、入力データの同じパーティション(入力データフレームで表される)から来ます。言い換えれば、入力データのあるパーティションのレコードは出力データの1つのパーティションにのみ寄与します。したがって、出力データフレーム内のパーティション生成を容易にするためにデータを移動する必要がなく、狭変換は一般的に高速です。狭い変換の例としてはmap()やfilter()があります。
しかし、ワイド変換では、出力データの同じパーティション内の行を計算するために必要な行(出力データフレームで表される)が、入力データの異なるパーティション(入力データフレームで表される)から来ることがあります。言い換えれば、入力データの1パーティションのレコードが出力データの複数のパーティションに寄与することがあります。したがって、出力データフレームでパーティションを生成するために、Sparkは出力データフレームを生成する際に異なるノード間でデータをシャッフルする必要があるかもしれません。このデータシャッフルは変換プロセスで必要な計算リソースに加えて追加の計算資源を必要とし、特にデータサイズが大きい場合はETL全体の処理が遅くなる可能性があります。したがって、できるだけワイド変換を避けるのが最善です。よく使われるワイド変換には、groupByKey()やaggregateByKey()があります。
まとめると、高性能なETLプロセスを設計するには、アクションと変換、狭い変換と広範囲変換の違いを十分に理解することが不可欠です。アクションは実際のデータを抽出・読み込む作業ですが、変換は実際のデータの表現のみを生成します。したがって、アクションは変換よりも計算集約的であり、必要な場合にのみETLプロセスに組み込むべきです。狭い変換はデータのシャッフルを伴いませんが、広範囲変換は必要です。したがって、広範囲変換を過剰に使うことはETLプロセスのパフォーマンスを悪化させる可能性があり、できるだけ避けるべきです。
これらの違いを念頭に置いてETLプロセスを構築することで、完全に最適化されたETLプロセスはもはや遠い夢ではありません。この記事を読んでいただきありがとうございます。Sparkの歩みに役立てば幸いです。