メインコンテンツまでスキップ

データのクエリ

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

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

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

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

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実行コンテキストおよび対応言語でサポートされています。

SQL
SELECT * FROM catalog_name.schema_name.table_name

Unity Catalog 識別子の解決​

Databricks では、クエリまたはワークロードが複数のスキーマまたはカタログに格納されているデータベース オブジェクトと対話する場合は、完全修飾識別子を使用することをお勧めします。

次の表は、部分修飾識別子と非修飾識別子の動作の概要を示しています。

識別子パターン

挙動

catalog_name.schema_name.object_name

識別子で指定されたデータベース・オブジェクトを参照します。

schema_name.object_name

現在のカタログ内の指定された schema_name および object_name に関連付けられたデータベース・オブジェクトを参照します。

object_name

現在のカタログとスキーマ内の指定された object_name に関連付けられているデータベース オブジェクトを参照します。

現在のカタログとスキーマは何ですか?​

対話型のコンピュート環境では、 current_catalog() と current_schema() を使用して、現在のカタログとスキーマを確認します。

Unity Catalog で構成されたすべてのワークスペースには、ワークスペース レベルで設定されたデフォルト カタログがあります。「デフォルトカタログの管理」を参照してください。

次の表では Databricks ワークスペースのデフォルトカタログを上書きする可能性のある製品の構成について説明します。

製品

構成

All-purpose または ジョブ コンピュート

コンピュートを設定するときは、 Spark 設定spark.databricks.sql.initial.catalog.namespaceを設定します。

DLT

パイプラインの設定時に指定されたカタログとスキーマは、すべてのパイプラインロジックのワークスペースのデフォルトを上書きします。

注記

デフォルトのカタログまたはスキーマは、外部システムまたはメタストアに接続するときに JDBC 構成によって設定される場合もあります。 予期しないデフォルト動作が発生した場合は、 Databricks コンピュートおよび統合システムの構成を担当する管理者に連絡してください。

USE CATALOG または USE SCHEMA 構文を使用して、現在のセッションの現在のカタログまたはスキーマを指定します。現在のカタログまたはスキーマは、クエリまたはステートメントで部分修飾または非修飾の ID を使用する場合に使用されます。

ステートメント

結果

USE CATALOG catalog_name

指定された catalog_nameを使用して現在のカタログを設定します。 現在のスキーマを defaultに設定します。

USE SCHEMA schema_name

現在のカタログに指定された schema_name を使用して、現在のスキーマを設定します。

USE SCHEMA catalog_name.schema_name

指定された catalog_name を使用して現在のカタログを設定し、指定された schema_nameを使用して現在のスキーマを設定します。

注記

完全修飾識別子を使用してテーブル、ビュー、関数、モデルなどのオブジェクトと対話するクエリとコマンドは、現在のカタログやスキーマを変更せず、常に指定されたオブジェクトを参照します。

パスでデータをクエリします​

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

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

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

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

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

次の例は、URIJSON を使用してAzure データレイク Storage、GCS 、およびS3 の データをクエリする方法を示しています。

SQL
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`;

SQLウェアハウスを使用したデータのクエリ​

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

に最終更新