Databricks上でZalandoがAIと分析のための統合データ基盤を構築した方法

欧州を代表するファッション・ライフスタイル分野のオンラインプラットフォームであるZalandoでは、欧州全域で5000万人以上のアクティブ顧客と7000以上のブランドおよびパートナーを結びつける、大規模なデジタルエコシステムを管理しています。顧客一人ひとりのインタラクション（閲覧、注文、返品など）は、パーソナライズされたレコメンデーションからロジスティクス最適化に至るまで、意思決定を推進するデータのパルスを生成します。

この規模での運用には特有の課題が伴います。当社のデータランドスケープは広大かつ複雑で、マイクロサービスアーキテクチャによって、テラバイト級のイベントが中央データレイクにストリーミングされています。このアーキテクチャにより急速なスケールアップが可能になりましたが、ガバナンスが困難になり、トランザクションデータ（日々の業務オペレーション）と分析データ（意思決定のためのインサイト）の区別が曖昧になりました。

長年にわたり、ドメインチーム（「決済」や「ロジスティクス」など）が独自のデータプロダクトを管理できるように、分散型アプローチでこれを解決しようと努めてきました。このセットアップでは、チームへの負荷を管理し、ビジネスリスクを防ぐために、中央集権的なガバナンス構造が不可欠です。さらに、真実を定義する統一されたレイヤーがないと、メトリックの乖離という課題に直面します。「なぜマーケティングダッシュボードの「純売上高」がファイナンスレポートと異なるのか？」といった問題です。メトリックがサイロ化されているため、ライフサイクル全体での再利用のために、それらを管理し、発見可能で信頼できるものにすることは困難です。

この記事では、ZalandoがDatabricks Platformの全機能を活用してこれをどのように実現しているかを共有します。トランザクションデータと分析データのギャップを埋める統一セマンティックレイヤーの構築方法を掘り下げます。具体的には、以下の点について説明します。

• 基盤：Unity Catalogがどのようにして数百のチームにわたるフェデレーテッドガバナンスとセキュアな共有を可能にするか。
• セマンティックレイヤー：Unity Catalog Business Semanticsが、Metric Viewsによって、ビジネスロジックを一度定義してどこでも利用できるようにするか。
• 会話型AI搭載分析：Genie（SQLの専門知識がなくても自然言語でデータをクエリできる生成AI搭載インターフェース）を通じてセマンティックレイヤーを活用し、より迅速なデータ駆動型の意思決定を支援する方法。

基盤 – Unity Catalogによるガバナンスの民主化

広大なデータランドスケープを効果的に管理するために、リソース中心のゲートキーピングから脱却することを決定しました。そのモデルでは、新しいデータセットやコンシューマーごとに、個別のIAMロール、S3バケットポリシー、例外処理が必要でした。しかし、課題を特定しました。権限は数千のリソースに分散され、レビューが煩雑で、ドリフトが発生しやすかったのです。そのため、アイデンティティベースのガバナンスアプローチに移行しました。アクセス決定は、人やグループに関連付けられた再利用可能なポリシーとして表現されます。これらはデータセット全体で一貫して評価され、中央で強制されます。これにより、アクセス運用、監査、チームやデータの変化への対応が容易になります。Databricks Unity Catalogを使用してこの基盤を構築し、その上にフェデレーテッドアクセス制御フレームワークを実装しました。

アーキテクチャ

アジリティをコントロールの犠牲にすることなく確保するため、データの作成と消費を厳密に分離するデュアルカタログパターンを設計しました。

• プライベートカタログによる自律性：各ドメインチームは、社内セルフサービスソリューションを使用して独自のプライベートカタログを作成します。このプライベート環境内で、チームは中央の承認を待つことなく、スキーマを作成し、生データをインジェストし、テーブルを自分のペースで構築できます。これは「ファクトリー」として機能し、無制限の開発とイテレーションに最適化されています。唯一の制限は、ここで作成されたすべてのオブジェクトは、そのチーム自身と、少数の関連貢献者のみがアクセスできることです。これは、これらのカタログ上に構築されたユースケースが、会社全体での使用を意図していないことを意味します。
• ガバナンスのためのセントラル共有カタログ：会社のさまざまなチームがこれらのデータセットを使用する必要があるユースケースのために、中央共有カタログを導入しました。これは、会社全体の「ショールーム」として機能します。組織全体で共有されるすべてのデータは、Dynamic Viewsを介してここで公開される必要があり、厳格な中央ガバナンス下に置かれます。データがここに配置されると、Unity Catalogを通じて即座に検出可能になります。

