2026年版 データエンジニア面接でよく聞かれる25の質問

2026年のデータエンジニア面接では、SQLの基礎知識だけでは不十分です。採用担当者は、システム設計、リアルタイムアーキテクチャ、コスト最適化、AI対応についても深く質問します。本記事では、スタートアップ企業からFAANG企業まで、データエンジニア面接で最も頻繁に出題される25の質問を、実務経験者向けの回答とともに解説します。

SQLとクエリ最適化に関する質問

SQLは、あらゆるデータエンジニアリング面接の基礎となります。シニアレベルの候補者であっても、構文ではなくパフォーマンスに焦点を当てたSQL質問に直面します。

1. ウィンドウ関数とGROUP BYの違いは何ですか？

GROUP BYは行を集約結果に折りたたみ、行数を削減します。一方、ウィンドウ関数は、現在の行に関連する行のセット全体で値を計算しますが、行を折りたたすことはありません。出力では元の行がすべて保持されます。

-- GROUP BY: one row per department
SELECT department, AVG(salary) AS avg_salary
FROM employees
GROUP BY department;

-- Window function: every row preserved, avg added
SELECT
  employee_id,
  department,
  salary,
  AVG(salary) OVER (PARTITION BY department) AS dept_avg
FROM employees;

ウィンドウ関数は、行レベルの詳細と集約コンテキストの両方が同時に必要な場合に不可欠です。これは、データ品質チェックやレポートパイプラインでよく求められる要件です。

2. 5億行のファクトテーブルで遅いクエリをどのように最適化しますか？

体系的なアプローチが最も効果的です。

1. 実行プランを確認する（EXPLAIN ANALYZE）：フルテーブルスキャン、インデックスのない列でのハッシュ結合、ディスクへのスピルを特定します。
2. テーブルをパーティション化する：日付またはクエリフィルタと一致する高カーディナリティの列でパーティション分割します。
3. 対象を絞ったインデックスを追加する：頻繁にフィルタリングされる列にインデックスを作成しますが、過度なインデックス作成は避けます（各インデックスは書き込みオーバーヘッドを増やします）。
4. 中間結果をマテリアライズする：同じサブクエリが複数のダッシュボードで繰り返し実行される場合に有効です。
5. 述語をプッシュダウンする：早期にフィルタリングして、ステージ間でシャッフルされるデータを削減します。

面接官が求める重要なシグナルは、最適化が反復的でコンテキスト依存であり、チェックリストではないことを理解していることです。

3. CTE、サブクエリ、一時テーブルの違いを説明してください。それぞれをいつ使用しますか？

CTE（共通テーブル式）は、可読性を向上させ、再帰クエリを可能にします。ほとんどのクエリエンジンはCTEをインライン展開するため、パフォーマンスはサブクエリと同等です。一時テーブルはデータを物理的にマテリアライズするため、同じ中間結果がセッション内で複数の下流クエリに供給される場合に役立ちます。サブクエリは、シンプルな一度限りの変換に適しています。

経験則：明確さのためにはCTE、再利用のためには一時テーブル、単純なインラインフィルタにはサブクエリを使用します。

高度なSQLパターンの詳細については、SQL for Data Analysts: Window Functions, CTEs and Advanced Queriesをご覧ください。

ETLとELT、データパイプラインアーキテクチャ

パイプライン設計に関する質問は、アーキテクチャ思考をテストします。面接官は、ツールの擁護ではなく、トレードオフ分析を見たいと考えています。

4. ETLとELT：どちらをいつ選択しますか？

| 基準 | ETL | ELT | |----------|-----|-----| | 変換の場所 | ロード前（外部コンピューティング） | ロード後（ウェアハウスコンピューティング） | | 最適な用途 | レガシーシステム、厳格なスキーマ | クラウドウェアハウス（BigQuery、Snowflake） | | スキーマの柔軟性 | 低（変換が早期にスキーマを固定） | 高（生データが再変換に利用可能） | | コストモデル | ウェアハウス外のコンピューティング | ウェアハウスのコンピューティングコストが変換に応じてスケール | | データの鮮度 | レイテンシーが高い（変換ステップ） | レイテンシーが低い（先にロード、オンデマンド変換） |

