データファイルの準備

このトピックでは、データファイルをロード用に準備するためのベストプラクティス、一般的なガイドライン、および重要な考慮事項について説明します。

このトピックの内容：

ファイルサイズのベストプラクティスと制限事項

最適なロードパフォーマンスとサイズ制限を回避するために、次のデータファイルのサイズ設定ガイドラインを考慮します。これらの推奨事項は、Snowpipeを使用した連続ロードだけでなく、一括データロードにも該当します。

一般的なファイルサイズの推奨事項

並行して実行されるロード操作の数は、ロードされるデータファイルの数を超えることはできません。ロードの並列操作の数を最適化するには、 圧縮された データファイルのサイズをおよそ100から250 MB（またはそれ以上）にすることをお勧めします。

注釈

非常に大きなファイル（例: 100 GB 以上）をロードすることはお勧めしません。

大きなファイルをロードする必要がある場合は、 ON_ERROR コピーオプションの値を慎重に検討してください。少数のエラーでファイルを中止またはスキップすると、遅延が発生し、クレジットが無駄になる可能性があります。さらに、データのロード操作が最大許容時間の24時間を超えて継続した場合は、ファイルの一部がコミットされずに中止される可能性があります。

小さいファイルを集約して、各ファイルの処理オーバーヘッドを最小限に抑えます。アクティブなウェアハウス内のコンピューティングリソース間でロードを分散するために、大きなファイルを多数の小さなファイルに分割します。並行して処理されるデータファイルの数は、ウェアハウス内のコンピューティングリソースの量によって決まります。記録がチャンクにまたがることを避けるために、大きなファイルは行で分割することをお勧めします。

ソースデータベースでデータファイルを小さなチャンクでエクスポートできない場合、サードパーティのユーティリティを使用して大きな CSV ファイルを分割できます。

Linuxまたは macOS

split ユーティリティを使用すると、 CSV ファイルを複数の小さなファイルに分割できます。

構文：

split [-a suffix_length] [-b byte_count[k|m]] [-l line_count] [-p pattern] [file [name]]
Copy

詳細については、ターミナルウィンドウに man split と入力します。

例：

split -l 100000 pagecounts-20151201.csv pages
Copy

この例では、 pagecounts-20151201.csv という名前のファイルを行の長さで分割します。サイズが8 GB の大きな単一ファイルに、10百万行が含まれているとします。100、000で分割すると、100個の小さいファイルの各サイズは80 MB （10百万/100、000 = 100）です。分割ファイルの名前は pages<サフィックス> です。

Windows

Windowsには、ネイティブファイル分割ユーティリティは含まれていません。ただしWindowsは、大きなデータファイルを分割できる多くのサードパーティツールとスクリプトをサポートしています。

半構造化データサイズの制限

VARIANT の最大サイズは16 MB です。しかし実際には、内部的なオーバーヘッドのために最大サイズは小さくなるのが普通です。最大サイズは保存されるオブジェクトにも依存します。

詳細については、 VARIANT をご参照ください。

一般に、 JSON データセットは、複数のドキュメントの単純な連結です。一部のソフトウェアからの JSON 出力は、複数の記録を含む単一の巨大な配列で構成されています。両方ともサポートされていますが、ドキュメントを改行またはカンマで区切る必要はありません。

データが 16 MB を超える場合は、 COPY INTO <テーブル> コマンドの STRIP_OUTER_ARRAY ファイル形式オプションを有効にして、外部配列構造を削除し、記録を別のテーブル行にロードします。

COPY INTO <table>
  FROM @~/<file>.json
  FILE_FORMAT = (TYPE = 'JSON' STRIP_OUTER_ARRAY = true);
Copy

連続データロード（Snowpipeなど）とファイルサイズ

Snowpipeは、通常、ファイル通知が送信されてから1分以内に新しいデータをロードするように設計されています。ただし、非常に大きなファイルの場合や、新しいデータの圧縮解除、復号化、変換に通常以上のコンピューティングリソースが必要な場合は、ロードにかなりの時間がかかることがあります。

リソースの消費に加えて、内部ロードキュー内のファイルを管理するためのオーバーヘッドも、Snowpipeに請求される使用コストに含まれます。このオーバーヘッドは、ロードのためにキューに入れられたファイルの数に連動して増加します。Snowpipeは外部テーブルの自動更新のイベント通知に使用されるため、このオーバーヘッド料金は請求明細書にSnowpipe料金として表示されます。

Snowpipeで最も効率的で費用対効果の高いロードエクスペリエンスを得るために、 ファイルサイズ設定のベストプラクティスと制限事項 （このトピック内）のファイルサイズ設定の推奨事項に従うことをお勧めします。サイズがおよそ100から250 MB 以上のデータファイルをロードすると、ロードされるデータの合計量に比べて、オーバーヘッドコストが重要ではなくなるまでオーバーヘッド料金が削減されます。

ソースアプリケーションに MBs のデータを蓄積するのに1分以上かかる場合は、新しい（潜在的に小さい）データファイルを1分に1回作成することを検討します。通常、このアプローチは、コスト（つまり、Snowpipeキュー管理に費やされるリソースと実際のロード）とパフォーマンス（つまり、ロードレイテンシー）のバランスにつながります。

