Corporate Information Factory

Corporate Information Factory 는 회사의 분석 데이터를 한 저장소에서 먼저 통합한 뒤 부서로 나눠 주도록 짜는 설계입니다. 여러 운영 시스템에서 온 데이터를 이 저장소 하나에서만 맞춥니다. 부서가 쓰는 저장소는 그 통합본에서만 데이터를 받습니다.

쉽고 빠른 이해

회사의 분석 데이터를 한 저장소에 모아 맞추고, 부서는 거기서만 받아 가게 짜는 설계입니다. 마케팅 부서와 회계 부서가 각자 쓰는 저장소를 그 한 저장소에서 채워 넣는 식입니다.

부서마다 운영 시스템에서 따로 뽑아 가면 뽑아 오는 프로그램이 거미줄처럼 얽힙니다. 같은 질문에 부서마다 다른 숫자가 나옵니다. 어느 숫자가 옳은지 가릴 기준도 없어집니다.

1. 운영 시스템에서 데이터를 뽑아 키와 구조와 코드를 회사 하나의 기준으로 맞춥니다
2. 맞춘 데이터를 합계가 아니라 가장 잘게 쪼갠 단위로, 옛 값까지 함께 그 한 저장소에 쌓습니다
3. 부서가 쓸 저장소는 그 한 저장소에서만 채웁니다

대가가 있습니다. 통합이 끝나야 첫 부서 저장소를 세울 수 있어서 오래 걸립니다. 같은 상세 데이터를 두 번 넣고 두 벌로 저장하게 됩니다.

상세

이 설계가 두는 구성 요소 열한 가지와 그 사이의 데이터 방향을 봅니다. 재는 것은 한가운데 웨어하우스가 무엇을 담는지와 부서용 저장소가 어디서만 데이터를 받는지입니다.

줄여서 CIF(Corporate Information Factory)라고 씁니다. Inmon 아키텍처라는 별칭도 있습니다. 이름을 세운 사람의 이름이 그대로 붙은 것입니다.

허브 앤 스포크(hub and spoke) 아키텍처라는 이름도 함께 쓰입니다. 한가운데 웨어하우스가 축이고 부서용 저장소가 바큇살입니다. 하향식(top-down) 설계로 분류되는 쪽이 많습니다. 회사 전체의 정규화 모델을 먼저 설계하고 거기서 부서용 마트를 만들어 내려가는 순서이기 때문입니다.

한가운데에 서는 웨어하우스

CIF 의 한가운데에는 회사 전체가 함께 쓰는 데이터 웨어하우스 하나가 섭니다. 이 웨어하우스가 엔터프라이즈 데이터 웨어하우스, 줄여서 EDW(Enterprise Data Warehouse)입니다.

데이터 웨어하우스의 정의는 주제별로 모이고, 통합되어 있고, 시간에 따라 갈리고, 한 번 들어오면 바뀌지 않는 데이터 모음입니다. 시간에 따라 갈린다는 것은 한 시점의 모습을 찍어 쌓아 둔다는 뜻입니다. 회사의 전략 의사결정을 받치려고 둡니다. EDW 가 담는 것은 넷으로 꼽힙니다 — 가장 잘게 쪼갠 단위, 통합된 것, 이력, 그리고 회사 전체의 것입니다.

데이터는 가장 잘게 쪼갠 단위로 둡니다. 월별 합계가 아니라 기록 한 건 한 건입니다. 잘게 둔 덕에 같은 데이터를 지금은 회계의 것으로, 다음 순간에는 마케팅의 것으로, 그 다음에는 영업의 것으로 바꿔 보일 수 있습니다.

이력을 넉넉히 쌓습니다. 많게는 10년치를 담습니다. 웨어하우스 층에 들어온 데이터는 통합된 이력이고 갱신되지 않습니다.

내부 구조는 정규화되어 있습니다. 정규화된 테이블은 키와 외래 키와 속성을 갖습니다. 그 테이블의 모든 데이터는 키에 매달려 존재합니다. 테이블끼리는 키와 외래 키로 이어집니다. 완전히 정규화된 것은 아닙니다 — 가볍게 역정규화되기도 합니다. 역정규화는 정규화로 잘게 나눠 둔 것을 다시 합쳐 두는 설계입니다. 제3정규형(3NF, third normal form) 데이터베이스라는 표현은 Kimball 쪽 요약이 쓰는 말입니다.

