7.7 데이터 모델링과 시맨틱 계층

개요와 동기

데이터 모델은 데이터가 어디에 사는지 정하기 전에 내리는, 데이터가 무엇을 뜻하는지에 대한 결정입니다. 비즈니스가 신경 쓰는 사물, 그것을 기술하는 속성, 그 사이의 관계에 이름을 붙입니다. 저장소, 색인, 파일 형식, 질의 엔진은 모두 나중에 옵니다. 이 순서가 중요한 것은 데이터의 의미가 그것을 담는 어떤 기술보다 오래가기 때문입니다. 웨어하우스는 교체되고, 테이블 형식은 바뀌고, 질의 엔진은 오가지만, “고객”, “주문”, “활성 사용자”는 그 모두에 걸쳐 여러 해 동안 같은 뜻이어야 합니다.

작은 팀에서 모델링은 암묵적인 경우가 많습니다. 한 엔지니어가 스키마 전체를 머릿속에 지니고, 의견이 갈릴 사람이 세 명뿐이므로 “매출”에 대한 공유된 이해가 살아남습니다. 대규모 개발 조직, 기업, 정부 기관의 규모에서는 그 비공식성이 7.1장(데이터 전략과 거버넌스)에 기술된 바로 그 방식으로 무너집니다. 수십 개 팀이 수백 개 테이블을 만들고, 각각 “세션”이 무엇인지 또는 사용자가 언제 “활성”으로 치는지에 대해 자기 생각이 있습니다. 두 대시보드가 같은 주에 대해 두 개의 다른 숫자를 보이고, 리더십 회의는 다음에 무엇을 할지가 아니라 누구의 질의가 맞는지에 대한 논쟁이 됩니다. 나쁜 모델링은 스스로를 알리지 않습니다. 몇 달 뒤 조정 작업, 실패한 감사, 아무도 방어할 수 없는 수치에 근거한 결정으로 나타납니다.

이 장은 그 일을 의도적으로 하는 것에 관한 것입니다. 개념, 논리, 물리 모델, 개체-관계 모델링, 언제 정규화하고 언제 비정규화하는지, 트랜잭션 워크로드 대 분석 워크로드에서 모델링이 어떻게 다른지, 사실과 차원을 쓰는 차원 모델링, 모든 비즈니스 지표의 하나의 거버넌스가 적용되는 정의를 담는 시맨틱 계층을 다룹니다. 보답은 그 자체를 위한 우아함이 아닙니다. “활성 사용자”와 “매출”이 어디서나 하나의 뜻이어서 팀이 숫자를 신뢰하고 그 덕에 더 빨리 움직일 수 있다는 것입니다.

함께 보기: 3.4장(데이터 아키텍처와 저장소), 7.3장(분석과 비즈니스 인텔리전스), 11.5장(핵심 성과 지표).

핵심 원칙

데이터가 어디에 사는지 정하기 전에 데이터가 무엇을 뜻하는지 정하십시오.
세 수준에서 모델링하십시오. 개념(비즈니스), 논리(구조), 물리(구현).
트랜잭션 시스템에서는 정확성을 지키려고 정규화하고, 분석 속도를 위해서는 의도적으로 비정규화하십시오.
모델을 워크로드에 맞추십시오. 트랜잭션과 분석은 반대의 필요를 갖습니다.
모든 비즈니스 지표에는 정확히 하나의 거버넌스가 적용되는 정의가 있으며, 그것은 시맨틱 계층에 삽니다.
정합 차원은 독립적인 팀이 안전하게 조인하고 비교하게 합니다.
그레인은 질의의 우연이 아니라 의도적으로 내리는 설계 결정입니다.
모델은 살아 있는 자산입니다. 이름을 잘 붙이고, 문서화하고, 진화 가능하게 유지하십시오.

권장 사항

세 수준에서 순서대로 모델링한다

