クエリ データ

  • [アーティクル]

データのクエリは、Azure Databricks でほぼすべてのデータ ドリブン タスクを実行するための基本的なステップです。 使用する言語やツールに関係なく、ワークロードではまず、テーブルまたはその他のデータ ソースに対してクエリを定義してから、データから分析情報を得るためのアクションを実行します。 この記事では、さまざまな Azure Databricks 製品オファリングにわたってクエリを実行するための主要な概念と手順について概説し、ユース ケースに合わせて調整できるコード例を示します。

以下を使用して、対話形式でデータのクエリを実行できます。

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

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

Azure Databricks でのストリーミング クエリの概要については、ストリーミング データのクエリに関するページを参照してください。

Azure Databricks ではどのようなデータにクエリを実行できますか?

Azure Databricks では、複数の形式およびエンタープライズ システムでのデータのクエリがサポートされています。 Azure Databricks を使用してクエリを実行するデータは、Databricks レイクハウス内のデータと外部データという 2 つの大きなカテゴリのいずれかに分類されます。

Databricks レイクハウスにはどのようなデータがありますか?

Databricks Data Intelligence Platform では、すべてのデータが既定で Databricks レイクハウスに格納されます。

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

  • Delta Lake 形式で格納される。
  • クラウド オブジェクト ストレージに格納される。
  • Unity Catalog によって管理される。

Azure Databricks 上のほとんどのレイクハウス データは、マネージド テーブルとして Unity Catalog に登録されます。 マネージド テーブルでは、最も簡単な構文が提供され、ほとんどのリレーショナル データベース管理システムの他のテーブルと同様に動作します。 マネージド テーブルはほとんどのユース ケースに推奨され、データ ストレージの実装の詳細について心配したくないすべてのユーザーに適しています。

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

一部のレガシ ワークロードでは、ファイル パスを介して Delta Lake データと排他的に対話し、テーブルがまったく登録されない場合があります。 このデータはまだレイクハウス データですが、Unity Catalog に登録されていないため、検出がより難しくなる可能性があります。

Note

ワークスペース管理者が、Unity Catalog を使用するようにデータ ガバナンスをアップグレードしていない可能性があります。 Unity Catalog を使用しない Databricks レイクハウスの利点の多くは引き続き得られますが、この記事または Azure Databricks ドキュメント全体に一覧表示されているすべての機能がサポートされているわけではありません。

外部と見なされるのはどのようなデータですか?

Databricks レイクハウスにないデータはすべて外部データと見なすことができます。 外部データの例をいくつか以下に示します。

  • Lakehouse Federation に登録されている外部テーブル。
  • Parquet でサポートされる Hive メタストア内のテーブル。
  • JSON でサポートされる Unity Catalog 内の外部テーブル。
  • クラウド オブジェクト ストレージに格納されている CSV データ。
  • Kafka から読み取られたストリーミング データ。

Azure Databricks では、多くのデータ ソースへの接続の構成がサポートされています。 データ ソースへの接続に関するページを参照してください。

Unity Catalog を使用して、テーブルへのアクセスの管理と複数の形式および外部システムで格納されているデータに対するテーブルの定義は可能ですが、データがレイクハウスで考慮されるようにするには Delta Lake が必要です。

Delta Lake では、データの整合性と一貫性を維持するために重要な Azure Databricks のすべてのトランザクション保証が提供されます。 Azure Databricks データのトランザクション保証と、それらが重要である理由について詳しくは、「Azure Databricks での ACID 保証とは」を参照してください。

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

名前でテーブルに対してクエリを実行する

テーブルとして登録されているすべてのデータに対して、Databricks ではテーブル名を使用してクエリを実行することをお勧めします。

Unity Catalog を使う場合、テーブルでは <catalog-name>.<schema-name>.<table-name> 形式の 3 層名前空間が使用されます。

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

Note

Azure Databricks では、その SQL 構文の多くが Apache Spark から継承され、SCHEMA と DATABASE は区別されません。

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

SQL

SELECT * FROM catalog_name.schema_name.table_name

Python

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

パスでデータに対してクエリを実行する

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

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

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

SQL

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

Python

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

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

次の例では、URI を使用して Azure Data Lake Storage Gen2、GCS、S3 の JSON データに対してクエリを実行する方法を示します。

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

Python

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 ウェアハウスを使用してデータに対してクエリを実行する

Azure 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 では遅延コード実行が使用されます。つまり、結果は必要に応じてのみ計算され、結果を強制しない場合は、データ ソースに対する複数の変換またはクエリを単一クエリとして最適化できます。 これは、計算を順番に処理してから次のメソッドに結果を渡す必要がある、pandas で使用される一括実行モードとは対照的です。

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

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