データファイルの準備¶

ファイルサイズのベストプラクティス¶

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

データベースオブジェクトのサイズ制限¶

SELECT SYSTEM$ENABLE_BEHAVIOR_CHANGE_BUNDLE('2025_03');

Snowflake にデータ読み込み中 の利用可能メソッドを使用すると、16 MB を超えるサイズのオブジェクトを列に格納できるようになりました。特定のデータタイプには以下の制限が適用されます。

VARCHAR 列のデフォルトサイズは16 MB のままです (バイナリの場合は8 MB)。16 MB を超える列を持つテーブルを作成する場合は、明示的にサイズを指定します。例:

CREATE OR REPLACE TABLE my_table (
  c1 VARCHAR(134217728),
  c2 BINARY(67108864));

VARCHAR 列の新しい制限を使用するには、列のサイズを変更するためにテーブルを変更することができます。例:

ALTER TABLE my_table ALTER COLUMN col1 SET DATA TYPE VARCHAR(134217728);

これらのテーブルのBINARYタイプの列に新しいサイズを適用するには、テーブルを再作成してください。既存のテーブルのBINARY列の長さを変更することはできません。

ARRAY 、 GEOGRAPHY 、 GEOMETRY 、 OBJECT 、 VARIANT のタイプの列については、デフォルトでは、既存のテーブルや新しいテーブルに、長さを指定せずに、16 MB より大きなオブジェクトを格納することができます。例:

CREATE OR REPLACE TABLE my_table (c1 VARIANT);

これらの変更はUnistoreのワークロードには影響しません。ハイブリッド・テーブルの場合、現在の制限はすべて変更されません。

新しいサイズ制限が導入される前に作成された、 VARIANT 、 VARCHAR 、 BINARY の値を入力または出力として使用するプロシージャや関数も、16 MB より大きなオブジェクトをサポートするように（長さを指定せずに）再作成する必要があります。例:

CREATE OR REPLACE FUNCTION udf_varchar(g1 VARCHAR)
  RETURNS VARCHAR
  AS $$
    'Hello' || g1
  $$;

管理されていない Iceberg テーブル の場合、 VARCHAR および BINARY 列のデフォルトの長さは 128 MB です。このデフォルトの長さは、新しく作成または更新されたテーブルに適用されます。新しいサイズ制限が有効になる前に作成され、リフレッシュされなかったテーブルは、以前のデフォルトの長さのままです。

管理されているIcebergテーブルでは、VARCHARとBINARY列のデフォルトの長さは128 MBです。新しいサイズ制限が有効になる前に作成されたテーブルは、以前のデフォルトの長さのままです。これらのテーブルのVARCHARタイプの列に新しいサイズを適用するには、テーブルを再作成するか、列を変更してください。以下の例では、列を変更して新しいサイズ制限を使用しています。

ALTER ICEBERG TABLE my_iceberg_table ALTER COLUMN col1 SET DATA TYPE VARCHAR(134217728);

これらのテーブルのBINARYタイプの列に新しいサイズを適用するには、テーブルを再作成してください。既存のテーブルのBINARY列の長さを変更することはできません。

100067 (54000): The data length in result column <column_name> is not supported by this version of the client.
Actual length <actual_size> exceeds supported length of 16777216.

Max LOB size (16777216) exceeded

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

{
  "ID": 1,
  "CustomerDetails": {
    "RegistrationDate": 158415500,
    "FirstName": "John",
    "LastName": "Doe",
    "Events": [
      {
        "Type": "LOGIN",
        "Time": 1584158401,
        "EventID": "NZ0000000001"
      },
      /* ... */
      /* this array contains thousands of elements */
      /* with total size exceeding 16 MB */
      /* ... */
      {
        "Type": "LOGOUT",
        "Time": 1584158402,
        "EventID": "NZ0000000002"
      }
    ]
  }
}