의미에서 바깥으로 작업하십시오. 개념 모델로 시작합니다. 비즈니스가 신경 쓰는 엔터티와 그 관계를 도메인 전문가가 확인할 수 있는 쉬운 말로 씁니다. “고객은 여러 주문을 한다. 주문은 여러 품목을 담는다. 각 품목은 하나의 제품을 가리킨다.” 아직 키도, 타입도, 테이블도 없습니다. 그다음 구조를 더한 논리 모델을 만듭니다. 속성, 기본 키와 외래 키, 카디널리티, 제약으로, 여전히 특정 데이터베이스와 독립적입니다. 개체-관계 모델링이 여기의 표준 표기이며, 개체-관계 다이어그램은 엔지니어와 비즈니스 이해관계자 모두와 리뷰하는 산출물입니다. 그런 뒤에야 물리 모델을 만듭니다. 선택한 엔진의 실제 테이블, 열, 데이터 타입, 색인, 파티션, 저장 레이아웃입니다. 물리 설계로 건너뛰는 것이 가장 흔한 모델링 실수입니다. 그보다 오래가야 할 결정에 오늘의 기술 선택을 굳혀 넣기 때문입니다.

트랜잭션 시스템은 정규화하고, 분석 시스템은 의도적으로 비정규화한다

트랜잭션을 기록하는 시스템에서는 데이터베이스 정규화를 선호하십시오. 정규형은 중복을 제거해 각 사실이 한 번 저장되게 하며, 갱신 이상을 막고 많은 사용자가 동시에 데이터를 바꿀 때 쓰기를 올바르게 유지합니다. 이것이 동시 쓰기 아래의 정확성이 어떤 단일 분석 질의의 속도보다 중요한 온라인 트랜잭션 처리(OLTP)의 올바른 기본값입니다. 분석 시스템은 반대의 우선순위를 갖습니다. 읽기 중심이고, 거대한 범위를 스캔하고 집계하며, 질의 시점에 수십 개의 정규화된 테이블을 조인하는 것은 느리고 추론하기 어렵습니다. 거기서는 관련 속성을 함께 합쳐 질의가 더 단순하고 빠르도록 의도적으로 비정규화합니다. 규율은 중복이 우연히 스며들게 두지 않고 문서화된 이유로 의도적으로 비정규화하는 것입니다. 3.4장(데이터 아키텍처와 저장소)은 각 패턴이 잘 수행되게 하는 엔진을 다룹니다.

분석에는 차원 모델링을 쓴다

분석 워크로드에는 랄프 킴벌이 대중화한 접근인 차원 모델링을 채택하십시오. 세계를 사실과 차원으로 나눕니다. 사실 테이블은 비즈니스 프로세스의 측정을 담습니다. 판매 금액, 통화 시간, 출하 수량입니다. 차원 테이블은 필터링하고 그룹화하는 서술적 맥락을 담습니다. 고객, 제품, 매장, 날짜입니다. 하나의 사실 테이블을 그 차원들로 둘러싸 배치하면 스타 스키마가 되며, 분석가가 이해하기 쉽고 엔진이 질의하기 빠릅니다. 그 차원을 하위 테이블로 정규화하면 스노플레이크 스키마가 되며, 더 많은 조인과 복잡성을 대가로 일부 저장을 아낍니다. 구체적인 이유가 없다면 스타를 선호하십시오. 감사 가능성과 원천 추적이 지배하는 매우 크고 규제가 심한 환경에서는 데이터 볼트 접근이 허브, 링크, 위성을 모델링해 이력과 계보를 공격적으로 포착하며, 더 많은 테이블과 가파른 학습 곡선을 대가로 합니다. 대부분의 팀은 킴벌 방식의 스타로 시작하고, 감사 요건이 정당화할 때만 데이터 볼트에 손을 뻗어야 합니다.

그레인을 고정하고 변하는 차원을 명시적으로 다룬다

사실 테이블에 열 하나를 더하기 전에 그레인, 곧 한 행이 정확히 무엇을 나타내는지 진술하십시오. “주문 품목당 한 행.” “사용자당 하루 한 행.” 그레인은 올바른 모델의 기초입니다. 모든 측정값과 차원이 그 그레인에 맞거나 테이블에 속하지 않기 때문입니다. 그레인을 섞는 것이 매출이 이중 집계되는 방식입니다. 그다음 차원이 시간에 따라 어떻게 변하는지 정하십시오. 고객이 새 도시로 이사했을 때, 옛 값을 덮어쓰는가, 전체 이력을 유지하는가, 현재와 직전 값만 추적하는가? 이것이 표준 천천히 변하는 차원 패턴이며, 잘못 고르면 과거 보고서가 조용히 과거를 다시 씁니다. 그레인과 변경 전략을 앞서 정하고, 모델 문서에 적고, 리뷰에서 선을 지키십시오.

모든 지표의 단일 정의로 하나의 시맨틱 계층을 구축한다

