ServiceNow®データのデータインジェスチョンの設定¶
Snowflake Connector for ServiceNow® V2は、 Snowflakeコネクタ規約 に従うものとします。
このトピックでは、 Snowflake Connector for ServiceNow®V2 のデータインジェストを設定する方法について説明します。
注釈
Snowflake Connector for ServiceNow®V2 は ServiceNow®テーブルからSnowflakeにデータをインジェストします。データインジェスチョンは、ServiceNow® テーブル API の v2
に依存します。
このトピックの内容:
ServiceNow®テーブルをインジェストするための戦略¶
注釈
コネクタは、
sys_id
列が存在するテーブルのみをインジェストできます。ServiceNow ビュー はサポートされていません。これらのビューをインジェストする代わりに、基になるビューのすべてのテーブルを同期し、同期したテーブルをSnowflakeに結合する必要があります。
コネクタは、テーブルスキーマに応じて、さまざまなインジェスチョン戦略を使用します。コネクタは、次の3つのインジェスチョンモードを使用します。
テーブルの同期が有効になると、テーブルごとにデータの 初期ロード が実行されます。
このモードでは、
sys_id
列の IDs で識別される記録を反復処理することにより、テーブルがインジェストされます。すべての記録がインジェストされると、初期ロードフェーズが完了します。特定のテーブルでは、 data range start time 値を設定することもでき、どの記録をインジェストするかを制限することができます。増分更新 は、
sys_updated_on
またはsys_created_on
列を持つテーブルに対してのみ実行されます。増分更新は、初期ロードが完了した後に開始され、構成可能な定期的なスケジュールで実行されます。このモードでは、コネクタは、最後の同期以降に追加、更新、または削除された記録のみをインジェストします。
注釈
削除に関する情報は、コネクタの構成時に提供されるジャーナルテーブルから取得されます。
sys_updated_on
またはsys_created_on
列を持たないテーブルの場合、コネクタは 切り捨ててロード モードを使用します。このモードでは、テーブルは常に初期ロードアプローチを使用してインジェストされ、新しくインジェストされたデータが古いデータに置き換わります。コネクタは、
INSERT OVERWRITE
コマンドを実行してデータを置き換えます。
注釈
「増分更新」モードでは、
sys_updated_on
列が存在する場合、コネクタはその列を使用します。列が存在しない場合、コネクタは代わりに
sys_created_on
列を使用します。回転テーブル の場合、コネクタは常に
sys_created_on
列を使用します。sys_created_on
以外の列を使用してテーブルを回転すると、そのテーブルのインジェスチョンによってパフォーマンスの問題が発生する可能性があります。
注釈
ServiceNow で記録が変更されたときに
sys_updated_on
またはsys_created_on
フィールドが更新されていない場合、それらの変更はSnowflakeに反映されず、データの不整合が発生します。Snowflakeでは、 システムフィールドの更新を無効にする ことは避けることをお勧めします。記録の削除が 監査されていない 場合、削除された記録に関する情報はSnowflakeに反映されず、データの不整合が発生します。
注釈
Snowflakeと ServiceNow® REST APIs の制限により、1行のデータが16 MB を超えると、コネクタはテーブルをインジェストできません。その場合、コネクタはテーブルスケジュールで定義された頻度でデータのインジェスチョンを試みます。行が制限を超えると、コネクタはエラーメッセージを生成し、他のテーブルのインジェスチョンを続行します。この制限を克服するために、 列フィルタリング を構成して、大きな列をインジェスチョンから除外できます。
アーカイブ済みの記録¶
コネクタは、インジェストされたテーブルに対してSnowflake側で ServiceNow でアーカイブされた記録 を積極的に反映しません。ある日付より古い非アクティブな記録をアーカイブすると想定すると、以下のようになります。
コネクタがインジェストする前(たとえば、テーブルの 初期ロード の前)にアーカイブされた記録は、Snowflake側のテーブルにはまったく存在しません。
コネクタによって既にインジェストされた後にアーカイブされた記録は、アーカイブアクションが発生したことを示すことなく、Snowflake側に残ります。
既に 増分更新 モードで動作しているテーブルに対して復元されたアーカイブ記録は、その後にその記録も変更されない限り(その
sys_updated_on
値が現在の時刻に更新されない限り)、Snowflake側でインジェストされることはありません。テーブルの 初期ロード 中に復元されたアーカイブ記録は、
sys_id
列の ID によっては、Snowflake側でインジェストされる場合があります。
アクティブなアーカイブルールがあるテーブルを最新の状態にしたい場合、 テーブル全体をリロード することができます。しかし、リロード終了後にアーカイブまたは復元された記録は、上記と同じ原則に従います。
ServiceNow アーカイブテーブル ar_[table_name]
の同期を有効にすることができます。ただし、そのようなテーブルの 初期ロード に続く最初の 増分更新 は、アーカイブテーブルの 初期ロード が開始された日以降に作成/更新された記録のために検索されます。 sys_updated_on
または sys_created_on
のどちらも記録のアーカイブ時には変更されないため、アーカイブテーブルの 初期ロード 以降、ある時点までにアーカイブされた記録は、Snowflake側で欠落しています。たとえば、1年以上前の記録をアーカイブする場合、アーカイブテーブルの 初期ロード の後、1年間アーカイブされた記録は、Snowflake側のアーカイブテーブルにインジェストされません。アーカイブテーブルの 初期ロード の後、 destroyルール によって復元たは削除されたアーカイブ記録は、Snowflake側でそのテーブルから削除されることはありません。
ServiceNow®テーブルの並列インジェスチョン¶
コネクタはいくつかのテーブルを並行してインジェストしますが、個別のテーブルのインジェスチョンは同期プロセスです。これは、大型のテーブルをインジェストすると、コネクタが他のテーブルを更新するのをブロックする可能性があることを意味します。この問題は、他のフェーズよりも初期ロードフェーズで発生する可能性が高くなります。デフォルトでは、コネクタは10個のワーカースレッドを使用します。これは、 ServiceNow®インスタンスに過負荷をかけないようにするための最適な値と考えられています。インスタンスがさらなる同時実行をサポートできることが確実な場合は、 CONFIGURE_CONCURRENCY プロシージャ を呼び出すことで、この値を最大30まで増やすことができます。
Snowsight を使用したデータインジェスチョンの設定¶
Snowsight を使用してデータインジェストを設定するには、次を実行します。
ACCOUNTADMIN ロールを持つユーザーとして Snowsight にサインインします。
ナビゲーションメニューで Data Products » Apps を選択します。
Snowflake Connector for ServiceNow®V2アプリを検索し、コネクタのタイルを選択します
Snowflake Connector for ServiceNow®V2 のページで、 Data Sync タブを選択します。
これにより、すべての ServiceNow®テーブルのリストが表示されます。
注釈
コネクタは、
sys_id
列が存在するテーブルのみをインジェストできます。インジェストするテーブルを選択します。
インジェストするテーブルを検索します。
選択するテーブルの左から Status 列のチェックボックスを選択します。
Sync Schedule で、Snowflakeと ServiceNow®間でテーブルを同期する頻度を選択します。
Snowflakeにインジェストするテーブルごとに、これらのステップを繰り返します。
Status 列の見出しを選択して、現在選択しているテーブルを表示します。
Start sync を選択して、Snowflakeアカウントへのデータのインジェスチョンを開始します。
コネクタのステータスが Syncing data に変わります。少なくとも1つのテーブルが正常にインジェストされると、コネクタのステータスが Last Sync: just now に変わります。
Snowflakeでテーブルのコンテンツを表示する方法については、 Snowflake Connector for ServiceNow®V2 のモニター をご参照ください。
Snowsightを使用したデータインジェスチョンの変更¶
インジェストされる ServiceNow®テーブルまたはテーブルの同期スケジュールを変更するには、次を実行します。
ACCOUNTADMIN ロールを持つユーザーとして Snowsight にサインインします。
ナビゲーションメニューで Data Products » Apps を選択します。
Snowflake Connector for ServiceNow®V2アプリを検索し、コネクタのタイルを選択します
Snowflake Connector for ServiceNow®V2 のページで、 Data Sync を選択します。
編集モードに入るには、 Edit tables ボタンを選択します。
インジェストするテーブルを変更します。
インジェストするテーブルを検索します。
選択する、または選択解除するテーブルの左から Status 列のチェックボックスを選択します。
Sync Schedule で、Snowflakeと ServiceNow®間でテーブルを同期する頻度を選択します。
Update data sync を選択します。
SQL ステートメントを使用したデータインジェスチョンの設定¶
SQL ステートメントを使用してデータインジェスチョンを設定するには、次を実行します。
注釈
これらの設定を構成するには、 コネクタのインスタンスとして機能するデータベース の PUBLIC スキーマで定義されているストアドプロシージャを使用します。
これらのストアドプロシージャを呼び出す前に、そのデータベースをセッションに使用するデータベースとして選択します。
たとえば、そのデータベースの名前が my_connector_servicenow
の場合は、次のコマンドを実行します。
USE DATABASE my_connector_servicenow;
テテーブル同期の有効化または無効化¶
このセクションでは、 ServiceNow®でテーブルの同期を有効または無効にする方法について説明します。同期の有効化は、デフォルト構成とカスタム構成の両方で実行できます。
デフォルト構成を使用して複数のテーブルを有効にする¶
ServiceNow®内にある1つ以上のテーブルのデータ同期を有効にするには、次の引数を使用して ENABLE_TABLES
ストアドプロシージャを呼び出します。
CALL ENABLE_TABLES(<tables_to_enable>);
条件:
tables_to_enable
ServiceNow®テーブル名の配列を指定します。
ServiceNow® UI に表示されるラベルではなく、テーブル名を使用します。テーブル名は、 ServiceNow 内にあるデータディクショナリテーブル で確認できます。ServiceNow® UIで、 System Definition » Tables に進みます。テーブルの名前を表示する Name 列。
たとえば、 table1
、 table2
、および table3
という名前のテーブルの同期を有効にするには、次のコマンドを実行します。
CALL ENABLE_TABLES(['table1', 'table2', 'table3']);
複数のテーブルを無効にする¶
ServiceNow®内にある特定のテーブルのテーブルデータ同期を無効にするには、次の引数を使用して DISABLE_TABLES
ストアドプロシージャを呼び出します。
CALL DISABLE_TABLES(<tables_to_disable>);
条件:
tables_to_disable
ServiceNow®テーブル名の配列を指定します。
ServiceNow® UI に表示されるラベルではなく、テーブル名を使用します。テーブル名は、 ServiceNow 内にあるデータディクショナリテーブル で確認できます。ServiceNow® UIで、 System Definition » Tables に進みます。テーブルの名前を表示する Name 列。
たとえば、 table1
と table2
という名前のテーブルの同期を無効にするには、次のコマンドを実行します。
CALL DISABLE_TABLES(['table1', 'table2']);
テーブルを無効にすると、可能な限り早く同期が正常に停止されます。テーブルの同期が再度有効になると、一時停止された場所からインジェスチョンが再開されます。
注釈
すべてのテーブルの同期を無効にしても、 Snowflake Connector for ServiceNow®V2 のコストの発生が停止するわけではありません。通知に関連するタスクなどのバックグラウンドタスクは引き続き実行できます。
ENABLE_TABLES
と DISABLE_TABLES
プロシージャは、指定されたテーブル名を CONFIGURED_TABLES
ビューに追加します。
注釈
コネクタは、 ServiceNow®での ロールバックまたは削除の回復 をサポートしていません。
ロールバックおよび削除の復元機能を使用すると、データの不整合が発生する場合があります。ServiceNow®で回復された記録は、Snowflakeで削除済みとしてマークされる場合があります。これを解決するには、テーブルを 再ロード します。
カスタム構成を使用して単一のテーブルを有効にする¶
ServiceNow®内にある特定のテーブルのカスタム構成によるデータの同期を有効にするには、次の引数を使用して ENABLE_TABLE
ストアドプロシージャを呼び出します。
CALL ENABLE_TABLE('<table_to_enable>', <table_config>);
条件:
table_to_enable
ServiceNow®テーブル名を指定します。
table_config
必要に応じて、テーブルインジェスチョン構成を持つオブジェクトを指定します。指定されていない場合、テーブルのインジェスチョンではデフォルトの構成が使用されます。
現在サポートされている構成は次のとおりです。
注釈
すべてのカスタム構成を1つのオブジェクトに組み合わせて、1つのテーブルインジェスチョンに同時に使用できます。たとえば、次の構成でテーブル
sys_audit
のインジェスチョンを有効にします。テーブルは毎週土曜日の10:00 AM UTC に同期され、
newvalue
とreason
の列のみをインジェストする必要があり、privacy
という文字列で始まるnewvalue
列を持つ行のみをインジェストする必要があり、
次のコマンドを実行します。
CALL ENABLE_TABLE('sys_audit', { 'schedule': { 'type': 'custom', 'value': { 'hour': 10, 'day_of_week': '6' } }, 'include_columns': ['newvalue', 'reason'], 'row_filter': 'newvalue STARTSWITH "privacy"' });
列フィルタリングを使用して単一のテーブルを有効にする¶
Snowflakeの ServiceNow®テーブルのすべての列が不要な場合、コネクタはそれらを無視できます。たとえば、1行が最大行サイズ16 MB を超える場合に、列をスキップします。
指定した列を含むテーブルのインジェスチョンを有効にするには、次のコマンドを実行します。
CALL ENABLE_TABLE('<table_to_enable>', <table_config>);
条件:
table_to_enable
ServiceNow®テーブル名を指定します。
table_config
列名のリストを持つ
include_columns
またはexclude_columns
のプロパティを含むオブジェクト。sys_id
、sys_created_on
、およびsys_updated_on
が存在する場合、それらは常に含まれます。included_columns
配列に追加する必要はありません。また、コネクタによりインジェスチョンプロセスで使用されるため、excluded_columns
を使用して除外することはできません。
注釈
ServiceNow®の列は小文字で記述され、コネクタが使用する API は大文字と小文字を区別するため、指定された列に提供する値も小文字である必要があります。
注釈
include_columns
と exclude_columns
の両方を提供することはできません。 include_columns
をリスト表示したい場合は、 exclude_columns
プロパティをスキップする必要があります。その逆も同様です。両方の配列が空でなく、競合する列がない場合、 include_columns
が exclude_columns
より優先されます。
include_columns
と exclude_columns
の両方が空の配列の場合、利用可能なすべての列がインジェストされます。
たとえば、列 sys_id
、 sys_updated_on
、 col_1
、 col_2
が含まれる u_table
という名前の ServiceNow®テーブルに対して次を実行します。
CALL ENABLE_TABLE('u_table', { 'include_columns': ['sys_id', 'sys_updated_on'] });
これにより、指定したテーブルの sys_id
と sys_updated_on
列のみがインジェストされますが、
CALL ENABLE_TABLE('u_table', { 'exclude_columns': ['col_1'] });
を呼び出すと、 sys_id
、 sys_updated_on
、そして col_2
もまたインジェストされます。
コネクタは提供された列を検証し、列のいずれかが ServiceNow®で利用できない場合は、有効化のリクエストを拒否します。ServiceNow® API は、インクルードモードのみをサポートします。そのため、コネクタは提供された列配列をインクルード列リストに変換して、リクエストごとに ServiceNow®に送信します。列が含まれる URL は、 ServiceNow®で処理するには長すぎる可能性があります。コネクタは、 ENABLE_TABLE
が呼び出されたときに、この制限を検証します。
各テーブルの列の構成は、 CONFIGURED_TABLES
ビューの INCLUDED_COLUMNS
列で確認できます。インジェストされる列のリストを変更するには、まず特定のテーブルを無効化する必要があります。テーブルに対してテーブルフィルタリングが構成されている場合は、 ENABLE_TABLE
プロシージャを使用してテーブルのみを有効にすることができます。テーブルのリストを引数として受け入れる ENABLE_TABLES
は使用できません。
フラット化されたビューには、テーブルが有効化されたときに指定された列のみが含まれます。これらは、含まれる列のリストが変更されるたびに更新されます。列フィルタリングが構成されていない場合、ビューには使用可能なすべての列が含まれます。
注釈
構成の変更は、以前にインジェストされたデータには影響しません。列のフィルタリングは、新しくインジェストされた記録にのみ適用されます。以前にインジェストされたデータにフィルターを適用するには、テーブルを 再ロード する必要があります。
行フィルタリングを使用して単一のテーブルを有効にする¶
フィルター条件を指定することで、 ServiceNow®テーブルから選択した行のデータインジェスチョンを除外できます。たとえば、Snowflakeに不要な機密データを含む行を除外したり、コストを削減するために不要なデータを含む行を除外したりします。
指定した行フィルターを含むテーブルのインジェスチョンを有効にするには、次のコマンドを実行します。
CALL ENABLE_TABLE('<table_to_enable>', <table_config>);
条件:
table_to_enable
ServiceNow®テーブル名を指定します。
table_config
有効な文字列であるフィルター式を持つ
row_filter
プロパティを含むオブジェクト。現在サポートされているフィルター演算子は次のとおりです。
演算子
説明
例
AND
両方が満たされる必要がある条件を結合する、論理演算子。
active = "true" AND impact = "2"
OR
少なくとも1つが満たされる必要がある条件を結合する、論理演算子。
重要
AND
演算子よりも優先されます。次の 例 をご参照ください。tablename = "incident" OR tablename = "problem"
=
値が等しいかどうかをチェックします。
priority = "1"
!=
値が等しくないかどうかをチェックします。
state != "7"
LIKE
値に指定された文字列が含まれているかどうかをチェックします。*
newvalue LIKE "privacy"
STARTSWITH
値が指定された文字列で始まるかどうかをチェックします。*
description STARTSWITH "important"
ENDSWITH
値が指定された文字列で終わるかどうかをチェックします。*
description ENDSWITH "important"
IN
値が値のリストのいずれかと等しいかどうかをチェックします。**
tablename IN ("incident", "task", "cmdb_ci")
(*) - フィールドは
string
データ型である必要があります。(**) - 選択フィールドには文字列を含める必要があります。フィルター表現のルールと制限:
任意の2つのフィルター式は、
AND
またはOR
演算子で結合する必要があります。演算子はスペースで区切られ、大文字である必要があります。
値の式は二重引用符で囲む必要があります。
式は大文字と小文字を区別します。
式は、
sys_id
、sys_updated_on
、またはsys_created_on
列では動作できません。
注釈
構成の変更は、以前にインジェストされたデータには影響しません。行のフィルタリングは、新しくインジェストされた記録にのみ適用されます。すでにインジェストされたデータにフィルターを適用するには、テーブルを 再ロード する必要があります。
例¶
テーブル
sys_audit
のインジェスチョンを有効にし、INCIDENT
テーブルのプライバシーインシデントに関連する行のみを同期するには、次を実行します。
CALL ENABLE_TABLE('sys_audit', {
'row_filter': 'tablename = "incident" AND fieldname = "cause" AND newvalue LIKE "privacy"'
});
テーブルの
incident
インジェスチョンを有効にし、次の条件で行のみを同期します。active
フィールドはtrue
に等しく、sys_created_by
フィールドはsupport
で始まるか、admin
で終わり、category
フィールドはNetwork
、Cloud Management
のいずれかである。
次を実行します。
CALL ENABLE_TABLE('incident', {
'row_filter': 'active = "true" AND sys_created_by STARTSWITH "support" OR sys_created_by ENDSWITH "admin" AND category IN ("Network", "Cloud Management")'
});
テーブル
incident
のインジェスチョンを有効にし、指定されたインシデント状態の行と指定された列のみをインジェストするには、次を実行します。
CALL ENABLE_TABLE('incident', {
'row_filter': 'incident_state IN ("1", "2", "3")', -- "New", "In Progress", "On Hold"
'include_columns': ['incident_state', 'description']
});
同期スケジュールの指定¶
Snowflake Connector for ServiceNow®V2 は、指定されたスケジュールですべての ServiceNow®テーブルからSnowflakeにデータを同期します。デフォルトでは、すべてのテーブルが毎時(1時間ごとに)同期されます。
すべてのテーブルのデフォルトの同期スケジュールを変更するには、次の引数で CONFIGURE_DATA_INGESTION_SCHEDULE
ストアドプロシージャを呼び出します。
CALL CONFIGURE_DATA_INGESTION_SCHEDULE(<schedule>);
条件:
schedule
同期の頻度を指定します。次の JSON 値のいずれかを指定できます。
{ 'type': 'interval', 'value': '<interval_value>' }
。ここで、interval_value
は以下の文字列値のいずれかです。
'30m'
'1h'
'3h'
'6h'
'12h'
'1d'
{ 'type': 'custom', 'value': { 'hour': <hour>, 'day_of_week': '<day_of_week>' } }
。ここで、hour
は UTC のタイムゾーンでインジェスチョンを開始する時刻を指定し、day_of_week
はインジェスチョンを実行する曜日を指定します。次のような特殊式を曜日として使用することができます。
'*'
は、インジェスチョンを毎日実行する。
'1-3'
は、月曜日から水曜日までインジェスチョンを実行する。
'0,5,6'
は、金曜日、土曜日、日曜日にインジェスチョンを実行する。
day_of_week
構成の式で可能な値は次のとおりです。
'0'
- 日曜日
'1'
- 月曜日
'2'
- 火曜日
'3'
- 水曜日
'4'
- 木曜日
'5'
- 金曜日
'6'
- 土曜日月の最終金曜日を示す
'5L'
や、金曜日から日曜日までの範囲を示す'FRI-SUN'
のような、数字以外の値はサポートされていません。
有効化中に特定のテーブルのインジェスチョンスケジュールを設定することが可能です。単一のテーブルを有効にして、そのインジェスチョンスケジュールを設定するには、以下の引数を指定して ENABLE_TABLE
ストアドプロシージャを呼び出します。
CALL ENABLE_TABLE('<table_name>', <table_config>);
条件:
table_name
有効にする ServiceNow®テーブル名を指定します。
table_config
テーブル同期の構成を指定する
schedule
プロパティを含むオブジェクト。詳細はCONFIGURE_DATA_INGESTION_SCHEDULE
ストアドプロシージャのschedule
をご参照ください。
たとえば、テーブル table_1
のインジェスチョンを有効にし、3時間ごとにデータを同期するには、以下のストアドプロシージャを呼び出します。
CALL ENABLE_TABLE('table_1', { 'schedule': { 'type': 'interval', 'value': '3h' } });
コネクタでは、同期が有効になっているテーブルごとに異なるスケジュールを指定することもできます。選択した一連のテーブルの同期スケジュールを変更するには、次の引数で CONFIGURE_TABLES_SCHEDULE
ストアドプロシージャを呼び出します。
CALL CONFIGURE_TABLES_SCHEDULE(<table_names>, <schedule>);
条件:
table_names
同期スケジュールを構成するテーブル名の配列を指定します。
schedule
同期の頻度を指定します。詳細は
CONFIGURE_DATA_INGESTION_SCHEDULE
ストアドプロシージャのschedule
をご参照ください。
たとえば、毎週土曜日と日曜日の11:00 PM UTC にテーブル table_1
と table_2
をインジェストするには、以下のストアドプロシージャを呼び出します。
CALL CONFIGURE_TABLES_SCHEDULE(['table_1', 'table_2'], { 'type': 'custom', 'value': { 'hour': 23, 'day_of_week': '0,6' } });
デフォルトでは、コネクタはスケジュールされた開始時刻から3時間の時間ウィンドウでインジェスチョンの開始を試みます。コネクタが他のテーブルをインジェストしている場合など、その時間枠内にインジェスチョンを開始できない場合、現在スケジュールされた実行は実行されません。コネクタは次のスケジュールされた時間枠でインジェスチョンの実行を試みます。 CONFIGURE_CUSTOM_SCHEDULE_START_INGESTION_WINDOW
ストアドプロシージャを呼び出すと、時間枠の期間を変更できます。
CALL CONFIGURE_CUSTOM_SCHEDULE_START_INGESTION_WINDOW(<window_length>);
ここで、 window_length
は ISO 8601期間形式のウィンドウの長さです。継続時間は1時間単位に切り上げられ、少なくとも1時間継続する必要があります。たとえば、値 'PT12H'
は12時間継続するウィンドウを指定し、 'P2D'
は2日間継続するウィンドウを指定します。
カスタムスケジュールを持つテーブルのみを有効にすると、この構成は構成されたテーブルのフラット化されたビューの作成とリフレッシュにかかる時間にのみ影響します。フラット化されたビューは、以下の条件が満たされた後、最初のインジェスチョンサイクルで作成されます。
メタデータテーブルのインジェスチョンが完了している
構成されたテーブルのインジェスチョンが開始されている。
メールアラートが有効になっている場合、カスタムスケジュールを使用するときにアラート頻度を Once per day に変更することをSnowflakeはお勧めします。
data range start timeの指定¶
デフォルトでは、 Snowflake Connector for ServiceNow®V2 は対応する ServiceNow テーブルのすべての記録を同期します。 sys_updated_on
または sys_created_on
列(以降、 time列 と呼ぶ)が存在するテーブルでは、 data range start time (つまり記録の対応する time列 の値の下限)を設定することで、同期データの範囲を制限することができます。
このような構成では、対応する time列 の値が data range start timestamp より古い記録はインジェスト されません。このプロシージャで使用される対応する time列 は、増分更新と 同じ方法 で決定されます。
data range start timestamp 値を変更するには、 CONFIGURE_TABLES_RANGE_START
ストアドプロシージャを次の引数で呼び出します。
CALL CONFIGURE_TABLES_RANGE_START(<table_names>, <range_start>);
条件:
table_names
data range start time を構成するテーブル名の配列を指定します。
range_start
data range start time を TIMESTAMP_TZ フォーマットで指定するタイムスタンプ、または NULL で現在値の設定を解除します。
注釈
sys_updated_on
列と sys_created_on
列のいずれも存在しないテーブルには、data range start timeを設定できません。
テーブルのインジェスチョンがまだ開始されていない場合、 data range start time の値は、最初のインジェスチョンで考慮されます。
テーブルのインジェスチョンが既に開始されている場合(リロード中など)、 data range start time 値は無視され、対応する time列 値が古すぎる記録をフィルターするために(別の) テーブルのリロード が必要になります。
したがって、テーブルの最初のインジェスチョンを開始する前(つまり、テーブルを有効にする前)に、 data range start time を設定することをお勧めします。
例えば、テーブル table1
と table2
に必要な time列 がある場合、これら2つのテーブルの data range start time を2022-11-23 07:00:00 UTC に設定するには、次のコマンドを実行します。
CALL CONFIGURE_TABLES_RANGE_START(['table1', 'table2'], TO_TIMESTAMP_TZ('2022-11-23 07:00:00 +00:00'));
コマンド実行後:
例えば、テーブル
table1
の場合、インジェスチョンがまだ開始されていない場合、2022-11-23 07:00:00 より前に対応する time 列 の値を持つすべての記録はインジェスト されません。例えば、テーブル
table2
に対して、そのインジェスチョンが既に開始されている場合、このテーブルをリロードするまで、すべてのデータ同期で data range time start 値は無視されます。リロード中、2022-11-23 07:00:00より前に対応する time列 値を持つ記録はすべてインジェストされません。
data range start time の設定を解除しないことも可能です。例えば、テーブル table1
の設定を解除するには、次のコマンドを実行します。
CALL CONFIGURE_TABLES_RANGE_START(['table1'], NULL);
この場合も、テーブル table1
のインジェスチョンが既に開始されている場合、 ServiceNow®からすべての記録をインジェストするには、このテーブルのリロードが必要です。
注釈
data range start time を考慮してデータをロードすると、増分更新のパフォーマンスが低下するため、すべての履歴データをロードするよりも時間がかかる場合があります。
テーブルへのデータのリロード¶
特定のテーブルにデータをリロードするには、 RELOAD_TABLE
ストアドプロシージャを呼び出します。
CALL RELOAD_TABLE('<table_name>');
条件:
table_name
リロードするテーブルの名前を指定します。
RELOAD_TABLE
ストアドプロシージャを呼び出すと、コネクタは次の例を実行します。
コネクタは、インジェスチョンのために元のテーブルを一時的に中断します。
注釈
テーブルのリロード中は、インジェスチョンのためにテーブルを再度有効にすることはできません。
コネクタは、インジェスチョン用に別の仮テーブルを作成します。
コネクタは、この新しい仮テーブルにデータをインジェストします。このテーブルは、
__tmp
サフィックスが付いた名前のテーブルとして CONNECTOR_STATS ビューに表示されます。注釈
リロードのたびに data range start time の値が考慮され、どの記録がインジェストされるかを制限することができます。
データがインジェストされた後、コネクタは元のテーブルのデータを仮テーブルのデータに置き換えます。
コネクタは仮テーブルを削除します。
コネクタは、インジェスチョンのために元のテーブルを再度有効にします。
このプロセス中、元のテーブル内にある既存のデータに対して引き続きクエリを実行できます。ただし、ServiceNow®テーブルのデータへの変更は、インジェスチョンプロセスが完了するまでSnowflakeテーブルに反映されません。
ServiceNow®インスタンスの過負荷を回避するには、一度に1つのテーブルのみをリロードします。
テーブルのリロードのキャンセル¶
テーブルにデータをリロードするプロセスをキャンセルするには、次の例に示すように CANCEL_RELOAD_TABLE
ストアドプロシージャを使用します。
CALL CANCEL_RELOAD_TABLE('<table_name>');
条件:
table_name
リロードをキャンセルするテーブルの名前を指定します。
リロードをキャンセルすると、コネクタはリロード中に作成されたすべての仮オブジェクトをドロップします。その後、テーブルは通常の同期スケジュールの一部としてインジェスチョン可能になります。
テーブルの単一ページフェッチのサイズ構成¶
コネクタは、テーブルをページと呼ばれる小さなチャンクに分割することで、テーブルからデータをフェッチします。ServiceNow®への API リクエストごとに1ページがフェッチされます。
これを考慮して、コネクタは単一の API リクエスト内でフェッチされる行数を制限します。この制限はページサイズです。
コネクタは、次のプロセスを使用してページサイズを決定します。
最初にデフォルトのページサイズは10,000行に設定されています。
応答サイズを超えたためにインジェスチョン中にフェッチリクエストが失敗した場合、リクエストが成功するか、最終的なページサイズが1に設定されるまで、ページサイズは1000、100、10、1と徐々に減少します。
成功したページサイズはコネクタの状態に保存され、この値が後続のリクエストで使用されます。
テーブルの現在のページサイズは TABLES_STATE
ビューで確認できます。ページサイズを確認するには、次のコマンドを実行します。
SELECT PAGE_SIZE FROM TABLES_STATE WHERE TABLE_NAME = '<table_name>';
条件:
table_name
インジェストされる ServiceNow®テーブルの名前を指定します。
コネクタがページサイズを決定するために使用するプロセスは、非効率につながる可能性があります。このプロセスは、ページサイズを縮小するだけです。ページサイズは増加しません。これは、ページサイズがより低い値に設定される原因となる、単一の大きな行がテーブルにある場合に発生する可能性があります。
この状況を回避するには、次の例に示すように、 RESET_PAGE_SIZE
ストアドプロシージャを呼び出してページサイズを手動で設定できます。
CALL RESET_PAGE_SIZE('<table_name>');
条件:
table_name
インジェストされる ServiceNow®テーブルの名前を指定します。
インジェスチョン実行¶
所定のテーブルのインジェスチョン実行は、設定されたスケジュールに従ってトリガーされます。実行は、ループ内でソーステーブルから前の段落で述べたページに分割された関連するすべての行をダウンロードします。
初期ロードおよび更新
データのページは、フェッチされるとすぐに対応するイベントログテーブルに挿入されます。このステージでは、新しくフェッチされた変更は同期テーブルやフラット化ビューではまだ利用できません。終了すると、何らかのデータが返される限り、条件を更新した次のリクエストが発行されます。インジェスチョン実行が完了し、ソーステーブルにフェッチするデータがなくなると、非同期マージタスクがトリガーされ、最後のマージ以降に挿入されたイベントログのすべての変更が取得され、同期テーブルに適用されます。それが完了すると、データは同期テーブルとフラット化ビューで利用できるようになります。
切り捨ててロード
切り捨ててロードモードでは、インジェスチョン実行ごとに仮テーブルが作成されます。フェッチされた行の各ページは、まずこの仮テーブルに挿入されます(このテーブルは内部コネクタスキーマに存在し、コネクタユーザーは利用できません)。このステージでは、新しく取得された変更はまだ同期テーブルやフラット化された表示では利用できず、前回の実行でフェッチされたデータが表示されます。インジェスチョン実行が完了し、ソーステーブルに利用可能なデータがなくなると、同期テーブルの既存のデータは仮テーブルのデータに置き換えられます。フェッチされた行はすべてイベントログにも追加されます。最後に仮テーブルはドロップされます。
進捗状況のモニター
現在または過去のインジェスチョン実行のステータスを確認するには、 CONNECTOR_STATS
ビューをクエリできます。 STATUS
列に表示されます。データのフェッチに成功し、すべての変更が同期テーブルに適用された場合にのみ、 DONE
に設定されます。インジェスチョンを実行中、または同期テーブルへのマージまたは同期テーブル内の行の置換がまだ完了していない場合、ステータスは RUNNING
となります。
次のステップ¶
ダイジェストを構成した後、 Snowflakeでの ServiceNow®データへのアクセス で説明した手順を実行し、ServiceNow®データを表示したりアクセスしたりします。