데이터웨어 하우스의 스테이징 영역 내 구조

Question

우리는 은행 용 데이터웨어 하우스를 작업 중이며 스테이징 테이블, 스타 스키마 및 ETL의 표준 Kimball 모델을 거의 준수하여 프로세스를 통해 데이터를 가져 왔습니다.

Kimball은 데이터를 스타 스키마에 넣을 준비가 될 때까지 가져 오기, 치료, 처리 및 모든 작업을위한 준비 영역 사용에 대해 이야기합니다. 실제로 이것은 일반적으로 원본에서 수정 사항이 거의 또는 전혀없는 표 집합으로 데이터를 업로드 한 다음 별표 스키마로 이동할 준비가 될 때까지 중간 표를 통해 데이터를 선택적으로 가져 오는 것을 의미합니다. 그것은 단일 엔티티에 대한 많은 작업입니다. 여기서는 하나의 책임이 없습니다.

이전 시스템 내가 가진의 범위, 테이블의 다른 세트 사이의 구분을 한에 일한 :

• 업로드 테이블 :
• 수정되지 않은 원시 소스 시스템의 데이터를, 스테이징 테이블 : 중간 처리, 유형화 및 클렌징
• 웨어 하우스 테이블

당신은 별도의 스키마에이 충실하고 아카이브/백업/보안 등 StagingInput가있는 곳에 다른 사람의 하나는 창고에 근무하고있다과 StagingOutput, 비슷한 이야기에 대한 서로 다른 정책을 적용 할 수 있습니다 . 팀 전체는 데이터웨어 하우스와 그렇지 않은 경우 모두 많은 경험을 가지고 있습니다.

그러나이 모든 경우에도 불구하고 Kimball과 웹을 살펴보면 스테이징 데이터베이스에 어떤 종류의 구조를 부여하는 것에 대해 서면으로는 전혀없는 것처럼 보입니다. 킴볼이 우리 모두가이 엄청나게 깊은 어둠의 구조화되지 않은 데이터 풀로 발걸음을 옮겨 다닐 것이라고 믿는다면 용서받을 수 있습니다.

물론 스테이징 영역에 구조를 추가하고 싶다면 어떻게해야하는지 분명히 분명하지만, 그것에 대해 쓰여진 것도없는 것처럼 보입니다.

그래서 다른 사람들은 무엇을하고 있습니까? 이 큰 구조화되지 않은 난장판을 준비하고 있습니까? 아니면 민속에 재미있는 디자인이 있습니까?

Answer 1

동일한 문제가 발생했습니다. 우리는 대규모 HR 데이터웨어 하우스를 보유하고 있으며 기업 전체에서 시스템의 데이터를 가져오고 있습니다. 사실과 차원 테이블의 훌륭한 콜렉션을 가지고 있지만, 스테이징 영역은 엉망입니다.나는 이것에 대한 어떤 기준도 모르고있다. 나는 당신이하고있는 것과 동일한 길을 따라 가고 일들을 순서대로 지키기 위해 표준 이름을 생각해냅니다. 당신의 제안은 명명에 꽤 좋습니다. 나는 그걸로 계속 일 할거야.

Answer 2

개인적으로 나는 킴볼이나 다른 곳에서 문제를 찾으러 가지 않습니다.

어떤 종류의 "구조"를 찾고 계십니까? 어떤 종류의 "구조"가 필요하다고 느끼십니까? 오늘날 당신이 갖고있는 "구조"의 부족으로 인해 어떤 문제가 있습니까?

나는 Kimball을별로 생각하지 않는다는 인상을 남기고 있습니다. 그렇지 않습니다. 나는 킴볼을 읽지 않았습니다. 나는 어떤 패턴을 맞추지 않고 아무 이유없이 변화하는 것을별로 생각하지 않습니다. 실세계의 문제를 해결하기위한 변화는 괜찮을 것이다. 예를 들어, 구조가 부족하여 스테이징 및웨어 하우스 테이블이 동일하게 취급되기 때문에 스테이징 테이블을 백업하는 경우 구조가 변경 될 수 있습니다. 그러나 그것이 당신이 염두에 두었던 일이라면 질문을 편집하여 그것을 나타내야합니다.

Answer 3

스테이징에는 하위 영역이있을 수 있습니다. 예를 들어 staging1, staging2라고합니다.

Staging1은 변형없이 데이터 원본에서 직접 가져올 수 있습니다. Staging1은 최신 데이터 만 유지합니다.

Staging2는 데이터를 변환하고웨어 하우스에 갈 준비를 유지합니다. Staging2는 모든 기록 데이터를 유지합니다.

Answer 4

Raph Kimball과 Joe Caserta의 "The Data Warehouse ETL Toolkit"이라는 책이 있습니다. 그래서 Kimball 씨는 이것에 약간의 노력을 기울였습니다. :)

Answer 5

이 게시물을보십시오 here. DW 내 스테이징 영역의 책임에 대한 좋은 개요를 제공합니다.

Answer 6

우리는 현재 다소 큰 규모의 대규모 보험 DWH 프로젝트를 진행하고 있지만 소스 시스템 테이블 각각은 STAGING 데이터베이스의 별도 스키마에 배치 된 다음 이동/정리/준수 (MDM) 데이터를 준비 데이터베이스에서 STAGINGCLEAN 데이터베이스로 변환 한 다음 데이터를 Kimball DWH로 이동시키는 추가 ETL을 생성합니다.

Staging과 StagingClean 데이터베이스를 분리하면 데이터 품질에 대한 문제를 진단하는 데 매우 도움이됩니다. DWH 속성으로 변환되기 전에 정리 된 데이터뿐만 아니라 정리 된 버전이 있으므로

Answer 7

정말 좋은 질문입니다.

이전에는 데이터베이스에 변환되지 않은 데이터를 가져 오기 위해 _MIRR (미러 용) 접미어를 사용했습니다. 그것은 소스를 반영합니다. 그런 다음 소스에서 변환 된 데이터로 _STG을 사용하고 스타 스키마로는 _DW을 사용합니다.

여기서 스테이징 테이블은 3NF입니다. 나는 이것이 이것이 핵심 포인트라고 생각한다. 데이터는 변환되지 않은 상태로 착륙하고 데이터를 완전히 정상화 한 다음 단계에서 분리 한 다음보고를 위해 별표 스키마로 모두 병합합니다.