Agile DWH 설계 방법론 개요

저장 시설을 개발하는 것은 길고 진지한 작업입니다.

프로젝트 수명의 많은 부분은 처음에 객체 모델과 기본 구조를 얼마나 잘 고려했는지에 달려 있습니다.

일반적으로 받아들여지는 접근 방식은 별 체계와 제3정규형을 결합하는 다양한 변형이었으며 여전히 남아 있습니다. 원칙적으로 초기 데이터 - XNUMXNF, 쇼케이스 - 스타의 원칙에 따라. 오랜 시간에 걸쳐 테스트되고 많은 양의 연구를 통해 뒷받침되는 이 접근 방식은 숙련된 DWH 전문가가 분석 저장소의 모습을 생각할 때 가장 먼저 떠오르는(때로는 유일한) 접근 방식입니다.

반면 일반적인 비즈니스와 특히 고객 요구 사항은 빠르게 변화하는 경향이 있으며 데이터는 "깊이"와 "폭" 모두 증가하는 경향이 있습니다. 그리고 이것이 별의 주요 단점이 나타나는 곳입니다. 유연성.

DWH 개발자로서 조용하고 아늑한 생활을 하던 중 갑자기:

• "적어도 뭔가를 빨리 하면 우리가 보게 될 것"이라는 과제가 생겼습니다.
• 새로운 소스를 연결하고 적어도 일주일에 한 번 비즈니스 모델을 재작업하여 빠르게 발전하는 프로젝트가 나타났습니다.
• 시스템이 어떤 모습이어야 하는지, 궁극적으로 어떤 기능을 수행해야 하는지 전혀 모르지만 실험할 준비가 되어 있고 원하는 결과에 지속적으로 가까워지면서 지속적으로 개선할 준비가 되어 있는 고객이 나타났습니다.
• 프로젝트 관리자가 방문하여 "이제 Agile이 생겼습니다!"라는 좋은 소식을 전했습니다.

또는 저장 시설을 구축할 수 있는 다른 방법을 알아내는 데 관심이 있다면 컷에 오신 것을 환영합니다!

"유연성"은 무엇을 의미하나요?

먼저, "유연성"이라고 부르기 위해 시스템이 갖춰야 할 속성이 무엇인지 정의해 보겠습니다.

별도로, 설명된 속성은 구체적으로 다음과 관련되어야 한다는 점을 언급할 가치가 있습니다. 체계, 하지 프로세스 그것의 개발. 따라서 개발 방법론으로서 Agile에 대해 읽고 싶다면 다른 기사를 읽는 것이 좋습니다. 예를 들어 바로 거기 Habré에는 흥미로운 자료가 많이 있습니다. 검토 и 실용적인과 문제가 있는).

이는 개발 프로세스와 데이터 웨어하우스의 구조가 전혀 관련이 없다는 의미는 아닙니다. 전반적으로 Agile 아키텍처를 위한 Agile 저장소를 개발하는 것이 훨씬 더 쉬워야 합니다. 그러나 실제로는 하나의 프로젝트에서 두 가지 형태의 유연성이 우연히 일치하는 것보다 Kimbal 및 DataVault에 따르면 클래식 DWH의 Agile 개발 옵션이 더 자주 존재합니다.

그렇다면 유연한 스토리지에는 어떤 기능이 있어야 할까요? 여기에는 세 가지 요점이 있습니다.

