Databricksの業界データモデルでデータモデリングを迅速に開始しましょう

業界データモデルの課題

過去30年間にわたり、規制が厳しくデータ量の多い業界は、同じ近道を提案されてきました。それは「業界データモデルの購入」です。保険業界向けの ACORD、ヘルスケア業界向けの FHIR や HL7、小売業界向けの ARTS などがその例です。標準化団体やベンダーが公開する、数百から時には数千ものテーブルが、1つのライセンスで1年分の作業を削減できるとアピールされてきました。

このアピールは魅力的ですが、現実はもっと困難です。業界データモデルは、その業界におけるすべての企業の「平均値」にすぎません。自社の製品ライン、地理的条件、規制への対応状況、レガシーな制約、命名規則、組織の形態などは考慮されておらず、自社のビジネスを他社と差別化する要素が何であるかも認識していません。その結果、開発チームは、データを入力することのない何百ものテーブル、自社の用語と一致しない命名規則、ワークロードに不要なリレーションシップの方向性を引き継ぐことになります。テンプレートを購入する価値の大部分は、不要な部分の削除、名前の変更、接続の再構築に費やされてしまいます。これらはまさに、テンプレートによって削減されるはずだった作業そのものです。

本番環境の分析や ML を実際に動かすような、堅牢な分析データモデルの構築には、歴史的に数か月から数年の歳月がかかっていました。

私たちは、これとは異なるアプローチを公開します。世界の主要な40業界を対象とした、構築済みのレイクハウス業界データモデルのライブラリです。現在パブリックリポジトリで公開されており、Databricks の Silver レイヤーとしてすぐにデプロイできます。各業界データモデルは2つのスコープで提供され、14のモデリングドメインにわたる200以上の厳格な構造ルールに基づいて構築されているため、初日から本番環境レベルの品質を実現できます。さらに、これらは硬直した固定的なデータモデルではないため、必要に応じて組織に合わせて拡張やカスタマイズが可能です。

レイクハウスにおけるこれらのデータモデルの位置づけ

Databricks のメダリオンアーキテクチャにおいて、Bronze は生データを保持し、Silver はすべての分析担当者、BI ツール、データサイエンティストが読み取る適合済みの分析ベースモデルを保持し、Gold は派生メトリクス、KPI、集計データを保持します。

これらのベースデータモデルこそが Silver レイヤー です。Lakeflow と Auto Loader がデータの取り込みを処理します。各モデルには、churn_score や monthly_revenue_summary などの事前計算されたメトリクスが付属しています。ベースモデルは分析の基盤であり、ビジネスの概念を信頼できるテーブルに変換し、BI ツール、特徴量パイプライン、下流の集計ですぐに利用できるようにする場所です。

Bronze、Silver、Gold

2つのスコープ：MVM と ECM

すべてのベースモデルは2つのスコープで公開されます。どちらも同じ論理的な model.json からデプロイされ、同じルールに従い、テーブルあたりの属性の深さも同じです。違いは「幅（網羅範囲）」にあります。

Minimum Viable Model（MVM）。ECM のテーブル数の30〜50%に相当します。必須のビジネス機能のみを含みます。SMB、迅速なデプロイ、概念実証（PoC）、MVP に最適です。MVM は単なる骨組みやデモ用の玩具ではありません。すべてのテーブルは、対応する ECM と同等の豊かな属性を備えています。軽量化は、ドメイン数とテーブル数を減らすことによって実現されており、テーブルの内容を薄くしているわけではありません。

Expanded Coverage Model（ECM）。完全なカバレッジを提供します。コーポレートバックオフィスを含むすべての部門を網羅します。Fortune 100 企業向けのモデルに求められるすべてのドメインをカバーしています。最大限の幅（網羅範囲）を備えています。

MVM と ECM のスコープの比較

なぜ両方のスコープが重要なのでしょうか。その目的は、組織がモデルを自社のビジネスデータに適合させるために時間を費やすことではなく、レイクハウスでの分析を迅速に開始することにあります。そのため、適切なスコープから開始すること自体が時間の節約になります。

これら2つのスコープは、個別にメンテナンスされるわけではありません。1つの変換処理によって、一方から他方を派生させることができます。shrink ecm を実行すると、コア製品を保護し、必須の外部キーを維持した MVM サブセットが生成されます。enlarge mvm はその逆を行います。バージョンが上書きされることはありません。どちらの操作でも、元のバージョンのほかに、新しい番号のバージョンが作成されます。

これらのモデルがユニークである理由

