익스텐트(데이터 분할)

개요

Kusto는 엄청난 수의 레코드(행) 및 많은 양의 데이터가 있는 테이블을 지원하도록 빌드되었습니다. 이러한 큰 테이블을 처리하기 위해 각 테이블의 데이터는 데이터 분할 또는 익스텐 트(두 용어는 동의어)라고 하는 작은 "청크"로 나뉩니다. 모든 테이블 익스텐트의 합합은 테이블의 데이터를 보유합니다. 개별 익스텐트 크기는 단일 노드의 용량보다 작게 유지되며, 익스텐트 범위는 클러스터의 노드에 분산되어 스케일 아웃을 달성합니다.

익스텐트도 미니 테이블 형식과 같습니다. 여기에는 데이터 및 메타데이터 및 생성 시간 및 데이터와 연결된 선택적 태그와 같은 정보가 포함됩니다. 또한 익스텐트에서는 일반적으로 Kusto가 데이터를 효율적으로 쿼리할 수 있는 정보를 보유합니다. 예를 들어 익스텐트 내 데이터의 각 열에 대한 인덱스 및 열 데이터가 인코딩된 경우 인코딩 사전이 있습니다. 따라서 테이블의 데이터는 테이블 익스텐트의 모든 데이터 통합입니다.

익스텐트는 변경할 수 없으며 수정할 수 없습니다. 쿼리하거나, 다른 노드에 다시 할당하거나, 테이블에서 삭제할 수 있습니다. 데이터 수정은 하나 이상의 새 익스텐트 만들기 및 트랜잭션 방식으로 이전 익스텐트와 새 익스텐트 교환을 통해 발생합니다.

익스텐트에서는 열에 물리적으로 정렬된 레코드 컬렉션을 보유합니다. 이 기술을 열 형식 저장소라고 합니다. 동일한 열의 다른 값이 서로 "유사"하는 경우가 많기 때문에 데이터를 효율적으로 인코딩하고 압축할 수 있습니다. 또한 쿼리에서 사용하는 열만 로드해야 하므로 대규모 데이터 범위를 쿼리하는 것이 더 효율적입니다. 내부적으로 익스텐트 내 데이터의 각 열은 세그먼트로 세분화되고 세그먼트는 블록으로 세분화됩니다. 이 구분은 쿼리에서 관찰할 수 없으며 Kusto에서 열 압축 및 인덱싱을 최적화할 수 있습니다.

쿼리 효율성을 유지하기 위해 더 작은 익스텐트도 더 큰 범위로 병합됩니다. 병합은 구성된 병합 정책분할 정책에 따라 백그라운드 프로세스로 자동으로 수행됩니다. 익스텐트 병합은 추적할 익스텐트 수가 많은 관리 오버헤드를 줄입니다. 더 중요한 것은 Kusto가 인덱스를 최적화하고 압축을 개선할 수 있게 해줍니다.

익스텐트 병합은 익스텐트 크기와 같은 특정 한도에 도달하면 중지됩니다. 특정 시점을 초과하면 병합이 효율성을 높이는 대신 감소하기 때문입니다.

테이블에 데이터 분할 정책이 정의되면 익스텐트 생성 후(수집 후) 다른 백그라운드 프로세스를 거칩니다. 이 프로세스는 원본 익스텐트에서 데이터를 다시 수집하고 테이블의 파티션 키인 열 값이 모두 동일한 파티션에 속하는 동종 익스텐트(익스텐트)를 만듭니다. 정책에 해시 파티션 키가 포함된 경우 동일한 파티션에 속하는 모든 동종 익스텐트는 클러스터의 동일한 데이터 노드에 할당됩니다.

참고

익스텐트 태그 병합 또는 변경과 같은 익스텐트 수준 작업은 기존 익스텐트 수정을 하지 않습니다. 대신 기존 원본 익스텐트 기반의 이러한 작업에 새 익스텐스가 만들어집니다. 새 익스텐트에서는 단일 트랜잭션에서 해당 선조를 대체합니다.

일반적인 범위 수명 주기는 다음과 같습니다.

  1. 익스텐트를 수집 작업으로 만듭니다.
  2. 익스텐트도 다른 익스텐트와 병합됩니다. 병합되는 범위가 작으면 Kusto는 실제로 다시 빌드라는 수집 프로세스를 수행합니다. 익스텐트 크기가 특정 크기에 도달하면 인덱스에 대해서만 병합이 수행됩니다. 스토리지에 있는 익스텐트의 데이터 아티팩트가 수정되지 않습니다.
  3. 병합된 익스텐트(계보를 다른 병합된 익스텐트 등으로 추적하는 익스텐트)는 보존 정책으로 인해 결국 삭제됩니다. 시간(이전 x시간/일)에 따라 익스텐트 삭제 시 병합된 익스텐트 내의 최신 익스텐트 생성 날짜가 계산에 사용됩니다.

익스텐트 생성 시간

각 익스텐트에서 가장 중요한 정보 중 하나는 생성 시간입니다. 이 시간은 다음과 같은 용도로 사용됩니다.

  1. 보존 - 이전에 만든 익스텐트 이전에 삭제됩니다.
  2. 캐싱 - 최근에 만든 익스텐트 핫 캐시에 유지됩니다.
  3. 샘플링 - 다음과 같은 쿼리 작업을 사용할 때 최근 익스텐트 선호 take

실제로 Kusto는 익스텐트당 두 datetime 값과 MaxCreatedOn. MinCreatedOn 처음에는 두 값이 동일합니다. 익스텐트와 다른 익스텐트와 병합되는 경우 새 값은 병합된 익스텐트에서 원래의 최소값과 최대값에 따라 다릅니다.

