連載「Genie Codeと学ぶDatabricks」

はじめに

前回の記事では、フルページ型のGenie Codeに仕様を渡してノートブックを作らせ、コードを読み解きながら学ぶという2026年型の学習法を提案しました。ありがたいことに反響をいただいたので、この進め方でDatabricksの主要機能を一つずつ体で覚えていく連載にします。

今回はUnity Catalogです。前回「AIに任せず自分の頭に入れるべき概念」の筆頭に挙げた、3階層名前空間の話。概念の説明を読むだけでは頭に残らないので、今回もGenie Codeに作らせて、出てきたものを読み解きながら固めていきます。

Unity Catalogとは (日本語ドキュメント)

環境は前回同様、Databricks Free Editionです。

Unity Catalogは「データの住所体系」

Unity Catalogを一言で言うと、ワークスペース上のすべてのデータとAI資産に住所を与える仕組みです。テーブル、ビュー、ボリューム、関数、モデルまで、あらゆる資産が カタログ.スキーマ.オブジェクト という3階層の名前空間に従います。

前回の記事で使った samples.tpch.orders がまさにこれです。samplesというカタログの、tpchというスキーマの、ordersというテーブル。ファイルパスを覚える必要も、接続文字列を管理する必要もなく、この住所さえ分かればSQLからもPySparkからもGenie Codeへの依頼文からも同じ名前でアクセスできます。

住所体系が一つに決まっていることの効能は3つあります。どこにあるかが一意に決まる (名前空間)、誰が触れるかを住所単位で制御できる (権限)、どこから来てどこで使われているかが自動で記録される (リネージ)。この3つ目は後半で実際に目にします。

まず、今見えている世界を一覧する

最初のステップは、何かを作ることではなく、いま自分のワークスペースから何が見えているかを把握することです。フルページ型のGenie Codeにこう依頼します。

今のワークスペースで見えるデータの全体像を確認するノートブックを作成してください。
- SHOW CATALOGSでカタログの一覧を表示する
- samplesカタログのスキーマ一覧と、samples.tpchスキーマのテーブル一覧を表示する
- samples.tpch.ordersをDESCRIBE EXTENDEDで確認する
- 各セルの前に、その結果が何を意味するかをコメントで説明する

生成されたノートブックを開いて、セルを上から順に実行していくと、3階層が上から順に見えていきます。カタログの一覧には、サンプルデータ用のsamples、自分の作業用となるworkspace、そしてシステムテーブル用のsystemが並んでいるはずです。私の環境ではこれに加えて、過去の検証で作ったカタログもいくつか表示されました。SHOW CATALOGSの結果が人によって違うこと自体が、カタログが「ワークスペースの中の論理的な分離単位」であることの現れです。Free Editionでは、このうちworkspaceカタログが自分のホームになります。

細かい発見も一つ。SHOW SCHEMASの結果列は「databaseName」、SHOW TABLESの結果列は「database」という名前になっています。スキーマを見ているのにデータベース？と混乱しそうになりますが、Sparkの世界ではスキーマとデータベースは同義語で、出力にはまだ古い呼び名が残っている、というだけの話です。初見で戸惑うポイントなので先にお伝えしておきます。

読み解きの本命はDESCRIBE EXTENDEDの出力です。28行ほどの出力の前半はカラム定義 (o_orderkeyがbigint、o_totalpriceがdecimalなど) で、スクロールした後半の「# Detailed Table Information」ブロックに、このテーブルのメタデータがまとまっています。CatalogとDatabaseの欄で住所が確認でき、TypeがMANAGED、Providerがdeltaとなっているはずです。

このブロックは眺めるほど発見があります。Statisticsを見るとordersは750万行あることが分かりますし、Locationには実体が置かれているS3のパスまで表示されています。ただしIs_managed_locationはtrue。つまり実体は確かにS3上のファイルなのですが、その置き場所の管理はDatabricks側の仕事で、私たちがこのパスを覚えたり直接触ったりする必要はない。これが「マネージド」の意味です。住所 (3階層の名前) だけ知っていればよい、という冒頭の話がここでつながります。

