Cloud Storage とビッグデータの使用

Google Cloud Platform でビッグデータを保存し、利用するために最も重要な機能が Cloud Storage です。次のような使用例があります。

  • BigQuery へのデータの読み込み

  • Cloud Dataproc の使用。Cloud Dataproc を使用すると、HDFS 互換の Cloud Storage コネクタが自動的にインストールされるため、HDFS と並行して Cloud Storage バケットを使用できます。

  • バケットを使用した Cloud Dataflow パイプラインのステージング ファイルと一時データの格納

  • バケットを使用した遺伝子データの Google Genomics データセットへのインポート

Cloud Genomics と Cloud Dataflow の場合、Cloud Storage バケットの使用は必須です。BigQuery と Cloud Dataproc の場合は、Cloud Storage バケットの使用は任意ですが推奨されています。

コマンドライン ツールである gsutil を使用して、特にビッグデータのシナリオで Cloud Storage バケットとオブジェクトを簡単かつ安全に操作できます。たとえば、gsutil を使用して、1 つのコマンドによる多くのファイルの並列コピー、大きなファイルの効率的なコピー、データのチェックサムの計算、ローカルのパソコンからの Cloud Storage のパフォーマンスの測定を行うことができます。

このページでは、ビッグデータ タスクでの gsutil の使用に重点を置いて説明します。gsutil の概要については、スタートガイド: gsutil ツールの使用をご覧ください。すべての gsutil コマンドの詳細なドキュメントは、オンラインで利用することも、gsutil help を実行して表示できる組み込みのヘルプで参照することもできます。

このページに表示されている例を最大限に活用するには、次の条件を満たす必要があります。

多くのファイルのバケットへのコピー

アップロードするファイルが数多くある場合は、gsutil -m オプションを使用して、並列コピー(マルチスレッド、マルチ処理)を実行できます。サブディレクトリを再帰的にコピーするには、cp コマンドの -R フラグを使用します。たとえば、サブディレクトリが含まれるファイルを top-level-dir という名前のローカル ディレクトリからバケットにコピーする場合は、次のコマンドを使用できます。

gsutil -m cp -R top-level-dir gs://example-bucket

コマンドにワイルドカードを使用することで、特定の名前パターンと一致させることができます。たとえば、image で始まるファイルのみをコピーするには、次のコマンドを実行します。

gsutil -m cp -R top-level-dir/subdir/image* gs://example-bucket

同じワイルドカードを使用してファイルを削除することもできます。

gsutil -m rm gs://example-bucket/top-level-dir/subdir/image*

ローカル ファイルからクラウドへ、またはその逆へのコピーのほか、たとえば次のようにクラウド内でコピーすることもできます。

gsutil -m cp gs://example-bucket/top-level-dir/subdir/** gs://example-bucket/top-level-dir/subdir/subdir2

gsutil は、複数のファイルを移動していることを自動的に検出し、subdir2 という名前の新しいディレクトリ内にそれらを作成します。

ローカル ディレクトリの同期

gsutil rsync コマンドを使用すると、ローカル ディレクトリをバケットに同期できます(その逆も可能です)。たとえば、gs://example-bucket とローカル ディレクトリ local-dir の内容を一致させるには、次のコマンドを使用できます。

gsutil -m rsync -r local-dir gs://example-bucket