Dynamic Viewsを採用する理由：中央集権的な管理と監査可能性

共有カタログのデータは、直接のテーブルポインタではなく、Dynamic Viewsを通じてのみ公開するという戦略的な決定を下しました。このアプローチにより、複雑なコンプライアンスルールを処理できる中央集権的なアクセスプロセスを強制できます。

Dynamic Viewsをサービングレイヤーとして使用することで、以下のことを達成しました。

• GDPRのためのカスタムプロセスルール：is_account_group_member()のような関数を使用して、ビュー定義にカスタムロジックを直接注入します。これにより、ユーザーが独占禁止法の要件を満たし、機密データ（メールなど）へのアクセスを許可されているかを確認することで、堅牢なアクセス制御が保証されます。
• デフォルトで準拠した内部アクセス：自動化された分類プロセスにより、各列が分類されます。非機密列はすべて、デフォルトで幅広いユーザーがアクセスでき、データ民主化と意思決定を迅速化します。
• 完全な監査可能性：すべてのクロスチームアクセスがこれらの中央管理ビューを通過するため、アクセス決定の完全な監査証跡を維持します。どのポリシーがユーザーに特定の行または列へのアクセスを許可したかを正確に把握しています。
• 信頼性の高いインサイト：部分的な集計による不正確なデータまたは誤解を招く数値の生成を防ぐため、必要な特定の承認なしに機密列にアクセスしようとするクエリは、アクセス拒否エラーで明示的に失敗します。

ガバナンス・アズ・コード：共有ワークフロー

このプロセスを効率的に維持するために、GitOpsアプローチを使用して共有ワークフローを自動化しました。

1. 共有のためのプルリクエスト：チームがプライベートカタログから共有カタログにデータセットを共有する準備ができたとき、チケットを提出するのではなく、ソーステーブルを指す設定ファイルを含む中央リポジトリでプルリクエスト（PR）を開きます。
2. 承認ルール：プルリクエストは、共有基準、一意性、その他の重要な決定要因についてチェックされます。
3. 自動化された検証とプロビジョニング：PRが承認されマージされると、プラットフォームサービスは中央共有カタログにそれに対応するDynamic Viewを自動的に生成し、列を自動的に分類します。

このセットアップにより、分散チームのアジリティを維持しながら、データが容易に発見可能で、安全で、準拠した状態に保たれる、中央集権的で完全に監査可能なガバナンス標準を強制できます。

セマンティックレイヤー – 「真実」の定義とMetric Views

データアクセス用に確立したセキュアな基盤により、一貫したデータ解釈の確保に注力しています。

これまでデータスタック全体に断片化されていたビジネスロジックを積極的に中央集権化しています。

• BIツール：個々のダッシュボードに埋め込まれたメトリック定義
• SQLスクリプト：ノートブックやパイプライン全体で重複するロジック
• マテリアライズドテーブル：特定のユースケースに紐づいた事前計算メトリック

数千ものメトリック定義を、単一の管理されたレイヤーに統合しています。これにより、「ロジックロックイン」を打破できます。あるダッシュボードツールでの「総商品販売額」（NMV）の定義が、ノートブックで作業するデータサイエンティストや、ユーザーの質問に答えるAIボットから完全にアクセスできるようになります。

これを実現するために、Databricks Metric Views を統一されたセマンティックレイヤーとして採用しています。これにより、メトリクスの定義と消費が明確に分離され、ユーザーは SQL エディター、ダッシュボード、または AI エージェントを介してクエリを実行した場合でも、まったく同じ計算結果を得ることができます。実際には、これにより技術ユーザーと非技術ユーザーの両方が同じメトリクス定義を使用することが保証されます。

Metric as Code: メトリクスのライフサイクル