1. 조기 배송 및 빠른 처리 - 이는 이상적으로 첫 번째 비즈니스 결과(예: 첫 번째 작업 보고서)가 가능한 한 빨리, 즉 전체 시스템이 완전히 설계되고 구현되기 전에 얻어야 함을 의미합니다. 더욱이, 각 후속 개정에도 가능한 한 적은 시간이 소요되어야 합니다.
2. 반복적인 개선 - 이는 이후의 각 개선 사항이 이상적으로는 이미 작동 중인 기능에 영향을 미치지 않아야 함을 의미합니다. 대규모 프로젝트에서 종종 가장 큰 악몽이 되는 순간이 바로 이 순간입니다. 조만간 개별 개체가 너무 많은 연결을 획득하기 시작하여 기존 테이블에 필드를 추가하는 것보다 근처 복사본에서 논리를 완전히 반복하는 것이 더 쉬워집니다. 그리고 기존 객체에 대한 개선의 영향을 분석하는 데 개선 자체보다 시간이 더 많이 걸릴 수 있다는 사실에 놀랐다면 아직 은행이나 통신 분야에서 대규모 데이터 웨어하우스를 사용해본 적이 없을 가능성이 높습니다.
3. 변화하는 비즈니스 요구 사항에 지속적으로 적응 - 전반적인 객체 구조는 확장 가능성만을 고려하여 설계되어야 하지만, 다음 확장의 방향은 설계 단계에서는 꿈조차 꾸지 못할 것이라는 기대를 가지고 설계되어야 합니다.

그리고 그렇습니다. 하나의 시스템에서 이러한 모든 요구 사항을 충족하는 것이 가능합니다(물론 특정 경우와 일부 예약이 있는 경우).

아래에서는 데이터 웨어하우스에 대해 가장 인기 있는 두 가지 애자일 설계 방법론을 살펴보겠습니다. 앵커 모델 и 데이터 금고. 괄호 안에는 EAV, 6NF(순수한 형태) 및 NoSQL 솔루션과 관련된 모든 것과 같은 훌륭한 기술이 제외되어 있습니다. 이는 더 나쁘기 때문도 아니고 이 경우 기사가 획득하겠다고 위협하기 때문도 아닙니다. 평균 디서의 볼륨. 이 모든 것은 약간 다른 클래스의 솔루션, 즉 프로젝트의 전체 아키텍처(예: EAV)에 관계없이 특정 사례에 사용할 수 있는 기술 또는 전 세계적으로 다른 정보 저장 패러다임(예: 그래프 데이터베이스)과 관련이 있습니다. 및 기타 옵션 NoSQL).

"고전적인" 접근 방식의 문제점과 유연한 방법론의 해결책

"클래식" 접근 방식이란 좋은 오래된 스타를 의미합니다(기본 레이어의 특정 구현에 관계없이 Kimball, Inmon 및 CDM의 추종자들이 나를 용서하길 바랍니다).

1. 연결의 엄격한 카디널리티

이 모델은 데이터의 명확한 구분을 기반으로 합니다. 치수 и 사리. 그리고 이것은 젠장 논리적입니다. 결국 대부분의 경우 데이터 분석은 특정 섹션(차원)의 특정 수치 지표(사실) 분석으로 귀결됩니다.

이 경우 객체 간 연결은 외래 키를 사용하여 테이블 간의 관계 형태로 설정됩니다. 이는 매우 자연스러워 보이지만 즉시 유연성의 첫 번째 제한으로 이어집니다. 연결의 카디널리티에 대한 엄격한 정의.

이는 테이블 디자인 단계에서 관련 객체의 각 쌍에 대해 다대다와 관련될 수 있는지 아니면 일대다만 관련될 수 있는지 여부와 "어느 방향"인지를 정확하게 결정해야 함을 의미합니다. 이는 기본 키를 가질 테이블과 외래 키를 가질 테이블을 직접 결정합니다. 새로운 요구 사항이 접수되면 이러한 태도를 바꾸면 기반을 재작업하게 될 가능성이 높습니다.

예를 들어, "현금 영수증" 개체를 디자인할 때 영업 부서의 맹세에 따라 조치 가능성을 명시했습니다. 여러 수표 위치에 대한 하나의 프로모션 (그 반대는 아님):

그리고 얼마 후 동료들은 같은 입장에서 행동할 수 있는 새로운 마케팅 전략을 도입했다. 동시에 여러 프로모션. 이제 관계를 별도의 개체로 분리하여 테이블을 수정해야 합니다.

(승격 확인이 결합된 모든 파생 개체도 이제 개선되어야 합니다.)