모든 부서가 믿고 쓰는 한 벌의 데이터를 단일 진실 버전(single version of the truth)이라고 합니다. CIF 에서는 EDW 가 그 한 벌입니다. 두 사람이 분석 결과를 두고 다투면 여기를 기준으로 맞춰 봅니다.

CIF 를 고른 조직에서는 분석 사용자가 EDW 를 직접 조회하는 경우가 많습니다. 데이터가 상세해서, 또는 데이터가 도착하는 시점이 빨라서 그렇게 씁니다.

원천에서 웨어하우스까지

데이터가 처음 생기는 곳은 회사의 일상 업무를 받치는 운영 시스템입니다. ERP(Enterprise Resource Planning, 전사적 자원 관리)와 관계형 데이터베이스와 레거시 시스템이 모두 여기 듭니다. 운영 시스템은 웨어하우스와 운영 데이터 저장소에 데이터를 내주는 쪽입니다.

운영 시스템의 데이터는 먼저 데이터 획득 계층을 지납니다. 통합·변환 계층이라는 이름으로도 부르는 같은 계층입니다. 이 계층은 원천 데이터를 잡아내고 통합하고 변환하고 씻어 내고 다시 짜서 웨어하우스와 운영 데이터 저장소에 적재합니다. 뽑고 바꾸고 넣는 이 작업이 ETL(Extract, Transform, Load, 추출·변환·적재)입니다.

무엇을 맞추는지가 이 계층의 몫입니다. 키를 바꿔 회사 하나의 이해로 만들고, 구조를 바꾸고, 인코딩 규칙을 통일합니다. 데이터는 통합되지 않은 상태로 이 계층에 들어가 통합된 상태로 나옵니다.

통합하지 않고 운영 환경에서 그냥 옮겨 오면 회사 전체의 관점을 받칠 수 없습니다. 손이 많이 가고 오래 걸리는 작업입니다. 다만 한 번만 하면 됩니다.

운영 데이터 저장소

CIF 는 지금 이 순간의 통합된 모습을 보여 주는 저장소를 따로 둡니다. 운영 데이터 저장소, 줄여서 ODS(Operational Data Store)입니다. 주제별로 모이고 통합되어 있으며 지금 값을 담고 자주 바뀌는 데이터 모음입니다. 전략 의사결정이 아니라 전술 의사결정을 받칩니다.

ODS 는 웨어하우스와 운영 시스템의 성질을 반반씩 가진 잡종입니다. 그래서 짓고 굴리기가 어렵습니다. 2~3초의 거래 응답 시간과 갱신 기능과 분석 기능을 함께 내줍니다. 데이터를 ODS 에 직접 갱신할 수 있습니다. 이력은 적게 담습니다 — 보통 2~3주치입니다.

화살표는 데이터 획득 계층에서 ODS 로 들어오는 것 하나만이 아닙니다. ODS 는 EDW 로도 데이터를 흘려보냅니다. 거꾸로 EDW 에서 집계되어 ODS 로 되돌아오는 갈래도 있습니다.

데이터 마트

부서가 실제로 쿼리하는 저장소는 데이터 마트입니다. 웨어하우스에서 끌어온 데이터를 그 부서나 업무 기능의 분석 요구에 맞게 다듬거나 요약해 담습니다. 마케팅·회계·보험계리처럼 부서마다 하나씩 섭니다. 부서가 자기 웨어하우스 설비를 직접 쥐고 관리하게 되는 셈입니다.

마트는 EDW 에서만 데이터를 받습니다. CIF 에서 마트의 유일한 데이터 출처는 웨어하우스입니다. 웨어하우스에서만 받는 마트가 종속 데이터 마트입니다. 하나 이상의 운영 시스템에서 바로 지은 마트는 독립 데이터 마트입니다. 독립 데이터 마트는 CIF 의 한 부분이 아닙니다.

마트 안의 구조는 대개 스타 조인입니다. 스타 조인은 더할 숫자를 담은 테이블 하나에 그 숫자를 가를 기준을 담은 테이블 여러 개를 매단 모양입니다. 그렇게 짠 모델이 차원 모델입니다. 쓰임 패턴이 예측되고 데이터가 많은 곳에 스타 조인을 만듭니다. 패턴이 예측되지 않는 곳은 관계형 테이블로 설계합니다. 마트의 데이터는 웨어하우스의 것과 달리 역정규화되고 요약되어 있습니다. 모양은 한 부서의 운영 요구에 맞춰 정해집니다.