일반적으로 익스텐트의 생성 시간은 익스텐트의 데이터가 수집되는 시간에 따라 설정됩니다. 클라이언트는 필요에 따라 수집 속성에 대체 생성 시간을 제공하여 익스텐트의 생성 시간을 덮어쓸 수 있습니다. 덮어쓰기는 예를 들어 클라이언트가 데이터를 다시 수집하려고 하고 늦게 도착한 것처럼 표시하지 않으려는 경우 보존 목적으로 유용합니다.

익스텐트 태그 지정

Kusto는 해당 메타데이터의 일부로 익스텐트에 여러 선택적 익스텐트 태그 를 연결할 수 있도록 지원합니다. 익스텐트 태그(또는 단순히 태그)는 익스텐트와 연결된 문자열입니다. .show 익스텐트 명령을 사용하여 익스텐트와 연결된 태그와 extent-tags() 함수를 사용하여 레코드와 연결된 태그를 익스텐트에서 볼 수 있습니다. 익스텐트 태그를 사용하여 익스텐트 내의 모든 데이터에 공통적인 속성을 효율적으로 설명할 수 있습니다. 예를 들어 수집 중에 수집된 데이터의 원본을 나타내는 익스텐트 태그를 추가하고 나중에 해당 태그를 사용할 수 있습니다. 익스텐트에서 데이터를 설명하기 때문에 둘 이상의 병합 시 연결된 태그도 병합됩니다. 결과 익스텐트의 태그는 병합된 익스텐트의 모든 태그의 합집합이 됩니다.

Kusto는 값에 접사 형식이 있는 모든 익스텐트 태그에 특별한 의미를 할당합니다. 여기서 접두사는 다음 중 하나입니다.

  • drop-by:
  • ingest-by:

'drop-by:' 익스텐트 태그

접두사로 시작하는 태그를 drop-by: 사용하여 병합할 다른 범위를 제어할 수 있습니다. 태그 집합이 동일한 익스텐트도 함께 병합할 수 있지만 다른 태그 집합 drop-by:drop-by: 이 있는 경우 다른 익스텐트에서는 병합되지 않습니다.

1. 함께 병합할 수 있는 익스텐트

경우:

  • 익스텐트 1에는 다음과 같은 태그가 있습니다. drop-by:bluedrop-by:redgreen
  • 익스텐트 2에는 다음과 같은 태그가 있습니다. drop-by:redyellow
  • 익스텐트 3에는 다음 태그가 있습니다. purpledrop-by:reddrop-by:blue

그렇다면

  • 익스텐트 1과 2는 서로 다른 태그 집합 drop-by 이 있으므로 함께 병합되지 않습니다.
  • 익스텐트 2와 3은 서로 다른 태그 집합 drop-by 을 가지므로 함께 병합되지 않습니다.
  • 익스텐트 1과 3은 동일한 태그 집합 drop-by 을 가지므로 함께 병합할 수 있습니다.

2. 익스텐트 수준 작업의 일부로 태그 사용 drop-by

태그에 따라 drop-by: 익스텐트 삭제 명령을 실행할 수 있습니다.

.ingest ... with @'{"tags":"[\"drop-by:2016-02-17\"]"}'

.drop extents <| .show table MyTable extents where tags has "drop-by:2016-02-17" 

경고

  • 태그를 과도하게 사용하지 drop-by 마세요. 위에서 언급한 방식으로 데이터를 삭제하는 것은 거의 발생하지 않는 이벤트를 위한 것입니다.
    • 레코드 수준 데이터를 바꾸는 데 사용하면 안 되며, 이러한 방식으로 태그가 지정된 데이터가 부피가 큰 사실에 의존합니다.
    • 각 레코드, 적은 수의 레코드 또는 파일에 고유한 태그를 지정하려고 하면 성능에 심각한 영향을 줄 수 있습니다.
  • 데이터를 수집한 후 일정 기간 동안 태그가 필요하지 않은 경우 drop-by태그를 삭제하는 것이 좋습니다.

'수집 기준:' 익스텐트 태그

접두사로 시작하는 태그를 ingest-by: 사용하여 데이터가 한 번만 수집되도록 할 수 있습니다. 이 특정 ingest-by: 태그가 ingestIfNotExists 있는 범위가 이미 있는 경우 데이터가 수집되지 않도록 하는 속성 명령을 실행할 수 있습니다. 둘 다 tags 에 대한 값이며 ingestIfNotExists JSON으로 직렬화된 문자열 배열입니다.

다음 예제에서는 데이터를 한 번만 수집합니다. 2번째 및 3번째 명령은 아무 것도 수행하지 않습니다.

.ingest ... with (tags = '["ingest-by:2016-02-17"]')

.ingest ... with (ingestIfNotExists = '["2016-02-17"]')

.ingest ... with (ingestIfNotExists = '["2016-02-17"]', tags = '["ingest-by:2016-02-17"]')

참고

일반적으로 수집 명령은 위의 세 번째 명령과 같이 동일한 값으로 설정된 태그와 ingestIfNotExists 속성을 모두 ingest-by: 포함할 수 있습니다.

경고

  • 태그를 ingest-by 과도하게 사용하는 것은 권장되지 않습니다.
  • Kusto를 공급하는 파이프라인에 데이터 중복이 있는 것으로 알려진 경우 Kusto로 데이터를 수집하기 전에 이러한 중복을 가능한 한 많이 해결하는 것이 좋습니다.
  • 각 수집 호출에 대해 고유한 ingest-by 태그를 설정하려고 하면 성능에 심각한 영향을 미칠 수 있습니다.
  • 데이터가 수집된 후 일정 기간 동안 이러한 태그가 필요하지 않은 경우 익스텐트 태그를 삭제하는 것이 좋습니다.