ELTは、ストレージが安価で、コンピューティングが弾力的にスケールし、生データを保持することでスキーマの進化が可能になるため、現代のクラウドネイティブスタックで主流となっています。ETLは、規制要件によりデータがウェアハウスに入る前に変換が必要な場合（PIIスクラビングなど）に依然として関連性があります。

5. 冪等なデータパイプラインを設計してください。冪等性がなぜ重要ですか？

冪等性は、同じ入力でパイプラインを複数回実行しても、データを重複させることなく同じ結果が得られることを保証します。これが重要なのは、パイプラインが失敗して再試行されるためです。

実装戦略：

• アップサートパターン：自然キーまたは複合キーに基づくMERGEまたはINSERT ... ON CONFLICT
• パーティション上書き：追加ではなく、日付パーティション全体を置き換える
• 書き込み時の重複排除：決定論的ID（ビジネスキー＋イベントタイムスタンプのハッシュ）を割り当てる

# partition_overwrite.py
# Idempotent write: overwrite the entire partition for a given date
from pyspark.sql import SparkSession

spark = SparkSession.builder.appName("idempotent_load").getOrCreate()

df = spark.read.parquet("s3://raw-events/2026-04-11/")

# Transform: deduplicate by event_id, keep latest
df_deduped = (
    df.orderBy("event_timestamp", ascending=False)
    .dropDuplicates(["event_id"])
)

# Overwrite only the target partition
df_deduped.write \
    .mode("overwrite") \
    .partitionBy("event_date") \
    .parquet("s3://warehouse/events/")

このアプローチにより、4月11日の実行を再試行すると、重複行を追加するのではなく、4月11日のパーティションが置き換えられます。

6. データリネージとは何ですか？なぜ本番パイプラインで重要ですか？

データリネージは、パイプライン全体でのデータの起源、移動、変換を追跡します。どこからこの数値が来たのか、どのような変換が適用されたのか、どの下流システムがそれに依存しているのかという質問に答えます。

実用的価値：ダッシュボードが予期しない値を表示する場合、リネージにより、数時間ではなく数分で根本原因分析が可能になります。OpenLineage、dbt docs、クラウドネイティブリネージ（BigQueryの列レベルリネージ）などのツールがこれを自動化します。

ストリーミングとリアルタイムデータ処理

ストリーミングに関する質問は、「Kafkaとは何か」から、ストリーミングをいつどのように使用するかのアーキテクチャ決定に移行しています。

7. バッチとストリーミング：どちらを使用するかをどのように決定しますか？

この決定は、技術的な好みではなく、レイテンシー要件に依存します。

• バッチ：データ消費者が数分から数時間の遅延を許容できる場合に適切です。構築、テスト、デバッグが簡単で、ほとんどのワークロードで運用コストが低くなります。
• ストリーミング：ビジネスロジックが1分未満の鮮度に依存する場合に必要です：不正検出、リアルタイム価格設定、ライブダッシュボード。
• マイクロバッチ：実用的な中間地点（Spark Structured Streamingなど）で、バッチのようなシンプルさでほぼリアルタイムを提供します。

最も強力な回答は、ほとんどのパイプラインはバッチとして開始し、具体的なレイテンシーSLAが要求する場合にのみストリーミングに移行すべきであることを認識しています。

8. Kafkaのアーキテクチャを説明してください：トピック、パーティション、コンシューマグループ

Kafkaは、データをトピック（論理チャネル）に編成します。各トピックは、ブローカー間で分散されたパーティション（順序付けされた不変のログ）に分割されます。プロデューサーはレコードをパーティションに書き込みます（ラウンドロビンまたはキーベース）。コンシューマグループは読み取りを並列化します：各パーティションはグループ内の正確に1つのコンシューマに割り当てられ、水平スケーリングが可能になります。

重要なトレードオフ：パーティションを増やすと並列性が向上しますが、ブローカーへのオーバーヘッド（ファイルハンドル、レプリケーション）が追加されます。一般的な出発点は、トピックあたり6〜12パーティションで、スループット要件に基づいてスケーリングします。

9. ストリーミングパイプラインで遅延データをどのように処理しますか？

分散システムでは、遅延データは避けられません。3つのアプローチがあります。

