ServiceNow® 데이터에 대한 데이터 수집 설정하기¶

보관된 레코드¶

커넥터는 수집된 테이블에 대해 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 측의 보관 테이블에 수집되지 않습니다. 보관 테이블의 초기 로 후 파괴 규칙 에 의해 복원 또는 삭제된 보관 레코드는 Snowflake 측에서 절대 제거되지 않습니다.

Snowsight를 사용하여 데이터 수집 수정하기¶

수집할 ServiceNow® 테이블 또는 테이블의 동기화 일정을 수정하려면 다음을 수행합니다.

1. ACCOUNTADMIN 역할을 가진 사용자로 Snowsight 에 로그인합니다.

2. 탐색 메뉴에서 Data Products » Apps 를 선택합니다.

3. ServiceNow® V2용 Snowflake Connector를 검색한 다음 커넥터에 알맞은 타일을 선택합니다.

4. Snowflake Connector for ServiceNow®V2 페이지에서 Data Sync 를 선택합니다.

5. Edit tables 버튼을 선택하여 편집 모드로 들어갑니다.

6. 수집하려는 테이블을 수정합니다.

   1. 수집하려는 테이블을 검색합니다.

   2. 왼쪽에서 Status 열의 확인란을 선택하여 선택하거나 선택 취소할 테이블로 이동합니다.

   3. Sync Schedule 아래에서 Snowflake와 ServiceNow® 사이에서 테이블을 동기화할 빈도를 선택합니다.

7. Update data sync 를 선택합니다.

테이블 동기화 활성화 또는 비활성화하기¶

이 섹션에서는 ServiceNow®에서 테이블 동기화를 활성화하거나 비활성화하는 방법을 설명합니다. 기본 구성과 사용자 지정 구성에서 모두 동기화 활성화를 수행할 수 있습니다.

CALL ENABLE_TABLES(<tables_to_enable>);

CALL ENABLE_TABLES(['table1', 'table2', 'table3']);

CALL DISABLE_TABLES(<tables_to_disable>);

CALL DISABLE_TABLES(['table1', 'table2']);

CALL ENABLE_TABLE('<table_to_enable>', <table_config>);

CALL ENABLE_TABLE('<table_to_enable>', <table_config>);

CALL ENABLE_TABLE('u_table', { 'include_columns': ['sys_id', 'sys_updated_on'] });

CALL ENABLE_TABLE('u_table', { 'exclude_columns': ['col_1'] });

CALL ENABLE_TABLE('<table_to_enable>', <table_config>);

CALL ENABLE_TABLE('sys_audit', {
  'row_filter': 'tablename = "incident" AND fieldname = "cause" AND newvalue LIKE "privacy"'
});

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")'
});

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에 동기화합니다. 기본적으로, 모든 테이블은 매시간(1h) 한 번씩 동기화됩니다.

모든 테이블의 기본 동기화 일정을 변경하려면 다음 인자를 사용하여 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시간 이상 지속해야 합니다. 예를 들어, 'PT12H' 값은 12시간 동안 지속되는 기간을 지정하고, 'P2D' 값은 2일 동안 지속되는 기간을 지정합니다.

사용자 지정 일정이 있는 테이블만 활성화하는 경우 이 구성은 구성된 테이블에 대해 평면화된 뷰를 생성하고 새로 고치는 데 걸리는 시간에만 영향을 미칩니다. 평면화된 뷰는 다음 조건이 충족된 후 첫 번째 수집 주기에서 생성됩니다.

• 메타데이터 테이블 수집이 완료됨

• 구성된 테이블의 수집이 시작됨

이메일 경고가 활성화된 경우 사용자 지정 예약을 사용할 때 경고 빈도를 Once per day 로 변경하는 것이 좋습니다.

데이터 범위 시작 시간 지정하기¶

기본적으로 Snowflake Connector for ServiceNow®V2 는 해당 ServiceNow® 테이블의 모든 레코드를 동기화합니다. 다음이 포함된 테이블의 경우: sys_updated_on 또는 sys_created_on 열(지금부터 시간 열 이라고 함)이 있는 경우 데이터 범위 시작 시간, 즉 레코드의 해당 시간 열 값 하한을 설정하여 동기화된 데이터 범위를 제한할 수 있습니다.

이러한 구성을 사용하면 데이터 범위 시작 타임스탬프 보다 오래된 해당 시간 열 값이 있는 레코드는 수집되지 않습니다. 이 절차에 사용되는 해당 시간 열 은 증분 업데이트와 동일한 방식 으로 결정됩니다.

데이터 범위 시작 시간 값을 변경하려면 다음 인자를 사용하여 CONFIGURE_TABLES_RANGE_START 저장 프로시저를 호출하십시오.

