업데이트 정책 개요
적용 대상: ✅Microsoft Fabric✅Azure Data Explorer
업데이트 정책은 새 데이터가 테이블에 기록될 때 트리거되는 자동화 메커니즘입니다. 수집된 데이터를 변환하고 결과를 대상 테이블에 저장하는 쿼리를 실행하여 특수 오케스트레이션이 필요하지 않습니다. 단일 테이블에 여러 업데이트 정책을 정의하여 다양한 변환을 허용하고 동시에 여러 테이블에 데이터를 저장할 수 있습니다. 대상 테이블에는 원본 테이블의 다른 스키마, 보존 정책 및 기타 정책이 있을 수 있습니다.
예를 들어 높은 비율의 추적 원본 테이블에는 자유 텍스트 열로 서식 지정된 데이터가 포함될 수 있습니다. 대상 테이블에는 구문 분석 연산자를 사용하여 원본 테이블의 자유 텍스트 데이터 변환에서 생성된 잘 구성된 스키마와 함께 특정 추적 줄이 포함될 수 있습니다. 자세한 내용은 일반적인 시나리오입니다.
다음 다이어그램은 업데이트 정책의 개략적인 보기를 보여 줍니다. 두 번째 원본 테이블에 데이터가 추가될 때 트리거되는 두 가지 업데이트 정책을 보여 있습니다. 트리거되면 변환된 데이터가 두 대상 테이블에 추가됩니다.
업데이트 정책에는 일반 수집과 동일한 제한 사항 및 모범 사례가 적용됩니다. 정책은 클러스터 크기에 따라 확장되며 대량 수집을 처리할 때 더 효율적입니다.
업데이트 정책에는 일반 수집과 동일한 제한 사항 및 모범 사례가 적용됩니다. 정책은 Eventhouse 크기에 따라 확장되며 대량 수집을 처리할 때 더 효율적입니다.
참고 항목
- 원본 및 대상 테이블은 동일한 데이터베이스에 있어야 합니다.
- 업데이트 정책 함수 스키마와 대상 테이블 스키마는 열 이름, 형식 및 순서에서 일치해야 합니다.
- 업데이트 정책 함수는 다른 데이터베이스의 테이블을 참조할 수 있습니다. 이렇게 하려면 업데이트 정책을 속성으로
ManagedIdentity정의해야 하며 관리 ID에는viewer참조된 데이터베이스에 대한 역할이 있어야 합니다. 형식이 지정된 데이터를 수집하면 성능이 향상되고 CSV는 잘 정의된 형식이므로 사용하는 것이 좋습니다. 그러나 데이터 형식을 제어할 수 없거나, 예를 들어 데이터베이스의 정적 차원 테이블과 레코드를 조인하여 수집된 데이터를 보강하려는 경우가 있습니다.
정책 쿼리 업데이트
업데이트 정책이 대상 테이블에 정의된 경우 원본 테이블에 수집된 데이터에서 여러 쿼리를 실행할 수 있습니다. 여러 업데이트 정책이 있는 경우 실행 순서를 반드시 알 수 있는 것은 아닙니다.
쿼리 제한 사항
- 정책 관련 쿼리는 저장된 함수를 호출할 수 있지만 다음을 수행합니다.
- 클러스터 간 쿼리를 수행할 수 없습니다.
- 외부 데이터 또는 외부 테이블에 액세스할 수 없습니다.
- 플러그 인을 사용하여 설명선은 만들 수 없습니다.
- 쿼리에는 RestrictedViewAccess 정책을 사용하도록 설정된 테이블에 대한 읽기 권한이 없습니다.
- 스트리밍 수집의 업데이트 정책 제한 사항은 스트리밍 수집 제한을 참조 하세요.
- 정책 관련 쿼리는 저장된 함수를 호출할 수 있지만 다음을 수행합니다.
- 이벤트 하우스 간 쿼리를 수행할 수 없습니다.
- 외부 데이터 또는 외부 테이블에 액세스할 수 없습니다.
- 플러그 인을 사용하여 설명선은 만들 수 없습니다.
- 쿼리에는 RestrictedViewAccess 정책을 사용하도록 설정된 테이블에 대한 읽기 권한이 없습니다.
- 스트리밍 수집의 업데이트 정책 제한 사항은 스트리밍 수집 제한을 참조 하세요.
Warning
잘못된 쿼리는 원본 테이블로의 데이터 수집을 방지할 수 있습니다. 쿼리 결과와 원본 및 대상 테이블의 스키마 간의 호환성뿐만 아니라 제한 사항으로 인해 잘못된 쿼리로 인해 원본 테이블로의 데이터 수집을 방지할 수 있습니다.
이러한 제한 사항은 정책을 만들고 실행하는 동안 유효성을 검사하지만 쿼리에서 참조할 수 있는 임의의 저장된 함수가 업데이트되는 경우는 아닙니다. 따라서 업데이트 정책이 그대로 유지되도록 주의해서 변경해야 합니다.
정책의 일부 또는 파트에서 Query 참조하는 Source 함수에서 테이블을 참조하는 Query 경우:
- 테이블의 정규화된 이름을 사용하지 마세요. 대신
TableName을 사용합니다. database("<DatabaseName>").TableName또는cluster("<ClusterName>").database("<DatabaseName>").TableName은 사용하지 마세요.
- 테이블의 정규화된 이름을 사용하지 마세요. 대신
TableName을 사용합니다. database("<DatabaseName>").TableName또는cluster("<EventhouseName>").database("<DatabaseName>").TableName은 사용하지 마세요.
업데이트 정책 개체
테이블에 연결된 업데이트 정책 개체가 0개 이상 있을 수 있습니다. 이러한 각 개체는 다음 속성이 정의된 JSON 속성 모음으로 표시됩니다.
| 속성 | Type | 설명 |
|---|---|---|
| IsEnabled | bool |
업데이트 정책이 true인 경우(사용 또는 false) 상태 - 사용 안 함 |
| Source | string |
업데이트 정책의 호출을 트리거하는 테이블의 이름 |
| 쿼리 | string |
업데이트에 대한 데이터를 생성하는 데 사용되는 쿼리 |
| IsTransactional | bool |
업데이트 정책이 트랜잭션인지 아닌지 여부, 기본값은 false입니다. 정책이 트랜잭션이고 업데이트 정책이 실패하면 원본 테이블이 업데이트되지 않습니다. |
| PropagateIngestionProperties | bool |
익스텐트 태그 및 생성 시간과 같이 원본 테이블을 수집하는 동안 지정된 속성이 대상 테이블에 적용되는지 확인합니다 . |
| ManagedIdentity | string |
업데이트 정책이 실행되는 관리 ID입니다. 관리 ID는 개체 ID 또는 system 예약어일 수 있습니다. 쿼리가 사용 가능한 행 수준 보안 정책을 사용하여 다른 데이터베이스 또는 테이블의 테이블을 참조하는 경우 업데이트 정책을 관리 ID로 구성해야 합니다. 자세한 내용은 관리 ID를 사용하여 업데이트 정책을 실행하세요. |
참고 항목
프로덕션 시스템에서 :true를 설정IsTransactional하여 대상 테이블이 일시적인 오류로 데이터가 손실되지 않도록 합니다.
참고 항목
예를 들어 테이블 A에서 테이블 B, 테이블 C에 대한 연계 업데이트가 허용됩니다. 그러나 업데이트 정책이 순환 방식으로 정의되면 런타임에 검색되고 업데이트 체인이 잘려집니다. 데이터는 체인의 각 테이블에 한 번만 수집됩니다.
관리 명령
업데이트 정책 관리 명령은 다음과 같습니다.
.show table *TableName* policy update는 테이블의 현재 업데이트 정책을 표시합니다..alter table *TableName* policy update는 테이블의 현재 업데이트 정책을 정의합니다..alter-merge table *TableName* policy update는 테이블의 현재 업데이트 정책에 정의를 추가합니다..delete table *TableName* policy update는 테이블의 현재 업데이트 정책을 삭제합니다.
업데이트 정책은 수집 후 시작됩니다.
업데이트 정책은 데이터를 수집하거나 원본 테이블로 이동하거나 원본 테이블에 익스텐트를 만들 때 적용됩니다. 이러한 작업은 다음 명령 중 어느 것을 사용하여 수행할 수 있습니다.
- .ingest(pull)
- .ingest(인라인)
- .set | .append | .set-or-append | .set-or-replace
- .move 익스텐트
- .replace 익스텐트
- 이
PropagateIngestionProperties명령은 수집 작업에만 적용됩니다. 업데이트 정책이 명령.replace extents의.move extents일부로 트리거되면 이 옵션은 적용되지 않습니다.
- 이
Warning
업데이트 정책이 명령의 일부로 호출되면 기본적으로 파생 테이블의 .set-or-replace 데이터가 원본 테이블과 동일한 방식으로 대체됩니다.
명령이 호출되면 업데이트 정책 관계가 replace 있는 모든 테이블에서 데이터가 손실될 수 있습니다.
대신 .set-or-append을 사용하는 것이 좋습니다.
원본 테이블에서 데이터 제거
대상 테이블에 데이터를 수집한 후 필요에 따라 원본 테이블에서 제거할 수 있습니다. 원본 테이블의 0sec 보존 정책에서 일시 삭제 기간(또는00:00:00)을 설정하고 업데이트 정책을 트랜잭션으로 설정합니다. 다음 조건이 적용됩니다.
- 원본 데이터는 원본 테이블에서 쿼리할 수 없습니다.
- 원본 데이터는 수집 작업의 일부로 지속성 스토리지에 유지되지 않습니다.
- 운영 성능이 향상됩니다. 수집 후 리소스는 원본 테이블의 익스텐트에서 백그라운드 그루밍 작업에 대해 감소됩니다 .
참고 항목
원본 테이블에 일시 삭제 기간 0sec (또는 00:00:00)이 있는 경우 이 테이블을 참조하는 모든 업데이트 정책은 트랜잭션이어야 합니다.
성능에 미치는 영향
업데이트 정책은 성능에 영향을 줄 수 있으며 데이터 익스텐트 수집에 대상 테이블 수를 곱합니다. 정책 관련 쿼리를 최적화하는 것이 중요합니다. 기존 익스텐트에서 정책을 호출하거나, 정책을 만들거나 변경하기 전에 또는 쿼리와 함께 사용되는 함수에서 정책을 호출하여 업데이트 정책의 성능 영향을 테스트할 수 있습니다.
리소스 사용량 평가
다음 매개 변수를 사용하여 리소스 사용량(CPU, 메모리 등)을 평가하는 데 사용합니다 .show queries.
- 속성( 원본 테이블 이름)을
Source로 설정합니다.MySourceTable - 명명된
Query함수를 호출하도록 속성 설정MyFunction()
// '_extentId' is the ID of a recently created extent, that likely hasn't been merged yet.
let _extentId = toscalar(
MySourceTable
| project ExtentId = extent_id(), IngestionTime = ingestion_time()
| where IngestionTime > ago(10m)
| top 1 by IngestionTime desc
| project ExtentId
);
// This scopes the source table to the single recent extent.
let MySourceTable =
MySourceTable
| where ingestion_time() > ago(10m) and extent_id() == _extentId;
// This invokes the function in the update policy (that internally references `MySourceTable`).
MyFunction
트랜잭션 설정
업데이트 정책 IsTransactional 설정은 업데이트 정책이 트랜잭션인지 여부를 정의하며 다음과 같이 정책 업데이트의 동작에 영향을 줄 수 있습니다.
IsTransactional:false: 값이 기본값인 false로 설정된 경우 업데이트 정책은 원본 테이블과 대상 테이블의 데이터 간의 일관성을 보장하지 않습니다. 업데이트 정책이 실패하면 데이터는 대상 테이블이 아닌 원본 테이블에만 수집됩니다. 이 시나리오에서는 수집 작업이 성공합니다.IsTransactional:true: 값이 true로 설정된 경우 이 설정은 원본 테이블과 대상 테이블의 데이터 간의 일관성을 보장합니다. 업데이트 정책이 실패하면 데이터가 원본 또는 대상 테이블에 수집되지 않습니다. 이 시나리오에서는 수집 작업이 실패합니다.
오류 처리
정책 업데이트가 실패하면 설정 여부에 IsTransactional 따라 다르게 처리됩니다 true false. 업데이트 정책 실패의 일반적인 이유는 다음과 같습니다.
- 쿼리 출력 스키마와 대상 테이블이 일치하지 않습니다.
- 모든 쿼리 오류입니다.
다음 명령을 사용하여 .show ingestion failures 정책 업데이트 실패를 볼 수 있습니다. 다른 경우에는 수동으로 수집을 다시 시도할 수 있습니다.
.show ingestion failures
| where FailedOn > ago(1hr) and OriginatesFromUpdatePolicy == true
추출, 변환, 로드의 예
업데이트 정책 설정을 사용하여 ETL(추출, 변환, 로드)을 수행할 수 있습니다.
이 예제에서는 간단한 함수와 함께 업데이트 정책을 사용하여 ETL을 수행합니다. 먼저 다음 두 개의 테이블을 만듭니다.
- 원본 테이블 - 데이터가 수집되는 단일 문자열 형식 열을 포함합니다.
- 대상 테이블 - 원하는 스키마를 포함합니다. 업데이트 정책은 이 테이블에 정의되어 있습니다.
원본 테이블을 만들어 보겠습니다.
.create table MySourceTable (OriginalRecord:string)다음으로 대상 테이블을 만듭니다.
.create table MyTargetTable (Timestamp:datetime, ThreadId:int, ProcessId:int, TimeSinceStartup:timespan, Message:string)그런 다음, 데이터를 추출하는 함수를 만듭니다.
.create function with (docstring = 'Parses raw records into strongly-typed columns', folder = 'UpdatePolicyFunctions') ExtractMyLogs() { MySourceTable | parse OriginalRecord with "[" Timestamp:datetime "] [ThreadId:" ThreadId:int "] [ProcessId:" ProcessId:int "] TimeSinceStartup: " TimeSinceStartup:timespan " Message: " Message:string | project-away OriginalRecord }이제 업데이트 정책을 설정하여 만든 함수를 호출합니다.
.alter table MyTargetTable policy update @'[{ "IsEnabled": true, "Source": "MySourceTable", "Query": "ExtractMyLogs()", "IsTransactional": true, "PropagateIngestionProperties": false}]'데이터가 대상 테이블에 수집된 후 원본 테이블을 비우려면 원본 테이블의 보존 정책을 0으로
SoftDeletePeriod정의합니다..alter-merge table MySourceTable policy retention softdelete = 0s