Databricks Reposで実務と資格対策を両立する

Databricksのノートブック開発はブラウザ上で完結する手軽さがある一方、 チームでの共同開発やバージョン管理にはGit統合が必須です。Databricks Reposは、ワークスペース内から直接Gitリポジトリをクローンし、 ブランチの切り替え・Pull・Push・差分表示を行える機能です。

この記事では、Reposの概要、サポートされるGitプロバイダ、ブランチ運用設計、 ファイル形式の選択（.py vs .ipynb）、シークレット管理の注意点、そしてCI/CDとの連携パターンを解説します。

Databricks Reposとは

ReposはDatabricksワークスペース内のフォルダとして表示されるGitリポジトリのクローンです。 ローカルPCにGitをインストールする必要はなく、ワークスペースのUI上でブランチ操作・Pull・Pushを行えます。

Reposの主な特徴は以下の通りです。

• ワークスペースUIからブランチの作成・切り替え・Pull・Push・差分表示が可能
• ノートブック・Pythonファイル・SQLファイルなどをGit管理対象にできる
• Pull Request（PR）はGitプロバイダ側で作成・レビュー（DatabricksUI上では不可）
• 1ユーザーにつき複数のReposフォルダを作成可能（ブランチごとに分ける運用も可能）

サポートされるGitプロバイダ

Git認証情報はワークスペースのUser Settings → Git Integrationから設定します。 認証情報はユーザー単位で保存され、ワークスペース内の他のユーザーからは参照できません。

ブランチ運用のベストプラクティス

Databricks Reposを使ったチーム開発では、以下のブランチ戦略が推奨されます。

実際の開発フローは以下の通りです。

1. 開発者がReposでfeature/add-etl-pipelineブランチを作成
2. ノートブックUI上でコードを開発・テスト
3. ReposのUIからCommit → Push
4. GitプロバイダのWebUI上でPull Requestを作成
5. レビューアがコードレビューし、CIがテストを実行
6. マージ後、CI/CDパイプライン（DABs等）が本番環境にデプロイ

ファイル形式の選択: .py vs .ipynb

Databricks ReposでGitに保存されるファイルの形式はGit管理の品質に直結します。

Databricksのノートブックを.py形式で保存する場合、セルの区切りは# COMMAND ----------コメントで表現されます。 DatabricksのUIではこのコメントを解釈してセル分割を再現するため、.py形式でもノートブックUIの使い勝手は維持されます。

# Databricks notebook source

# COMMAND ----------

from pyspark.sql import SparkSession

# COMMAND ----------

df = spark.read.format("delta").load("/mnt/data/sales")
display(df.limit(10))

# COMMAND ----------

# MAGIC %sql
# MAGIC SELECT region, SUM(amount) FROM sales GROUP BY region

シークレット管理の注意点

Repos（Gitリポジトリ）にシークレット情報を含めてはいけません。以下は厳守すべきルールです。

• APIキー・パスワード・トークンはコードに書かない: Gitの履歴に永続的に残り、 リポジトリが公開された場合やチームメンバーの退職時にシークレットが漏洩する
• Databricks Secret Scopeを使う: dbutils.secrets.get(scope, key)で 実行時にシークレットを取得する。Secret ScopeはDatabricks上に安全に保存され、Gitには含まれない
• 環境変数を活用する: クラスタの環境変数やSpark Config経由でシークレットを注入し、 コード上ではキー名のみ参照する
• .gitignoreを活用する: 設定ファイルやローカルの.envファイルをGit管理対象外にする

# NG: シークレットをハードコード
storage_key = "AbCdEfGhIjKlMnOp..."

# OK: Secret Scopeから取得
storage_key = dbutils.secrets.get(scope="my-scope", key="storage-key")

# OK: Spark Configから取得（クラスタ設定で注入）
storage_key = spark.conf.get("spark.custom.storage_key")

CI/CD連携パターン

Reposは開発フェーズのGit統合を担い、デプロイはCI/CDパイプライン（DABs、GitHub Actions等）が担当する 「開発はRepos、デプロイはCI/CD」の役割分担が推奨されます。

Reposの制限事項

• リポジトリのサイズ上限は10 GB（大きなデータセットやバイナリファイルはGit LFSを検討）
• 1つのReposフォルダは1つのGitリポジトリに対応（モノレポの場合はスパースチェックアウトを検討）
• マージコンフリクトの解消は基本的なもの以外はGitクライアント側で行う必要がある
• Git Submodulesは非サポート
• Reposフォルダ内のファイルはワークスペースACLでアクセス制御される（Gitの権限とは別）

Repos vs Workspace Filesの違い

Databricksにはファイルを配置する場所としてReposとWorkspace Filesがあります。

試験で問われるポイント

• 「ノートブックのバージョン管理に使う機能は」→ Databricks Repos（Git統合）
• 「シークレットをGitリポジトリに含めてよいか」→ 不可。Secret Scopeを使用する
• 「ReposとDABsの使い分けは」→ Reposは開発フェーズのGit統合、DABsはデプロイ自動化
• 「PRレビューはどこで行うか」→ Gitプロバイダ（GitHub/GitLab等）のWebUI上
• 「.ipynbのGit管理の問題点は」→ JSON形式でdiffが読みにくく、出力セルがノイズになる

問題で確認

よくある質問