データ分析

インテリジェントなコード変換: Gemini を活用した、Databricks Spark SQL から BigQuery SQL への変換

2025年8月26日

Dhruv Ahuja

Technical Solution Consultant, Data

※この投稿は米国時間 2025 年 8 月 22 日に、Google Cloud blog に投稿されたものの抄訳です。

データプラットフォームが進化し、企業がクラウドエコシステムを多様化するにつれて、エンジン間で SQL ワークロードを移行する必要性がますます広まっています。最近、Databricks SQL クエリのセットを BigQuery SQL に変換する作業に携わる機会がありました。構文、関数、実行動作などが異なるため、この作業は一見単純に見えても実際には複雑です。

作業を効率化するために、強力な AI アシスタントである Google Gemini を利用して、2 つの SQL 言語間のギャップを埋めることにしました。今回の記事では、そのプロセス、直面した課題、Gemini がどのように役立ったか、そして得られた教訓についてご説明します。

翻訳が難しい理由

運用効率を高めて費用を削減するため、分析ワークロードを Databricks SQL（Delta Lake テーブル上）から Google BigQuery に移行しました。ただしそのためには、単純な集計から複雑な CTE やウィンドウ関数まで、多数のクエリを書き換える必要がありました。

Databricks は強力な Spark SQL 機能を備え、BigQuery はサーバーレスでスケーラビリティの高いデータウェアハウスであり、どちらもデータの業界では中心的な存在です。ただし SQL 言語は、ANSI SQL 基盤こそ共通していますが、バリエーション間には明確な差異があります。2 つの言語を手動で翻訳することは可能でしたが、時間がかかり、エラーが発生しがちでした。ここで重要な役割を果たすのが Google Gemini です。

Databricks と BigQuery のデータ型のマッピングを以下に示します。

カテゴリ	Databricks SQL のデータ型	BigQuery SQL のデータ型	説明
整数型	TINYINT	INT64	8 ビット整数
	SMALLINT	INT64	16 ビット整数
	INT または INTEGER	INT64	32 ビット整数
	BIGINT	INT64	64 ビット整数
#floating_point_types	FLOAT または REAL	FLOAT64	64 ビット浮動小数点
	DOUBLE	FLOAT64	64 ビット浮動小数点（BigQuery の FLOAT64 に相当）
10 進数/正確な型	DECIMAL または NUMERIC	NUMERIC または BIGNUMERIC	ユーザー定義の精度とスケールを持つ固定小数点 10 進数。BigQuery には、より高い精度を実現する拡張 BIGNUMERIC があります。
ブール型	BOOLEAN	BOOL	正誤問題
文字列型	STRING または VARCHAR	STRING	可変長文字列
	CHAR	サポート対象外	固定長文字列は BigQuery で直接サポートされていません。代わりに STRING を使用してください。
日時型	DATE	DATE	カレンダーの日付（年、月、日）
	TIMESTAMP	TIMESTAMP	タイムゾーン情報を含むタイムスタンプ
	DATETIME	DATETIME	タイムゾーン情報を含まないタイムスタンプ

Databricks と BigQuery の構文の違い

First_Value :

Databricks

読み込んでいます...

BigQuery

読み込んでいます...

特に、H3 地理空間関数を使用する場合は、翻訳に特有の課題が生じることがよくあります。Google のリソースでは、以下のような明確なマッピングが提供されています。

Databricks 関数	BigQuery での同等の関数	説明
h3_boundaryasgeojson(h3CellIdExpr)	ST_ASGEOJSON(jslibs.h3.ST_H3_BOUNDARY(h3CellIdExpr))	入力された H3 セルのポリゴン境界を GeoJSON 形式で返します。
h3_boundaryaswkb(h3CellIdExpr)	ST_ASBINARY(jslibs.h3.ST_H3_BOUNDARY(h3CellIdExpr))	入力された H3 セルのポリゴン境界を WKB 形式で返します。
h3_boundaryaswkt(h3CellIdExpr)	ST_ASTEXT(jslibs.h3.ST_H3_BOUNDARY(h3CellIdExpr))	入力された H3 セルのポリゴン境界を WKT 形式で返します。

このような複雑な機能について正確な詳細を提供することは非常に重要です。実際、これらの H3 変換を詳細に記述することで、Gemini のような高度な AI モデルでも、元の Databricks Spark SQL からより正確で信頼性の高い BigQuery SQL を生成できることがわかりました。これにより、地理空間分析がそのまま維持されます。

アーキテクチャの概要

翻訳ロジックについて詳しく説明する前に、各部分がどのように組み合わされているかを見てみましょう。

パイプラインコンポーネント

ソース SQL ストレージ:

元の Databricks SQL ファイルはすべて Google Cloud Storage に保存されていました。

機能マッピングガイド:

Databricks 固有の SQL 関数（例: First_value、UCase など）を BigQuery の同等の関数（FIRST_VALUE、UPPER、TIMESTAMP など）に変換する
このガイドには、Gemini の入力コンテキストとして使用される例と構文ルールが含まれていました。

少数ショットの例

Gemini の一貫性を高めるための高品質なトレーニングプロンプトとして、手作業で翻訳した一連のクエリを選択しました。

検索拡張生成（RAG）レイヤ:

Gemini にクエリを実行する前に、Vertex AI RAG Engine を活用して、関連する関数マッピングと翻訳例を取得しました。これにより、Gemini はグラウンディングされた知識を持ち、出力の精度が向上しました。RAG で強化されたプロンプトは、翻訳のために Gemini に送信され、返された SQL は、エッジケースを修正するために必要に応じて後処理されました。

これにより、Gemini はグラウンディングされた知識を持ち、出力の精度が向上しました。

Gemini API の統合:

RAG で強化されたプロンプトが Gemini に送信され、翻訳されました。
返された SQL は、エッジケースを修正するために必要に応じて後処理されました。

検証レイヤ

翻訳された SQL クエリは、BigQuery のドライランモードで実行して構文の問題を検出することで検証されました。

アーキテクチャの図

https://storage.googleapis.com/gweb-cloudblog-publish/images/image1_LrbXXzc.max-800x800.jpg

学んだ教訓

RAG + Gemini = スマートな SQL 変換: Gemini を実際の例でグラウンディングし、ロジックをマッピングすることで、精度が大幅に向上しました。
包括的な機能マッピングガイドが不可欠: 堅牢な機能マッピングリソースの構築に時間を費やします。
徹底的な検証が鍵: BigQuery のドライランと情報スキーマを使用して、翻訳されたクエリが安全で最適化されていることを確認します。