データのクエリー

データのクエリは、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 を使用している場合、テーブルでは <catalog-name>.<schema-name>.<table-name>という形式の 3 層名前空間が使用されます。

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

注：

Databricks は Apache Spark から SQL 構文の多くを継承しており、 SCHEMA と DATABASEを区別しません。

テーブル名によるクエリは、すべての 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 ボリュームパスを使用してデータを read.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 クエリー
Databricks SQLのダッシュボード
SQL アラート

オプションで、次の製品でSQLウェアハウスを使用できます。

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

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

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

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

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

データを All Purpose コンピュートまたは Jobコンピュートを使ってクエリーする

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

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

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

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

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

小規模な操作や小規模なデータセットの場合、時間とコストの節約はわずかです。しかし、大規模な操作では、結果を計算してノートブックに出力するためにかなりの時間が浪費され、手動で検査されない可能性があります。保存後、保存された出力から同じ結果がほとんどコストをかけずにクエリーされる可能性があります。