1. ウォーターマーク：しきい値（例：10分）を定義し、それを超えた遅延データは破棄します。Apache FlinkとSpark Structured Streamingはこれをネイティブサポートしています。
2. ウィンドウの再処理：最近の時間ウィンドウの集約を定期的に再実行して、遅れて到着したデータをキャプチャします。
3. Delta/アップサートシンク：更新をサポートする可変ストア（Delta Lake、Apache Iceberg）に書き込み、遅延レコードが以前の結果を修正できるようにします。

適切なアプローチは、下流の消費者が正確に1回のセマンティクスを必要とするか、最終的な整合性を許容できるかによって異なります。

データモデリングとスキーマ設計

データモデリングに関する質問は、候補者がデータの保存方法だけでなく、消費方法についても考えているかどうかを明らかにします。

10. スタースキーマとスノーフレークスキーマ：トレードオフは何ですか？

スタースキーマは、ディメンションテーブルを中央のファクトテーブルに結合されたフラットで幅広いテーブルに非正規化します。スノーフレークスキーマは、ディメンションをサブディメンションに正規化します。

| 側面 | スタースキーマ | スノーフレークスキーマ | |--------|------|-----------| | クエリパフォーマンス | 速い（結合が少ない） | 遅い（結合が多い） | | ストレージ | 高い（冗長データ） | 低い（正規化） | | 複雑さ | 理解が簡単 | より複雑な関係 | | メンテナンス | ディメンションの更新が困難 | サブディメンションの更新が容易 | | 最適な用途 | BI/レポート（読み取り重視） | 厳格な正規化が必要な状況 |

実際には、クエリパフォーマンスとシンプルさがストレージの節約を上回るため、分析ウェアハウス（BigQuery、Snowflake、Redshift）ではスタースキーマが主流です。詳細については、data modeling interview moduleをご覧ください。

11. 緩やかに変化するディメンション（SCD）とは何ですか？タイプ1、2、3を説明してください。

SCDは、ディメンション属性が時間とともにどのように変化するかを追跡します。

• タイプ1：古い値を上書きします。履歴がありません。シンプルですが、情報が失われます。
• タイプ2：バージョン追跡（valid_from、valid_to、is_current）を使用して新しい行を追加します。完全な履歴が保持されます。本番ウェアハウスで最も一般的です。
• タイプ3：以前の値の列を追加します（current_city、previous_city）。限定的な履歴（1つの変更のみ追跡）。

タイプ2は、ほとんどのビジネスディメンション（顧客の住所、製品カテゴリ、従業員部門）のデフォルトの選択肢です。監査証跡と履歴レポートにはこれが必要だからです。

12. リアルタイム分析と長期保存の両方のためにイベントデータをどのようにモデル化しますか？

2層アプローチが有効です。

1. ホット層：イベントをリアルタイムストア（Apache Druid、ClickHouse、またはウェアハウスのマテリアライズドビュー）にストリーミングし、最近のデータの低レイテンシー集約用に最適化します。
2. コールド層：生イベントをレイクハウス（Delta Lake、Iceberg）に日付でパーティション分割して配置し、アドホック分析とML特徴エンジニアリングのために無期限に保持します。

ホット層は、速度のために事前集約または非正規化されたスキーマを使用します。コールド層は完全な粒度を保持します。調整ジョブは、両方の層が一致することを定期的に検証します。

Apache Sparkと分散処理

Sparkに関する質問は、API呼び出しだけでなく、並列性とパフォーマンスの理解に焦点を当てています。

13. Sparkでデータスキューが発生する原因と修正方法は何ですか？

データスキューは、1つのパーティションが他のパーティションよりも不釣り合いに多くのデータを保持し、単一のタスクがステージ全体のボトルネックになる場合に発生します。

一般的な原因：優位な値を持つキーでの結合（nullキー、単一の人気製品ID）、または低カーディナリティ列によるパーティション分割。

修正方法：

• ソルティング：スキューしたキーにランダムなサフィックスを追加し、ソルトされたキーで結合してから、ソルトを削除するために集約します。
• ブロードキャスト結合：片側が十分に小さい場合（通常<200MB）、ブロードキャストしてシャッフルを完全に回避します。
• AQE（適応クエリ実行）：Spark 3.x+は、ランタイムでスキューしたパーティションを自動検出して分割できます。

# salting_technique.py
# Fix skewed join by salting the large table's key
from pyspark.sql import functions as F

SALT_BUCKETS = 10

