재빌드에도 유지되는 식별자 만들기
데이터셋이나 온톨로지 객체의 ID는 같은 업무 레코드를 여러 빌드에서 같은 대상으로 식별할 수 있어야 합니다. 데이터가 같아도 실행 순서에 따라 ID가 바뀌면 비교, 중복 해소와 증분 갱신이 어려워집니다.
문자열 결합과 SHA-256
권장 방식은 레코드를 고유하게 식별하는 문자열 열들을 결합한 뒤 Hash sha256을 적용하는 것입니다.
- 조합하면 레코드를 식별할 수 있는 열을 고릅니다.
- 열의 순서, 문자열 표현과 구분 방식을 고정하여 한 문자열로 만듭니다.
Hash sha256으로 256비트 해시를 계산합니다. 결과는 64자리 16진수 문자열로 표현할 수 있습니다.
화면 예시는 scope와 file을 -로 결합합니다. 구분자가 실제 값 안에도 나타날 수 있으면 서로 다른 열 조합이 같은 문자열이 되지 않도록 직렬화 규칙을 정해야 합니다. 예를 들어 a-b와 c의 조합, a와 b-c의 조합을 단순히 하이픈으로 연결하면 구별할 수 없습니다. 구분자가 입력에 없다는 조건을 보장하거나 일관된 이스케이프 및 길이 구분을 사용해야 합니다.
같은 입력 문자열은 같은 해시를 만들므로 재빌드와 분산 실행에서도 같은 ID를 독립적으로 계산할 수 있습니다. 중앙의 순번 발급 없이 여러 작업이 동시에 생성할 수 있다는 이점이 있습니다.
해시는 입력의 고유성을 만들어 주지 않습니다. 같은 식별 열 조합은 같은 ID가 되므로 원천 키의 고유성과 null 처리 기준을 먼저 정합니다. 해시 충돌 가능성이 완전히 없어지는 것도 아니며, 해시를 만들었다는 사실만으로 민감한 원천값이 익명화되거나 비밀로 보호되는 것은 아닙니다.
결정적인 UUID V5
표준 UUID 형태가 필요하면 namespace UUID와 name 문자열로 UUID V5를 만들 수 있습니다. UUID V5는 SHA-1 기반의 이름 결정 방식이며 RFC 4122에 정의된 식별자 형식입니다.
- 데이터 도메인을 나타낼 namespace UUID를 정합니다. 표준 namespace를 사용하거나 자체 namespace를 만들 수 있습니다.
- 식별 열들을 일관되게 결합하여 name 문자열을 만듭니다.
UUID V5표현식을 적용합니다.
같은 namespace와 name이면 같은 UUID가 생성됩니다. 다른 시스템이 UUID를 기대할 때 호환되는 형식을 제공하며 분산된 작업에서도 같은 입력으로 독립 생성할 수 있습니다. namespace나 name 구성 규칙을 바꾸면 ID도 달라지므로 출력 계약으로 관리합니다.
단조 증가 ID의 제약
Pipeline Builder는 단조 증가 ID 생성 방식을 지원하지 않습니다. Spark의 monotonically_increasing_id()는 파티션 식별자와 파티션 안의 레코드 번호에 의존하므로 같은 입력도 재실행의 파티션 배치가 바뀌면 다른 ID를 얻을 수 있습니다.
이 함수의 결과는 단조 증가하는 고유 정수이지만 1, 2, 3처럼 연속되는 번호는 아닙니다. 행과 파티션의 실행 상태에 의존하는 번호를 지속적인 업무 ID로 사용하면 빌드 비교와 증분 갱신이 어려워집니다. 온톨로지 기본 키가 매번 바뀌면 객체를 안정적으로 갱신하지 못하고 전체 재인덱싱 부담을 만들 수 있습니다.
고유한 원천 열 조합이 없는 경우
안정적인 키를 찾을 수 없는 경우의 마지막 수단으로 난수를 문자열로 바꾼 뒤 해시를 만들 수 있습니다.
Uniform random number로 값을 생성합니다.Cast로 String으로 바꿉니다.Hash sha256을 적용합니다.
이 ID는 빌드와 미리보기 사이에서 일관되지 않습니다. 난수의 seed를 지정해도 분산 실행에서 각 행이 난수 수열의 어느 값을 받는지 일정하지 않아 레코드별 안정성을 보장하지 않습니다. 같은 난수를 다시 얻으면 해시도 같으므로 고유성 검사가 별도로 필요합니다.
하위 사용자가 ID의 안정성을 기대하는지, 특히 객체 기본 키나 외부 참조로 사용하는지 확인한 뒤 선택합니다.