이 장 전체의 값을 하는 권장 사항입니다. 시맨틱 계층은 물리 테이블과 그것을 소비하는 모든 도구 사이에 앉아 각 비즈니스 지표의 거버넌스가 적용되는 하나의 정의를 담습니다. “활성 사용자”는 코드로 한 번 정의되며, 정확한 로직을 담습니다. 어떤 이벤트가 세어지는지, 어떤 윈도우에서, 어떤 내부 계정을 제외하는지입니다. “매출”도 환불, 할인, 환율 변환을 어떻게 처리하는지 포함해 한 번 정의됩니다. 모든 대시보드, 노트북, 보고서, 역방향 ETL 작업이 맞춤 질의에서 다시 구현하는 대신 그 정의를 읽습니다. 정의가 바뀌면 한 곳에서 바뀌고 모든 소비자가 함께 갱신됩니다. 이것이 거버넌스가 적용되는 지표 정의를 열망이 아니라 현실로 만드는 메커니즘이며, 11.5장(핵심 성과 지표)이 요구하는 것의 직접적 구현입니다. 7.1장이 데이터를 제품으로 다루라고 요구하듯, 지표 정의를 소유자, 리뷰, 테스트가 있는 버전 관리되는 코드로 다루십시오.

관례, 명명, 문서화를 확립한다

일관성은 기능입니다. 명명 관례를 채택하고 시행하십시오. 테이블 이름의 관례, 키의 관례, 날짜 열의 표준, 사실과 차원을 표시하는 규칙입니다. 엔터티 이름을 단수로 쓸지 복수로 쓸지 한 번 정하고 결코 섞지 마십시오. 각 모델을 그것을 쓰는 사람들이 볼 곳에 문서화하십시오. 모든 테이블의 의미, 모든 사실의 그레인, 모든 지표의 정의, 각각의 소유자입니다. 좋은 명명과 문서화가 새 분석가가 팀을 방해하는 대신 스스로 해결하게 하고, 감사자가 안내 투어 없이 이사회 자료의 숫자를 원천까지 추적하게 합니다.

모델을 진화 가능하게 유지한다

모델은 바뀔 것이므로 변화를 위해 설계하십시오. 기존 열을 용도 변경하는 대신 열을 추가하십시오. 원천 시스템의 자연 키가 바뀌어도 웨어하우스 전체로 파급되지 않도록 대리 키를 쓰십시오. 지표 정의를 조용히 바꾸는 대신 버전을 관리하고 예고와 함께 폐기하십시오. 변환을 버전 관리에 두고, 테스트하고, 리뷰하십시오. “활성 사용자”의 뜻 변경이 BI 도구의 조용한 편집이 아니라 diff와 승인자가 있는 풀 리퀘스트가 되게 하는 것입니다. 안전하게 진화시킬 수 없는 모델은 사람들이 우회하는 모델이 되고, 그림자 정의가 단일 진실 원천이 죽는 방식입니다.

장단점

접근	장점	단점	가장 적합한 곳
정규화 (3NF)	올바른 쓰기. 중복 없음. 유연	느린 분석 조인. 복잡한 질의	OLTP와 운영 시스템
스타 스키마 (킴벌)	빠르고 직관적이며 분석가 친화적	약간의 중복. 유지할 ETL	대부분의 분석과 BI
스노플레이크 스키마	더 적은 저장. 더 깨끗한 차원	더 많은 조인. 더 많은 복잡성	크고 엄격히 다스려지는 차원
데이터 볼트	전체 이력. 감사 가능. 민첩한 적재	많은 테이블. 가파른 학습 곡선	규제가 심하고 감사 중심
모델 위의 시맨틱 계층	어디서나 하나의 정의. 도구 독립적	선행 구축. 소유권 필요	다중 팀, 다중 도구 조직

중심 긴장은 단일 질의의 속도 대 전체 영역에 걸친 정확성과 유연성입니다. 정규화는 정확성을 지키고 질의 복잡성으로 값을 치르며, 차원 모델은 질의 속도와 명료함을 사고 ETL과 일부 관리되는 중복으로 값을 치릅니다. 보편적 승자는 없으므로, 좋아하는 것을 고르는 대신 모델을 워크로드에 맞춥니다. 시맨틱 계층은 지표 정의를 어느 한 도구에서도 독립적으로 만들어 많은 팀과 많은 도구 사이의 두 번째 긴장을 해결합니다. 실수는 이를 이념적 진영으로 다루는 것입니다. 건강한 조직은 정규화된 OLTP 시스템, 그것에서 공급받는 차원 분석 모델, 그 위의 하나의 시맨틱 계층을 운영하며, 각각이 잘하는 일을 합니다.