Data Vault와 앵커 모델의 관계

이러한 상황을 피하는 것은 매우 간단한 것으로 나타났습니다. 이를 위해 영업 부서를 신뢰할 필요는 없습니다. 모든 연결은 처음에 별도의 테이블에 저장됩니다. 다대다 방식으로 처리합니다.

이 접근법이 제안되었습니다 댄 린스테트 패러다임의 일부로 데이터 금고 완벽하게 지원됩니다 라르스 뢴베크 в 앵커 모델.

결과적으로 우리는 유연한 방법론의 첫 번째 특징을 얻습니다.

개체 간의 관계는 상위 엔터티의 특성에 저장되지 않고 별도의 개체 유형입니다.

В 데이터 금고 이러한 연결 테이블을 호출합니다. (링크), 및 c 앵커 모델 - 넥타이. 언뜻 보면 차이점이 이름으로 끝나지 않지만 매우 유사합니다 (아래에서 설명합니다). 두 아키텍처 모두에서 링크 테이블은 링크할 수 있습니다. 원하는 수의 엔터티 (반드시 2일 필요는 없음).

언뜻 보기에 이러한 중복성은 수정 시 상당한 유연성을 제공합니다. 이러한 구조는 기존 링크의 카디널리티 변경뿐만 아니라 새로운 링크 추가에도 허용됩니다. 이제 수표 위치에 이를 돌파한 계산원에 대한 링크가 있는 경우 이러한 링크의 모양은 단순히 기존 객체와 프로세스에 영향을 주지 않고 기존 테이블 위에 추가 기능이 됩니다.

2. 데이터 복제

유연한 아키텍처로 해결되는 두 번째 문제는 덜 명확하고 애초에 내재된 문제입니다. SCD2 유형 측정 (두 번째 유형의 치수가 천천히 변경됨) 뿐만 아니라.

클래식 웨어하우스에서 차원은 일반적으로 대리 키(PK)와 별도의 열에 있는 비즈니스 키 및 속성 집합을 포함하는 테이블입니다.

차원이 버전 관리를 지원하는 경우 버전 유효성 경계가 표준 필드 집합에 추가되고 소스의 한 행에 대해 여러 버전이 저장소에 나타납니다(버전이 지정된 속성의 각 변경 사항에 대해 하나씩).

차원에 자주 변경되는 버전 지정 속성이 하나 이상 포함되어 있는 경우 해당 차원의 버전 수는 인상적입니다(나머지 속성의 버전이 지정되지 않거나 전혀 변경되지 않더라도). 이러한 속성이 여러 개 있는 경우 버전 수는 다음과 같습니다. 그 수는 기하급수적으로 늘어납니다. 이 차원은 상당한 양의 디스크 공간을 차지할 수 있지만, 여기에 저장되는 데이터의 대부분은 단순히 다른 행의 불변 속성 값과 중복됩니다.

동시에 매우 자주 사용되기도 합니다. 비정규화 — 일부 속성은 의도적으로 참조 서적이나 다른 차원에 대한 링크가 아닌 값으로 저장됩니다. 이 접근 방식은 데이터 액세스 속도를 높이고 차원에 액세스할 때 조인 수를 줄입니다.

일반적으로 이로 인해 동일한 정보가 여러 곳에 동시에 저장됨. 예를 들어, 거주 지역 및 고객 카테고리에 대한 정보는 "클라이언트" 차원과 "구매", "배송" 및 "콜센터 통화" 사실은 물론 "클라이언트 - 고객 관리자"에 동시에 저장될 수 있습니다. ” 링크 테이블.

