データのクエリー

データのクエリーは、Databricks内のほぼすべてのデータドリブンタスクを実行するための基本的なステップです。使用する言語やツールに関係なく、ワークロードはテーブルやその他のデータソースに対するクエリーを定義し、データから洞察を得るためのアクションを実行することから始まります。この記事では、様々なDatabricks製品でクエリーを実行するための中核となる概念と手順について概説し、ユースケースに合わせたコード例を紹介します。

次を使用してインタラクティブにデータのクエリーを実行できます。

ノートブック
SQLエディタ
ファイルエディタ
ダッシュボード

Delta Live Tablesのパイプラインまたはジョブの一部としてクエリを実行することもできます。

Databricksでのストリーミングクエリーの概要については、「ストリーミングデータのクエリー」を参照してください。

Databricksでクエリーできるデータとは？

Databricksは、複数の形式とエンタープライズシステムでのデータクエリーをサポートしています。Databricksを使用してクエリーするデータは、Databricksのレイクハウス内のデータと外部データの2つに大きく分けられます。

Databricksレイクハウスに含まれるデータとは？

Databricksデータインテリジェンスプラットフォームは、デフォルトですべてのデータをDatabricksレイクハウスに格納します。

これは、基本的な CREATE TABLE ステートメントを実行して新しいテーブルを作成すると、レイクハウステーブルが作成されることを意味します。レイクハウスデータには、次のプロパティがあります。

Delta Lake形式での保存。
クラウドオブジェクトストレージでの保存。
Unity Catalogによる管理。

Databricksのほとんどのレイクハウスデータは、マネージドテーブルとしてUnity Catalogに登録されています。マネージドテーブルは最も簡単な構文が採用され、ほとんどのリレーショナルデータベース管理システムの他のテーブルと同じように動作します。マネージドテーブルはほとんどのユースケースに推奨され、データストレージの実装の詳細に関する不安を解消したいユーザーに適しています。

アンマネージドテーブル、または外部テーブルは、指定されたLOCATIONで登録されたテーブルです。外部という用語は誤解を招く可能性があります。外部Deltaテーブルは依然としてレイクハウスのデータです。アンマネージドテーブルは、他の Delta リーダークライアントから直接テーブルにアクセスするユーザーに好まれる場合があります。テーブルセマンティクスの違いの概要については、「テーブルとビューとは」を参照してください。

一部のレガシーワークロードは、ファイルパスを介してDelta Lakeデータとのみ対話し、テーブルの登録をまったく行わない場合があります。このデータがレイクハウスデータであることに変わりはありませんが、Unity Catalogに登録されていないため、発見が困難になる可能性があります。

注：

ワークスペース管理者が、Unity Catalogを使用するようにデータガバナンスをアップグレードしていない可能性があります。Unity CatalogがなくてもDatabricksレイクハウスのメリットの多くを活用することはできますが、この記事やDatabricksのドキュメントに記載されているすべての機能がサポートされているわけではありません。

どのようなデータが外部データと見なされるか

Databricksレイクハウスに含まれないデータはすべて外部データとみなされます。以下に、外部データの例を挙げます。

レイクハウスフェデレーションに登録されたフォーリンテーブル。
ParquetでサポートされるHive metastoreのテーブル。
JSONでサポートされるUnity Catalog内の外部テーブル。
クラウドオブジェクトストレージに保存されたCSVデータ。
Kafkaから読み取られたストリーミングデータ。

Databricksは多くのデータソースへの接続設定をサポートしています。「データソースへの接続」を参照してください。

Unity Catalogを使用することえ、複数の形式で外部システムに保存されたデータに対するアクセスを管理してテーブルを定義することができますが、データがレイクハウスに含まれるとみなされるためにはDelta Lakeが必要です。

Delta Lakeは、データ完全性と一貫性を維持するために重要となるDatabricksのトランザクション保証をすべて提供しています。Databricksデータのトランザクション保証とその重要性について詳しく知りたい場合は、「DatabricksのACID保証とは」を参照してください。

ほとんどのDatabricksユーザーは、レイクハウスデータと外部データの組み合わせに対してクエリーを実行します。外部データとの接続は、データ取り込みや、データをレイクハウスに持ち込むETLパイプラインの最初のステップです。データの取り込みについては、「Databricksレイクハウスへのデータの取り込み」を参照してください。

テーブルを名前でクエリーする

テーブルとして登録されたすべてのデータに対して、Databricksはテーブル名を使用したクエリーを推奨します。

Unity Catalogを使用している場合、テーブルは次の形式の3層の名前空間を使用します。 <catalog-name>.<schema-name>.<table-name>.

Unity Catalogがない場合、テーブル識別子は次の形式を使用します。<schema-name>.<table-name>

注：

Databricksは、SCHEMA と DATABASE を区別しないApache SparkからSQL構文の多くを継承しています。

テーブル名によるクエリーは、すべてのDatabricks実行コンテキストおよび対応言語でサポートされています。

