Datawarehouse 중복 치수 행

이벤트 로그의 데이터로 데이터웨어 하우스를로드하기 시작했습니다. 팩트 테이블의 행이 하나의 이벤트를 나타내는 일반적인 스타 스키마가 있습니다. 우리가 ID를 자동 생성Datawarehouse 중복 치수 행

create table referal_dim(
    id integer, 
    domain varchar(255), 
    subdomain varchar(255), 
    page_name varchar(4096), 
    query_string varchar(4096) 
    path varchar(4096) 
)

결국 사실 테이블에 대해 가입 : 우리의 차원 테이블은 하나 개의 차원 테이블이 보이는 등 USER_AGENT, IP, referal, 페이지의 전형적인 조합입니다. 제 질문은 대량로드 프로세스에서 중복 레코드를 식별하는 가장 좋은 방법은 무엇입니까? 영구 저장소에 실제로 삽입하기 전에 로그 파일의 모든 레코드를 임시 테이블에 업로드하지만 ID는 자동으로 증가하므로 2 일 동안 동일한 두 개의 희미한 레코드가 서로 다른 ID를 갖습니다. 값 열의 해시를 만드는 것이 적절할 것이라고 생각하고 비교하려고합니다. 각 값 열을 비교하려고 시도하는 것이 느린 것 같습니다. 이와 같은 상황에 대한 모범 사례가 있습니까?

출처

2009-11-12 igkins

SQL Server는 어떤 플랫폼을 사용하고 있습니까? 신탁? MySql? 번역? – chadhoc

그는 Vertica를 사용하고 있지만 사실 테이블에 참조를 유지하면서 들어오는 데이터를 차원 테이블로 정규화하는 방법을 묻고 있다고 생각합니다. 특정 행렬에 이미 차원이 존재하는지 알아보기 위해 행마다 조회를 수행하면 수백만 행에 도달하면 매우 느려질 것입니다. 기본 키를 생성하기 위해 열을 해싱하는 것은 실행 가능한 솔루션 일 수 있지만 생일 패러독스와 가능한 충돌에 대해 걱정해야합니다. –

대리 키 PK의 자동 증가 정수는 괜찮지 만 (Kimball에 따르면) 차원 테이블에도 자연 키가 있어야합니다. 따라서 해시 NaturalKey 열이 순서대로 지정되며 Status "현재"또는 "만료 됨"열이 SCD 유형 2를 허용하는 데 유용 할 수 있습니다.

출처

2009-11-13 03:58:54

멋지다, 해시 된 자연 키는 우리가 대리 ID와 함께 할 생각 이었지만, 우리는 성능 상충 관계가 무엇인지 확신 할 수 없었다. – igkins

로드 성능을 향상 시키려면 자연스러운 키와 테이블의 최신 기본 키를 일치시키는 (NaturalKey, PrKey) 차원의 키 일치 테이블을 유지 관리 (재로드 후 다시 작성) 할 수 있습니다. 로드하는 동안 KeyMatchingTable에서 기본 키를 조회하는 것보다 레코드에 해시 컬럼을 추가하십시오. 발견되지 않으면 새로운 레코드이므로 삽입 용으로 준비하십시오. 발견되면 이미 존재 함을 의미하므로 무엇을 해야할지 결정하십시오 (폐기, SC1 또는 SC2). 그런 다음 치수 표를로드하십시오. –

Datawarehouse 중복 치수 행

답변

관련 문제