導入
Databricks AWS Tokyoリージョンにおいて、サーバレスSQLウェアハウスが提供開始されました。
SQLウェアハウスはDatabricksにおいてデータウェアハウスの中核を担う仕組であり、そのサーバレス機能がAWS東京リージョンにやってきました。
(↓利用における失敗(?)談)
個人的に待望の機能であり、合わせてDatabricks SQLの学び直しも始めているのですが、サーバレスSQLウェアハウスによってどこで何が良くなるんだろうと疑問に思ったので、関連するサービスとその影響の個人的見解を書き出してみます。
かなり個人の主観や駄々洩れの欲望が入っていますのご注意ください。
あくまで一人のDatabricksユーザとしての意見です。
また、AWS上のDatabricksについて述べています。
Azureだと状況が異なるかもしれません。
その前に
そもそものDatabricks SQLウェアハウスの種類について、おさらいしておきます。
以下より抜粋。
Databricks SQL では、次の種類の SQLウェアハウスがサポートされています。
- サーバーレス
- Pro
- クラシック
SQLウェアハウスの種類ごとに、パフォーマンス機能が異なります。 次の表は、各 SQLウェアハウスの種類でサポートされるパフォーマンス機能を示しています。
Photon エンジン |
予測IO |
インテリジェントなワークロード管理 |
|
|---|---|---|---|
サーバーレス |
X |
X |
X |
Pro |
X |
X |
|
クラシック |
X |
次の一覧では、各パフォーマンス機能について説明します。
Photon: Databricksのネイティブベクトル化クエリエンジン。これにより、既存の SQL および DataFrame API 呼び出しが高速化され、ワークロードあたりの総コストが削減されます。
予測 IO: SQL クエリでの選択的スキャン操作を高速化するための一連の機能。予測 IO は、さまざまな高速化を提供できます。
インテリジェント ワークロード管理 (IWM): 多数のクエリを迅速かつコスト効率よく処理する Databricks SQL Serverless の機能を強化する一連の機能。IWMは、AIを活用した予測と動的管理技術を使用して、ワークロードに適切な量のリソースを迅速に確保します。主な違いは、静的なしきい値を使用するのではなく、ワークロードの要求に動的に応答する Databricks SQL の AI 機能にあります。
というわけで、もともとクラシック->Pro->サーバレスの順にパフォーマンスに関する機能が増えていきます。
正直データ量がそこまで多くない領域においてはクラシックでも十分なパフォーマンスが出ているのですが、サーバレスになるとより高速なパフォーマンス、かつ柔軟なオートスケールが実現できるようです。
とはいえ、性能の増加と合わせて単価も上がります。
以下が2024年3月現在のウェアハウス種類別DBU単価です。（DBUはDatabricksの使用リソース単位）
また、Enterpriseプランのプライスを出していますが、Premiumでも同価格でした。
ただ、価格比較において、サーバレスの価格はAWSのインスタンス費用も含むところに注意が必要です。
クラシック・Proは自前のAWSアカウント下でEC2インスタンスを起動するため、その分のコストを追加で見る必要がありますが、サーバレスはDatabricksアカウント下のEC2インスタンスを使用している(たぶん)ため、自AWSアカウント側のコストはかからなくなります。
これを考えるとProと価格差ほとんど無い気がします（厳密に試算してないけど）し、利便性考えるとサーバレス使っといたらいいじゃん、と感じています。
サーバレスの恩恵を受けづらいワークロード（あまり大量データを扱わず、しかし常時起動しておかなければならない）の場合は従来通りクラシックで、それ以外はサーバレスという使い分けでいいんじゃないかと思います。
ただし、自社のセキュリティポリシーで使えないというケースや、サーバレスは外部Hiveメタストアが使えないなどの制約もあるので、そこは注意が必要です。
ただ、みんなUnity Catalogに移行すると幸せになれると思うよ。マジで。
では、サーバレスSQLウェアハウスの導入によって影響を受けるサービスと影響内容を考察してみます。
その1: Databricks SQL関連(SQLエディタ・クエリー・ダッシュボード・アラート)
Databricks SQLの主要サービス群であるクエリー・ダッシュボード・アラートはサーバレスSQLウェアハウスによってかなり体験が変わります。
SQLエディタ
これまでは開発用やデータ確認用にクエリを書く際は3分程度スピンアップを待ってから行っていました。
だいたいコードを書き終わってから一息つくころに、ようやく実行可能になる感じ。
また、SQLエディタ上でのコード補完も、テーブル名などはウェアハウス起動中でないと補完されないケースがあり、ウェアハウスの起動待ちで結構ストレスを感じていました。
それが、数秒待ち時間がかかるとはいえ、ほぼ待ち時間無しで行えるのはエンジニアとしてとても嬉しい。
クエリー/ダッシュボード
Databricksのクエリー/ダッシュボードは軽量で必要最低限の機能が提供されているいいサービスだと思うのですが、個人的にビジネスユーザへの提供に踏み出せていませんでした。
理由としては、
- コスト低減を狙ってオンデマンドでウェアハウスを立上げる運用をする場合、ユーザ体験を著しく損なう（間違いなく使われなくなる）
- ユーザ体験を上げようと思うと起動し続ける必要があるが、コストが・・・。
という(よくある)ジレンマです。
そのため、この領域のバックエンドは競合サービスを活用していたのですが、サーバレスSQLウェアハウスによってようやくこのジレンマを解消できそうです。
とはいえ待ち時間が無いわけでは無いので、スピンアップ時のレイテンシはもっと短くなって欲しいなと思っています。人間の欲望は尽きることがないなあ。
アラート
アラートのスケジュールについて、サーバレスSQLウェアハウスを利用することでスピンアップタイムをあまり加味する必要が無くなりました。
これまでは（常時起動のウェアハウスを使わない場合）ウェアハウスの起動時間を加味してスケジュールを考慮することをしていましたが、そこをあまり気にしなくて済むようになったのは地味に大きい。
その2: カタログエクスプローラ
何気にこれの使い勝手向上が個人的に一番大きいかもしれません。
ちょっとデータのプレビューが見たいとき、でも使えるクラスタが起動してないとき、というのは個人的によくあります。
そんなときに分単位で待つ必要がないのはかなりストレス軽減になります。
（また、最短5分で自動終了する設定ができるので、手動終了させなくてもそれなりにお財布に優しい）
また、SQLウェアハウスはDatabricksのデータオブジェクトの閲覧に制限が(ほとんど?)ないため、サーバレスだと使いやすいです。
例えば、Unity Catalog対応のDelta Live Tablesを利用すると、通常のテーブルやビューではなく、マテリアライズドビューなどが作らます。
これは、2024年3月現在、シングルユーザモードのクラスタでは利用することができないという制限があります。
シングルユーザモードのクラスタは起動してるけど、マテリアライズドビューのデータをプレビューしたい・・・という経験が実際にあるので、それらをすぐに実行できるサーバレスSQLはありがたいです。
一方、マテリアライズドビューに関する制限については、Databricks社に早くこの制限解消を実施して欲しいと願っています。
その3: ノートブック
ノートブックのコンピュートリソースとして、サーバレスSQLウェアハウスを利用することができます。（ただし、言語=SQLのみ）
自分はPythonもSQLもノートブックで書くことが多いのですが、SQLだけとはいえノートブックでも気軽に開発作業を行えるのは助かります。開発体験大事。
その4: ワークフロー
SQLのタスクに限りますが、ワークフローのクラスタにもSQLウェアハウスの指定が可能です。
サーバレスSQLウェアハウスを利用することでジョブ実行の起動時間が短縮し、またスケジュール設定の起動待ち時間の考慮を緩和することができます。
サーバレスDelta Live Tablesも早く来て欲しい。。。
その5: 外部ツールからの利用
TableauやPowerBIのような外部ツールからの接続において、サーバレスSQLウェアハウスの導入は効果的です。
私は実際にPowerBIとの接続をよく利用しますが、特に開発においてSQLウェアハウスの起動時間はやはりストレスでした。また、PowerBI Serviceを使ったダッシュボード公開においてもSQLウェアハウスのスピンアップ時間を気にしないといけないケースがありましたので、このあたりの体験が向上するのは非常にありがたいです。
他、Databricks SQL CLI経由でSQLを実行するといったケースでも同様にメリットがあるかと思います。
おわりに
サーバレスSQLウェアハウスが関係するサービスをいろいろ挙げてみました。
他にもAPI関連など影響するサービスが多々あると思いますが、さすがに挙げきれないのでこんなところで。
派手な機能ではないかもしれませんが、様々な体験が変わる重要なアップデートだと思います。
ただ、たまにサーバレスSQLウェアハウスの起動時に以下のようなエラーに遭遇します。
今後の改善・安定化を期待しています。
しかし、繰り返しになりますが、サーバレスSQLウェアハウスは個人的にかなり待ち望んでいた機能の一つでして、ようやく来たなーという感じです。
Databricks社の方々には、この調子で米国にて実装されているサービスを日本でも早期に展開いただくことを期待しています。
Model Servingとか。Model Servingとか。Lakehouse Appとか。Model Servingとか。VectorSearchとか。Model Servingとか。（くどい）