はじめに
2024年の6月10日から14日にかけて、Databricks最大のイベント「Databricks Data + AI Summit 2024」がサンフランシスコで開催されました。
いくつかのセッションはオンラインで配信されましたが、その中から製造業をピックアップして、現地13日に行われたadidas社の事例についての講演の内容をまとめました。
adidas社ではDatabricksを以前より導入していましたが、権限の管理などは複数サービスに分散されている状態で、データガバナンスが確立されていませんでした。
その状態からどのようにしてUnity Catalogを導入したのか、また導入したことでどのようなメリットが発生したのかについての講演が行われました。
データ活用の歩み
2021年以前のAdidasのデータジャーニーについて簡単に振り返りましょう。Adidasも他の大規模なデータ駆動型企業と同様にデータの課題があり、冗長なデータが一貫性のないデータインサイトを生み出していました。私たちは複数のデータプラットフォームを構築し、さまざまなビジネスニーズを満たすために何百万ユーロも投資しました。
AdidasのLakehouse採用の成長について見ていきましょう。現在、Adidasは5ペタバイトのデータを使用しており、この大規模なデータが分析および運用プロセスを支えています。レイクハウスプラットフォームには270以上のデータ製品がホストされており、1200以上のプロダクショングレードのデータパイプラインを監視しています。また、96の機械学習モデルを監視し、50以上のBI製品が世界中で使用されています。
Adidasのデータジャーニーは、2021年Databricksに移行し、すべてのデータとAIのユースケースを単一のプラットフォームに統一することから始まりました。しかし、データガバナンスは依然として分散化されており、主にAWS GlueとIAMロールに依存していました。2024年には、Unity Catalogが技術的に稼働しており、すべてのデータ活動の集中ガバナンスを提供しています。
従来アーキテクチャとUnity Catalogの違い
導入前のアーキテクチャ
Adidasでは、Unity Catalog導入前はAWS Glueをメタデータレイヤーとして使用していました。
データはS3に書き込まれ、テーブルレベルのメタデータはGlueに更新され、クエリ時にGlueからメタデータを取得していました。データセットへのアクセスポリシーはGlueではなく、S3バケットポリシーとIAMポリシーに基づいて定義されていました。
BIシステムやMLアーティファクトのアクセス制御は、それぞれのスタック（例えば、SageMakerやPower BI）で管理されていました。
標準的なワークフロー
ユーザーがAzure Active Directoryを使用してDatabricksにログインし、クエリやジョブを実行する際に、対応するインスタンスプロファイルがDatabricksクラスターにアタッチされてアクセス制御が実施されていました。
インスタンスプロファイルはクラスターにアタッチされ、どのユーザーがクエリを実行しているかは気にせず、クラスターがデータを読み書きする際にアクセス権限を確認していました。
以前のアーキテクチャでは、異なるデータ資産間でガバナンスが統一されておらず、行や列レベルのデータアクセスが欠けていました。
導入後のアーキテクチャ
Unity Catalogを導入することで、ガバナンスが統一され、ユーザーが行うすべてのアクションがUnity Catalogで定義されたアクセス制御リストに対してチェックされます。
アクセス制御はデータだけでなく、MLアーティファクト、BIダッシュボード、クエリ、ノートブックなど、あらゆるものに対して適用されます。
新しいワークフローの例
ユーザーがAzure Active Directoryを使用してログインし、ジョブを実行しようとすると、Unity Catalogがユーザーにそのジョブへのアクセス権限があるかを確認します。
ジョブ内で特定のテーブルやファイルにアクセスしようとすると、Unity Catalogがそのオブジェクトへのアクセス権限を確認します。
以前のアーキテクチャと比較して、システムではなくユーザーのアクセスをチェックするようになり、行や列レベルのアクセスも確認します。
ユーザーレベルでのACLの適用により、クラスターにインスタンスプロファイルをアタッチする必要がなくなりました。
すべての種類のユーザー（ビジネスユーザーや開発者など）がデータを利用できるように、アクセス制御が統一されました。
Unity Catalog導入の動機
データリネージ機能により、すべてのDatabricksワークスペースでリネージが自動的に追跡され、外部パートナーツール（例：Colibra）での表示が可能になります。
高度な検索機能により、テーブルやタグベースの検索ができ、セキュリティモデルに自動的に準拠します。
AIベースの監視機能がモデル開発プロセスのすべてのステップをカバーし、監査機能がレイクハウスオペレーションチームに役立ちます。
Delta Sharing機能により、外部パートナー（例：Zalando、Dichman、Foot Lockerなど）へのデータ共有が容易で強力になります。
Unity Catalogへの移行
インベントリ化
最初のフェーズはインベントリ化であり、Adidasのデータプラットフォームの資産を完全に把握することが重要でした。
データプラットフォームのさまざまな資産についての完全な概要を持つことができる人やチームは存在しないため、すべてのシナリオを評価し計画する必要がありました。
管理テーブルの数やDBFSルートの外部テーブルの数を把握し、アップグレードが必要かどうかを確認しました。
Adidasの場合、これらのテーブルが不要であると分かり、多大な労力を節約できました。これはインベントリ化フェーズのおかげです。
グローバルinitスクリプトの数を把握し、クラスター範囲のinitスクリプトに変換する計画を立てました。使用されるデータフォーマット（Parquet、JSON、CSVなど）を把握しました。
テーブル、ビュー、関数、ジョブ、ストレージロケーションなどの各種メトリクスを理解し、アップグレードに必要な労力とタイムラインを定量化しました。
全体の評価を行うために、Databricks Labs UCXというオープンソースツールを使用しました。
UCXはUnity Catalogへのアップグレードの各フェーズで使用できる包括的なツールです。
計画
インベントリ化と評価の結果に基づき、各シナリオを詳細に分析し、アップグレードプロセスの各ステージをマッピングし、ロールバックプランも策定しました。
データ製品ごとにフェーズアップグレードを行い、各データ製品がUnity Catalogにアップグレードするタイミングを自律的に決定できるようにしました。
アップグレード計画の概要を示し、各ステップの詳細を定義しました。
個々のデータ製品チームの関与を最小限に抑え、準備が整った段階で自動化と集中化された変更を使用して移行できるようにしました。
変更を行うための労力と必要なチームを明確に理解し、ステークホルダーのコミュニケーションを行いました。早期のコミュニケーションとステークホルダーの合意が重要でした。
データ構造設計
Unity Catalog実装の最初のステップの1つは、データがUnity Catalog内でどのように構造化されるかを決定することです。従来の2レベルのネームスペース設計(schema.table)から、カタログ、スキーマ、テーブルビューまたはボリュームの3レベルのネームスペース設計(catalog.schema.table)に移行しました。この変更により、データランドスケープの構造が改善され、異なる環境、組織構造、およびデータ製品の間で明確な分離が可能になりました。ただし、この変更にはコード変更が必要でした。
Adidasでは既に明確な構造があり、各開発環境ごとに異なるGlueカタログを使用していました。この構造をUnity Catalogでも採用しました。
デフォルトカタログの設定によりコードの変更を完全に回避し、2レベルの表記法を引き続き使用しました。
変更の集中化
統合やアップグレードを迅速化するためには、自動化とタッチポイントの削減が重要です。これにはインフラストラクチャの変更とアプリケーションの変更が含まれます。
これらの変更を事前に準備し、既存のワークロードやユーザーに影響を与えないようにしました。変更は段階的に展開され、データ製品チームがアップグレードの準備ができたときに使用できるようにしました。
中央機能には、インフラストラクチャの変更と自動化スクリプトが含まれます。グループマイグレーション中にダウンタイムをゼロにし、アカウントグループの事前作成、ユーザーの事前同期、UCXを使用して権限を移行しました。
Unity CatalogとGlueの共存期間中、最新データへのアクセスを維持するために双方向同期メカニズムを実装しました。
クラスター構成の必要な変更（アクセスモードの調整、インスタンスプロファイルの制限など）を行い、これらをクラスターポリシーに組み込むことで、データ製品チームが各設定を個別に更新する必要をなくしました。
データ移動の最小化
データ移動の最小化に焦点を当て、データのリライトを防ぎました。管理テーブルを外部テーブルに変換することでデータ移動を回避し、各データ製品チームが独自のタイムラインでアップグレードできるようにしました。
各データ製品チームの準備ができたら、ガイドラインに従って変更を行い、クラスター政策を適用し、コードをUC互換に適応させました。
全てのデータ製品がアップグレードされた後、Glueのアクセス権限を削除し、誤ってアクセスすることを防ぎました。
Unity Catalogを採用するメリット
各種ペルソナに対するユースケースを紹介。
データエンジニア
- Unity Catalogは、さまざまなデータリソースに対するユーザーアクセスを簡素化し統一しています。
- データエンジニアは、パートナーとリアルタイムで最新のデータを共有できるようになり、データの複製や冗長性がなくなり、一貫性が保たれます。
- データオペレーションチームには、詳細な監視と監査ログを提供し、内部および外部のポリシーに従うことを支援します。
- セキュリティと効率性が向上し、データ管理と運用がスケールで強化されました。
BIユーザー
- Unity Catalogは、BIユーザーにとって重要なレポート実行時間を改善し、パフォーマンスの向上をもたらします。
- クエリリスティングが高速化され、生産性が向上しました。
- 行レベルおよび列レベルのセキュリティポリシーをテーブルやビューにシームレスに適用でき、敏感なデータを保護しながら効率的なデータ探索が可能になります。
データディスカバリーユーザー
- Unity Catalogはメタデータの探索を容易にし、レポート、テーブル、列、モデルを簡単に発見できるようにします。
- データの出所から消費までのリネージを提供し、完全な透明性と信頼性を確保します。
データアナリスト
- Unity Catalogは、データアナリストがデータのコンテキスト、リネージ、関連性を理解することで、分析を迅速に開始し、スマートかつ効率的に作業できるようにします。
- 人気のある資産を特定するためのインサイトタブを提供し、データの豊富さを容易に確認できます。
- データドメインの専門家を特定し、シームレスなコラボレーションを促進します。
データサイエンティスト/MLエンジニア
- 複雑なコンピュータビジョンプロジェクトを実行するエンジニアにとって、Unity Catalogのボリューム機能は非常に革新的です。
- 非表形式データソースとのシームレスなインタラクションを可能にし、トレーニングパフォーマンスを向上させます。
- リアルタイムのアナリティクスやモデルの監視、AIベースの監視ソリューションを提供し、モデルの動作とパフォーマンスの透明性を提供します。
Adidasのデータリーダーの洞察
最後に、AdidasのデータリーダーからUnity Catalogの重要性についての洞察を共有します。
- データプラットフォームのシニアディレクターであるStefan Bassは、Unity CatalogがAdidasにとってのゲームチェンジャーであると強調しています。
Unity Catalogは数百の製品と数千のユーザーにわたるレイクハウスの利用に関する見えない洞察を明らかにし、プラットフォームの価値を深め、コスト最適化を可能にし、すべてのデータおよびAIアーティファクトの透明なガバナンスを確保でき、単なるデータ管理ツールではなく、将来の可能性を解き放つためのものと考えています。 - レイクハウスアーキテクチャのディレクターであるDmitry Litnickは、Unity Catalogがデータアクセスアーキテクチャを大幅に簡素化し、すべてのレイクハウスユーザーに一貫したエクスペリエンスを提供すると予想しています。
- データエンジニアリングストリームを率いるCarlos Costaは、Unity Catalogが安全でスムーズなデータアクセスを提供するための重要な要素であり、Adidasのすべてのデータ市民がデータリソースにシームレスにアクセスできるようにするものと考えています。
- AIおよびBIエンジニアリングのディレクターであるPhilip Keysは、Unity Catalogがデータリネージを自動化および強化し、データの発見を容易にし、共有を簡素化する方法を評価しています。これは、AdidasのすべてのデータおよびAIイニシアチブをスケールアップするために不可欠です。
まとめ
Adidasのデータプラットフォームは、Unity Catalogを使用することで、データの一貫性とガバナンスを確保し、データユーザーが効果的にデータを活用できるようになりました。Unity Catalogは、AdidasのデータとAIの民主化ビジョンを実現するための次の大きな転換点となるでしょう。
Databricks Champion からのコメント
Unity Catalog はかなり機能が充実してきましたね。特に、ABAC（属性ベースアクセスコントール）の導入が発表され、GUIベースでルールを作成することでデータマスキングを容易に実装できるようになりました。Unity Catalog をスケールしていくうえでかなり大きなアップデートだと感じております！