Unity Catalog でのデータ共有に GitOps を利用するのと同じように、セマンティックレイヤーには厳格な「Metric as Code」アプローチを実装しています。すべての KPI 定義を一元化および標準化することで、すべてのチーム間で一貫性を確保します。

私たちのアーキテクチャは、メトリクスのライフサイクル全体を管理します。

1. YAML での定義: メトリクスは、中央リポジトリに保存されたコード（YAML ファイル）で定義されます。これにより、集計ロジック（例: SUM(amount)）とテーブル、ファクト、メトリクスの間の関係だけでなく、所有権、説明、フォーマットなどの重要なメタデータもキャプチャされます。

2. 自動検証: メトリクスが本番環境にマージされる前に、CI/CD パイプラインで一連の自動チェックが実行されます。これには以下が含まれます。
   • 一意性: 同じ名前または定義のメトリクスが既に存在しないことを確認します。
   • 整合性: 検出可能性を確保するために、命名規則（例: snake_case）を強制します。
   • 所有権: 説明責任のために、有効なチーム ID がメトリクスに添付されていることを確認します。
3. 人間による確認: 4Eyes 原則 を通じて、各プルリクエストはドメインエキスパートによってレビューされます。
4. 個別の開発環境: チームが本番環境に非常に近い環境でテストしながら迅速にイテレーションできるように、各プルリクエストは Metric Views を個別のテスト環境にデプロイします。このセットアップにより、変更の影響をすぐに検証できます。

レイクハウスのためのスタースキーマの構築

内部的には、確立された次元モデリングの原則に依存しています。本番環境の各 Metric View は標準インターフェイスとして機能し、通常はファクトテーブルに 1 対 1 でマッピングされ、統合されたディメンションテーブルから属性を継承します。

このセットアップは、私たちのスケールにとって重要です。Metric Views が共有カタログ （セクション 1 より）の信頼できるデータの上に構築されていることを強制することにより、セマンティックレイヤーが基盤となるプラットフォームのすべてのセキュリティおよびコンプライアンスのメリットを継承することを保証します。メトリックビューをクエリするユーザーは、依然として、Unity Catalog レイヤーで定義したのと同じ行レベルおよび列レベルのセキュリティ、およびアクセスルールに従います。今年後半には、Metric Views を介した追加の承認レイヤーでこのセットアップを強化する予定です。これにより、ユーザーは生のデータアクセスを必要としなくなり、メトリクスとディメンションレベルのアクセスのみが必要になります。

結果: 相互運用性

このアーキテクチャの成果は相互運用性です。ビジネスロジックを独自の BI ツールからレイクハウスのセマンティックレイヤーに移行することで、将来に備えます。このレイヤーで一度定義されたメトリクスは、以下ですぐに利用可能になります。

• Databricks Dashboards 標準レポート用。
• Genie 自然言語を使用した会話型インターフェイスでの AI パワード分析用。
• 外部ツール およびアプリケーション 標準化されたコネクタ経由。

この一元化は、次の主要ステップである「ビジネスがデータと「会話」できるようにする」ための鍵となります。

会話型 AI パワード分析

ダッシュボードは、日常的で繰り返し発生する質問に答えるために不可欠です。しかし、ビジネスのスピードは、標準レポートですべてをキャプチャする能力をしばしば上回ります。たとえば、カテゴリーマネージャーは次のようなことを知る必要があるかもしれません。「ドイツで先週、クリック率が高かったが、販売数量トップ 10 には入らなかったスニーカーブランドはどれか？」 既存の標準レポートで対応されていない、このような新しい質問に答えるには、新しいダッシュボードの構築が必要になることがよくありました。セルフサービスツールを使用しても、依然として「インサイトまでの時間」の遅延が残っていました。ユーザーは、回答を得る前に、適切なデータセットを見つけ、ウィジェットを構成し、フィルターを適用する必要がありました。これはしばしば 1 回限りのダッシュボードにつながり、ダッシュボードのスプロール化と検出可能性の低下につながりました。

ユーザーエクスペリエンスを最適化するために、LLM パワードの会話型インターフェイス（しばしば AI チャットボットと呼ばれる）を提供するいくつかの「Talk-to-Data」ソリューションを評価しました。Genie は、統一されたセマンティックレイヤーに依存しているため、最もパフォーマンスが高かった一方、このレイヤーを持たないソリューションは、複雑なビジネスロジックに対して正確な SQL を生成するのに苦労しました。