rsync -d フラグを使用すると、同期先(上のコマンドの gs://example-bucket)で、同期元(local-dir)に存在しないファイルを削除するように、gsutil に指示します。2 つのバケットの間で同期することもできます。

大きなファイルのバケットへのコピー

一般的に、ビッグデータを利用するときには、クラウドに移動したデータはクラウドにそのまま保存する必要があります。データが Google のクラウドに保存された後は、Google Compute Engine などの他のサービスに高速で転送されます。さらに、同じロケーションまたはサブロケーションにあるバケットから Google Cloud サービスへの下りは無料になります。詳しくは、ネットワークの料金体系をご覧ください。

大きなローカル ファイルをバケットにコピーするには、次のコマンドを使用します。

gsutil cp local-file gs://example-bucket

大きなファイルを既存のバケット(Genomics 一般公開データなど)からコピーするには、次のコマンドを使用します。

gsutil cp gs://example-source-bucket/file  gs://example-destination-bucket

gsutil は、Google Cloud Storage の再開可能なアップロードおよびダウンロード機能を最大限に活用します。大きなファイルの場合、転送されるデータのサイズが大きくなると、ISP でネットワーク障害が発生する可能性が高くなるので、これは特に重要です。サーバーが実際に受信したバイト数を基にしてアップロードを再開することにより、gsutil は、不要なバイトの再送信を回避し、最終的にアップロードを確実に完了できます。ダウンロードにも、ローカル ファイルのサイズを基準として同じロジックが適用されます。

大きなファイルをアップロードする際に gsutil cp では必要なパフォーマンスを実現できない場合は、複合アップロードの構成を検討します。

バケットの構成

バケットを構成する必要がある一般的なビッグデータ タスクとしては、異なるストレージ クラスへのデータの移動、ログアクセスの構成、オブジェクトのバージョニングの構成、ライフサイクル ルールの設定などがあります。

バケットの構成の詳細は gsutil ls -L -b を使用して表示できます。

gsutil ls -L -b gs://example-bucket

出力にバケットの構成情報が表示されますが、それらのほとんどは gsutil でも構成できます。

  • CORS: バケットの Cross-Origin-Resource-Sharing 設定を制御します。
  • ロギング: バケットの使用状況をログに記録できます。
  • ウェブサイト: バケット内のオブジェクトをウェブページとして機能させたり、ウェブサイトで静的なアセットとして使用したりできます。
  • バージョニング: バケット内のオブジェクトを削除して、アーカイブされたバージョンを作成します。
  • ストレージ クラス: バケットの作成中にストレージ クラスを設定できます。
  • ライフサイクル: 定期的なオペレーションをバケット上で実行できます。最も一般的なのは、古くなったオブジェクトの削除です。

たとえば、特定のバケット内に 1 日だけファイルを保管したい場合、次のコマンドを使用してバケットのライフサイクル ルールを設定できます。

echo '{ "rule": [{ "action": {"type": "Delete"}, "condition": {"age": 1}}]}' > lifecycle_config.json
gsutil lifecycle set lifecycle_config.json gs://example-bucket

これで、バケット内の 1 日以上経過しているオブジェクトがバケットから自動的に削除されます。gsutil lifecycle コマンドで行った構成を確認できます(他の構成コマンドも同じように機能します)。

gsutil lifecycle get gs://example-bucket

バケット内のデータの共有

ビッグデータを利用するときには、共同でファイルを利用することが多いので、特定のユーザーまたはグループにアクセス権を付与できる必要があります。アクセスできるユーザーを記述する ACL が各オブジェクトに指定されます。オブジェクトの ACL の詳細は gsutil acl コマンドを使用して表示できます。

gsutil acl get gs://example-bucket/file

オブジェクトをアップロードしたエンティティ(この場合は、OAuth2 更新トークンによって表される Google アカウント)は、オブジェクトに対するオーナー アクセス権を自動的に取得します。詳しくは、プロジェクト メンバーと権限をご覧ください。

オブジェクトの ACL の残りの部分は、バケットのデフォルトのオブジェクト ACL によって決定されます。これはよく混乱されやすい点です。バケット ACL がバケットへのアクセス(オブジェクトを作成および一覧表示する権限など)を制御するのに対し、デフォルトのオブジェクト ACL は作成時にオブジェクトが取得する ACL を制御し、この 2 つが同じとは限りません。この 2 つの違いについて詳しくは、アクセス制御をご覧ください。

Google アカウントを持っているどのユーザーも、バケット内のファイルを一覧表示できるようにバケットを構成できます。この場合、データへのアクセス権は付与されません。そのため、ユーザーは、bigfile がバケット内に存在することを確認できますか、その内容は表示できません。

gsutil acl ch -g 'AllAuthenticatedUsers:R' gs://example-bucket

ls -Lb コマンドを使用してバケットの ACL を表示できます。

gsutil ls -Lb gs://example-bucket

これで、Google アカウントで認証されたすべてのユーザーがバケット内のファイルを一覧表示できます。

次の 3 つのセクションでは、データの一般公開での共有、グループでの共有、ユーザーとの共有という 3 つの一般的なシナリオについて説明します。

一般公開

世界中が読むことができるバケットにする場合、次のように構成します。

# Read access on the bucket so that is contents can be listed
gsutil acl ch -g AllUsers:R gs://example-bucket

# Default bucket ACL so any new objects added at a later date are readable.
gsutil defacl ch -g AllUsers:R gs://example-bucket

# Read access to all of its current contents.
gsutil -m acl ch -R -g AllUsers:R gs://example-bucket

グループでの共有

Google Cloud Platform プロジェクトのメンバーになっていない共同編集者の場合、Google グループを作成し、その Google グループをバケットに追加することをおすすめします。たとえば、gs-announce Google グループの場合は、次のように構成します。

# Read access to the bucket so that its contents can be listed.
gsutil acl ch -g 'gs-announce@googlegroups.com:R' gs://example-bucket

# Default bucket ACL so any new objects added at a later date are readable.
gsutil defacl ch -g 'gs-announce@googlegroups.com:R' gs://example-bucket

# Read access to all of a bucket's current contents.
gsutil -m acl ch -R -g 'gs-announce@googlegroups.com:R' gs://example-bucket

詳しくは、グループを使用したオブジェクトへのアクセスの制御をご覧ください。

1 人のユーザーとの共有

多くの共同編集者がいる場合はグループを使用します。1 人の場合は、次のようにアクセス権を構成します。

# Read access to the bucket so that its contents can be listed.
gsutil acl ch -u liz@gmail.com:R gs://example-bucket

# Default bucket ACL so any new objects added at a later date are readable.
gsutil defacl ch -u liz@gmail.com:R gs://example-bucket

# Read access to all of a bucket's current contents.
gsutil -m acl ch -R -u liz@gmail.com:R gs://example-bucket

バケット内のデータ量の表示

gsutil du コマンドを使用して、指定したバケットのすべてのオブジェクトによって使用されている合計容量を表示できます。次に例を示します。

gsutil du -sh gs://example-bucket

同じ接頭辞のすべてのオブジェクトのサイズを返す方法など、使用可能なその他のオプションについては、gsutil du コマンドのヘルプをご覧ください。

バケットのロギングを設定し、バケットの合計サイズが 1 日に 1 回自動的に報告されるようにすることもできます。詳しくは、アクセスログについての記事をご覧ください。バケット内のオブジェクト数が多い場合は(数百、数千、数百万など)、この方法で、使用容量をより効率的にトラッキングできます。gsutil du コマンドは、バケットの一覧表示リクエストを実行することで使用容量を計算するので、大きなバケットの場合は時間がかかることがあります。

次のコマンドでバケット内のファイルの数をカウントできます。

gsutil ls gs://example-bucket/** | wc -l

バケットのクリーンアップ

次のコマンドでバケットをすばやくクリーンアップできます。

gsutil -m rm gs://example-bucket/**

チェックサムの操作

gsutil cp コマンドと gsutil rsync コマンドは、コピーを実行するときに、コピー元ファイルのチェックサムがコピー先ファイルのチェックサムと一致することを確認します。例外的にチェックサムが一致しない場合、gsutil が、無効なコピーを削除し、警告メッセージを出力します。詳細については、チェックサムの検証をご覧ください。

gsutil を使用してバケット内のファイルのチェックサムを取得したり、ローカル オブジェクトのチェックサムを計算したりできます。たとえば、次のように Google Genomics 一般公開データファイルを作業中のバケットにコピーするとします。

gsutil -m cp gs://genomics-public-data/1000-genomes/vcf/ALL.chrMT.phase1_samtools_si.20101123.snps.low_coverage.genotypes.vcf gs://example-bucket

これで、ファイルの一般公開バケット バージョンとバケット内のファイルのバージョンの両方のチェックサムを取得し、一致することを確認できます。

gsutil ls -L gs://example-bucket/ALL.chrMT.phase1_samtools_si.20101123.snps.low_coverage.genotypes.vcf
gsutil ls -L gs://genomics-public-data/1000-genomes/vcf/ALL.chrMT.phase1_samtools_si.20101123.snps.low_coverage.genotypes.vcf

次に、ローカル データセンターのファイル内にデータがあり、それを Cloud Storage にコピーするとします。gsutil hash を使用して、ローカル ファイルのチェックサムを取得し、バケットにコピーしたファイルのチェックサムと比較できます。ローカル ファイルのチェックサムを取得するには、次のコマンドを使用します。

gsutil hash local-file

MD5 値

非複合オブジェクトの場合、バケット内のオブジェクトに対して gsutil ls -L を実行すると、次のような出力が返されます。

gs://example-bucket/100MBfile.txt:
        Creation time:          Thu, 26 Mar 2015 20:11:51 GMT
        Content-Length:         102400000
        Content-Type:           text/plain
        Hash (crc32c):          FTiauw==
        Hash (md5):             daHmCObxxQdY9P7lp9jj0A==
        ETag:                   CPjo7ILqxsQCEAE=
        Generation:             1427400711419000
        Metageneration:         1
        ACL:            [
        ....

ローカル ファイルに対して gsutil hash を実行すると、次のような出力が返されます。

Hashing     100MBfile.txt:
Hashes [base64] for 100MBfile.txt:
        Hash (crc32c):          FTiauw==
        Hash (md5):             daHmCObxxQdY9P7lp9jj0A==

両方の出力に CRC32c と MD5 値があります。gsutil で複合アップロードを構成する場合と同じく、複合オブジェクトとしてアップロードされるオブジェクトには MD5 値はありません。

並列複合アップロードの構成

gsutil の構成方法によって、大きなファイルをアップロードするときのパフォーマンスを向上させることができます。つまり、各ファイルを複数の部分に分割して各部分を並列アップロードし、その後で Cloud Storage の複合オブジェクト機能を使用してそれらの部分を組み合わせて複合オブジェクトに戻すように構成します。詳しくは、並列複合アップロードをご覧ください。並列複合アップロードはデフォルトで無効になっています。

並列複合アップロードを構成する前に、利点と欠点を認識する必要があります。主な利点は、ネットワークやディスクの速度が制限要因になっていない場合、大きなファイルのアップロードが大幅に高速化できることです。並列複合アップロードの欠点は以下のとおりです。

  • ユーザー(または共同編集者)が gsutil を使用して複合アップロード(gsutil 並列複合アップロードを使用して作成されたアップロードなど)をダウンロードする場合、gsutil help crcmod の説明に従ってコンパイル済みの crcmod をインストールすることをおすすめします。そのようにしないと、コンパイル済みの crcmod を使用せずに複合オブジェクトをダウンロードすると実行に非常に時間がかかることを警告するメッセージが表示されます。並列複合アップロード オプションの設定にかかわらず、ダウンロードにはコンパイル済みの crcmod を使用することをおすすめします。

  • バケット内の複合オブジェクトには MD5 ハッシュがありません。

gsutil help crcmod の手順に沿って crcmod を構成してコンパイルした後で、並列複合アップロードがデフォルトでオンになるように .boto ファイルを構成します。詳しくは、gsutil の構成.boto ファイルの GSUtil セクションの parallel_composite_upload_* の設定をご覧ください。

並列複合アップロードを有効にし、大きなファイルをバケットにアップロードする場合、1 つのアップロードではなく、ファイルが 50 MB のチャンクでアップロードされます。たとえば、一時的なネットワークの問題などが原因でエラーが発生した場合、no-clobber(-n)フラグを指定してコピーを再実行し、失敗したファイルのみを転送できます。

複合オブジェクトとしてアップロードされたバケット内のファイルのデータの整合性をチェックするときには、CRC32c ハッシュ値のみがあり、MD5 値はありません。

並列複合アップロードを構成した場合、アップロードが中断されたときに一時ファイルが残される可能性があります。アップロードを再開しない場合は、これらの一時ファイルを削除しても問題ありません。

gsutil -m rm gs://example-bucket/**/gsutil/tmp/parallel_composite_uploads/for_details_see/gsutil_help_cp**

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...

ご不明な点がありましたら、Google のサポートページをご覧ください。