팀과 논의할 질문

두 대시보드가 같은 지표에 다른 숫자를 보일 때, 누구의 정의가 이기며, 그 정의는 물리적으로 어디에 삽니까? 이 질문은 정말로 단일 진실 원천이 있는지, 아니면 그렇다고 믿을 뿐인지를 드러냅니다. 대부분의 큰 팀에서 정직한 답은 “활성 사용자”가 열두 개의 다른 질의에서 재정의되어 있고, 승자는 회의에서 가장 크게 논쟁하는 사람이라는 것입니다. 실제 증거를 가져오십시오. 지표 하나를 골라 계산되는 모든 자리를 찾고 로직을 한 줄씩 비교하십시오. 윈도우, 제외, 엣지 케이스에 대한 조용한 불일치를 거의 확실히 찾을 것입니다. 답은 각 지표가 리뷰된 코드로 한 번 정의되는 시맨틱 계층을 구축하는 결정을 이끌어, 질문이 사람에 대한 것이 아니라 버전 관리되는 산출물에 대한 것이 되게 해야 합니다. 그 정의에 단일 물리적 집이 생기기 전까지 모든 조정은 일시적입니다.
가장 중요한 사실 테이블의 그레인은 무엇이며, 방 안의 모두가 같은 방식으로 진술할 수 있습니까? 그레인은 대부분의 모델링 실패가 거슬러 추적되는 조용한 기초입니다. 팀 절반이 “주문당 한 행”이라고 하고 나머지 절반이 “품목당 한 행”이라고 하면, 매출 보고서에서 드러나기를 기다리는 이중 집계 버그가 있는 것입니다. 실제 테이블을 가져와 각자에게 한 행을 한 문장으로 기술해 달라고 요청하십시오. 여기서의 불일치는 매끄럽게 넘길 소통 문제가 아니라 그 위에 측정값이 더 쌓이기 전에 고칠 설계 결함입니다. 답은 모델 문서에 적히고 리뷰에서 시행되어야 합니다. 분석가들이 모호한 그레인 위에 질의를 만들기 시작하면 그 모호함이 바로잡는 것보다 빨리 퍼지기 때문입니다.
이 모델은 변화를 어떻게 흡수하며, 정의가 바뀔 때 작년 보고서는 어떻게 됩니까? 모든 모델은 바뀌는 원천 시스템, 바뀌는 비즈니스 규칙, 바뀌는 지표 정의에 직면하므로, 진짜 질문은 변화가 통제된 풀 리퀘스트인지, 이력을 다시 쓰는 조용한 편집인지입니다. 최근 예를 가져오십시오. 정의가 바뀐 지표나 이름이 바뀐 원천 키를 가져와 기존 대시보드에 무슨 일이 있었는지 추적하십시오. 천천히 변하는 차원이 덮어쓰기로 처리되었다면, 과거 보고서가 과거 값을 조용히 바꿨을 수 있으며, 이는 추세 분석이나 규제 보고를 하는 누구에게든 심각한 문제입니다. 답은 대리 키, 버전 관리되는 지표 정의, 명시적 변경 전략, 리뷰와 함께 버전 관리에 보관되는 변환 쪽으로 이끌어야 합니다. 아무도 안전하게 바꿀 수 없는 모델은 사람들이 버리는 모델이 됩니다.
어떤 차원이 모든 팀에서 같은 뜻이어야 하며, 각각을 소유하는 책임은 누구에게 있습니까? 정합 차원은 마케팅, 재무, 운영이 데이터를 조인하고 비교 가능한 답을 얻게 해 주지만, “고객”, “제품”, “지역”, “날짜”가 팀별 비공개 사본이 아니라 하나의 합의된 정의를 지닐 때만 그렇습니다. 경쟁하는 끌림은 자율입니다. 각 팀이 자기 세계를 자기 속도로 모델링하고 싶어 하고, 공유 차원을 강제하면 단기적으로는 느려지지만 영역 전반에서 보답합니다. 가장 많은 팀 간 보고서에 나오는 두세 개의 차원을 가져와, 각각의 오늘 존재하는 모든 버전을 나열하고 키와 속성이 실제로 얼마나 갈라졌는지 보십시오. 각 정합 차원에 소유자의 이름을 정하십시오. 소유자 없는 공유 차원은 한 분기 안에 비공개 사본으로 되돌아가기 때문입니다. 한 부서의 수치가 다른 부서와 공개적으로 비교되는 기업과 정부 환경에서 정합되지 않은 차원은 정직한 비교와 우발적 거짓의 차이이므로, 어느 차원을 중앙에서 다스리고 어느 것을 지역에 둘지 일찍 결정하십시오.
정규화된 트랜잭션 시스템과 비정규화된 분석 모델 사이의 경계는 어디에 있으며, 모든 비정규화가 의도적인 결정입니까? 모델을 워크로드에 맞추는 것이 핵심 규율이지만, 그 경계가 바로 흐려지는 곳입니다. 분석가가 속도를 위해 웨어하우스 테이블을 비정규화하고, 엔지니어가 습관으로 보고 테이블을 정규화하며, 각 선택이 어느 쪽에 속하는지 아무도 적어 두지 않습니다. 긴장은 단일 질의의 속도 대 모든 것에 걸친 정확성과 유연성이며, 쓰기를 소유하느냐 읽기를 소유하느냐에 따라 합리적인 사람들이 다르게 귀결됩니다. 가장 느린 분석 질의와 가장 경합이 심한 트랜잭션 테이블을 가져와, 각 중복된 열에 대해 그 중복이 문서화된 이유로 선택되었는지 우연히 스며들었는지 물으십시오. 목표는 순수성 대회가 아니라 비정규화가 언제 허용되고 누가 승인하는지에 대한 서면 규칙입니다. 크거나 규제된 조직에서 이 경계는 개인 데이터가 어디서 중복되는지도 정하므로, 문서화되지 않은 비정규화는 성능의 문제이자 언젠가 누군가 감사자에게 설명해야 할 데이터 거버넌스 노출입니다.
시맨틱 계층을 만들어야 합니까, 사야 합니까? 존재하게 된 뒤 모든 지표 정의를 최신으로 유지하는 책임은 누구에게 있습니까? 시맨틱 계층은 소유되고 유지될 때만 단일 진실 원천을 줍니다. 그러므로 도구의 선택은 “매출”의 뜻 변경을 누가 리뷰하는지, 정의가 낡으면 누가 책임지는지의 답보다 덜 중요합니다. 경쟁하는 고려는 실제입니다. 구축은 통제를 주고 스택에 맞지만 엔지니어링 부담을 더하고, 지표 도구를 사는 것은 더 빠르지만 종속과 완전히 통제하지 못하는 정의 언어의 위험이 있습니다. 가장 판돈이 큰 소수의 지표, 오늘 그것을 소비하는 도구, 누군가 현재 그 정의를 소유하는지 아니면 그냥 존재하는지에 대한 정직한 판독을 가져오십시오. 정의가 지명된 소유자와 테스트가 있는 버전 관리되는 코드로 사는지 앞서 정하십시오. 아무도 유지하지 않는 시맨틱 계층은 그것이 대체하려던 흩어진 정의로 썩기 때문입니다. 공개 대시보드의 지표가 문서화되고 리뷰된 정의까지 추적 가능해야 하는 기업과 정부 보고에서, 그 소유권과 숫자의 계보를 증명할 수 있는 능력이 시맨틱 계층을 편의에서 감사 가능한 통제로 바꿉니다.

