レンコン畑でつかまえて

Databricksでもdbtを動かしてみたい

2026-09-05T00:00:00Z

はじめに

DatabricksにはApache Spark™ 宣言型パイプラインといういい感じにデータを精錬するための機能があります。

同様の機能を持つ製品としてdbtがあります。 DatabricksだけであればSDPで十分ですが、触ったことすらないのは問題かなと思い試してみました。

PATの払い出し

dbtからDatabricksを触りに行くために、PATを発行しておきます。

めんどくさかったので私はAPI scopeをall-apisで発行してしまいましたが、たぶんsqlがあれば大丈夫かもしれません。しらんけど

dbt環境のセットアップ

Databricksの公式ドキュメントにセットアップ方法が載っているので、その通りにセットアップします。

Databricks曰くPythonの仮想環境を別途用意して、その上にインストールしろとのことです。

私はuvを使用しているので、uv環境セットアップします。

uv init -p 3.11

dbtのGet startedではバージョン2を進められるのですが、どうもプレリリースのようなので--prerelease allowを指定してインストールします。

uv add dbt --prerelease allow

あとは、dbtをDatabrickcsにつなげるためにDatabricksアダプターをインストールします。

uv add dbt-databricks

アダプターのインストールが完了したら、dbtのプロジェクトを初期化します。

uv run dbt init my_dbt_demo

対話形式でいろいろ聞かれるので、番号で答えたり実際の値を入力したりします。

04:55:39  Running with dbt=1.12.3
04:55:39  Creating dbt configuration folder at C:\Users\someone\.dbt
04:55:39  Setting up your profile.
Which database would you like to use?
[1] databricks
[2] spark

