大量入力の処理

このページでは、Variant Transforms ツールを使用して多数のファイルを読み込む際に、パフォーマンスを向上させてコストを削減する方法を示します。

Variant Transforms ツールのデフォルト設定

Variant Transforms ツールは次のデフォルト設定で実行されます。

フラグ デフォルト
--optimize_for_large_inputs False
--max_num_workers 自動的に決定
--worker_machine_type n1-standard-1
--disk_size_gb 250
--worker_disk_type PD
--num_bigquery_write_shards 1

これらの各設定を調整してツールのパフォーマンスを最適化できます。Compute Engine の割り当てをリクエストすることもできます。各フラグの説明は次のとおりです。

--optimize_for_large_inputs

このフラグは、大量入力用の Cloud Dataflow パイプラインを最適化します。これによりコストを大幅に削減し、ターンアラウンド タイムを短縮できます。ただし、少量の入力の場合、追加のオーバーヘッドによってコストとターンアラウンド タイムが増加する可能性があります。

50,000 を超えるファイルを読み込むか、多数のバリアント(30 億を超える)に対するバリアントのマージが有効になっている場合(あるいはその両方の場合)は、このフラグを true に設定します。

--max_num_workers

デフォルトでは、Cloud Dataflow は、ジョブの実行に必要な適切な数のワーカー インスタンスを自動的に選択する自動スケーリング アルゴリズムを使用します(Compute Engine の割り当てによって制限されます)。

このフラグを調整すると、Cloud Dataflow が自動スケーリングするジョブのワーカーの最大数が増えます。--num_workers フラグを使用して、ジョブに最初に割り当てられるワーカーの数を指定することもできます。

--worker_machine_type

デフォルトでは、Cloud Dataflow は 1 つの vCPU と 3.75 GB の RAM が搭載された n1-standard-1 マシンタイプを使用します。多数のファイルを読み込む場合は、より大きなマシンを要求する必要がある場合があります。詳細については、事前定義されたマシンタイプをご覧ください。

Cloud Dataflow で最高のパフォーマンスを得るには、少数の大型マシンではなく、多数の小型マシンを使用します。たとえば、25 個の n1-standard-32 ワーカーではなく、200 個の n1-standard-4 ワーカーを使用してください。このことは、特にバリアントのマージが有効な場合に、各マシンでディスクとネットワークの 1 秒あたりの入出力操作(IOPS)が制限されるために推奨されます。

ただし、ディスクおよび IP アドレスの割り当てには制限があるため、多数のワーカーをいつも使用できるとは限りません。このような場合、SSD を(--worker_disk_type フラグで設定)、大型のマシン(n1-standard-16 以上)で使用します。これにより、より高いディスク IOPS が得られ、CPU サイクルがアイドル状態になることが回避されます。ディスクは CPU よりもずっと安価であるため、ディスク使用率でなく CPU 使用率を高くするように最適化してください。

--disk_size_gb

デフォルトでは、各ワーカーは 250 GB のディスクサイズを持っています。すべてのワーカーの合計ディスク容量は、処理されるすべての VCF ファイルの未圧縮状態のサイズと同じかそれ以上である必要があります。ただし、推奨されるディスクサイズは、処理されるすべての VCF ファイルの未圧縮状態のサイズの 3 〜 4 倍です。これには次の理由があります。

  • パイプラインの中間ステージでは、追加のディスク容量が必要になります。
  • 変換ステージでは、追加のオーバーヘッドが生じます。たとえば、サンプル名は BigQuery 出力の各レコードで繰り返されますが、VCF ヘッダーでは 1 回だけ指定されます。

バリアントのマージまたは --num_bigquery_write_shards フラグを有効にすると、同じバリアントが 1 台のマシンに集約されるため、各ワーカーに必要なディスクサイズが大きくなることがあります。

--worker_disk_type

Compute Engine インスタンスには、標準および SSD の 2 種類のメイン ストレージ タイプがあります。

SSD は標準ディスクよりもはるかに大きい IOPS を提供しますが、より高価になります。しかし、n1-standard-16 などの大型マシンを利用する場合、SSD によってコストが削減されます。SSD を使用することで、IOPS の制限による CPU サイクルのアイドル状態を回避できるためです。

バリアントのマージまたは --num_bigquery_write_shards フラグが有効な場合は、SSD を使用します。これらの操作はデータをシャッフルするため、大量のディスク I/O が必要です。

SSD を使用するには、--worker_disk_type フラグを compute.googleapis.com/projects//zones//diskTypes/pd-ssd に設定します。

--num_bigquery_write_shards

