Understanding Unity Catalog in Databricks: Simplifying Data Governanceの翻訳です。
本書は著者が手動で翻訳したものであり内容の正確性を保証するものではありません。正確な内容に関しては原文を参照ください。
私がDatabricksにjoinして以来の数多くのエンゲージメントを通じて、お客様が多くの場合ににおいてUnity Catalogのスコープと混戦プトの理解に苦慮していることを知りました。「私のデータを格納しますか？」、「安全ですか？」、「複数のUnity Catalogを持つことはできますか？」、「何か壊したりしませんか？」といった質問は、私が望む以上に共通していました。我々は万能のソリューションとしてUnity Catalogを提供しており、そしてこれは真実です。しかし、そのスコープと機能のため、使い始める際には恐れを感じることがあります。
レガシーなアーキテクチャから移行してくるお客様にとって、このシフトは彼らの頭の中において物事がどのように動くのかに対する理解を変化させ、自身のデータを管理する全く新たな手段を導入することになるので、非常に重要なものとなります。
私は、「how(どのように)」に踏み込む前に「why(なぜ)」を理解することが常に重要であることを知っているので、Unity Catalogが何者であるのか(そして何者でないのか)をブレークダウンすることに自分のベストを尽くすことにします。
ちょっとした歴史の授業
当初、hive_metastoreはデータオブジェクトの管理や効率的なクエリーを実現するためのメタデータリポジトリとして、HadoopとHiveエコシステムから発生しました。これはDatabricksプラットフォームのデフォルトのメタデータリポジトリになり、それぞれのワークスペースにおけるデータオブジェクトと権限を管理していました。このアプローチは、初期のHadoopベースのアーキテクチャのニーズには適していましたが、現在のクラウドネイティブ、複数ワークスペースの環境においては制限が出てきました。
Databricksにおける実装として、hive_metastoreはメタデータと権限を管理するためのワークスペースレベルの構成要素として設計されました。多くの場合、この環境はうまく動作しましたが、例えば100のワークスペースで単一のデータソースを共有しようとすると、それらのワークスペースにおいて100の個別の権限セットを管理することになってしまいます。(100個の鍵で一つのドアを開けようとしていることを想像してみましょう。間違いなく楽しくも効率的でもありません！)いくつかのお客様は柔軟性を高めるために外部のhive_metastoreに切り替えましたが、集中管理されたガバナンスの欠如によって、Databricks内での権限管理をスケールさせることは困難となっていました。
そして、そこには2レベルの名前空間の制約による問題が存在していました。この環境は、大規模な権限管理を必要以上の頭痛の種にしていました。イメージしてみましょう: 100のテーブルを抱えるスキーマ(データベース)、テーブルのそれぞれが異なるユースケースをサポートしています。あなたの選択肢はどのようなものがあるでしょうか？スキーマ全体にアクセス権を付与し、そのテーブル全てを公開するか、注意深く一つ一つのテーブルにアクセス権を割り当てるか。間違いなくスケールする成功に繋がるレシピではありません。
hive_metastoreのデフォルトストレージロケーションであるdbfsでは特に、背後のストレージに対するアクセス管理自体が課題となります。外部のオブジェクトストレージへのアクセスは、ユーザーレベルではなくクラスターレベルで操作されるインスタンスプロファイルを通じて取り扱われます。これは、特定のクラスターにおける全てのユーザーが個人のニーズに関係なく同じアクセス権を共有することを意味していました。ユーザー固有の権限なしには、正確なセキュリティ制御の強制は困難であり、きめ細かいデータガバナンスで求められる柔軟性を欠いた環境になっていました。
そして、hive_metastoreは別の観点でも時代遅れとなっていたことを忘れないでください。データリネージ、アクセスパターン、データ検索のようなキーとなる機能が欠けていました。現在のデータドリブンの環境において期待される集中管理のガバナンスソリューションで重要となる機能です。
ここで、Unity Catalogの出番です。その前任者とは異なり、Unity Catalogはアカウントレベルの構成要素であり、複数のワークスペースでメタデータと権限を共有することができます。このシフトによって、データ管理をより円滑、効率的にすることで、大規模なガバナンスの集中管理を実現します。
まとめると、hive_metastoreはかつてはスポットライトを浴びていましたが、Unity Catalogは大きな一歩を踏み出し、モダンなデータ環境が必要とする柔軟性、セキュリティ、スケーラビリティを提供するということになります。
メタストア
はい、ここまでで背景をカバーしたので、Unity Catalogを起動して稼働させるための部品に踏み込みましょう。「UCの有効化」について誰かが話しているのを聞いて、どうしたらいいのか迷ってしまったとしても心配しないでください。あなたは一人ではありません。彼らが本当に話しているのは、メタストアの作成に関してです。
それでは、メタストアとは一体何なのでしょうか？あなたのデータエコシステムの背後で、全てのどこにあるのかを調整し、ワークスペース横断での権限を管理していますが、実際にはデータを格納はしていない中央ディレクトリを考えてください。
従来のメタストアと異なり、Unity Catalogは名前空間にカタログというレベルを追加します。この追加のレイヤーは、あなたの組織と権限管理をさらに細かい粒度にすることを可能にし、これまで以上に大規模でのデータガバナンスを容易かつ柔軟なものします。例えば、同じスキーマ、テーブル構造を持つdev、stg、prodの3つのカタログによって、コードを変更することなしに容易にテストを行えるようになります。
おそらく、あなたは「私のワークスペースにメタストアをアタッチすると、hive_metastoreを無効化して何か壊してしまうのでは？」と自問することでしょう。答えはNOです。 Unity Catalogとhive_metastoreは何の問題も無く共存できます。あなたのクラスターはレガシーモードで稼働し続け、あなたのデータはそのままであり、あなたのジョブの参照は突然切り替わったりしません。置き換えを強制するのでは無く、あなたの道具箱に新しい道具を追加することをイメージしてください。このアプローチによって、徐々に移行することを可能にし、あなたの既存のワークフローに即座のインパクトを与えることなしに、Unity Catalogの集中管理された機能を完全に活用するための時間を得ることができます。
メタストアの作成と設定
免責事項: 新規ワークスペースではデフォルトでUnity Catalogが有効化されます。詳細はこちらをご覧ください。
問題が片付いたので、メタストアの作成に進むことができます。唯一の要件は、あなたがアカウント管理者であることであり、有効化しようとしているワークスペースがプレミアムプライン以上の対象になっていることです。
あなたのアカウントコンソールで、Catalogをクリックし、Create Metastoreを選択します。
以下のリンクから画面遷移のアニメーションを確認できます。
この画面で必要なことは、名前を指定し、ワークスペースが存在するリージョンを選択することです。Unity Catalogはクラウドリージョンに紐づけられ、あなたのデータの設計図であるメタデータのみを格納することを忘れないでください。
メタストアのデフォルトストレージロケーションを選択するために、ストレージ設定を追加するオプションがありますが、現時点ではこれをスキップすることを強くお勧めします。これを追加すると、あなたのデータがどこに格納されたのかの追跡ができなくなる場合があり、後で管理が困難になることがあります。
メタストアが準備できたら、次のステップはメタストアをワークスペースにアタッチすることです。恐れ知らずの探検者のように、ポップアップのメッセージを無視して次に進みましょう。ここで、爆弾を爆発させるのではないので、心配しないでください。何も爆発しません。
そして、これであなたのワークスペースではUnity Catalogが有効化されました！でも、待ってください。あなたのデータはどこに格納されるのでしょうか？ 次の記事で詳細に取り組みます。続報をお待ちください！
他の記事もチェックしたいですか？