데이터 결합 및 최적화
조직은 종종 여러 소스에서 다양한 유형의 정보를 수집합니다. 정보는 많은 테이블에 저장됩니다. 심층 분석 또는 보고를 위해 테이블 간의 논리적 관계를 기반으로 테이블을 조인해야 하는 경우도 있습니다. 소매 회사 시나리오에서는 고객, 제품 및 판매 정보에 대한 테이블을 사용합니다.
이 모듈에서는 Kusto 쿼리의 데이터를 결합하여 팀 구성원에게 제품 인식을 높이고 매출을 늘리는 데 필요한 정보를 제공하는 다양한 방법에 대해 알아봅니다.
데이터 이해
테이블의 정보를 결합하는 쿼리 작성을 시작하기 전에 데이터를 이해해야 합니다. Kusto 쿼리를 사용하는 경우 테이블을 다음 두 범주 중 하나에 광범위하게 속하는 것으로 간주하려고 합니다.
- 팩트 테이블: 리테일 회사 시나리오의 SalesFact 테이블과 같이 레코드가 변경할 수 없는 팩트인 테이블입니다. 이러한 테이블에서 레코드는 스트리밍 방식으로 또는 큰 청크로서 점진적으로 추가됩니다. 레코드는 제거되고 업데이트되지 않을 때까지 테이블에 유지됩니다.
- 차원 테이블: 리테일 회사 시나리오의 고객 및 제품 테이블과 같이 레코드가 변경 가능한 차원인 테이블입니다. 이러한 테이블에는 엔터티 식별자에서 해당 속성으로의 조회 테이블과 같은 참조 데이터가 저장됩니다. 차원 테이블은 정기적으로 새 데이터로 업데이트되지 않습니다.
소매 회사 시나리오에서는 차원 테이블을 사용하여 추가 정보로 SalesFact 테이블을 보강하거나 쿼리에 대한 데이터를 필터링하기 위한 추가 옵션을 제공합니다.
또한 작업 중인 데이터의 볼륨과 해당 구조 또는 스키마(열 이름 및 형식)를 이해하려고 합니다. 검사 중인 테이블의 이름으로 TABLE_NAME을(를) 바꿔 다음 쿼리를 실행해 해당 정보를 가져올 수 있습니다.
테이블의 레코드 수를 얻으려면 다음과 같은
count연산자를 사용합니다.TABLE_NAME | count테이블의 스키마를 얻으려면 다음과 같은
getschema연산자를 사용합니다.TABLE_NAME | getschema
소매 회사 시나리오에서 팩트 및 차원 테이블에 대해 이러한 쿼리를 실행하면 다음 예제와 같은 정보가 제공됩니다.
| 테이블 | 레코드 | 스키마 |
|---|---|---|
| SalesFact | 2,832,193 | - SalesAmount(실제) - TotalCost(실제) - DateKey(날짜/시간) - ProductKey(김) - CustomerKey(김) |
| 고객 | 18,484 | - CityName(문자열) - CompanyName(문자열) - ContinentName(문자열) - CustomerKey(김) - Education(문자열) - FirstName(문자열) - Gender(문자열) - LastName(문자열) - MaritalStatus(문자열) - Occupation(문자열) - RegionCountryName(문자열) - StateProvinceName(문자열) |
| 제품 | 2,517 | - ProductName(문자열) - Manufacturer(문자열) - ColorName(문자열) - ClassName(문자열) - ProductCategoryName(문자열) - ProductSubcategoryName(문자열) - ProductKey(김) |
표에서는 테이블 간에 레코드를 결합하는 데 사용되는 고유한 식별자 CustomerKey 및 ProductKey 를 강조 표시했습니다.
다중 테이블 쿼리 이해
데이터를 분석한 후에는 테이블을 결합하여 필요한 정보를 제공하는 방법을 이해해야 합니다. Kusto 쿼리는 lookup, join 및 union 연산자를 포함하여 여러 테이블의 데이터를 결합하는 데 사용할 수 있는 여러 연산자를 제공합니다.
join 연산자는 각 테이블에서 지정된 열의 값을 일치시켜 두 테이블의 행을 병합합니다. 결과 테이블은 사용하는 조인의 종류에 따라 달라집니다. 예를 들어 내부 조인을 사용하는 경우 테이블에 왼쪽 테이블과 동일한 열(외부 테이블이라고도 함)과 오른쪽 테이블의 열(내부 테이블이라고도 함)이 있습니다. 다음 섹션에서 조인 종류에 대해 자세히 알아봅니다. 최상의 성능을 위해 한 테이블이 항상 다른 테이블보다 작으면 해당 테이블을 join 연산자의 왼쪽으로 사용합니다.
lookup 연산자는 팩트 테이블이 차원 테이블의 데이터로 보강되는 쿼리의 성능을 최적화하는 join 연산자의 특수 구현입니다. 차원 테이블에서 조회되는 값으로 팩트 테이블을 확장합니다. 최상의 성능을 위해 시스템은 기본적으로 왼쪽 테이블이 더 큰(팩트) 테이블이고 오른쪽 테이블이 더 작은(차원) 테이블이라고 가정합니다. 이 가정은 연산자가 사용하는 가정과 정확히 반대입니다 join .
union 연산자는 둘 이상의 테이블에서 모든 행을 반환합니다. 여러 테이블의 데이터를 결합하려는 경우에 유용합니다.
materialize() 함수는 쿼리에서 후속 재사용을 위해 쿼리 실행 내에서 결과를 캐시합니다. 이는 하위 쿼리 결과의 스냅샷을 만들고 쿼리 내에서 여러 번 사용하는 것과 같습니다. 이 함수는 결과가 있는 시나리오에 대한 쿼리를 최적화하는 데 유용합니다.
- 컴퓨팅 비용이 많이 듦
- 비결정적임
잠시 후 다양한 테이블 병합 연산자와 함수 및 materialize() 사용 방법에 대해 자세히 알아봅니다.
조인 종류
결과 테이블의 스키마 및 행에 영향을 주는 다양한 종류의 조인을 수행할 수 있습니다. 다음 표에서는 반환하는 Kusto 쿼리 언어 및 스키마 및 행에서 지원하는 조인의 종류를 보여 줍니다.
| 조인 종류 | Description | 그림 |
|---|---|---|
innerunique(기본값) |
왼쪽 중복 제거를 사용하는 내부 조인 스키마: 일치하는 키를 포함하여 두 테이블의 모든 열 행: 왼쪽 테이블의 중복 제거된 모든 행이 오른쪽 테이블의 행과 일치 |
|
inner |
표준 내부 조인 스키마: 일치하는 키를 포함하여 두 테이블의 모든 열 행: 두 테이블에서 일치하는 행만 |
|
leftouter |
왼쪽 우선 외부 조인 스키마: 일치하는 키를 포함하여 두 테이블의 모든 열 행: 왼쪽 테이블의 모든 레코드와 오른쪽 테이블의 행만 |
|
rightouter |
오른쪽 우선 외부 조인 스키마: 일치하는 키를 포함하여 두 테이블의 모든 열 행: 오른쪽 테이블의 모든 레코드와 왼쪽 테이블의 행만 |
|
fullouter |
완전 외부 조인 스키마: 일치하는 키를 포함하여 두 테이블의 모든 열 행: 일치하지 않는 셀이 null로 채워진 두 테이블의 모든 레코드 |
|
leftsemi |
왼쪽 우선 세미 조인 스키마: 왼쪽 테이블의 모든 열 행: 오른쪽 테이블의 레코드와 일치하는 왼쪽 테이블의 모든 레코드 |
|
leftanti, , antileftantisemi |
왼쪽 안티 조인 및 세미 변형 스키마: 왼쪽 테이블의 모든 열 행: 오른쪽 테이블의 레코드와 일치하지 않는 왼쪽 테이블의 모든 레코드 |
|
rightsemi |
오른쪽 우선 세미 조인 스키마: 오른쪽 테이블의 모든 열 행: 왼쪽 테이블의 레코드와 일치하는 오른쪽 테이블의 모든 레코드 |
|
rightanti, rightantisemi |
오른쪽 안티 조인 및 세미 변형 스키마: 오른쪽 테이블의 모든 열 행: 왼쪽 테이블의 레코드와 일치하지 않는 오른쪽 테이블의 모든 레코드 |
|
기본 조인 종류는 innerunique지정될 필요가 없습니다. 그럼에도 불구하고 명확성을 위해 항상 조인 종류를 명시적으로 지정하는 것이 좋습니다.
이 모듈을 진행하면서 집계 함수, arg_max()as 문 대신 let 연산자 및 startofmonth() 월별 데이터 그룹화를 지원하는 함수에 대해서도 arg_min() 알아봅니다.