데이터 메시 및 분산형 데이터 아키텍처
30년 넘게 엔터프라이즈 데이터 아키텍처는 중력 모델을 따라왔습니다. 모든 데이터는 하나의 중앙 지점에 모여 전문 팀이 관리합니다. 전체 조직의 병목 현상으로 작용합니다. 모놀리식 데이터 웨어하우스, 데이터 레이크 이전 기사에서 살펴본 최신 데이터 레이크하우스도 중앙 집중화되어 있습니다. 그들은 모두 동일한 아키텍처 가정을 공유합니다. 즉, 데이터는 수집, 단일 팀에서 처리 및 서비스 제공.
이 모델은 조직이 작고 도메인이 소규모인 한 합리적으로 잘 작동했습니다. 비즈니스 규모가 거의 없었고 데이터 볼륨도 관리할 수 있었습니다. 하지만 회사가 어느 정도 성장하면 수십 개의 제품 팀, 수백 개의 데이터 소스, 페타바이트 규모의 정보, 모델 중앙 집중식 시스템은 자체 무게로 인해 붕괴됩니다. 중앙 데이터 엔지니어가 병, 요청 대기열이 점점 길어지고 배송 시간이 분기 단위로 측정됩니다. 데이터를 생산하는 사람이 이에 대해 책임을 지지 않기 때문에 데이터 품질이 저하됩니다.
2019년에는 자막 데가니, 그 후 ThoughtWorks의 컨설턴트가 공식화했습니다. 근본적으로 다른 패러다임: 데이터 메시. 이것은 새로운 것이 아닙니다. 기술 또는 새로운 도구이지만 조직 및 아키텍처 사고 방식의 변화 Domain-Driven Design과 플랫폼 사고의 원칙을 데이터 세계에 적용하는 것입니다. 데이터 메시는 마이크로서비스가 애플리케이션 세계에 있었던 것처럼 데이터 세계에 있습니다. 비즈니스 영역에 따른 책임의 분산입니다.
2024년 Gartner 분석에 따르면 대규모 조직의 25%가 이니셔티브를 시작했습니다. 데이터 메시의 비율은 2027년까지 50%에 이를 것으로 예상됩니다. 시장 데이터 메시 및 데이터 패브릭 플랫폼의 규모는 2025년에 42억 달러를 초과할 것입니다. 연평균 성장률(CAGR)은 22%입니다.
이 기사에서 배울 내용
- 중앙 집중식 데이터 모델은 복잡한 조직에서는 확장되지 않기 때문입니다.
- Zhamak Dehghani의 데이터 메시의 네 가지 기본 원칙
- 구체적인 예를 통해 DDD 경계 컨텍스트를 데이터 도메인에 매핑하는 방법
- 데이터 제품이란 무엇이며 데이터 계약, SLA 및 품질 지표를 정의하는 방법
- 셀프 프로비저닝 셀프 서비스 데이터 플랫폼 아키텍처
- 연합 컴퓨팅 거버넌스: 코드형 정책 및 자동화된 규정 준수
- 코드를 통한 실제 구현: 데이터 계약, DBT 모델, API 및 파이프라인
- 비교표를 이용한 Data Mesh와 Data Fabric의 비교
- 실제 사례 연구: Zalando, Netflix, JPMorgan Chase, Intuit
- 과제, 안티 패턴 및 데이터 메시를 채택하지 말아야 할 경우
- 이탈리아 상황: 중소기업, 문화적 과제 및 PNRR 기회
데이터 웨어하우스, AI 및 디지털 혁신 시리즈 개요
| # | Articolo | 집중하다 |
|---|---|---|
| 1 | 데이터 웨어하우스의 진화 | SQL Server에서 데이터 레이크하우스로 |
| 2 | 현재 위치 - 데이터 메시 및 분산 아키텍처 | 데이터를 분산화 |
| 3 | 클라우드의 ETL과 ELT | 최신 데이터 파이프라인 |
| 4 | 비즈니스를 위한 AI 및 머신러닝 | 비즈니스 예측 모델 |
| 5 | 실시간 분석 | 스트리밍 및 실시간 결정 |
| 6 | 데이터 품질 및 관찰 가능성 | 데이터 상태 모니터링 |
| 7 | PNRR과 디지털 혁신 | 이탈리아 중소기업을 위한 기회 |
| 8 | 엔드투엔드 실제 사례 | 데이터 레이크하우스를 처음부터 구축하기 |
중앙 집중식 데이터 웨어하우스의 문제
데이터 메시를 탐색하기 전에 데이터 메시가 해결하는 문제를 이해하는 것이 중요합니다. 모델 중앙 집중식 데이터는 본질적으로 잘못된 것이 아닙니다. 수십 년 동안 기업에 큰 도움이 되었습니다. 그러나 특정 조직 규모를 넘어서는 지속 불가능해지는 구조적 한계가 있습니다.
중앙데이터팀의 병목현상
중앙 집중식 데이터 웨어하우스를 갖춘 일반적인 조직에는 단일 데이터 팀이 있습니다. 엔지니어링(종종 5~15명)이 회사 전체에 서비스를 제공합니다. 생성부터 모든 요청 데이터 품질 이상 현상을 수정하기 위한 새로운 파이프라인이 이 팀을 통해 전달됩니다. 그 결과는 예측 가능합니다. 몇 주 동안 계속되는 대기열, 고통스러운 우선순위 지정 및 만연한 좌절감입니다.
20개의 제품팀이 있는 회사에서 중앙 데이터 팀은 평균 150~200개의 요청을 받습니다. 분기당. 분기당 30-40개 작업의 전달 능력으로 요청의 80% 대기열에 머물다. 기다림에 좌절한 도메인 팀은 섀도우 솔루션 구축을 시작합니다. Excel 내보내기, 로컬 데이터베이스, 누구도 유지 관리하지 않는 임시 스크립트.
중앙집권형 모델의 5가지 구조적 문제
- 조직의 병목 현상: 중앙 데이터 팀이 제한 요소가 됨 전체 조직의. 데이터가 필요한 각각의 새로운 기능은 용량에 따라 제한됩니다.
- 도메인 컨텍스트 누출: 중앙 데이터 엔지니어는 도메인을 모릅니다 사업에 대해 심도 있게 설명합니다. 그들은 새로운 파이프라인이 나올 때마다 도메인 전문가와 인터뷰를 해야 합니다. 요구 사항 번역의 중요한 뉘앙스.
- 광범위한 소유권: 판매 데이터의 품질은 누가 책임지나요? 이를 생산하는 영업팀인가요, 아니면 이를 변환하는 데이터팀인가요? 중앙 집중식 모델에서는 대답은 모호하며, 모호함은 품질 저하를 초래합니다.
- 건축적 결합: 모든 파이프라인은 동일한 DWH로 수렴됩니다. 암시적 종속성을 생성합니다. "주문" 도메인의 데이터 모델 변경으로 인해 중단될 수 있음 "물류", "금융" 및 "마케팅" 파이프라인을 동시에 수행합니다.
- 선형 확장성: 중앙 집중식 모델은 사람을 추가해야만 확장됩니다. 중앙팀으로. 그러나 브룩스의 법칙은 프로젝트에 사람을 추가한다는 것을 가르쳐줍니다. 지연으로 인해 조정 비용으로 인해 속도가 더욱 느려집니다.
중앙집중화의 역설
역설적인 점은 회사가 중앙 집중식 데이터 웨어하우스에 더 많이 투자할수록 데이터 팀이 더 많이 필요하다는 것입니다. 병목 현상이 발생하면 도메인 팀이 대체 솔루션을 더 많이 찾을수록 데이터가 더 많아집니다. 그들은 관리되지 않는 사일로로 조각화됩니다. 중앙 집중식 모델은 주장하는 문제를 생성합니다. 해결하다. 그리고 이것이 데이터 메시가 탄생한 맥락입니다. 기술이 아닌, 조직의 문제에 대한 조직의 대응.
데이터 메시의 4가지 기본 원칙
2019년 Zhamak Dehghani가 공식화하고 그의 저서에서 심층적으로 탐구한 데이터 메시 "데이터 메시: 대규모 데이터 기반 가치 제공"(2022)은 네 가지 원칙을 기반으로 합니다. 채택해야 할 기본 사항 함께. 글라이드 없이 바르세요 다른 것들은 차선책이거나 심지어 비생산적인 결과로 이어집니다.
데이터 메시의 네 가지 기둥
| 원칙 | 설명 | 유추 |
|---|---|---|
| 1. 도메인 중심 소유권 | 도메인 팀은 자체 데이터를 소유하고 관리합니다. | 마이크로서비스와 마찬가지로 각 팀은 자체 서비스를 소유합니다. |
| 2. 상품으로서의 데이터 | 데이터는 SLA, 품질 및 문서를 갖춘 제품으로 취급됩니다. | 공개 API와 유사: 계약, 버전 관리 및 지원이 있습니다. |
| 3. 셀프 서비스 데이터 플랫폼 | 데이터 생산 및 소비 비용을 절감하는 내부 플랫폼 | 내부 PaaS로서: 자동 프로비저닝, 템플릿, 가드레일 |
| 4. 연합 컴퓨팅 거버넌스 | 코드형 정책을 통한 자동화된 거버넌스, 상호 운용성 보장 | 표준 및 프로토콜: 웹용 HTTP, 데이터용 데이터 계약 |
구체적인 예와 아키텍처적 의미를 통해 각 원칙을 자세히 살펴보겠습니다.
원칙 1: 도메인 중심 데이터 소유권
데이터 메시의 첫 번째 원칙은 데이터에 대한 책임을 뒤집는 것입니다. 즉, 더 이상 중앙 팀이 아닙니다. 회사의 모든 데이터를 소유하고 있지만 각 도메인 팀은 소유, 생산 및 서비스를 제공합니다. 당신의 데이터. 이 원칙은 다음에서 직접적으로 영감을 받았습니다. 도메인 중심 설계 (DDD) Eric Evans의 특히 개념에 대해 제한된 컨텍스트.
바인딩된 컨텍스트를 데이터 도메인에 매핑
DDD의 제한된 컨텍스트는 도메인 모델이 다음을 갖는 의미론적 경계입니다. 정확하고 모호하지 않은 의미. 데이터 메시에서 각 바인딩된 컨텍스트는 잠재적인 컨텍스트가 됩니다. 데이터 도메인 귀하의 팀, 귀하의 데이터 및 귀하의 책임과 함께.
구체적인 예를 들어보겠습니다. 중형 전자상거래 플랫폼입니다. 방법은 다음과 같습니다 제한된 컨텍스트는 데이터 도메인에 매핑됩니다.
전자상거래: 제한된 컨텍스트를 데이터 도메인에 매핑
| 제한된 컨텍스트 | 데이터 도메인 | 주요 제품 데이터 | 팀 소유자 |
|---|---|---|---|
| 제품 카탈로그 | 제품 카탈로그 | 제품, 카테고리, 가격, 재고 | 카탈로그 팀(개발자 4명 + 데이터 엔지니어 1명) |
| 명령 | 주문 관리 | 주문, 주문 라인, 주문 상태 | 주문팀(개발자 5명 + 데이터 엔지니어 1명) |
| 사용자 | 고객 | 사용자 프로필, 세분화, 행동 | 고객팀(개발자 3명 + 데이터 엔지니어 1명) |
| 결제 | 결제 | 거래, 화해, 사기 | 결제팀(개발자 4명 + 데이터 엔지니어 1명) |
| 기호 논리학 | 이행 | 배송, 추적, 반품 | 물류팀(개발자 4명 + 데이터 엔지니어 1명) |
| 마케팅 | 마케팅 | 캠페인, 전환, 기여 | 마케팅팀(개발자 3명 + 데이터 엔지니어 1명) |
한 가지 중요한 측면에 주목하세요. 모든 팀에는 최소한 하나의 팀이 포함됩니다. 임베디드 데이터 엔지니어 도메인에서. 이 사람은 중앙팀에 속하지 않고 팀에 통합되어 있습니다. 도메인을 공유하고 해당 컨텍스트, 우선 순위 및 민첩한 행사를 공유합니다. 그리고 차이점은 중앙 집중식 모델에 비해 기본적입니다.
데이터 도메인 아키텍처
Data Mesh의 각 데이터 도메인은 잘 정의된 아키텍처 구조를 가지고 있습니다. 보자 단일 도메인을 구성하는 방법:
+------------------------------------------------------------------+
| DATA DOMAIN: ORDINI |
+------------------------------------------------------------------+
| |
| +------------------+ +------------------+ |
| | Sorgenti Dati | | Servizi Applicat | |
| | - PostgreSQL | | - Order API | |
| | - Event Stream | | - Order Worker | |
| | - Legacy ERP | | - Notification | |
| +--------+---------+ +--------+---------+ |
| | | |
| v v |
| +------------------------------------------------+ |
| | Pipeline di Trasformazione | |
| | - Ingestione (CDC / Event Streaming) | |
| | - Pulizia e Validazione | |
| | - Aggregazione e Arricchimento | |
| +------------------------+-----------------------+ |
| | |
| v |
| +------------------------------------------------+ |
| | DATA PRODUCTS (Output) | |
| | | |
| | [1] ordini.fatto_ordini | |
| | - Tabella Iceberg Gold | |
| | - SLA: freshness 1h, completeness 99.5% | |
| | | |
| | [2] ordini.ordini_stream | |
| | - Kafka topic (real-time) | |
| | - SLA: latency <5s, availability 99.9% | |
| | | |
| | [3] ordini.metriche_giornaliere | |
| | - API REST / GraphQL | |
| | - SLA: response time <200ms | |
| +------------------------------------------------+ |
| |
+------------------------------------------------------------------+도메인당 세 가지 유형의 데이터 제품
각 도메인은 각각 최적화된 세 가지 보완적인 형식으로 데이터를 노출할 수 있습니다. 다른 소비 패턴의 경우:
- 분석 테이블(배치): 분석 쿼리 및 보고서를 위한 개체 스토리지의 Iceberg/Delta 테이블입니다. 매시간 또는 매일 업데이트됩니다.
- 이벤트 스트림(실시간): 실시간 데이터가 필요한 소비자를 위한 Kafka 주제입니다. 다운스트림 파이프라인 및 알림에 이상적입니다.
- API(주문형): 특정 쿼리, 대시보드 및 애플리케이션 통합을 위한 REST 또는 GraphQL 엔드포인트입니다. 낮은 대기 시간 응답.
원칙 2: 제품으로서의 데이터
두 번째 원칙이자 아마도 가장 혁신적인 원칙: 데이터세트를 부산물로 취급하지 않음 하지만 어떻게 모든 면에서 제품, 라이프 사이클이 있는 자체 사용자, SLA 및 품질 지표를 제공합니다. 첫 번째 원칙이 "누구"(팀)을 정의하는 경우 도메인), 두 번째는 "무엇"(데이터 제품)과 "어떻게"(품질 표준)를 정의합니다.
데이터 제품의 특성
고품질 데이터 제품은 자주 언급되는 8가지 기본 특성을 충족해야 합니다. 약어와 함께 DATSIS+:
데이터 제품의 8가지 특성
- 검색 가능: 중앙 카탈로그에 기록되어 검색으로 쉽게 찾을 수 있음
- 주소 지정 가능: 안정적이고 표준화된 주소(URI)를 통해 액세스 가능
- 신뢰할 수 있는: 검증 가능한 품질 지표와 정의된 SLA가 함께 제공됩니다.
- 자기 설명: 제작자에게 묻지 않고도 회로도, 문서 및 계보를 사용할 수 있습니다.
- 상호 운용 가능: 회사 이름 지정, 입력 및 형식 표준을 준수합니다.
- 안전한: 정책, 암호화 및 감사 추적을 통해 액세스 제어
- 귀중한: 소비자를 위한 측정 가능한 가치를 생성합니다(데이터를 위한 데이터가 아님).
- 때마침: 신선도 모니터링을 통해 SLA에 선언된 빈도로 업데이트되었습니다.
데이터 계약: 생산자와 소비자 간의 계약
"제품으로서의 데이터" 원칙의 핵심은 데이터 계약: 합의 데이터를 생산하는 사람과 데이터를 소비하는 사람 사이에서 공식적이고 기계로 읽을 수 있습니다. 데이터 계약은 다음을 정의합니다. 계획, SLA, 소유권, 품질 규칙 및 발전 정책. 그리고 마이크로서비스 세계의 API 계약.
# data-contract.yaml - Contratto per il Data Product "Ordini"
# Formato basato su Data Contract Specification v0.9.3
# https://datacontract.com
dataContractSpecification: 0.9.3
id: urn:datacontract:ordini:fatto-ordini
info:
title: Fatto Ordini
version: 2.1.0
description: |
Tabella dei fatti contenente tutti gli ordini completati.
Aggiornata ogni ora con CDC dal database operazionale.
owner: team-ordini
contact:
name: Marco Rossi
email: marco.rossi@azienda.it
slack: "#team-ordini-data"
servers:
production:
type: iceberg
catalog: lakehouse
database: ordini
table: fatto_ordini
location: s3://data-lakehouse/ordini/fatto_ordini/
schema:
type: table
fields:
- name: ordine_id
type: bigint
required: true
unique: true
description: Identificativo univoco dell'ordine
pii: false
- name: cliente_id
type: integer
required: true
description: FK al dominio Customer
references: urn:datacontract:customer:dim-clienti.cliente_id
- name: data_ordine
type: timestamp
required: true
description: Timestamp di creazione dell'ordine (UTC)
- name: importo_totale
type: decimal(12,2)
required: true
description: Importo totale dell'ordine in EUR
checks:
- type: range
min: 0.01
max: 999999.99
- name: stato
type: string
required: true
description: Stato corrente dell'ordine
enum: [completato, annullato, rimborsato, in_lavorazione]
- name: canale
type: string
required: true
description: Canale di vendita
enum: [web, mobile_app, marketplace, pos]
- name: regione_cliente
type: string
required: false
description: Regione di residenza del cliente
quality:
type: SodaCL
specification:
checks for fatto_ordini:
- row_count > 0
- freshness(data_ordine) < 2h
- missing_percent(ordine_id) = 0
- missing_percent(importo_totale) = 0
- invalid_percent(importo_totale) < 0.1%:
valid min: 0.01
- duplicate_percent(ordine_id) = 0
- schema:
name: fatto_ordini_schema
warn:
when schema changes: any
sla:
freshness: 1h # Dati aggiornati entro 1 ora
availability: 99.5% # Uptime della tabella
completeness: 99.9% # Percentuale record completi
latency_p95: 5s # Tempo query P95
terms:
usage: |
Dati disponibili per analytics, reporting e ML.
Non utilizzare per comunicazioni dirette al cliente
senza consenso esplicito del dominio Customer.
retention: 7 anni (obbligo fiscale)
classification: internal
pii_fields: [cliente_id]
history:
- version: 2.1.0
date: 2025-12-01
changes: Aggiunto campo canale
- version: 2.0.0
date: 2025-06-15
changes: Breaking change - rinominato amount in importo_totale이 데이터 계약은 단순한 문서가 아닙니다. 실행 가능한 결과물입니다. 도구 거버넌스는 계약에 따라 데이터를 자동으로 검증하고 배포를 차단할 수 있습니다. 예고되지 않은 주요 변경 사항을 도입하고 SLA가 위반되면 경고를 생성합니다.
진화 및 버전 관리 체계
데이터 제품의 중요한 측면은 진화 계획: 관리하는 방법 소비자를 방해하지 않고 계획을 변경합니다. 데이터 메시는 동일한 것을 채택합니다. API 버전 관리 전략:
스키마 진화 전략
| 기어박스 유형 | Esempio | 전략 | 파괴? |
|---|---|---|---|
| 열이 추가됨 | 새로운 "채널" 필드 | 이전 버전과 호환 가능, 직접 추가 | No |
| 선택적 열 | 필수에서 nullable로 | 이전 버전과 호환 가능 | No |
| 컬럼 제거 | "legacy_code" 삭제 | 90일 동안 지원 중단 후 제거 | 예(주 버전) |
| 유형 변경 | 문자열에서 정수로 | 새로운 주요 버전 + 마이그레이션 | 예(주 버전) |
| 이름 바꾸기 | '금액'에서 'total_amount'로 | 임시 별칭 + 지원 중단 | 예(주 버전) |
원칙 3: 셀프 서비스 데이터 인프라 플랫폼
세 번째 원칙은 데이터 소유권을 분산화할지 여부라는 실용적인 질문을 다룹니다. 도메인 팀의 경우 각 팀이 바퀴를 재발명하지 못하게 하려면 어떻게 해야 합니까? 답은 하나이다 내부 셀프 서비스 플랫폼 도구, 템플릿 및 자동화를 제공하는 데이터 제품을 생산하고 소비하는 데 드는 인지 및 운영 비용을 줄입니다.
셀프 서비스 데이터 플랫폼은 위장된 데이터 웨어하우스가 아닙니다. 플랫폼으로서의 제품 도메인 팀이 자율적으로 운영할 수 있도록 지원합니다. 중앙 집중식 모델을 적용하지 않고 인프라, 도구 및 가드레일을 관리합니다.
플랫폼 아키텍처
+============================================================================+
| SELF-SERVE DATA PLATFORM |
+============================================================================+
| |
| +---------------------------+ +---------------------------+ |
| | Data Product Builder | | Data Product Discovery | |
| | - Template pipeline | | - Data Catalog | |
| | - Schema registry | | - Search & Browse | |
| | - Contract generator | | - Lineage viewer | |
| | - CI/CD per dati | | - Quality dashboard | |
| +---------------------------+ +---------------------------+ |
| |
| +---------------------------+ +---------------------------+ |
| | Infrastructure Layer | | Governance Layer | |
| | - Compute provisioning | | - Policy engine | |
| | - Storage management | | - Access control (RBAC) | |
| | - Networking | | - Audit logging | |
| | - Monitoring & Alerts | | - Compliance checks | |
| +---------------------------+ +---------------------------+ |
| |
| +---------------------------+ +---------------------------+ |
| | Mesh Connectivity | | Observability | |
| | - Event bus (Kafka) | | - Data quality metrics | |
| | - API gateway | | - SLA monitoring | |
| | - Query federation | | - Cost tracking | |
| | - Cross-domain joins | | - Usage analytics | |
| +---------------------------+ +---------------------------+ |
| |
+============================================================================+코드형 인프라를 사용한 자동 프로비저닝
플랫폼은 도메인 팀이 새로운 데이터 제품을 생성할 수 있도록 해야 합니다. 인프라에 대한 티켓을 열지 않고도 몇 가지 명령만으로 가능합니다. Terraform을 사용한 예를 살펴보겠습니다.
# terraform/modules/data-product/main.tf
# Modulo Terraform per il provisioning di un Data Product
variable "domain_name" {
type = string
description = "Nome del dominio (es: ordini, catalogo)"
}
variable "product_name" {
type = string
description = "Nome del data product"
}
variable "owner_team" {
type = string
description = "Team responsabile"
}
variable "sla_tier" {
type = string
default = "standard" # standard | premium | critical
}
# Storage: bucket S3 dedicato per il dominio
resource "aws_s3_bucket" "data_product" {
bucket = "data-mesh-${var.domain_name}-${var.product_name}"
tags = {
Domain = var.domain_name
Product = var.product_name
Owner = var.owner_team
ManagedBy = "data-platform"
SLATier = var.sla_tier
}
}
# Iceberg: tabella registrata nel catalogo
resource "aws_glue_catalog_table" "iceberg_table" {
database_name = var.domain_name
name = var.product_name
table_type = "EXTERNAL_TABLE"
parameters = {
"table_type" = "ICEBERG"
"metadata_location" = "s3://${aws_s3_bucket.data_product.id}/metadata/"
"data_contract_url" = "s3://data-contracts/${var.domain_name}/${var.product_name}.yaml"
}
}
# IAM: ruolo per il team di dominio
resource "aws_iam_role" "domain_role" {
name = "data-mesh-${var.domain_name}-${var.product_name}-role"
assume_role_policy = jsonencode({
Version = "2012-10-17"
Statement = [{
Action = "sts:AssumeRole"
Effect = "Allow"
Principal = {
AWS = "arn:aws:iam::role/${var.owner_team}"
}
}]
})
}
# Monitoring: dashboard CloudWatch automatica
resource "aws_cloudwatch_dashboard" "data_product" {
dashboard_name = "data-product-${var.domain_name}-${var.product_name}"
dashboard_body = templatefile("${path.module}/dashboard.json.tpl", {
domain = var.domain_name
product = var.product_name
sla = var.sla_tier
})
}
# Output: informazioni per il team
output "data_product_uri" {
value = "s3://${aws_s3_bucket.data_product.id}/"
}
output "catalog_table" {
value = "${var.domain_name}.${var.product_name}"
}데이터 카탈로그: 검색 및 계보
플랫폼의 필수 구성 요소는 데이터 카탈로그: 레지스터 모든 데이터 제품이 게시되고, 문서화되고, 검색 가능한 중앙 집중식입니다. 주요 내용 이 분야의 오픈 소스 도구는 다음과 같습니다.
오픈 소스 데이터 카탈로그 비교
| 기구 | 작성자: | 강점 | 적합 |
|---|---|---|---|
| 데이터허브 | 링크드인 | 풍부한 계보, GraphQL API, 광범위한 통합 | 엔터프라이즈, 이기종 플랫폼 |
| 오픈메타데이터 | 오픈 소스 | 최신 UI, 통합 데이터 품질, 기본 데이터 계약 | SMB 및 중간 규모 시장, 소규모 팀 |
| 아파치 아틀라스 | 아파치/호튼웍스 | 고급 거버넌스, 데이터 분류, 감사 | Hadoop 생태계, 규정 준수 |
| 아문센 | 리프트 | 간단한 사용자 경험, 전체 텍스트 검색 | 분석가를 위한 데이터 검색 |
| 유니티 카탈로그 | Databricks(오픈 소스) | 다중 엔진, 세분화된 액세스 제어 | Databricks 및 멀티 클라우드 환경 |
원칙 4: 연합 컴퓨팅 거버넌스
네 번째 원칙은 종종 가장 잘못 이해되고 데이터 메시의 성공에 가장 중요한 원칙입니다. 거버넌스 없이 데이터 소유권을 분산하면 혼란이 발생합니다. 하지만 거버넌스 위원회, 수동 프로세스 및 Word 문서를 기반으로 하는 기존 방식은 확장되지 않습니다. 데이터 메시 하나를 제안하다 연합 및 컴퓨팅 거버넌스: 중앙에서 정의된 규칙 코드를 통해 자동으로 적용됩니다.
코드로서의 정책
거버넌스 정책은 플랫폼이 적용하는 실행 파일로 인코딩됩니다. 데이터 제품 수명주기 동안 자동으로. 구체적인 예를 들어보자 OPA(개방형 정책 에이전트) 사용:
# governance/policies/data_product_policy.rego
# Policy OPA per la validazione dei Data Product
package datamesh.governance
# Regola 1: Ogni data product DEVE avere un data contract valido
deny[msg] {
not input.data_contract
msg := "Data product deve avere un data contract definito"
}
# Regola 2: Ogni data product DEVE avere un owner
deny[msg] {
not input.data_contract.info.owner
msg := "Data contract deve specificare il team owner"
}
# Regola 3: I campi PII devono essere dichiarati
deny[msg] {
field := input.data_contract.schema.fields[_]
contains(lower(field.name), "email")
not field.pii
msg := sprintf("Campo '%s' potrebbe contenere PII ma non e contrassegnato", [field.name])
}
# Regola 4: SLA obbligatori per data product in produzione
deny[msg] {
input.environment == "production"
not input.data_contract.sla
msg := "SLA obbligatori per data product in produzione"
}
# Regola 5: Freshness SLA deve essere definito
deny[msg] {
input.environment == "production"
not input.data_contract.sla.freshness
msg := "SLA di freshness obbligatorio per data product in produzione"
}
# Regola 6: Naming convention per le tabelle
deny[msg] {
table_name := input.data_contract.servers.production.table
not re_match("^[a-z][a-z0-9_]*$", table_name)
msg := sprintf("Nome tabella '%s' non conforme: usa solo lowercase, numeri e underscore", [table_name])
}
# Regola 7: Data classification obbligatoria
deny[msg] {
not input.data_contract.terms.classification
msg := "Classification obbligatoria (public, internal, confidential, restricted)"
}
# Regola 8: Retention policy obbligatoria per compliance GDPR
deny[msg] {
not input.data_contract.terms.retention
msg := "Retention policy obbligatoria per compliance GDPR"
}레지스트리 스키마 및 상호 운용성
서로 다른 도메인의 데이터 제품이 상호 운용될 수 있도록 거버넌스 federata는 명명 규칙, 데이터 유형 및 형식에 대한 글로벌 표준을 정의합니다. 참조. 에이 스키마 레지스트리 중앙 집중식(Conluent Schema와 같은) 레지스트리 또는 AWS Glue 스키마 레지스트리)는 모든 스키마를 등록하고 버전을 관리합니다.
# governance/standards/global_types.yaml
# Standard globali per il Data Mesh aziendale
naming_conventions:
tables:
pattern: "^[a-z][a-z0-9_]{2,60}$"
prefixes:
fact: "fatto_" # Tabelle dei fatti (fact tables)
dimension: "dim_" # Dimensioni
staging: "stg_" # Staging temporaneo
aggregate: "agg_" # Aggregazioni pre-calcolate
columns:
pattern: "^[a-z][a-z0-9_]{1,60}$"
reserved_suffixes:
_id: "Identificativo (integer o bigint)"
_ts: "Timestamp (UTC)"
_dt: "Data senza orario"
_amt: "Importo monetario (decimal)"
_qty: "Quantità (integer)"
_pct: "Percentuale (decimal 0-100)"
_flag: "Booleano"
global_types:
currency:
type: decimal(12,2)
description: "Importi monetari in EUR"
identifier:
type: bigint
description: "Chiavi primarie e foreign key"
timestamp:
type: timestamp
timezone: UTC
description: "Tutti i timestamp in UTC"
country_code:
type: string
format: ISO-3166-1-alpha-2
description: "Codice paese ISO a 2 lettere"
interoperability:
shared_dimensions:
- name: dim_data
owner: platform-team
description: "Dimensione temporale condivisa (calendario)"
- name: dim_geografia
owner: platform-team
description: "Gerarchia geografica (nazione, regione, provincia, comune)"
- name: dim_valuta
owner: platform-team
description: "Conversioni valuta giornaliere"
compliance:
gdpr:
pii_fields_must_be_tagged: true
retention_policy_required: true
right_to_deletion_supported: true
data_classification:
levels: [public, internal, confidential, restricted]
default: internal실제로 연합 거버넌스
연합 거버넌스는 세 가지 수준으로 작동합니다.
- 글로벌 수준(플랫폼 팀): 표준, 명명 규칙, 공유 유형, OPA 정책. 중앙에서 정의되고 자동으로 적용됩니다.
- 도메인 수준(도메인 팀): 특정 스키마, SLA, 도메인 품질 규칙. 팀에서 정의하고 플랫폼에서 검증합니다.
- 데이터 제품 수준(단일): 특정 계약, 지표, 액세스. 소유자 팀이 관리합니다.
데이터 메시의 완전한 기술 아키텍처
네 가지 원칙을 개별적으로 살펴본 후, 이 원칙들이 어떻게 결합되는지 살펴보겠습니다. 통합된 기술 아키텍처. 다음 다이어그램은 주요 구성 요소를 보여줍니다. 그리고 그들의 상호작용:
+============================================================================+
| FEDERATED GOVERNANCE LAYER |
| Policy Engine (OPA) | Schema Registry | Compliance Automation |
+============================================================================+
| | |
v v v
+--------------------+ +--------------------+ +--------------------+
| DOMAIN: ORDINI | | DOMAIN: CATALOGO | | DOMAIN: CUSTOMER |
| | | | | |
| +----------------+ | | +----------------+ | | +----------------+ |
| | Data Products | | | | Data Products | | | | Data Products | |
| | - fatto_ordini | | | | - dim_prodotti | | | | - dim_clienti | |
| | - ordini_stream| | | | - prezzi_storico| | | | - segmentazione| |
| | - metriche_day | | | | - inventory | | | | - comportamento| |
| +----------------+ | | +----------------+ | | +----------------+ |
| | | | | |
| +----------------+ | | +----------------+ | | +----------------+ |
| | Pipeline (dbt) | | | | Pipeline (dbt) | | | | Pipeline (dbt) | |
| | - bronze | | | | - bronze | | | | - bronze | |
| | - silver | | | | - silver | | | | - silver | |
| | - gold | | | | - gold | | | | - gold | |
| +----------------+ | | +----------------+ | | +----------------+ |
| | | | | |
| [Team: 5+1 DE] | | [Team: 4+1 DE] | | [Team: 3+1 DE] |
+--------------------+ +--------------------+ +--------------------+
| | |
v v v
+============================================================================+
| SELF-SERVE DATA PLATFORM |
| |
| +-------------------+ +-------------------+ +-------------------+ |
| | Compute Layer | | Storage Layer | | Connectivity | |
| | - Spark / dbt | | - S3 / ADLS | | - Kafka | |
| | - Airflow | | - Iceberg tables | | - API Gateway | |
| | - Kubernetes | | - Schema Registry | | - Query Federation| |
| +-------------------+ +-------------------+ +-------------------+ |
| |
| +-------------------+ +-------------------+ +-------------------+ |
| | Data Catalog | | Observability | | Security | |
| | - OpenMetadata | | - Great Expect. | | - RBAC / ABAC | |
| | - Lineage | | - SLA Monitoring | | - Encryption | |
| | - Search | | - Cost Tracking | | - Audit Trail | |
| +-------------------+ +-------------------+ +-------------------+ |
+============================================================================+실제 구현: 데이터 모놀리스에서 데이터 메시까지
모놀리식 데이터 웨어하우스에서 데이터 메시로의 마이그레이션은 빅뱅으로 발생하지 않습니다. 여러 단계로 구분되는 증분 경로입니다. 실용적인 접근 방식을 단계별로 살펴보겠습니다. 각 단계에 대한 실제 코드를 사용합니다.
1단계: 파일럿 도메인 및 데이터 제품 식별
우리는 성숙한 팀과 세 가지 기준에 따라 선택된 2-3개의 파일럿 도메인을 식별하는 것부터 시작합니다. 동기가 부여되고, 잘 이해된 데이터, 명확한 소비자. 우리는 더 이상 도메인에서 시작하지 않습니다 복잡하거나 중요합니다.
2단계: 데이터 계약 정의
파일럿 도메인의 각 데이터 제품에 대해 데이터 계약이 정의됩니다(예: 위에 표시됨). 계약은 도메인 코드와 함께 Git에서 버전이 관리됩니다.
3단계: dbt를 사용하여 파이프라인 생성
dbt(데이터 구축 도구) 변화를 위한 이상적인 도구입니다. 데이터 메시: 도메인 팀이 버전이 지정되고 테스트된 SQL 모델을 정의할 수 있습니다. 문서화되었습니다. 각 도메인에는 자체 dbt 프로젝트가 있습니다.
-- dbt/models/ordini/gold/fatto_ordini.sql
-- Modello dbt per il Data Product "fatto_ordini"
-- Dominio: Ordini | Layer: Gold | Owner: team-ordini
{{ config(
materialized='incremental',
unique_key='ordine_id',
partition_by={
'field': 'data_ordine',
'data_type': 'timestamp',
'granularity': 'day'
},
tags=['gold', 'ordini', 'data-product'],
meta={
'owner': 'team-ordini',
'sla_freshness': '1h',
'sla_availability': '99.5%',
'data_contract': 'urn:datacontract:ordini:fatto-ordini'
}
) }}
WITH ordini_silver AS (
SELECT * FROM {{ ref('stg_ordini_clean') }}
{% if is_incremental() %}
WHERE data_aggiornamento > (
SELECT MAX(data_aggiornamento) FROM {{ this }}
)
{% endif %}
),
clienti AS (
-- Cross-domain reference: consuma dal dominio Customer
SELECT * FROM {{ source('customer_domain', 'dim_clienti') }}
),
arricchiti AS (
SELECT
o.ordine_id,
o.cliente_id,
o.data_ordine,
o.importo_totale,
o.stato,
o.canale,
c.regione AS regione_cliente,
c.segmento AS segmento_cliente,
o.data_aggiornamento
FROM ordini_silver o
LEFT JOIN clienti c ON o.cliente_id = c.cliente_id
)
SELECT * FROM arricchiti# dbt/models/ordini/gold/schema.yml
# Test e documentazione per il data product fatto_ordini
version: 2
models:
- name: fatto_ordini
description: >
Tabella dei fatti degli ordini completati.
Data Product del dominio Ordini, aggiornato ogni ora.
meta:
owner: team-ordini
data_contract: urn:datacontract:ordini:fatto-ordini
columns:
- name: ordine_id
description: Identificativo univoco dell'ordine
tests:
- unique
- not_null
- name: cliente_id
description: FK al dominio Customer
tests:
- not_null
- relationships:
to: source('customer_domain', 'dim_clienti')
field: cliente_id
- name: importo_totale
description: Importo totale in EUR
tests:
- not_null
- dbt_utils.accepted_range:
min_value: 0.01
max_value: 999999.99
- name: stato
description: Stato dell'ordine
tests:
- accepted_values:
values: ['completato', 'annullato', 'rimborsato', 'in_lavorazione']
- name: data_ordine
description: Timestamp di creazione (UTC)
tests:
- not_null
- dbt_utils.recency:
datepart: hour
field: data_ordine
interval: 24단계: API를 통해 데이터 제품 노출
분석 테이블 외에도 데이터 제품을 API를 통해 노출할 수 있습니다. 낮은 대기 시간으로 주문형 액세스가 필요한 소비자. 여기에 예가 있습니다 Python에서 FastAPI 사용:
# api/ordini_data_product.py
# API per il Data Product "Ordini" - Dominio Ordini
from fastapi import FastAPI, Query, HTTPException
from pydantic import BaseModel
from typing import Optional
from datetime import date, datetime
import duckdb
app = FastAPI(
title="Ordini Data Product API",
version="2.1.0",
description="API per il consumo del data product Ordini"
)
class MetricheOrdini(BaseModel):
regione: str
data: date
num_ordini: int
fatturato: float
ordine_medio: float
clienti_unici: int
class HealthCheck(BaseModel):
status: str
freshness_minutes: int
record_count: int
last_update: datetime
# Connessione a DuckDB/Iceberg
con = duckdb.connect()
con.execute("""
INSTALL iceberg;
LOAD iceberg;
""")
@app.get("/health", response_model=HealthCheck)
async def health_check():
"""Verifica SLA del data product"""
result = con.execute("""
SELECT
COUNT(*) as record_count,
MAX(data_aggiornamento) as last_update,
DATEDIFF('minute', MAX(data_aggiornamento), NOW())
AS freshness_minutes
FROM iceberg_scan('s3://data-mesh/ordini/fatto_ordini/')
""").fetchone()
freshness = result[2]
status = "healthy" if freshness < 60 else "degraded"
return HealthCheck(
status=status,
freshness_minutes=freshness,
record_count=result[0],
last_update=result[1]
)
@app.get("/metriche", response_model=list[MetricheOrdini])
async def get_metriche(
data_inizio: date = Query(..., description="Data inizio (YYYY-MM-DD)"),
data_fine: date = Query(..., description="Data fine (YYYY-MM-DD)"),
regione: Optional[str] = Query(None, description="Filtro regione"),
limit: int = Query(100, ge=1, le=1000)
):
"""Metriche aggregate degli ordini per regione e giorno"""
query = """
SELECT
regione_cliente AS regione,
CAST(data_ordine AS DATE) AS data,
COUNT(*) AS num_ordini,
ROUND(SUM(importo_totale), 2) AS fatturato,
ROUND(AVG(importo_totale), 2) AS ordine_medio,
COUNT(DISTINCT cliente_id) AS clienti_unici
FROM iceberg_scan('s3://data-mesh/ordini/fatto_ordini/')
WHERE data_ordine BETWEEN ? AND ?
"""
params = [data_inizio, data_fine]
if regione:
query += " AND regione_cliente = ?"
params.append(regione)
query += """
GROUP BY regione_cliente, CAST(data_ordine AS DATE)
ORDER BY fatturato DESC
LIMIT ?
"""
params.append(limit)
rows = con.execute(query, params).fetchall()
if not rows:
raise HTTPException(status_code=404, detail="Nessun dato trovato")
return [
MetricheOrdini(
regione=r[0], data=r[1], num_ordini=r[2],
fatturato=r[3], ordine_medio=r[4], clienti_unici=r[5]
)
for r in rows
]5단계: 데이터 제품을 위한 CI/CD 파이프라인
각 데이터 제품에는 데이터 계약을 검증하고 테스트를 실행하는 CI/CD 파이프라인이 있어야 합니다. 배포하기 전에 거버넌스 정책을 확인합니다. 다음은 GitHub Actions의 예입니다.
# .github/workflows/data-product-ci.yml
name: Data Product CI/CD - Ordini
on:
push:
paths:
- 'domains/ordini/**'
pull_request:
paths:
- 'domains/ordini/**'
jobs:
validate-contract:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Validate Data Contract Schema
run: |
pip install datacontract-cli
datacontract test domains/ordini/data-contract.yaml
- name: Check Breaking Changes
run: |
datacontract breaking \
domains/ordini/data-contract.yaml \
--with-previous-version
test-transformations:
runs-on: ubuntu-latest
needs: validate-contract
steps:
- uses: actions/checkout@v4
- name: Install dbt
run: pip install dbt-core dbt-duckdb
- name: Run dbt Tests
run: |
cd domains/ordini/dbt
dbt deps
dbt seed --target test
dbt run --target test
dbt test --target test
- name: Check Data Quality (Soda)
run: |
pip install soda-core-duckdb
soda scan -d ordini_test \
-c domains/ordini/soda/configuration.yml \
domains/ordini/soda/checks.yml
governance-check:
runs-on: ubuntu-latest
needs: validate-contract
steps:
- uses: actions/checkout@v4
- name: Policy Validation (OPA)
run: |
opa eval \
--data governance/policies/ \
--input domains/ordini/data-contract.yaml \
"data.datamesh.governance.deny"
- name: Schema Registry Compatibility
run: |
curl -X POST \
"$SCHEMA_REGISTRY_URL/compatibility/subjects/ordini-fatto_ordini/versions/latest" \
-H "Content-Type: application/json" \
-d "$(cat domains/ordini/schema.json)"
deploy:
runs-on: ubuntu-latest
needs: [test-transformations, governance-check]
if: github.ref == 'refs/heads/main'
steps:
- name: Deploy Data Product
run: |
dbt run --target production
datacontract publish domains/ordini/data-contract.yaml \
--catalog-url $CATALOG_URL데이터 메시와 데이터 패브릭: 두 가지 보완적인 접근 방식
현대 데이터 아키텍처 논쟁에서 Data Mesh e 데이터 패브릭 그들이 온다 종종 대안으로 제시됩니다. 실제로 그들은 다양한 문제를 해결하고 공존하다. Data Fabric은 기술 중심의 아키텍처 접근 방식입니다. Active Metadata와 AI를 활용하여 분산된 데이터를 통합하고 관리합니다. 데이터 메시는 데이터 책임을 도메인으로 분산시키는 조직적 접근 방식입니다.
데이터 메시와 데이터 패브릭 비교
| 나는 기다린다 | 데이터 메시 | 데이터 패브릭 |
|---|---|---|
| 철학 | 조직의 분산화 | 스마트 기술 통합 |
| 드라이버 | 조직(팀, 소유권) | 기술(메타데이터, AI) |
| 통치 | 연합, 코드형 정책 | 중앙 집중식, AI 지원 |
| 건축학 | 공통 플랫폼을 갖춘 독립 도메인 | 이기종 소스에 대한 통합 레이어 |
| 메타데이터 | 도메인 팀에서 관리 | AI가 자동으로 발견하고 관리합니다. |
| 데이터 통합 | 도메인 간의 명시적 계약 | 가상화 및 지식 그래프 |
| 조직의 전제조건 | 높음(자율 팀, DevOps 문화) | 중간(중앙 데이터팀에서 채택 가능) |
| 채택의 복잡성 | 높음(조직적 + 기술적 변화) | 미디어(대부분 기술) |
| 주요 공급업체 | 오픈 소스: dbt, Kafka, Iceberg, OPA | IBM, 인포매티카, 탈렌드, 데노도 |
| 다음에 이상적입니다. | 많은 도메인을 보유한 대규모 조직 | 이기종 레거시 시스템을 보유한 조직 |
데이터 메시와 데이터 패브릭을 결합하는 경우
많은 성숙한 조직에서는 데이터 메시와 데이터 패브릭이 공존합니다. 데이터 패브릭은 다음을 수행할 수 있습니다. Data Mesh의 셀프 서비스 데이터 플랫폼 내에서 통합 계층 역할을 하며, 데이터 가상화, 지식 그래프 및 자동 메타데이터 검색을 제공합니다. 데이터 메시는 조직 모델(소유권, 계약, 연합 거버넌스)을 제공합니다. Data Fabric은 기술적 기능(활성 메타데이터, 통합)을 제공합니다. 지능형 쿼리 연합).
실제 사례 연구: 데이터 메시를 채택하는 사람
Data Mesh는 단순한 학문적 이론이 아닙니다. 여러 대규모 조직에서 이를 채택했습니다. 측정 가능한 결과를 제공합니다. 네 가지 중요한 사례 연구를 살펴보겠습니다.
Zalando: 유럽의 개척자
잘란도, 5천만 명 이상의 고객을 보유한 유럽의 온라인 패션 대기업 active는 2020년부터 Data Mesh를 최초로 채택한 팀 중 하나입니다. 200개가 넘는 팀이 있습니다. 개발과 수백 개의 마이크로서비스를 통해 중앙 집중식 데이터 웨어하우스는 지속 불가능한 병목 현상.
- 결과: 새로운 데이터 제품의 온보딩 시간이 4주에서 2일로 단축되었습니다.
- 플랫폼: Databricks, Kafka 및 내부 카탈로그를 기반으로 하는 셀프 서비스 플랫폼
- 영향: 80개 이상의 도메인 팀이 게시한 600개 이상의 데이터 제품
- 교훈: 연합 거버넌스는 가장 큰 과제였습니다. 글로벌 표준 없이 처음 몇 달간 일관성 없는 데이터 제품이 생산되었습니다.
Netflix: DNA 속의 데이터 메시
넷플릭스 Data Mesh를 변환 프로젝트로 채택하지 않았습니다. 분산화된 접근 방식은 항상 조직 DNA의 일부였습니다. 230이 넘는 수백만 명의 가입자와 페타바이트 규모의 스트리밍 데이터, 모든 제품 팀 및 관리자 귀하의 데이터를 엔드투엔드 방식으로 관리합니다.
- 결과: 도메인 팀이 독립적으로 관리하는 4,000개 이상의 데이터 세트
- 플랫폼: Apache Iceberg(Netflix에서 제작), Apache Spark, 맞춤형 내부 플랫폼
- 영향: 콘텐츠 및 추천 팀의 통찰력 확보 시간이 며칠에서 몇 분으로 단축되었습니다.
- 교훈: 셀프 서비스 플랫폼이자 가장 중요한 투자입니다. 그것이 없으면 분권화는 단편화만 만들 뿐입니다.
JPMorgan Chase: 은행 업무의 데이터 메시
JP 모건 체이스자산 기준 미국 최대 은행인 가 출범했습니다. 6천만 명 이상의 고객 데이터를 관리하기 위해 2021년 Data Mesh를 향한 길 소비자와 수천 명의 기관 고객. 은행 부문은 다음과 같은 독특한 과제를 안고 있습니다. 엄격한 규제, 다중 관할권 준수 및 감사 요구 사항.
- 결과: 위험 팀의 데이터 파이프라인 제공 시간 40% 단축
- 플랫폼: 거버넌스가 강화된 하이브리드 클라우드 기반 내부 데이터 플랫폼
- 영향: GDPR, SOX 및 은행 규제에 대한 자동화된 규정 준수
- 교훈: 은행에서는 연합 거버넌스가 더욱 엄격해야 합니다. OPA 정책은 배포에 대한 차단 요구 사항이 되었습니다.
Intuit: 핀테크를 위한 데이터 메시
인튜이트TurboTax, QuickBooks 및 Mint를 개발한 회사인 는 1억 명 이상의 고객 금융 데이터를 관리하는 데이터 메시. 도전 주요한 것은 서로 다른 제품 간의 개인 정보 보호 및 데이터 세분화였습니다.
- 결과: 200개 이상의 데이터 제품을 포함하는 15개 이상의 활성 데이터 메시 도메인
- 플랫폼: Iceberg, dbt 및 내부 카탈로그를 갖춘 AWS 기반
- 영향: 새로운 통찰력 개발 시간이 60% 단축되었습니다.
- 교훈: 데이터 계약은 규모가 커지는 동안 품질을 유지하는 데 필수적이었습니다. 그것들이 없었다면 도메인 간의 종속성이 깨졌을 것입니다.
과제, 안티 패턴 및 데이터 메시를 사용하지 말아야 할 경우
데이터 메시는 보편적인 솔루션이 아닙니다. 이는 상당한 과제를 제시하며 적합하지 않습니다. 모든 조직에. 한계를 이해하는 것은 이해하는 것만큼 중요합니다. 이점.
데이터 메시의 5가지 안티 패턴
- 1. 플랫폼 없는 데이터 메시(야생적인 분산화): 셀프 서비스 플랫폼을 제공하지 않고 데이터 소유권을 분산시키는 것은 동일합니다. 각 팀에게 처음부터 자체 인프라를 구축하도록 요청합니다. 결과는 단편화, 복제 및 기하급수적인 비용.
- 2. 기술 프로젝트로서의 데이터 메시: 데이터 메시는 주로 조직의 변화입니다. 그냥 이렇게 접근하면 소유권 변경 없이 기술 이전(새 카탈로그, 새 플랫폼), 인센티브와 팀 구조를 통해 결과는 동일한 새로운 플랫폼이 될 것입니다. 중앙 집중식 모델의 문제
- 3. 너무 빨리 도메인이 너무 많아짐: 모델 검증 없이 20개 도메인에서 동시에 데이터 메시 실행 약 2-3명의 운전자와 실패의 비법. 점진적이고 근본적인 접근 방식.
- 4. 시행되지 않는 데이터 계약: CI/CD에 통합되지 않아 누구도 존중하지 않는 데이터 계약을 정의하세요. 그리고 자동화된 거버넌스에서. 계약은 장식적인 것이 아니라 집행 가능한 것이어야 합니다.
- 5. 연합 거버넌스 무시: 거버넌스 없는 분권화는 혼란을 낳습니다. 각 도메인은 자체적으로 발명됩니다. 표준, 명명 규칙 및 형식은 호환되지 않는 데이터의 생태계를 만듭니다.
데이터 메시를 채택하지 말아야 할 경우
Data Mesh는 모든 조직에 적합하지 않습니다. 다음은 이를 나타내는 표시입니다. 중앙 집중식 모델이 여전히 최선의 선택일 수 있습니다.
체크리스트: 다음과 같은 경우에는 데이터 메시가 적합하지 않습니다.
- 5개 미만의 제품 팀: 팀 수가 적을수록 중앙 집중화가 잘 작동하고 조직의 오버헤드가 줄어듭니다.
- 조직의 인원이 50명 미만인 경우: 조정은 이미 자연스럽고 공식적인 구조가 필요하지 않습니다.
- 하나의 비즈니스 도메인: 모든 것이 단일 제품을 중심으로 돌아가는 경우 분산화는 의미가 없습니다.
- DevOps 문화 없음: 팀이 엔드투엔드 소프트웨어 소유권에 익숙하지 않은 경우 데이터 책임을 추가하는 것은 기회가 아니라 부담으로 느껴질 것입니다.
- 데이터 플랫폼 없음: 셀프 서비스 플랫폼이 없으면 모든 팀이 바퀴를 재발명해야 합니다.
- 플랫폼 팀의 제한된 예산: 셀프 서비스 플랫폼에는 상당한 초기 투자가 필요합니다(일반적으로 6~12개월 동안 3~5명의 전담 엔지니어).
이탈리아 상황: 중소기업과 데이터 분산화
이탈리아 기업가 구조는 95%가 소규모 기업과 소규모 기업으로 구성되어 있습니다. 직원 50명 중. 이러한 현실에서 완전한 형태의 데이터 메시는 종종 과잉입니다. 공학의. 그러나 그 기본 원칙은 보편적으로 유효하며 소규모 조직에도 적용할 수 있습니다.
이탈리아 SME에 데이터 메시 적용
직원 수가 50~200명이고 기능 영역이 3~5개 있는 중소기업은 단순화된 버전을 채택할 수 있습니다. 우리가 부를 Data Mesh의 데이터 메쉬 라이트:
중소기업을 위한 데이터 메시 라이트
| 원칙 | 전체 데이터 메시 | 데이터 메시 라이트(PMI) |
|---|---|---|
| 도메인 소유권 | 도메인별 임베디드 데이터 엔지니어 | 기능별 데이터 관리자(파트타임) |
| 제품으로서의 데이터 | 공식 데이터 계약, API, Kafka | 공유 시트 + dbt에 스키마와 소유자가 포함된 문서화된 데이터 세트 |
| 셀프 서비스 플랫폼 | 맞춤형 내부 플랫폼 | DuckDB + dbt + BI 도구(메타베이스 또는 슈퍼세트) |
| 연합 거버넌스 | OPA, 스키마 레지스트리, 코드형 정책 | 공유 규칙 명명 + DBT 테스트 + 분기별 검토 |
문화적 도전
이탈리아 중소기업의 가장 큰 과제는 기술적 문제가 아니라 문화적 문제입니다. 기업 문화 이탈리아어는 의사 결정의 중앙 집중화, 수직적 계층 구조 및 변화에 대한 저항. 데이터 메시에는 그 반대인 팀 자율성, 책임이 필요합니다. 분산 및 수평 협업. 이러한 문화적 변화에는 리더십이 필요합니다 강력하고 지속적인 교육과 파일럿 프로젝트의 가시적인 결과를 얻을 수 있습니다.
PNRR 기회 및 디지털 전환
Transition 5.0 자금이 소진되었음에도 불구하고(2025년 11월 6일 종료됨) 2년 기간(2024~2025)), 2026~2028년 주기에 새로운 자금 조달 기회가 예상됩니다. 이미 데이터 거버넌스 및 데이터 아키텍처 여정을 시작한 SME는 이러한 자금에 접근할 수 있는 특권적인 위치에 있으며 디지털 성숙도를 입증하고 구체적인 실행 계획.
결론: 데이터 메시 준비 체크리스트
데이터 메시는 조직 관리 방식의 패러다임 변화를 나타냅니다. 귀하의 데이터. 설치해야 할 기술이 아니라 채택해야 할 조직 모델입니다. 점차적으로. 4가지 원칙(도메인 소유권, 제품으로서의 데이터, 셀프 서비스 플랫폼, 연합 거버넌스)를 함께 구현해야 의미 있는 결과를 얻을 수 있습니다.
준비 체크리스트: 귀하의 조직은 준비가 되어 있습니까?
- 조직: 서로 다른 비즈니스 도메인을 갖춘 제품팀이 5개 이상 있나요?
- 문화: 팀은 의사결정 자율성과 서비스에 대한 엔드투엔드 소유권을 갖고 있습니까?
- 병목: 중앙 데이터 팀과 몇 주 동안의 대기열로 인한 병목 현상이 있습니까?
- 계단: 50개 이상의 데이터 파이프라인 또는 100개 이상의 데이터세트를 관리하시나요?
- 예산: 전담 플랫폼팀(3~5명, 6~12개월)에 투자할 수 있나요?
- 후원: 조직 변화에 대한 리더십 지원이 있습니까?
- 기술: 도메인 팀에 포함된 데이터 엔지니어가 있거나 고용할 수 있나요?
- 하부 구조: 이미 데이터 플랫폼(클라우드 DWH, 데이터 레이크, 레이크하우스)이 있습니까?
이 질문 중 6개 이상에 "예"라고 답했다면 아마도 다음은 Data Mesh가 될 것입니다. 데이터 아키텍처의 성숙도를 한 단계 높이세요. 4개 미만의 항목에 '예'라고 답한 경우, 견고한 기반에 우선 집중(최신 데이터 웨어하우스, 데이터 팀, 데이터 기반 문화) 12~18개월 후에 재평가하세요.
기억해야 할 핵심 사항
- Il 데이터 메시 이는 기술이 아니라 조직 패러다임입니다. 데이터 책임을 도메인 팀에 분산시킵니다.
- I 네 가지 원칙 (도메인 소유권, 제품으로서의 데이터, 셀프 서비스 플랫폼, 연합 거버넌스)를 함께 채택해야 합니다.
- I 데이터 계약 이는 시스템의 핵심입니다. 기계가 읽을 수 있고 검증 가능한 방식으로 스키마, SLA 및 품질을 정의합니다.
- La 셀프 서비스 데이터 플랫폼 그리고 가장 중요한 기술 투자: 그것이 없으면 분산화는 분열을 낳습니다.
- La 연합 거버넌스 자율성과 일관성의 균형: 중앙에서 정의된 정책, 자동 시행
- 데이터 메시 그것은 모든 사람을위한 것이 아닙니다: 소규모 또는 소규모 도메인 조직은 중앙 집중식 모델에서 더 많은 가치를 얻을 수 있습니다.
- Le 이탈리아 중소기업 DuckDB, dbt 및 단순화된 조직 원칙을 갖춘 "Data Mesh Light"를 채택할 수 있습니다.
- 잘란도, 넷플릭스, JPMorgan 모델이 대규모로 작동하지만 플랫폼과 거버넌스에 대한 투자가 필요함을 보여줍니다.
시리즈의 다음 기사에서는 밀접하게 관련된 주제를 다룰 것입니다. 클라우드의 ETL과 ELT. 최신 데이터 파이프라인이 어떤 모습인지 살펴보겠습니다. 기존 배치 ETL에서 dbt를 사용한 클라우드 네이티브 ELT로 진화했으며 이러한 파이프라인이 어떻게 진화했는지 이는 Data Mesh 아키텍처에 통합되어 각 도메인의 데이터 제품을 강화합니다.
추천 실습
다음 문서로 넘어가기 전에 자신의 데이터 도메인을 정의해 보세요. 조직. 종이 한 장을 가지고 다음 질문에 답해 보세요.
- 얼마나 많은 제품 팀이 있고 어떤 비즈니스 도메인을 다루고 있나요?
- 각 도메인에 대해 가장 중요한 2~3개의 데이터 세트는 무엇입니까?
- 현재 각 데이터 세트를 담당하는 사람은 누구인가요? (대답이 "아무도 없음" 또는 "IT 팀"인 경우 문제를 발견한 것입니다.)
- 두 개 이상의 팀에서 어떤 데이터 세트를 사용합니까? (데이터 제품이 될 첫 번째 후보입니다)