# Add salt to the large (skewed) table
large_df = large_df.withColumn(
    "salted_key",
    F.concat(F.col("join_key"), F.lit("_"), (F.rand() * SALT_BUCKETS).cast("int"))
)

# Explode the small table to match all salt values
small_df = small_df.crossJoin(
    spark.range(SALT_BUCKETS).withColumnRenamed("id", "salt")
).withColumn(
    "salted_key",
    F.concat(F.col("join_key"), F.lit("_"), F.col("salt"))
).drop("salt")

# Join on salted key (evenly distributed)
result = large_df.join(small_df, "salted_key")

これにより、ワークロードがエグゼキュータ間で均等に分散され、ボトルネックが解消されます。

14. Sparkの変換とアクションの違いを説明してください。

変換（map、filter、select、join）は遅延評価されます：論理プランを構築しますが、何も実行しません。アクション（count、collect、write）は、プランをクラスタに送信することで実際の計算をトリガーします。

この遅延評価により、Sparkのカタリストオプティマイザーは、データが移動する前に操作を並べ替え、述語をプッシュダウンし、不要なシャッフルを排除できます。この区別を理解することはデバッグに不可欠です：遅いように見える変換は実際には問題なく、ボトルネックはそれをトリガーするアクションにあります。

15. repartition()とcoalesce()の違いは何ですか？

repartition(n)は、完全なシャッフルを実行して正確にn個のパーティションを作成し、データを均等に分散します。並列性を高めたり、スキューしたパーティションを再バランスしたりするために使用します。

coalesce(n)は、隣接するパーティションをマージすることでシャッフルなしでパーティションを削減します。書き込み前にパーティション数を減らすために使用します（多数の小さなファイルを回避）。

ルール：削減にはcoalesce、増加または再バランスにはrepartition。

オーケストレーションとパイプライン管理

オーケストレーションに関する質問は、運用の成熟度をテストします：パイプラインが本番環境でどのように実行、失敗、回復するか。

16. Airflow、Dagster、Prefectを比較してください。それぞれをいつ選択しますか？

| 機能 | Airflow | Dagster | Prefect | |---------|---------|---------|--------| | 成熟度 | 最も成熟、最大のコミュニティ | 成長中、ML/データチームで強い | クラウドファースト、強力なDX | | コア抽象化 | タスクのDAG | アセット（データ中心） | フローとタスク | | テスト | 困難（DAGレベル） | 組み込みアセットテスト | 優れたタスクレベルテスト | | ローカル開発 | Docker/コンテナが必要 | ネイティブローカル実行 | ネイティブローカル実行 | | 最適な用途 | 複雑で長時間実行されるETL | データメッシュ/アセット指向チーム | 最小限のインフラを望むチーム |

Airflowは、成熟したデータプラットフォームの業界標準のままです。Dagsterは、タスクシーケンスではなくデータアセットの観点で考えるチームに適しています。Prefectは、Airflowのようなオーケストレーションを運用オーバーヘッドを減らして実現したいチームに魅力的です。Airflow固有の面接準備については、Airflow fundamentals moduleをご覧ください。

17. 本番環境でのパイプライン障害とアラートをどのように処理しますか？

本番グレードの障害戦略には以下が含まれます。

1. バックオフ付き再試行：一時的な障害（ネットワークタイムアウト、APIレート制限）は、指数バックオフ再試行で解決されます。
2. デッドレターキュー：ポイズンメッセージは、パイプラインをブロックせずに手動検査のために別のキューにルーティングされます。
3. サーキットブレーカー：N回連続して失敗した後、パイプラインを一時停止し、不良データで下流システムをあふれさせるのではなく、アラートを発します。
4. 観測可能性：構造化ログ、メトリクス（タスク期間、行数、エラー率）、および各パイプラインステージでのデータ品質チェック（Great Expectations、dbtテスト）。
5. アラートティア：P1（パイプラインダウン、データ欠落）はオンコールにページを送信します。P2（データ品質ドリフト）は翌営業日のSlack通知を送信します。

18. パイプラインを「本番準備完了」とプロトタイプにするものは何ですか？

本番準備完了とは、冪等な実行、自動再試行、監視とアラート、取り込みと変換ステージでのデータ検証、データコントラクトのドキュメント、バージョン管理されたパイプライン定義、およびテストされたロールバックパスを意味します。プロトタイプにはこれらのいずれもありません。この2つの間のギャップは、ほとんどのパイプライン技術負債が蓄積される場所です。

