【第4回】ETLの基礎 - Load（ロード）

Loadとは何か

Load（ロード）は、ETLプロセスの最終ステップで、変換済みデータを目的地に保存する処理です。「データを書き込むだけ」と思われがちですが、実際には多くの考慮事項があります。

保存先は用途によって様々です。データウェアハウス、データレイク、分析用データベース、BIツール、機械学習モデルなど、目的に応じた最適な保存方法を選択する必要があります。

ロードの基本パターン

データのロード方法は、主に3つのパターンに分類されます。

フルロード（Full Load）
既存データを完全に置き換える方法です。最もシンプルですが、大量データでは時間がかかります。

# 既存テーブルを完全に置き換え
df.to_sql('products', 
          con=engine, 
          if_exists='replace',  # テーブルを置き換え
          index=False)

追記ロード（Append Load）
既存データに新しいデータを追加する方法です。ログデータや時系列データに適しています。

# 既存データに追加
df.to_sql('access_logs',
          con=engine,
          if_exists='append',  # 既存データに追加
          index=False)

更新ロード（Upsert/Merge Load）
既存レコードがあれば更新、なければ挿入する方法です。最も複雑ですが、柔軟性が高いです。

# PostgreSQLでのUPSERT例
from sqlalchemy import text

# 一時テーブルにデータを投入
df.to_sql('temp_customers', con=engine, if_exists='replace', index=False)

# UPSERTを実行
with engine.begin() as conn:
    conn.execute(text("""
        INSERT INTO customers (customer_id, name, email, updated_at)
        SELECT customer_id, name, email, updated_at FROM temp_customers
        ON CONFLICT (customer_id) 
        DO UPDATE SET
            name = EXCLUDED.name,
            email = EXCLUDED.email,
            updated_at = EXCLUDED.updated_at
    """))

ロード先の選択

データの特性と用途に応じて、適切な保存先を選びます。

データウェアハウス（DWH）
構造化された分析用データの保存に適しています。Amazon Redshift、Google BigQuery、Snowflakeなどが代表的です。

# BigQueryへのロード
from google.cloud import bigquery

client = bigquery.Client()
table_id = "project.dataset.sales_summary"

# DataFrameを直接ロード
job = client.load_table_from_dataframe(df, table_id)
job.result()  # 完了を待つ

print(f"{job.output_rows} rows loaded")

DWHの利点は、大規模なSQLクエリを高速に実行できることです。欠点は、コストが比較的高いことと、スキーマ変更が慎重さを要することです。

データレイク
構造化・非構造化を問わず、大量の生データを保存します。Amazon S3、Azure Data Lake、Google Cloud Storageなどが使われます。

# S3へのParquetファイル保存
import pyarrow.parquet as pq
import s3fs

# S3ファイルシステムの初期化
s3 = s3fs.S3FileSystem()

# Parquet形式で保存（圧縮・列指向）
table = pa.Table.from_pandas(df)
pq.write_table(
    table,
    's3://my-bucket/data/sales_2025-10-27.parquet',
    filesystem=s3,
    compression='snappy'
)

データレイクは、コストが安く柔軟性が高い一方で、データ管理やクエリ性能に工夫が必要です。

リレーショナルデータベース
トランザクション処理と分析の両方に使えます。PostgreSQL、MySQLなどが一般的です。

from sqlalchemy import create_engine

# データベース接続
engine = create_engine('postgresql://user:pass@localhost/db')

# バッチ挿入でパフォーマンス向上
df.to_sql('orders',
          con=engine,
          if_exists='append',
          index=False,
          method='multi',  # 複数行を一度に挿入
          chunksize=1000)  # 1000行ずつ処理

パフォーマンス最適化

大量データのロードでは、パフォーマンスが重要な課題になります。

バッチ処理
一行ずつ挿入するのではなく、まとめて処理します。

# 遅い方法（一行ずつINSERT）
for _, row in df.iterrows():
    cursor.execute("INSERT INTO products VALUES (%s, %s)", 
                   (row['id'], row['name']))

# 速い方法（バルクINSERT）
values = [tuple(row) for row in df.values]
cursor.executemany("INSERT INTO products VALUES (%s, %s)", values)

バルクINSERTは、通常10〜100倍高速です。

パーティショニング
データを時間やカテゴリで分割して保存します。

# 日付ごとにファイルを分割保存
for date, group in df.groupby(df['order_date'].dt.date):
    filename = f's3://bucket/orders/date={date}/data.parquet'
    group.to_parquet(filename)

これにより、特定期間のデータのみを読み込むクエリが高速化されます。

圧縮の活用
ストレージコストと転送時間を削減します。

# Parquet: 列指向フォーマットで高圧縮
df.to_parquet('data.parquet', compression='gzip')