두 저장소의 모양을 나란히 놓으면 이렇습니다.

flowchart TD
    subgraph EDW["엔터프라이즈 데이터 웨어하우스 · 정규화"]
        A1["테이블 가<br/>키 · 속성"]
        A2["테이블 나<br/>키 · 외래 키 · 속성"]
        A3["테이블 다<br/>키 · 외래 키 · 속성"]
        A2 -->|"외래 키 → 키"| A1
        A3 -->|"외래 키 → 키"| A1
        A3 -->|"외래 키 → 키"| A2
    end
    subgraph MART["데이터 마트 · 스타 조인"]
        F["더할 숫자를 담은 테이블"]
        K1["가를 기준을 담은 테이블"]
        K2["가를 기준을 담은 테이블"]
        K3["가를 기준을 담은 테이블"]
        K4["가를 기준을 담은 테이블"]
        K1 --> F
        K2 --> F
        K3 --> F
        K4 --> F
    end

위쪽 웨어하우스에서는 테이블이 키와 외래 키로 서로 이어져 그물처럼 놓입니다. 아래쪽 마트에서는 더할 숫자를 담은 테이블 하나에 가를 기준을 담은 테이블들이 매달려 별 모양이 됩니다.

EDW 는 마트보다 큽니다. 보통은 훨씬 큽니다. 두 저장소가 갈리는 축은 넷입니다. 크기 차이의 까닭으로 꼽히는 것도 그 넷입니다.

웨어하우스는 아직 모르는 쓰임까지 받으려고 상세 데이터를 단순한 구조로 쌓아 둡니다. 마트는 알려진 요구에 맞춰 집계한 것만 담습니다.

나머지 구성 요소

앞의 다섯 말고 구성 요소가 여섯 더 있습니다. 합해서 열한 가지입니다.

전체 흐름

flowchart TD
    S["운영 시스템<br/>ERP · 관계형 · 레거시"]
    A["데이터 획득 계층<br/>통합과 변환"]
    W["엔터프라이즈 데이터 웨어하우스<br/>정규화 · 가장 잘게 · 이력"]
    O["운영 데이터 저장소<br/>지금 값 · 자주 바뀜"]
    D["데이터 전달"]
    E["탐색 웨어하우스 ·<br/>데이터 마이닝 웨어하우스"]
    subgraph M["데이터 마트 · 대개 스타 조인"]
        M1["마케팅"]
        M2["회계"]
        M3["보험계리"]
    end
    S --> A
    A --> W
    A --> O
    O --> W
    W -->|"집계해 되돌림"| O
    W --> D
    D --> M1
    D --> M2
    D --> M3
    W --> E

데이터는 대개 위에서 아래로 흐릅니다. 마트가 운영 시스템에서 바로 받아 가는 화살표는 없습니다. 양쪽으로 서는 화살표는 운영 데이터 저장소와 웨어하우스 사이뿐입니다. 웨어하우스는 마트 말고도 탐색 웨어하우스와 데이터 마이닝 웨어하우스에 데이터를 내줍니다.

이 그림이 그리는 것은 데이터가 지나가는 본류뿐입니다. 주 저장 관리와 대체 저장소와 메타데이터 관리는 그 옆에 서는 구성 요소라 빠져 있습니다.

버스 아키텍처와 갈리는 곳

같은 역할을 두고 겨루는 설계는 Kimball 쪽의 엔터프라이즈 데이터 웨어하우스 버스 아키텍처입니다. 버스 아키텍처는 한가운데의 정규화된 저장소를 필수로 두지 않습니다. ETL 처리를 받치려고 정규화를 두는 것은 선택으로 열려 있습니다. Kimball 쪽은 상세 데이터를 미리 정규화해 두는 것을 권하지는 않지만 아주 금하지도 않습니다. CIF 에서는 반대로 정규화된 EDW 가 빼놓을 수 없는 구성물입니다.

숫자를 맞추는 방법도 다릅니다. 버스 아키텍처는 업무마다 차원 모델을 짓습니다. 그 모델들은 공통 차원 테이블을 나눠 씁니다. 여러 모델이 함께 쓰는 차원 테이블이 컨폼드 디멘션입니다.

