DATA VAULT 개발 및 BUSINESS DATA VAULT로의 전환

이전 기사에서는 DATA VAULT의 기본 사항에 대해 이야기하고 DATA VAULT의 주요 요소와 그 목적을 설명했습니다. 이는 DATA VAULT의 주제가 소진된 것으로 간주될 수 없으며 DATA VAULT 발전의 다음 단계에 대해 이야기할 필요가 있습니다.

그리고 이 기사에서는 DATA VAULT의 개발과 BUSINESS DATA VAULT 또는 간단히 BUSINESS VAULT로의 전환에 중점을 둘 것입니다.

BUSINESS DATA VAULT의 출현 이유

DATA VAULT에는 특정 장점이 있지만 단점도 있다는 점에 유의해야 합니다. 이러한 단점 중 하나는 분석 쿼리를 작성하는 것이 어렵다는 것입니다. 쿼리에는 상당한 수의 JOIN이 포함되어 있으며 코드가 길고 번거롭습니다. 또한 DATA VAULT에 입력되는 데이터는 어떠한 변환도 거치지 않으므로 비즈니스 관점에서 순수한 형태의 DATA VAULT는 절대적인 가치가 없습니다.

이러한 단점을 제거하기 위해 DATA VAULT 방법론이 다음과 같은 요소로 확장되었습니다.

• PIT(특정 시점) 테이블
• 브리지 테이블;
• 미리 정의된 파생.

이러한 요소의 목적을 자세히 살펴보겠습니다.

PIT 테이블

일반적으로 하나의 비즈니스 엔터티(HUB)에는 업데이트 속도가 다른 데이터가 포함될 수 있습니다. 예를 들어 개인을 특징짓는 데이터에 대해 이야기하는 경우 전화번호, 주소 또는 이메일에 대한 정보가 다음보다 업데이트 속도가 더 높다고 말할 수 있습니다. 성명, 여권 정보, 결혼 여부 또는 성별.

따라서 위성을 결정할 때 업데이트 빈도를 염두에 두어야 합니다. 왜 중요 함?

동일한 테이블에 서로 다른 업데이트 속도로 속성을 저장하는 경우 가장 자주 변경되는 속성이 업데이트될 때마다 테이블에 행을 추가해야 합니다. 결과적으로 디스크 공간이 늘어나고 쿼리 실행 시간이 늘어납니다.

이제 업데이트 빈도별로 위성을 나누고 독립적으로 데이터를 로드할 수 있으므로 최신 데이터를 수신할 수 있는지 확인해야 합니다. 불필요한 JOIN을 사용하지 않는 것이 더 좋습니다.

예를 들어, 업데이트 속도가 다른 위성으로부터 최신(마지막 업데이트 날짜에 따라) 정보를 얻어야 한다고 설명하겠습니다. 이렇게 하려면 JOIN을 만드는 것뿐만 아니라 최대 업데이트 날짜 MAX(Update Date)를 선택하여 여러 중첩 쿼리(정보가 포함된 각 위성에 대해)를 만들어야 합니다. 새로운 JOIN이 나올 때마다 이러한 코드는 점점 커지고 이해하기가 매우 어려워집니다.

PIT 테이블은 이러한 쿼리를 단순화하도록 설계되었으며, PIT 테이블은 DATA VAULT에 새 데이터를 쓰는 것과 동시에 채워집니다. 피트 테이블:

따라서 우리는 각 시점의 모든 위성에 대한 데이터의 관련성에 대한 정보를 가지고 있습니다. PIT 테이블에 JOIN을 사용하면 PIT가 매일 공백 없이 채워지는 조건으로 자연스럽게 중첩된 쿼리를 완전히 제거할 수 있습니다. PIT에 공백이 있더라도 PIT 자체에 하나의 중첩 쿼리를 사용해야만 최신 데이터를 얻을 수 있습니다. 하나의 중첩 쿼리는 각 위성에 대한 중첩 쿼리보다 빠르게 처리됩니다.

다리

BRIDGE 테이블은 분석 쿼리를 단순화하는 데에도 사용됩니다. 그러나 PIT와 다른 점은 다양한 허브, 링크 및 해당 위성 간의 요청을 단순화하고 속도를 높이는 수단입니다.

테이블에는 쿼리에 자주 사용되는 모든 위성에 필요한 모든 키가 포함되어 있습니다. 또한 필요한 경우 분석을 위해 키 이름이 필요한 경우 해시된 비즈니스 키에 텍스트 형식의 키를 추가할 수 있습니다.

사실 BRIDGE를 사용하지 않고 다른 허브에 속한 위성에 있는 데이터를 수신하는 과정에서 위성 자체뿐만 아니라 허브를 연결하는 링크에 대해서도 JOIN을 만들어야 합니다.

BRIDGE의 존재 여부는 스토리지 구성과 쿼리 실행 속도 최적화 필요성에 따라 결정됩니다. BRIGE의 보편적인 예를 생각해내기는 어렵다.

미리 정의된 파생

BUSINESS DATA VAULT에 더 가까워지는 또 다른 유형의 개체는 사전 계산된 지표가 포함된 테이블입니다. 이러한 테이블은 비즈니스에 매우 중요하며 주어진 규칙에 따라 집계된 정보를 포함하고 상대적으로 쉽게 액세스할 수 있습니다.

구조적으로 사전 정의된 파생은 특정 허브의 또 다른 위성에 지나지 않습니다. 이는 일반 위성과 마찬가지로 비즈니스 키와 위성에 기록이 생성된 날짜를 포함합니다. 그러나 유사점은 여기서 끝납니다. 이러한 "특수" 위성 속성의 추가 구성은 가장 널리 사용되는 사전 계산된 지표를 기반으로 비즈니스 사용자에 의해 결정됩니다.

예를 들어 직원에 대한 정보가 포함된 허브에는 다음과 같은 표시기가 있는 위성이 포함될 수 있습니다.

• 최저 임금;
• 최대 급여;
• 평균 연봉;
• 누적임금 등의 총액

동일한 허브의 PIT 테이블에 사전 정의된 파생을 포함하는 것이 논리적입니다. 그러면 특별히 선택한 날짜에 직원에 대한 데이터 조각을 쉽게 얻을 수 있습니다.

결론

실습에서 알 수 있듯이 비즈니스 사용자가 DATA VAULT를 사용하는 것은 다음과 같은 여러 가지 이유로 다소 어렵습니다.

• 쿼리 코드는 복잡하고 번거롭습니다.
• JOIN이 많으면 쿼리 성능에 영향을 미칩니다.
• 분석 쿼리를 작성하려면 스토리지 설계에 대한 뛰어난 지식이 필요합니다.

데이터 액세스를 단순화하기 위해 DATA VAULT가 추가 개체로 확장되었습니다.

• PIT(특정 시점) 테이블
• 브리지 테이블;
• 미리 정의된 파생.

다음 기사 제 생각에는 BI 작업을 하는 사람들에게 가장 흥미로운 점을 말씀드릴 계획입니다. DATA VAULT를 기반으로 팩트 테이블과 차원 테이블을 생성하는 방법을 제시하겠습니다.

기사의 자료는 다음을 기반으로 합니다.

• 에 출판 자세한 설명과 함께 모델 다이어그램이 포함된 Kenta Graziano;
• 도서: "DATA VAULT 2.0을 사용하여 확장 가능한 데이터 웨어하우스 구축";
• 기사 Data Vault 기본 사항.

출처 : habr.com