データエンジニアの面接質問

回答の組み立て — 決定的な順序を持つウィンドウ関数

row_number() over (partition by event_id order by updated_at desc, ingestion_at desc, source_sequence desc)で連番を付け、1位を残します。同時刻があるためupdated_atだけでは決定的でないことがあります。 event_idが事業上のキーか、後の更新が前のイベントを置き換えるか確認します。増分処理では遡及窓またはMERGEで遅延データを扱い、冪等に書き込みます。重複、空キー、競合は黙って消さず測定します。

回答の組み立て — 有効な活動 → 日付 → 一意利用者 → 増分パーティション

まず活動として数えるイベントと、除外する試験・ボット・社内利用者を定義します。event_atを合意済みタイムゾーンと日付へ正規化し、日ごとの一意user_idを数えます。 本番用にはevent_dateでパーティション化し、再実行を冪等にし、遅延イベントを処理し、品質検査を加えます。入力・出力件数、異常な変動を監視し、定義と鮮度を文書化します。

回答の組み立て — 変化を特定 → 実行計画 → 容量 → 結合・条件 → 資源

悪化が始まった時点と、コード、スキーマ、容量、分布、統計、パーティション、計算資源の変更を確認します。実行計画を比較し、全表走査、非効率な結合、ディスク退避、偏り、パーティション絞り込み不足を探します。 行数増加、カーディナリティ、結合粒度も見ます。新しい1対多結合はデータを増幅します。早期の条件・集約、結合順、適切なパーティション・クラスタリング、統計更新、必要に応じた資源増強を試し、時間、読取量、シャッフル、費用を前後比較します。

回答の組み立て — 事業過程 → ファクト → ディメンション → 粒度 → 指標

閲覧、カート、注文、決済、発送、返品、返金、在庫、アトリビューションから始めます。候補ファクトは注文単位のfact_orders、明細単位のfact_order_items、決済、返金、発送、日次在庫スナップショットです。顧客、商品、日付、倉庫、獲得経路、キャンペーンをディメンションにします。 各粒度を明示します。カテゴリ売上は明細、顧客ライフサイクルは顧客または契約、在庫はスナップショットから求めます。属性履歴、取消、注文・明細割引、通貨、税、ゲスト購入、遅延データを考慮し、財務と取引・決済・倉庫システムへ照合します。

回答の組み立て — 履歴要件に応じてタイプ1またはタイプ2を選ぶ

タイプ1は旧値を上書きし、現在状態だけが必要な場合に適します。タイプ2は変更ごとに新しい行を作り、有効開始、有効終了、current_flag、代理キーを保持します。 顧客の地域が西から東へ変わる場合、タイプ1は過去売上も東へ付け替えます。タイプ2なら各時点で正しい地域を保持し、イベント日時に有効な版へファクトを結合できます。キー、時間結合、遅延ファクト、現在・履歴表示が複雑になるため、事業要件で選びます。

回答の組み立て — 統制・柔軟性と、単純さ・クエリ性能の比較

スタースキーマはファクトとディメンションを分け、再利用可能なディメンション、一貫した指標、明確な粒度、重複の少ない柔軟な分析に向きます。 ワイドテーブルは、利用頻度の高いダッシュボード、特定の分析、機械学習特徴量など、単純さと速度を優先する用途に適しますが、重複と定義の不一致を招きやすくなります。通常は正規のファクト・ディメンションと、利用者別のデータマート・ワイド表を組み合わせます。容量、利用者、BI、費用、遅延、変更頻度で判断します。

回答の組み立て — 抽出 → 生データ保存 → 変換 → 検証 → 公開 → 監視

鮮度、容量、元DBへの許容負荷、利用者、後日修正を確認します。updated_atまたはCDCで注文を増分抽出し、オブジェクトストレージまたはraw表へ不変コピーを保存し、stagingで整形してfact_ordersとfact_order_itemsを公開します。依存関係はオーケストレーターが管理します。 再試行はMERGE、パーティション置換、原子的な切替で決定的にします。遡及窓で遅延変更を取り込みます。行数、空キー、重複ID、売上、状態、鮮度、元DBとの照合を検査し、失敗、異常量、重複、遅延を通知します。責任者と依存先も文書化します。

回答の組み立て — 同じ入力を再処理しても同じ出力状態になる