두 설계가 같은 곳도 있습니다. 둘 다 회사 차원의 데이터 조율과 통합을 내세웁니다. 갈리는 것은 그 일을 정규화된 중앙 웨어하우스가 맡느냐 공통 차원 테이블이 맡느냐입니다.

대가

이 설계를 고른 순간 확정되는 값을 봅니다. 통합 작업과 두 단계로 나뉜 적재 경로를 봅니다. 재는 것은 첫 결과까지의 시간, 같은 데이터를 두 번 다루는 값, 상세 데이터를 꺼내 쓰는 길입니다.

통합이 먼저 끝나야 한다

마트를 짓기 전에 웨어하우스를 지어야 합니다. 그리고 웨어하우스를 짓는 데는 시간이 걸립니다.

제일 큰 일거리는 응용 시스템의 데이터를 회사 데이터로 다시 짜는 통합입니다. 레거시 데이터가 이 일을 어렵게 만드는 대목이 넷입니다.

• 문서가 없는 경우가 많습니다
• 몇 해 전부터 지원이 끊긴 기술 위에 놓여 있는 경우도 많습니다
• 애초에 합칠 생각 없이 설계된 응용 시스템들을 합쳐야 하는 경우도 많습니다
• 데이터의 정의 자체를 다시 세워야 하는 경우도 있습니다

이 일은 모두 지루합니다. 그래도 규율을 지켜 정확하게 해야 합니다.

그래서 Kimball 쪽의 단순한 차원 아키텍처보다 시간과 자원이 더 듭니다. 범위가 회사 전체이기 때문입니다.

단순한 차원 아키텍처는 회사 전체의 정규화 웨어하우스 없이 차원 모델만 지어 쓰는 것입니다. Inmon 쪽은 이것을 Kimball 방식의 1단계로 부릅니다. 앞 절에서 견준 버스 아키텍처는 그런 차원 모델 여럿을 공통 차원 테이블로 묶은 것이라 같은 것이 아닙니다.

통합할 것이 적은 작은 조직에서는 이 값이 작습니다. 조직이 클수록 통합 과정이 고되고 오래 걸립니다.

그래서 이 값을 치를 이유도 조직 크기에 따라 갈립니다. 데이터가 적은 작은 조직에서는 중앙 웨어하우스 없이 차원 모델 하나만 지어도 충분할 수 있습니다. 데이터가 많고 회사 전체의 통합이 필요한 큰 조직에서는 그 단순한 아키텍처가 머지않아 문제가 됩니다. 다만 그 단순한 아키텍처에는 회사 전체의 단일 진실 버전이 없습니다.

이 시간을 두고 Inmon 본인의 말이 엇갈립니다. 한쪽 글은 웨어하우스를 짓는 것이 쉽지도 짧지도 않은 일이라고 적습니다. 다른 글은 웨어하우스를 작고 짧은 걸음으로 쪼개 지으면 짧은 시간에 결과가 난다고 적습니다. 그 글은 「큰 한 방」 식으로 짓는 것이 권해 온 전략이 아니었다고 덧붙입니다.

같은 데이터를 두 번 다룬다

원천에서 웨어하우스로 한 번, 웨어하우스에서 마트로 또 한 번 적재합니다. 적재 작업이 두 벌이고 저장도 두 벌입니다. 단계가 하나 더 있으니 마트에 데이터가 닿는 시각도 그만큼 밀립니다.

정규화해도 그 자체가 통합을 해 주지는 않습니다. 정규화는 다대일 관계를 물리 테이블로 만드는 일입니다. 앞에서 본 키와 외래 키 구조가 그 결과입니다. 서로 안 맞는 원천들을 끝까지 정규화해 놓고도 통합에는 손을 안 댄 상태일 수 있습니다. 원천마다 다른 키와 이름을 맞추는 일은 그래서 따로 해야 합니다.

요약에서 상세로 내려가는 길

요약만 차원 모델이고 상세 데이터는 정규화 구조에 남습니다. 그래서 요약에서 상세로 파고들려 하면 벽에 부딪히는 일이 흔합니다. 두 구조가 많이 달라서 양쪽을 아는 사람이 끼어들어야 합니다.

마트로 내보내는 처리가 단순 요약을 넘는 규칙을 적용하면 이 길이 더 멀어질 수 있습니다. 부서별로 열 이름을 바꾸거나 다른 계산식을 쓰면 마트의 숫자를 웨어하우스의 상세 데이터에 맞대 보기가 어려워질 수 있습니다.

예시