(Don't see the one you want? https://docs.getdbt.com/docs/available-adapters)

Enter a number: 1 👈 Databricksにつなぐので「１」
host (yourorg.databricks.com): dbc-12345678-abcd.cloud.databricks.com 👈 ワークスペースのホスト
http_path (HTTP Path): /sql/1.0/warehouses/abc123456789a123 👈 SQL WarehousesのHTTPパス
[1] use access token
Desired access token option (enter a number): 1 👈 トークンを使用するので「1」
token (dapiXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX): 👈 トークンを入力
[1] use Unity Catalog
[2] not use Unity Catalog
Desired unity catalog option (enter a number): 1 👈 UCを使用するので「1」
catalog (initial catalog): dbt 👈 カタログ名を入力
schema (default schema that dbt will build objects in): default 👈 スキーマ名を入力
threads (1 or more) [1]: 👈 同時実行するスレッド数を入力？
04:59:06  Profile my_dbt_demo written to C:\Users\someone\.dbt\profiles.yml using target's profile_template.yml and your supplied values.
04:59:06  Running dbt debug to validate the project...
04:59:06  dbt version: 1.12.3
04:59:06  python version: 3.11.15
04:59:06  python path: C:\dev\try-databricks-dbt\.venv\Scripts\python.exe
04:59:06  os info: Windows-10-10.0.26200-SP0
04:59:06  Using profiles dir at C:\Users\someone\.dbt
04:59:06  Using profiles.yml file at C:\Users\someone\.dbt\profiles.yml
04:59:06  Using dbt_project.yml file at C:\dev\try-databricks-dbt\my_dbt_demo\dbt_project.yml
04:59:06  adapter type: databricks
04:59:06  adapter version: 1.12.5
04:59:06  Configuration:
04:59:06    profiles.yml file [OK found and valid]
04:59:06    dbt_project.yml file [OK found and valid]
04:59:06  Required dependencies:
04:59:06   - git [OK found]

04:59:06  Connection:
04:59:06    host: dbc-52ec1bce-aed0.cloud.databricks.com
04:59:06    http_path: /sql/1.0/warehouses/ca9667106d87a573
04:59:06    catalog: dbt
04:59:06    schema: default
04:59:06  Registered adapter: databricks=1.12.5
04:59:07  Databricks adapter:   SPOG host (host_type='workspace'): no
04:59:07  Databricks adapter:   workspace_id (from ?o= in http_path): None
04:59:07  Databricks adapter:   databricks-sql-connector version: 4.4.0 (supported)
04:59:07  Databricks adapter:   databricks-sdk version: 0.117.0 (supported)
04:59:21    Connection test: [OK connection ok]

04:59:21  All checks passed!
04:59:21  Your new dbt project "my_dbt_demo" was created!
Initialized new project in C:\dev\try-databricks-dbt\my_dbt_demo\my_dbt_demo

For more information on how to configure the profiles.yml file,
please consult the dbt documentation here:

  https://docs.getdbt.com/docs/configure-your-profile

One more thing:

Need help? Don't hesitate to reach out to us via GitHub issues or on Slack:

  https://community.getdbt.com/

Happy modeling!

初期化が終わるとプロジェクトのディレクトリが作成されているので、移動します。

cd .\my_dbt_demo\

ちゃんと初期化できているか動作確認をします。色々出てきますが、All checks passed!と出ればOKなんだと思います。

uv run dbt debug

05:02:37  Running with dbt=1.12.3
05:02:37  dbt version: 1.12.3
05:02:37  python version: 3.11.15
05:02:37  python path: C:\dev\try-databricks-dbt\.venv\Scripts\python.exe
05:02:37  os info: Windows-10-10.0.26200-SP0
05:02:38  Using profiles dir at C:\Users\someone\.dbt
05:02:38  Using profiles.yml file at C:\Users\someone\.dbt\profiles.yml
05:02:38  Using dbt_project.yml file at C:\dev\try-databricks-dbt\my_dbt_demo\dbt_project.yml
05:02:38  adapter type: databricks
05:02:38  adapter version: 1.12.5
05:02:38  Configuration:
05:02:38    profiles.yml file [OK found and valid]
05:02:38    dbt_project.yml file [OK found and valid]
05:02:38  Required dependencies:
05:02:38   - git [OK found]

05:02:38  Connection:
05:02:38    host: dbc-52ec1bce-aed0.cloud.databricks.com
05:02:38    http_path: /sql/1.0/warehouses/ca9667106d87a573
05:02:38    catalog: dbt
05:02:38    schema: default
05:02:38  Registered adapter: databricks=1.12.5
05:02:39  Databricks adapter:   SPOG host (host_type='workspace'): no
05:02:39  Databricks adapter:   workspace_id (from ?o= in http_path): None
05:02:39  Databricks adapter:   databricks-sql-connector version: 4.4.0 (supported)
05:02:39  Databricks adapter:   databricks-sdk version: 0.117.0 (supported)
05:02:42    Connection test: [OK connection ok]

05:02:42  All checks passed!

モデリングする

サンプルデータの作成

公式のチュートリアルに沿って、いろいろと試してみましょう。

チュートリアルははじめにサンプルテーブルを作るように言いますが、なんとコード例が動きません。ですので、あきらめてそれっぽい等価なSQLに書き換えて実行します。

CREATE OR REPLACE TABLE diamonds AS
SELECT
  *
FROM
  read_files(
    "/Volumes/samples/databricks/datasets/Rdatasets/data-001/csv/ggplot2/diamonds.csv",
    format => 'csv',
    header => true
  )

モデルの作成

すでに公式チュートリアルを脱線しますが、dbt上でちゃんとリネージを扱えるように先ほど作成したテーブルをソーステーブルとして登録します。

models/sources.ymlみたいなファイルに定義するようです。

version: 2

sources:
  - name: diamonds_raw
    catalog: dbt
    schema: default
    tables:
      - name: diamonds

そうすると、{{ source('diamonds_raw', 'diamonds') }}のような表記で参照できるようになるので、各モデル内で参照します。

{{
  config(materialized = 'table', file_format = 'delta')
}}
SELECT
  carat,
  cut,
  color,
  clarity
FROM
  {{ source('diamonds_raw', 'diamonds') }}

{{
  config(materialized = 'materialized_view')
}}
SELECT DISTINCT
  color
FROM
  {{ ref('diamonds_four_cs') }}
ORDER BY
  color ASC

SELECT
  color,
  avg(price) AS price
FROM
  {{ source('diamonds_raw', 'diamonds') }}
GROUP BY
  color
ORDER BY
  price DESC

コマンドを実行すると、それぞれテーブルやマテリアライズドビュー・ビューが生えてきます。

uv run dbt run

07:37:47  Running with dbt=1.12.3
07:37:48  Registered adapter: databricks=1.12.5
07:37:48  [WARNING]: Configuration paths exist in your dbt_project.yml file which do not apply to any resources.
There are 1 unused configuration paths:
- models.my_dbt_demo.example
07:37:48  Found 3 models, 1 source, 773 macros
07:37:48
07:37:48  Concurrency: 1 threads (target='dev')
07:37:48
07:37:54  1 of 3 START sql table model default.diamonds_four_cs .......................... [RUN]
07:37:57  1 of 3 OK created sql table model default.diamonds_four_cs ..................... [OK in 3.73s]
07:37:57  2 of 3 START sql view model default.diamonds_prices ............................ [RUN]
07:37:59  2 of 3 OK created sql view model default.diamonds_prices ....................... [OK in 1.92s]
07:37:59  3 of 3 START sql materialized_view model default.diamonds_list_colors .......... [RUN]
07:38:47  3 of 3 OK created sql materialized_view model default.diamonds_list_colors ..... [OK in 47.59s]
07:38:47
07:38:47  Finished running 1 materialized view model, 1 table model, 1 view model in 0 hours 0 minutes and 58.55 seconds (58.55s).
07:38:47
07:38:47  Completed successfully
07:38:47
07:38:47  Done. PASS=3 WARN=0 ERROR=0 SKIP=0 NO-OP=0 REUSED=0 TOTAL=3

リネージの確認

uv run dbt docs generate

uv run dbt docs serve

とすると、ローカルサーバーが起動してモデル間のリネージが見られるようになります。

おわりに

いったんはここまでとしますが、中身はJinjaテンプレートらしく、いろいろと作りこめるそうなので今後もいろいろと触ってみたいですね。

おわり

Databricks SDKでも統合認証を使いたい

2026-08-14T00:00:00Z

はじめに

Databricksでは統合認証と呼ばれる、ツールやSDKの言語に関わらず統一的な方法で認証を行う方法が用意されています。

その中でも、今回はなんだかんだ言って色々お世話になりそうな環境変数を使用した認証を試してみます。

ここで紹介されている環境変数はSDKだけでなく、CLIやTerraformでの認証にも使うことが出来ます。

認証を行うサンプルコード

今回はDatabricks SDK for Pythonを使用します。

from databricks.sdk import WorkspaceClient

w = WorkspaceClient()

for c in w.catalogs.list():
    print(c.name)

みたいなコードを用意し、uvの環境変数読み込み機能を使用して環境変数経由で認証情報を注入します。

認証がうまくいけば、認証されたユーザ・サービスプリンシパルの権限に応じたカタログの一覧が見えるはずです。

以下のサンプルではDATABRICKS_AUTH_TYPEを使用して認証方法の指示をSDKに与えていますが、与えない場合は認証方法の優先度に応じて認証を試行します。

Databricks CLIの認証情報を使用した認証

Databricks CLIを使用してOAuth U2M認証を行ってから、その認証情報を使ってSDKの認証を行います。

使い方はとっても簡単で、databricks auth loginでCLI上でログインしてから以下の環境変数をセットするだけです。

DATABRICKS_CONFIG_PROFILEはDEFAULT以外のプロファイル名を使用したいときに設定します。

DATABRICKS_HOST=https://dbc-12345678-abcd.cloud.databricks.com
DATABRICKS_AUTH_TYPE=databricks-cli

Personal Access Tokenを使用した認証

PATを発行して、そのPATでアクセスします。

DATABRICKS_HOST=https://dbc-12345678-abcd.cloud.databricks.com
DATABRICKS_AUTH_TYPE=pat
DATABRICKS_TOKEN=<token>

サービスプリンシパルのシークレットを使用した認証

何らかの処理を自動化したい場合、サービスプリンシパルを使うことも多いと思います。

DATABRICKS_HOST=https://dbc-12345678-abcd.cloud.databricks.com
DATABRICKS_AUTH_TYPE=oauth-m2m
DATABRICKS_CLIENT_ID=00000000-0000-0000-0000-000000000000
DATABRICKS_CLIENT_SECRET=<secret>

おわり

AWS Summit Japan 2026 に参加してきたお話

2026-06-28T00:00:00Z

はじめに

今年もAWS Summit Japanに参加してきたので、そのお話です。

全体的なお話

全体を通して感じたのが、「AI（エージェント）が当たり前になった」という点です。

企業でAIエージェントをデプロイするのは当たり前として、どのように使えるエージェントをコスト効率よくデプロイするかという実用面に軸足が移ったと感じました。

各社フロンティアモデルであれば業務を遂行させるのに十分な性能を持っており、あとはAIにどのようにコンテキストを与えますか？エージェントの設計はどのようにしますか？という方向にトレンドが移っていると感じます。

そんな感じのお仕事をしている私にとってはワクワクした内容でしたが、全体的に展示内容としては猫も杓子もAIになっているので、AI周りに食傷気味な方にとっては少しつまらない内容になってたかもしれません。

AWS謹製のオントロジー

個人的に一番興味深かったのが、AWSが開発中としているオントロジー製品（Project Orion）のデモの展示があったことです。

既存のRDSやJDBC・Snowflake（や、たぶんDatabricksも）をラップする形で定義する、既存のDB構造やドキュメントからオントロジーを構築し人間が承認する形式を取るとのことでした。

現在は規制業界でAIエージェントが厳格に回答をしないといけない領域をターゲットとしているらしく、デモでは某金融機関のロゴが見えてました。（このロゴは見えていいのでしょうか？）

DatabricksのData + AI Summit 2026でもGenie Ontologyというオントロジー製品の発表がありましたが、AIにコンテキストを理解させるコンテキストレイヤーとしてオントロジーを各社注目していること、開発を進めていることはAIエージェントを開発している1人として注目せざる負えませんでした。

オントロジーが一般企業に使いこなせるかどうか・お仕事で使う（使わせてもらえる）かはなんともかんともですが、ひとまずはこのあたりの製品は追い続けたいですね。

おわりに

Project Orionは個人的にはビッグニュースなのですが、誰も何も書いてないんですよね。もしかしたら私が幻覚を見せられていた説や、ほんとはしゃべっちゃいけない内容で途中から見せなくなったとかじゃないですよね・・・

追記（2026年8月4日）

Project Orionとして展示されていたものはContext Ontology Acceleratorという名前になってOSSで公開されたようです。

すでにAWS Japanの方が記事を書いて下さっているようなので、そのうち触ってみたいですね。

オントロジーで AI に業務知識を渡す — AWS の OSS「Context Ontology Accelerator」を試してみた

おわり

UUIDv7の基礎

2026-06-21T00:00:00Z

はじめに

そういえばいつぞやにPostgresでのUUIDv7の単調性の保証方法について解説しましたが、そもそもUUIDv7について書いてないなと思い返したので、昔の発表資料を再利用しつつブログにも書いておこうと思います。

UUID

そもそもUUIDってなんだっけというお話から入ろうと思います。

仕様から引用すると

A UUID is 128 bits long and is intended to guarantee uniqueness across space and time.

ということで、UUIDは128bitからなる識別子で、空間と時間にわたって一意性を保証します。

00000000-0000-0000-0000-000000000000みたいな見た目をしており、最新の仕様はRFC9562で規定されています。

UUIDの各バージョン

UUIDはv1からv8まで規定されています。が、v2は仕様からはハブられているので仕様としては7種類です。まぁ、実務上だとv4とv7しか使わないと思うのでとりあえず2種類覚えておけば生きていけます。

v8はベンダー固有ということで、独自のUUID実装を表すバージョンとなっています。

バージョン	説明
UUIDv1	100ナノ秒単位のタイムスタンプ＋重複回避用のクロックシーケンス＋ノードID タイムスタンプを下位ビットから並べているせいで生成順にソート出来ない
UUIDv2	（RFC9562で規定されていないので割愛）
UUIDv3	名前空間内で名前から一意な値を生成する（MD5）
UUIDv4	（バージョンとバリアントフィールド以外）完全にランダム
UUIDv5	名前空間内で名前から一意な値を生成する（SHA-1）
UUIDv6	UUIDv1のタイムスタンプを上位ビットから並べて生成順にソート可能にしたもの
UUIDv7	ミリ秒単位のUNIXタイムスタンプ＋ランダム値で生成順にソート可能にしたもの
UUIDv8	君だけの最強のUUIDを実装しよう

UUIDv7を採用するモチベーション

上記の表のとおり、v7以外にタイムスタンプを使用している実装としてv1とv6があります。

そのうち、v1はビットフィールドを下位から並べているせいで解析をしないとソートが出来ません。ただし、一般的なガイダンスとしてUUIDの解析は避けることが推奨されています。（Section 6.12.）

また、v1とv6はともにグレゴリオエポックでタイムスタンプが実装されていますが、グレゴリオエポックをIEEE754で実装するのは結構大変です。仕様としてもグレゴリオエポックをIEEE754で実装するのはまれとしています。（Section 2.1.）

v1とv6はUUIDの衝突を防ぐ目的でUUIDを生成した端末のMACアドレスを含めますが、仕様としてはセキュリティの目的でMACアドレスをUUID内で使用すべきではないというスタンスです。（Section 8.）

また、v7はv1やv6に比べてエントロピー特性を改善しています。（Section 5.7.）

ということからRFC的にもタイムベースなUUIDを使う場合はv7を採用するべきとしています。（Section 5.6.）

UUIDv7のフィールド及びビットレイアウト

v7はバージョンとバリアントを除くと、以下のフィールドから構成されます。

フィールド	説明
`unix_ts_ms`	48ビットで表現されたミリ秒単位のUnixエポックタイムスタンプ
`rand_a`	12ビットのランダムフィールド
`rand_b`	62ビットのランダムフィールド

unix_ts_msはミリ秒なので、同一ミリ秒内で複数回生成した場合は生成順のソート（単調性）を保証できなくなります。

追加の単調性を保証するためにRFCで提案されている方法

せっかくタイムスタンプを使って単調性を保証できるようにしたのに、なんだか片手落ちですね。

でももう大丈夫

RFCでは追加の単調性を保証する以下の3つを提案しています。（Section 6.2. Monotonicity and Counters）

共通して以下の方法はrand_a（とrand_bの左側ビット）を使用して追加の単調性を保証します。ただし、いずれも状態を保持する必要があるため、基本的にはシングルノードを前提としています。

固定ビット長カウンター

固定ビット長カウンターでは、rand_aの一部もしくは全部をカウンターとして使用して、タイムスタンプティック内で生成するたびにカウンターをインクリメントします。

また、桁数が不足するようであればrand_bの左側ビットもカウンターとして拡張します。

単調増加するランダム値

タイムスタンプティック内の初回生成時は普通にv7を生成し、2回目以降は前回生成した値にランダム値を加算していきます。

この場合、初回にあまりにも大きい値を生成してしまうとすぐにレンジを使いつぶしてしまうので、ramd_aパートを000で生成しておくといった工夫も必要になります。

追加のクロック精度の導入

rand_aを追加のタイムスタンプフィールドとし、サブミリ秒をエンコードして格納します。また、サブミリ秒が衝突した場合はサブミリ秒のティックを進めて衝突を回避します。

クロック精度がプラットフォームで変わるため、実装上はプラットフォーム毎に生成ロジックを変える必要があります。

まとめ

タイムベースのUUIDを使うならUUIDv7を使う
- UUIDv1 / UUIDv6は互換性が必要な用途以外では非推奨
タイムスタンプはミリ秒精度
- サブミリ秒を取り出せる場合もあるが、生成側の実装依存
実装によっては同一ミリ秒内でも単調性を保証する
RFCで提案しているのは以下の方法
- 固定ビット長カウンター
- 単調増加するランダム値
- 追加のクロックの導入

おわり

はじめてのDatabricks on AWS

2026-05-05T00:00:00Z

はじめに

上司から「Databricksを使えるようにしておいて」と言われることは長い人生のなかでは一度くらいはあるかもしれません。

「まぁ、公式リファレンスを見れば何とかなるやろ」と意気揚々と見に行くも、そもそもどこから読み始めたらよいかよくわからないリファレンスを前に心をへし折られた方もいると思います。私です

ここでは、私が実際にDatabricksをAWSに展開したときに知っておきたかった前提知識や参考になったページ、約1年程度運用して最初から考慮した方がよかったと思うプラクティスなどを紹介します。

前提知識

AWS

Databricksは基本的には顧客（つまり私たち）のAWS環境にデータを保存したり計算資源を作成します。 Serverless workspaceのようなものもあったりしますが、すべてをServerless workspaceで賄うのはたぶん無理だと思うのでいったん忘れてください。

Databricksでは主に以下のAWSリソースを使用するため、最低限概要をつかんでおく必要があります。

ストレージ（S3）

Databricksではあらゆる顧客データをS3のバケットに作成します。

生データはそのままオブジェクトとして保存されますし、テーブルデータはDelta Lakeと呼ばれるOpen Table Format（OTF）として保存されます。ワークスペースで作成したノートブックなども実体はS3に保存されます。

OTFにはそのほかにもApache Icebergなどがありますが、この段階では気にする必要はありませんし、そのうち違いは無くなるので将来的にはそんなこともありましたよねという感じになると思います。

なんだかDatabricks社はOTFをIceberg寄りにしたがってそうな雰囲気をなんとなく感じるので、余裕が出たらIcebergのことも追いかけておくと後々幸せになれるのではないかという気がして来ました。

また、使うのはS3 Tablesのようなものではなく普通のS3です。 Delta Lake自体にバージョニング機能（タイムトラベルクエリ）も持っているため、バケット側のバージョニングも使いません。

計算資源（EC2）

Databricksには主にクラシックコンピュートとサーバレスコンピュートの二種類があります。

そのうち、クラシックコンピュートは顧客のAWSアカウントで動作するEC2を実体としています。 EC2を稼働させるVPCがオンプレミスやほかのAWSリソースに接続しに行ける構成となっていれば、そのままDatabricksからオンプレミスのデータベースに接続することができます。

サーバレスコンピュートはDatabricks社のAWSアカウント上のKubernetesクラスタ上で動作しているらしいです。そのため、サーバレスコンピュート用の計算資源は管理する必要はありません。

ネットワーク（VPC・Peering・Direct Connect・Site-to-Site VPN）

クラッシックコンピュートの実体がEC2であるならば、そのEC2を稼働させるためのVPCも必要になります。

Databricksからオンプレミスのデータベースに接続する必要があれば、Direct ConnectやSite-to-Site VPNを使用してオンプレミスとの接続性を確保する必要があります。同様に、他のVPCのリソースに接続しに行く必要があればVPC Peeringなどで接続性を確保する必要があります。

この辺はDatabricks固有のお話というよりかは一般的なVPCネットワークの設計のお話となります。

Databricksコントロールプレーンへの権限の委譲（IAM）

AWSのリソースは顧客のAWSアカウントに作成しますが、クラシックコンピュート起動するたびに手動でEC2インスタンスを作成するわけではありません。

クロスアカウントアクセスが可能なIAMロールをDatabricksに連携しておいて、Databricksの制御側（この制御側をよくコントロールプレーンと呼びます）から必要なEC2インスタンスを作成したり削除してもらいます。

また、S3バケットに格納されているデータにアクセスするためのIAMロールなども作成して連携する必要があります。クラシックコンピュートやサーバレスコンピュートはこのIAMロールをAssume Roleしてデータに触りに行きます。

Databricks

Databricksではトップレベルの要素として、Unity Catalogとワークスペースが存在します。 Databricksの論理設計ではUnity Catalogとワークスペースの設計を最初に行います。

Unity Catalogの階層構造の設計や、ワークスペースの分割設計が今後のDatabricks運用に多大な影響を与えます。そのため、この部分の設計はふわっとやらない方が良いと思います。

Unity Catalog

Unity Catalog（UC）はデータを格納しアクセス権を管理するための入れ物となります。

UCはAWSの場合、リージョン毎に1つしか作成することができません。

UCでは常にcatalog.schema.objectという3タプルの識別子でオブジェクト（テーブル・ボリューム・モデル）を識別します。2つにしたり4つにしたりは出来ません。そのため、カタログやスキーマの階層構造の設計はその後のデータ整理に多大な影響を及ぼします。また、運用途中での変更には多大な労力がかかります。

What is Unity Catalog?

ワークスペース

UCがデータの入れ物であるならば、ワークスペースはプログラム（ノートブック・Job・パイプライン・ダッシュボード）と計算資源（クラスタ・AI Search）の入れ物となります。

ワークスペースは一つのリージョンの中に複数することができます。ワークスペースはアクセスの境界にもなるので、組織間のアクセス制御にワークスペースを使うことも多いです。

クラシックコンピュートとサーバレスコンピュート

クラシックコンピュートとサーバレスコンピュートはワークスペース作成時にどちらを使うか選択するようなものではなく、用途によってそれぞれ使い分けを行います。

サーバレスは制約は多いですが、起動がめっちゃ早いという1点だけでもかなり便利なので、個人的にはサーバレスでは出来ないこと以外は基本的にはサーバレスを使っています。

クラシックコンピュート
- メリット
  - VPCの構成によってはオンプレミスのリソースに接続しに行ける
  - EC2のインスタンスタイプやクラスタサイズを柔軟に構成できる
- デメリット
  - 起動に時間が掛かる
サーバレスコンピュート
- メリット
  - 起動がほぼ一瞬
- デメリット
  - （PrivteLinkの設定をしないと）オンプレミスのリソースには接続しに行けないうえに、PrivateLinkは追加のコストが掛かる
  - ~~GPUは使えない~~プレビューで使えるようになった

インフラ設計

ワークスペースとAWSリソースの関係

ワークスペースにはEC2を動かすためのアベイラビリティゾーンが異なるサブネットが最低2つと、ワークスペースのリソースを保存するためのS3バケットが1つ必要になります。

ワークスペースを作成するのに指定したバケットはそのままExternal locationsとしても登録されるので、UCを経由してテーブルなどのUCオブジェクトを保存するのにも使用できます。

また、ワークスペースのバケット以外にも別途バケットを作成してExternal locationとして登録すれば、UCオブジェクトを登録する専用のバケットとして使用することもできます。

VPC構成

EC2を動かすためのサブネットは最低限インターネットへの接続性があれば大丈夫です。また、S3用のゲートウェイエンドポイントには費用が掛からないのと、用意しないとS3のアウトバンドコストがまぁまぁ大変なことになるので最低限S3ゲートウェイエンドポイントは用意しておきます。

あとは、オンプレミスのデータベースやほかのVPCへの接続性のためにDirect ConnectやVPC Peeringを必要に応じて設定します。

ただし、この構成はクラシックコンピュートとコントロールプレーンの通信はインターネットを経由します。業界のコンプライアンス要件などでインターネットを経由できない場合、AWSサービスエンドポイントとDatabricksバックエンドサービスへのPrivateLinkを追加で構成することでインターネットへの接続性なしでクラシックコンピュートを運用できます。

クラシックコンピュートがインターネットへの接続性を持たない構成にすることもできます。この場合、ノートブックでPythonライブラリをインターネット経由でインストールすることが出来なくなるので、別途プロキシリポジトリを建てるかwheelパッケージをあらかじめダウンロードしてS3などに配置する必要があります。

厳密なインターネット分離が求められる場合、クラシックコンピュート⇔コントロールプレーン間だけでなくユーザ⇔コントロールプレーン間でもインターネットを経由しないことが求められるかと思います。その場合、フロントエンドへの接続もインターネットを経由しない構成にすることができます。

この辺を真面目にやろうとすると結構大変なので、やる場合は実力のあるサポートベンダに相談した方が良いです。

プラクティス

VPCは新規で作成するか？既存のを流用するか？

導入企業の既存のAWS環境の設計やポリシーに強く依存しますが、基本的には分けた方が良いと思います。 VPCが分かれてもVPC PeeringでほかのVPCに触りに行くことが出来ますし、Databricks向けのリソースと他のリソースが混ざる心配もありません。

もっというと、アカウントを分けるぐらいの勢いで行っても良いと思います。

サブネットサイズ設計

クラシックコンピュートのインスタンスは対コントロールプレーンに1つと、クラスタ内の通信に1つの計2つのプライベートアドレスを使用します。また、クラスタの再起動時や拡張・縮退時など稼働しているインスタンスよりも多い数のプライベートアドレスを使用することがあります。

とはいえ、あるワークスペースに割り当てられたサブネットは他のワークスペースに重複して割り当てが出来ないため、過剰に大きいサブネットに分割してしまうとサブネットが足りなくなる場面も出てきます。私です

個人的には最小のサブネットを/22として、稼働予定のインスタンスの倍の数を収容できるサブネットに分割するのがいいのかなと思っています。

マルチAZ構成

ワークスペースに関連付けるサブネットは最低でも2つ以上のAZで構成しなければいけませんが、高可用構成にするには最低でもNAT Gatewayも1つのAZに1つ作成するなど全体として単一障害点をなくさないといけません。

運用としてはクラシックコンピュートがワークロードの主体になっており、高可用性が求められるのであれば単一障害点をなくす設計を行わないといけません。

対して、普段のワークロードはサーバレスコンピュートが主体でクラシックコンピュートはオンプレミスに触りに行くだけとかであれば費用対効果の観点から高可用を捨ててしまってもいいかもしれません。

リソースの命名規則

DatabricksとAWSという異なる世界のリソースを一緒に扱うため、リソースの命名の一貫性には気を付けています。過去の経緯から一貫性を欠いているものも一部ありますが、こんな感じで短さよりも分かりやすさを優先して命名をしています。

Databricks

ワークスペース
- {リージョン名}-{連番}
- apn1-0

AWS

VPC
- databricks-vpc-{リージョン}
- databricks-vpc-apn1
サブネット
- databricks-subnet-{ワークスペース}-{AZ}
- databricks-subnet-apn1-0-a
バケット（カタログ）
- databricks-catalog-{リージョン}-rootbucket
- databricks-catalog-apn1-rootbucket
バケット（ワークスペース）
- databricks-workspace-{ワークスペース名}-rootbucket
- databricks-workspace-apn1-0-rootbucket

Terraformでのリソースのデプロイ

どこまでをTerraformなどのIaCに乗せるかは組織や担当者のIaCへの理解度に依存すると思います。

私はAWSのリソースはTerraformでデプロイしていますが、Databricksのリソースは手動で展開しています。

Databricksのリソースはものによっては一度作成したら削除出来ない・一度設定したら削除して再作成しないと変更できないリソースがそこそこあり、無理にTerraform化してよく分からないことになるくらいだったら手動で管理した方が管理しやすいと考えてそのようにしています。

カタログ設計

UCではcatalog.schema.objectの3タプルでオブジェクトが識別されます。また、アクセス権は階層構造で設定するので、3タプルの構造がそのままアクセス権の構造に影響します。

この辺は組織のポリシーやデータの特性に大きく影響を受けるためこれが正解というのはありませんが、一例として以下のようなイメージが考えられます。

ここではメダリオンアーキテクチャに従って、販売_bronzeをブロンズ層としてデータの着地点として利用します。

後続のシルバー層に向けてデータを供給する役目を持つことからブロンズ層はユーザには見せません。ブロンズ層は可能な限り上流のシステムに近い構成とし、認知負荷を下げます。

シルバー層ではすべてのユーザが見れる情報と閲覧できる人が限られる情報で分けてカタログに収納します。閲覧できる人が限られる情報についてはカタログとスキーマで権限を制御します。

catalog	schema	table
販売_bronze	販売	受注
		売上
		商品情報
	CRM	顧客情報
販売	販売	受注
		売上
		商品情報（原価情報なし）
	CRM	顧客情報（個人情報なし）
販売_センシティブ	原価	商品情報（原価情報あり）
販売_センシティブ	CRM	顧客情報（個人情報あり）

ワークスペース設計

1年近く運用してみて、ワークスペースは以下のように分割するのがいいのかなという感覚を持っています。まぁ、あくまでも私が所属している組織で都合が良いというだけで、あらゆる組織に適用できるかというと微妙ですが・・・

構成としては、ユーザが触る用のワークスペースとデータエンジニアが作業を行うデータの取り込み・パイプライン実行用のワークスペースを最低限分離します。

これはデータ取り込み用のリソース（ジョブ・パイプライン）と利用者が普段触るリソース（ダッシュボード・Genieスペース）を分離する意図があります。もちろん、アクセス権を設定すれば触れなくはなりますが、ワークスペースへのアクセス権レベルで制御してしまえば細かいリソース毎のアクセス権は気にしなくてもよくなります。

また、同時に複数のワークスペースからS3上のDeltaテーブルを変更するとデータが壊れるので、データを変更する操作はなるべく単一のワークスペースに寄せるようにしています。

また、ある程度の大きさの組織毎にワークスペースを分離します。ここでの組織とは、組織図に厳密に対応するものではなく、組織の属性に応じたものを考えています。組織の属性に応じて、どのカタログをアタッチするかの管理を行い、まずはアタッチするカタログレベルでデータへのアクセス権を絞ります。

もちろん、その先の細かいアクセス権の制御はUnity CatalogなりABACなりで制御を行います。

同様にDatabricks Appsやダッシュボード・Genieスペースはワークスペースに紐づくため、生産部門が営業部門のアプリに触らないまたはその逆が起こらないという観点からもワークスペースを分離します。

あとは、たまにやべー挙動をする利用者が出てくると思うので、その監査用にsystem.auditスキーマのテーブルを使ってアクティビティ監査を行う専用のワークスペースを置いておきます。

カタログ専用バケットのデプロイ

私の組織ではワークスペースとデータを完全に分離したいという考え方からカタログの保存先としてワークスペースのバケットは使用せず、カタログ保存用のバケットを用意したうえでそこに保存しています。

こうしておけばどのカタログがどのバケットに入っているかなどは気にしなくて良くなるので、組織のニーズに応じて柔軟にワークスペースの作成と削除を行えます。

ただし、複数のワークスペースから同じテーブルに変更をかけるとデータが壊れるので、テーブルの更新を行うワークスペースには気を付けた方が良いです。

新機能の検証用にアメリカリージョンにもワークスペースが欲しいよね

Databricksは過去からの傾向として、新機能のPreviewはアメリカのリージョンから利用可能になることが多いです。

私の組織ではアメリカの主要リージョンの中で日本からのレイテンシが比較的小さいus-west-2（オレゴン）に機能の評価用ワークスペースを構築しています。

機能の名前がすごい勢いで変わるので、頑張って追従する

Databricksはなぜかすごい勢いで機能の名前を変更します。

ちょっと思い出すだけでもこのくらいあります。

AI Search（旧：Vector Search）
Genie One（旧：Databricks One）
Spark Declarative Pipelines（旧：Delta Live Table）
Declarative Automation Bundles（旧：Databricks Asset Bundles）
OpenSharing（旧：Delta Sharing）
Genie Agents（旧：Genie Spaces）
Unity Gateway（旧：Unity AI Gateway）← New!

まぁ、ブランディングとか関連機能との整合性とかあるのでしょうがないのかもしれませんが、他の人と機能のことを話す際に「この人はどっちで覚えてるだろうか」みたいな余計な気を遣わないといけないので少し面倒です。

その他参考リファレンス

VPC

Configure a customer-managed VPC

Storage

Workspace

Create a workspace with manual AWS configurations

おわり

DatabricksのSpark Declarative Pipelinesを使って簡易的な家計簿を作りたい

2026-04-29T00:00:00Z

はじめに

DatabricksにはAI Functionsがあり、ノートブックやSQL Editorなどで使用できます。

いつからかSpark Declarative Pipelinesでも使えるようになっており、パイプラインだけでOCRと抽出が完結できるようになっていました。

そこで、今回はボリュームに格納されたレシートから日時と金額を抽出してダッシュボードに表示するまでの処理をSpark Declarative Pipelinesで実装して、Declarative Automation Bundlesでデプロイできるようにしてみました。

jyuch/public-expenses

パイプラインの実装

以下の流れのパイプラインを実装します。

Volumeからレシートのイメージをロード
ai_parse_documentでOCR処理を実行
ai_queryで抽出結果を構造化
構造化データをフラット化してシルバーテーブルに変換

基本的にai_〇〇は実行にまぁまぁの時間が掛かるので、毎回全部のイメージの再処理をしていたら実行時間がとんでもないことになります。そのため、ストリーミングテーブルを使用して差分実行を行うようにします。

この辺もCREATE STREAMING TABLEとSTREAM()でチェックポイントの管理をしなくても良きにしてくれるのでSDPは大好きです。

まずはVolumeに格納されているレシートのイメージをロードします。

CREATE STREAMING TABLE raw_receipts AS
SELECT
  path,
  modificationTime,
  length,
  content
FROM
  STREAM(READ_FILES('/Volumes/expenses/default/receipt_images/', format => 'binaryFile'));

そうしたら、ai_parse_documentでOCRを実行します。

CREATE STREAMING TABLE parsed_receipts AS
SELECT
  path,
  modificationTime,
  length,
  content,
  ai_parse_document(content, Map('version', '2.0')) AS parsed_receipt
FROM
  STREAM(raw_receipts);

ai_queryのresponseFormatにJSON Schemaを指定して構造化出力を行わせます。本当はSTRUCT<>で構造体の定義を指定できるはずなのですが、「Spark Declarative Pipelinesのバグにエンカウントしたのでバグ報告ヨロ」みたいなエラーが表示されるので、あきらめてJSON Schemaを指定しています。

個人的にはJSON Schemaは書式が冗長なので、できればSTRUCT<>の方の構文を使いたいです。

CREATE STREAMING TABLE structured_receipts AS
SELECT
  path,
  ai_query(
    'databricks-qwen3-next-80b-a3b-instruct',
    CONCAT(
      'レシートをパースした結果が与えられます。そこから購入日と合計金額を抽出しなさい。',
      parsed_receipt
    ),
    responseFormat =>
      '{
        "type": "json_schema",
        "json_schema": {
          "name": "structured_food_receipts",
          "schema": {
            "type": "object",
            "properties": {
              "purchase_date": {
                "type": "string",
                "format": "date"
              },
              "total_amount": {
                "type": "integer"
              }
            },
            "required": [
              "purchase_date",
              "total_amount"
            ]
          },
          "strict": true
        }
      }'
  ) AS structured_receipt