분야별 관점

스타트업. 모델링은 기다릴 수 있지만 정의는 기다릴 수 없습니다. 엔지니어가 둘이고 웨어하우스를 만들 자금이 없다면, 변환 도구에 작은 시맨틱 계층 하나를 두고 이사회가 실제로 지켜보는 두세 개 지표, “활성 사용자”와 “매출”을 테스트된 코드로 한 번 정의하십시오. 데이터 볼트와 정교한 차원 스키마는 건너뛰십시오. 얇은 스타와 소수의 거버넌스가 적용되는 정의가 전달을 늦추지 않고 일관된 숫자를 줍니다. 보답은 이사회 준비가 누구의 질의가 맞는지에 대한 논쟁이 아니게 된다는 것입니다.

소기업. 데이터 모델러도 지표 플랫폼에 쓸 예산도 없으니, 이미 운영하는 도구에 내장된 정의에 기대고 중요한 소수를 모두가 읽는 하나의 공유 문서에 적어 두십시오. 인력을 둘 수 없는 웨어하우스를 세우기보다 기존 소프트웨어에 내장된 분석을 사는 쪽을 선호하십시오. 모델링을 한다면 단순하게 하고 일관되게 이름을 붙이십시오. 내년에 그것을 유지하는 사람이 “고객”이 왜 두 가지 뜻이었는지 기억하지 못하는 바로 그 사람일 수 있기 때문입니다. 일관성이 조정보다 쌉니다.