이 설계가 실제로 어떻게 그려지고 어떤 값으로 굴러가는지 봅니다. 보는 것은 발표된 구성도 셋에 적힌 구성 요소 이름과, 운영 데이터 저장소의 네 등급을 가르는 기준입니다.

발표된 구성도 셋의 구성 요소 이름

아래 표의 이름은 그림에 적힌 영어 그대로입니다. OLAP(Online Analytical Processing)은 온라인 분석 처리, BI(Business Intelligence)는 비즈니스 인텔리전스를 줄인 것입니다.

세 그림은 같은 구조를 가리킵니다. 이름은 조금씩 다르게 붙입니다. 데이터 획득 계층은 integration/transformation 과 Data Acquisition 으로 갈립니다. 부서용 저장소는 data marts 와 OLAP Data Mart 로 갈립니다. 겨루는 쪽이 그린 그림은 마트 칸에 Often summarized · Often departmental 이라는 한정어를 달아 두었습니다.

Inmon 의 그림 3 은 같은 구조에서 두 저장소의 모양만 떼어 나란히 적습니다 — 마트 쪽에 star joins, 엔터프라이즈 데이터 웨어하우스 쪽에 normalized; granular 입니다. 스타 조인은 하나하나가 서로 다르게 생깁니다.

운영 데이터 저장소의 네 등급

운영 환경에서 일이 벌어진 때부터 그 갱신이 ODS 에 비치는 때까지의 지연으로 앞의 세 등급이 갈립니다. 넷째 등급은 지연이 아니라 데이터가 오는 방향으로 갈립니다.

공저자 Imhoff 가 적은 값은 조금 다릅니다. 손님 연락처처럼 몇 초 안에 반영해야 하는 것이 class I 입니다. class II 는 30분이나 한 시간마다 갱신을 받습니다. class III 은 대개 하루 한 번 배치로 적재됩니다.

이 설계로 지었다고 이름을 밝힌 조직은 확인되지 않습니다(미확인).

배경

분석에 쓸 데이터를 부서마다 운영 시스템에서 직접 뽑아 가던 때가 있었습니다. 뽑은 것에서 또 뽑고 거기서 또 뽑으면서 뽑아 오는 프로그램이 거미줄처럼 얽혔습니다. 큰 회사가 하루 45,000 번씩 추출을 돌리는 일도 드물지 않았습니다.

통제를 벗어난 추출이 이렇게 흔해져서 「자연 발생 아키텍처(naturally evolving architecture)」라는 이름까지 붙었습니다. 조직이 크고 오래될수록 문제가 심해졌습니다.

세 가지가 문제였습니다. 데이터를 믿을 수 없었고, 생산성이 떨어졌고, 데이터를 정보로 바꿀 수 없었습니다.

두 부서가 경영진에 보고를 올립니다. 한쪽은 활동이 15퍼센트 줄었다고 하고 다른 쪽은 10퍼센트 늘었다고 합니다. 두 숫자를 맞춰 보기도 어렵습니다. 아주 꼼꼼히 문서를 남겨 두지 않았다면 실질적으로 불가능합니다. 어느 쪽이 더 믿을 만하지도 않으니 경영진은 정치와 인물로 결정하게 됩니다.

flowchart TD
    subgraph L0["운영 시스템"]
        S1["응용 시스템 하나"]
        S2["응용 시스템 둘"]
    end
    subgraph L1["1차 추출"]
        E1["추출"]
        E2["추출"]
        E3["추출"]
    end
    subgraph L2["추출에서 또 뽑은 2차 추출"]
        E4["추출"]
        E5["추출"]
        E6["추출"]
    end
    subgraph L3["거기서 또 뽑은 3차 추출 · 아래로도 이어진다"]
        E7["추출"]
        E8["추출"]
    end
    S1 --> E1
    S1 --> E2
    S2 --> E2
    S2 --> E3
    E1 --> E4
    E2 --> E4
    E2 --> E5
    E3 --> E6
    E4 --> E7
    E6 --> E8
    E7 --> R1["부서 한쪽의 보고<br/>활동 15퍼센트 감소"]
    E8 --> R2["부서 다른 쪽의 보고<br/>활동 10퍼센트 증가"]

층마다 추출이 앞 층의 추출을 입력으로 삼습니다. 그래서 두 부서의 보고는 같은 운영 데이터에서 출발했는데도 거미줄의 서로 다른 가지 끝에 걸립니다. 가지를 거꾸로 따라 올라가 두 숫자를 맞춰 보는 일이 그래서 어렵습니다.

