TL;DR
今では多くの企業がSnowflakeとDatabricksを併用しており、両方のコストを一元的に把握できる手段を求めています。さらに、Databricksは他の多くのプラットフォームと比べて、最適化が実際に難しいプラットフォームです。サービスの数が多く、設定項目も多く、明確な理由がないままコストが変動する要因も多いのです。私たちは、Snowflake向けに提供してきたのと同じコスト可視化と最適化の機能をデータチームに届けるため、SELECT for Databricksを開発しました。
SELECTでは、これまでに250社を超えるSnowflakeのお客様とご一緒する機会に恵まれてきました。そして時間が経つにつれ、「同じことをDatabricksでもできませんか?」という声を繰り返しいただくようになりました。
この声が出発点でした。ただ、Databricks向けのコスト可視化と最適化の開発を後押しした要因はほかに2つあり、この2つこそが実際の開発方針を大きく左右しています。
マルチプラットフォームはもはや標準
私たちが関わるアカウント全体で見ると、SnowflakeとDatabricksの併用は例外ではなく、すでに当たり前になっています。この使い分けは多くの場合、workloadsの観点から理にかなっています。構造化データの分析にはSnowflake、より重いコンピュートやML処理にはDatabricks、という具合です。
両方を利用しているチームは、両プラットフォームでworkloadsを実行した場合のコストを比較し、さらにデータプラットフォーム全体の支出を一箇所で追跡したいと考えていました。
DatabricksはSnowflakeよりも設定項目がはるかに多い
Snowflakeのコンピュートは非常にシンプルで使いやすく、ユーザーが最適化すべき仮想ウェアハウスの設定パラメータはごくわずかです。
Databricksはまったく事情が異なります。複数のコンピュートオプションとworkloadsの実行方法(ジョブコンピュート、All Purpose/インタラクティブ、サーバーレスSQLなど)があり、各サービスの設定オプションも格段に多くなっています。クラスタサイズ、オートスケーリングのパラメータ、インスタンスタイプの選択、Spotインスタンスの利用は、いずれも請求額を左右する重要な選択です。
設定項目が多いということは、それだけ最適化の余地が広いということです。同時に、設定ミスに気づかないまま、コストが動いてから初めて発覚するリスクも高くなります。
確実に言えるのは、まず可視化が先だということです。見えないものは調整できません。SELECT for Databricksはそこから始まります。実際のコストがどこに使われているのか、そして時間の経過とともに何が変化を引き起こしているのかを、明確に分解して示します。
Databricksは組織内で急速に拡大している
Databricksは、MLとデータエンジニアリングに特化したプラットフォームとしてスタートしましたが、今やその枠を大きく超えています。より多くのチームがより多様なworkloadsを実行するようになり、組織内での採用は加速しています。
急速な普及は、おなじみの問題を生みます。支出を管理するプロセスが整う前に、支出そのものが増えてしまうのです。チームがworkloadsを追加し、コストが膨らみ、請求額が予想を超えて初めて、何が原因なのかを誰も明確に把握できていないことに気づきます。
私たちはSnowflakeで同じことが起きるのを見てきました。チームが急速に採用し、コストが可視化を追い越し、そこから支出を理解しコントロールする取り組みが始まる。SELECTはまさにその瞬間のために作られました。同じことが今、Databricksで起きています。
私たちが開発したもの
SELECT for Databricksは、チーム、ワークスペース、ジョブ、クエリworkload単位でコストの帰属先を把握できる機能をデータチームに提供します。コストは1ドル残らず追跡でき、MLを活用した異常検知によって支出の増加を自動で通知し、さらにAI Copilotで根本原因を自動的に調査できます。
充実したコストオブザーバビリティに加えて、Automated Savings機能により、ユーザーは一切手間をかけずにコンピュート支出を自動で削減できます。この機能は、SQL Warehouse、All Purposeクラスタ、ジョブコンピュートを、パフォーマンスに影響を与えることなくリアルタイムで最適化します。
実際の動作をご覧になりたい方は、こちらからお打ち合わせをご予約ください:select.dev/demo