대기업. 문제는 많은 팀과 많은 도구가 비공개 정의로 표류하는 것이므로, 정합 차원, 하나의 거버넌스가 적용되는 시맨틱 계층, 소유자와 리뷰가 있는 버전 관리되는 코드로서의 지표 정의에 투자하십시오. 한 도구의 숫자가 다른 도구의 같은 숫자와 일치하도록 명명, 그레인 선언, 천천히 변하는 차원 전략을 영역 전반에 표준화하십시오. 시맨틱 계층을 로드맵과 소유 팀이 있는 제품으로 다루고, 그것이 얼마나 많은 조정 시간을 없애는지 측정하십시오. 보답은 사업 전반의 신뢰할 수 있는 숫자와 이사회 자료에서 원천까지 깨끗하게 추적되는 감사입니다.

정부. 투명성과 기관 간 비교 가능성이 일을 형성합니다. 지리와 인구통계에 대한 정본 참조 데이터, 핵심 지표의 거버넌스가 적용되는 정의, 대중이 어떤 수치든 문서화된 정의까지 추적할 수 있도록 공표된 방법론과 버전 관리되는 릴리스입니다. 조달 규칙이 모델과 정의가 이식 가능하고 벤더 중립적으로 남도록 요구할 수 있으므로, 하나의 독점 도구에 묶인 시맨틱 계층을 피하십시오. 개별 기관이 운영 데이터를 모델링하는 것은 자유롭게 두되, 전국적으로 보고되는 모든 것은 공유 차원에 정합하게 하십시오. 버전 관리되는 정의까지 추적할 수 없는 공표된 지표는 데이터 문제만큼이나 책무의 실패입니다.

사례

스타트업. 시리즈 A 회사는 “활성 사용자”의 세 가지 정의가 세 곳, 곧 제품 분석 도구, 재무 스프레드시트, 투자자 자료에 살았습니다. 숫자는 결코 맞지 않았고, 모든 이사회 준비가 허둥지둥이 되었습니다. 두 엔지니어가 변환 도구에 작은 시맨틱 계층을 도입해, “활성 사용자”와 “월간 반복 매출”을 정확한 윈도우와 제외를 적은 테스트된 코드로 한 번 정의했습니다. 이제 모든 대시보드가 그 정의를 읽습니다. 이사회 준비 논쟁이 사라졌고, 새 분석가의 온보딩이 일주일의 암묵지에서 문서화된 모델 하나를 읽는 일로 줄었습니다. 이는 7.4장(제품 분석과 실험)에 기술된 규율과 직접 연결됩니다. “활성”의 안정적 정의가 실험 결과를 비교 가능하게 하기 때문입니다.

기업. 한 글로벌 소매업체는 마케팅, 재무, 공급망, 상품 기획, 매장에 걸쳐 다섯 개의 비즈니스 인텔리전스 도구를 운영했고, 각각이 “매출총이익”을 조금씩 다르게 재발명했습니다. 그들은 정합 차원이 있는 킴벌 방식 웨어하우스 위에 하나의 시맨틱 계층을 구축해, “제품”, “매장”, “날짜”가 모든 사실 테이블과 모든 도구에서 같은 뜻이 되게 했습니다. 각 지표는 한 번 정의되어 어디서나 소비되었습니다. 분기마다 며칠씩 먹던 조정 회의가 대부분 사라졌고, 재무가 반품이 마진에 영향을 주는 방식을 바꿨을 때 변경이 다섯 도구 모두에 한꺼번에 전파되었습니다. 정합 차원이 독립적인 팀이 의심 대신 자신감을 갖고 데이터를 조인하게 해 주었습니다.

