データメッシュと分散型データアーキテクチャ
30 年以上にわたり、エンタープライズ データ アーキテクチャは重力モデルに従ってきました。 すべてのデータは 1 つの中心点にまとめられ、専門チームが管理します。 組織全体のボトルネックとして。モノリシック データ ウェアハウス、データ レイク 前の記事で説明した最新のデータ レイクハウスも含めて、一元化されています。 これらはすべて、データは次のとおりである必要があるという同じアーキテクチャ上の前提を共有しています。 集められた、 単一のチームによって処理および提供される.
このモデルは、組織が小規模でドメインが小さい限り、かなりうまく機能しました。 ビジネスは少なく、データ量は管理可能でした。しかし、会社が成長すると、 数十の製品チーム、数百のデータソース、ペタバイト規模の情報、モデル 集中システムは自重で崩壊します。中央のデータエンジニアがネックになる ボトル、リクエストの列は長くなり、配達時間は 4 分の 1 単位で測定されます 数週間ではなく、データを作成した人が責任を負わないため、データの品質が低下します。
2019年には、 ザマック・デガニその後、ThoughtWorks のコンサルタントとなり、正式に 根本的に異なるパラダイム: データメッシュ。これは新しいものではありません テクノロジーまたは新しいツールですが、組織およびアーキテクチャの考え方が変化します。 これは、ドメイン駆動設計とプラットフォーム思考の原則をデータの世界に適用します。 データ メッシュは、データの世界にとって、マイクロサービスがアプリケーションの世界にとってそうであったのと同じです。 ビジネスドメインによる責任の分散化。
2024 年の Gartner の分析によると、大規模組織の 25% がイニシアティブを開始しました データメッシュの割合は 2027 年までに 50% に達すると予想されています。 データ メッシュおよびデータ ファブリック プラットフォームの規模は 2025 年に 42 億ドルを超える見込みです。 年間平均成長率 (CAGR) は 22% です。
この記事で学べること
- 一元化されたデータ モデルは複雑な組織では拡張できないため
- データ メッシュの 4 つの基本原則 (Zhamak Dehghani 著)
- DDD で制限されたコンテキストをデータ ドメインにマッピングする方法と具体的な例
- データ製品とは何か、またデータ契約、SLA、品質指標を定義する方法
- セルフプロビジョニング セルフサービス データ プラットフォーム アーキテクチャ
- Federated Computational Governance: コードとしてのポリシーと自動化されたコンプライアンス
- コードによる実践的な実装: データ コントラクト、dbt モデル、API、パイプライン
- データメッシュとデータファブリックの比較表
- 実際のケーススタディ: Zalando、Netflix、JPMorgan Chase、Intuit
- 課題、アンチパターン、およびデータ メッシュを採用すべきではない場合
- イタリアの背景: 中小企業、文化的課題、PNRR の機会
データ ウェアハウス、AI、デジタル トランスフォーメーション シリーズの概要
| # | アイテム | 集中 |
|---|---|---|
| 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 によって公式化され、彼の著書で詳しく説明されています。 「Data Mesh: Delivering Data-Driven Value at Scale」（2022 年）は 4 つの原則に基づいています 取り入れなければならない基本 一緒に。グライドなしで適用します 最適ではない、あるいは逆効果な結果につながるものもあります。
データメッシュの 4 つの柱
| 原理 | 説明 | 類推 |
|---|---|---|
| 1. ドメイン指向の所有権 | ドメイン チームは独自のデータを所有および管理します | マイクロサービスと同様: 各チームが独自のサービスを所有します |
| 2. 製品としてのデータ | データは SLA、品質、文書化された製品として扱われます | パブリック API と同様: コントラクト、バージョン管理、サポートが存在します。 |
| 3. セルフサービス データ プラットフォーム | データの生成と消費のコストを削減する内部プラットフォーム | 内部 PaaS として: 自動プロビジョニング、テンプレート、ガードレール |
| 4. フェデレーテッド・コンピューティング・ガバナンス | コードとしてのポリシーによる自動ガバナンス、保証された相互運用性 | 標準とプロトコルとして: Web の HTTP、データのデータ コントラクト |
具体的な例とアーキテクチャ上の影響を示しながら、各原則を詳しく見てみましょう。
原則 1: ドメイン指向のデータ所有権
データ メッシュの第一原則により、データに対する責任が逆転します。データはもはや中央チームではありません。 会社のすべてのデータを所有する必要がありますが、 各ドメインチームが所有、生産、提供します あなたのデータ。この原則は次のことから直接インスピレーションを受けています。 ドメイン駆動設計 (DDD) エリック・エヴァンス著、特に次の概念について 境界のあるコンテキスト.
境界付きコンテキストのデータドメインへのマッピング
DDD の境界コンテキストは、ドメイン モデルがその中にある意味論的な境界です。 正確かつ明確な意味。データ メッシュでは、境界付けられた各コンテキストが潜在的なコンテキストになります。 データドメイン チーム、データ、そして責任と。
具体的な例として、中規模の電子商取引プラットフォームを考えてみましょう。その方法は次のとおりです 境界付きコンテキストはデータ ドメインにマッピングされます。
E コマース: 境界のあるコンテキストをデータ ドメインにマッピングする
| 境界のあるコンテキスト | データドメイン | 主要製品データ | チームオーナー |
|---|---|---|---|
| 製品カタログ | 製品カタログ | 製品、カテゴリ、価格、在庫 | カタログ チーム (開発者 4 名 + データ エンジニア 1 名) |
| 注文 | 注文管理 | 注文、注文明細、注文ステータス | 注文チーム (開発者 5 名 + データ エンジニア 1 名) |
| ユーザー | お客様 | ユーザープロファイル、セグメンテーション、行動 | 顧客チーム (開発者 3 名 + データ エンジニア 1 名) |
| 支払い | 支払い | 取引、和解、詐欺 | 決済チーム (開発者 4 名 + データ エンジニア 1 名) |
| ロジスティクス | 充実 | 配送、追跡、返品 | 物流チーム (開発者 4 名 + データ エンジニア 1 名) |
| マーケティング | マーケティング | キャンペーン、コンバージョン、アトリビューション | マーケティング チーム (開発者 3 名 + データ エンジニア 1 名) |
1 つの重要な側面に注意してください。どのチームにも少なくとも 1 人は含まれています。 組み込みデータエンジニア ドメイン内で。この人は中央チームの一員ではありませんが、チームに組み込まれています ドメインを共有し、そのコンテキスト、優先順位、アジャイル セレモニーを共有します。そしてその違いは 集中型モデルと比較して基本的なものです。
データドメインのアーキテクチャ
データ メッシュ内の各データ ドメインには、明確に定義されたアーキテクチャ構造があります。見てみましょう 単一のドメインを編成する方法:
+------------------------------------------------------------------+
| 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 | |
| +------------------------------------------------+ |
| |
+------------------------------------------------------------------+ドメインごとに 3 種類のデータ製品
各ドメインは、それぞれが最適化された 3 つの相補的な形式でデータを公開できます。 異なる消費パターンの場合:
- 分析テーブル (バッチ): 分析クエリおよびレポート用のオブジェクト ストレージ上の Iceberg/Delta テーブル。毎時または毎日更新されます。
- イベント ストリーム (リアルタイム): リアルタイム データを必要とする消費者向けの Kafka トピック。ダウンストリームのパイプラインと通知に最適です。
- API (オンデマンド): 特定のクエリ、ダッシュボード、アプリケーション統合用の REST または GraphQL エンドポイント。低遅延の応答。
原則 2: 製品としてのデータ
2 番目の原則、そしておそらく最も変革的な原則: データセットを副産物として扱わない アプリケーションの数、しかしその方法 あらゆる面での製品、ライフサイクルでは、 独自のユーザー、SLA、品質指標。第一原則が「誰」（チーム）を定義する場合、 ドメイン）、2 番目は「何を」（データ製品）と「どのように」（品質基準）を定義します。
データプロダクトの特徴
高品質のデータ製品は、よく言及される 8 つの基本的な特性を満たさなければなりません 頭字語で ダチス+:
データ製品の 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 |
| オプションの列 | 必須から NULL 可能へ | 下位互換性 | No |
| カラムの取り外し | 「legacy_code」を削除します | 90 日間の非推奨、その後削除 | はい（メジャーバージョン） |
| 種類の変更 | 文字列から整数へ | 新しいメジャー バージョン + 移行 | はい（メジャーバージョン） |
| 名前の変更 | 「金額」から「合計金額」まで | 一時的なエイリアス + 非推奨 | はい（メジャーバージョン） |
原則 3: セルフサービスのデータ インフラストラクチャ プラットフォーム
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 | |
| +---------------------------+ +---------------------------+ |
| |
+============================================================================+Infrastructure as Code による自動プロビジョニング
プラットフォームでは、ドメイン チームが新しいデータ プロダクトを作成できる必要があります。 インフラストラクチャへのチケットを開かずに、いくつかのコマンドを実行するだけで実行できます。 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 および中規模市場の小規模チーム |
| アパッチ アトラス | Apache/ホートンワークス | 高度なガバナンス、データ分類、監査 | Hadoop エコシステム、コンプライアンス |
| アムンセン | リフト | シンプルなユーザーエクスペリエンス、全文検索 | アナリストのためのデータ発見 |
| Unityカタログ | Databricks (オープンソース) | マルチエンジンのきめ細かいアクセス制御 | Databricks とマルチクラウド環境 |
原則 4: 連合コンピューティング ガバナンス
4 番目の原則は最も誤解されていることが多く、データ メッシュの成功にとって最も重要です。 ガバナンスなしでデータ所有権を分散化すると、混乱が生じます。しかし、ガバナンス 従来型は委員会、手動プロセス、Word ドキュメントに基づいており、拡張性がありません。データメッシュ 1つを提案します フェデレーテッドおよびコンピューティングガバナンス: 一元的に定義されたルール ただし、コード経由で自動的に適用されます。
コードとしてのポリシー
ガバナンス ポリシーは、プラットフォームが適用する実行可能ファイルにエンコードされます データ製品のライフサイクル中に自動的に実行されます。具体的な例を見てみましょう オープン ポリシー エージェント (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 は、命名規則、データ型、形式に関する世界標準を定義します。 参考。あ スキーマレジストリ 集中型 (Confluent スキーマのような) レジストリまたは AWS Glue Schema Registry) は、すべてのスキーマを登録し、バージョン管理します。
# 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連合ガバナンスの実践
フェデレーション ガバナンスは次の 3 つのレベルで機能します。
- グローバル レベル (プラットフォーム チーム): 標準、命名規則、共有タイプ、OPA ポリシー。一元的に定義され、自動的に適用されます。
- ドメイン レベル (ドメイン チーム): 特定のスキーマ、SLA、ドメイン品質ルール。チームによって定義され、プラットフォームによって検証されます。
- データ製品レベル (単一): 特定の契約、指標、アクセス。オーナーチームによって管理されています。
データメッシュの完全な技術アーキテクチャ
4 つの原則を個別に検討した後、それらがどのように組み合わされるかを見てみましょう 統合された技術アーキテクチャ。次の図は主なコンポーネントを示しています そして彼らのやりとり:
+============================================================================+
| 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: データ コントラクトを定義する
パイロット ドメインのデータ製品ごとに、データ コントラクトが定義されます (次のようなもの)。 上に示されています）。コントラクトは、ドメイン コードとともに 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: 2ステップ 4: 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 アクションの例を次に示します。
# .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データ メッシュとデータ ファブリック: 2 つの補完的なアプローチ
現代のデータ アーキテクチャの議論では、データ メッシュと データファブリック 彼らは来ます 代替案として提示されることが多いです。実際には、さまざまな問題を解決し、 共存する。データ ファブリックは、テクノロジー主導のアーキテクチャ アプローチです。 アクティブなメタデータと AI を使用して、分散データを統合および管理します。データメッシュは、 データ責任をドメインに分散させる組織的アプローチ。
データメッシュとデータファブリックの比較
| 待ってます | データメッシュ | データファブリック |
|---|---|---|
| 哲学 | 組織の分散化 | スマートなテクノロジーの統合 |
| ドライバー | 組織 (チーム、所有権) | テクノロジー（メタデータ、AI） |
| ガバナンス | フェデレーテッド、コードとしてのポリシー | 一元化された AI 支援 |
| 建築 | 共通のプラットフォームを備えた独立したドメイン | 異種ソース上の統合レイヤー |
| メタデータ | ドメインチームによって管理される | AI によって自動的に検出および管理されます |
| データ統合 | ドメイン間の明示的な契約 | 仮想化とナレッジグラフ |
| 組織の前提条件 | 高 (自律的なチーム、DevOps 文化) | 中 (中央データチームが採用可能) |
| 導入の複雑さ | 高 (組織的 + 技術的変化) | メディア (主に技術) |
| 主要ベンダー | オープンソース: dbt、Kafka、Iceberg、OPA | IBM、インフォマティカ、Talend、Denodo |
| に最適 | 多くのドメインを持つ大規模な組織 | 異種のレガシー システムを使用する組織 |
データ メッシュとデータ ファブリックを組み合わせる場合
多くの成熟した組織では、データ メッシュとデータ ファブリックが共存しています。データ ファブリックでできることは、 データ メッシュのセルフサービス データ プラットフォーム内の統合レイヤーとして機能し、 データ仮想化、ナレッジ グラフ、自動メタデータ検出を提供します。 データ メッシュは、組織モデル (所有権、契約、フェデレーション ガバナンス) を提供します。 一方、データ ファブリックは技術的な機能 (アクティブなメタデータ、統合) を提供します。 インテリジェント、クエリフェデレーション)。
実際のケーススタディ: データ メッシュを採用しているのは誰ですか
データ メッシュは単なる学術理論ではありません。いくつかの大規模な組織がそれを採用しています。 測定可能な結果が得られます。 4 つの重要なケーススタディを見てみましょう。
ザランド: ヨーロッパの先駆者
ザランド、5,000 万人以上の顧客を持つヨーロッパのオンライン ファッション大手 active は、2020 年からデータ メッシュを最初に採用したチームの 1 つです。200 を超えるチームが参加しています 開発と数百のマイクロサービスにより、集中型データ ウェアハウスは 持続不可能なボトルネック。
- 結果： 新しいデータ製品のオンボーディング時間が 4 週間から 2 日に短縮されました
- プラットフォーム: Databricks、Kafka、内部カタログに基づくセルフサービス プラットフォーム
- インパクト： 80以上のドメインチームによって公開された600以上のデータプロダクト
- 学んだ教訓: 連合ガバナンスが最大の課題でした。世界標準がなかったため、最初の数か月間は一貫性のないデータ製品が生成されました
Netflix: DNA のデータ メッシュ
Netflix データ メッシュを変換プロジェクトとして採用しませんでした。 分散型アプローチは常に組織の DNA の一部となっています。 230以上 数百万の加入者とペタバイトのストリーミング データ、すべての製品チームとマネージャー データをエンドツーエンドで管理します。
- 結果： 4,000 を超えるデータセットがドメイン チームによって個別に管理されている
- プラットフォーム: Apache Iceberg (Netflix によって作成)、Apache Spark、カスタム内部プラットフォーム
- インパクト： コンテンツおよびレコメンデーションチームにとって、洞察を得るまでの時間が数日から数分に短縮されました
- 学んだ教訓: セルフサービス プラットフォームと最も重要な投資。それがなければ、分散化は断片化を生み出すだけです
JPモルガン・チェース: 銀行業務におけるデータメッシュ
JPモルガン・チェース資産規模で米国最大の銀行である 6,000 万を超える顧客のデータを管理する 2021 年のデータ メッシュへの道 消費者と数千の機関顧客。銀行セクターには次のような特有の課題があります。 厳格な規制、複数の管轄区域にわたるコンプライアンスおよび監査要件。
- 結果： リスクチームのデータパイプライン配信時間を 40% 削減
- プラットフォーム: ガバナンスを強化したハイブリッドクラウドベースの社内データプラットフォーム
- インパクト： GDPR、SOX、銀行規制への自動コンプライアンス
- 学んだ教訓: 銀行業界では、連合ガバナンスをより厳格にする必要があります。 OPA ポリシーは展開の妨げとなる要件となっています
Intuit: FinTech 向けデータ メッシュ
直感TurboTax、QuickBooks、Mint の背後にある会社は、 1 億を超える顧客の財務データを管理するデータ メッシュ。挑戦 主なものは、異なる製品間のプライバシーとデータのセグメント化でした。
- 結果： 200 以上のデータ製品を含む 15 以上のアクティブなデータ メッシュ ドメイン
- プラットフォーム: Iceberg、dbt、内部カタログを備えた AWS ネイティブ
- インパクト： 新しい洞察の開発時間が 60% 削減
- 学んだ教訓: データ契約は、規模拡大時に品質を維持するために不可欠でした。これらがなければ、ドメイン間の依存関係は壊れていたでしょう。
課題、アンチパターン、およびデータ メッシュを使用すべきでない場合
データ メッシュは万能のソリューションではありません。重大な課題があり、適切ではありません すべての組織に。限界を理解することは理解することと同じくらい重要です 利点。
データメッシュの 5 つのアンチパターン
- 1. プラットフォームレス データ メッシュ (ワイルド分散化): セルフサービス プラットフォームを提供せずにデータ所有権を分散化することは同等です 各チームに独自のインフラストラクチャを一から構築するよう依頼します。結果は 断片化、重複、および指数関数的なコスト。
- 2. 技術プロジェクトとしてのデータメッシュ: データ メッシュは主に組織変更です。ただ次のようにアプローチすると 所有権を変更せずに技術的な移行 (新しいカタログ、新しいプラットフォーム)、 インセンティブとチーム構造の結果、同じものを備えた新しいプラットフォームが作成されます。 集中モデルの問題点。
- 3. ドメインが多すぎると早すぎる: モデルを検証せずに 20 のドメインでデータ メッシュを同時に起動する ドライバーが 2 ～ 3 人程度と失敗のレシピが 1 つあります。漸進的かつ基本的なアプローチ。
- 4. 強制力のないデータ契約: CI/CD に統合されていないために誰も尊重しないデータ コントラクトを定義する そして自動化されたガバナンスにおいても。契約は装飾的なものではなく、強制力のあるものでなければなりません。
- 5. 連合ガバナンスの無視: ガバナンスのない分散化は混乱を生み出します。各ドメインが独自の発明を行う 標準、命名規則、形式により、互換性のないデータのエコシステムが形成されます。
データメッシュを採用すべきではない場合
データ メッシュはすべての組織に適しているわけではありません。それを示す兆候は次のとおりです 集中型モデルが依然として最良の選択である可能性があります。
チェックリスト: データ メッシュは次のような場合には適していません...
- 製品チームが 5 人未満: チームの数が少ないと、一元化がうまく機能し、組織のオーバーヘッドが少なくなります。
- 組織内の人数が 50 人未満の場合: 調整はすでに自然であり、正式な構造は必要ありません
- 1 つのビジネス ドメイン: すべてが単一の製品を中心に展開する場合、分散化は意味がありません
- DevOps 文化がない: チームがエンドツーエンドのソフトウェア所有権に慣れていない場合、データ責任の追加は機会ではなく負担に感じられるでしょう
- データ プラットフォームがありません: セルフサービス プラットフォームがなければ、どのチームも車輪の再発明が必要になります
- プラットフォーム チームの予算は限られています: セルフサービス プラットフォームには多額の初期投資が必要です (通常、6 ～ 12 か月間、3 ～ 5 人の専任エンジニアが必要)
イタリアの背景: 中小企業とデータ分散化
イタリアの起業家精神の基盤は 95% の零細企業と中小企業で構成されており、 従業員数は50名。こうした現実を考えると、完全な形のデータ メッシュは過剰であることがよくあります。 工学の。ただし、その根底にある原則は普遍的に有効であり、 小規模な組織にも適応できます。
データメッシュをイタリアの中小企業に適応させる
従業員数が 50 ～ 200 名で、機能分野が 3 ～ 5 つある中小企業は、簡易バージョンを採用できます。 データメッシュの データメッシュライト:
SMB向けデータメッシュライト
| 原理 | フルデータメッシュ | データメッシュライト (PMI) |
|---|---|---|
| ドメインの所有権 | ドメイン別の組み込みデータ エンジニア | 職能別データマネージャー（非常勤） |
| 製品としてのデータ | 正式なデータ契約、API、Kafka | 共有シート + dbt 内のスキーマと所有者を含む文書化されたデータセット |
| セルフサービス プラットフォーム | カスタム内部プラットフォーム | DuckDB + dbt + BI ツール (メタベースまたはスーパーセット) |
| 連合ガバナンス | OPA、スキーマ レジストリ、コードとしてのポリシー | 共通の命名規則 + DBT テスト + 四半期レビュー |
文化的な課題
イタリアの中小企業にとっての最大の課題は技術的なものではなく文化的なものです。企業文化 イタリア人は意思決定の集中化、垂直的な階層構造、 変化に対する抵抗。データ メッシュでは、その逆であるチームの自主性、責任が求められます。 分散型かつ水平的なコラボレーション。この文化的変化にはリーダーシップが必要です 強力で継続的なトレーニングとパイロットプロジェクトからの具体的な結果。
PNRRの機会とデジタル移行
トランジション 5.0 資金が枯渇したにもかかわらず (トランジション 5.0 資金は 2025 年 11 月 6 日に終了) 2024 年から 2025 年の 2 年間）、2026 年から 2028 年のサイクルでは新たな資金調達の機会が期待されます。 すでにデータ ガバナンスとデータ アーキテクチャへの取り組みを開始している中小企業は、 これらの資金にアクセスできる特権的な立場にあり、デジタルの成熟度を実証し、 具体的な実施計画。
結論: データ メッシュの準備状況チェックリスト
データ メッシュは、組織の管理方法におけるパラダイム シフトを表しています。 あなたのデータ。導入するテクノロジーではなく、採用する組織モデルです 段階的に。 4 つの原則 (ドメイン所有権、製品としてのデータ、セルフサービス プラットフォーム、 有意義な結果を生み出すには、連合ガバナンス）を一緒に実装する必要があります。
準備チェックリスト: あなたの組織の準備はできていますか?
- 組織： 明確なビジネス ドメインを持つ少なくとも 5 つ以上の製品チームがいますか?
- 文化： チームには意思決定の自主性とサービスのエンドツーエンドの所有権がありますか?
- ボトルネック: 中央のデータ チームと数週間にわたるキューがボトルネックになっていますか?
- 階段： 50 以上のデータ パイプラインまたは 100 以上のデータセットを管理していますか?
- 予算： 専用のプラットフォーム チーム (3 ～ 5 人で 6 ～ 12 か月間) に投資できますか?
- スポンサーシップ: 組織変更に対するリーダーのサポートはありますか?
- スキル: ドメイン チームに組み込まれたデータ エンジニアがいますか、または雇用できますか?
- インフラストラクチャー： すでにデータ プラットフォーム (クラウド DWH、データ レイク、レイクハウス) をお持ちですか?
これらの質問のうち 6 つ以上に「はい」と答えた場合、次はおそらく Data Mesh です。 データ アーキテクチャの成熟の一歩を踏み出します。 4つ未満で「はい」と答えた場合、 まず強固な基盤に焦点を当てます (最新のデータ ウェアハウス、データ チーム、データ駆動型の文化) 12 ～ 18 か月後に再評価します。
覚えておくべき重要なポイント
- Il データメッシュ これはテクノロジーではなく、組織のパラダイムです。データの責任をドメイン チームに分散します。
- I 4つの原則 (ドメイン所有権、製品としてのデータ、セルフサービス プラットフォーム、フェデレーション ガバナンス) を同時に採用する必要がある
- I データ契約 これらはシステムの中心であり、スキーマ、SLA、品質を機械で読み取り可能かつ検証可能な方法で定義します。
- La セルフサービス データ プラットフォーム そして最も重要な技術的投資: それがなければ分散化は断片化を生み出す
- La フェデレーションガバナンス 自律性と一貫性のバランス: 一元的に定義されたポリシーが自動的に適用されます
- データメッシュ 誰にとってもそうではない: 小規模または小規模なドメインの組織は、一元化モデルからより多くの価値を得ることができます
- Le イタリアの中小企業 DuckDB、dbt、および簡素化された組織原則を備えた「データ メッシュ ライト」を採用できます。
- ザランド、ネットフリックス、JPモルガン 彼らは、モデルが大規模に機能するが、プラットフォームとガバナンスへの投資が必要であることを実証しています。
シリーズの次の記事では、密接に関連するトピックについて取り上げます。 クラウドにおける ETL と ELT。最新のデータ パイプラインがどのようなものかを探っていきます 従来のバッチ ETL から dbt を使用したクラウドネイティブ ELT への進化と、これらのパイプラインがどのように機能するか これらはデータ メッシュ アーキテクチャに統合され、各ドメインのデータ製品を強化します。
推奨される実践的な演習
次の記事に進む前に、データ ドメインを定義してみてください。 組織。紙を用意して、次の質問に答えてください。
- 製品チームは何チームあり、どのようなビジネス領域をカバーしていますか?
- 各ドメインについて、最も重要なデータセットを 2 ～ 3 つ選択してください。
- 現在、各データセットの責任者は誰ですか? (答えが「誰も」または「IT チーム」であれば、問題は見つかったことになります)
- どのデータセットが複数のチームによって使用されますか? (これらはデータ製品となる最初の候補です)