クラウドデータプラットフォームとレイクハウスアーキテクチャ

クラウドプラットフォームに関する質問は、候補者がベンダー固有の構文を超えて、コスト、スケール、アーキテクチャのトレードオフを理解しているかどうかを評価します。

19. レイクハウスとは何ですか？なぜ支配的なアーキテクチャになったのですか？

レイクハウスは、データレイク（スキーマオンリード、生データストレージ、複数のファイル形式）の柔軟性と、データウェアハウス（ACIDトランザクション、スキーマ強制、クエリ最適化）の信頼性を組み合わせたものです。Delta Lake、Apache Iceberg、Apache Hudiなどのテクノロジーは、オブジェクトストレージ（S3、GCS、ADLS）の上にメタデータ/トランザクション層を追加することでこれを可能にします。

レイクハウスが勝つのは、レイクとウェアハウス間のコストのかかるETL層を排除し、同じデータでBIクエリとMLワークロードの両方をサポートし、安価なオブジェクトストレージを活用するためです。

20. クラウドウェアハウスのコスト（BigQuery、Snowflake、Redshift）をどのように最適化しますか？

コスト最適化戦略：

• テーブルのパーティション化とクラスタ化：クエリごとにスキャンされるバイト数を削減
• 適切なウェアハウスサイズの設定（Snowflake）またはスロット予約（BigQuery）：ワークロードパターンに基づく
• アイドルリソースの自動サスペンド：Snowflakeウェアハウスは、非アクティブ後1〜5分で自動サスペンドする必要があります
• クエリごとのコスト監視：BigQueryのINFORMATION_SCHEMA.JOBSビューで高価なクエリが明らかになります
• マテリアライズドビューの使用：繰り返し計算される集約用
• コールドデータのアーカイブ：ライフサイクルポリシーを使用した安価なストレージ層へ

面接シグナル：候補者がコストを事後的な考えではなく、第一級のエンジニアリング制約として考えていること。

データ品質とガバナンス

データ品質に関する質問は、パイプラインを出荷するエンジニアと、信頼できるデータプラットフォームを維持するエンジニアを区別します。

21. パイプラインでデータ品質チェックをどのように実装しますか？

データ品質チェックは3つのステージに属します。

1. 取り込み：スキーマ準拠の検証、プライマリキーのnullチェック、ソースに対する行数しきい値の確認。
2. 変換：ビジネスルールのアサート（例：収益 > 0、有効範囲内の日付）、テーブル間の参照整合性チェック。
3. サービング：メトリクスドリフトの監視（デイリーアクティブユーザーの50%の突然の減少は、ビジネスの変化ではなくパイプラインの問題を示す可能性があります）。

ツール：dbtテスト（スキーマとカスタム）、Great Expectations、Soda Core、Monte Carlo（データ観測可能性）。最良のアプローチは、チェックをパイプラインDAGに直接統合して、失敗が下流処理をブロックするようにします。

22. データコントラクトとは何ですか？パイプラインの破損をどのように防ぎますか？

データコントラクトは、データプロデューサーとその消費者の間の正式な合意であり、以下を指定します：スキーマ（列名、型、null可能性）、鮮度SLA（午前6時UTCまでにデータが利用可能）、ボリューム期待値（毎日100万〜1000万行）、およびセマンティックルール（ステータスフィールドにはACTIVE、INACTIVE、SUSPENDEDのみが含まれる）。

プロデューサーがコントラクトを更新せずにスキーマを変更すると、自動検証が不一致を下流に伝播する前にキャッチします。これにより、パイプラインの障害が、サイレントなデータ破損から明示的で実行可能なエラーに移行します。

システム設計とアーキテクチャ

システム設計ラウンドは、ミッドからシニアのデータエンジニアリングの役割で標準的です。これらはエンドツーエンドの思考をテストします。

23. eコマースプラットフォーム向けのリアルタイム分析パイプラインを設計してください。

堅実な設計は以下に対処します。

取り込み：クリックストリームイベントとトランザクションイベントはKafkaトピックに流れ、ユーザーセッション内での順序保証のためにuser_idでパーティション分割されます。