だからこそ、Metric Views の導入が、Genie のような会話型 AI パワード分析に不可欠であることが証明されたのです。Genie を事前に確立された Metric Views（セクション 2 で詳述）に向けることで、重要なブレークスルーを達成しました。それは、管理されたビジネス定義に基づいた、一貫性のある信頼性の高い回答です。

Metric Views が AI の精度を劇的に向上させる理由

分析における AI 導入の最大の障壁は信頼です。LLM が SQL クエリを幻覚した場合、数値は間違っており、ユーザーは信頼を失います。

Genie は、Metric Views のセマンティックレイヤーと連携することでこれを解決します。

• 推測なし: ユーザーが「NMV」（Net Merchandise Value）を要求したとき、Genie は生のテーブルから計算しようとしません。それは「NMV」をメトリクスビューの管理されたメトリクスとして認識し、事前に定義されたロジックを単純にクエリします。したがって、メトリクスビューは SQL ステートメントの生成の複雑さを軽減し、精度を高めます。
• コンテキスト認識: 説明、同義語、サンプルクエリを追加して、Unity Catalog メタデータを強化するために多大な投資を行いました。Genie はこのコンテキストを使用して、ユーザーが「キャンセル」と言ったときに、それが私たちの内部定義と一致して、出荷前にキャンセルされた注文を特に意味することを理解します。

最前線を強化する

これまで Excel エクスポートや BI ツールに依存していたマーチャンダイザー、バイヤー、価格アナリストなどの非技術チームで Genie をテストしました。フィードバックは即座に得られました。ユーザーは、SQL を一行も知らなくても、カスタムレポートビューを作成する時間を費やすことなく、詳細な質問（例: 特定のデバイスタイプとペアになった特定の市場パフォーマンス）に対する迅速な回答を得ることができました。

新しい Agent Mode の導入は、ユーザーエクスペリエンスを大幅に向上させました。Agent Mode はデータを自動的に分析して分析結果の根本原因を特定するため、ユーザーは単に「なぜ」そうなったのかを尋ねることができます。Zalando では、これにより、重要な経営判断が行われる定期的なパフォーマンス会議の準備時間が数時間からわずか数分に短縮される可能性があります。

しかし、Genieはその広範な機能により、例えば集計されていないテーブルやビューに設定した場合など、正しく設定しないと高価になる可能性もあります。そのため、Genieが使用するデータとコンテキストを慎重にキュレーションすることが極めて重要です。さらに、完全なGenieバージョン管理の導入や、Databricksが既に開発中で部分的にサポートされているGenie構成のプログラムによる更新の有効化といった、さらなる機能強化の可能性を認識しています。エンタープライズ導入のためのGenieのスケーリング

Genieを単なるサンドボックス実験として扱うのではなく、エンタープライズ運用に統合しています。スケーリングのための重点分野は以下のとおりです。

• ガバナンスの確立: キュレーションされたGenieスペースは、ガバナンスされ適切に維持されたMetric Viewsによってサポートされます。
• データ信頼性の確保: データ所有チームと協力して、キュレーションされたGenieスペースを確立しています。これらのスペースは、データ所有者自身がデータ品質を維持することを保証するMetric Viewsを介して、データの分析表現を提供します。
• Agent Bricksとの統合またはDatabricks OneでのGenieの使用: これらのキュレーションされたGenieスペースは、Agent Bricksを使用するか、Databricks One内でGenieを使用することによってオーケストレーションする予定です。このアプローチにより、ユーザーはすべてのデータクエリに対して単一の統合されたエントリポイントを持つことができます。

Unity Catalogのガバナンス、Metric Viewsによるビジネスロジックの標準化、そしてGenieのインテリジェンスを組み合わせることで、「データに尋ねる」ことが同僚に尋ねるのと同じくらい簡単になるデータカルチャーを構築しています。

この投稿に貢献してくれたMerve Karali、Tobias Efinger、そしてRoberto Bruno Martinsに感謝します。

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