データのクエリー

データのクエリは、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 構文の多くを継承しており、 SCHEMADATABASEを区別しません。

テーブル名によるクエリは、すべての 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 クエリー

  • Lakeview ダッシュボード

  • 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で使用される一括実行モードでは、結果を次のメソッドに渡す前に計算を順番に処理する必要があります。

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

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