処理：FlinkまたはSpark Structured StreamingジョブがKafkaから消費し、製品カタログデータでイベントをエンリッチし（ディメンションテーブルからのブロードキャスト結合）、セッションレベルおよび5分間の集約を計算します。

サービング：集約されたメトリクスは、サブセカンドレイテンシーのダッシュボードクエリ用にリアルタイムOLAPストア（ClickHouseまたはApache Druid）に配置されます。生イベントは、履歴分析用にDelta Lake/Icebergに配置されます。

データ品質：スキーマレジストリ（ConfluentまたはAWS Glue）が取り込み時にイベントスキーマを検証します。ストリーミングデータ品質チェックは異常（イベントボリュームの突然の低下）にフラグを立て、デッドレタートピックにルーティングします。

障害処理：Kafkaのコンシューマオフセットにより、チェックポイントを使用した正確に1回の処理が可能になります。ストリーミングジョブは、障害時に最後のチェックポイントから自動再起動します。

24. レガシーETLパイプラインを最新のスタックに移行するにはどうしますか？

移行はストラングラーフィグパターンに従います。

1. 監査：すべての既存のパイプライン、そのソース、変換、消費者をカタログ化します。依存関係とSLAを特定します。
2. 並列実行：古いパイプラインと並行して新しいパイプラインを構築します。両方が同じソースを消費し、別々のターゲットに書き込みます。
3. 検証：古いパイプラインと新しいパイプライン間で出力を比較します。自動調整クエリが不一致にフラグを立てます。
4. カットオーバー：2週間以上にわたって出力が許容範囲内で一致したら、消費者を新しいターゲットに切り替えます。ロールバック用に古いパイプラインを読み取り専用モードで保持します。
5. 廃止：安定期間後、レガシーパイプラインをシャットダウンします。

重要な洞察：ビッグバン移行は決して行わないでください。信頼が確立されるまで、両方のシステムを並行して実行します。

25. 重要なダッシュボードに誤った数値が表示されます。デバッグプロセスを説明してください。

体系的なアプローチ：

1. 問題の範囲を特定する：どのメトリクスが間違っていますか？いつからですか？すべてのディメンションですか、それとも特定のフィルタですか？
2. サービング層を確認する：ウェアハウスに直接クエリして、問題がダッシュボードツール（キャッシング、フィルタロジック）にあるのか、データ自体にあるのかを確認します。
3. リネージを上流にトレースする：ダッシュボードテーブルから各変換ステップを通してデータを遡ります。各ステージで行数と主要メトリクスを確認します。
4. ブレークポイントを特定する：期待値と実際の値が分岐するステージが根本原因の場所です。
5. 一般的な原因を確認する：ソースシステムのスキーマ変更、アラートされなかった失敗したパイプライン実行、処理ウィンドウを逃した遅延データ、または変換ロジックを変更したデプロイメント。
6. 修正と防止：即座の問題を修正し、それをキャッチできたはずのデータ品質チェックを追加し、ランブックを更新します。

この質問は、インシデント対応の成熟度をテストします。面接官は、ランダムな推測ではなく、構造化された思考を見たいと考えています。

データエンジニアリング面接の準備

SharpSkillのdata engineering interview preparation trackでは、ETL/ELT patterns、データモデリング、Airflow、BigQueryなどにわたるインタラクティブな練習でこれらのトピックをカバーしています。

まとめ

• SQLウィンドウ関数、CTE、クエリ最適化は、シニアレベルに関係なく基礎のままです
• ETLとELTの決定は、トレンドフォローではなく、レイテンシー要件、データガバナンスニーズ、インフラストラクチャコストによって推進される必要があります
• 冪等性、データコントラクト、データ品質チェックは、本番グレードのパイプラインとプロトタイプを区別します
• ストリーミングアーキテクチャの質問は、ツール固有の知識ではなく、トレードオフ（バッチ対ストリーミング対マイクロバッチ）に焦点を当てています
• データモデリングの選択（スタースキーマ対スノーフレークスキーマ、SCDタイプ）は、理論的なベストプラクティスではなく、消費パターンと一致する必要があります
• システム設計の回答は、ハッピーパスと並行して、障害処理、コスト最適化、観測可能性に対処する必要があります
• 最も強力な候補者は、トレードオフについての構造化された問題解決と正直な推論を示します