Variant Transforms ツールの基礎となる Cloud Dataflow パイプラインは、主変換が完了した後の後処理ステップとしてデータを BigQuery に書き込みます。BigQuery には書き込み制限があるため、書き込み時にデータをシャーディングする必要があります。データをシャーディングすることで、書き込みプロセスを並列化し、大きな(5 TB を超える)データセットを一度に BigQuery に読み込むことができるため、BigQuery へのデータ書き込み速度が大幅に向上します。

10 億行以上(バリアントのマージ後)のデータまたは 1 TB 以上の出力を持つデータを読み込む場合は、--num_bigquery_write_shards フラグを 20 に設定します。

多数のシャード(50 など)を使用した場合、各 BigQuery テーブルに対する同時書き込み数に制限があるため、BigQuery へのデータ書き込みプロセスが失敗する可能性があります。

Compute Engine の割り当てのリクエスト

デフォルトで Compute Engine にはリソースの割り当てがあり、不注意による使用を防ぎます。割り当てを増やすことで、より多くの仮想マシンを同時に起動し、スループットを向上させ、ターンアラウンド タイムを短縮できます。

多数のファイルを読み込むときに、ツールのパフォーマンスが低いかまったく動作していない場合、プロジェクトのデフォルトよりも多くの割り当てをリクエストできます。割り当ての増加に関するおすすめは次のとおりです。

  • CPU: ワーカーあたり 1 つ。より大きなマシンタイプを使用する場合はそれ以上。
  • Persistent Disk Standard(GB): ワーカーあたり 250 GB。より大きなディスクを使用する場合はそれ以上。
  • Persistent Disk SSD(GB): --worker_disk_type フラグが SSD に設定されている場合のみ必要です。推奨される割り当てサイズはワーカーあたり 250 GB で、より大きなディスクを使用する場合はそれ以上になります。
  • 使用 IP アドレス: ワーカーあたり 1 つ

Compute Engine の割り当ては、ジョブで利用可能なリソースの上限であることに注意してください。たとえば、使用 IP アドレスの割り当てが 10 に設定されているときに、--max_num_workers20 に設定してツールを実行すると、ジョブは 20 ワーカーではなく 10 ワーカーで実行されます。

プリプロセッサ ツールを使用した大量入力の処理

大量入力の処理は、コストがかかり、数時間かかることがあります。したがって、VCF ファイルを BigQuery に読み込む前に、VCF ファイルに対してプリプロセッサ ツールを実行する必要があります。そうすることで、無効なレコードによる失敗を避けることができ、コストを削減してターンアラウンド タイムを短縮できます。

入力ファイルの品質に応じて、ファイルに関する完全なレポートを取得するために、--report_all_conflicts フラグを付けてプリプロセッサ ツールを実行した方がよい場合もあります。これを行うと、時間がかかることがありますが、データに関するより正確なレポートが提供されます。入力ファイルの品質が不確かな場合は、この手順をおすすめします。

バリアントのマージ

バリアントのマージを使用して、VCF ファイル間で呼び出しをマージできます。--variant_merge_strategy フラグを渡すことで、さまざまなマージ オプションを指定できます。

