SnowflakeとDatabricksの機能をそれぞれ見てみる
Update履歴
もし新機能がでたりして内容を追加したりしたら履歴として追加したいなと思ってます。
※小さなリライトは履歴に残しません。
Update日 | Update内容 |
---|---|
2025/9 | 新規作成 |
はじめに
今回はSnowflakeとDatabricksの機能を見てみたいと思います。
日本だけでなく、海外の記事や動画をみても、網羅的な比較事例が少なめだったので、今回まとめてみようかと思い立ちました。
業務でどちらも詳しく調べる必要があり、知識のまとめということで書いてみます。
一つ一つの機能を細かくみるというより、こういう機能があるというのを紹介する感じなので、リファレンスから詳しく調べていただければ幸いです。
併用している会社様も多いので、どちらがいいというより、機能を見て、合いそうな部分があったら併用するのもいいと思います。
Snowflakeとは
SnowflakeとはということでChatGPTに200文字で要約してもらいます。
Snowflakeは、クラウドベースのデータウェアハウスサービスで、大量のデータを高速・安全に処理・分析できるプラットフォームです。スケーラビリティや同時実行性に優れ、SQLでの操作が可能です。Amazon Web Services、Google Cloud、Microsoft Azure上で動作し、ストレージとコンピューティングを分離する独自のアーキテクチャが特徴です。データ共有やセキュリティ機能も強力で、企業のデータ活用を支援します。 |
---|
高速に起動・データ集計できるとともに、ガバナンスがよく効いたデータ管理が可能です。最近ではデータ基盤を用いたAI機能が多く発表されており、データ基盤として多くの会社に採用されている印象です。
様々な会社様の資料などをみているとAWS Redshiftなどから移行してコスト削減などをされている会社様も多い印象で、今までのサービス対比でコストパフォーマンスにも優れたサービスと言えそうです。
SaaSサービスとなっており、初めて活用される方や管理者に優しいサービスになっています。もちろん大規模活用にも多く使われており、初級者-上級者に全部マッチするのではと思います。
Databricksとは
DatabricksとはということでChatGPTに200文字で要約してもらいます。
Databricksは、Apache Sparkを基盤としたクラウドベースのデータ分析・AIプラットフォームです。データエンジニアリング、機械学習、BI分析を統合的に実行でき、データレイクとデータウェアハウスの利点を兼ね備えた「レイクハウス」アーキテクチャが特徴です。Python、SQL、Rなど複数の言語に対応し、ノートブック形式での共同作業も可能。大規模データの処理からモデルの運用まで、一元的に管理できる環境を提供します。 |
---|
こちらもマルチクラウドの上に立つ形でAWS/Azure/GCPなどから、自組織にマッチする環境を活用することができます。特にAzureについてはAzure Databricksという形でAzureサービスとしても提供されているため、Azureを使っているならばすぐに立ち上げられます。
- Apache Spark™
- Delta Lake
- MLflow
- Unity Catalog
などが特徴的で、かつ、これらのサービス開発者がDatabricksの創業者です。
DatabricksはDWHとしてももちろん活用できますが、データ分析や機械学習などを使うことができ、オールインワンのプラットフォームとして幅広く活用することができます。
DWHの移行先としてもデータ分析プラットフォームとしても移行先の候補としてなっているようです。クラウドの複数サービスを一つに統合する目的で活用する企業様もいる気がします。
データ周り
データ周りのまとめは下記になります。
観点 | Snowflake | Databricks |
---|---|---|
データ形式と構造 | クラウドネイティブなDWH。構造化データが主だが、半構造化(JSON, YAML 等)や非構造化(画像等)も格納可能。 | レイクハウスプラットフォーム。構造化データに限定されず多様なデータを格納可能。 |
ストレージ方式 | Database/Schema/Object 階層。 オブジェクト種類: - Table - View - Stage - Model - Task など 最近 Workspace 機能がPreviewリリースされフォルダ的管理も可能。 |
Catalog/Schema/Object 階層。 オブジェクト種類: - Table - View - Volume - Function - Model 加えて WorkSpace によりExplorer/Finderのようにファイル管理可能。 |
外部データ接続 | - External Table により s3/ADLS/GCS を直接参照。 - Snowpipe による継続取り込み。 |
- Data IngestionやConnectorで多様なデータに接続可能。 - Auto Loader による自動増分取り込み(バッチ/ストリーミング両対応)。 - Delta Live Tables による容易なETLも可能。 |
データ管理 (権限管理) | UBAC, RBAC によりユーザー/ロールごとのアクセス制御が可能。 | Unity Catalog によりユーザーやロールベースのガバナンス管理が可能。 |
データ共有 | Secure Data SharingによりSnowflakeアカウント間でデータ共有可能 | Delta SharingによりDatabricks間や他プラットフォームと共有可能 |
データ周り: データ形式と構造
Snowflakeはクラウドネイティブなデータウェアハウス、Databricksはレイクハウスプラットフォームといわれていますが、どちらも構造化データだけでなく、非構造化データなども格納できます。
Snowflake
クラウドネイティブなデータウェアハウスで構造化データを入れるイメージがありますが、非構造化データ、半構造化データも格納可能です(画像、json, ymlなど)。後述するStage Objectには何でも入ります。
オープンなフォーマットであるIceberg方式でもデータを管理することができるので、その活用方法の検討もいいかもしれません。
Databricks
DatabricksはLakeHouseプラットフォームと言われており、今までよく使われてきたDWHのように構造化データに縛られることなく、AI活用までできるよう様々なデータを入れることができます。
DatabricksはAWS/Azure/GCPベースがありますが、それぞれs3/ADLS/GCSが裏のストレージ環境として使われており、明示的に接続してデータを格納していくことが可能です。
データ周り: ストレージ方式
Snowflake
Databaseの/Schemaの下に様々なObjectを入れていくことができます。
例えばDatabase/Schema/Table/ の下に
- Database/Schema/Table/Table_a
- Database/Schema/Table/Table_b
- Database/Schema/Table/Table_c
みたいにデータを入れていきます。この入れ方はDatabricksもほぼ同じです。
オブジェクトの種類は
- Table: メインで使うと思いますが、データをテーブル形式で入れます。
- View: Tableっぽく使うことができますが、最新の集計データを参照します。
- Stage: ファイルを一時的に置くための中間ストレージで、csv/json/parquetなど様々なデータを入れることができます。
- Model: 機械学習のModel情報を登録できます
- Task: スケジュールされたTaskなどを入れられます。
他にも色々ありますが、Objectとしていろいろな種類があるので下記参照ください。
基本はObject内にデータを入れて全体で共有するという使い方になっていたのですが、
つい最近Workspace機能がPreviewとしてリリースされ、Databricksと似たようにフォルダ的な使い方もできるようになってきました。
Databricks
Databricksの場合はCatalog/Schemaの下に様々なObjectを入れることができます。
データの最上流の部分をDatabricksでは「Catalog」と言います。
Snowflakeと見た感じは一緒です。
オブジェクトの種類は
- Table: こちらはTableを入れられます。
- View: こちらはViewを入れられます。
- Volume: 様々なデータ(構造、半構造、非構造データ)を入れられることができます。
- Function: UDFを入れられます。
- Model: 機械学習の学習済モデルを入れられます。
Object内にもデータを入れられますが、別途WorkSpaceというフォルダ環境があるので、ObjectかWorkSpaceを使ってデータ/ファイルを管理する使い方になりそうです。
WorkSpaceはローカルの「Explorer(Windows)」や「Finder(Mac)」のような使い方ができます。
データ周り: 他のデータとの接続
Snowflake
外部ストレージを直接参照 (External Table)
s3/ADLS/GCS上のファイルを External Tableとしてクエリできます。事前に外部ステージとして場所を登録後、外部テーブルとして活用できます。
継続取り込み (Snowpipe)
Snowflakeは継続的にデータを取り込む機能としてSnowpipeがあります。
クラウドストレージに新規ファイルが置かれたら自動で取り込むことが可能です。
Databricks
Data Ingestion、Connector
Databricksの「Data Ingestion」やそれに含まれる「Connector」を用いることでさまざまなデータに接続することが可能です。
継続取り込み (Auto Loader)
s3/ADLS/GCS上のディレクトリを監視し、新着ファイルを増分で自動取り込みできます。
Structured Streaming の cloudFiles ソースを使い、バッチ/ストリーミング両方で運用可能。スキーマエボリューションやクリーンアップ(移動/削除)などの運用オプションも豊富です。
Delta Live Tablesの機能を活用して、さらに容易に活用することもできます。
他クラウドサービスの活用
マルチクラウド上で動くSnowflake、Databricksは自分たちのクラウドにマッチしたETL/ELTツールやクラウドストレージと合わせて活用するのも割と容易だと思います。
下記の3セットと合わせた検討もいいかもしれません。
- AWS Glue / s3
- Azure Data Factory / ADLS
- GCP Data Fusion / GCS
データ周り: データ管理
Snowflake
SnowflakeはUBAC(User Based Access Control)やRBAC(Role Based Access Control)でユーザーとObjectをどのようにManageするかを管理できます。
- このユーザーにはこのデータを見せたくない
- このロールにはReadだけさせたい
- Adminには全ての権限を与える
のような管理が可能です。
Databricks
Unity Catalogという機能があり、こちらでもSnowflakeと同じようにユーザーやロールベースの管理が可能です。
データ周り: データ共有
最近このあたりについて、非常に素晴らしい記事が出ていたので、こちらを参考にすることをオススメします。
SnowflakeはSecure Data Sharing、DatabricksはDelta Sharingという機能があり、プラットフォーム間でデータの共有が可能です。
Snowflake
SnowflakeではSecure Data Sharingという機能により、データプロバイダーが自アカウント内のデータベースオブジェクトを他のSnowflakeアカウントと安全に共有できます。
Databricks
一方、Databricksには Delta Sharing と呼ばれる、データとAI資産を組織外のユーザーと安全に共有するためのプラットフォーム機能があります。
Snowflakeと異なる点としては「Databricksに限らず、他のシステムでも利用可能なオープン標準ベースの仕組み」になっている点です(ただ、意外と異なるプラットフォームの場合は制限もあり)。
データ分析周り
どちらもデータプラットフォームとしても扱われますが、SQLやPythonを用いて分析することができます。
SQLは他のデータソースからのデータ前処理やETLなどに用いられますが、Pythonはデータ分析や機械学習に強みを持ちます。Pythonは主にNotebookを用いて分析されます。
観点 | Snowflake | Databricks |
---|---|---|
SQL分析 | Worksheets 機能で一般的なSQLエディターを利用可能。 Copilot機能により生成AIがSQL作成や分析を支援。 |
SQL Editor 機能を提供。 Databricks Assistant により生成AIがコーディング支援。 |
Notebook分析 | 2024年からNotebook機能が利用可能。 Pandas形式やSnowpark DataFrameで分析可能。 |
Notebook機能が標準で充実。 Sparkを標準利用でき大規模分散処理が容易。 Databricks Assistant にEditモードやAgentモード(Preview)を搭載。 |
大規模処理 | チューニング少なめでも大規模処理可能。 - Auto Scale(スケールイン/アウト) - マルチクラスターウェアハウス - マイクロパーティション自動最適化 |
Sparkを標準利用し大規模分散処理に強み。 - Apache Spark - Photon(高速処理) - Auto Scale対応 高速化とコスト管理のチューニングが必要。 |
グラフ機能 | Worksheets上でGUIによるグラフ生成が可能。 | GUIで多種多様なグラフを作成可能。 カスタマイズ性が高く、ピボットテーブルなども提供。 |
AutoML | ML関数によりSQLベースで予測分析可能。 - 異常検出 - 分類 - 時系列予測 Snowflake MarketplaceでH2O.aiのAI機能も利用可能。 |
AutoML機能が標準搭載。 - 回帰 - 分類 - 時系列予測 途中経過をNotebookで確認可能。複数モデルの比較も容易。 |
MLOps (Experiment, Serving) | モデルレジストリで scikit-learn, xgboost, LightGBM モデルを格納可能。 Snowpark Container Services でモデルをサービング可能。 |
MLflow が標準搭載され、実験管理・モデル管理が容易。 Model Serving によりリアルタイム推論も可能。 |
他AI機能 | Cortex: - Cortex Search: 自然言語でドキュメント横断検索 (RAG機能) - Cortex Analyst: Text to SQL による自然言語分析 Snowflake Intelligence とも連携予定。 |
Genie: - Text to SQL により自然言語でCatalog内データを分析可能。 - ダッシュボードと連携し、会話形式でDWHを分析可能。 |
データ分析周り: SQL分析
どちらもSQLエディターのような形でSQLで格納されているデータの分析ができます。
どちらも後述のNotebook上でもSQL分析ができます。
Snowflake
一般的なSQLエディターでSQL分析できます。Worksheetsという機能になります。
最近はCopilot機能が使えるようになってきており、分析時に生成AIの力も借りることが出来ます。
計算リソースが高速で立ち上がり分析できるので、ストレスがかなり少なく実施可能です。
Databricks
一般的なSQLエディターでSQL分析できます。SQL Editorという機能です。
データを早く見たいときが多いので、コンピュートの種類はできたらサーバーレスを使いたいものです。
こちらもDatabricks Assistantというチャット機能でサポートを受けながらコーディングできます。
データ分析周り: Notebook分析
Pythonで分析するならやはりNotebookでしょうか。
実際は.py形式でモジュールとして連携することも多いかなと思いますが、クラウド系の分析サービスはNotebookを推していると思いますので、今回はNotebookについてみていきます。
Snowflake
こちらは2024年に発表されており、Snowflakeでも活用可能です。
一般的なPandas形式でもデータを処理することが可能ですが、Snowpark形式のデータフレームでも処理することが可能です。
SnowparkとはSnowflakeが提供する開発フレームワークです。Python、Java、Scalaなどを使用でき、分散処理によって効率的な分析が実施可能です。
ただ、Notebook機能がまだガンガン使えるかというといくつか気になる点もあるのですが(Notebookがフォルダ分けできない、モジュール登録が面倒)などありますが、2025WorldTourの情報を見ていると、改善予定だと思うので要チェックです。
Databricks
Databricksは元々AI/機械学習に強い特徴があるので、基本的なことは何でもできるのはないでしょうか。Notebookはもちろん使えますし、.pyなども普通に使えます。Sparkも標準で使えます。
.ipynb/.py/.sql/.yml/.json/.csvなど使うことが多いと思いますが、Workspaceというフォルダ環境にこれらのファイルを入れられます。Volume Objectに入れることも可能です。
相対パスなども問題なく使えるので、ローカルで使われているものをDatabricksに移管するのも問題なくできると思います。
Databrick Assistantというチャット機能を強化しており、NotebookのCellごとに変更するEditモードやAgentモード(Preview)も出ています。
データ分析周り: 大規模処理
大規模処理を伴うパフォーマンスとそのコストについて調べることもあるかもしれませんが、実際は細かいチューニングなども必要です。
大規模処理に対するパフォーマンスやコストだけでなく、トータルで管理しやすいかも合わせて検討するのが良いかと思います。
Snowflake
SnowflakeはDatabricksほどチューニングを細かくしなくても、高パフォーマンスな大規模処理をすることが出来ます。
具体的には
- Auto Scale(スケールアウト、スケールイン)
- マルチクラスターウェアハウス
等を用いて高速で管理コストも少ない大規模処理を試すことができると思います。
ただ、Snowflakeはマイクロパーティションやキャッシュなど自動最適化機能があるので、スペックや台数だけにとらわれずに検証するのが良いと思います。
Databricks
大規模処理といえばSparkを標準的に活用することができます。合わせてPhotonの機能を追加すれば高速化できる可能性があります。
具体的には
- Apache Spark(分散処理)
- Photon(高速処理)
- Auto Scale(スケールアウト、スケールイン)
等の技術を用いて検証することになるかなと思います。
ただ高速化とともに時間単位コストも上昇したり、Sparkの記述手法を理解することがあるので、パフォーマンスが上がる一方で、料金と管理のコストを見ることも大事だと思います。
データ分析周り: グラフ機能
SnowflakeもDatabricksもグラフを気軽に作る機能があります。
データ分析をする際にはmatplotlib, seaborn, plotlyなど使うのが一般的なだと思いますが、いちいちコードを書くのは面倒です。
これらをポチポチ作れば効率がかなり高くなりそうです。
Snowflake
Worksheet(SQLエディター)の方でグラフをグラフをGUIで作ることができます。
ただ若干カスタム性に乏しいので、使ってみて確認した方が良さそうです。
Databricks
かなりの種類のグラフをGUIで作ることができます。
カスタム性にも結構優れているので、これだけでもかなりの時間短縮になります。
ピボットテーブルなども気軽に作れるので、ビジネス向けの方にもすぐ見せるアウトプットを作ることが出来ます。
データ分析周り: AutoML
最近は機械学習系のプラットフォームでほとんどがAutoMLの機能がありますが、Snowflake、Databricksでもあります。
ネイティブな機能についてはSnowflakeはSQLベース、DatabricksはPythonベースで使えます。
Snowflake
SnowflakeにはML関数があり、SQLを用いてさまざまな予測を容易に実施することができます。
- 異常検出 (https://docs.snowflake.com/ja/user-guide/ml-functions/anomaly-detection)
- 分類 (https://docs.snowflake.com/ja/user-guide/ml-functions/classification)
- 時系列予測 (https://docs.snowflake.com/ja/user-guide/ml-functions/forecasting)
また、こちらは使ったことがないのですが、SnowflakeのマーケットプレイスのH2O.aiのAI機能も推奨されているようです。
こちらではPythonベースで分析できそうです。
Databricks
DatabricksはAutoML機能が標準で使えるようになっています。
下記の課題について分析することが可能です。
- 回帰 (https://docs.databricks.com/aws/ja/machine-learning/automl/regression)
- 分類 (https://docs.databricks.com/aws/ja/machine-learning/automl/classification)
- 時系列予測 (https://docs.databricks.com/aws/ja/machine-learning/automl/forecasting)
途中の計算をNotebookで見れるので、再活用にも便利ですし、いくつかのモデルの結果も網羅的にみることができます。
データ分析周り: MLOps(Experiment, Serving)
Snowflake
モデルレジストリという機能があり、scikit-learn
xgboost、LightGBMなどのモデルを格納することができます。
Snowpark Container Servicesを用いてモデルをサービングすることが可能です。
Databricks
Databricksといえば、MLFlowを使うことができます。
Databricksには実験管理やモデル管理などを行うOSS技術のMLFlowが標準で入っていますので、こちらで実験管理やモデル管理ができます。
DatabricksはModel Servingも可能で、リアルタイムの推論などにも活用が可能です。
データ分析周り: 他AI機能(Cortex、Genie等)
Snowflake
ここではCortexの機能について紹介します。
Snowflakeに多くのデータを格納して管理している会社様も多いかと思いますが、このCortexの機能を使うことでビジネスユーザーにも使いやすいサービスを提供することができます。
後述するSnowflake Intelligentce(エージェント)とも組み合わせて活用されていきそうです。
- Cortex Search:さまざまなドキュメントに対して自然言語で問い合わせることができ、効率的に横断検索できる機能。RAGの構築機能。
- Cortex Analyst:データに対して自然言語で問い合わせることができ、分析してくれる機能。Text to SQLです。
Databricks
ここではGenieという機能について紹介します。
これはCortexと近い機能になるのですが、自然言語によりCatalog内に登録されているデータの分析が可能です。Text to SQLです。
ビジネス側の方が気軽に分析することができます。
ダッシュボードと合わせてGenieを使うこともできるので、ダッシュボードを見ながら実際にDWHと会話形式で分析ができます。
コードや環境周り
実際に分析しようとするとコード管理や環境管理が非常に重要になります。
それらの機能を見てみます。
観点 | Snowflake | Databricks |
---|---|---|
GitHub連携 | GitHub連携用のObjectを作成して利用可能。 | WorkSpace内に直接Clone可能。 個人フォルダで自由に操作 or ReposフォルダでCI/CD的に利用。 GUI操作中心。 |
Python Package管理 | Notebook単位でPackageインストール可能。 Snowpark利用時は requirements.txt で追加インストールも可能。 |
NotebookやクラスターにLibraryをインストール可能。requirements.txt をクラスターに適用すれば全員同じ環境で利用可能。 |
CI/CD | GitHub Actions + Snowflake CLI を活用してCI/CDを実現可能。 | GitHub Actions + Asset Bundles を活用。 ジョブはGUIでも作成できるが、ymlでも管理可能。 |
コードや環境周り: GitHub
コード管理のサービスはいくつもあるかと思いますが、今回は一番メジャーなGitHubの活用方法について調べてみます。
Snowflake
SnowflakeはGitHubとの連携が可能です。
リポジトリ連携用のObjectを作成する必要があります。
コードでいくつか書く必要があり、ちょっと最初は慣れが必要かもしれません。
ただ、最近PreviewになったWorkspaceにて、使い勝手が良くなってそうなので、そちらの機能と合わせて見るものよさそうです。
Databricks
こちらも一般的な操作は可能です。
WorkSpace内のどのフォルダにもCloneすることができるので、開発的にいじりたいときは個人フォルダでガチャガチャするのも実施可能ですが、もっとCI/CD的に使いたいときはReposフォルダを使うのがオススメです。
GUI的な操作になるため、GitHubに慣れてないユーザーには優しいかもしれませんが、VSCodeやターミナルでずっと慣れてきた方にはちょっと使いづらさが残るかもしれません。
コードや環境周り: Python Package管理
Pythonを使った分析を実施する際は追加でPackage管理することが必要になります。
自分のローカル環境でPythonを実行するときは、scikit-learnやLightGBMなど追加で必要になることが多いと思います。
それらをSnowflakeとDatabricksでどのように管理するかを見ます。
Snowflake
NotebookにPython Packageをインストールすることができます。
Snowparkを実行している場合はrequirementsなどもインストールすることができます。
サーバーレス的な使い方がメインになるので、NotebookやSessionに対するPackageインストールすることがメインなような気がするので、Notebook間での環境差異など気をつけた方がいいかもしれません。
Databricks
NotebookやクラスターにLibraryをインストールできます。
requirements.txtなどをクラスターにインストールできますので、そのクラスターを全員で使えば全員同じ環境で分析ができます。同じ環境なので、個々人で結果の相違がなくなりますので、予測結果の安定性につながります。
コードや環境周り: CI/CD
CI/CDについては、GitHub Actions等と連携して実施することになります。
Snowflake
自分は試したことがないですが、GigHub ActionsおよびSnowflake CLIを用いてCI/CDを実現することができるそうです。
Databricks
GitHub ActionsとAsset bundlesを用いて実施可能です。
さまざまなリソースをAsset bundlesで管理することでDev→Prod環境など、継続的にデプロイすることが可能です。
ジョブはDatabricks内でGUIで作ることが可能ですが、ymlファイルで管理することができるため、このymlファイルとAsset bundlesで環境の構築が可能です。
ジョブ
ジョブ: Task、Workflow
Snowflake、Databricksどちらも下記を設定して自動で処理を走らせることができます。
下記のような部分を設定して、定期的に処理を走らせることが可能です。
- トリガー
- 通知
- パラメータ
Snowflake
Taskいう機能で実施可能です。
SQLで書くので慣れが必要かもしれませんが、問題なく使うことが可能です。
DAGも活用することができます。
Airflowなど別のサービスも使ってSnowflakeの処理を管理している組織もよく見かける気がします。
Databricks
ちょくちょく名前が変わっている(気がする)ので、呼び名は怪しいですがJobの機能は下記のようにあります。
GUIでポチポチ作りながら、Notebookや.pyファイルの実行ができます。
複数フローを繋げて実施することも可能です。
ダッシュボード
どちらもダッシュボードを作る機能があります。
データプラットフォームとして活用されていますので、他のツールやBIツールに繋げずにそのままプラットフォーム上でダッシュボードを作れるため、セキュリティ的にも安心です。
また、「ライセンスによる課金ではなく、計算リソースに応じた従量課金になるため、使う人数をスケールしやすい」メリットもあると思います。
最近はBIツールのライセンス代も結構高いので。。
※計算リソースやストレージ料金はかかるので、そこは注意が必要です。
観点 | Snowflake | Databricks |
---|---|---|
ネイティブ機能 | Dashboards機能を提供。 Worksheetで作成したグラフをそのままダッシュボード表示可能。 カスタマイズ性はやや限定的。 |
ダッシュボード機能を提供。 カスタマイズ性が高く、生成AIサポート付きで効率的に作成可能。 Genieと統合表示可能。 |
アプリ活用 (Streamlit等) | Streamlitを標準で統合。 Snowflake環境内でセキュアにStreamlitアプリを構築可能。 |
Databricks Apps機能でアプリ構築可能。 Streamlit / Dash / Gradio をサポート。 Chatbotなども容易に開発可能。 |
ダッシュボード: ネイティブ機能
Snowflake
SnowflakeといえばStreamlitという印象も強いのですが、Dashboardsという機能が別途存在します。こちらはWorksheetで活用できるグラフをDashboardで表示できるような機能です。
グラフの機能紹介部でも記載しましたが、若干カスタム性に乏しいので、使ってみて確認した方が良さそうです。
Databricks
こちらもダッシュボードの機能が存在し、気軽にダッシュボードを作ることが出来ます。カスタム性は結構高めです。
生成AIなども活用しながら、ダッシュボードをポチポチ作ることが可能です。
後述されるGenieとも一緒に表示できるので、もしかしたら他のBIツールやStreamlitを立てるなどしなくても、ネイティブ機能ダッシュボードで十分かもしれないです。というくらい結構使いやすいです。
ダッシュボード: Streamlitなどのアプリ活用
Snowflake
Snowflakeは、標準機能としてStreamlitをすぐに活用できます。
セキュアなデータ環境の中でStreamlitアプリを構築できるので、多くの会社様でも活用されているみたいです。
Databricks
最近出た機能ではありますが、Databricks Appsという機能でさまざまなアプリを構築できます。
- Streamlit
- Dash
- Gradio
などがサポートされており、Chatbotも容易に作ることが可能です。
マーケットプレイス
どちらもマーケットプレイスがあり、さまざまなデータやサービスを無料/有料で活用することができます。
色々ありすぎるので、直接触って確認した方が良いと思います。
エージェント
こちらはどちらも最近出た機能なので、まだまだこれから要確認な感じもします。
ご確認ください。
Snowflake IntelligenceというCortexと組み合わせたAgent機能が発表されました。Cortex AnalystなどのテクノロジーでSQLクエリを直接生成して、データの深い推察ができるようです。
Agent Bricksという機能が発表され、情報抽出、カスタムLLM、ナレッジアシスタント、マルチAgent Supervisorなどの機能があるそうです。
コスト
まずどちらのプラットフォームも従量課金になります。
ライセンス代はかからず使った分だけ課金です。
使う頻度が低い月は安かったりしますが、ミスって計算リソースをつけっぱなしにすると高い料金になることもあると思います。
コスト形態ですが、Snowflake, Databricksともに
全体コスト = Storageコスト(Data Transfer含む) + Computeコスト + 他 |
---|
というコスト構造が大まかなものになるのではと思います。
Storage, Computeが結構かかると思うので、そちらを注視して見積もるのが大事そうです。
「他」というのは基本的に立ち上げて運用する際にかかる
- ネットワーク
- セキュリティ
などのコストになります。閉域作成、ログ、セキュリティ対策などをクラウド側ですることが必須だと思いますので、その辺がかかります。
ほぼほぼ組織による部分が多いかなと思います。
コスト: Storageコスト
全体像は下記のようになります。
Data Transferもここに入れています。
コスト要素 | Snowflake / Databricks 共通の考え方 | 注意ポイント |
---|---|---|
Storage Cost(保存コスト) | S3 / ADLS / GCS などクラウドストレージに依存。 | - サービス側で自動圧縮あり - 圧縮率はサービスやデータ特性により変動 - 営業や担当に要確認 |
Data Transfer Cost(転送コスト) | データ移動時に課金発生。 | - 同クラウド内・異リージョン:課金あり - 異クラウド間(AWS→Azureなど):料金高め |
Old Data Cost(古いデータ保持コスト) | ログやタイムトラベル、バージョン管理で古いデータが裏で保持される。 | - Snowflake:Time Travel / Fail-safe - Databricks:Delta Lake + VACUUM設定不足で残存 - 想定以上にデータ容量が膨らむ可能性あり |
コスト: Storage Cost
Snowflake、Databricksどちらもs3, ADLS, GCSのクラウドストレージを使っており、容量に対してコストがかかります。ですが、サービス側でデータを自動で圧縮していたりするので、サービス毎にちゃんと見た方が良さそうです。
ちなみに下記をみるとどちらも「1TBあたり23ドル/月~25ドル/月」くらいみたいです(リージョンによっても変わる)。
しかしデータ圧縮後のコストになるので、圧縮率的な部分も営業さんと話すのが良さそうです。
コスト: Storage(Data) Transfer Cost
Transferに関してもコストがかかるので、こちらも注意が必要です。
- 同じクラウドサービス&違うリージョンのクラウドサービスに転送する
- 違うクラウドサービスに(AWS→Azure etc.)転送する
ときは料金がかかります。違うクラウドサービス転送は料金高めです。
コスト: Storage Old Data Cost
また、ログやタイムトラベルなどで古いデータも実は裏で存在しているので、適切に設定したりVACCUM処理しないと「データが想定の数倍-数十倍保管されている」なんて自体に陥る可能性もあります。もちろんコストはその分かかります。
見積もりを実施する際は「⚪︎日分/⚪︎年分はデータを残す」という前提で見積もるのが良さそうです。
コスト: Computeコスト
Computeは裏でVertual Machine(AWS EC2, Azure VM, GCP VM)が動いています。
大きく使い方は2種類ありサーバーレスとノンサーバーレスがあります。
※ノンサーバーレスとは一般的に呼びませんが、サーバーを自分たちで管理するサーバーレスじゃないものをノンサーバーレスと一旦呼びます。
種類 | 特徴 | 時間単価 |
---|---|---|
サーバーレス | ベンダー管理のサーバーを即時利用可能 高速立ち上げ・高速立ち下げ(起動に数秒-数十秒) |
単価は高め(ただし短時間ジョブでは効率的) |
ノンサーバーレス | 自分でVMを随時立ち上げて利用 立ち上げは遅め(起動に3-5分程度) |
単価は安め(ただしアイドル時間が発生しやすい) |
このような特徴を持ちます。
サーバーレスは単価自体はノンサーバーレスより高めですが、アイドル時間が発生しにくいため、実ジョブの稼働時間が短い場合は、サーバーレスの方が安く済むことも多いと思います。
Snowflake
基本はSnowflake社がマネージするサーバーを使うサーバーレスのような使い方になります。
Computeは高速で立ち上げてETL処理や分析を迅速に実行できます。数秒-数十秒で起動します。
待ち時間がかなり短く、かつ計算が終了すると計算リソースをすぐに停止することもできますので、計算時以外の使っていない時間に課金されるコストが少なくなります。
マルチクラスタウェアハウスを使うと、AutoScaleでいい感じにスケールアウト、スケールインできるので、コストの最適化も容易に実施可能です。
また、Standard、Enterprice、Business Criticalによって料金が変わりますので、下記から確認ください。
全体的には下記となります。
項目 | 内容 |
---|---|
基本料金形態 | クレジット制:クラスタ台数 × クラスタ稼働時間 × クラスタ単価 |
プラン | Standard / Enterprise / Business Critical で単価が変動 |
課金が発生しそうな部分 | - マルチクラスタウェアハウスでスケールアウトすると台数分加算 - 長時間稼働しっぱなしにするとコスト増 - 大きなクラスタサイズを選択すると単価が上昇 |
Databricks
サーバーレスとClassic(ノンサーバーレス)どちらも使えます。
サーバーレスの方を好む方は多いですが、Classicはrequirements.txtなどでpackageをインストールした状態で安定して分析できるので、Notebookの場合はClassicでやる方があっているかもしれません。ただ起動は3-5分くらいかかります。
Databricksはやや複雑なコスト計算になり、下記2つを合わせた料金になります。
- VMのCompute料金
- Databricks使用料(DBU料金)
※All-Purpose(Notebook)、Job、SQLでクラスター種類が変わり、料金がそれぞれ異なります。
※Standard、Premiumで料金が変わります。
またいくつか課金要素がありますので注意が必要です。
項目 | 内容 |
---|---|
基本料金形態 | クラスタ台数 × クラスタ稼働時間 × クラスタ単価(VMのCompute料金 + Databricks使用料(DBU料金)) |
プラン | Standard / Premium で料金が変動 クラスター種類(All-Purpose / Job / SQL)で料金が変動 |
課金が発生しそうな部分 | - AutoScaleでスケールアウトすると台数分加算 - 個人クラスターを複数立てると人数×台数分課金 - マルチノードクラスターでDriver + Workerの両方に課金 - Photon利用で高速化する代わりに単価が上昇 - 大きなクラスタサイズを選択すると単価が上昇 - クラスターを起動したまま放置すると時間課金で膨らむ |
一応参考資料を添付しますが、Snowflakeよりは見積もりが難しいと思います。自分も理解するのにだいぶ時間がかかりました。一番分かりやすそうなAzure Databricksのコストページも載せます。
営業担当などと擦り合わせるのが良さそうです。
まとめ
Snowflake
SnowflakeはSaaS型で管理が容易なデータ基盤として人気が高く、BIツールとの接続を通じたビジネス活用を推進しやすいプラットフォームです。CortexやStreamlitなど新機能も充実しており、アプリ化やデータ活用がより容易になっています。計算リソースの起動/停止も高速で、運用効率やコスト最適化にもつながります。
Databricks
Databricksは機能が豊富で、データ分析から機械学習まで幅広くカバーします。ただし設定や管理に一定の知識が必要で、適切に運用しないとコストが膨らむ可能性もあります。その一方で、複数のクラウドサービスを統合しワンプラットフォームで活用できる点は大きな魅力です。あと、公式リファレンスも割と分かりやすいなと感じました。
SnowflakeとDatabricks
どちらも機能的には似ている点が多く、比較するのが難しいかと思います。片方が足りない機能があったら、次の年くらいには追いつくためにその機能がPreviewになっている気がします。
機能・コストを見るのも重要だと思いますが、将来適用されるかもしれない技術や管理される組織形態なども想定しながら比較検討するのが良いと思います。
ちなみにMicrosoft Fabricなどもこの領域に踏み込みつつある(気がする)ので注視するのが良さそうです。
最後に
今回の比較がインフラ選定やデータ基盤設計の参考になれば幸いです。
ただ、こうして今回まとめましたが、どっちが機能として欠けているということはないのですが、使い勝手や管理のしやすさが異なります。
今後も2社の新機能など楽しみです。
もしご興味ある方はどちらも無料で試せるので、一旦試すのが良さそうです。
Discussion