そしてProviderのdeltaが何者なのかは、次回のDelta Lake編の主役なので、ここでは「そういう形式で保存されているらしい」で通過して大丈夫です。

自分の置き場を作る

見るだけ見たら、次は自分の住所を作ります。仕様はこうです。

workspaceカタログの中に、自分の学習用の置き場を作るノートブックを作成してください。
- tpch_learningというスキーマを作成する (すでに存在すればそのまま使う)
- samples.tpch.ordersから1998年の注文だけを抽出し、
  workspace.tpch_learning.orders_1998というテーブルとして保存する
- 保存したテーブルの件数と先頭5行を表示する
- テーブル名はすべてカタログ.スキーマ.テーブルの3階層で指定する

最後の行にわざわざ「3階層で指定する」と入れているのがこの記事のキモで、理由は後述のハマりどころで説明します。

今回は1本目と違って書き込みを伴うため、Genie Codeの挙動も変わりました。ノートブックを生成した後、すぐには実行せず「作成される内容: スキーマ workspace.tpch_learning、テーブル workspace.tpch_learning.orders_1998」と提示して承認を求めてきます。読むだけの操作は自律的に進み、環境に変更を加える操作は人間の承認を挟む。この線引きは安心材料です。

承認して実行する前に、生成されたコードを読みます。スキーマ作成はこうなっていました。

CREATE SCHEMA IF NOT EXISTS workspace.tpch_learning
COMMENT 'TPCHデータセットの学習用スキーマ';

IF NOT EXISTSが付いているのは再実行しても壊れないようにするためで、こういう防御的な書き方はAIの出力から学べる良い癖の一つです。依頼していないのにCOMMENTまで付いているのも、後から他人 (と未来の自分) がスキーマの用途を判別できるという意味で実務的です。

一方、テーブルの保存はこうです。

CREATE OR REPLACE TABLE workspace.tpch_learning.orders_1998
AS
SELECT * FROM samples.tpch.orders
WHERE YEAR(o_orderdate) = 1998;

ここで手が止まった方は、前回の記事を読んでくださった方です。OR REPLACE、つまり同名のテーブルが既にあれば黙って置き換える書き方です。今回は新規作成なので実害はありませんが、この選択をAIが特に説明なく行っているという事実は、前回の「書き込みmodeは自分の目で確認する」とまったく同じ構図です。ではREPLACEされた側のテーブルは本当に消えてしまうのか。実はそう単純ではないのですが、それを確かめるのが次回のタイムトラベルです。

実行すると、orders_1998の件数は668,101件でした。前回を覚えている方は「1998年のデータは8月の途中までしかない」ことも思い出せるはずで、1年分にしては少なめのこの件数がそれを裏付けています。先頭5行も1998-01-01の注文から始まっており、意図通りの抽出です。

カタログエクスプローラーで裏を取る

作ったものをコード側からだけでなく、UIからも確認します。左サイドバーのカタログアイコンからカタログエクスプローラーを開き、workspace → tpch_learning → orders_1998 とたどってください。

ツリーを眺めると小さな発見があります。workspaceやsystemは「自組織」の下に、samplesは「受け取った共有」の下にぶら下がっています。SHOW CATALOGSでは同列に並んでいたsamplesカタログ、実はDelta Sharingで外部から共有されているデータでした。SQLとUIの両方から眺めると、こういう構造が見えてきます。

サンプルデータのタブではorders_1998の中身がプレビューでき、上部には「What is the average total price by order status?」といった自然言語の質問候補まで並んでいます。この質問機能の正体は連載第5回で扱うGenieです。詳細タブを開くと、タイプ: MANAGED、作成者、そしてdelta.で始まる大量のプロパティ (spark.sql.statistics.numRows=668101という行もあります) が確認でき、先ほどDESCRIBE EXTENDEDで見た情報とつながります。

