Foundry 스트림에서는 하나 이상의 열을 키 열로 지정하고 기본 키를 사용하여 해결된 레코드를 식별할 수 있습니다. 아래 섹션에서는 스트리밍 파이프라인의 파티션과 기본 키를 설정하고 유지 관리하는 방법에 대해 설명합니다.
일반적으로 Palantir 플랫폼의 기본 키는 데이터베이스 레코드를 고유하게 식별하는 데 사용됩니다. 그러나 Foundry 스트림에서 파티션 키는 동일한 키를 가진 레코드를 그룹화합니다. 예를 들어 특정 장치의 모든 리딩 또는 특정 고객의 모든 거래입니다. 스트림의 파티션 키는 기록을 고유하게 식별하지 않기 때문에 일괄 파이프라인의 기본 키와 달리 레코드 중복을 제거하지 않습니다.
Foundry의 키를 사용하면 사용자가 특정 키에 대한 모든 레코드가 순서를 유지하도록 할 수 있습니다. 레코드가 Foundry에 입력되면 내부적으로 Kafka에 저장됩니다. Kafka는 동일한 파티션에 쓰여진 레코드가 읽기와 쓰기에서 순서를 유지하도록 보장합니다. 키 없이 레코드가 Foundry로 전송되면 레코드는 내부 Kafka 토픽의 모든 파티션에 라운드 로빈 방식으로 작성됩니다. 그러나 사용자가 레코드에 대해 키를 지정하면 레코드가 해당 키에 대한 전용 파티션에 작성되어 다운스트림에서 소비될 때 순서가 유지됩니다.
마찬가지로 Flink 스트리밍 작업은 입력 소스에서 설정된 파티션 키 열을 기준으로 자동으로 정렬을 유지합니다. Flink 변환 작업은 변환 작업당 하나 이상의 병렬 파티션으로 실행될 수 있습니다. 파티션 키가 있는 입력 스트림의 경우 Flink 작업은 모든 키 열의 값이 동일한 모든 레코드를 동일한 병렬 작업자 인스턴스로 자동으로 전송합니다. 특별히 재키 설정하지 않는 한(Key by 변환과 같이), 파이프라인의 전체 길이에 대한 파티셔닝과 정렬은 원본에서 키 열과 행 값에 따라 결정됩니다. 변환 로직이 열을 삭제하거나 값을 덮어쓰더라도.
Foundry 스트림의 기본 키는 관계형 데이터베이스 및 일괄 데이터셋에서 사용되는 기본 키와 유사한 방식으로 작동합니다. 그러나 스트리밍 기본 키는 해결된 레코드를 고유하게 식별하는 중복 제거 열 집합으로 구성되며 순서 지정 열을 지정하지 않습니다.
기본 키는 Foundry 스트림의 스키마에 있는 메타데이터 조각입니다. 키는 저장된 데이터의 내용이나 스트리밍 데이터 파이프라인 및 변환의 적용 방식에 영향을 주지 않습니다. 기본 키는 일부 Foundry 소비자가 데이터를 읽는 방법을 제어합니다. 전체 데이터는 변경 로그로 생각할 수 있으며, 기본 키는 모든 변경 사항을 적용한 후 중복 제거된 현재 뷰를 계산하는 방법을 소비자에게 알려줍니다.
현재 뷰는 최근에 스트리밍된 각 키에 대한 레코드만 포함하는 데이터의 필터링된 뷰입니다. 키에 대한 가장 최근 레코드가 null을 포함하더라도 항상 유지됩니다. 삭제된 열이 지정된 경우, 키에 대한 가장 최근에 스트리밍된 레코드가 이 값을 true로 설정하면 레코드가 필터링됩니다.
다음 예제는 기본 키와 데이터 스트림을 보여주며, 테이블에서 가장 최근에 스트림된 행이 더 높습니다.
기본 키: {Dedeuplication column(s): [Key], isDeletedColumn: Optional[isDeleted]}
| Key | Value | isDeleted |
|---|---|---|
| Key2 | null | false |
| Key1 | thirdVal | true |
| Key2 | secondVal | false |
| Key1 | firstVal | false |
CDC를 인식하는 소비자가 읽는 이러한 변경 로그 스트림은 다음 현재 뷰로 읽힙니다:
| Key | Value | isDeleted |
|---|---|---|
| Key2 | null | false |
스트리밍 데이터에 기본 키를 설정하려는 경우, 파티션 키로 동일한 열을 설정해야 순서를 유지하고 중복 제거된 데이터 뷰를 올바르게 해결할 수 있습니다. 기본 키를 스트리밍 설정 인터페이스에 설정하면 동일한 열이 자동으로 파티션 키 열로 추가됩니다.
다음 두 개의 CDC를 인식하는 작업은 기본 키가 있는 스트리밍 데이터를 현재 뷰로 자동으로 읽습니다:
Pipeline Builder는 파이프라인 변환을 통해 파티션 키와 기본 키 열의 진화를 추적하고 출력 스트림의 스키마에 유효한 키를 작성합니다. 변환 작업이 키 열을 무효화하지 않으면 동일한 파티셔닝 및 중복 제거 지침이 다운스트림 파이프라인의 연속에서 자동으로 유지됩니다.
키 열의 이름을 변경하면 키가 새 열 이름을 포함하도록 업데이트됩니다. 마찬가지로 키 열을 제거하거나 덮어쓰는 변환을 적용하면 해당 열이 키에서 제거됩니다. 키 열 내용의 덮어쓰기는 새로운 정렬 보장이나 새로운 중복 제거 전략을 나타낼 수 있으므로 Pipeline Builder는 키에서 열을 완전히 삭제합니다. 이전에 덮어쓰기된 키 열을 유지하려면 Key by 변환을 다시 적용해야 합니다. 파티션 키 열이 삭제 또는 덮어쓰기로 인해 삭제되더라도 나머지 파이프라인에 대한 동일한 정렬 보장이 유지됩니다. 재키 지정하지 않는 한.
모든 파티션 키 또는 중복 제거 CDC 키가 삭제되거나 덮어쓰여지면 키가 완전히 삭제됩니다. 키 열의 내용을 삭제하거나 덮어쓸 때 주의하세요. 이렇게 하면 예기치 않은 결과가 발생할 수 있으며, 정렬 보장이나 중복 제거 전략을 잃을 수 있습니다.
현재 키는 사용자 정의 함수(UDF)에 대해 결코 전파되지 않습니다. 함수가 사용자 정의이므로 사용자가 의도하는 키 전파 전략이 없습니다. 키를 전파하려는 경우 UDF 다음에 Key by 변환을 적용하세요.
또한 상태 있는 변환(대부분의 변환은 상태가 없음)에 대한 기본 키가 전파되지 않습니다.
Pipeline Builder 애플리케이션의 스트리밍 파이프라인에서 그래프에 Key by 변환을 추가하세요. 주목할 점은 여기에서 설정한 모든 키는 입력 데이터에 있던 키를 대체하고 교체합니다.
파티션 키만 설정하려는 경우 CDC 모드 옵션을 끄고 Key by columns 목록만 제공하세요. 다른 매개변수는 CDC 모드에서만 필요하거나 허용됩니다.
기본 키와 파티션 키를 모두 설정하려면 CDC 모드 옵션을 켜세요. isDeleted 열이 있는 경우 Primary key is deleted 필드에 선택적으로 지정하세요. 스트리밍 사용 사례의 경우 선택적 Primary key ordering columns 매개변수를 공백으로 두는 것이 좋습니다. 변환은 파티션 키 열이 기본 키 중복 제거 열과 동일한 기본 키와 파티션 키를 설정합니다. Primary key ordering columns 매개변수는 아카이브 데이터셋을 일괄 작업에서 소비할 때만 중요하며 스트리밍이 중복 제거에 대해 어떻게 생각하는지에 영향을 주지 않습니다. 정렬 열을 지정할 수 있는 옵션은 이전 호환성, 일괄 변환 사용자 또는 스트림 아카이브를 특정 일괄 작업 전용 방식으로 소비하려는 사용자를 위해 제공됩니다.
다음 섹션에서는 Foundry 스트림에서 스트리밍 키 로직을 찾고 확인하는 방법에 대해 설명합니다.
스트리밍 데이터셋을 열고 Details 탭으로 이동한 다음 Schema 탭을 열어 JSON 형식의 데이터 스키마를 확인합니다.
기본 키의 일부인 각 열의 fieldSchemaList 요소에 나타나는 includeInParitioning을 검색합니다.
"customMetadata": {
"includeInPartitioning": true
// 파티셔닝에 포함시키기: 참
}
스트림이 키가 없고 데이터가 저장되거나 처리되는 방식에 대한 순서가 보장되지 않는 경우 includeInParitioning과 함께 스키마 필드를 볼 수 없습니다. 수동으로 키를 추가하려면 JSON 텍스트로 스키마를 편집하고 사용자 정의 메타데이터(위에서 설명한 대로)를 파티션 키 열로 설정하려는 각 스키마 필드(열)에 삽입합니다.
스트림에 이미 하나 이상의 파티션 키가 있는 경우, 새 파티션 키 열을 추가하면 더 많은 파티션 때문에 약한 정렬 보장이 발생합니다. 순서는 모든 파티션 키 열에 대해 동일한 값을 공유하는 행에 대해서만 유지되는 것이 보장됩니다.
배포 전에 파이프라인의 입력 스트림에 파티션 키 열이 설정되면 해당 소스와 모든 변환에 대한 순서가 전체 파이프라인에 대해 보장되며, 의도적으로 다시 키를 설정하지 않는 한 유지됩니다. 파티션 키 열은 데이터 미리보기에서 키 기호로 표시될 수 있습니다.
스트리밍 데이터셋을 열고 Details 탭으로 이동한 다음 Schema 탭을 열어 JSON에서 데이터 스키마를 확인합니다.
primaryKey라는 JSON 속성을 볼 수 있습니다. 스트림에 uniqueCol1 및 uniqueCol2라는 중복 제거 열이 있고 isDeleted 열이 isDeletedCol인 경우, 스키마는 다음과 같이 표시됩니다:
"primaryKey": {
"columns": [
"uniqueCol1", // 고유한 열1
"uniqueCol2" // 고유한 열2
],
"resolution": {
"type": "duplicate", // 중복 해결 타입
"duplicate": {
"resolutionStrategy": { // 해결 전략
"type": "customStrategy", // 사용자 정의 전략 타입
"customStrategy": {} // 사용자 정의 전략 설정
},
"deletionColumn": "isDeletedCol" // 삭제된 열 확인
}
}
}
주요 키가 설정되지 않은 경우, 스키마에 null이 표시됩니다:
"primaryKey": null // 기본키: 없음
기본 키를 수동으로 설정하거나 제거하려면 스키마 JSON을 편집하여 위의 형식에 따라 키를 지정하거나 null을 사용하여 키를 제거할 수 있습니다. 기본 키를 수동으로 설정하는 경우, 분할 키 컬럼으로 동일한 컬럼을 설정하는 것을 강력히 권장합니다.
정렬을 보장하는 유일한 방법은 전체 스트리밍 리니지에 분할 키 컬럼을 설정하는 것입니다. 설정하면 분할 키 컬럼이 자동으로 다운스트림에 전파됩니다. 스트림이 단 하나의 파티션만 갖도록 설정되어 있더라도, Flink 애플리케이션의 확장 방식과 비결정적 레코드 처리 방식 때문에 정렬이 반드시 보장되는 것은 아닙니다.
파티션 키를 신중히 선택하세요. 비효율적으로 분산된 레코드를 생성하는 키는 인위적으로 부하를 증가시키고 처리량을 제한할 수 있습니다. 만약 정렬이 유즈케이스에 중요하다면, 이메일 ID, 고객 ID, 그룹 ID와 같은 일반적인 그룹 식별자에 파티션 키를 설정하세요. 정렬이 유즈케이스에 중요하지 않다면, 고유 ID를 키로 사용하거나 스트림에 키를 전혀 사용하지 않을 수도 있습니다.
최종 스트리밍 결과물의 정렬 보장은 스트리밍 시리즈(카프카 주제에 의해 지원됨)와 변환(Flink 작업) 중 가장 약한 보장에 따라 결정됩니다. 따라서 원하는 정렬이 유지되고 올바른 파티션 키가 Foundry로 레코드를 가져오는 초기 스트리밍 추출부터 전체 Data Lineage에 설정되어 있는지 확인하세요. 정렬 보장은 Foundry로 추출하는 시스템보다 강하지 않을 것입니다. 예를 들어, 카프카에서 추출하기 위해 카프카 커넥터를 사용하는 경우, 카프카 키 컬럼과 동일하게 파티션 키 컬럼을 설정하여 Foundry가 시스템에서 동등한 정렬 보장을 유지할 수 있도록 합니다.
또한, 데이터 변환 시리즈 중에 파티션 컬럼(그리고 정렬 보장)을 완전히 변경하면 문제가 발생할 수 있습니다. 새로운 Key by 변환을 적용하기 전에 다른 정렬이 보장되었다면, 변환은 새로 추가된 키 컬럼에서 순서가 뒤바뀐 레코드를 받게 될 것이며; 이 레코드들은 변환 시리즈 동안 잘못된 순서를 유지하게 됩니다.