インライン準備
Last updated
Last updated
データの準備には、通常、ローカルファイルシステム上のフォルダである元のデータソースを32GiB未満のCARファイルのコレクションに変換する従来の方法があります。この方法では、データの準備者が2倍のストレージ容量を必要とするため、非常に高価になります。たとえば、1PiBのデータセットの準備にはCARファイル用に別の1PiBのストレージが必要となり、合計2PiBのストレージスペースが必要となります。
インライン準備では、CARファイルのブロックを元のデータソースに対応付けることにより、エクスポートされたCARファイルを保存する必要がなくなります。
インライン準備では、CARファイルは元のデータソースとメタデータデータベースを使用してHTTP経由で提供できます。なぜなら、元のデータソースのバイト範囲をCARファイルのバイト範囲にマッピングする方法を知っているからです。
CARファイルをHTTP経由で提供するには、単にcontent providerを起動します。
注：このコマンドはローカルのHTTPサーバーを実行します。インターネット経由でアクセス可能にする場合は、nginxなどのリバースプロキシの背後に配置することを検討してください。
これにより、データソースがすでにリモートストレージシステム（S3やFTPなど）の場合、ファイルの内容はSingularityコンテンツプロバイダを介してストレージプロバイダにプロキシされるため、パフォーマンスのボトルネックとなります。
この課題に対する解決策として、SingularityメタデータAPIおよびSingularityダウンロードユーティリティを使用する方法があります。
SingularityメタデータAPIを実行するには、
次に、Singularityダウンロードユーティリティ（ストレージプロバイダ上で実行）
SingularityメタデータAPIは、元のデータソースからCARファイルをどのように組み立てるかの計画を返し、Singularityダウンロードユーティリティはこの計画を解釈し、元のデータからローカルのCARファイルにデータをストリーミングします。中間での変換や組み立ては何も行われず、すべてがストリームとして機能します。
メタデータAPIは、元のデータソースからデータにアクセスするために必要な資格情報を返しません。ストレージプロバイダは、自分でデータソースへのアクセス権を取得し、その資格情報をsingularity downloadコマンドに提供する必要があります。
インライン準備には、主に必要なストレージ容量に関するわずかなオーバーヘッドが発生します。また、計算および帯域幅のオーバーヘッドもわずかです。
データの各ブロックのメタデータはデータベースの行として保存され、1MiBのデータブロックごとに100バイトのディスク容量が必要です。1PiBのデータセットの場合、このメタデータマッピングを保存するために10TiBのディスク容量が必要です。これは通常問題ではありませんが、多数の小さいファイルを含むデータセットは、著しく高いディスクオーバーヘッドをもたらす場合があります。
その後、CARファイルが元のデータソースから動的に再生成されると、データベースでこれらのマッピングをクロスリファレンスする必要があります。ただし、これは一般的には懸念されません。1GB/秒の帯域幅は、1,000のデータベースエントリの検索に相当し、これはすべてのサポートされているデータベースバックエンドのボトルネック能力からはるかに少ないです。さらに、将来の最適化により、このオーバーヘッドはさらに削減される可能性があります。
インライン準備は、暗号化が必要ないデータセットに自動的に有効になります。データセットの作成時に出力ディレクトリが指定されると、CARファイルはその場所にエクスポートされます。CARの取得要求は、これらのディレクトリを優先します。CARファイルがユーザーによって削除されると、システムは元のデータソースからの取得に戻ります。