# CSV: gzip圧縮（互換性重視）
df.to_csv('data.csv.gz', compression='gzip', index=False)

Parquet形式は、分析ワークロードで圧縮率が特に高くなります。

エラーハンドリングとリトライ

ロード処理では、ネットワーク障害やリソース不足などの一時的なエラーが発生することがあります。

import time
from tenacity import retry, stop_after_attempt, wait_exponential

@retry(
    stop=stop_after_attempt(3),  # 最大3回リトライ
    wait=wait_exponential(multiplier=1, min=4, max=10)  # 指数バックオフ
)
def load_to_database(df, table_name):
    """データベースへのロード（リトライ付き）"""
    try:
        df.to_sql(table_name, con=engine, if_exists='append', index=False)
        print(f"{len(df)} rows loaded successfully")
    except Exception as e:
        print(f"Load failed: {e}")
        raise  # リトライのため再送出

トランザクションの活用
複数のロード操作を一つのトランザクションにまとめ、すべて成功するか、すべて失敗するかを保証します。

from sqlalchemy import text

try:
    with engine.begin() as conn:
        # 複数のテーブルに関連データをロード
        df_customers.to_sql('customers', con=conn, 
                           if_exists='append', index=False)
        df_orders.to_sql('orders', con=conn, 
                        if_exists='append', index=False)
        df_items.to_sql('order_items', con=conn, 
                       if_exists='append', index=False)
        # すべて成功すればコミット
except Exception as e:
    # どれか失敗すればすべてロールバック
    print(f"Transaction failed: {e}")
    raise

データ品質の検証

ロード後、データが正しく保存されたかを確認します。

# ロード前のレコード数
original_count = len(df)

# ロード実行
df.to_sql('products', con=engine, if_exists='append', index=False)

# ロード後の確認
with engine.connect() as conn:
    result = conn.execute(text("SELECT COUNT(*) FROM products"))
    db_count = result.scalar()
    
    # 期待値との比較
    expected_count = original_count + previous_count
    if db_count != expected_count:
        print(f"警告: レコード数の不一致 (期待値: {expected_count}, 実際: {db_count})")

データ整合性のチェック
主要なメトリクスが想定範囲内かを確認します。

# 基本統計量の比較
stats_before = df['amount'].describe()

with engine.connect() as conn:
    query = "SELECT AVG(amount), MIN(amount), MAX(amount) FROM orders"
    stats_after = pd.read_sql(query, conn)

# 大きな乖離があれば警告
if abs(stats_before['mean'] - stats_after['AVG'][0]) > 100:
    print("警告: 金額の平均値に大きな差異があります")

インクリメンタルロードの実装（←更新ロードのことです）

効率的なインクリメンタルロードの実装例を示します。

def incremental_load(df, table_name, key_column, updated_column):
    """
    インクリメンタルロード
    - 既存レコードは更新
    - 新規レコードは挿入
    """
    # 最終更新時刻を取得
    with engine.connect() as conn:
        result = conn.execute(
            text(f"SELECT MAX({updated_column}) FROM {table_name}")
        )
        last_update = result.scalar()
    
    # 前回以降の変更のみフィルタ
    if last_update:
        df_new = df[df[updated_column] > last_update]
    else:
        df_new = df
    
    if len(df_new) == 0:
        print("No new data to load")
        return
    
    # 一時テーブルにロード
    temp_table = f"temp_{table_name}"
    df_new.to_sql(temp_table, con=engine, 
                  if_exists='replace', index=False)
    
    # UPSERT実行
    with engine.begin() as conn:
        conn.execute(text(f"""
            INSERT INTO {table_name}
            SELECT * FROM {temp_table}
            ON CONFLICT ({key_column})
            DO UPDATE SET
                {updated_column} = EXCLUDED.{updated_column}
        """))
    
    print(f"{len(df_new)} rows loaded")

まとめと次回予告

Loadは、変換済みデータを目的地に保存する最終ステップです。フルロード、追記ロード、更新ロードという3つの基本パターンがあり、用途に応じて使い分けます。パフォーマンス最適化、エラーハンドリング、データ検証を適切に実装することで、信頼性の高いロード処理を実現できます。

次回は、「バッチ処理の基本」について学びます。一定量のデータをまとめて処理するバッチパイプラインの設計と実装方法を、具体的なユースケースとともに解説します。

感想

ロードのパターンについては、3種類（フルロード、追記ロード、更新ロード）ありました。本文にもあった通りですが、マスタ系は更新ロード、トランザクション系は追記ロードがよさそうですね。
ロード先の選択については、単に形式や速度だけでなく様々なことを考慮する必要があるので理解を深めていきたいですね。
ではまたお会いしましょう。