일반적으로 위에서 설명한 내용은 일반(버전이 없는) 차원에 적용되지만 버전이 있는 차원에서는 크기가 다를 수 있습니다. 객체의 새 버전이 나타나면(특히 돌이켜보면) 관련된 모든 항목이 업데이트될 뿐만 아니라 그러나 관련 개체의 새 버전이 계단식으로 나타나는 경우 - 표 1을 사용하여 표 2를 작성하고 표 2를 사용하여 표 3을 작성하는 경우 등 표 1의 단일 속성이 표 3의 구성에 포함되지 않더라도(및 다른 소스에서 얻은 표 2의 다른 속성이 포함됨) 이 구성을 버전화하면 최소한 추가 오버헤드가 발생하고 최대 추가 오버헤드가 발생합니다. 표 3의 버전은 전혀 관련이 없으며 체인 아래로 더 내려갑니다.

3. 재작업의 비선형 복잡성

동시에, 다른 상점을 기반으로 구축된 각각의 새로운 상점은 ETL이 변경될 때 데이터가 "분산"될 수 있는 위치의 수를 증가시킵니다. 이는 결과적으로 각 후속 개정의 복잡성(및 기간)이 증가하게 됩니다.

위에서 거의 수정되지 않은 ETL 프로세스가 있는 시스템에 대해 설명하는 경우 이러한 패러다임에 살 수 있습니다. 모든 관련 객체에 대해 새로운 수정이 올바르게 이루어졌는지 확인하기만 하면 됩니다. 수정이 자주 발생하면 실수로 여러 연결이 "누락"될 가능성이 크게 높아집니다.

또한 "버전이 있는" ETL이 "버전이 없는" ETL보다 훨씬 더 복잡하다는 점을 고려하면 전체 기능을 자주 업데이트할 때 실수를 방지하는 것이 상당히 어려워집니다.

Data Vault 및 앵커 모델에 객체 및 속성 저장

유연한 아키텍처의 저자가 제안한 접근 방식은 다음과 같이 공식화될 수 있습니다.

변화하는 것과 변하지 않는 것을 분리하는 것이 필요합니다. 즉, 속성과 별도로 키를 저장합니다.

그러나 혼동해서는 안됩니다 버전이 지정되지 않음 속성 변하지 않은: 첫 번째 항목은 변경 내역을 저장하지 않지만 변경될 수 있습니다(예: 입력 오류를 수정하거나 새 데이터를 수신할 때). 두 번째 항목은 변경되지 않습니다.

Data Vault와 Anchor Model에서 정확히 무엇이 불변으로 간주될 수 있는지에 대한 관점이 다릅니다.

건축학적 관점에서 보면 데이터 금고, 변경되지 않은 것으로 간주될 수 있음 전체 키 세트 - 자연(조직의 TIN, 소스 시스템의 제품 코드 등) 및 대리. 이 경우 나머지 속성은 변경 소스 및/또는 변경 빈도에 따라 그룹으로 나눌 수 있으며 각 그룹마다 별도의 테이블을 유지합니다. 독립적인 버전 세트를 사용합니다.

패러다임에서는 앵커 모델 변하지 않은 것으로 간주 대리 키만 본질. 다른 모든 것(자연 키 포함)은 해당 속성의 특별한 경우일 뿐입니다. 여기서 모든 속성은 기본적으로 서로 독립적입니다., 따라서 각 속성에 대해 별도의 테이블.

В 데이터 금고 엔터티 키가 포함된 테이블을 호출합니다. 후바미. 허브에는 항상 고정된 필드 집합이 포함되어 있습니다.

• 자연 엔터티 키
• 대리 키
• 소스 링크
• 기록 추가 시간

허브의 게시물 변경되지 않으며 버전도 없습니다.. 외부적으로 허브는 일부 시스템에서 서로게이트를 생성하는 데 사용되는 ID 맵 유형 테이블과 매우 유사하지만, Data Vault에서는 비즈니스 키 집합의 해시를 서로게이트로 사용하는 것이 좋습니다. 이 접근 방식은 소스에서 관계 및 속성 로드를 단순화하지만(대리자를 얻기 위해 허브에 가입할 필요가 없으며 자연 키의 해시만 계산함) 다른 문제(예: 충돌, 대/소문자 및 인쇄할 수 없는 문제와 관련)가 발생할 수 있습니다. 문자열 키 등의 문자)이므로 일반적으로 허용되지 않습니다.