デフォルトでは、VCF ファイル間の呼び出しはマージされません。たとえば、以下の 2 つの VCF ファイルが同じ Cloud Storage バケット内にあり、これらを同時に(--input_pattern gs://my-bucket/*.vcf フラグを渡して)読み込む場合、Variant Transforms ツールは BigQuery に 2 行を読み込みます。

gs://my-bucket/a.vcf:

## <headers omitted>
#CHROM  POS   ID    REF   ALT   QUAL  FILTER  INFO    FORMAT  S1      S2
1       100   rs1   A     T     29    PASS    DP=14   GT:GQ   0|1:48  0/0:30

gs://my-bucket/b.vcf:

## <headers omitted>
#CHROM  POS   ID    REF   ALT   QUAL  FILTER  INFO         FORMAT  S3
1       100   rs1   A     T     7     q10     DP=11;AA=G   GT:GQ   1/1:2

すべての呼び出しが同じバリアントを持っていても、一方の行は呼び出し S1S2 を持ち、他方の行は呼び出し S3 を持っています。

MOVE_TO_CALLS 戦略

--variant_merge_strategy MOVE_TO_CALLS 戦略は、次のフィールドが同じファイル間で呼び出しをマージします。

  • reference_name
  • start_position
  • end_position
  • reference_bases
  • alternate_bases

デフォルトでは、これらのフィールドは次のようにマージされます。

  • calls は順不同でマージされます。
  • マージされるバリアントの中で最高の quality 値が選択されます。
  • すべての filter 値がマージされ、重複排除されます。
  • すべての names(VCF 仕様の ID 列に相当)がマージされ、重複排除されます。
  • 順不同でマージされたバリアント レコード全体を表すために、1 つの INFO フィールドが選択されます。繰り返しフィールドの場合、その特定のフィールドを表すために単一のセットが選択されます。

次のフラグを使用してマージ戦略をカスタマイズできます。

  • --copy_quality_to_calls または --copy_filter_to_calls(あるいはその両方)

    各ファイルの quality または filter(あるいはその両方)の値を、そのファイルで指定された呼び出しセットにコピーします。通常、qualityfilter 値は呼び出しレベルの品質とフィルタに対応するため、単一の呼び出し VCF ファイルをマージする場合に便利です。バリアント レベルの quality 値と filter 値は、前述のロジックに従ってマージされます。

  • --info_keys_to_move_to_calls_regex REGEX

    指定された正規表現に一致する INFO フィールドを関連する呼び出しに移動します。これにより、マージ時にすべての INFO フィールドが保持されます。

    :

    • --info_keys_to_move_to_calls_regex .* と指定すると、すべての INFO キーが呼び出しに移動されます。
    • --info_keys_to_move_to_calls_regex ^(AA|AF)$ と指定すると、AA フィールドと AF フィールドだけが呼び出しに移動されます。

    INFO フィールドと FORMAT フィールドの両方でキーが同じであれば、そのキーを呼び出しに移動することはできず、エラーが発生します。

    正規表現仕様の詳細については、正規表現構文をご覧ください。

マージロジックの実装例を見るには、GitHub の move_to_calls_strategy.py ファイルのコードとドキュメントをご覧ください。特に get_merged_variants メソッドに注意してください。

次の例では、上記の gs://my-bucket/a.vcf ファイルと gs://my-bucket/b.vcf ファイルをマージした結果を示しています。

デフォルトの設定

次の例は、デフォルトの設定と --variant_merge_strategy MOVE_TO_CALLS フラグを使用して Variant Transforms ツールを実行した結果を示しています。

reference_name: "1"
start_position: 100
end_position: 101
reference_bases: "A"
alternate_bases: {alt: "T"}
names: ["rs1"]
quality: 29
filter: ["PASS", "q10"]
call: {
  [
    name: "S3",
    genotype: [1, 1]
    phaseset: null
    GQ: 2
  ],
  [
    name: "S1",
    genotype: [0, 1]
    phaseset: "*"
    GQ: 48
  ],
  [
    name: "S2",
    genotype: [0, 0]
    phaseset: null
    GQ: 30
  ]
}
DP: 14  # This can also be 11.
AA: "G"

qualityfilter の呼び出しへのコピー

次の例は、デフォルトの設定と次のフラグを使用して Variant Transforms ツールを実行した結果を示しています。

  • --variant_merge_strategy MOVE_TO_CALLS
  • --copy_quality_to_calls
  • --copy_filter_to_calls
reference_name: "1"
start_position: 100
end_position: 101
reference_bases: "A"
alternate_bases: {alt: "T"}
names: ["rs1"]
quality: 29
filter: ["PASS", "q10"]
call: {
  [
    name: "S3",
    genotype: [1, 1]
    phaseset: null
    GQ: 2
    quality: 7
    filter: ["q10"]
  ],
  [
    name: "S1",
    genotype: [0, 1]
    phaseset: "*"
    GQ: 48
    quality: 29
    filter: ["PASS"]
  ],
  [
    name: "S2",
    genotype: [0, 0]
    phaseset: null
    GQ: 30
    quality: 29
    filter: ["PASS"]
  ]
}
DP: 14  # This can also be 11.
AA: "G"

正規表現の使用による関連した呼び出しへの INFO フィールドの移動

次の例は、デフォルトの設定と次のフラグを使用して Variant Transforms ツールを実行した結果を示しています。

  • --variant_merge_strategy MOVE_TO_CALLS
  • --copy_quality_to_calls
  • --copy_filter_to_calls
  • --info_keys_to_move_to_calls_regex ^DP$
reference_name: "1"
start_position: 100
end_position: 101
reference_bases: "A"
alternate_bases: {alt: "T"}
names: ["rs1"]
quality: 29
filter: ["PASS", "q10"]
call: {
  [
    name: "S3",
    genotype: [1, 1]
    phaseset: null
    GQ: 2
    quality: 7
    filter: ["q10"]
    DP: 11
  ],
  [
    name: "S1",
    genotype: [0, 1]
    phaseset: "*"
    GQ: 48
    quality: 29
    filter: ["PASS"]
    DP: 14
  ],
  [
    name: "S2",
    genotype: [0, 0]
    phaseset: null
    GQ: 30
    quality: 29
    filter: ["PASS"]
    DP: 14
  ]
}
AA: "G"
このページは役立ちましたか?評価をお願いいたします。

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

Cloud Life Sciences のドキュメント