SQL メソッドを使用してデータを取り込む
SQL コマンドは、Azure Databricks でのデータ インジェストに対する宣言型アプローチを提供します。 既に SQL 構文に慣れている場合、これらのメソッドを使用すると、手続き型コードを記述せずにテーブルを作成して設定できます。 3 つの主要な SQL インジェスト手法 (CREATE TABLE AS SELECT (CTAS)、 CREATE OR REPLACE TABLE、 COPY INTO) は、Unity カタログとの完全な互換性を維持しながら、異なるインジェスト シナリオに対処します。
CTAS を使用してクエリからテーブルを作成する
CREATE TABLE AS SELECT ステートメントは、テーブルの作成とデータの作成を 1 つの操作に結合します。
SELECT クエリの結果に基づいて新しいテーブルを定義するため、インジェスト中のデータの変換に最適です。
外部ソースから顧客データを取り込み、変換を適用する必要があるシナリオを考えてみましょう。 CTAS では、ソースから読み取り、変換を適用し、結果を新しいマネージド テーブルに保存するクエリを記述します。
CREATE TABLE catalog.schema.customers AS
SELECT
customer_id,
UPPER(customer_name) AS customer_name,
email,
created_date
FROM external_staging.raw_customers
WHERE customer_status = 'active';
テーブル スキーマは、クエリ結果から自動的に派生します。 Azure Databricks では、既定で Delta 形式を使用してテーブルが作成されます。この形式では、ACID トランザクション、時間移動、および最適化されたパフォーマンスが提供されます。
CTAS は、初期データの読み込みと 1 回限りの移行に適しています。 ファイルからデータを読み取る必要がある場合は、CTAS と read_files テーブル値関数を組み合わせます。
CREATE TABLE catalog.schema.sales_data AS
SELECT * FROM read_files(
'/Volumes/catalog/schema/volume/sales/*.parquet',
format => 'parquet'
);
注
CTAS は、実行されるたびに新しいテーブルを作成します。 テーブルが既に存在する場合、 IF NOT EXISTS 句を使用しない限りコマンドは失敗しますが、その句はテーブルを更新するのではなく、実行を完全にスキップします。
CREATE または REPLACE TABLE を使用してテーブルを更新する
テーブルの内容を完全に更新する必要がある場合、 CREATE OR REPLACE TABLE はクリーンなソリューションを提供します。 このコマンドは、新しいテーブルを作成するか、既存のテーブルを完全に置き換えます。テーブル履歴、付与された権限、および構成した行フィルターまたは列マスクを保持します。
この方法は、既存のすべてのデータを置き換える必要がある定期的なデータ更新に価値があることを証明します。
CREATE OR REPLACE TABLE catalog.schema.daily_metrics AS
SELECT
report_date,
SUM(revenue) AS total_revenue,
COUNT(DISTINCT customer_id) AS unique_customers
FROM catalog.schema.transactions
WHERE report_date >= CURRENT_DATE - INTERVAL 30 DAYS
GROUP BY report_date;
テーブルの削除と再作成とは異なり、 CREATE OR REPLACE はテーブルのメタデータとアクセス許可を保持します。 ダウンストリーム ユーザーとアプリケーションは、再構成なしで引き続きテーブルにアクセスします。
このコマンドを使用して、ファイルから直接データを読み込むこともできます。 スキーマは、クエリ結果から自動的に推論されます。
CREATE OR REPLACE TABLE catalog.schema.products AS
SELECT * FROM read_files(
'/Volumes/catalog/schema/volume/products.csv',
format => 'csv',
header => true
);
Important
CREATE OR REPLACE は、テーブルの完全な置換を実行します。 新しいレコードのみを追加する増分更新の場合は、代わりに COPY INTO を使用します。
COPY INTO を使用してファイルを増分読み込みする
COPY INTO は、一般的なインジェストの課題である、信頼性の高い反復可能な方法でクラウド ストレージからファイルを読み込むという課題に対処します。 1 回実行してテーブルを作成する CTAS とは異なり、 COPY INTO は、新しいファイルが定期的に到着する継続的なインジェスト ワークフロー用に設計されています。
このコマンドは、指定した場所からファイルを読み取り、既存の Delta テーブルに追加します。 その主な機能はべき等性です。既に読み込まれているファイルは、複数の実行でも自動的にスキップされます。
COPY INTO catalog.schema.events
FROM '/Volumes/catalog/schema/volume/events/'
FILEFORMAT = JSON
FORMAT_OPTIONS ('multiline' = 'true');
COPY INTOを実行する前に、ターゲット テーブルが既に存在している必要があります。 適切なスキーマを使用して作成します。
CREATE TABLE IF NOT EXISTS catalog.schema.events (
event_id STRING,
event_type STRING,
event_timestamp TIMESTAMP,
payload STRING
);
ファイルの選択を構成する
ソース ディレクトリに異なる名前付けパターンのファイルが含まれている場合、または特定のファイルを読み込む必要がある場合は、 PATTERN または FILES オプションを使用します。
-- Load only files matching a pattern
COPY INTO catalog.schema.orders
FROM '/Volumes/catalog/schema/volume/orders/'
FILEFORMAT = PARQUET
PATTERN = 'orders_2024*.parquet';
-- Load specific files by name
COPY INTO catalog.schema.orders
FROM '/Volumes/catalog/schema/volume/orders/'
FILEFORMAT = PARQUET
FILES = ('orders_001.parquet', 'orders_002.parquet');
スキーマとデータ品質を処理する
COPY INTO には、読み込む前にスキーマの変更を処理し、データを検証するためのオプションが用意されています。
COPY INTO catalog.schema.sensor_data
FROM '/Volumes/catalog/schema/volume/sensors/'
FILEFORMAT = CSV
FORMAT_OPTIONS (
'header' = 'true',
'inferSchema' = 'true'
)
COPY_OPTIONS ('mergeSchema' = 'true');
mergeSchema オプションを使用すると、ソース ファイルに新しい列が表示されるにつれてテーブル スキーマを進化させることができます。 読み込まずにデータを検証する場合は、VALIDATE 句を追加します。
COPY INTO catalog.schema.sensor_data
FROM '/Volumes/catalog/schema/volume/sensors/'
FILEFORMAT = CSV
VALIDATE ALL;
この検証では、データを解析できるかどうかを確認し、テーブル スキーマと一致し、null 許容制約と check 制約を満たします。
適切な方法の選択
各 SQL インジェスト方法は、データ エンジニアリング ワークフローで個別の目的を果たします。
| メソッド | 最適な用途 | 行動 |
|---|---|---|
| Ctas | 初期データの読み込み、1 回限りの移行、クエリからのテーブルの作成 | 新しいテーブルを作成します。テーブルが存在する場合は失敗する |
| 作成または置換 | 定期的にステージングテーブルを置き換える完全更新 | テーブル全体を置き換えます。アクセス許可を保持します |
| コピーイン | 進行中のファイル取り込み、増分データの読み込み | 既存のテーブルに追加します。読み込まれたファイルをスキップします |
自動スキーマ推論、ファイル通知、または 1 回限り保証を必要とするファイル ベースのインジェストの場合は、補完的なアプローチとして自動ローダーを使用することを検討してください。 インジェストのニーズが単純で、手続き型コードよりも宣言型 SQL を使用する場合、これら 3 つの方法により、Unity カタログへのデータ フローを管理するための完全なツールキットが提供されます。
注
COPY INTO は、長期間にわたって数千のファイルを取り込む際に適切に機能します。 数百万以上のファイルに拡張されるソースの場合は、自動ローダー (次のユニットで説明します) が推奨されるアプローチです。これは、ファイルをより効率的に検出し、より豊富なスキーマの進化をサポートし、ディレクトリ一覧のオーバーヘッドなしでスケーリングします。 Databricks では、SQL ベースのファイル インジェストのスケーラブルで長期的な代替手段として、自動ローダーによってサポートされるストリーミング テーブルも推奨されています。