거미줄에서 정보를 꺼내는 값도 비싸고 만드는 데도 오래 걸립니다.

필요한 것은 현상 유지보다 큰 것, 곧 아키텍처를 바꾸는 일이었습니다. 그래서 설계된 데이터 웨어하우스가 들어옵니다. 데이터는 네 층으로 갈립니다. 운영 층, 웨어하우스 층, 마트 층, 그리고 개인 층입니다.

웨어하우스 층은 앞에서 본 가장 잘게 쪼갠 단위를 담는 층이고 원자 층이라는 이름도 씁니다. 마트 층에는 부서 층이라는 이름도 붙습니다. 개인 층은 사람이 짐작을 세워 가며 직접 뒤져 보는 분석이 일어나는 층입니다.

이 네 층이 더 큰 아키텍처의 바탕이 됩니다. 그 아키텍처에 붙은 이름이 Corporate Information Factory 입니다. 이 설계가 서기 전에는 데이터가 넘쳤습니다. 그런데 어느 데이터가 옳고 어느 데이터가 틀렸는지 알 수 없었습니다.

경계

한가운데에 정규화된 웨어하우스를 두고 그 아래 마트를 차원 모델로 지은 꼴도 Corporate Information Factory 인가.

맞습니다. 마트를 차원 모델로 짓는 것은 이 설계가 원래 적어 온 모양입니다. 마트 안의 구조는 스타 조인입니다. 겨루는 쪽이 그린 구성도도 CIF 의 마트 칸을 Dimensional 로 적습니다.

이름을 세운 사람 자신도 한가운데에 이 설계를 두고 둘레에 Kimball 식 스타 스키마 마트를 붙인 배치를 그려 두었습니다. 그 배치에서도 마트의 데이터 출처는 웨어하우스 하나입니다. 다만 본인은 그 배치를 두 아키텍처를 섞은 것이라고 부릅니다.

선이 그어지는 곳은 다른 데입니다. 같은 배치에서 중앙 웨어하우스를 분석 사용자에게 아예 닫아 버립니다. 그리고 부서별이 아니라 업무별로 짠 차원 모델들이 공통 차원 테이블을 기준으로 통합을 맡습니다. 겨루는 쪽 저자들은 이 배치를 CIF 와 자기 방식의 결합이라고 따로 부릅니다.

그러니 마트의 모양만으로는 이 설계를 벗어나지 않습니다. 통합의 기준이 중앙 웨어하우스에서 공통 차원 테이블로 옮겨 간 꼴은 이 설계 하나로 부르지 않습니다.

관련 항목

CIF 를 이루는 구성 요소

원천 · ETL · 데이터 획득 · 엔터프라이즈 데이터 웨어하우스 · 운영 데이터 저장소 · 데이터 마트 · 종속 데이터 마트 · 데이터 전달 · 탐색 웨어하우스 · 데이터 마이닝 웨어하우스 · 대체 저장소 · 오퍼 마트 · 메타데이터 · 스테이징 영역

CIF 가 속하는 상위 분류

데이터 웨어하우스 · 데이터 엔지니어링 · 데이터 아키텍처 · 데이터 관리 · 소프트웨어 아키텍처

CIF 안에서 쓰는 모델링 방법

정규화 · 제3정규형 · 엔티티-관계 모델링 · 데이터 모델링 · 차원 모델링 · 스타 조인 · 스타 스키마 · 팩트 테이블 · 차원 테이블 · 컨폼드 디멘션

CIF 와 같은 역할을 맡는 다른 웨어하우스 구조

엔터프라이즈 데이터 웨어하우스 버스 아키텍처 · 독립 데이터 마트 · DW 2.0 · 데이터 볼트 · 메달리온 아키텍처 · 데이터 레이크 · 데이터 레이크하우스 · 데이터 메시

CIF 가 지키려는 성질과 설계 원칙

단일 진실 버전 · 데이터 통합 · 데이터 품질 · 데이터 계보 · 허브 앤 스포크 · 하향식 설계 · 데이터 독립성

CIF 가 데이터를 넘겨받고 내주는 처리 방식

OLTP · OLAP · 배치 처리 · 변경 데이터 캡처 · 비즈니스 인텔리전스 · 데이터 분석 · 데이터 시각화