다른 모든 엔터티 속성은 다음과 같은 특수 테이블에 저장됩니다. 위성. 하나의 허브에는 다양한 속성 세트를 저장하는 여러 위성이 있을 수 있습니다.

위성 간의 속성 분포는 다음 원칙에 따라 발생합니다. 공동 변경 — 한 위성에는 버전이 지정되지 않은 속성(예: 개인의 생년월일 및 SNILS)을 저장할 수 있고, 다른 위성에는 버전이 거의 변경되지 않는 속성(예: 성 및 여권 번호), 세 번째에는 자주 변경되는 속성이 저장될 수 있습니다. (예: 배송 주소, 카테고리, 마지막 주문 날짜 등) 이 경우 버전 관리는 엔터티 전체가 아닌 개별 위성 수준에서 수행되므로 한 위성 내의 버전 교차가 최소화되도록 속성을 배포하는 것이 좋습니다(이로 인해 저장된 버전의 총 수가 줄어듭니다). ).

또한 데이터 로딩 프로세스를 최적화하기 위해 다양한 소스에서 얻은 속성이 개별 위성에 포함되는 경우가 많습니다.

위성은 다음을 통해 허브와 통신합니다. 외래 키 (일대다 카디널리티에 해당) 이는 이 "기본" 아키텍처에서 여러 속성 값(예: 한 클라이언트에 대한 여러 연락처 전화번호)이 지원된다는 의미입니다.

В 앵커 모델 키를 저장하는 테이블을 호출합니다. 앵커. 그리고 그들은 다음을 유지합니다:

• 대리 키만
• 소스 링크
• 기록 추가 시간

앵커 모델 관점에서 자연 키가 고려됩니다. 일반적인 속성. 이 옵션은 이해하기 더 어려워 보일 수 있지만 개체를 ​​식별하는 데 훨씬 더 많은 범위를 제공합니다.

예를 들어, 동일한 엔터티에 대한 데이터가 서로 다른 시스템에서 나올 수 있는 경우 각 시스템은 고유한 자연 키를 사용합니다. Data Vault에서는 이로 인해 여러 허브(소스당 하나 + 통합 마스터 버전)의 다소 번거로운 구조가 발생할 수 있는 반면, 앵커 모델에서는 각 소스의 자연 키가 자체 속성에 속하며 독립적으로 로드할 때 사용할 수 있습니다. 다른 모든 것.

그러나 여기에는 한 가지 교묘한 점도 있습니다. 즉, 서로 다른 시스템의 속성이 하나의 엔터티에 결합된 경우 일부 오류가 발생할 가능성이 높습니다. "접착"의 규칙, 이를 통해 시스템은 다양한 소스의 기록이 엔터티의 한 인스턴스에 해당한다는 것을 이해해야 합니다.

В 데이터 금고 이 규칙은 포메이션을 결정할 가능성이 높습니다. 마스터 엔터티의 "대리 허브" 자연 소스 키와 원래 속성을 저장하는 허브에는 어떠한 방식으로도 영향을 미치지 않습니다. 어느 시점에서 병합 규칙이 변경되거나 이를 수행하는 속성이 업데이트되면 대리 허브를 다시 포맷하는 것으로 충분합니다.

