より大きなデータセットでOOMエラーが発生するSparkMLパイプラインに取り組んでいます。トレーニング前は、cache();を使用していました。これを交換したところcheckpoint()、メモリ要件が大幅に低下しました。ただし、のドキュメントには次RDDのcheckpoint()ように記載されています。
このRDDをメモリに保持することを強くお勧めします。そうしないと、ファイルに保存するときに再計算が必要になります。
DataSet私が使用しているのチェックポイントについても、同じガイダンスは提供されていません。とにかく上記のアドバイスに従って、私はメモリ要件が実際にcache()単独で使用することからわずかに増加することを発見しました。
私の期待は、
...
ds.cache()
ds.checkpoint()
...
チェックポイントへの呼び出しは、チェックポイントDataSetされる前に同時にキャッシュされるの評価を強制します。その後、へのds参照はキャッシュされたパーティションを参照し、より多くのメモリが必要でパーティションが退避した場合、チェックポイントされたパーティションが再評価されるのではなく使用されます。これは本当ですか、それとも内部で何か違うことが起こりますか？理想的には、可能であればDataSetをメモリに保持したいのですが、メモリの観点からは、キャッシュとチェックポイントのアプローチを使用することに何のメリットもないようです。
TL; DR後続のアクションでは、メモリ内キャッシュ（のデフォルトのストレージレベルDatasetはMEMORY_AND_DISKとにかく）のメリットはありませんが、コンピューティングdsにコストがかかる場合は、キャッシュを検討する必要があります。
説明
あなたの期待は
ds.cache() ds.checkpoint() ...チェックポイントを呼び出すと、DataSetの評価が強制されます
正しい。Dataset.checkpointさまざまなフレーバーがあり、熱心なチェックポイントと怠惰なチェックポイントの両方が可能であり、デフォルトのバリアントは熱心です
def checkpoint(): Dataset[T] = checkpoint(eager = true, reliableCheckpoint = true)
したがって、後続のアクションではチェックポイントファイルを再利用する必要があります。
ただし、内部ではSparkが内部に適用されるcheckpointRDDだけなので、評価のルールは変更されていません。Sparkは最初にアクションを評価し、次に作成しますcheckpoint（そのため、最初にキャッシュが推奨されました）。
したがって、省略するds.cache() dsと、次のように2回評価されds.checkpoint()ます。
count用に1回。checkpoint。したがって、何も変更されておらず、cache引き続き推奨されますがRDD、Datasetキャッシュは計算コストが高いと見なされるため、推奨はプレーンと比較してわずかに弱い可能性があり、コンテキストによっては、単にデータをリロードする方が安価な場合があります（通常、Dataset.countなしcacheは最適化されますが、Dataset.countwith cacheis not-スパークのカウントを使用して熱心な評価を強制するパフォーマンスの問題はありますか？）。
この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。
侵害の場合は、連絡してください[email protected]
コメントを追加