止めるまでの待ちを1分から10分にすると、立ち上げに当たる件数は67.8%から1.9%になりました。
同時に起動していた時間が66.4時間から198.1時間へ、3.0倍に増えます。
利用者は待ち時間を意識しません。そのぶん、止めるまでの待ちの設定が費用を決めます。
Databricksでは、管理者が計算のまとまりを整えます。公式は管理者は大きさを変えられる計算のまとまりをSQLの倉庫として整えるので、利用者はクラウドを扱う面倒を管理せずに問い合わせを走らせられると述べています。
面倒を引き受ける側は、止める設定を決めます。実際に流して数えました。
20日ぶん・問い合わせ 4,800件（平日の日中に寄せてある）
止まっているときの立ち上げに 240秒かかる。何分あいたら止めるかを変える
止めるまでの待ち 起動していた時間 1件あたりの起動時間 立ち上げに当たった件数 割合
1分 66.4時間 49.8秒 3256件 67.8%
5分 174.1時間 130.6秒 659件 13.7%
10分 198.1時間 148.6秒 91件 1.9%
30分 208.2時間 156.1秒 20件 0.4%
60分 218.2時間 163.6秒 20件 0.4%
120分 238.2時間 178.6秒 20件 0.4%
1分で止めると3分の2以上が立ち上げに当たります。67.8%が4分待たされる計算です。
10分にすれば1.9%まで下がります。そのかわり起動時間が66.4時間から198.1時間になりました。
30分・60分・120分は、どれも20件です。20日ぶんなので、1日1回の立ち上げまで減っています。
それでも起動時間は208.2時間から238.2時間へ増え続けます。効果は止まり、費用だけが伸びます。
同じ形はCloud Runの記事でも扱っていて、まばらな流量ほどこの設定が効きます。
10分で立ち上げはほぼ消える。それ以上は費用だけが伸びる。
Administrators configure scalable compute clusters as SQL warehouses, so end users can run queries without managing the complexities of working in the cloud.原文Databricks ドキュメント「What is Databricks?」 この内容の有効期限2027-02-18
権限を1か所で扱えます。それでも配った分は積み上がるので、外す仕組みが要ります。
Databricksでは、権限の扱いを1つの形にまとめられます。公式はUnity Catalogは、データの湖と倉庫を合わせた形に対して、統一された統治の仕組みを提供すると述べています。
1か所で扱えても、配った分は残ります。どれだけ積むのか実際に数えてみました。
人 400名・対象 3,000件。毎月 260件の権限が新しく配られる
配られた権限のうち、実際に使われるのは 22%とした。24か月ぶんを見る
棚卸しの間隔 月ごとの平均で見た残り 使われていない権限 その割合 棚卸しで外した件数
しない 3,250件 2,555件 78.6% 0件
3か月ごと 1,144件 400件 35.0% 4,807件
6か月ごと 1,436件 716件 49.9% 4,881件
12か月ごと 2,026件 1,326件 65.4% 4,876件
棚卸しをしないと、78.6%が使われないままの権限になります。漏れたときの範囲がそのまま広がります。
3か月ごとに外せば35.0%です。それでも3件に1件は使われていません。
右端を見ると、3か月・6か月・12か月で4,807件・4,881件・4,876件です。ほぼ同じでした。
つまり間隔を短くしても作業量は減りません。変わるのは、使われない権限が残っている時間の長さです。
この判断の形はアクセスレビューの記事でも扱いました。
Unity Catalog provides a unified data governance model for the data lakehouse.原文Databricks ドキュメント「What is Databricks?」 この内容の有効期限2027-02-18
湖に置いたまま倉庫のように読めます。ただし読む量は、選んだ項目の数で決まります。
Databricksが土台にするのは、湖と倉庫を合わせた形です。公式はデータの湖と倉庫を合わせた形は、企業のデータ倉庫とデータの湖を組み合わせ、企業のデータの解決を速く、簡単に、ひとつにすると述べています。
倉庫のように読める利点は、書き方しだいで消えます。実際に読んで測りました。
表 200,000行・1行あたり 12項目（1項目 4バイト） 集計に使う項目の数を変えて、読む量を見る 使う項目 行ごとに持つ形 列ごとに持つ形 比 1個 9.2MB 0.8MB 12.0倍 2個 9.2MB 1.5MB 6.0倍 3個 9.2MB 2.3MB 4.0倍 6個 9.2MB 4.6MB 2.0倍 12個 9.2MB 9.2MB 1.0倍
1項目だけなら12.0倍の差です。12項目すべてを使えば1.0倍になります。
つまり全項目を選ぶ書き方では、湖に置いたままで速く読める利点がそのまま消えます。
読む量が増えれば、その分だけ計算のまとまりが動きます。最初の節の起動時間にそのまま乗ります。
だから費用を下げる手は2つあります。止める設定を詰めるか、読む量を減らすかです。後者のほうが効き方は大きくなります。
3つの計測はいずれも手元で書いた模型で、実際のDatabricksを動かしたものではありません。立ち上げ240秒、権限の22%が使われるといった値はすべて置いたものです。問い合わせの到着も平日の日中に寄せた形で作っており、実際の分布とは違います。読む量は項目の数からの計算で、圧縮の効きは含めていません。ここで見せているのは、止めるまでの待ちを延ばす効果は10分あたりで止まるという点と、棚卸しの間隔を変えても外す総数は変わらないという点の2つです。
The data lakehouse combines enterprise data warehouses and data lakes to accelerate, simplify, and unify enterprise data solutions.原文Databricks ドキュメント「What is Databricks?」 この内容の有効期限2027-02-18
同じ課題を持つ会社にとって、動いている設定は「作る時間」を買えるということです。ServiceDockは自作のワークフローやテンプレートを出品できるマーケットプレイスです。手数料や出品の流れは出品者向けページにまとまっています。
出品の仕組みを見る