私たちが公開するベースモデルは、委員会規格の業界テンプレートの名前を変更しただけのものではありません。これらは、すべてのモデリングステップで構造的な品質を強制する、規律あるルール駆動型の AI エージェントによって生成されています。主な特徴は以下の通りです。

業界に応じた階層的なサイジング。すべてのモデルは、各セクターの実際の複雑さに合わせてサイズ調整されています。分類器は、規制の密度、関係者の複雑さ、製品階層の深さ、インフラストラクチャ管理、業界標準モデル、トランザクションの複雑さ、運用システム環境という7つの次元を使用して、各業界を5つの階層（ティア）のいずれかに分類します。これにより、ドメイン数、ドメインあたりの製品数、および属性の深さが決定されます。

業界特有の専門用語。各モデルは、そのセクターで実際に使われている用語を使用します。電気通信業界では MSISDN、ARPU、IMSI、CDR が、鉱業では ROM、cut_off_grade、JORC が、ヘルスケア業界では ICD、CPT、DRG が、銀行業界では IBAN が使用されます。これらは後から付け足したものではなく、列名、主キーの規則、ガバナンスタグの構造を決定づけるものです。

3部門の足場（スキャフォールディング）。すべてのモデルは、3つの同心円状のリングに整理されています。

• Operations（運用）は、ネットワーク、フリート、プラント、インフラストラクチャなど、ビジネスが物理的に行う活動です。
• Business（ビジネス）は、顧客、請求、製品、販売など、誰にサービスを提供し、どのように収益を上げるかを示します。
• Corporate（コーポレート）は、人事（HR）、財務、コンプライアンスなどのサポート体制です。

この比率はルール（ルール G06-R001）によって強制されます。Operations と Business が全ドメインの少なくとも80%を占める必要があり、Corporate は最大20%に制限されます。これにより、制約のないモデリングで最もよく見られる失敗パターン（モデルの半分が HR、財務、法務で占められ、ビジネスを実際に動かす運用の核心部分が手薄になること）を防ぎます。

3つの部門

6段階の階層構造。すべてのモデルは、Organization（組織）→ Division（部門）→ Domain（ドメイン）→ Subdomain（サブドメイン）→ Product（製品）→ Attribute（属性）という同じ厳格な形状に従います。この階層は単なる推奨事項ではなく、構造ルール、2段階のアーキテクトレビュー、および各パイプラインの最後に行われる静的解析によって強制されます。

4段階の階層構造

200以上の強制可能なルール。すべてのベースモデルは、命名規則、セマンティック重複排除、外部キー、主キー、正規化、ドメイン構造、データ型、分類タグ、リレーションシップ/DAG 強制、品質、製品設計、バイブ制約、物理スキーマデプロイ、サブドメインサイジングなど、14以上のグループに分類された200以上のルールに照らし合わせて検証されます。すべてのテーブルに主キーが必要です。すべての外部キーは実際のターゲットを指している必要があります。すべてのドメインは、組織図テスト（「この名前の実在する部門/チームが組織内に存在し得るか？」）に合格する必要があります。循環参照はなく、サイロ化も排除され、厳格な Single Source Of Truth（SSOT）が遵守されます。

1つの論理モデル、3つの物理レイアウト。各ベースモデルは、環境に依存しない単一の model.json として提供されます。同じ論理モデルを、1つのカタログ（単一のガバナンス境界）、部門ごとのカタログ（Operations / Business / Corporate を分離）、またはドメインごとのカタログ（データメッシュに対応）という3つのカタログスタイルで Unity Catalog にきれいにデプロイできます。別のスタイルに再デプロイしても、論理モデルには一切影響しません。

具体的な例：航空業界向け ECM モデル v1

具体的には、現在リポジトリで提供されている航空業界向けの ECM は以下の通りです。

グラフとして視覚化すると、完全な DAG は次のようになります（各長方形はドメイン、小さな円はテーブル、各線は FK リンクを表します）：

接続された DAG としての Airline ECM v1

19のドメインは、3つの部門にすっきりと分類されます。Operations（運行）には、airport、crew、fleet、flight、inventory、maintenance、routeが含まれます。Business（ビジネス）には、ancillary、cargo、loyalty、passenger、reservation、revenue、service、ticketが含まれます。Corporate（コーポレート）には、compliance、finance、safety、workforceが含まれます。

部門別の Airline ドメイン

単一のドメイン（flight operations）をドリルダウンすると、実務レベルで構造が分かりやすくなります。resource loading、flight operations、passenger services のサブドメインには、運行アナリストが実際に利用するデータ製品（leg、flight_plan、oooi_event、atc_clearance、dispatch_release、notam_brief、tech_log、weight_balance、fuel_uplift、pax_segment）が保持されています。（各円はテーブル、各線は FK 関係を表します）