CALL CONFIGURE_TABLES_RANGE_START(<table_names>, <range_start>);

Copy

여기서

table_names

데이터 범위 시작 시간 을 구성하려는 테이블 이름으로 구성된 배열을 지정합니다.

range_start

현재 값을 설정 해제하려면 TIMESTAMP_TZ 형식 또는 NULL로 데이터 범위 시작 시간 을 지정하는 타임스탬프입니다.

• 테이블의 수집이 아직 시작되지 않은 경우 첫 번째 수집 시 데이터 범위 시작 시간 값이 고려됩니다.

• 테이블 수집이 이미 시작된 경우(예: 다시 로드가 진행 중인 경우) 데이터 범위 시작 시간 값이 무시되고 해당 시간 열 값이 너무 오래된 레코드를 걸러내려면 (또 다른) 테이블을 다시 로드 해야 합니다.

따라서 테이블의 첫 번째 수집을 시작하기 전(따라서 활성화하기 전) 데이터 범위 시작 시간 을 설정하는 것이 좋습니다.

예를 들어 테이블 table1 및 table2 에 필수적인 시간 열 이 있는 경우 이 두 테이블에 대해 데이터 범위 시작 시간 을 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'));

Copy

그러면 다음과 같습니다.

• 예를 들어 테이블 table1 의 경우 수집이 아직 시작되지 않았다면 2022-11-23 07:00:00 이전에 해당 시간 열 값이 있는 모든 레코드는 수집되지 않습니다.

• 예를 들어 테이블 table2 의 경우 수집이 이미 시작되었다면 이 테이블을 다시 로드할 때까지 모든 데이터 동기화에서 데이터 범위 시간 시작 값이 무시됩니다. 다시 로드하는 동안 2022-11-23 07:00:00 이전에 해당 시간 열 값이 있는 모든 레코드가 수집되지 않습니다.

데이터 범위 시작 시간 을 설정 해제할 수도 있습니다. 예를 들어 table1 테이블에 대해 설정을 해제하려면 다음 명령을 실행하십시오.

CALL CONFIGURE_TABLES_RANGE_START(['table1'], NULL);

Copy

다시 설명하자면, table1 테이블의 수집이 이미 시작되었다면 ServiceNow®에서 모든 레코드를 다시 수집하려면 이 테이블을 다시 로드해야 합니다.

테이블에서 데이터 다시 로드하기¶

특정 테이블의 데이터를 다시 로드하려면 RELOAD_TABLE 저장 프로시저를 호출하십시오.

CALL RELOAD_TABLE('<table_name>');

여기서

table_name

다시 로드할 테이블의 이름을 지정합니다.

RELOAD_TABLE 저장 프로시저를 호출하면 커넥터가 다음 예제를 수행합니다.

1. 커넥터가 수집을 위해 임시로 원본 테이블을 일시 중단합니다.

   참고

   테이블을 다시 로드하는 동안 수집을 위해 테이블을 다시 활성화할 수 없습니다.

2. 커넥터가 수집을 위한 별도의 임시 테이블을 만듭니다.

3. 커넥터가 데이터를 이 새 임시 테이블로 수집합니다. 이 테이블은 CONNECTOR_STATS 뷰에서 __tmp 접미사로 명명된 테이블로 표시됩니다.

   참고

   다시 로드할 때마다 데이터 범위 시작 시간 값을 고려하므로 수집되는 레코드가 제한될 수 있습니다.

4. 데이터가 수집된 후 커넥터는 원본 테이블의 데이터를 임시 테이블의 데이터로 바꿉니다.

5. 커넥터가 임시 테이블을 삭제합니다.

6. 커넥터가 수집을 위해 원래 테이블을 다시 활성화합니다.

이 프로세스 중에 원래 테이블의 기존 데이터를 계속 쿼리할 수 있습니다. 하지만 ServiceNow® 테이블의 데이터에 대한 변경 사항은 수집 프로세스가 완료될 때까지 Snowflake 테이블에 반영되지 않습니다.

ServiceNow® 인스턴스의 오버로드를 방지하려면 테이블을 한 번에 하나씩만 다시 로드합니다.

테이블 다시 로드 취소하기¶

테이블의 데이터를 다시 로드하는 프로세스를 취소하려면 다음 예와 같이 CANCEL_RELOAD_TABLE 저장 프로시저를 사용하십시오.

CALL CANCEL_RELOAD_TABLE('<table_name>');

여기서

table_name

다시 로드를 취소하려는 테이블의 이름을 지정합니다.

다시 로드를 취소하면 커넥터가 다시 로드 중에 생성된 모든 임시 오브젝트를 삭제합니다. 그런 다음 일반 동기화 일정의 일부로 테이블을 사용하여 수집할 수 있습니다.

