【Azure Databricks】 REFRESH TABLEコマンドの説明

1.概要
2.背景
3.具体的な例
4.注意事項
5.まとめ
- この記事を読んだ方へのオススメコンテンツはこちら

1.概要

Databricksを使用していると、DeltaテーブルやParquetファイルなどのストレージ上のデータを更新したはずなのに、クエリ結果に反映されないケースがあります。「なぜこうなるのか？」と疑問に思ったことはありませんか？

実は、こうした状況ではREFRESH TABLEコマンドが大きな役割を果たします。本記事では、このREFRESH TABLEの動作について、具体的な例を交えて解説します。

2.背景

REFRESH TABLEが必要になるのはどんなとき？

Databricks上でPARQUETやCSVファイル等の外部テーブルを使用する際、ストレージ上のファイルデータを更新しても、Databricks側のメタデータキャッシュは自動で更新されない。
複数のノートブック間で同じテーブルを操作する際、セッション間でキャッシュが残ってしまう。

その結果、ノートブック上でSELECTクエリを実行しても、実際のファイル内容がすでに変更されているにもかかわらず、古いデータが返ってくることがあります。

こういった状況を防ぐために、データ更新後やノートブック間でのデータ連携時には、REFRESH TABLEの実行を推奨します。

次の内容は詳細に説明します。

3.具体的な例

①ストレージアカウント上のCSVファイルに接続する外部テーブルを作成します。

文法：

CREATE TABLE IF NOT EXISTS <catalog_name>.<schema_name>.<table_name>
USING CSV
OPTIONS (
  header 'true',
  inferSchema true
)
LOCATION 'abfss://<container_name>@<storageaccount_name>.dfs.core.windows.net/<path_to_data>'

CREATE TABLE IF NOT EXISTS <catalog_name>.<schema_name>.<table_name>

USING CSV

OPTIONS (

header 'true',

inferSchema true

)

LOCATION 'abfss://<container_name>@<storageaccount_name>.dfs.core.windows.net/<path_to_data>'

その後、以下のコマンドを使って、テーブルの情報がCSV形式として正しく反映されているかを確認します。

DESCRIBE DETAIL <catalog_name>.<schema_name>.<table_name>;

1	DESCRIBE DETAIL <catalog_name>.<schema_name>.<table_name>;

② セッションキャッシュの仕組みをより明確に説明するために、別のノートブックを作成し、それを独立したセッションとして扱います。

そして、両方のノートブックで同時に「csv_table」に対して「SELECT」を実行すると、ストレージアカウントからのデータがテーブルに反映されている結果が確認できます。

SELECT * FROM adf_test_02.schema_02.csv_table;

1	SELECT * FROM adf_test_02.schema_02.csv_table;

③ 外部テーブルを読み込んだ後、CSVファイルで直接編集し、以下の操作を実施します。

「Age_range」列を追加する
新規の行を１つ追加する

④元データを変更した後、ステップ①のコマンドを再実行し、テーブルの内容を再読み込みします。

メインセッションのNotebookで、SELECTを実行してテーブルのデータを確認します。

SELECT * FROM adf_test_02.schema_02.csv_table;

1	SELECT * FROM adf_test_02.schema_02.csv_table;

「Age_range」列および新規の行が無事に追加されました。

⑤ ステップ②で作成した別のノートブックで、再び「SELECT」文を実行して確認します。

ただし、「Age_range」列や新しいデータがまだ反映されていないのが分かりますよね？では、説明します。

※留意：

Databricksでは、ノートブックやQuery Editor、Jobタスクなどの各セッションごとに以下の情報を個別に保持しています。

データファイルの一覧（ファイルインデックス）
テーブル構造（スキーマ）

これは、繰り返しクエリを実行する際のパフォーマンス向上につながる一方で、外部ストレージ上のデータが変更されても、セッション側の情報が更新されない限り、古いデータがそのまま返ってきてしまうというリスクもあります。
👉　このようなケースでは、REFRESH TABLEを使ってメタデータキャッシュを明示的に更新することで、常に最新の状態でデータを参照することができます。

⑥ 他のセッションでキャッシュされたデータの問題を解消するために、以下のようにREFRESH TABLEコマンドを実行します。

文法：

REFRESH TABLE <catalog_name>.<schema_name>.<table_name>;

1	REFRESH TABLE <catalog_name>.<schema_name>.<table_name>;

結果として最新情報が更新されました。

そのため、複数のノートブック（セッション）で同じテーブルのデータを扱う場合は、REFRESH TABLEを実行して、常に最新のデータが反映・統一されるようにしてください。

4.注意事項

REFRESH TABLEを使えばキャッシュの問題を回避できますが、すべてのケースで必ずしも使用が必要というわけではありません。

たとえば、DatabricksのDelta Tableに対して「INSERT」や「ALTER TABLE」を直接実行する場合は、REFRESH TABLEを使わなくても常に最新のデータが反映されるようになっています。これは、Delta Lakeの仕組みにより、すべての更新操作が「_delta_log」と呼ばれるトランザクションログに記録され、その内容に基づいてメタデータも自動的に同期されるためです。したがって、こういった内部更新においては、Databricksが自動的に情報を反映してくれるため、手動で REFRESH TABLEを実行する必要はありません。
※詳細は公式ドキュメントでも確認できます。Delta Lake – Databricks SQL | Microsoft Learn

REFRESH TABLEは、Databricksにおいてクエリ結果が実際のデータを正しく反映するために重要な手段です。特に、複数のセッションが存在する場合や、外部データストレージ上でデータが更新された場合に、その効果を発揮します。

Databricksのキャッシュの仕組みを理解した上で、REFRESH TABLE を必要な場面に限定して使うことが、無駄なリソース消費を避け、システムのパフォーマンスを最適化し、より安定したパイプライン構築につながります。