冪等なパイプラインは同じ入力で何度実行しても、重複や意図しない副作用なしに同じ正しい状態を作ります。再試行とバックフィルに不可欠です。 非冪等な処理は再実行のたびに昨日の注文を再追加します。堅牢な方式では、対象パーティションを置き換える、主キーでMERGEする、一時領域へ書いて原子的に切り替えるなどを行います。一意キー、適切なパーティション、決定的な変換、制御された副作用が必要です。

回答の組み立て — 検出 → 分類 → 保護 → 連絡 → 移行

レジストリ、メタデータ検査、契約テスト、取り込み検証で変更を検出し、列の追加・削除・改名、型、NULL許容性、意味の変更へ分類します。NULL許容列の追加は互換なことが多い一方、改名、削除、型変更は利用側を壊します。意味だけ変わる変更はスキーマが通るため特に危険です。 生データを保持し、重要な情報源には契約と互換性ルールを適用します。互換性のない変更では上流責任者と調整し、版を分け、変換を更新し、必要なら履歴を再構築し、リネージから影響を受ける利用者へ連絡します。

回答の組み立て — 意思決定の遅延と複雑さを比較する

不正検知、運用アラート、個人化、在庫更新、直近イベントを使う機能など、低遅延が実際の価値を生む場合に選びます。日次報告、履歴分析、財務照合、時間単位の変換には、通常バッチの方が単純で安価、再現も容易です。 鮮度、容量、順序、状態処理、耐障害性、チーム経験、費用、利用者で判断します。ストリーミングは重複、遅延イベント、チェックポイント、スキーマ、監視を複雑にします。事業要件を満たす最も単純な構成を選びます。

回答の組み立て — イベント → ストリーム → 情報付加 → ルール・モデル → 対応 → 保存 → 監視

容量、遅延目標、判断内容、許容偽陽性、遮断または審査の要否を確認します。決済イベントをKafkaまたはKinesisへ送り、処理系がスキーマを検証し、event_idで重複除去し、利用者、端末、加盟店、取引速度を付加してルールまたはモデルを適用します。高リスクなら遮断、追加認証、手動審査へ送ります。イベントと判断は監査・学習用に保存します。 順序、重複、特徴量鮮度、状態量、バックプレッシャー、デッドレターキュー、再生、遅延、版管理が重要です。理由コード、偽陽性監視、ロールバックで顧客と運用を守ります。

回答の組み立て — パーティション間でデータを再配分する処理

groupBy、join、distinct、orderBy、repartitionなどで、Sparkがパーティション間のデータを再配分するときに発生します。ネットワーク転送、直列化、ディスク入出力、調整が必要です。中間結果が大きい、または頻出キーがあると一部タスクが遅延・メモリ不足になります。 早期絞り込み、必要列だけの選択、事前集約、小表のbroadcast join、適切なパーティション、偏りへのsalting、不要なdistinct・orderByの削減で抑えます。Spark UIでstage、shuffle read・write、spill、タスク時間、executorメモリを確認します。

回答の組み立て — stage特定 → データ削減 → 偏り修正 → パーティション調整 → 問題操作の除去

Spark UIとログで、失敗するstage、操作、パーティション、executorを特定します。偏り、大規模結合、collect()、大きすぎるパーティション、非効率なUDF、過剰なキャッシュが原因になり得ます。 早期に条件と列選択を適用し、partition pruning、broadcast join、頻出キーへのsalting、パーティション数を見直します。大きなcollect()や、組み込み関数で代替できるPython UDFを除き、再利用データだけをキャッシュします。メモリ増強より、分布と実行計画の改善を優先します。

回答の組み立て — 列指向、スキーマ、圧縮、predicate pushdown

Parquetは列単位で保存し、型とスキーマを保持し、効率的に圧縮し、列絞り込みとpredicate pushdownを可能にします。分析クエリは一部列だけ読むことが多いため、走査量を減らせます。 CSVは移植しやすいテキストですが、型を持たず、大きく、遅く、区切り・エスケープの問題があります。小規模な出力や交換には適しますが、データレイクやウェアハウスの主要形式にはParquetが通常高速で安価です。

回答の組み立て — 鮮度 → 完全性 → 一意性 → 妥当性 → 照合

