Unity Catalog Lakeguardを発表できることを嬉しく思います。これにより、Databricksデータインテリジェンスプラットフォームのコスト効率の高いマルチユーザーコンピューティング上で完全なデータガバナンスを備えたSQL、Python、ScalaでApache Spark™ ワークロードを実行できるようになります。 従来、ガバナンスを強化するにはシングルユーザークラスターを使用する必要があり、コストと運用のオーバーヘッドを負担する必要がありました。Lakeguardを使用すると、ユーザーコードは他のユーザーのコードや共有コンピュート上のSparkエンジンから完全に分離された状態で実行されるため、実行時にデータガバナンスを強制する ことができます。 これにより、クラスターをチーム全体で安全に共有し、計算コストを削減し、運用の手間を最小限に抑えることができます。
Lakeguardは、Unity Catalogの導入以来、不可欠な存在となっています。DBR 13.1ではPython UDF、DBR 13.3ではScalaサポート、そして最終的にはDBR 14.3でScala UDFを使用して、共有クラスター上で任意のコードを実行する機能を徐々に拡張してきました。Databricks SQLウェアハウス内のPython UDFもLakegaurdによって保護されています！ これ により、Databricksのお客様は、SQL、Python、Scalaのワークロードを、完全なデータガバナンスを備えたマルチユーザーコンピューティング上でUDFを含めて実行することができます。
このブログの投稿では、Unity Catalog Lakeguardの概要と、LakeguardがデータガバナンスでApache Spark™ をどのように補完するかについて詳しく説明します。
Apache Sparkは、世界で最も人気のある分散データ処理フレームワークです。 企業のデータ重視に伴いSparkの利用が増加するにつれ、データガバナンスの必要性も高まっています。 例えば、一般的なユースケースは、財務と人事などの異なる部門間でデータの可視性を制限したり、ビューやテーブルの列や行レベルのフィルタなどのきめ細かいアクセス制御を使用してPIIデータを保護することです。 Databricksのお客様にとって、Unity Catalogは、あらゆるクラウド上のすべてのテーブル、ビュー、機械学習モデルに対する包括的なガバナンスとリネージを提供します。
Unity Catalogでデータガバナンスを定義したら、実行時にガバナンスルールを適用する必要があります。最大の技術的課題は、Sparkがユーザーコードを分離するメカニズムを提供していないことです。異なるユーザーが同じ実行環境であるJava仮想マシン（JVM）を共有するため、ユーザー間でデータが漏洩する可能性があります。 クラウドでホストされるSparkサービスは、ユーザーごとに専用のクラスターを作成することでこの問題を回避しています。これにより、インフラコストの増加と、管理者がより多くのクラスターを定義して管理する必要があるため、管理オーバーヘッドの増加という 2 つの大きな問題が生じます。 さらに、Sparkは、きめ細かなアクセス制御を念頭に置いて設計されていません。ビューをクエリする際、Sparkはファイルを「オーバーフェッチ」します。つまり、ビューで使用される基礎となるテーブルのすべてのファイルをフェッチします。その結果、ユーザはアクセス権を付与されていないデータを読み取る可能性があります。
Databricksでは、Lakeguardを内部で使用する共有クラスターでこの問題を解決しました。 Lakeguardはコンピュートレベルで透過的にデータガバナンスを実施し、各ユーザのコードが他のユーザのコードや基礎となるSpark エンジンから完全に分離された状態で実行されることを保証します。Lakeguardはまた、Databricks SQLウェアハウス内のPython UDFを分離するためにも使用されます。これにより、Databricksは、SQL 、Python 、Scala のワークロードに対して、ビューや列レベル・行レベルのフィルタを使用したきめ細かなアクセス制御の実施を含む、完全なデータガバナ ンスでセキュアなコンピュート共有をサポートする業界初で唯一のプラットフォームです。
コンピューティングレベルでデータガバナンスを強制するために、ユーザーがJVMを共有するセキュリティモデルから、データガバナンスが常に強制されるように、各ユーザーのコードが相互および基盤となるSparkエンジンから完全に分離されて実行されるモデルにコンピューティングアーキテクチャを進化させました。 すべてのユーザーコードを (1) Sparkドライバーと (2) Spark エグゼキューターから分離することで、これを実現しました。下の画像は、従来のSpark アーキテクチャ（左）では、ユーザーのクライアントアプリケーションが、基礎となるマシンへの特権アクセスを持つJVMを共有していたことを表します。共有クラスター（右）では、すべてのユーザーコードがセキュアコンテナを使用して完全に分離されている様子を示しています。このアーキテクチャにより、Databricksは複数のワークロードを同じクラスター上で安全に実行し、共同作業、コスト効率、および安全なソリューションを提供します。
SparkクライアントアプリケーションをSparkドライバーから分離するために、私たちはまずこの2つを切り離し、次に個々のクライアントアプリケーションを互いに、そして基盤となるマシンから分離する必要がありました：
Sparkドライバと同様に、 Sparkエグゼキューターはユーザ定義関数（UDF）の分離を強制しません。例えば、UDFは、マシンへの特権アクセスにより、ファイルシステムに任意のファイルを書き込む可能性があります。クライアントアプリケーションと同様に、PythonおよびScala UDFを安全に実行するために、Sparkエグゼキューター上で実行環境をサンドボックス化しました。また、システムの他の部分から出力のネットワークトラフィックを分離しています。最後に、ユーザーが自分のライブラリをUDFで使用できるように、 クライアント環境をUDFサンドボックスに安全に複製します。その結果、共有クラスター上のUDFは完全に分離された状態で実行され、LakeguardはDatabricks SQLウェアハウス内のPython UDFにも使用さ れます。
今すぐ共有クラスターをお試しいただき、チームとのコラボレーションとコスト削減を実現してください。 LakeguardはUnity Catalogの不可欠なコンポーネントであり、Unity Catalogで共有クラスター、Delta Live Tables (DLT) 、Databricks SQLをご利用のすべてのお客様で有効になっています。