CREATE OR REPLACE TABLE mytable AS
  SELECT
    t1.$1:ID AS id,
    t1.$1:CustomerDetails:RegistrationDate::VARCHAR AS RegistrationDate,
    t1.$1:CustomerDetails:FirstName::VARCHAR AS First_Name,
    t1.$1:CustomerDetails:LastName::VARCHAR AS as Last_Name,
    t2.value AS Event
  FROM @json t1,
    TABLE(FLATTEN(INPUT => $1:CustomerDetails:Events)) t2;

+----+-------------------+------------+------------+------------------------------+
| ID | REGISTRATION_DATE | FIRST_NAME | LAST_NAME  | EVENT                        |
|----+-------------------+------------+------------+------------------------------|
| 1  | 158415500         | John       | Doe        | {                            |
|    |                   |            |            |   "EventID": "NZ0000000001", |
|    |                   |            |            |   "Time": 1584158401,        |
|    |                   |            |            |   "Type": "LOGIN"            |
|    |                   |            |            | }                            |
|                     ... thousands of rows ...                                   |
| 1  | 158415500         | John       | Doe        | {                            |
|    |                   |            |            |   "EventID": "NZ0000000002", |
|    |                   |            |            |   "Time": 1584158402,        |
|    |                   |            |            |   "Type": "LOGOUT"           |
|    |                   |            |            | }                            |
+----+-------------------+------------+------------+------------------------------+

CREATE OR REPLACE TABLE mytable (
  id VARCHAR,
  registration_date VARCHAR(16777216),
  first_name VARCHAR(16777216),
  last_name VARCHAR(16777216),
  event VARCHAR(16777216));

INSERT INTO mytable
  SELECT
    t1.$1:ID,
    t1.$1:CustomerDetails:RegistrationDate::VARCHAR,
    t1.$1:CustomerDetails:FirstName::VARCHAR,
    t1.$1:CustomerDetails:LastName::VARCHAR,
    t2.value
  FROM @json t1,
    TABLE(FLATTEN(INPUT => $1:CustomerDetails:Events)) t2;

<?xml version='1.0' encoding='UTF-8'?>
<osm version="0.6" generator="osmium/1.14.0">
  <node id="197798" version="17" timestamp="2021-09-06T17:01:27Z" />
  <node id="197824" version="7" timestamp="2021-08-04T23:17:18Z" >
    <tag k="highway" v="traffic_signals"/>
  </node>
  <!--  thousands of node elements with total size exceeding 16 MB -->
  <node id="197826" version="4" timestamp="2021-08-04T16:43:28Z" />
</osm>

CREATE OR REPLACE TABLE mytable AS
  SELECT
    value:"@id" AS id,
    value:"@version" AS version,
    value:"@timestamp"::datetime AS TIMESTAMP,
    value:"$" AS tags
  FROM @mystage,
    LATERAL FLATTEN(INPUT => $1:"$")
  WHERE value:"@" = 'node';

+--------+---------+-------------------------+---------------------------------------------+
| ID     | VERSION | TIMESTAMP               | TAGS                                        |
|--------+---------+-------------------------+---------------------------------------------|
| 197798 | 17      | 2021-09-06 17:01:27.000 | ""                                          |
| 197824 | 7       | 2021-08-04 23:17:18.000 | <tag k="highway" v="traffic_signals"></tag> |
|                   ... thousands of rows ...                                              |
| 197826 | 4       | 2021-08-04 16:43:28.000 | ""                                          |
+--------+---------+-------------------------+---------------------------------------------+

CREATE OR REPLACE TABLE mytable AS
  SELECT
    ST_SIMPLIFY($1:geo, 10) AS geo
  FROM @mystage;

CREATE OR REPLACE TABLE mytable (
  id VARCHAR,
  registration_date VARCHAR,
  first_name VARCHAR,
  last_name VARCHAR);

COPY INTO mytable (
  id,
  registration_date,
  first_name,
  last_name
) FROM (
    SELECT
      $1:ID,
      $1:CustomerDetails::OBJECT:RegistrationDate::VARCHAR,
      $1:CustomerDetails::OBJECT:FirstName::VARCHAR,
      $1:CustomerDetails::OBJECT:LastName::VARCHAR
    FROM @mystage
);

連続データロード（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サポート にお問い合わせください。

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

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

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

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

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

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

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