FROM
  STREAM(parsed_receipts);

抽出したパスからレシートの種類（食費とか日用品とか）を付与しています。また、JSON形式の文字列からSTRUCT<>に変換します。

購入日とかを抽出するタイミングでカテゴライズをしてもいいのですが、精度が出なかったのでひとまずファイルパスで識別させています。

CREATE STREAMING TABLE flatten_receipts AS
SELECT
  path,
  regexp_extract(path, '/([^/]+)/[^/]+$', 1) AS kind,
  try_cast(
    try_parse_json(structured_receipt) AS STRUCT<purchase_date DATE, total_amount INT>
  ) AS receipt
FROM
  STREAM(structured_receipts);

最後にフラット化すればひとまずは家計簿テーブルが完成します。名前とやっていることが微妙に一致してませんが、まぁ、その・・・。

CREATE OR REPLACE MATERIALIZED VIEW receipts AS
SELECT
  path,
  kind,
  receipt.purchase_date,
  receipt.total_amount
FROM
  flatten_receipts;

DABでの展開

パイプラインを手動でデプロイしてもいいのですが、全部自動でできた方がうれしいですよね。

ということでDABで一発デプロイできるようにします。

特にひねりのないdatabricks.ymlとresources/expenses.pipeline.ymlを定義します。