정부. 한 국가 정부는 보건, 노동, 교육 기관에 걸친 비교 가능한 보고가 필요했는데, 각 기관이 역사적으로 “가구”, “지역”, “고용”을 자기 방식으로 정의했습니다. 한 기관 간 조직이 공유 참조 데이터와 표준 정의를 확립했습니다. 지리와 인구통계에 대한 정본 차원 테이블, 방법론과 버전 관리되는 릴리스와 함께 공표된 핵심 지표의 거버넌스가 적용되는 정의입니다. 개별 기관은 자기 운영 데이터를 모델링하되 전국적으로 보고되는 모든 것에는 공유 차원과 정의에 정합합니다. 그 결과 한 기관의 수치를 다른 기관의 것과 정직하게 비교할 수 있고, 대중이 공표된 어떤 지표든 문서화된 정의까지 추적할 수 있어, 7.1장에서 다룬 투명성 의무를 뒷받침합니다.

비즈니스 사례: 동기, ROI, TCO

좋은 모델링과 시맨틱 계층의 수익은 대부분 되찾은 시간과 피한 오류입니다. 많은 조직에서 분석가들은 시간의 대부분을 데이터를 찾고, 상충하는 숫자를 조정하고, 다른 사람들이 이미 쓴 정의를 다시 만드는 데 씁니다. 각 지표의 거버넌스가 적용되는 단일 정의는 그 반복된 작업을 일회성 투자로 바꿉니다. 또한 비싼 실패의 한 범주 전체를 없앱니다. 이사회 자료의 틀린 숫자, 감사 지적을 촉발하는 잘못 보고된 수치, 두 팀이 “매출”을 다르게 정의했기 때문에만 존재하는 한 분기짜리 조정 프로젝트입니다. 정의가 리뷰되는 한 곳에 살면 그런 실패는 대체로 멈춥니다.

비용은 실제이며 이름을 댈 가치가 있습니다. 개념 및 논리 모델링, 시맨틱 계층의 구축과 채우기, 정의를 최신으로 유지하는 지속적 소유권에 앞서 투자합니다. 총소유비용(TCO)에는 도구, 모델링과 분석 엔지니어링 시간, 모델의 드리프트를 막는 거버넌스가 포함됩니다. 이를 하지 않는 비용에 견주어 저울질하십시오. 더 크지만 숨어 있습니다. 중복된 파이프라인, 인간 조정 엔진이 된 분석가, 아무도 방어할 수 없는 수치로 확신에 찬 결정을 내리는 임원으로 나타납니다. 리더십에는 그들의 용어로 설득하십시오. 모든 지표의 하나의 신뢰할 수 있는 정의가 그들이 사업 전반을 비교하고, 대시보드를 신뢰하고, 비상 훈련 없이 규제 기관에 답하게 해 줍니다. 조정 고통이 가장 심한 곳에서 시작해 그 몇 개의 지표를 한 번 정의하고, 되찾은 시간이 나머지에 자금을 대게 하십시오.

안티패턴과 함정

물리 테이블로 곧장 뛰어들어, 그보다 오래가야 할 결정에 오늘의 기술을 굳혀 넣는 것.
같은 지표를 모든 대시보드에서 독립적으로 정의해 어떤 두 숫자도 일치하지 않는 것.
그레인을 진술하지 않아 매출 보고서에서 이중 집계된 측정값을 발견하는 것.
문서화된 결정이 아니라 우연으로 분석 테이블을 비정규화하는 것.
모든 질의가 아무도 이해하지 못하는 열두 테이블 조인이 될 때까지 분석 웨어하우스를 정규화하는 것.
천천히 변하는 차원을 덮어쓰기로 처리해 과거 보고서가 조용히 과거를 다시 쓰는 것.
어디서나 자연 키를 써서 원천 시스템의 키 변경이 웨어하우스 전체로 파급되는 것.
소유자 없이 시맨틱 계층을 만들어 정의가 표류하고 신뢰가 침식되는 것.
모델을 출시 때 끝난 것으로 다루고, 진화 가능하게 유지해야 하는 살아 있는 자산으로 다루지 않는 것.

성숙도 모델

