- Netflixでは、ビジネスドメイン（例: 映画、俳優、シリーズなど）のデータモデリングが各システムごとに重複・不一致・非標準用語のため、 協業とデータ品質の問題に直面していた
- UDA（統合データアーキテクチャ）は「一度モデル化し、どこでも表現する」を目標に、 ドメイン概念を一度定義し、さまざまなシステムへ一貫して投影・接続するナレッジグラフ基盤のインフラである
- UDAは ドメインモデル→データコンテナ（例: GraphQL、Avro、Iceberg など）への自動スキーマ生成・マッピング・データ移動の自動化 を支援する
- ビジネスユーザーは Sphere や PDM などの UDA 活用ツールを通じて、用語検索だけでデータ探索・レポート生成・参照データ管理が可能
- RDF・SHACL などのセマンティック技術の上に独自の Upper メタモデルを適用 し、大規模なコラボレーション・ガバナンス・スキーマ一貫性・拡張性をすべて実現している
Netflixシステムの複雑化とドメインモデルの課題
- Netflixのサービスが映画、シリーズ、ゲーム、ライブイベント、広告などへ拡大するにつれ、それを支える システムの複雑性 も大きく増加した
actor、movie のような 中核的なビジネス概念 が、異なるシステム（Enterprise GraphQL Gateway、資産管理プラットフォーム、メディアコンピューティングなど）で個別に定義され、連携や共有なしに分断されたまま運用されていた- その結果、次のような問題が発生
- 重複と不一致のあるモデル: 異なるシステムで同じエンティティが再定義され、衝突回避が困難
- 用語の不一致: 同一システム内でも異なる用語の使用、あるいは同じ用語の重複使用によりコミュニケーションが混乱
- データ品質の問題: 多数のマイクロサービス間に不一致や参照エラーが存在し、識別子や外部キーの管理も不十分で手動改善が必要
- 接続性の限界: システム内の関係性が限定的で、システム間連携も不十分
- こうした問題を解決するには、一度概念モデルを定義したらあらゆる場所で再利用 し、実際のシステムやデータと実質的に接続・統合する基盤が必要だった
UDA（統合データアーキテクチャ）の概要
- UDA は Netflix Content Engineering における データ接続性基盤のプラットフォーム
- ドメインモデル（ビジネス概念）を一度定義することで、すべてのシステムへの一貫した投影と、自動化・発見・セマンティック相互運用性を支援する
- UDAで可能な主な機能
- ドメインモデルの登録と接続: 公式な概念定義を単一のソースとして使い、チーム間の混乱や重複モデリングを防止
- ドメインモデルとデータコンテナのマッピング: ビジネス概念と実データの保存場所（データベース、テーブル、サービスなど）および構造を把握しやすいよう、グラフ構造で表現
- ドメインモデルをスキーマ定義言語へ変換: GraphQL、Avro、SQL、RDF、Java など、さまざまなシステム向けに自動変換し、手作業を最小化してエラーを減らす
- データコンテナ間の信頼できるデータ移動: GraphQLエンティティ、Data Mesh、CDC、Iceberg などのシステム間でデータ変換・移動を自動処理
- ドメイン概念の探索と検索: ビジネス概念間の関係を探索・検索でき、正確な情報を得やすい
- ナレッジグラフのプログラマブルなイントロスペクションを提供: Java、GraphQL、SPARQL で接続されたビジネス情報を活用し、自動化やインサイト抽出を実現
UDAの中核アーキテクチャ
-
Knowledge Graph ベース
- RDF/SHACLベースのナレッジグラフ により、ドメインモデル・スキーマ・データコンテナ・マッピングなど、すべての要素をグラフデータとして接続
- named graph中心の情報モデル により、各 named graph が規律あるガバナンスモデルに従い、解釈体系、モジュール化、運用ポリシーを実現
-
Upper メタモデル
- Upper はドメインモデルを厳密に定義するメタモデル言語
- ドメインごとの主要エンティティ・属性・関係を型と階層構造でモデル化し、RDFで表現・バージョン管理・クエリ可能
- Upper 自体も Upper でモデル化されており（自己参照・自己妥当性検証）、あらゆる拡張・投影に一貫性を提供
- 属性値についてドメインごとのカスタマイズが可能で、すべての概念は conceptual RDF および named graph として表現され、イントロスペクション・検索・バージョン管理を支援
- Upper は高水準の抽象化とともに、RDFS/OWL/SHACL などの W3C セマンティック技術の中核のみを厳選して適用し、オントロジーの概念を知らなくても効果的にドメインモデリングできる
- Upper メタモデルから Jenaベースの Java API と GraphQL スキーマを自動生成 し、実際の GraphQL サービスと連携
-
データコンテナとマッピング
- Data Container: 実際のデータ保存先（例: GraphQLサービスのエンティティ、Data Mesh ソースの Avro レコード、Iceberg テーブルの行、Java API のオブジェクトなど）
- マッピング（Mappings）: ドメインモデルの特定要素とデータコンテナ（テーブル、フィールドなど）との一対一の対応を定義
- マッピングを通じて ドメイン概念→実データの所在を追跡でき、逆にデータ→関連するドメイン概念の探索も可能
- 意図ベースのデータ移動/自動化: マッピング情報を活用して、データフローや変換をシステムが自動的に判断
-
Projections（投影）
- ドメインモデル→ターゲットシステムのスキーマ（例: GraphQL、Avro など）へ自動変換・生成（コード・スキーマ・パイプラインの自動化）
- スキーマ一貫性を保証し、重複定義や同期の問題を最小化
実際の適用事例
-
PDM（Primary Data Management）
- 参照データおよびタクソノミー（階層型分類体系）管理プラットフォーム
- ドメインモデルを階層型またはフラットな分類へ変換し、ビジネスユーザー向け UI を自動生成
- ビジネス用語を一貫して定義し、SKOS モデルをベースに、UDA により Avro・GraphQL スキーマ/パイプラインを自動生成
- ドメインモデルだけを入力すれば、UI/データパイプライン/GraphQL API が自動構成される
-
Sphere（Operational Reporting）
- ナレッジグラフベースのセルフサービス運用レポーティングツール
- ドメイン用語ベースの検索・探索・JOIN戦略の自動化により、技術的な複雑さなしでデータ発見やレポート作成が可能
- UDA ベースのメタデータ/マッピングにより、実データの所在と JOIN ロジックまでシステムが自動で把握・実行
actor、movie のような馴染みのある用語で概念を探索し、選択した概念をもとにナレッジグラフをたどって SQL クエリを自動生成し、別途 JOIN や技術作業なしにデータを取得できる
結論と展望
- UDA は Netflix のデータモデリングと統合のあり方に根本的な変化 をもたらしている
- 一度のドメインモデル定義によって、組織全体のシステムで一貫性があり、自動化され、拡張性のあるデータ連携が可能になる
- 今後は Protobuf/gRPC などの追加サポートや、ナレッジグラフの実データ化など、適用範囲の拡大が予定されている
2件のコメント
似たようなものを構築しなければならないのですが、途方に暮れています。
Hacker Newsの意見
あらゆる利点があるにもかかわらず、この方式にはあまり語られない大きな問題があると思う
それはビジネス上の問題であり、技術的な問題にも影響するため、結局は開発速度に影響する二次的な技術課題として作用する
組織全体が単一の統合データ定義を信頼できるという契約がビジネスにかかっているため、今やデータを定義・修正するときには自分の領域だけでなく、組織全体のさまざまなユースケースを考慮せざるを得ない
小さな変更ですら組織全体に影響するので、多様なステークホルダーの承認を経るほど複雑な手続きが生まれる
これは大企業でいう「ボタンの色を変えるのに2か月かかる理由」という古典的な問題のデータ版だ
もちろん、通常はデータを複製したり一貫性なく分散させたりするほうが、より深刻な問題だという点は認める
しかし時には、小さく孤立した変更をすばやくデプロイしたい場面で、このようなシステムが大きな障害になる
これを解決しようとして製品を開発したことがある
企業共通モデルに従いつつも、ローカルでモデルを簡単に特化できる方式（Prologのようなデータ定義言語を拡張し、その場しのぎではなく現実に基づく企業モデルを本気で考えること）を試みた
残念ながら、NoSQL、Big Dataブームの真っ最中に試したのでタイミングが悪かった
NoSQL、Big Dataは緩いモデルで運用でき、データが一部失われたり誤解されたりしても後で継ぎはぎすればいいという文化だった
初期に強力なモデルを設計するより、後始末がしやすいという空気で、少し残念だったが受け入れた
本質的にビジネスの問題だという点には同意するし、私たちは技術によってこれを体系的に解決できると考えている
エンタープライズ内でモデルファーストなナレッジグラフを導入・展開する、より体系的な方法を用意できたという自信がある
UDAは、要求されるものすべてをかえって追加の官僚主義にしないよう慎重にアプローチしている
UDAは既存システムと並存し、無条件の採用を強制しない
しかし、自分たちのビジネスモデルをどこでも活用でき、簡単に接続・拡張・発見できるようにしたいチームにとっては、強力で使いやすいツールになることを目指している
（自分はUDAアーキテクトの一人であることを明かしておく）
経験上、社内の「大物(big men)」の主張のせいで、論理的または一貫したデータモデルが作られないことが多かった記憶がある
現場の技術者たちがデータをもっと合理的かつ標準に沿って扱おうとしても、影響力のある人物が自分の頭の中のモデルを作って、開発者にそれへ合わせるよう強いる現実がある
こうした象徴的な思考様式がひとたび入り込むと、その会社で一貫したデータモデルが作られる可能性は0に収束する
結局こうした問題のために、コンサルタントに非効率に多額の金が支払われる構造だと思う
SAPが何なのか長いこと疑問だったが、実際に知って驚いた経験がある
数多くの企業でSAPが使われているので、ものすごい技術力があるのかと推測していたが、実際には固定スキーマを置き、顧客にその構造へ適応するよう求める方式だと知った
原文が、これがビジネス上の問題である点を否定しているようには読めない
定義されたモデルはあらゆる役割にまたがって定義され、エンジニアリングはその一部にすぎないという見方だ
Semantic Web、RDF、OWL、SKOSなどが登場してからかなり時間が経ったと感じる
W3Cを引き続き支持し、すでにある車輪を再発明しなかったのはよかった
UDAの方式が大衆的に定着するかは分からないが、組織規模が大きい場所でDDD（ドメイン駆動設計）とセマンティックな概念を適用するときの難しさを革新的に減らそうとする試みとして期待している
複数の開発チームに、同じデータ意味体系を共有する共通のツールと技術セットを提供し、「複利(compound interest)」効果を狙えるなら、データ契約をDTO、POSTなどネットワーク転送の都合で無理やり平準化しなくてもよくなるかもしれないという点が興味深い
こうした興味深い実験を公開しながら進めているNetflixには好意的だ
UberのDragonというプロジェクトを思い出した
Dragon schema at Uber に関する作業をしていたことがあったが、オープンソース化はできなかった
その後JoshuaはLinkedInに移り、LambdaGraphプロジェクトとHydra言語に参加し、これらは ここ でオープンソースとして公開されている
こうした方式や10年前のSemantic Webの流れは、いずれも概念を形式化して維持しなければならない追加作業量が大きすぎたのが欠点だった
今ではLLM（大規模言語モデル）でこの負担を減らせるのか気になる
今回使われている「ドメインモデル」という用語の選び方が惜しい
ここでのドメインモデルは純粋にデータ中心の概念だが、本来のドメインモデリングの本質は、データ構造よりも振る舞い（Behavior）への集中にある
ドメインモデルのデータは振る舞いを可能にするために存在する役割であり、振る舞いそのものがコードの中心だ
データモデリングを観点によって多様に表現すること自体に複雑さはあるが、この違いはむしろ機能と見ることもできると思う
あらゆる状況で同じ複雑さや精密さが求められるわけではなく、表現モデルは読み取りシナリオに最適化するのが一般的だ
この方式を使うと、情報の文脈ごとの扱いより統一性に偏りやすく、ドメイン理解度の高い環境ではスケーラビリティが良いかもしれないが、実際には複雑または微妙なドメインモデルを単純化しないと、ほとんどのユースケースが難しくなるという経験がある
「こうした試みで5%以上、あるいは500万ドル以上の定量的なビジネス改善が見られた事例を見たことがあるか」という質問
データテーブルを統合しようとする試みを何度も経験したが、実際には異なる分析が必要ならテーブル統合には意味がなく、多様な分析は依然としてそれぞれ独立して行われていた
つまり、誰もが望む分析方法に合わせてベースレイヤーを統合しても、なお異なる分析は別々に進み続ける
それでも今回の試みは、すべてを1つに統合させるのではなく、幅広いアクセスのしやすさを高めようとしているようで賢明に見える
公式なビジネス概念の定義を皆で統一して混乱を減らそうという目的には深く共感する
たとえば、誰もがマスター prison リストを欲しがるとしても、prison が建物そのものなのか、収監者の集合（同じ敷地内にある男女別 prison が区別された独立体）なのか、特定の契約で運営される機関なのかは、定義によってまったく異なる
この意味で、組織の観点ごとに微妙に異なるオブジェクトが必要になる
ドメイン駆動設計（DDD）とどう関係するのか気になる
DDDでは、同じ概念であってもシステムごとに異なる表現を取りうることを前提にしているのではないかと思う
ただ、記事自体はUMLっぽさのせいで最後まで読まなかった
upper:DomainModel における Domain はDDDのD（ドメイン）と同じで、DGS（Domain Graph Service）も同様
DDDでは、同じ概念でもシステムごとに表現方式が異なることを同時に許容するが、UDAでは各ドメインにおいてこうした多様な概念が明示的に共存するよう設計している
「同じ」という概念が主観的になる
"ubiquitous language（共通言語）" という用語を使わなかったのは、むしろよかった
この概念は今回の試みと完全に逆の概念だ
関連する概念だけ聞いて深く見ていない人は、違いが分からないかもしれない
Netflix EngineeringがなぜMediumにコンテンツを載せるのか疑問
Mediumのポップアップなどで読者を簡単に失う状況なのに、そんなリスクを負う価値があるのか気になる
16進数のMedium URLを見るたびに、scribe.rip経由で読む楽しみがある
scribe.rip UDA記事
マーケティングチームがこれを運営しているなら、SEOまで含めた戦略である可能性が高い
Mediumがもたらす「発見」（discovery）効果は実際にある
そしてMediumに書くタイプのエンジニアは、Netflixがリクルートしたい人材層である可能性が高い
自前でブログを管理しなくていいので、さらに便利だ
データモデルのバージョン管理や破壊的変更にどう対応するのか気になる
モデルをもっと分離して運用する場合は、従来どおり断片単位で簡単に直せるが、このような統合モデルではどうするのか疑問だ
Netflix方式では、新しいモデルを追加した後、古いモデルを段階的に廃止していくのだろうと推測している
UDAではまだ完全には実装されていないが、Federated GraphQLと同じ方式を適用する予定だ
Federated GraphQLで実証済みのdeprecation管理モデルを導入する予定で、500以上のフェデレーテッドGraphQLスキーマをうまく管理した経験がある
核心は、projected models のコンシューマーを追跡しつつ、deprecated サイクルを能動的に管理するロードマップにある
統合グラフを成功させるには、ビジネス、コミュニケーション、技術の3つすべてを解決しなければならないと実感している
コミュニケーションの問題では、「自律的なチームのほのかな独立性」を壊す必要がある
各チームをまたぐ橋渡し役を務め、データモデルも分析しなければならない
単なるスキーマ共有だけでは不十分で、実際に人々へインタビューしながら合意していく過程がどうしても必要だ
技術的側面はむしろ最も簡単で、Microsoft Graphのように「厚いスキーマ」を強制適用すればシンプルだ
この過程にはかなりの共感力と忍耐が必要だ
技術的解決には、経営陣の確固たる意思決定と実行権限が不可欠で、チームごとに自由に動けるならどんなアイデアも役に立たない
ビジネス面が最上位の難易度だ
20年かけて最適化されたプロセスと用語を一度に変えるのは、実際ほとんど不可能に近い
結局、全社的なbuy-inが完全に得られて初めて、この途方もない仕事が「生涯を通じて」投資する価値を持つ
共通語彙の導入は非常に意義があると信じている
しかし、企業全体、新規買収、多様なビジネスプロセス、時間軸など、組織の広がりが大きくなるほど難しくなる
2つのシステムを接続するインターフェース程度ならすぐ作れるだろうが、1つのエンタープライズに複数のレイヤーが存在し、すべての知識をカタログへ収める理想的なDBを誰が作って継続的に維持できるのかは疑問だ
成功して残った試みの多くは、非常に抽象的に運用するか、特定のユースケースにだけ範囲を限定した方式だった
経験的に、企業全体のエンティティ（例: 会社の公式エンティティ）を定義しても、各部門ごとにこれを拡張する必要が生じ、新しい属性を全部門で使えるようにするのか、その部門だけで使うのかといった政治的・楽観的な判断が必要になる
公式エンティティを更新するなら、全体への影響を評価しながら厳密な変更管理が必要だ
正しくしっかり構築され、厳格な組織文化が支えれば、コストと摩擦は大きく減らせるし、Netflixなら可能性はありそうだ
生き残っている唯一無二の大規模共通語彙の例としてWikidataが挙げられている
16億5千万個のグラフノードが標準語彙のもとで継続的に拡張されている