How to Structure Unity Catalog Like a Pro: Real-Wo... - Databricks Community - 120125の翻訳です。
本書は著者が手動で翻訳したものであり内容の正確性を保証するものではありません。正確な内容に関しては原文を参照ください。
Unity Catalogに移行する数多くの組織と取り組みを行った後、私は同じパターンが繰り返されるのを何度も見ました: チームは良い意図からスタートしますが、誰もナビゲートできない絡まり合ったカタログ、スキーマ、テーブルに陥ってしまいます。あなたが一貫性のない命名規則でプロダクションデータを散在させるまでは、3レベルの名前空間(カタログ.スキーマ.テーブル)はシンプルなものに見えるものです。
ここでは、プロダクション環境で実際に立証されたデザインパターンを共有させてください。
基礎: Unity Catalogの階層の理解
Unity Catalogは厳密な3レベルの階層構造に従います: メタストア → カタログ → スキーマ → テーブル/ビュー/ボリュームです。膨大なライブラリを整理するようなものだと考えてください - あなたは明確なセクション(カタログ)、整理された本棚(スキーマ)、適切にラベル付けされた本(テーブル)を必要とします。
多くのチームが見逃してしまう主要な洞察: データ分離の主要な単位がカタログであるということです[出典]。他のすべてはこの意思決定に従います。
パターン 1: 環境ベースのカタログ設計
ゴールドスタンダードアプローチ
私が見た多くの成功したパターンは環境ベースのカタログです[出典1、出典2]。なぜこれがうまくいくのかを説明します:
-- 開発環境
dev_analytics.bronze_sales.raw_transactions
dev_analytics.silver_sales.cleaned_transactions
dev_analytics.gold_sales.daily_revenue
-- プロダクション環境
prod_analytics.bronze_sales.raw_transactions
prod_analytics.silver_sales.cleaned_transactions
prod_analytics.gold_sales.daily_revenue
なぜ環境ベースのカタログがうまくいくのか
- 物理的分離: それぞれの環境には個別のストレージロケーションを割り当てることができます
- セキュリティ境界: プロダクションデータは決して誤って開発環境にリークすることがありません
- 明確なプロモーションパス: コードは予測可能な形で dev → staging → prod を遷移します
- コンプライアンスフレンドリー: 監査官は明確な環境分離を好みます
ストレージ分離の例
-- HRのプロダクションデータは特定のバケットに存在すべきです
CREATE CATALOG hr_prod
MANAGED LOCATION 's3://mycompany-hr-prod/hr_bucket';
-- 開発では共通ストレージを共有可能
CREATE CATALOG dev_shared
MANAGED LOCATION 's3://mycompany-dev/hr_bucket';
パターン 2: ハイブリッドスキーマ構成
プロデューサーベースのブロンズ/シルバー + プロダクトベースのゴールド
私が実装した最もエレガントなスキーマデザインではハイブリッドアプローチを採用しています:
ブロンズ & シルバースキーマ: ソースシステムドリブン
prod_analytics.bronze_salesforce.accounts
prod_analytics.bronze_salesforce.opportunities
prod_analytics.silver_salesforce.cleaned_accounts
prod_analytics.bronze_stripe.payments
prod_analytics.silver_stripe.processed_payments
ゴールドスキーマ: ビジネスドメインドリブン
prod_analytics.bronze_salesforce.accounts
prod_analytics.bronze_salesforce.opportunities
prod_analytics.silver_salesforce.cleaned_accounts
prod_analytics.bronze_stripe.payments
prod_analytics.silver_stripe.processed_payments
このパターンはデータリネージ問題を解決します - ビジネスニーズごとのコンサンプションレイヤーを構成しつつも、データの由来を容易にトレースすることができます。
パターン 3: メダリオンアーキテクチャインテグレーション
テーブルレベルのメダリオンプレフィクス
ブロンズ/シルバー/ゴールドごとの個別のカタログの代わりに、スキーマ内でのテーブルプレフィクスを使用します:
prod_analytics.bronze_salesforce.accounts
prod_analytics.bronze_salesforce.opportunities
prod_analytics.silver_salesforce.cleaned_accounts
prod_analytics.bronze_stripe.payments
prod_analytics.silver_stripe.processed_payments
命名規則のメリット
-
認識のしやすさ:
brz_*,slv_*,gld_*プレフィクスは即座に認識できます - スキーマの凝集度: 関連するテーブルは同じグループにとどまります
パターン 4: ドメイン駆動のデータアーキテクチャ
複雑なビジネスドメインが存在する場合
大規模組織では、ドメイン駆動のカタログ設計を検討しましょう:
-- 金融サービスの例
prod_lending.applications.brz_loan_requests
prod_lending.underwriting.gld_risk_scores
prod_deposits.accounts.brz_account_openings
prod_deposits.transactions.gld_daily_balances
prod_compliance.kyc.slv_customer_verification
prod_compliance.reporting.gld_regulatory_reports
以下のケースでこのパターンはうまく動作します:
- 様々なビジネスユニットで固有のデータガバナンス要件が存在する
- 規制の要件がドメイン分離を必要とする
- チームは最小限のデータ共有で独立で運用する
避けるべきアンチパターン
カタログ爆発
すべてのプロジェクトに対して個別のカタログを作らないようにしましょう。
単一スキーマの罠
単一のスキーマに全てのテーブルを格納すると、発見可能性とアクセス制御の粒度を損なうことになります。
一貫性のない命名によるカオス
bronze_sales, sales_silver, gold-marketingの命名規則を混在させると、認知のオーバーヘッドを引き起こします。
現実世界の実装戦略
フェーズ 1: シンプルにスタートしましょう
-- 環境分離から始めましょう
CREATE CATALOG dev_lakehouse;
CREATE CATALOG prod_lakehouse;
-- 基本的なメダリオンスキーマの追加
CREATE SCHEMA dev_lakehouse.bronze_raw;
CREATE SCHEMA dev_lakehouse.silver_curated;
CREATE SCHEMA dev_lakehouse.gold_analytics;
フェーズ 2: ドメイン分離を追加しましょう
-- ドメイン固有スキーマへの進化
CREATE SCHEMA prod_lakehouse.bronze_salesforce;
CREATE SCHEMA prod_lakehouse.bronze_stripe;
CREATE SCHEMA prod_lakehouse.gold_finance;
CREATE SCHEMA prod_lakehouse.gold_marketing;
フェーズ 3: スケールに応じて最適化しましょう
- ストレージ分離の実装
- コンプライアンス要件に対してワークスペースバインディングを追加
- Unity Catalogの使用を強制するコンピュートポリシーの作成
結論
ベストなUnity Catalog階層設計は、あなたの組織の成熟度、コンプライアンス要件、チーム構成に依存します。環境ベースのカタログからスタートし、スケールするに従って、ハイブリッドスキーマ構成を活用し、ドメイン駆動のパターンに向けて進化しましょう。
覚えておいてください: あなたのカタログ構造はあなたのデータガバナンス戦略を可視化します。 正しく行うことで、あなたのチームのみんなは感謝することでしょう。間違って行ってしまうと、6ヶ月を費やしてリファクタリングすることになります。
あなたの最大のUnity Catalog構成の課題はなんですか？ 以下にコメントしてください - あなたたちの環境でどのようにデータ階層に取り組んでるのをお聞かせいただければ幸いです。