1단계, 시작: 모델링이 암묵적이고 반응적입니다. 테이블은 필요한 누구든 물리 우선으로 설계합니다. 지표는 모든 보고서에서 재정의되고, 숫자는 일상적으로 충돌합니다. 그레인은 문서화되지 않고, 아무도 정의를 소유하지 않습니다.
2단계, 발전: 일부 분석 테이블이 차원 패턴을 따르고, 몇몇 핵심 지표에 서면 정의가 있지만 위키에 살며 시행되지 않습니다. 명명 관례는 서류상 존재합니다. 실천은 팀마다 다르고, 조정은 여전히 빈번하고 수동적입니다.
3단계, 표준화: 개념, 논리, 물리 모델이 구별되고 리뷰됩니다. 시맨틱 계층이 핵심 지표를 소유자가 있는 버전 관리되는 코드로 한 번 정의합니다. 정합 차원이 팀이 안전하게 조인하게 합니다. 그레인과 천천히 변하는 차원 전략이 문서화되어 조직 전체의 리뷰에서 시행됩니다.
4단계, 관리: 모델 영역이 기준선에 대해 측정됩니다. 지표 정의 커버리지(시맨틱 계층이 서비스하는 보고된 지표의 비율), 여전히 쓰이는 중복 또는 그림자 정의의 수, 분기당 쓴 조정 시간, 프로덕션 대비 리뷰에서 잡힌 그레인과 계보 결함의 비율을 추적합니다. 정의 변경은 테스트와 함께 리뷰된 풀 리퀘스트를 거치고, 최신성, 테스트 통과율, 드리프트가 대시보드에서 지켜집니다. 지표가 갈라지거나 차원이 정합하기를 멈추면, 측정이 이사회 회의보다 먼저 그것을 드러냅니다.
5단계, 오케스트레이션: 모든 중요한 지표에 모든 도구와 팀이 소비하는 하나의 거버넌스가 적용되는 정의가 있고, 시맨틱 계층이 분석, 실험, 규제 보고와 통합됩니다. 모델은 설계상 진화 가능하고 지속적으로 다듬어지며, 정의는 조직 전체에서 신뢰받고, 조정 작업은 대체로 사라졌습니다. 조직은 사업이 바뀜에 따라 새 차원을 일상적으로 폐기하고, 범위를 다시 정하고, 정합시키며, 모델 영역을 적응형 자산으로 재균형합니다.

논의를 위한 아이디어

가장 중요한 세 지표를 고르십시오. 오늘 도구 전반에 각각 몇 개의 구별되는 정의가 존재하며, 하나로 붕괴시키려면 무엇이 필요합니까?
진술되지 않은 그레인이 실제 보고 오류를 일으킨 곳은 어디이며, 알아채는 데 얼마나 걸렸습니까?
어떤 차원을 팀 전반에서 가장 먼저 정합시켜야 하며, 누가 소유합니까?
지표 정의가 리뷰와 함께 버전 관리되고 있습니까, BI 도구 안에서 조용히 편집 가능합니까?
천천히 변하는 차원이 아무도 모르게 이력을 마지막으로 다시 쓴 것은 언제이며, 다음에는 어떻게 잡겠습니까?
내일 웨어하우스 엔진을 교체한다면, 모델의 의미가 이전을 얼마나 살아남겠습니까?

핵심 요점

데이터 모델링은 데이터가 무엇을 뜻하는지 정하는 일이며, 그 의미는 선택하는 어떤 저장 기술보다 오래갑니다.
세 수준에서 순서대로 모델링하십시오. 개념, 그다음 논리, 그다음 물리.
트랜잭션 시스템은 정확성을 위해 정규화하고, 분석 시스템은 속도를 위해 의도적으로 비정규화하십시오.
분석에는 사실, 차원, 진술된 그레인이 있는 차원 모델링을 쓰십시오.
모든 비즈니스 지표가 어디서나 거버넌스가 적용되는 단일 정의를 갖도록 하나의 시맨틱 계층을 구축하십시오.
정합 차원은 독립적인 팀이 자신감을 갖고 데이터를 조인하고 비교하게 합니다.
이름을 잘 붙이고, 문서화하고, 대리 키를 쓰고, 정의의 버전을 관리해 모델이 진화 가능하게 유지하십시오.

참고 문헌과 더 읽을거리

Ralph Kimball and Margy Ross, The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modelling.
Bill Inmon, Building the Data Warehouse.
Dan Linstedt and Michael Olschimke, Building a Scalable Data Warehouse with Data Vault 2.0.
Peter Chen, “The Entity-Relationship Model: Toward a Unified View of Data,” ACM Transactions on Database Systems.
E. F. Codd, “A Relational Model of Data for Large Shared Data Banks,” Communications of the ACM.
C. J. Date, An Introduction to Database Systems.
Lars Rönnbäck and colleagues, writings on anchor modelling.
DAMA International, DAMA-DMBOK: Data Management Body of Knowledge.