チュートリアル：Snowflake用のJSONの基本¶
概要¶
このチュートリアルでは、SnowflakeでJSONを使用する基本を学びます。
学習内容¶
このチュートリアルでは、以下の方法を学びます。
サンプル JSON データをパブリックS3バケットからSnowflakeテーブルの
variant型の列にアップロードします。テーブル内の JSON データの単純なクエリをテストします。
FLATTEN 関数を調べて、 JSON データをリレーショナル表現にフラット化し、別のテーブルに保存します。
フラット化されたバージョンのデータに行を挿入するときに一意性を確保する方法を調べます。
前提条件¶
このチュートリアルでは、次を前提としています。
Amazon AWS を使用するように構成されたSnowflakeアカウントと、データベース、テーブル、および仮想ウェアハウスオブジェクトを作成するために必要な権限を付与するロールを持つユーザーがある。
SnowSQL （CLI クライアント） がインストールされている。
Snowflakeを20分で紹介 チュートリアルでは、これらの要件を満たすための関連する段階的な手順が提供されています。
Snowflakeは、このチュートリアルで使用するパブリックS3バケットにサンプルデータファイルを提供します。ただし、開始する前に、このチュートリアル用のデータベース、テーブル、仮想ウェアハウス、および外部ステージを作成する必要があります。これらは、Snowflakeのほとんどのアクティビティに必要となる基本的なSnowflakeオブジェクトです。
サンプルデータファイルについて¶
このチュートリアルでは、パブリックS3バケットで提供される次のサンプルアプリケーションイベント JSON データを使用します。
{
"device_type": "server",
"events": [
{
"f": 83,
"rv": "15219.64,783.63,48674.48,84679.52,27499.78,2178.83,0.42,74900.19",
"t": 1437560931139,
"v": {
"ACHZ": 42869,
"ACV": 709489,
"DCA": 232,
"DCV": 62287,
"ENJR": 2599,
"ERRS": 205,
"MXEC": 487,
"TMPI": 9
},
"vd": 54,
"z": 1437644222811
},
{
"f": 1000083,
"rv": "8070.52,54470.71,85331.27,9.10,70825.85,65191.82,46564.53,29422.22",
"t": 1437036965027,
"v": {
"ACHZ": 6953,
"ACV": 346795,
"DCA": 250,
"DCV": 46066,
"ENJR": 9033,
"ERRS": 615,
"MXEC": 0,
"TMPI": 112
},
"vd": 626,
"z": 1437660796958
}
],
"version": 2.6
}
データは、アプリケーションがS3にアップロードするサンプルイベントを表します。イベントは、サーバー、携帯電話、ブラウザーなど、さまざまなデバイスやアプリケーションにより発行されます。一般的なデータ収集シナリオでは、スケーラブルなウェブエンドポイントがさまざまなソースから POSTed データを収集し、キューシステムに書き込みます。次に、インジェストサービス/ユーティリティはデータをS3バケットに書き込みます。そこからSnowflakeにデータをロードできます。
サンプルデータは、次の概念を示しています。
アプリケーションにより、イベントをバッチでグループ化することを選択できます。バッチは、バッチ内のすべてのイベントに共通のヘッダー情報を保持するコンテナーです。たとえば、前述の JSON は、これらのイベントを生成した
device_typeとversionで共通のヘッダー情報を持つ2つのイベントのバッチです。Amazon S3は、フォルダーの概念を使用してバケットを整理することをサポートしています。アプリケーションにより、この機能を利用してイベントデータを分割できます。通常、パーティション分割スキームは、イベントを生成したアプリケーションや場所などの詳細と、イベントがS3に書き込まれた日付を識別します。このようなパーティション分割スキームにより、単一の COPY コマンドで、パーティションされたデータの任意の部分をSnowflakeにコピーできます。たとえば、最初にテーブルにデータを入力するときに、時間、データ、月、または年ごとにイベントデータをコピーできます。
例:
s3://bucket_name/application_a/2016/07/01/11/s3://bucket_name/application_b/location_c/2016/07/01/14/application_a、application_b、location_cなどは、パス内にあるデータすべてのソースの詳細を識別することに注意してください。データは、書き込まれた日付ごとに整理できます。オプションの24時間ディレクトリは、各ディレクトリのデータ量を減らします。注釈
S3は、Snowflakeが使用する COPY ステートメントごとにディレクトリリストを送信するため、各ディレクトリ内のファイル数を減らすと、 COPY ステートメントのパフォーマンスが向上します。1時間ごとに10～15分単位のフォルダーを作成することも検討できます。
S3バケットで提供されるサンプルデータは、同様のパーティション分割スキームを使用します。COPY コマンドで、イベントデータをコピーする特定のフォルダーパスを指定します。
データベース、テーブル、ウェアハウス、および外部ステージの作成¶
次のステートメントを実行して、このチュートリアルに必要なデータベース、テーブル、仮想ウェアハウス、および外部ステージを作成します。チュートリアルの完了後に、これらのオブジェクトをドロップできます。
CREATE OR REPLACE DATABASE mydatabase; USE SCHEMA mydatabase.public; CREATE OR REPLACE TABLE raw_source ( SRC VARIANT); CREATE OR REPLACE WAREHOUSE mywarehouse WITH WAREHOUSE_SIZE='X-SMALL' AUTO_SUSPEND = 120 AUTO_RESUME = TRUE INITIALLY_SUSPENDED=TRUE; USE WAREHOUSE mywarehouse; CREATE OR REPLACE STAGE my_stage URL = 's3://snowflake-docs/tutorials/json';
次の点に注意してください。
CREATE DATABASEステートメントはデータベースを作成します。データベースには、「public」という名前のスキーマが自動的に含まれます。USE SCHEMAステートメントは、現在のユーザーセッションのアクティブなデータベースとスキーマを指定します。データベースの指定により、リクエストされるたびに名前を指定しなくても、このデータベースで作業を実行できるようになりました。CREATE TABLEステートメントは、 JSON データのターゲットテーブルを作成します。CREATE WAREHOUSEステートメントは、中断された初期状態のウェアハウスを作成します。このステートメントは AUTO_RESUME = true も設定します。これにより、コンピューティングリソースを必要とする SQL ステートメントを実行すると、ウェアハウスが自動的に開始されます。USE WAREHOUSEステートメントは、作成したウェアハウスを現在のユーザーセッションのアクティブなウェアハウスとして指定します。CREATE STAGEステートメントは、このチュートリアルのサンプルファイルを含むS3バケットをポイントする外部ステージを作成します。
データをターゲットテーブルにコピーする¶
COPY INTO <テーブル> を実行して、ステージングされたデータをターゲット RAW_SOURCE テーブルにロードします。
COPY INTO raw_source
FROM @my_stage/server/2.6/2016/07/15/15
FILE_FORMAT = (TYPE = JSON);
このコマンドは、すべての新しいデータを外部ステージの指定されたパスからターゲット RAW_SOURCE テーブルにコピーします。この例では、指定されたパスは、2016年7月15日の15時（3 PM）に書き込まれたデータをターゲットにしています。Snowflakeは各ファイルのS3 ETag 値をチェックして、ファイルが1回だけコピーされるようにすることに注意してください。
SELECT クエリを実行して、データが正常にコピーされていることを確認します。
SELECT * FROM raw_source;
クエリは次の結果を返します。
+-----------------------------------------------------------------------------------+
| SRC |
|-----------------------------------------------------------------------------------|
| { |
| "device_type": "server", |
| "events": [ |
| { |
| "f": 83, |
| "rv": "15219.64,783.63,48674.48,84679.52,27499.78,2178.83,0.42,74900.19", |
| "t": 1437560931139, |
| "v": { |
| "ACHZ": 42869, |
| "ACV": 709489, |
| "DCA": 232, |
| "DCV": 62287, |
| "ENJR": 2599, |
| "ERRS": 205, |
| "MXEC": 487, |
| "TMPI": 9 |
| }, |
| "vd": 54, |
| "z": 1437644222811 |
| }, |
| { |
| "f": 1000083, |
| "rv": "8070.52,54470.71,85331.27,9.10,70825.85,65191.82,46564.53,29422.22", |
| "t": 1437036965027, |
| "v": { |
| "ACHZ": 6953, |
| "ACV": 346795, |
| "DCA": 250, |
| "DCV": 46066, |
| "ENJR": 9033, |
| "ERRS": 615, |
| "MXEC": 0, |
| "TMPI": 112 |
| }, |
| "vd": 626, |
| "z": 1437660796958 |
| } |
| ], |
| "version": 2.6 |
| } |
+-----------------------------------------------------------------------------------+
このサンプル JSON データには、2つのイベントがあります。 device_type および version キー値は特定のデバイスからのイベントのデータソースとバージョンを識別します。
クエリデータ¶
このセクションでは、 SELECT ステートメントを調べて、 JSON データをクエリします。
device_typeを取得します。SELECT src:device_type FROM raw_source;
クエリは次の結果を返します。
+-----------------+ | SRC:DEVICE_TYPE | |-----------------| | "server" | +-----------------+
クエリでは、
src:device_type表記を使用して、取得する列名と JSON 要素名を指定します。この表記は、なじみのある SQLtable.column表記に似ています。Snowflakeでは、親列内にサブ列を指定できます。Snowflakeは、これを JSON データに埋め込まれたスキーマ定義から動的に派生させます。詳細については、 半構造化データのクエリ をご参照ください。注釈
列名では大文字と小文字が区別されませんが、 JSON 要素名では大文字と小文字が区別されます。
引用符なしで
device_type値を取得します。前述のクエリは、引用符で囲まれた JSON データ値を返します。データを特定のデータ型（この例では文字列）にキャストすることで、引用符を削除できます。
このクエリは、オプションでエイリアスを使用して列に名前を割り当てることもできます。
SELECT src:device_type::string AS device_type FROM raw_source;
クエリは次の結果を返します。
+-------------+ | DEVICE_TYPE | |-------------| | server | +-------------+
配列イベントオブジェクト内にネストされた繰り返しの
fキーを取得します。サンプル JSON データには
events配列が含まれています。示されているように、配列内の各イベントオブジェクトにはfフィールドがあります。{ "device_type": "server", "events": [ { "f": 83, .. } { "f": 1000083, .. } ]}
これらのネストされたキーを取得するには、 FLATTEN 関数を使用できます。この関数は、イベントを個別の行にフラット化します。
SELECT value:f::number FROM raw_source , LATERAL FLATTEN( INPUT => SRC:events );
クエリは次の結果を返します。
+-----------------+ | VALUE:F::NUMBER | |-----------------| | 83 | | 1000083 | +-----------------+
valueは、 FLATTEN 関数が返す列の1つです。次のステップでは、 FLATTEN 関数の使用について詳しく説明します。
データをフラット化する¶
FLATTEN は、 VARIANT、 OBJECT、または ARRAY 列の側面ビューを生成するテーブル関数です。このステップでは、この関数を使用して、フラット化のさまざまなレベルを調べます。
バリアント列の配列オブジェクトをフラット化する¶
FLATTEN 関数を使用して、 events 配列内のイベントオブジェクトを個別の行にフラット化できます。関数の出力には、これらの個々のイベントを格納する VALUE 列が含まれます。
その後、 LATERAL 修飾子を使用して、 FLATTEN 関数の出力をオブジェクト外の情報（この例では device_type と version）と結合できます。
各イベントのデータをクエリします。
SELECT src:device_type::string, src:version::String, VALUE FROM raw_source, LATERAL FLATTEN( INPUT => SRC:events );
クエリは次の結果を返します。
+-------------------------+---------------------+-------------------------------------------------------------------------------+ | SRC:DEVICE_TYPE::STRING | SRC:VERSION::STRING | VALUE | |-------------------------+---------------------+-------------------------------------------------------------------------------| | server | 2.6 | { | | | | "f": 83, | | | | "rv": "15219.64,783.63,48674.48,84679.52,27499.78,2178.83,0.42,74900.19", | | | | "t": 1437560931139, | | | | "v": { | | | | "ACHZ": 42869, | | | | "ACV": 709489, | | | | "DCA": 232, | | | | "DCV": 62287, | | | | "ENJR": 2599, | | | | "ERRS": 205, | | | | "MXEC": 487, | | | | "TMPI": 9 | | | | }, | | | | "vd": 54, | | | | "z": 1437644222811 | | | | } | | server | 2.6 | { | | | | "f": 1000083, | | | | "rv": "8070.52,54470.71,85331.27,9.10,70825.85,65191.82,46564.53,29422.22", | | | | "t": 1437036965027, | | | | "v": { | | | | "ACHZ": 6953, | | | | "ACV": 346795, | | | | "DCA": 250, | | | | "DCV": 46066, | | | | "ENJR": 9033, | | | | "ERRS": 615, | | | | "MXEC": 0, | | | | "TMPI": 112 | | | | }, | | | | "vd": 626, | | | | "z": 1437660796958 | | | | } | +-------------------------+---------------------+-------------------------------------------------------------------------------+
CREATE TABLE AS SELECT ステートメントを使用して、前述のクエリ結果をテーブルに保存します。
CREATE OR REPLACE TABLE flattened_source AS SELECT src:device_type::string AS device_type, src:version::string AS version, VALUE AS src FROM raw_source, LATERAL FLATTEN( INPUT => SRC:events );
結果のテーブルをクエリします。
SELECT * FROM flattened_source;
クエリは次の結果を返します。
+-------------+---------+-------------------------------------------------------------------------------+ | DEVICE_TYPE | VERSION | SRC | |-------------+---------+-------------------------------------------------------------------------------| | server | 2.6 | { | | | | "f": 83, | | | | "rv": "15219.64,783.63,48674.48,84679.52,27499.78,2178.83,0.42,74900.19", | | | | "t": 1437560931139, | | | | "v": { | | | | "ACHZ": 42869, | | | | "ACV": 709489, | | | | "DCA": 232, | | | | "DCV": 62287, | | | | "ENJR": 2599, | | | | "ERRS": 205, | | | | "MXEC": 487, | | | | "TMPI": 9 | | | | }, | | | | "vd": 54, | | | | "z": 1437644222811 | | | | } | | server | 2.6 | { | | | | "f": 1000083, | | | | "rv": "8070.52,54470.71,85331.27,9.10,70825.85,65191.82,46564.53,29422.22", | | | | "t": 1437036965027, | | | | "v": { | | | | "ACHZ": 6953, | | | | "ACV": 346795, | | | | "DCA": 250, | | | | "DCV": 46066, | | | | "ENJR": 9033, | | | | "ERRS": 615, | | | | "MXEC": 0, | | | | "TMPI": 112 | | | | }, | | | | "vd": 626, | | | | "z": 1437660796958 | | | | } | +-------------+---------+-------------------------------------------------------------------------------+
オブジェクトキーを個別の列にフラット化する¶
前述の例では、 events 配列内のイベントオブジェクトを個別の行にフラット化しました。結果の flattened_source テーブルでは、 VARIANT 型の src 列にイベント構造が保持されていました。
VARIANT 型の src 列にイベントオブジェクトを保持する利点の1つは、イベントの形式が変更されたときに、そのようなテーブルを再作成して再入力する必要がないことです。ただし、次のクエリに示すように、イベントオブジェクト内の個別のキーを異なる型に指定された列にコピーするオプションもあります。
次の CREATE TABLE AS SELECT ステートメントは、イベントオブジェクトのキーが異なる列に格納された events という名前の新しいテーブルを作成します。各値は、ダブルコロン（::）とそれに続く型を使用して、値に適したデータ型にキャストされます。キャストを省略すると、列は VARIANT データ型を想定し、任意の値を保持できます。
create or replace table events as
select
src:device_type::string as device_type
, src:version::string as version
, value:f::number as f
, value:rv::variant as rv
, value:t::number as t
, value:v.ACHZ::number as achz
, value:v.ACV::number as acv
, value:v.DCA::number as dca
, value:v.DCV::number as dcv
, value:v.ENJR::number as enjr
, value:v.ERRS::number as errs
, value:v.MXEC::number as mxec
, value:v.TMPI::number as tmpi
, value:vd::number as vd
, value:z::number as z
from
raw_source
, lateral flatten ( input => SRC:events );
このステートメントは、EVENTS.SRC：Vキーのネストされたデータをフラット化し、各値に個別の列を追加します。このステートメントは、キー/値のペアごとに行を出力します。次の出力は、新しい events テーブルの最初の2つのレコードを示しています。
SELECT * FROM events;
+-------------+---------+---------+----------------------------------------------------------------------+---------------+-------+--------+-----+-------+------+------+------+------+-----+---------------+
| DEVICE_TYPE | VERSION | F | RV | T | ACHZ | ACV | DCA | DCV | ENJR | ERRS | MXEC | TMPI | VD | Z |
|-------------+---------+---------+----------------------------------------------------------------------+---------------+-------+--------+-----+-------+------+------+------+------+-----+---------------|
| server | 2.6 | 83 | "15219.64,783.63,48674.48,84679.52,27499.78,2178.83,0.42,74900.19" | 1437560931139 | 42869 | 709489 | 232 | 62287 | 2599 | 205 | 487 | 9 | 54 | 1437644222811 |
| server | 2.6 | 1000083 | "8070.52,54470.71,85331.27,9.10,70825.85,65191.82,46564.53,29422.22" | 1437036965027 | 6953 | 346795 | 250 | 46066 | 9033 | 615 | 0 | 112 | 626 | 1437660796958 |
+-------------+---------+---------+----------------------------------------------------------------------+---------------+-------+--------+-----+-------+------+------+------+------+-----+---------------+
データを更新する¶
このチュートリアルでは、これまで次を完了しました。
サンプルの JSON イベントデータをS3バケットから
RAW_SOURCEテーブルにコピーし、簡単なクエリを調べました。また、 FLATTEN 関数を調べて、 JSON データをフラット化し、データのリレーショナル表現を取得しました。たとえば、イベントキーを抽出し、それらのキーを別の EVENTS テーブルにある個別の列に格納したとします。
最初に、チュートリアルでは、複数のソースがイベントを生成し、ウェブエンドポイントがそれをS3バケットに保存するアプリケーションシナリオについて説明します。新しいイベントがS3バケットに追加されると、スクリプトを使用して新しいデータを RAW_SOURCE テーブルに継続的にコピーできます。しかし、新しいイベントデータのみを EVENTS テーブルに挿入するにはどうすればよいでしょうか。
データの一貫性を維持するには、さまざまな方法があります。このセクションでは、2つのオプションについて説明します。
比較に主キー列を使用する¶
このセクションでは、主キーを EVENTS テーブルに追加します。主キーによって一意性が保証されます。
自然に一意であり、主キーの適切な候補となる値について、 JSON データを調べます。たとえば、
src:device_typeとvalue:rvの組み合わせが主キーになるとします。これらの2つの JSON キーは、EVENTSテーブルのDEVICE_TYPE列とRV列に対応しています。注釈
Snowflakeは主キー制約を強制しません。むしろ、制約はInformation Schema内の自然キーを識別するメタデータとして機能します。
主キー制約を
EVENTSテーブルに追加します。ALTER TABLE events ADD CONSTRAINT pk_DeviceType PRIMARY KEY (device_type, rv);
新しい JSON イベントレコードを
RAW_SOURCEテーブルに挿入します。insert into raw_source select PARSE_JSON ('{ "device_type": "cell_phone", "events": [ { "f": 79, "rv": "786954.67,492.68,3577.48,40.11,343.00,345.8,0.22,8765.22", "t": 5769784730576, "v": { "ACHZ": 75846, "ACV": 098355, "DCA": 789, "DCV": 62287, "ENJR": 2234, "ERRS": 578, "MXEC": 999, "TMPI": 9 }, "vd": 54, "z": 1437644222811 } ], "version": 3.2 }');
主キー値の比較に基づいて、
RAW_SOURCEテーブルに追加した新しい記録をEVENTSテーブルに挿入します。insert into events select src:device_type::string , src:version::string , value:f::number , value:rv::variant , value:t::number , value:v.ACHZ::number , value:v.ACV::number , value:v.DCA::number , value:v.DCV::number , value:v.ENJR::number , value:v.ERRS::number , value:v.MXEC::number , value:v.TMPI::number , value:vd::number , value:z::number from raw_source , lateral flatten( input => src:events ) where not exists (select 'x' from events where events.device_type = src:device_type and events.rv = value:rv);
EVENTSテーブルをクエリすると、追加された行が表示されます。select * from EVENTS;
クエリは次の結果を返します。
+-------------+---------+---------+----------------------------------------------------------------------+---------------+-------+--------+-----+-------+------+------+------+------+-----+---------------+ | DEVICE_TYPE | VERSION | F | RV | T | ACHZ | ACV | DCA | DCV | ENJR | ERRS | MXEC | TMPI | VD | Z | |-------------+---------+---------+----------------------------------------------------------------------+---------------+-------+--------+-----+-------+------+------+------+------+-----+---------------| | server | 2.6 | 83 | "15219.64,783.63,48674.48,84679.52,27499.78,2178.83,0.42,74900.19" | 1437560931139 | 42869 | 709489 | 232 | 62287 | 2599 | 205 | 487 | 9 | 54 | 1437644222811 | | server | 2.6 | 1000083 | "8070.52,54470.71,85331.27,9.10,70825.85,65191.82,46564.53,29422.22" | 1437036965027 | 6953 | 346795 | 250 | 46066 | 9033 | 615 | 0 | 112 | 626 | 1437660796958 | | cell_phone | 3.2 | 79 | "786954.67,492.68,3577.48,40.11,343.00,345.8,0.22,8765.22" | 5769784730576 | 75846 | 98355 | 789 | 62287 | 2234 | 578 | 999 | 9 | 54 | 1437644222811 | +-------------+---------+---------+----------------------------------------------------------------------+---------------+-------+--------+-----+-------+------+------+------+------+-----+---------------+
比較にすべての列を使用する¶
JSON データに主キーの候補となるフィールドがない場合は、 RAW_SOURCE テーブル内にあるすべての繰り返しの JSON キーを EVENTS テーブル内の対応する列の値と比較できます。
既存の EVENTS テーブルを変更する必要はありません。
新しい JSON イベントレコードを
RAW_SOURCEテーブルに挿入します。insert into raw_source select parse_json ('{ "device_type": "web_browser", "events": [ { "f": 79, "rv": "122375.99,744.89,386.99,12.45,78.08,43.7,9.22,8765.43", "t": 5769784730576, "v": { "ACHZ": 768436, "ACV": 9475, "DCA": 94835, "DCV": 88845, "ENJR": 8754, "ERRS": 567, "MXEC": 823, "TMPI": 0 }, "vd": 55, "z": 8745598047355 } ], "version": 8.7 }');
すべての繰り返しキー値の比較に基づいて、
RAW_SOURCEテーブルの新しいレコードをEVENTSテーブルに挿入します。insert into events select src:device_type::string , src:version::string , value:f::number , value:rv::variant , value:t::number , value:v.ACHZ::number , value:v.ACV::number , value:v.DCA::number , value:v.DCV::number , value:v.ENJR::number , value:v.ERRS::number , value:v.MXEC::number , value:v.TMPI::number , value:vd::number , value:z::number from raw_source , lateral flatten( input => src:events ) where not exists (select 'x' from events where events.device_type = src:device_type and events.version = src:version and events.f = value:f and events.rv = value:rv and events.t = value:t and events.achz = value:v.ACHZ and events.acv = value:v.ACV and events.dca = value:v.DCA and events.dcv = value:v.DCV and events.enjr = value:v.ENJR and events.errs = value:v.ERRS and events.mxec = value:v.MXEC and events.tmpi = value:v.TMPI and events.vd = value:vd and events.z = value:z);
EVENTSテーブルをクエリすると、追加された行が表示されます。select * from EVENTS;
クエリは次の結果を返します。
+-------------+---------+---------+----------------------------------------------------------------------+---------------+--------+--------+-------+-------+------+------+------+------+-----+---------------+ | DEVICE_TYPE | VERSION | F | RV | T | ACHZ | ACV | DCA | DCV | ENJR | ERRS | MXEC | TMPI | VD | Z | |-------------+---------+---------+----------------------------------------------------------------------+---------------+--------+--------+-------+-------+------+------+------+------+-----+---------------| | server | 2.6 | 83 | "15219.64,783.63,48674.48,84679.52,27499.78,2178.83,0.42,74900.19" | 1437560931139 | 42869 | 709489 | 232 | 62287 | 2599 | 205 | 487 | 9 | 54 | 1437644222811 | | server | 2.6 | 1000083 | "8070.52,54470.71,85331.27,9.10,70825.85,65191.82,46564.53,29422.22" | 1437036965027 | 6953 | 346795 | 250 | 46066 | 9033 | 615 | 0 | 112 | 626 | 1437660796958 | | cell_phone | 3.2 | 79 | "786954.67,492.68,3577.48,40.11,343.00,345.8,0.22,8765.22" | 5769784730576 | 75846 | 98355 | 789 | 62287 | 2234 | 578 | 999 | 9 | 54 | 1437644222811 | | web_browser | 8.7 | 79 | "122375.99,744.89,386.99,12.45,78.08,43.7,9.22,8765.43" | 5769784730576 | 768436 | 9475 | 94835 | 88845 | 8754 | 567 | 823 | 0 | 55 | 8745598047355 | +-------------+---------+---------+----------------------------------------------------------------------+---------------+--------+--------+-------+-------+------+------+------+------+-----+---------------+
おめでとうございます¶
おめでとうございます。チュートリアルを無事完了しました。
チュートリアルのキーポイント¶
論理的で詳細なパスを使用してS3バケットのイベントデータをパーティション分割すると、パーティション分割されたデータのサブセットを単一のコマンドでSnowflakeにコピーできます。
Snowflakeの
column:key表記は、なじみのある SQLtable.column表記に似ており、 JSON データに埋め込まれたスキーマ定義に基づいて動的に得られた列内の列（つまり、サブ列）を効率的にクエリできます。FLATTEN 関数を使用すると、 JSON データを個別の列に解析できます。
ステージングされたデータファイルとの比較に基づいてテーブルデータを更新するために、いくつかのオプションを使用できます。
チュートリアルのクリーンアップ（オプション）¶
次の DROP <オブジェクト> コマンドを実行して、システムをチュートリアルを開始する前の状態に戻します。
DROP DATABASE IF EXISTS mydatabase; DROP WAREHOUSE IF EXISTS mywarehouse;
データベースをドロップすると、テーブルなどのすべての子データベースオブジェクトが自動的に削除されます。