小さなデータファイルを作成し、1分に1回よりも頻繁にクラウドストレージにステージングすることには、次の欠点があります。

  • データのステージングとロードの間のレイテンシーの縮小は保証できません。

  • 内部ロードキュー内のファイルを管理するためのオーバーヘッドは、Snowpipeに請求される使用コストに含まれています。このオーバーヘッドは、ロードのためにキューに入れられたファイルの数に連動して増加します。

さまざまなツールでデータファイルを集約およびバッチ処理できます。便利なオプションの1つは、Amazon Data Firehoseです。Firehoseでは、 バッファーサイズ と呼ばれる目的のファイルサイズと、 バッファーインターバル と呼ばれる新しいファイルが（この場合はクラウドストレージに）送信されるまでの待機間隔の両方を定義できます。詳細については、 Amazon Data Firehoseドキュメント をご参照ください。通常、ソースアプリケーションが1分以内に十分なデータを蓄積して、最適な並列処理のために推奨される最大値よりも大きいファイルを取り込む場合は、小さいファイルをトリガーするようにバッファーサイズを縮小することができます。バッファー間隔の設定を60秒（最小値）に維持すると、ファイルの作成が過剰になったり、待ち時間が長くなったりすることを回避できます。

区切りテキストファイルの準備

ロードする区切りテキスト（CSV）ファイルを準備するときは、次のガイドラインを考慮してください。

  • UTF-8がデフォルトの文字セットですが、追加のエンコードがサポートされています。 ENCODING ファイル形式オプションを使用して、データファイルの文字セットを指定します。詳細については、 CREATE FILE FORMAT をご参照ください。

  • 区切り文字を含むフィールドは、引用符（一重または二重）で囲む必要があります。データに一重引用符または二重引用符が含まれる場合、それらの引用符はエスケープする必要があります。

  • キャリッジリターンは、通常、Windowsシステム上で行末を示す改行文字（\r \n）と組み合わせて導入されます。キャリッジリターンを含むフィールドも引用符で囲む必要があります（一重または二重）。

  • 各行の列数は一貫している必要があります。

半構造化データファイルと列指向化

半構造化データが VARIANT 列に挿入されると、Snowflakeは特定のルールを使用して、可能な限り多くのデータを列指向形式で抽出します。残りのデータは、解析された半構造化構造の単一の列として格納されます。

デフォルトでは、Snowflakeはテーブルごと、パーティションごとに最大200個の要素を抽出します。この制限を増やすには、 Snowflakeサポート にお問い合わせください。

抽出されない要素

現在、次の特性を持つ要素は列に抽出 されません。

  • 単一の「null」値を含む要素は列に抽出されません。これは、値が欠落している要素ではなく、列指向形式で表される「null」値をともなう要素に適用されます。

    このルールは、情報が失われないことを保証します（つまり、 VARIANT「null」値と SQL NULL 値の差は失われません）。

  • 複数のデータ型を含む要素。例：

    1行の foo 要素には数字が含まれています。

    {"foo":1}
    Copy

    別の行の同じ要素には文字列が含まれます。

    {"foo":"1"}
    Copy

抽出がクエリに与える影響

半構造化要素に対してクエリを実行すると、Snowflakeの実行エンジンは、要素が抽出されたかどうかによって異なる動作をします。

  • 要素が列に抽出された場合、エンジンは抽出された列のみをスキャンします。

  • 要素が列に抽出 されなかった 場合、実行エンジンは JSON 構造全体をスキャンし、各行で構造を走査して値を出力する必要があります。これはパフォーマンスに影響します。

抽出されなかった要素へのパフォーマンスの影響を避けるには、次を行います。

  • それらをロードする 前に、「null」値を含む半構造化データ要素をリレーショナル列に抽出します。

    または、ファイルの「null」値が欠損値を示しており、他の特別な意味がない場合、半構造化データファイルをロードするときに ファイル形式オプション STRIP_NULL_VALUES を TRUE に設定することをお勧めします。このオプションは、「null」値を含む OBJECT 要素または ARRAY 要素を削除します。

  • それぞれの一意の要素が、その形式に固有である単一のデータ型の値を格納していることを確認してください（例えば、 JSON の文字列または数）。

数値データのガイドライン

  • コンマなどの埋め込み文字（例: 123,456）は避けます。

  • 数値に小数部が含まれる場合、整数部と小数点で区切る必要があります（例: 123456.789）。

  • Oracleのみ。Oracleの NUMBER または NUMERIC 型は、任意のスケールを許可します。つまり、データ型が精度またはスケールで定義されていなくても、小数成分を持つ値を受け入れます。一方、Snowflakeでは、小数部分を持つ値用に設計された列は、小数部分を保持するスケールで定義する必要があります。

日付とタイムスタンプのデータガイドライン

  • 日付、時刻、タイムスタンプデータのサポートされている形式については、 日付と時刻の入出力形式 をご参照ください。

  • Oracleのみ。Oracle DATE データ型には、日付 または タイムスタンプ情報を含めることができます。Oracleデータベースに時間関連情報も保存する DATE 列が含まれている場合、これらの列を DATEではなくSnowflakeの TIMESTAMP データ型にマップします。

注釈

Snowflakeは、ロード時に一時的なデータ値をチェックします。無効な日付、時刻、およびタイムスタンプ値（例: 0000-00-00）ではエラーが発生します。

言語: 日本語