それぞれ500万レコードを含む64個のJSONファイルに分散した最大500GBのデータを処理したいと思います。基本的に、Map（Pyspark）は3億レコードのそれぞれで機能します。
PySparkマップ関数をテストするために、google Dataprocクラスターをセットアップしました（1つのマスター5ワーカーで1つのJSONファイルのみをテストします）。
（DataprocのHadoop分散ファイルシステムを利用するために）マスターノード内のすべてのファイルをコピーする必要がありますか、それともファイルをGCSバケットに保持し、Pyspark内のファイルの場所を指定する場合も同様に効率的ですか？
また、私のコードは、マスターにコピーしたかなりの数の外部モジュールをインポートし、インポートはマスターで正常に機能します。Pysparkがそれらのワーカーで実行されたときにインポートエラーが発生しないように、他のすべてのワーカーノードにコピーするためのベストプラクティスは何ですか。
Google Cloud Webサイトでいくつかの記事を読みましたが、ファイルを保存する場所について明確な回答が得られませんでした。
外部モジュールを各ワーカーノードに手動でコピーすることはできますが、少なくとも100ノードを処理する場合、本番環境ではコピーできません。
あなたはいくつかの質問をしているので、一度に一つずつ取り上げましょう。
モジュールが外部にある場合（たとえば、を介してモジュールをインストールする場合pip install）、初期化アクションを使用します
あなたが持っているものがあなたが.py書いたたくさんのファイルであるならば、私はそれらをアーカイブファイルに入れて、--py-files議論であなたの仕事に渡します。また、車輪や卵を作ることを検討することをお勧めします。
このリンクが役立つ場合があります：https：//developerzen.com/best-practices-writing-production-grade-pyspark-jobs-cb688ac4d20f
データがすでにGCSにあり、そこに保存する場合は、マスターノードにコピーするメリットはありません。GCSコネクタはGCSからその場で（そして並行して！）それを読み取ることができ、これはGCSとの間で個別にコピーするよりも（計算コストの点で）安価になる可能性があります。
データはすでに適切にシャーディングされているようです。これは、GCSから直接Sparkで読み取るのに十分な理由です。
GCSコネクタページには、明示的にこれを呼び出します。
直接データアクセス–データをクラウドストレージに保存して直接アクセスします。最初にHDFSに転送する必要はありません。HDFSの互換性– hdfs：//の代わりにgs：//プレフィックスを使用して、CloudStorageのデータに簡単にアクセスできます。
相互運用性– Cloud Storageにデータを保存すると、Spark、Hadoop、およびGoogleサービス間のシームレスな相互運用性が可能になります。
ストレージ管理のオーバーヘッドなし– HDFSとは異なり、Cloud Storageは、ファイルシステムのチェック、ファイルシステムの以前のバージョンへのアップグレードまたはロールバックなどの定期的なメンテナンスを必要としません。
クイックスタートアップ– HDFSでは、NameNodeがセーフモードを終了するまでMapReduceジョブを開始できません。このプロセスは、データのサイズと状態に応じて数秒から数分かかる場合があります。Cloud Storageを使用すると、タスクノードが開始するとすぐにジョブを開始できるため、時間の経過とともに大幅なコスト削減につながります。
この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。
侵害の場合は、連絡してください[email protected]
コメントを追加