bundle:
  name: expenses
  uuid: 00000000-0000-0000-0000-000000000000

include:
  - resources/*.yml

variables:
  catalog:
    description: The catalog to use
  schema:
    description: The schema to use
  ingest_from:
    description: The path log ingestion

targets:
  dev:
    mode: development
    default: true
    variables:
      catalog: expenses
      schema: dev
  prod:
    mode: production
    workspace:
      root_path: /Workspace/Bundles/${bundle.name}/${bundle.target}
    variables:
      catalog: expenses
      schema: prod

resources:
  pipelines:
    expenses:
      name: expenses
      catalog: ${var.catalog}
      schema: ${var.schema}
      serverless: true
      root_path: "../src/expenses"

      libraries:
        - glob:
            include: ../src/expenses/transformations/**

      environment:
        dependencies:
          - --editable ${workspace.file_path}

あとは🚀ボタンで一発デプロイです。

ダッシュボードの作成

あとはお好みの種類のグラフでダッシュボードを作るだけです。

ダッシュボードもDABでデプロイ出来ます。お仕事ではダッシュボードもパイプラインと同じようにDABでデプロイしているのですが、小回りが利かなくなるので趣味ならこの辺はお好みでいいと思います。

おわりに

SQLだけでレシートのOCR ⇒ 情報の抽出が完結しました。また、差分更新も勝手にやってくれます。

宣言的に実装からデプロイまでできるので管理しやすいです。皆様のお仕事のお供のぜひぜひ

おわり

Databricks Zerobus Ingestでサーバレスでリアルタイムにデータを流し込みたかった

2026-04-04T00:00:00Z

はじめに

ついにDatabricksのZerobus IngestがGAとなりました。

Preview版ではデフォルトストレージは対応していないとありましたが、GAになったタイミングでその表示が消えたので、Databricks Free Editionで試してみることにしました。

テーブルの作成

Databricks上のテーブルからProtobufの定義を生成出来るようなので、まずはテーブルを作成します。

ここではひとまず私が必要そうなデータ型に絞ってテーブルを作成します。

CREATE OR REPLACE TABLE workspace.default.zerobus_sample (
    id INT,
    name STRING,
    create_at TIMESTAMP
);

Protobufの定義生成

テーブルを作成したら、テーブル定義からProtbufの定義を生成します。

Zerobus Ingest SDKに生成するためのツール（generate_files）があるので、それを使って生成します。

ツールはサービスプリンシパル経由で触りに行くタイプなので、サービスプリンシパルを作成してシークレットを生成しておきます。

また、テーブル定義も触りに行く必要があるので、サービスプリンシパルに権限を振るのを忘れないようにして下さい。（1敗）

ツールはRustを使って実装されているので、Rustの処理系をあらかじめインストールしておきます。あとは以下のコマンドで生成できます。

cargo run -- \
  --uc-endpoint "<your_uc_endpoint>" \
  --client-id "your-client-id" \
  --client-secret "your-client-secret" \
  --table "workspace.default.zerobus_sample"

クライアントの実装

今回はRustで書いていきます。

必要なライブラリは以下の通りなのですが、databricks-zerobus-ingest-sdkのprost系は0.13に依存しているので、prostだけは0.13を明示的に指定してインストールする必要があります。（1敗）

[dependencies]
# 必須
databricks-zerobus-ingest-sdk = "1.0.1"
prost = "0.13.5"
prost-types = "0.13.5"
tokio = { version = "1", features = ["full"] }
# お好みで
anyhow = "1"
chrono = "0.4"

あとは公式のサンプルをベースに簡単な書き込み処理を実装していきます。

use crate::samples::TableZerobusSample;
use databricks_zerobus_ingest_sdk::{
    ProtoMessage, StreamConfigurationOptions, TableProperties, ZerobusSdk, ZerobusStream,
};
use prost::Message;
use prost_types::{DescriptorProto, FileDescriptorSet};
use std::fs;

pub mod samples {
    include!("../output/zerobus_sample.rs");
}

const SERVER_ENDPOINT: &str = "<workspace id>.zerobus.<region>.cloud.databricks.com";
const DATABRICKS_WORKSPACE_URL: &str = "https://dbc-12345678-90ab.cloud.databricks.com";
const DATABRICKS_CLIENT_ID: &str = "00000000-0000-0000-0000-000000000000";
const DATABRICKS_CLIENT_SECRET: &str = "dose12345678901234567890123456789012";

#[tokio::main]
async fn main() -> anyhow::Result<()> {
    let descriptor_proto = load_descriptor(
        "output/zerobus_sample.descriptor",
        "zerobus_sample.proto",
        "table_zerobus_sample",
    );

    let table_properties = TableProperties {
        table_name: "workspace.default.zerobus_sample".to_string(),
        descriptor_proto: Some(descriptor_proto),
    };

    let stream_configuration_options = StreamConfigurationOptions {
        max_inflight_requests: 100,
        // RecordType::Proto is the default.
        ..Default::default()
    };

    let sdk_handle = ZerobusSdk::builder()
        .endpoint(SERVER_ENDPOINT)
        .unity_catalog_url(DATABRICKS_WORKSPACE_URL)
        .build()?;

    let mut stream = sdk_handle
        .create_stream(
            table_properties.clone(),
            DATABRICKS_CLIENT_ID.to_string(),
            DATABRICKS_CLIENT_SECRET.to_string(),
            Some(stream_configuration_options),
        )
        .await?;

    ingest_with_offset_api(&mut stream).await?;

    stream.close().await?;
    println!("Stream closed successfully");
    Ok(())
}

/// Recommended API: returns offset directly after queuing.
async fn ingest_with_offset_api(stream: &mut ZerobusStream) -> anyhow::Result<()> {
    println!("=== Offset-based API (Recommended) ===");

    let now = chrono::Utc::now().timestamp();

    // 1. Auto-encoding: ProtoMessage - pass message directly, SDK handles encoding.
    let order = TableZerobusSample {
        id: Some(1),
        name: Some("test".to_string()),
        create_at: Some(now),
    };

    let offset_id = stream.ingest_record_offset(ProtoMessage(order)).await?;
    println!("[Auto-encoding] Record sent with offset ID: {}", offset_id);
    stream.wait_for_offset(offset_id).await?;
    println!(
        "[Auto-encoding] Record acknowledged with offset ID: {}",
        offset_id
    );

    Ok(())
}

// Load descriptor from generated files
fn load_descriptor(path: &str, file: &str, msg: &str) -> DescriptorProto {
    let bytes = fs::read(path).expect("Failed to read descriptor");
    let file_set = FileDescriptorSet::decode(bytes.as_ref()).unwrap();

    let file_desc = file_set
        .file
        .into_iter()
        .find(|f| f.name.as_deref() == Some(file))
        .unwrap();

    file_desc
        .message_type
        .into_iter()
        .find(|m| m.name.as_deref() == Some(msg))
        .unwrap()
}

実装できたら早速実行してみましょう。

Unsupported table kind. Tables created in default storage are not supported. Error Code: 4024, Error State: 0.

無慈悲

おわりに

Zerobus Ingest connector limitations - Workspace and Target table

書いてある場所が移動しただけで、使えないんすね。

Free EditionでもS3を外部ロケーションとして登録してカタログをそっちに作成すれば使えるとは思いますが・・・

おわり

Hugging FaceのSentence TransformersモデルをUnity Catalogに登録してServing endpointsにデプロイしたい

2026-02-25T00:00:00Z

はじめに

大体タイトル通りです。

Databricksに最初から登録されている埋め込みモデルは英語のみで日本語に対応していないので、Serving endpointにデプロイするためにHugging Faceから好きなモデルを引っ張ってきてUnity Catalogに登録する方法を確認してみました。

ちなみにモデルを登録するだけなら以下のノートブックを使えば一発で登録できると思います。

🤗HFのモデルをUCに登録する君

環境のセットアップ

ノートブックにServerlessコンピュートをアタッチして、以下のライブラリをインストールします。

MLflowのSentence Transformersを使用したいため、mlflow[sentence-transformers]を指定してインストールします。

mlflow[sentence-transformers]==3.9.0
sentence-transformers==5.2.3

今回はConfigurationのDependenciesから追加しましたが、たぶん%pipコマンドを使ってインストールしてdbutils.library.restartPython()しても良いと思います。

モデル名の入力とかスキーマの作成とか

このノートブックでは登録先のカタログ名とHugging Faceのモデル名をWidgetから受け付けます。

dbutils.widgets.text("uc_catalog_name", "", "UC Catalog name")
dbutils.widgets.text("hf_model_name", "", "Hugging Face Model name")

登録先のスキーマ名とモデル名は入力されたHugging Faceモデルから組み立てています。

UC_CATALOG_NAME = dbutils.widgets.get("uc_catalog_name")
HF_MODEL_NAME = dbutils.widgets.get("hf_model_name")
UC_SCHEMA_NAME = HF_MODEL_NAME.split("/")[0].replace("-", "_").replace(".", "_")
UC_MODEL_NAME = HF_MODEL_NAME.split("/")[1].replace("-", "_").replace(".", "_")

そうしたら登録先のスキーマを作成しておきます。

spark.sql(f"CREATE SCHEMA IF NOT EXISTS {UC_CATALOG_NAME}.{UC_SCHEMA_NAME}")

MLflowへのモデルのロギング

Sentence Transformers経由でHugging Faceのモデルを取得し、MLflowのSentence Transformersフレーバーを使用してモデルをロギングします。

import mlflow
from sentence_transformers import SentenceTransformer

mlflow.set_registry_uri("databricks-uc")

model = SentenceTransformer(HF_MODEL_NAME)

input_example = [
    "RFC 1034とRFC 1035は、Domain Name System（DNS）の基礎を定義する最も重要な仕様である。",
    "Paul Mockapetrisによって1987年に策定され、インターネットにおける名前解決の仕組み全体を規定している。",
]

with mlflow.start_run():
    model_info = mlflow.sentence_transformers.log_model(
        model=model,
        name=UC_MODEL_NAME,
        input_example=input_example,
    )

ロギングされたモデルにはモデルの実行に必要なライブラリが含まれるのですが、たまに必要な依存関係が足りずにServing endpointsへのデプロイに失敗することがあるので、事前に一度モデルが動作することを確認します。

大体10分位掛かるので、気長に待ちましょう。

mlflow.models.predict(
    model_uri=model_info.model_uri,
    input_data=input_example,
)

Unity Catalogへの登録

モデルが正常に動作することが確認出来たらUnity Catalogへ登録して完了です。

mlflow.register_model(
    model_info.model_uri, f"{UC_CATALOG_NAME}.{UC_SCHEMA_NAME}.{UC_MODEL_NAME}"
)

おわり

Databricksのread_files関数でもExcelファイルを読み込みたい

2026-01-17T00:00:00Z

2月8日追記

現時点ではフリガナ問題は解決しています。

また、より大きいファイルでも取り込めるようになっていました。ですが、調子に乗って大きなサイズを放り込むと処理が終わらないので、その辺はいい感じにする必要があります。

注意事項

本検証は2026年1月17時点の内容で検証しています。リリース版は挙動が異なる場合があります。

また、Databricks Free Editionで評価しています。そのため、商用版と挙動が異なる場合があります。

はじめに

Databricksのread_files関数はCSVやJSONフォーマットをいい感じに読み込んでくれる関数です。そのread_files関数がExcelファイルの読み込みをサポートしました。

ですが、Excelフォーマットをプログラムで扱う際のトラップに悩まされてきた生産性アプリケーション開発者も多いのではないでしょうか。

そこで、今回はトラップになりそうな部分の評価を行ってみました。

Office Open XMLフォーマット

今回はExcelフォーマットのうち、Office Open XMLフォーマット（xlsx）を評価してみます。そのOOXMLフォーマットのうち、今回の検証で触れる内容について軽く解説をしていきます。

OOXMLはXMLの名前がついている通り、主にzipで圧縮されたXMLファイルで構成されています。

たとえば、以下のようなExcelファイルをzip展開すると、以下のような構造となっています。

example.xlsx
│
│  [Content_Types].xml
│
├─docProps
│      app.xml
│      core.xml
│
├─xl
│  │  sharedStrings.xml
│  │  styles.xml
│  │  workbook.xml
│  │
│  ├─printerSettings
│  │      printerSettings1.bin
│  │
│  ├─theme
│  │      theme1.xml
│  │
│  ├─worksheets
│  │  │  sheet1.xml
│  │  │
│  │  └─_rels
│  │          sheet1.xml.rels
│  │
│  └─_rels
│          workbook.xml.rels
│
└─_rels
        .rels

そのうち、内容を確認する際に見るのが以下の二つのファイルになります。

`xl\worksheets\sheet1.xml`

xl\worksheets以下にはシート毎にシートの内容が含まれているXMLファイルが格納されています。

上記の例だと、こんな感じに内容になるはずです。

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<worksheet xmlns="http://schemas.openxmlformats.org/spreadsheetml/2006/main"
    xmlns:r="http://schemas.openxmlformats.org/officeDocument/2006/relationships"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    mc:Ignorable="x14ac xr xr2 xr3"
    xmlns:x14ac="http://schemas.microsoft.com/office/spreadsheetml/2009/9/ac"
    xmlns:xr="http://schemas.microsoft.com/office/spreadsheetml/2014/revision"
    xmlns:xr2="http://schemas.microsoft.com/office/spreadsheetml/2015/revision2"
    xmlns:xr3="http://schemas.microsoft.com/office/spreadsheetml/2016/revision3"
    xr:uid="{00000000-0001-0000-0000-000000000000}">
    <dimension ref="A1:B2" />
    <sheetViews>
        <sheetView tabSelected="1" workbookViewId="0" />
    </sheetViews>
    <sheetFormatPr defaultRowHeight="18.75" />
    <sheetData>
        <row r="1" spans="1:2">
            <c r="A1" t="s">
                <v>0</v>
            </c>
        </row>
        <row r="2" spans="1:2">
            <c r="B2" t="s">
                <v>1</v>
            </c>
        </row>
    </sheetData>
    <phoneticPr fontId="1" />
    <pageMargins left="0.7" right="0.7" top="0.75" bottom="0.75" header="0.3" footer="0.3" />
    <pageSetup paperSize="9" orientation="portrait" r:id="rId1" />
</worksheet>

A1とB2セルにデータが含まれているのが分かりますね。ですが、謎の数字0と1があるだけで、内容は特には記述されていません。

テキスト情報はどこに行ったのでしょう？

その答えはShared String Table（SST、sharedStrings.xml）の中にあります。

`xl\sharedStrings.xml`

SSTはその名の通り、複数の場所から参照されるテキスト情報を格納するためテーブルです。

上記の例だとシートはSSTのインデックス番号を参照していたことになります。

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<sst xmlns="http://schemas.openxmlformats.org/spreadsheetml/2006/main" count="2" uniqueCount="2">
    <si>
        <t>Hello Excel</t>
        <phoneticPr fontId="1" />
    </si>
    <si>
        <t>こんにちはExcel</t>
        <phoneticPr fontId="1" />
    </si>
</sst>

なお、文字情報は必ずSSTに格納しなければならない訳ではなく、Excelを出力するライブラリはシートのXMLに直接文字を格納する場合が多いです。

Excelファイルの読み込み

というわけで、Excelの深淵を覗く準備ができたところでread_files関数でファイルを読み込んでみましょう。

単純な例

以下のような単純なExcelファイルを用意します。

最低限のオプションだけ設定すると以下のように出力されます。

SELECT
  *
FROM
  read_files(
    "/Volumes/excel_read_files/default/files/01_simple_files.xlsx",
    format => "excel",
    schemaEvolutionMode => "none"
  )

スキーマを推論してくれるので、日付や数字もそれぞれの型として認識してくれています。

ですが、小数が少し怪しいですね。内部的にはこの形で格納されているので、read_files関数が悪いわけではなさそうです。

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<worksheet>
    <sheetData>
        <row r="1" spans="1:4">
            <c r="C1">
                <v>1.1000000000000001</v>
            </c>
        </row>
        <row r="2" spans="1:4">
            <c r="C2">
                <v>2.2000000000000002</v>
            </c>
        </row>
        <row r="3" spans="1:4">
            <c r="C3">
                <v>3.3</v>
            </c>
        </row>
        <row r="4" spans="1:4">
            <c r="C4">
                <v>4.4000000000000004</v>
            </c>
        </row>
        <row r="5" spans="1:4">
            <c r="C5">
                <v>5.5</v>
            </c>
        </row>
    </sheetData>
</worksheet>

型が既知なのであれば、あらかじめスキーマヒントを与えておいたほうが良いかもしれません。

SELECT
  *
FROM
  read_files(
    "/Volumes/excel_read_files/default/files/01_simple_files.xlsx",
    format => "excel",
    schemaEvolutionMode => "none",
    schemaHints => "_c2 decimal(5,1)"
  )

ちなみに、inferColumnTypesはExcel読み込みでは考慮されないようです。

SELECT
  *
FROM
  read_files(
    "/Volumes/excel_read_files/default/files/01_simple_files.xlsx",
    format => "excel",
    schemaEvolutionMode => "none",
    inferColumnTypes => false
  )

スキーマヒントを与えて強制的に文字列とすると、to_stringをしたような形式になります。

また、日付はMM/DD/YY形式になります。USロケールなのかもしれません。

SELECT
  *
FROM
  read_files(
    "/Volumes/excel_read_files/default/files/01_simple_files.xlsx",
    format => "excel",
    schemaEvolutionMode => "none",
    schemaHints => "_c1 string, _c2 string, _c3 string"
  )

日本語を含む例

次はよくオフィスで流通していそうなファイルを読み込んでみます。

今回の検証で初めて知ったのですが、Excelは変換時の元テキストをフリガナとして格納してくれるっぽいです。

関係ないセルを読まないよう、dataAddressで読み込む場所を明示してあげます。

SELECT
  *
FROM
  read_files(
    "/Volumes/excel_read_files/default/files/02_日本語を含むファイル.xlsx",
    dataAddress => "'お供　給与表'!B2:C5",
    headerRows => 1,
    format => "excel",
    schemaEvolutionMode => "none"
  )

良くないですね。 フリガナも拾ってきてしまっています。

少なくとも日本語だと意図してフリガナを拾ってほしいケースはあまりないと思うので、GAまでにフリガナを拾わないか、オプションで選択出来るようになるといいなと思います。

ちなみに、この例だとSSTはこのようになっています。シート名として入力したテキストもフォネティックを拾っているとは思いませんでした。

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<sst xmlns="http://schemas.openxmlformats.org/spreadsheetml/2006/main" count="8" uniqueCount="8">
    <si>
        <t>お供</t>
        <rPh sb="1" eb="2">
            <t>トモ</t>
        </rPh>
        <phoneticPr fontId="1" />
    </si>
    <si>
        <t>きび団子支給数</t>
        <rPh sb="2" eb="4">
            <t>ダンゴ</t>
        </rPh>
        <rPh sb="4" eb="7">
            <t>シキュウスウ</t>
        </rPh>
        <phoneticPr fontId="1" />
    </si>
    <si>
        <t>猿</t>
        <rPh sb="0" eb="1">
            <t>サル</t>
        </rPh>
        <phoneticPr fontId="1" />
    </si>
    <si>
        <t>犬</t>
        <rPh sb="0" eb="1">
            <t>イヌ</t>
        </rPh>
        <phoneticPr fontId="1" />
    </si>
    <si>
        <t>雉</t>
        <rPh sb="0" eb="1">
            <t>キジ</t>
        </rPh>
        <phoneticPr fontId="1" />
    </si>
    <si>
        <t>令和8年1月17日改定</t>
        <rPh sb="0" eb="2">
            <t>レイワ</t>
        </rPh>
        <rPh sb="3" eb="4">
            <t>ネン</t>
        </rPh>
        <rPh sb="5" eb="6">
            <t>ガツ</t>
        </rPh>
        <rPh sb="8" eb="9">
            <t>ニチ</t>
        </rPh>
        <rPh sb="9" eb="11">
            <t>カイテイ</t>
        </rPh>
        <phoneticPr fontId="1" />
    </si>
    <si>
        <t>※変更時はおじいさんとおばあさんの承認を得ること</t>
        <rPh sb="1" eb="4">
            <t>ヘンコウジ</t>
        </rPh>
        <rPh sb="17" eb="19">
            <t>ショウニン</t>
        </rPh>
        <rPh sb="20" eb="21">
            <t>エ</t>
        </rPh>
        <phoneticPr fontId="1" />
    </si>
    <si>
        <t>全然関係ないデータ</t>
        <rPh sb="0" eb="4">
            <t>ゼンゼンカンケイ</t>
        </rPh>
        <phoneticPr fontId="1" />
    </si>
</sst>

手動でフリガナを消してあげると意図した感じに取り込んでくれます。

ただし、手動で消すのは結構めんどくさいので、前処理でフリガナを消すプログラムを動かすとかでしょうか・・・

SELECT
  *
FROM
  read_files(
    "/Volumes/excel_read_files/default/files/03_日本語を含むファイル_フリガナ除去.xlsx",
    dataAddress => "'お供　給与表'!B2:C5",
    headerRows => 1,
    format => "excel",
    schemaEvolutionMode => "none"
  )

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<sst xmlns="http://schemas.openxmlformats.org/spreadsheetml/2006/main" count="8" uniqueCount="8">
    <si>
        <t>令和8年1月17日改定</t>
        <rPh sb="0" eb="2">
            <t>レイワ</t>
        </rPh>
        <rPh sb="3" eb="4">
            <t>ネン</t>
        </rPh>
        <rPh sb="5" eb="6">
            <t>ガツ</t>
        </rPh>
        <rPh sb="8" eb="9">
            <t>ニチ</t>
        </rPh>
        <rPh sb="9" eb="11">
            <t>カイテイ</t>
        </rPh>
        <phoneticPr fontId="1" />
    </si>
    <si>
        <t>※変更時はおじいさんとおばあさんの承認を得ること</t>
        <rPh sb="1" eb="4">
            <t>ヘンコウジ</t>
        </rPh>
        <rPh sb="17" eb="19">
            <t>ショウニン</t>
        </rPh>
        <rPh sb="20" eb="21">
            <t>エ</t>
        </rPh>
        <phoneticPr fontId="1" />
    </si>
    <si>
        <t>全然関係ないデータ</t>
        <rPh sb="0" eb="4">
            <t>ゼンゼンカンケイ</t>
        </rPh>
        <phoneticPr fontId="1" />
    </si>
    <si>
        <t>お供</t>
        <phoneticPr fontId="1" />
    </si>
    <si>
        <t>きび団子支給数</t>
        <phoneticPr fontId="1" />
    </si>
    <si>
        <t>猿</t>
        <phoneticPr fontId="1" />
    </si>
    <si>
        <t>犬</t>
        <phoneticPr fontId="1" />
    </si>
    <si>
        <t>雉</t>
        <phoneticPr fontId="1" />
    </si>
</sst>

計算式を含む例

次は式を含むExcelファイルを読み込ませてみます。

ドキュメントページでは評価された数式を取り込みますとありますが、どのような意味なのでしょうか。

SELECT
  *
FROM
  read_files(
    "/Volumes/excel_read_files/default/files/04_formula.xlsx",
    format => "excel",
    schemaEvolutionMode => "none"
  )

エクセルで数式セルを作成すると、内部的には数式と共に計算済みの値が格納されています。ドキュメントの「評価された数式を取り込みます」とはおそらく内部的に保持されている計算済みの値を取り込むということを言っているのだと思われます。

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<worksheet>
    <sheetData>
        <row r="1" spans="1:3">
            <c r="A1">
                <v>1</v>
            </c>
            <c r="B1">
                <v>2</v>
            </c>
            <c r="C1">
                <f>A1+B1</f>
                <v>3</v>
            </c>
        </row>
    </sheetData>
</worksheet>

では、計算済みの値が格納されないケースがあるのでしょうか。

全部のケースを確認した訳ではありませんが、ライブラリを使用してExcelファイルをプログラムから作成する場合は数式のみが格納されて計算済みの値が格納されない場合が多いです。

たとえば、以下のようなコードを使用して上記のExcelと同じようなファイルを作成したとします。

import openpyxl


def main():
    wb = openpyxl.Workbook()
    sheet = wb.active

    for it in range(1, 5):
        sheet.cell(it, 1).value = it
        sheet.cell(it, 2).value = it + 1
        sheet.cell(it, 3).value = f"=A{it}+B{it}"

    wb.save("05_formula_no_value.xlsx")


if __name__ == "__main__":
    main()

Excelで開くと未計算のセルは計算されて表示されますが、read_files関数では計算済みの値が無いため、正しく取得できていません。

SELECT
  *
FROM
  read_files(
    "/Volumes/excel_read_files/default/files/05_formula_no_value.xlsx",
    format => "excel",
    schemaEvolutionMode => "none"
  )

複数のファイル

問題ないとは思いますが、念のため複数のファイルの読み込みを試してみます。

以下のようなコードで100行×100ファイルのExcelを生成して読み込んでみます。

import random
import string

import openpyxl


def randomname(n):
    return "".join(random.choices(string.ascii_letters + string.digits, k=n))


def main():
    for i in range(1, 101):
        print(f"06_excel_files\\book_{i:0>3}.xlsx")
        wb = openpyxl.Workbook()
        sheet = wb.active

        for r in range(1, 101):
            sheet.cell(r, 1).value = i
            sheet.cell(r, 2).value = r

            for c in range(3, 6):
                sheet.cell(r, c).value = randomname(10)

            for c in range(6, 9):
                sheet.cell(r, c).value = random.randint(0, 100)

        wb.save(f"06_excel_files\\book_{i:0>3}.xlsx")


if __name__ == "__main__":
    main()

SELECT
  *
FROM
  read_files(
    "/Volumes/excel_read_files/default/files/06_excel_files/",
    format => "excel",
    schemaEvolutionMode => "none"
  )

良さそうですね。

サイズの大きいファイル

JavaでExcelを読み書きする代表的なライブラリと言えばApache POIがあります。

POIはUser API（Excelファイルをインメモリで展開するAPI）で巨大なファイルを扱おうとするとOOMでプログラムが爆散するという悲しき事故が発生しがちです。

SparkはScala、すなわちJVMで動作するので同じ事故が発生するか否かは割と気になりますよね。

以下のようなコードでそれぞれの行数を持つExcelファイルを作って、順番に読み込ませてみます。

import random
import string

import openpyxl

ROWS = [
    10000,
    10100,
    10101,
    10102,
    10103,
    10104,
    10105,
    10106,
    10107,
    10108,
    10109,
    10110,
    10120,
    10130,
    10140,
    10150,
    10160,
    10170,
    10180,
    10190,
    10200,
    10300,
    10400,
    10500,
    11000,
]


def randomname(n):
    return "".join(random.choices(string.ascii_letters + string.digits, k=n))


def main():
    for row_count in ROWS:
        print(f"07_large_excel_files\\book_{row_count}.xlsx")
        wb = openpyxl.Workbook()
        sheet = wb.active

        for r in range(1, row_count + 1):
            sheet.cell(r, 1).value = row_count
            sheet.cell(r, 2).value = r

            for c in range(3, 6):
                sheet.cell(r, c).value = randomname(10)

            for c in range(6, 9):
                sheet.cell(r, c).value = random.randint(0, 100)

        wb.save(f"07_large_excel_files\\book_{row_count}.xlsx")


if __name__ == "__main__":
    main()

詳細は省きますが、私の環境では10102行のファイルまでなら読み込んでくれましたが、10103行のファイルからは関数が返ってこなくなりました。

関数の内部的な制限に引っかかったのか、それともDatabricks Free Editionのなんらかのレートリミットに引っかかったのかは分かりませんが、あまり大量の行数を有するファイルの読み込みには向かないようです。

おわりに

いくつか気になる点はありましたが、ベータ版の機能なのでGAまでには修正されると思います。

Pythonでロジックを書かなくてもいい感じにExcelファイルが読み込めると、ファイルサーバ内に眠っているExcelファイルのデータの利活用のハードルも低くなると思います。

GAが待ち遠しい機能ですね。

jyuch / excel-read-files

余談

ファイルをドラッグアンドドロップでテーブルを作れる機能も内部的にread_files関数を使っているのか、現時点では同様に日本語のフリガナを拾ってしまいます。

こちらも解決済みです。やったぜ

おわり

2025年の振り返りとか

2025-12-31T00:00:00Z

はじめに

2025年の振り返りです。

Databricks

今年はお仕事でDatabricksをかなり触ってきました。

特にDatabricksの環境を完全にゼロから（新規契約のAWSアカウントから）構築するのはあまりない経験だと思うので、珍しい経験が出来たなと思います。

他にも基幹システムからのデータ取り込みやデータ加工パイプラインの構築・ガバナンス設計など~~運用の全部を一人でやらさせられてる~~大変貴重な経験を積ませていただいており大変うれしく思います。

個人的にはDatabricksは少なくとも数年はデータとAI領域でのトップを走るプロダクトだと思っているので、しばらくはDababricksのお仕事を続けたいなとは思ってます。

生成AI

データ基盤を触っているとAI絡みのお話を頂くので、RAGやプロンプト自動最適化などのテクノロジはちょこちょこと触っていました。特にDSPyとMLflowはかなり注目しているので、2026年もこれらのプロダクトを追いかけたいと思っています。

ただ、AIエージェントは技術的な領域としては面白いのですが、全社的なワークロードを動かしたときの性能面・コスト面の監視や基幹システムとの連接など考えないといけないことが多いなと現時点でも感じています。 2026年はこの辺の本格的な開発・運用が始まりそうなので2026年はつらみポイントが高い年になりそうです。

この辺を真面目にやろうとすると事業会社の内部でどうこう出来るレベルを超えそうと思っているのですが、皆さんどう考えてるんでしょうね？

資格とか

今年はネットワークスペシャリスト試験とSAAの2つを合格・取得できました。

ネットワークスペシャリスト試験で勉強した内容は普通に日常の業務~~やテキトーなことを吹っ掛けてくる自称有識者をボコすの~~に役に立つので、ネットワークに触る人はみんな勉強すると良いと思います。

IPAの試験体系が改定されて高度試験が消える前にデータベーススペシャリストもとっておこうかなと思ってます。セキュリティスペシャリストはどうなるんでしょうね？あれだけ体系が違うっぽいので残る気がしますが。

AWS系の資格について特にコンプとかは考えていないのですが、SAPを持ってると貰えるお小遣いが増えるので受けてもいいかなと思っています。まぁ、弊社は全体的に資格難易度と金額が明らかに乖離しているのでにゃーん（社会性フィルタ）

また、Databricks Certified Data Engineer Associateとかはあまり難しくなさそうなので試しに取ってみたいなとは思ってるのですが、受験料がｸｯｿ高いのと、弊社内でお小遣いが貰える資格ではないのでちょっと迷ってます。

コミュニティ

東京に勤務することになってから今年はDatabricksのユーザグループであるJEDAIのミートアップから始まり、結構な数の勉強会やもくもく会にお邪魔させていただきました。

とくにIbaraki.devにおかれましては、いきなりDNSの話をし始めたり誰も使ってないDNSのライブラリの話をし始めたりと大変ご迷惑をお掛けしました。

いろんな人と交流するとそれぞれの組織の考え方が分かったり、どんな組織でも大体似たようなことで悩んでるんだなというのが分かって楽しいですね。

おわりに

2026年も飛躍の年にしたいですね。

おわり