Flight ドメイン

さらに、cargo ドメイン内の単一のデータ製品である Air Waybill（awb）までドリルダウンすると、クロスドメインのリンクがどのように機能するかが正確にわかります。awb は、passenger ドメインの corporate_account、airport の station、flight の leg、finance の profit_center、ledger_account、company_code、そして compliance の screening_result に接続されています。これらは貨物収益アナリストが毎日実行する結合（join）であり、クロスドメイン DAG がこれらをサポートするように構築されているために存在しています。

Air Waybill データ製品

デプロイ時に提供されるもの

すべてのベースモデルには、完全なアーティファクトセットが付属しています。

論理アーティファクト。単一の model.json（主要な交換フォーマット）、人間が読める形式の readme.md、ドメイン、製品、属性のフラットエクスポート、Excel および CSV エクスポート、SQL DDL ファイル（ドメインごとに1つ、およびクロスドメインの FK ファイル）、DBML スキーマ図、および RDF/Turtle オントロジー。

Unity Catalog にデプロイする際の物理アーティファクト。Unity Catalog スキーマ（カタログ作成スタイルに応じて、ドメインごとまたはサブドメインごとに1つ）、すべての製品の Delta テーブル、依存関係の順序で適用された外部キー（FK）制約、Unity Catalog 分類タグ（PII、restricted、public）、再利用可能な KPI 定義のための Databricks メトリックビュー、および、すぐに探索を開始できる、有効な FK 参照を含む合成サンプルデータ。

model.json ファイルは共通の基本単位です。git にコミットし、2つのバージョンの差分（diff）を確認し、環境間で共有できます。本番環境へのアクセス権を付与することなく、セキュリティレビュー担当者に渡すことができます。3つの異なるカタログ作成スタイルの下で dev、staging、prod に再デプロイすれば、論理的なコンテンツがバイト単位で同一である3つの環境を構築できます。

このアプローチの強み

• スピード。以前は数か月かかっていた Silver レイヤーの基盤構築が、今ではデプロイの1ステップで完了します。
• 業界特化。モデルは、そのセクターの言語（業界用語、規制の形態、運用の実態など）を使用します。
• ルール適用範囲。200以上の強制可能なルールにより、手動で作成されたほとんどのモデルでは到達できない一貫性を実現します。
• ガバナンス。機密データを含むすべての列が分類され、タグ付けされます。すべての PK/FK は単一の規則に従います。すべてのカタログ作成スタイルは再現可能です。
• 多面性。同一のアーティファクトが、リレーショナルスキーマ、DBML 図、ナレッジグラフオントロジー、および物理的な Unity Catalog デプロイメントとして機能します。
• 論理と物理の分離。1つの model.json、3つのカタログ作成スタイル。手戻りゼロで再デプロイが可能です。

考慮すべき事項

ベースモデルは出発点であり、完成した成果物ではありません。ドメインに関する専門知識は依然として重要です。専門家によるレビューは、そのビジネスの内部で働く実務者にしか見えない方法で、常にモデルを改善します。非常にニッチなサブバーティカル（特定分野）は、主要な業界ほど、そのままの状態で最適化されているわけではありません。また、厳格なデータモデル承認委員会を持つ組織では、依然として出力をレビューに通す必要があります。変わるのはアーティファクト作成のスピードであり、ガバナンスの要件そのものではありません。

このトレードオフは適切であると考えています。数時間でデプロイでき、構造的に堅牢なベースモデルは、適応させるのに1年かかるテンプレートよりも優れた出発点となります。

今すぐお試しください

40のレイクハウス業界データモデルのリポジトリは、https://github.com/databricks-industry-solutions/databricks-industry-data-models にあります。各業界には、MVM と ECM の両方が付属しています。組織に適したスコープを選択し、Unity Catalog に指定するだけで、デプロイ、分類、FK 検証が完了した、分析可能な Silver レイヤーが用意されます。

次回の内容

ベースモデルは出発点にすぎません。そのため、すべてのモデルは v1 から始まり、それが最終的な形ではありません。どのような組織にも、優れた汎用モデルであっても完全には捉えきれない、独自の用語、部門、ビジネスプロセスが存在します。次回の記事では、自然言語 AI モデリングエージェントを使用して v1 モデルをカスタマイズおよび進化させる方法を説明します。元の構造的な厳密さを維持しながら、希望する変更をプレーンな英語で記述し、カスタマイズされたバージョン（v2、v3 など）を作成する方法をご紹介します。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事