В 앵커 모델 그러한 엔터티는 다음 위치에 저장될 가능성이 높습니다. 유일한 앵커. 이는 소스가 무엇이든 관계없이 모든 속성이 동일한 대리자에 바인딩된다는 것을 의미합니다. 잘못 병합된 기록을 분리하고 일반적으로 그러한 시스템에서 병합의 타당성을 모니터링하는 것은 훨씬 더 어려울 수 있습니다. 특히 규칙이 매우 복잡하고 자주 변경되고 동일한 속성이 다른 소스에서 얻을 수 있는 경우(확실히 가능합니다. 각 속성 버전은 해당 소스에 대한 링크를 유지하기 때문입니다.

어떤 경우든 귀하의 시스템이 해당 기능을 구현해야 한다면 중복 제거, 기록 병합 및 기타 MDM 요소, Agile 방법론에서 자연 키를 저장하는 측면에 특별한 주의를 기울일 가치가 있습니다. 더 큰 Data Vault 설계가 병합 오류 측면에서 갑자기 더 안전해질 가능성이 높습니다.

앵커 모델 또한 매듭 그것은 본질적으로 특별하다 퇴화된 앵커 유형, 여기에는 하나의 속성만 포함될 수 있습니다. 노드는 단순 디렉토리(예: 성별, 결혼 상태, 고객 서비스 카테고리 등)를 저장하는 데 사용됩니다. 앵커와 달리 매듭은 연관된 속성 테이블이 없습니다, 유일한 속성(이름)은 항상 키와 동일한 테이블에 저장됩니다. 노드는 앵커가 서로 연결되는 것과 마찬가지로 타이 테이블(Tie)에 의해 앵커와 연결됩니다.

노드 사용에 관한 명확한 의견은 없습니다. 예를 들어, 니콜라이 골로프, 러시아에서 앵커 모델의 사용을 적극적으로 장려하는 사람은 단 한 권의 참고서에도 불구하고 확실하게 언급할 수 있다고 믿습니다. 항상 정적이며 단일 레벨이므로 모든 개체에 대해 본격적인 앵커를 즉시 사용하는 것이 좋습니다.

Data Vault와 Anchor 모델의 또 다른 중요한 차이점은 가용성입니다. 연결의 속성:

В 데이터 금고 링크는 허브와 동일한 완전한 개체이며 다음을 가질 수 있습니다. 자신의 속성. 에 앵커 모델 링크는 앵커와 연결에만 사용됩니다. 자신의 속성을 가질 수 없습니다. 이러한 차이로 인해 모델링 접근 방식이 크게 달라집니다. 사실들, 이에 대해 더 자세히 논의하겠습니다.

사실 저장

앞서 우리는 주로 측정 모델링에 대해 이야기했습니다. 사실은 조금 덜 명확합니다.

В 데이터 금고 사실을 저장하는 일반적인 객체는 링크, 위성에 실제 지표가 추가됩니다.

이 접근 방식은 직관적인 것 같습니다. 이는 분석된 지표에 대한 쉬운 액세스를 제공하며 일반적으로 기존 팩트 테이블과 유사합니다(지표만 테이블 자체가 아닌 "이웃" 테이블에 저장됨). 그러나 함정도 있습니다. 모델의 일반적인 수정 중 하나인 사실 키의 확장은 다음을 필요로 합니다. Link에 새로운 외래 키 추가. 그리고 이는 결국 모듈성을 "파괴"하고 잠재적으로 다른 객체를 수정해야 할 필요성을 야기합니다.

В 앵커 모델 연결은 자체 속성을 가질 수 없으므로 이 접근 방식은 작동하지 않습니다. 모든 속성과 표시기는 하나의 특정 앵커에 연결되어야 합니다. 결론은 간단하다 - 각 사실에는 자체 앵커가 필요합니다.. 우리가 사실로 인식하는 데 익숙한 일부의 경우 이는 자연스러워 보일 수 있습니다. 예를 들어 구매 사실은 "주문"또는 "영수증"이라는 개체, 사이트 방문 세션 등으로 완벽하게 축소될 수 있습니다. 그러나 그러한 자연적인 "운송 개체"를 찾는 것이 그리 쉽지 않은 사실도 있습니다. 예를 들어 매일 시작될 때 창고에 남아 있는 물품이 있습니다.

따라서 Anchor 모델에서 팩트 키를 확장할 때 모듈성 문제는 발생하지 않지만(단순히 해당 앵커에 새 관계를 추가하는 것으로 충분함) 팩트를 표시하도록 모델을 설계하는 것은 덜 모호합니다. "인공" 앵커가 나타날 수 있습니다. 비즈니스 개체 모델을 명확하지 않은 방식으로 표시합니다.

유연성이 달성되는 방법

두 경우 모두 결과 구성에는 다음이 포함됩니다. 훨씬 더 많은 테이블전통적인 측정보다 하지만 시간이 걸릴 수도 있습니다 훨씬 적은 디스크 공간 기존 차원과 동일한 버전 속성 세트를 사용합니다. 당연히 여기에는 마법이 없습니다. 모든 것은 정규화에 관한 것입니다. Satellite(Data Vault 내) 또는 개별 테이블(Anchor Model)에 속성을 배포함으로써 속성을 줄이거나 완전히 제거합니다. 다른 속성을 변경할 때 일부 속성 값의 중복.

에 데이터 금고 상금은 위성 간의 속성 분포에 따라 달라집니다. 앵커 모델 — 측정 개체당 평균 버전 수에 거의 정비례합니다.

그러나 공간 절약은 중요하지만 속성을 별도로 저장하는 주요 이점은 아닙니다. 별도의 관계 저장과 함께 이 접근 방식을 사용하면 저장소가 모듈식 디자인. 이는 그러한 모델에 개별 속성과 전체 새로운 주제 영역을 모두 추가하는 것이 다음과 같다는 것을 의미합니다. 상부 구조 기존 객체 세트를 변경하지 않고 덮어씁니다. 이것이 바로 설명된 방법론을 유연하게 만드는 것입니다.

이는 또한 조각 생산에서 대량 생산으로의 전환과 유사합니다. 전통적인 접근 방식에서 모델의 각 테이블이 고유하고 특별한 주의가 필요한 경우 유연한 방법론에서는 이미 표준 "부품" 세트입니다. 한편으로는 더 많은 테이블이 있고 데이터를 로드하고 검색하는 프로세스가 더 복잡해 보일 것입니다. 반면에 그들은 전형적인. 즉, 자동화되고 메타데이터 기반. 개선 사항 설계 작업의 상당 부분을 차지할 수 있는 "어떻게 배치할 것인가?"라는 질문은 이제 그만한 가치가 없습니다. 모델 변경이 작업 프로세스에 미치는 영향에 대한 질문도 마찬가지입니다. ).