本命は依存関係のタブです。開くと3つのエントリが並んでいるはずです。上流にsamples.tpch.orders (テーブル) と「TPCH学習用データ準備」ノートブック、下流にも同じノートブック。つまりorders_1998がどのテーブルから作られたかだけでなく、どのノートブックが作り、どこで読まれているかまで自動で記録されているということです。念のため繰り返すと、リネージのための設定は何一つしていません。

「リネージグラフを表示」を押すと、samples.tpch.ordersからorders_1998への流れが、列の情報付きで図として表示されます。

これがUnity Catalogのガバナンスの実感ポイントです。「このテーブル、どこから来たんだっけ」「このテーブル、消していいんだっけ」という、実務で毎週のように発生する問いに、ドキュメントではなくプラットフォームが答えてくれる。個人学習の規模ではありがたみが薄いですが、テーブルが数百個ある組織では、これがあるかないかで運用の景色が変わります。

ハマりどころ: 名前を1階層で書くと迷子になる

今回の仕様プロンプトで「3階層で指定する」と縛った理由です。

実はテーブル名は orders_1998 のように1階層だけで書くこともできます。その場合、現在のデフォルトカタログとデフォルトスキーマが補われて解決されます。デフォルトは USE CATALOG や USE SCHEMA で切り替えられるほか、ノートブックの環境設定にも依存します。

つまり、同じ orders_1998 という名前が、実行時の状態によって別の場所を指し得るということです。自分で書くコードなら意識できますが、AIに書かせる場合はここが落とし穴になります。Genie Codeも文脈によっては省略形でコードを書くことがあり、そのコードは「たまたまデフォルトが合っていた環境」でしか正しく動きません。読めないコードより怖いのは、読めるのに場所が曖昧なコードです。依頼にも、生成されたコードにも、3階層のフルパスを徹底する。今回一番持ち帰ってほしい癖はこれです。

もう1つ、片付けに関する注意です。スキーマごと削除する DROP SCHEMA ... CASCADE は、中のテーブルをすべて道連れにします。Genie Codeに「作ったものを削除して」と頼むとCASCADEを使ったコードが出てくることがありますが、実行前に何が消えるのかを必ず自分の目で確認してください。前回の「書き込みmodeは自分で確認する」と同じ構図で、破壊的な操作の最終判断はAIに委ねない、が原則です。

なお、カタログそのものを新規作成することも可能ですが、この連載ではworkspaceカタログ配下で完結させます。組織のワークスペースではカタログの作成は管理者の権限設計に従う領域なので、実務でもまずスキーマから考えるのが現実的です。

まとめ

Unity Catalogを手を動かして確かめた結果をまとめます。

すべてのデータ資産は カタログ.スキーマ.オブジェクト の3階層の住所を持つ。Free Editionでは自分のホームはworkspaceカタログ
SHOW CATALOGSから順に降りていくと、3階層は「読む」だけで把握できる。DESCRIBE EXTENDEDで住所・MANAGED・Provider: deltaが確認できる
テーブル名は1階層でも書けてしまい、その場合デフォルト設定次第で別の場所を指し得る。依頼にも生成コードにも3階層フルパスを徹底する
リネージは何も設定しなくても自動記録される。上流のテーブルだけでなく、作成・参照したノートブックまで依存関係として追える
DROP SCHEMA CASCADEのような破壊的操作は、AIが提案してきても実行前に消える範囲を自分の目で確認する

概念としてのUnity Catalogは前回の記事でも紹介済みでしたが、SHOW CATALOGSから住所をたどり、自分のスキーマを作り、リネージが勝手に記録されているのを見る、という一巡をやると、3階層は「知識」から「感覚」になります。所要時間は30分程度なので、ぜひ手元のFree Editionで流してみてください。

次回はDelta Lake編です。今回DESCRIBE EXTENDEDの出力で素通りした「Provider: delta」の正体を確かめます。orders_1998に追記し、上書きし、わざと壊して、タイムトラベルで戻すところまでやる予定です。

参考リンク

はじめてのDatabricks

はじめてのDatabricks

Databricks無料トライアル

Databricks無料トライアル