테이블에 대한 단일 페이지 가져오기 크기 구성하기¶

커넥터는 페이지라고 하는 더 작은 청크로 나누어 테이블에서 데이터를 가져옵니다. ServiceNow®에 대한 각 API 요청은 1개 페이지를 가져옵니다.

이를 처리하기 위해 커넥터는 단일 API 요청 내에서 가져오는 행 수를 제한합니다. 이 제한은 페이지 크기입니다.

커넥터가 페이지 크기를 결정하기 위해 사용하는 프로세스는 다음과 같습니다.

1. 처음에 기본 페이지 크기는 10,000개 행으로 설정됩니다.

2. 응답 크기를 초과하여 수집 중 가져오기 요청이 실패하면 요청이 성공하거나 최종 페이지 크기가 1로 설정될 때까지 페이지 크기가 1000, 100, 10 및 1씩 점진적으로 감소합니다.

3. 성공한 페이지 크기는 커넥터 상태에 저장되며 후속 요청에서 이 값이 사용됩니다.

테이블에 대한 현재 페이지 크기는 TABLES_STATE 뷰에서 확인할 수 있습니다. 페이지 크기를 보려면 다음 명령을 실행합니다.

SELECT PAGE_SIZE FROM TABLES_STATE WHERE TABLE_NAME = '<table_name>';

여기서

table_name

수집 중인 ServiceNow® 테이블의 이름을 지정합니다.

페이지 크기를 결정하기 위해 커넥터가 사용하는 프로세스는 비효율적일 수 있습니다. 이 프로세스에서는 페이지 크기 감소만 수행되며, 페이지 크기 증가는 수행되지 않습니다. 이러한 상황은 테이블에 페이지 크기가 더 낮은 값으로 설정되도록 하는 대규모 행 1개가 있는 경우에 발생할 수 있습니다.

이러한 상황을 방지하려면, 다음 예에서와 같이 RESET_PAGE_SIZE 저장 프로시저를 호출하여 페이지 크기를 수동으로 설정할 수 있습니다.

CALL RESET_PAGE_SIZE('<table_name>');

여기서

table_name

수집 중인 ServiceNow® 테이블의 이름을 지정합니다.

수집 실행¶

주어진 테이블에 대한 수집 실행은 구성된 일정에 따라 트리거됩니다. 실행은 이전 단락에서 언급한 페이지로 구분된 모든 관련 행을 루프의 원본 테이블에서 다운로드합니다.

초기 로드 및 업데이트

데이터 페이지를 가져오자마자 해당 이벤트 로그 테이블에 삽입됩니다. 이 스테이지에서는 새로 가져온 변경 사항을 동기화 테이블이나 평면화된 뷰를 통해 아직 사용할 수 없습니다. 완료 시 데이터가 반환되는 한 업데이트된 기준으로 다음 요청이 발행됩니다. 수집 실행이 완료되고 원본 테이블에 더 이상 가져올 데이터가 없으면 비동기 병합 작업이 트리거되며, 해당 작업은 마지막 병합 이후 삽입된 이벤트 로그의 모든 변경 내용을 가져와서 동기화 테이블에 적용합니다. 완료되면 동기화 테이블과 평면화된 뷰에서 데이터를 사용할 수 있게 됩니다.

자르기 및 로딩

자르기 및 로딩 모드에서는 각 수집 실행에 대해 임시 테이블이 생성됩니다. 가져온 행의 각 페이지는 먼저 이 임시 테이블에 삽입됩니다(이 테이블은 내부 커넥터 스키마에 존재하며 커넥터 사용자는 사용할 수 없음). 이 스테이지에서는 새로 가져온 변경 사항을 동기화 테이블이나 평면화된 뷰를 통해 아직 사용할 수 없으며, 이전 실행에서 가져온 데이터가 계속 표시됩니다. 수집 실행이 완료되고 원본 테이블에 더 이상 사용 가능한 데이터가 없으면 동기화 테이블의 기존 데이터가 임시 테이블의 데이터로 바뀝니다. 가져온 모든 행은 이벤트 로그에도 추가됩니다. 마지막에는 임시 테이블이 삭제됩니다.

진행 상황 모니터링

현재 또는 과거 수집 실행 상태를 확인하려면 CONNECTOR_STATS 뷰를 쿼리하면 됩니다. 이는 STATUS 열에 표시됩니다. 데이터를 성공적으로 가져오고 모든 변경 사항이 동기화 테이블에 적용된 경우에만 DONE 으로 설정됩니다. 수집이 실행 중이거나 동기화 테이블에 대한 병합/동기화 테이블의 행 바꾸기가 아직 완료되지 않은 경우 상태는 RUNNING 입니다.