이는 그러한 시스템에 분석가가 전혀 필요하지 않다는 의미는 아닙니다. 누군가는 여전히 속성이 있는 개체 세트를 통해 작업하고 이를 모두 로드할 위치와 방법을 파악해야 합니다. 그러나 작업량은 물론 오류 발생 가능성과 비용도 크게 줄어듭니다. 분석 단계와 ETL 개발 중 상당 부분이 메타데이터 편집으로 축소될 수 있습니다.

다크 사이드

위의 모든 사항을 통해 두 가지 접근 방식은 모두 유연하고 기술적으로 진보하며 반복적인 개선에 적합합니다. 물론 "연고 속의 통"도 있는데, 이미 짐작하실 수 있을 것 같습니다.

유연한 아키텍처의 모듈화에 기초가 되는 데이터 분해는 테이블 수의 증가로 이어지며, 그에 따라 간접비 샘플링할 때 조인합니다. 단순히 차원의 모든 속성을 가져오려면 기존 저장소에서는 한 번만 선택하면 충분하지만 유연한 아키텍처에는 일련의 전체 조인이 필요합니다. 더욱이 보고서에 대한 이러한 조인을 모두 미리 작성할 수 있다면 SQL을 직접 작성하는 데 익숙한 분석가는 두 배의 어려움을 겪게 될 것입니다.

이 상황을 더 쉽게 만드는 몇 가지 사실이 있습니다.

큰 차원으로 작업할 때 모든 속성이 동시에 사용되는 경우는 거의 없습니다. 이는 모델에서 언뜻 보기에 보이는 것보다 조인 수가 적을 수 있음을 의미합니다. Data Vault는 위성에 속성을 할당할 때 예상되는 공유 빈도도 고려할 수 있습니다. 동시에 허브 또는 앵커 자체는 주로 로딩 단계에서 서로게이트를 생성하고 매핑하는 데 필요하며 쿼리에서는 거의 사용되지 않습니다(특히 앵커의 경우).