鮮度、行数、主キーの空値、重複取引、有効な状態・通貨、許容範囲の金額・日付、注文・決済・返金・顧客間の参照整合性を確認します。 売上を決済系または財務へ照合し、季節性を考慮して前日・前週との差を監視します。試験・取消を除外し、純売上から返金を引き、通貨を正しく換算します。各アラートには責任者、対応、対象表、重大度、下流影響、手順書が必要です。

回答の組み立て — 影響評価 → 版比較 → リネージ追跡 → 緩和 → 原因修正

対象ダッシュボード、指標、利用者、期間、意思決定を確認し、新しい値が誤りか、以前の誤りを直したものかを見極めます。旧版と新版を表、パーティション、行数、一意値、合計、セグメントで比較し、リネージに沿って変更を追います。コード、スキーマ、条件、結合、重複除去、日付も確認します。 誤りなら変換または表の版を戻し、画面を停止・注記し、正しいデータを再構築します。影響、確信度、復旧見込み、過去の判断を見直す必要があるかを伝えます。

回答の組み立て — 計測 → 取り込み → 保存 → 処理 → モデリング → 提供 → ガバナンス

容量、遅延、利用者、保存期間、スキーマ進化、プライバシー、信頼性を確認します。クライアントはSDKからevent_name、利用者・セッションID、時刻、属性、アプリ版、プラットフォームを含む型付きイベントを送ります。収集系は耐久ストリームへ書き、生イベントを再生用のオブジェクトストレージと分析用ウェアハウス・レイクハウスへ保存します。 処理ではスキーマ検証、重複除去、ボット・社内利用者除外、セッション化、ID解決を行い、fact_events、fact_sessions、dim_users、データマートを作ります。契約、スキーマレジストリ、個人情報・同意ルール、リネージ、責任者、鮮度・容量アラートで守り、BI、実験、reverse ETL、feature storeへ提供します。

回答の組み立て — オフライン・オンライン整合 → 定義 → 鮮度 → 提供 → 監視

feature storeは学習と提供に再利用できる信頼性の高い特徴量を用意します。オフライン特徴量は日時・実体別にウェアハウスまたはレイクハウスへ、オンライン特徴量は低遅延のキー値ストアへ保存します。レジストリには名称、責任者、実体キー、変換、鮮度SLA、情報源、説明を記録します。 point-in-time correctnessで学習時に未来情報を使わないようにします。オンライン・オフライン変換は共通ロジックまたは厳格な比較テストを使います。鮮度、空値、分布ドリフト、提供遅延、training-serving skew、モデル影響を監視し、個人情報、リネージ、権限、廃止を統制します。

回答の組み立て — 影響 → 切り分け → 緩和 → 原因 → 再発防止

欠損、誤指標、重複、停止したダッシュボード、製品機能への影響など実害のある障害を選びます。誰がなぜ影響を受けたかを先に説明し、ログ、オーケストレーター、元データ鮮度、デプロイ、スキーマ、行数、パーティション、リネージでの切り分けと、再試行、ロールバック、修正、バックフィル、注記による緩和を説明します。 品質検査、アラート、契約、冪等な書込み、手順書、リネージ、安全な公開などの再発防止で締めます。責任と説明を示し、誰かを責めません。

回答の組み立て — 確認 → 再現 → リネージ追跡 → 解決 → 文書化

指標、表、期間、条件、期待値、事業上の根拠を具体化します。クエリを再現し、粒度、条件、結合、タイムゾーン、鮮度、定義、リネージ上の変更を確認します。 誤りなら修正して影響を伝えます。技術的には正しくても定義が異なるなら、事業定義へ合意して文書化します。未確定なら、分かっていること、確認中のこと、回答予定を伝えます。迅速で証拠に基づく対応が信頼を作ります。

回答の組み立て — 影響 → 信頼性 → 緊急性 → 依存関係 → 波及効果

事業影響、信頼性リスク、緊急性、下流依存、波及効果で優先します。売上パイプライン停止や規制リスクは任意のモデルより先です。一つの基盤改善が多数の個別依頼より価値を生む場合もあります。 障害、戦略的基盤作業、依頼、技術的負債、運用負荷を分けます。責任者、SLA、重大度、ロードマップ、明確なトレードオフを使い、何を延期し、どのリスクを受け入れるかを共有します。