SELECT * FROM catalog_name.schema_name.table_name

spark.read.table("catalog_name.schema_name.table_name")

データをパスでクエリーする

ファイルパスを使用して、構造化データ、半構造化データ、および非構造化データをクエリーできます。Databricks上のほとんどのファイルは、クラウドオブジェクトストレージによってサポートされています。「Databricksでのファイルの操作」を参照してください。

Databricks では、Unity Catalog を使用してクラウドオブジェクトストレージへのすべてのアクセスを構成し、直接クエリされるオブジェクトストレージの場所のボリュームを定義することをお勧めします。ボリュームは、ファイルパスのカタログ名とスキーマ名を使用して、クラウドオブジェクトストレージ内の場所とファイルに人間が読めるエイリアスを提供します。「Unity Catalog を使用してクラウドオブジェクトストレージとサービスに接続する」を参照してください。

次の例は、Unity Catalog ボリュームパスを使用してJSONデータを読み取る方法を示しています。

SELECT * FROM json.`/Volumes/catalog_name/schema_name/volume_name/path/to/data`

spark.read.format("json").load("/Volumes/catalog_name/schema_name/volume_name/path/to/data")

Unity Catalogボリュームとして構成されていないクラウドの場所の場合は、URIを使用してデータを直接クエリーできます。クラウドオブジェクトストレージへのアクセスは、URIを使用してデータをクエリーするように構成する必要があります。「Databricksのクラウドオブジェクトストレージへのアクセスを構成する」を参照してください。

次の例は、URIを使用してAzure Data Lake Storage Gen2、GCS、および S3のJSONデータをクエリーする方法を示しています。

SELECT * FROM json.`abfss://container-name@storage-account-name.dfs.core.windows.net/path/to/data`;

SELECT * FROM json.`gs://bucket_name/path/to/data`;

SELECT * FROM json.`s3://bucket_name/path/to/data`;

spark.read.format("json").load("abfss://container-name@storage-account-name.dfs.core.windows.net/path/to/data")

spark.read.format("json").load("gs://bucket_name/path/to/data")

spark.read.format("json").load("s3://bucket_name/path/to/data")

SQLウェアハウスを使用してデータをクエリーする

Databricksは、次のインターフェースでのコンピュートにSQLウェアハウスを使用します。

SQLエディタ
Databricks SQLクエリー
ダッシュボード
レガシーダッシュボード
SQLアラート

必要に応じて、SQLウェアハウスを次の製品と共に使用できます。

Databricksノートブック
Databricksファイルエディタ
Databricksジョブ

SQLウェアハウスでデータをクエリーする場合は、SQL構文のみを使用できます。他のプログラミング言語とAPIはサポートされていません。

Unity Catalogに対し有効になっているワークスペースの場合、SQLウェアハウスは常にUnity Catalogを使用してデータソースへのアクセスを管理します。

SQLウェアハウスで実行されるほとんどのクエリーはテーブルをターゲットとしたものです。データファイルをターゲットとするクエリーでは、Unity Catalog ボリュームを活用してストレージの場所へのアクセスを管理する必要があります。

SQLウェアハウスで実行されるクエリでURIを直接使用すると、予期しないエラーが発生する可能性があります。

汎用コンピュートまたはジョブコンピュートを使用してデータをクエリーする

Databricksノートブック、ワークフロー、ファイルエディタから実行するクエリーのほとんどは、Databricks Runtimeを使って構成されたコンピュートクラスタに対して実行されます。これらのクラスターは、インタラクティブに実行するように構成することも、ワークフローを強化するジョブコンピュートとしてデプロイすることもできます。Databricksでは、非インタラクティブなワークロードに対して常にジョブコンピュートを使用することをお勧めします。

対話型ワークロードと非対話型ワークロード

多くのユーザーは、開発中に変換が処理されている間にクエリー結果を表示するのが便利だと感じています。対話型ワークロードを汎用コンピュートからジョブコンピュートに移行すると、結果を表示するクエリーを削除することで、時間と処理コストを節約できます。

Apache Sparkは遅延コード実行を使用します。つまり、結果は必要な場合にのみ計算され、結果を強制しない場合は、データソースに対する複数の変換またはクエリーを 1 つのクエリーとして最適化できます。これは、結果を次のメソッドに渡す前に計算を順番に処理する必要がある、Pandasで使用されるイーガー実行モードとは対照的です。

クリーンアップされ、変換され、集計されたデータを新しいデータセットとして保存することが目標の場合は、実行をスケジュールする前に、結果を表示するクエリーをコードから削除する必要があります。

小規模なオペレーションや小規模なデータセットの場合、時間とコストはさほど節約できないかもしれません。しかし、大規模なオペレーションでは、手作業では検査できないような結果を計算してノートブックに印刷するのにかなりの時間を費やしてしまう可能性があります。結果を保存した後で、ほとんどコストをかけることなく、保存した出力から同じ結果をクエリーすることが可能です。