データプラットフォーム技術におけるメダリオンアーキテクチャという考え方/DataPlatformWithMedallionArchitecture

データプラットフォーム技術とそれを支えるメダリオンアーキテクチャという考え方について説明しています

Transcript

1. データプラットフォーム技術における メダリオンアーキテクチャという考え⽅ 島⽥ 雅年 2025.6.25 Database Engineering Meetup
2. データプラットフォームエンジニア • GitHub: @smdmts • X: @smdmts • Software Engineer, Software Architect, Data Engineer • データプラットフォーム技術バイブルの著者 ⾃⼰紹介 2 Masatoshi Shimada 島⽥雅年
3. • データ抽象度とデータ処理 ◦ DIKWモデル ◦ メダリオンアーキテクチャの概要 • メダリオンアーキテクチャという考え⽅ ◦ データとふるまいの分離 ◦ 各ステージにおける主な課題 アジェンダ 3
4. • 本セッションは、 ◦ データ基盤設計において「データとふるまいの分離」の重要性について解説するもの ◦ 単なる技術選択ではなく、データ要件の抽象度に基づいた段階的に品質保証するアプローチを紹介 ◦ 普遍的なデータ処理の設計原則における課題の分離を試みる • ⚠メダリオンアーキテクチャは設計⼿法の⼀例であり、⽬的ではないことに注意⚠ データプラットフォーム技術における メダリオンアーキテクチャという考え⽅ 4
5. 5 データ抽象度とデータ処理
6. • Data（データ）：⽣データ、それ⾃体は意味を持たない記録物 • Information（情報）：構造化されたデータで、何らかの意味を持つ • Knowledge（知識）：情報を元に得られた洞察や理解、ダッシュボード • Wisdom（知恵）：意思決定などの⾏動に結びつく主観的な情報 データエンジニアリングは、この抽象度の階段を効率的にフィードバックループするための仕組みづくり • 知識（静的）と知恵（動的）はフィードバックループする関係にある • 情報を集める（知識）→情報を活⽤する（知恵）→更に情報を集める（知識）→ ... 続く • 例：サッカー監督は事前に相⼿チーム選⼿の情報を集める（知識）→その情報を元に出場選⼿を決定する （知恵）→実際の試合で選⼿の動きを観察する（知識）→試合状況を⾒て選⼿交代を指⽰する（知恵）→ ... 続く DIKWモデル データ抽象度とデータ処理 6
7. • DataからWisdomへ段階的に抽象度を引き上げる⾏為がデータエンジニアリングの本質 • 抽象度の各階層で異なる技術と異なる品質要件が求められる ◦ Data → Information：データの構造化 ◦ Information → Knowledge：データの集約と分析 ◦ Knowledge → Wisdom：データの可視化と意思決定⽀援 ◦ Wisdom → Data：必要に応じて新たなデータの収集と蓄積 • 各階層で異なる職種が関わる（関⼼事が異なる） ◦ Data → Data Engineer ◦ Information → Data Engineer, Data Analyst、Data Scientist ◦ Knowledge → Data Analyst, Data Scientist ◦ Wisdom → Data Analyst, Business Unit DIKWモデルのイメージ データ抽象度とデータ処理 7
8. データ抽象度の階層は、メダリオンアーキテクチャの各ステージに対応する • Landing：⽣データ（Data） • Bronze：⽂字列として構造化されたデータ（Data） • Silver：重複⽋損のない集約可能なデータ（Information/Knowledge） • Gold：可視化や意思決定⽀援するデータ（Knowledge） Wisdomは、メダリオンアーキテクチャの外側に位置する抽象度の階層であり、⼈の判断⼒に依存する データプラットフォームの本質的な役割とは、⼈のWisdom（知恵）を⽀えるための知識ネットワークの提供 DIKWモデルとメダリオンアーキテクチャの対応 データ抽象度とデータ処理 8
9. データプラットフォームは、いずれの世代においても、ドメイン知識のコアであるGoldを⽣成するための装置 • 第⼀世代：データウェアハウス ◦ 構造化データをデータウェアハウスに格納して、BIツール‧レポートなどに利⽤ • 第⼆世代：2層型データプラットフォーム（データウェアハウス＋データレイクの併⽤） ◦ BIツール‧レポートはデータウェアハウス、データサイエンス‧機械学習はデータレイクを利⽤ • 第三世代：Lakehouseプラットフォーム（データレイク） ◦ 全データをデータレイク上で管理し、BIツール‧レポート‧データサイエンス‧機械学習などに利⽤ データプラットフォーム技術の進化 データ抽象度とデータ処理 9
10. • データと処理を分離できるメリットに対して、データ責任範囲が曖昧になるデメリット ◦ データカタログやメタデータの管理は必須 • オールインワン型のデータプラットフォームは、提供されていない機能を⾃前で⽤意する必要がある ◦ 例1：OLAPではレイテンシ等に問題があるため、⾼頻度の検索/更新が必要な場合はRDBMSを併⽤ ◦ 例2：⾃然⾔語処理（NLP）や⼤規模⾔語モデル（LLM）の為に、ElasticsearchやベクターDBを併⽤ 実際のデータプラットフォームは、複数の要素技術を組み合わせて構築されることが多い • 構成例：Apache Spark + PostgreSQL + Elasticsearch Lakehouseプラットフォーム（補⾜） データ抽象度とデータ処理 10
11. 11 メダリオンアーキテクチャという考え⽅
12. データ抽象度の階層は、メダリオンアーキテクチャの各ステージに対応する • Landing：外部システムからのデータ受信領域。Landingを設けずBronzeと同⼀にする場合がある。 • Bronze：⽂字列として構造化されたデータ。既に構造化されているRDBMS等から受信する場合は、 Bronzeをスキップする場合がある。 • Silver：重複⽋損のない集約可能なデータ。ドメイン知識毎に複数階層に分ける場合がある。 • Gold：可視化や意思決定⽀援するデータ。ビジネスのドメイン知識そのもの。 メダリオンアーキテクチャの概要 メダリオンアーキテクチャという考え⽅ 12
13. • Landing→Bronze→Silver→Goldの各ステージで、段階的にデータ処理状況を検証する ◦ Landing/Bronzeは、⼀貫性のあるデータ受信などの検証が必要 ◦ Silver/Goldは、⼀貫性のあるドメイン知識の検証が必要 各ステージは明確に「関⼼事」が異なるため、「関⼼事の分離」の適⽤が可能 • システムのあるべき姿とは、 ◦ ドメインモデルが「知識が厳密に構成され、選び抜いて抽象化されている」状態 ◦ データとふるまいの分離を通じて、「機能の責任範囲が明確」な状態 メダリオンアーキテクチャの⽬指すもの メダリオンアーキテクチャという考え⽅ 13
14. • データ（Data）とは「何が必要か」を定義するもの • ふるまい（Function）とは「どのように実現するか」を定義するもの この2つは異なる関⼼事で、技術者は「ふるまい（要素技術）」に注⽬するケースが⾮常に多いが、 現実世界のビジネスでは、データ要件やデータ品質の⽅が遙かに重要で、それらを保証する処理が必要 • 上流から下流に向かい、漸進的/段階的なデータ品質の保証を⽬的とする契約が必要と⾔い換えられる • データパイプラインにおいても、契約プログラミング やSOLID原則の適⽤が有効と考えられる ◦ 契約プログラミング：データ処理実⾏時にガード条件などを適⽤する ◦ SOLID原則：単⼀責任の原則やオープン‧クローズドの原則などを適⽤する データ要件とふるまい要件 メダリオンアーキテクチャという考え⽅ 14
15. 理想的には、各ステージ間のTransformの前後でrequireとassertでデータ品質や要件を保証するのが望ましい 契約プログラミング（補⾜） メダリオンアーキテクチャという考え⽅ 15
16. データプラットフォーム技術は、「データ（Data）」と「ふるまい（Function）」を分離して考えることが重要 • データ：（What）どのようなデータが永続化されるか • ふるまい：（How）どのようにデータを処理するか データとふるまいは、次のような性質の差がある • 「データ」が保持する情報や意味は、静的（スタティック）に保持され続ける • 「ふるまい」は技術の進化により、動的（ダイナミック）に変化し続ける データとふるまいの分離 メダリオンアーキテクチャという考え⽅ 16
17. • データ要件： ◦ データプラットフォームが管理すべきデータの種類、データアクセス権、データフローなど ◦ 必要となるデータが分からない場合は、とりあえず必要と考えられるデータを収集しておくなど • ふるまい要件： ◦ 「ふるまい」とは、データをどのように処理するかに着⽬ ◦ ある業務要求を実現するにあたり、どのような「ふるまい」を定義するか ◦ データプラットフォーム技術バイブルでは「業務」に対する「ふるまい」を定義している データ要件とは「何が必要か」を定義し、ふるまい要件とは「どのように実現するか」を定義する。 この分離により、疎結合かつ⾼凝集なデータ処理の設計が可能となる。 データ要件とふるまい要件の違い メダリオンアーキテクチャという考え⽅ 17
18. データパイプラインおける各ステージは、上流と下流の間で⼀貫性のあるデータ品質を保証する • 実⾏時検証やデータ監視などで、契約（データ仕様）が守られていることを確認できるか • データ不整合が発⽣した場合に、速やかに異常追跡ができるデータ構造であるか • ドメイン知識に基づくデータの整合性確認を⾏える仕組みがあるか データ要件で対処すべき主な課題 メダリオンアーキテクチャという考え⽅ 18
19. データを「どのように処理するか」の前提に⽴ち、実⾏時のパフォーマンスや処理の堅牢性を考慮する • データを効率的に処理できる技術選択となっているか ◦ データの即応性を重視する場合は、ストリーミング処理を選択する ◦ 複雑なデータの集約が発⽣する場合は、バッチ処理を選択する ◦ 将来の担当者が安定/安⼼/安全に運⽤できる可能性の⾼い要素技術を選択する • データ変換や集約の実装が明確であり、修正や変更の対象が速やかに把握可能であるか ふるまい要件で対処すべき主な課題 メダリオンアーキテクチャという考え⽅ 19
20. • メダリオンアーキテクチャは、各ステージの課題を明確に分離することを⽬指す • 各ステージで段階的に処理を実⾏し、各ステージで必要となる要件や品質の保証を試みる • 各ステージの課題を分離することで、データパイプラインの設計がシンプルになり、保守性の向上が期待 できる 各ステージの課題は、データ要件とふるまい要件に分けて考えることで、より明確な設計が可能となる 次ページでは、各ステージにおける具体的な課題の例を紹介（Landing/Bronze/Silver/Gold） 各ステージの課題の分離を試みる メダリオンアーキテクチャという考え⽅ 20
21. メダリオンアーキテクチャは、データの品質保証における各ステージの課題は次のようになる • Landing：外部システムから適切にデータを受信すること • Bronze：⽂字列として構造化されていること • Silver：重複や⽋損がない集約可能なデータであること • Gold：可視化や意思決定⽀援するデータであること 各ステージをデータ要件とふるまい要件に分けて考えることで、課題の分離による保守性の向上が期待できる。 ただし、現実のシステムでは、Bronze、Silver、Goldという三層の分離では無理があることも多いので注意。 • 多数のシステム連携が必要となる場合。（bronze_a、bronze_b、bronze_c…） • 境界付けられたコンテキストが複数ある場合。（silver_a、silver_b、silver_c…） • データ消費層のドメイン分割が明確な場合。(gold_a、gold_b、gold_c…） 各ステージの主な課題 メダリオンアーキテクチャという考え⽅ 21
22. データ要件： • データ受信の完全性：ファイル完全性チェック、データ⽋損‧破損の検出、送信完了の確認 • データ形式の多様性への対応：レガシー圧縮形式（LZH等）、単純⽂字列や⾃然⾔語、バイナリファイル • データ保持‧バックアップ：⼀度しか受信できないデータの永続化、受信履歴の記録 • データ仕様の曖昧性排除：外部システムが出⼒するデータ仕様の明確化、スキーマ定義の整備 ふるまい要件： • 外部システム連携：送信側システムの特性把握、受信タイミング‧頻度の監視 • 受信処理の信頼性：ネットワーク障害時のリトライ、部分受信時の継続処理、バックアップの実⾏ Landing（受信データ）における主な課題 メダリオンアーキテクチャという考え⽅ 22
23. データ要件： • データ形式の標準化：CSV/JSON/XML等の⾏列化、⽂字コード‧NULL値表現の統⼀ • トレーサビリティ：スキーマ変更時の互換性や変更時のバージョン管理 ふるまい要件： • 処理性能‧技術実装：⼤容量ファイルの並列処理、全てString型として扱う • 処理の信頼性‧復旧性：リトライ機構、部分的な処理の再実⾏ 🥉Bronze（ローデータ）における主な課題 メダリオンアーキテクチャという考え⽅ 23
24. データ要件： • データ品質の保証：重複除去‧⽋損値補完、データ型の正規化や整合性の確保 • ビジネスルールの適⽤：ドメイン知識に基づくデータ変換や集約や適切なデータ粒度の確保 • 集計可能なデータ構造：探索的データ分析⽤のテーブル設計、時系列データの構造整理 ふるまい要件： • データ変換‧クレンジング：複雑なETL処理の明解化、⼤量データの効率的変換、増分更新の実装 • 品質監視‧検証：データ品質メトリクスの監視、異常値検出アルゴリズム、品質劣化時の⾃動対応 • パフォーマンス最適化：クエリ性能の向上、パーティショニングやリキッドクラスタリング等の技術活⽤ 🥈Silver（クレンジングデータ）における主な課題 メダリオンアーキテクチャという考え⽅ 24
25. データ要件： • データ品質の保証：ドメイン知識に基づく正確なデータであること • ビジネス価値の最⼤化：意思決定⽀援データの設計、KPI‧メトリクスの定義、ダッシュボードが提供する 価値の最⼤化 ふるまい要件： • 多様な形式への対応：DeltaLake/Iceberg、ベクターDB、グラフDB、Elasticsearch、RDBMS等の使い分け • 認証認可（ガバナンス）：部⾨‧役職別のデータアクセス権、セキュリティ要件が満たされていること • ⾼速クエリ‧可視化：リアルタイム分析の実現、BIツール連携、レスポンス性能の最適化 • 検索多様性：RAG（検索拡張⽣成）の実装、LLM連携、⾃然⾔語検索 • 運⽤：データカタログ管理、利⽤状況監視、コスト最適化とリソース管理 🥇Gold（消費データ）における主な課題 メダリオンアーキテクチャという考え⽅ 25
26. • データ（Data）とふるまい（Function）の分離は、データプラットフォーム技術の課題の核⼼ • メダリオンアーキテクチャは、データ処理やデータ品質を段階的に検証するアプローチ • 各ステージには、それぞれ異なる要件や要求があり、段階的に課題が分離される • 段階的な課題の分離は、特定の要素技術に依存せず、普遍的な設計原則と考えられる 話したこと 26