Azure Data Explorer에서 중복 데이터 처리
클라우드로 데이터를 전송하는 디바이스는 데이터의 로컬 캐시를 유지 관리합니다. 데이터 크기에 따라 로컬 캐시는 데이터를 수일 동안 저장하거나 수 개월 동안 저장할 수도 있습니다. 디바이스 오작동으로 인해 캐시된 데이터가 다시 전송되어 분석 데이터베이스에 데이터 중복이 발생하지 않도록 분석 데이터를 보호하는 것이 좋습니다. 중복은 쿼리에서 반환되는 레코드 수에 영향을 줄 수 있습니다. 이는 이벤트 카운팅과 같이 정확한 레코드 카운트가 필요한 경우에 적합합니다. 이 항목에서는 이러한 종류의 시나리오에서 중복 데이터를 처리하는 방법에 대한 모범 사례를 간략하게 설명합니다.
데이터 중복에 가장 효과적인 해결책은 중복을 방지하는 것입니다. 가능한 경우 데이터 파이프라인의 초기 단계에서 문제를 해결하여 데이터 파이프라인 내 데이터 이동과 관련한 비용을 절감하고 시스템에 수집된 중복 데이터를 처리하는 데 리소스를 소비하지 않도록 할 수 있습니다. 그러나 원본 시스템을 수정할 수 없는 경우 다양한 방법으로 문제를 해결할 수 있습니다.
중복 데이터의 영향 파악
중복 데이터의 비율을 모니터링하세요. 중복 데이터의 비율을 확인했으면 문제의 범위와 비즈니스에 미치는 영향을 분석하고 적절한 해결 방법을 선택할 수 있습니다.
중복 레코드의 비율을 파악하기 위한 샘플 쿼리:
let _sample = 0.01; // 1% sampling
let _data =
DeviceEventsAll
| where EventDateTime between (datetime('10-01-2018 10:00') .. datetime('10-10-2018 10:00'));
let _totalRecords = toscalar(_data | count);
_data
| where rand()<= _sample
| summarize recordsCount=count() by hash(DeviceId) + hash(EventId) + hash(StationId) // Use all dimensions that make row unique. Combining hashes can be improved
| summarize duplicateRecords=countif(recordsCount > 1)
| extend duplicate_percentage = (duplicateRecords / _sample) / _totalRecords
중복 데이터 처리 방법
솔루션 #1: 중복 데이터 제거 안 함
비즈니스 요구 사항 및 중복 데이터 허용치를 파악하세요. 일부 데이터 세트는 일정 비율의 중복 데이터를 사용하여 관리할 수 있습니다. 중복 데이터가 큰 영향을 주지 않는다면 무시해도 됩니다. 중복 데이터를 제거하지 않을 경우 수집 프로세스나 쿼리 성능에 추가적인 부담을 주지 않는다는 장점이 있습니다.
솔루션 #2: 쿼리 중 중복 행 처리
또 다른 옵션은 쿼리 중 데이터의 중복 행을 필터링하는 것입니다. arg_max()
집계 함수를 사용하여 중복 레코드를 필터링하고 타임스탬프(또는 다른 열)에 따라 마지막 레코드를 반환할 수 있습니다. 이 방법을 사용할 경우 쿼리 중에 중복 제거가 수행되므로 수집 시간이 단축된다는 장점이 있습니다. 또한 중복 항목을 포함한 모든 레코드를 감사 및 문제 해결에 사용할 수 있습니다. arg_max
함수 사용 시 데이터가 쿼리될 때마다 쿼리 시간과 CPU 로드가 늘어난다는 단점이 있습니다. 쿼리 중인 데이터 양에 따라 이 해결 방법이 효과가 없거나 메모리를 소모할 수 있으며, 이 경우 다른 옵션으로 전환해야 합니다.
다음 예에서는 수집된 마지막 레코드에서 고유한 레코드를 결정하는 열 집합을 쿼리합니다.
DeviceEventsAll
| where EventDateTime > ago(90d)
| summarize hint.strategy=shuffle arg_max(EventDateTime, *) by DeviceId, EventId, StationId
또한 테이블을 직접 쿼리하는 대신 함수 내부에 이 쿼리를 배치할 수도 있습니다.
.create function DeviceEventsView
{
DeviceEventsAll
| where EventDateTime > ago(90d)
| summarize arg_max(EventDateTime, *) by DeviceId, EventId, StationId
}
솔루션 #3: 구체화된 뷰를 사용하여 중복 제거
구체화된 뷰는 take_any()/arg_min()/arg_max() 집계 함수를 통해 중복 제거에 사용할 수 있습니다(materialized view create 명령의 예 #4 참조).
참고
구체화된 뷰에는 클러스터 리소스를 소비하는 비용이 발생하며, 이는 무시할 수 없습니다. 자세한 내용은 구체화된 뷰 성능 고려 사항을 참조하세요.
해결 방법 #4: 일시 삭제를 사용하여 중복 항목 제거
일시 삭제는 개별 레코드를 삭제하는 기능을 지원하므로 중복 항목을 삭제하는 데 사용할 수 있습니다. 이 옵션은 자주 삭제하지 않는 경우에만 권장되며 들어오는 모든 레코드를 지속적으로 중복 제거해야 하는 경우에는 권장되지 않습니다.
데이터 중복 제거를 위해 구체화된 뷰와 일시 삭제 중에서 선택
중복 제거를 위해 구체화된 뷰 또는 일시 삭제 사용 중에서 선택하는 데 도움이 될 수 있는 몇 가지 고려 사항이 있습니다.
- 관리 및 오케스트레이션: 구체화된 뷰는 완전 관리형 솔루션입니다. 뷰는 한 번만 정의되고 시스템은 들어오는 모든 레코드의 중복 제거를 처리합니다. 일시 삭제에는 오케스트레이션 및 관리가 필요합니다. 따라서 구체화된 뷰가 사용 사례에 적합한 경우 항상 이 옵션을 선택해야 합니다.
- 레코드 중복 제거 시기: 일시 삭제를 사용하면 중복 레코드가 먼저 테이블에 추가된 다음, 삭제됩니다. 따라서 수집 및 일시 삭제 프로세스 사이에 중복 항목이 테이블에 포함됩니다. 구체화된 뷰를 사용하면, 뷰에 들어가기 전에 중복 제거되므로 뷰의 레코드는 항상 중복 제거됩니다.
- 빈도: 테이블을 지속적으로 중복 제거해야 하는 경우 구체화된 뷰를 사용합니다. 중복이 자주 발생하지 않으며 수집 중에 중복 항목을 식별할 수 있는 경우 일시 삭제 프로세스가 일반적으로 구체화된 뷰보다 더 잘 수행됩니다. 예를 들어 수집에 일반적으로 중복 항목이 없지만 때때로 중복 항목이 포함된 것으로 알려진 스트림을 수집하는 상황이 있습니다. 이 시나리오에서는 모든 레코드를 지속적으로 중복 제거하도록 구체화된 뷰를 정의하는 것보다 일시 삭제를 사용하여 이러한 중복을 처리하는 것이 좋습니다.
솔루션 #5: ingest-by
익스텐트 태그
'ingest-by:' 익스텐트 태그를 사용하여 수집 중 중복을 방지할 수 있습니다. 이는 각 수집 일괄 처리에 중복이 없도록 보장되고 동일한 수집 일괄 처리가 두 번 이상 수집되어 중복이 예상되는 사용 사례에서만 관련이 있습니다.
요약
데이터 중복은 여러 가지 방법으로 처리할 수 있습니다. 비즈니스에 적절한 방법을 결정하려면 가격 및 성능을 고려하여 옵션을 신중하게 평가하세요.