データファイルの準備

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

このトピックの内容:

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

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

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

並行して実行されるロード操作の数は、ロードされるデータファイルの数を超えることはできません。ロードの並列操作の数を最適化するには、 圧縮された データファイルのサイズをおよそ10 MB から100 MB にすることをお勧めします。小さいファイルを集約して、各ファイルの処理オーバーヘッドを最小限に抑えます。アクティブなウェアハウス内のサーバー間でロードを分散するために、大きなファイルを多数の小さなファイルに分割します。並列処理されるデータファイルの数は、ウェアハウス内のサーバーの数と容量によって決まります。レコードがチャンクにまたがることを避けるために、大きなファイルは行で分割することをお勧めします。

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

Linuxまたは macOS

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

構文:

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

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

例:

split -l 100000 pagecounts-20151201.csv pages

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

Windows

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

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

VARIANT データ型は、個々の行に16 MB (圧縮)のサイズ制限を課します。

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

代わりに、 COPY INTO <テーブル> コマンドの STRIP_OUTER_ARRAY ファイル形式オプションを有効にして、外部配列構造を削除し、レコードを別のテーブル行にロードすることをお勧めします。

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

Parquetのデータサイズの制限

現在、大きいParquetファイル(例:3 GB より大きい)のデータロードはタイムアウトする可能性があります。ロード用に、大きなファイルを1 GB (またはそれ以下)のサイズのファイルに分割します。

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

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

リソースの消費に加えて、内部ロードキュー内のファイルを管理するためのオーバーヘッドも、Snowpipeに請求される使用コストに含まれます。このオーバーヘッドは、ロードのためにキューに入れられたファイルの数に連動して増加します。Snowpipeは、キューに入れられた1000ファイルごとに0.06クレジットを請求します。

Snowpipeで最も効率的で費用対効果の高いロードエクスペリエンスを得るために、 ファイルサイズ設定のベストプラクティスと制限事項 (このトピック内)のファイルサイズ設定の推奨事項に従うことをお勧めします。ソースアプリケーションに MBs 個のデータを蓄積するのに1分以上かかる場合は、新しい(潜在的に小さい)データファイルを1分に1回作成することを検討します。通常、このアプローチは、コスト(つまり、Snowpipeキュー管理に費やされるリソースと実際のロード)とパフォーマンス(つまり、ロードレイテンシー)のバランスにつながります。

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

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

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

さまざまなツールでデータファイルを集約およびバッチ処理できます。便利なオプションの1つは、Amazon Kinesis Firehoseです。Firehoseでは、 バッファーサイズ と呼ばれる目的のファイルサイズと、 バッファーインターバル と呼ばれる新しいファイルが(この場合はクラウドストレージに)送信されるまでの待機間隔の両方を定義できます。詳細については、 Kinesis Firehoseのドキュメント をご参照ください

通常、ソースアプリケーションが1分以内に十分なデータを蓄積して、最適な並列処理のために推奨される最大値よりも大きいファイルを取り込む場合、バッファーサイズを増やすことができます。バッファー間隔の設定を60秒(最小値)に維持すると、ファイルの作成が過剰になったり、待ち時間が長くなったりすることを回避できます。

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

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

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

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

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

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

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

半構造化データが VARIANT 列に挿入されると、Snowflakeは特定のルールに基づいて、可能な限り多くのデータを列指向形式で抽出します。残りは、解析された半構造化構造の単一の列として格納されます。現在、次の特性を持つ要素は列に抽出 されません

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

    このルールにより、情報が失われないようにします。つまり、 VARIANT の「null」値と SQL NULL 値の差が曖昧にならないようにします。

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

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

    {"foo":1}
    

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

    {"foo":"1"}
    

半構造化要素がクエリされると、

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

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

このパフォーマンスの低下を回避するには、

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

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

  • 一意の各要素に、単一のネイティブデータ型(文字列または数値)の値が格納されていることを確認します。

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

  • コンマなどの埋め込み文字(例: 123,456)は避けてください。

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

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

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

  • 日付、時刻、およびタイムスタンプのデータは、次のコンポーネントに基づいてフォーマットする必要があります。

    形式

    説明

    YYYY

    年を表す4桁の数字。

    YY

    TWO_DIGIT_CENTURY_START セッションパラメーターによって制御される年を表す2桁の数字。例: 1980 に設定されている場合、 79 および 80 の値はそれぞれ 2079 および 1980 として解析されます。

    MM

    月を表す2桁の数字(01=1月など)。

    MON

    完全な月名または短縮された月名。

    DD

    日を表す2桁の数字(01から31)。

    DY

    曜日の略称。

    HH24

    時間を表す2桁の数字(00から23)。午前/午後は許可されて いません

    HH12

    時間を表す2桁の数字(01から12)。午前/午後は許可されています。

    AMPM

    午前(am)/午後(pm)。 HH12 で使用します。

    MI

    分を表す2桁の数字(00から59)。

    SS

    秒を表す2桁の数字(00から59)。

    FF

    精度0(秒)から9(ナノ秒)までの小数秒。例: FFFF0FF3FF9FF を指定することは、 FF6 (マイクロ秒)と同等です。

    TZH:TZMTZHTZMTZH

    タイムゾーンの時間と分、 UTC との時差。記号として +/- を付けることができます。

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

注釈

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