모든 조인은 키를 기준으로 합니다. 또한 데이터를 저장하는 보다 "압축된" 방법은 필요한 곳(예: 속성 값으로 필터링하는 경우)에서 테이블을 검색하는 오버헤드를 줄여줍니다. 이는 여러 조인을 사용하여 정규화된 데이터베이스에서 샘플링하는 것이 행당 여러 버전이 있는 하나의 무거운 차원을 스캔하는 것보다 훨씬 빠르다는 사실로 이어질 수 있습니다.

예를 들어, 여기에서는 이 이 기사에는 한 테이블의 샘플을 사용하여 Anchor 모델의 성능에 대한 자세한 비교 테스트가 포함되어 있습니다.

많은 것은 엔진에 달려 있습니다. 많은 최신 플랫폼에는 내부 조인 최적화 메커니즘이 있습니다. 예를 들어, MS SQL 및 Oracle은 해당 데이터가 다른 조인을 제외한 어느 곳에서도 사용되지 않고 최종 선택(테이블/조인 제거)에 영향을 미치지 않는 경우 테이블에 대한 조인을 "건너뛸" 수 있으며 MPP Vertica Avito 동료의 경험는 쿼리 계획의 일부 수동 최적화를 고려하면 앵커 모델을 위한 탁월한 엔진임이 입증되었습니다. 반면, 조인 지원이 제한된 Click House에 앵커 모델을 저장하는 것은 아직 좋은 생각이 아닌 것 같습니다.

또한 두 아키텍처 모두에 다음이 있습니다. 특별한 움직임, 데이터 액세스를 더 쉽게 만듭니다(쿼리 성능 관점과 최종 사용자 모두). 예를 들어, 특정 시점 테이블 Data Vault 또는 특수 테이블 함수 앵커 모델에서.

전체로

고려되는 유연한 아키텍처의 주요 본질은 "설계"의 모듈성입니다.

다음을 허용하는 것이 바로 이 속성입니다.

• 메타데이터 배포 및 기본 ETL 알고리즘 작성과 관련된 초기 준비를 마친 후 고객에게 첫 번째 결과를 신속하게 제공 몇 가지 소스 개체의 데이터를 포함하는 두 개의 보고서 형식입니다. 전체 개체 모델을 (최상위 수준에서도) 완전히 생각할 필요는 없습니다.
• 데이터 모델은 2~3개의 개체만으로 작업을 시작할 수 있고 유용할 수 있습니다. 점차적으로 성장하다 (앵커 모델 Nikolai에 관하여 적용된 균사체와 좋은 비교).
• 주제 영역 확장, 새로운 소스 추가 등 대부분의 개선 기존 기능에 영향을 주지 않으며 이미 작동 중인 기능을 손상시킬 위험이 없습니다..
• 표준 요소로의 분해 덕분에 이러한 시스템의 ETL 프로세스는 동일하게 보이며, 해당 작성은 알고리즘화에 적합하며 궁극적으로는 자동화.

이러한 유연성의 대가는 공연. 이는 해당 모델에서 허용 가능한 성능을 달성하는 것이 불가능하다는 의미는 아닙니다. 원하는 측정항목을 달성하려면 세부 사항에 더 많은 노력과 주의가 필요한 경우가 많습니다.

애플 리케이션

엔터티 유형 데이터 금고

Data Vault에 대한 추가 정보:
댄 리스트타트의 웹사이트
러시아어로 된 Data Vault에 관한 모든 것
Habré의 Data Vault 정보

엔터티 유형 앵커 모델

앵커 모델에 대한 자세한 내용:

앵커 모델 제작자의 웹사이트
Avito에서 앵커 모델을 구현한 경험에 대한 기사

고려된 접근 방식의 공통 기능과 차이점이 포함된 요약표:

출처 : habr.com