プロンプトと適用可能なコンテキスト
データパイプラインのリリース後、日次収益ダッシュボードが同じ営業日における決済代行業者の照合データより8%高くなっています。イベントの取り込みは少なくとも1回（at-least-once）であり、返金は遅延して到着する可能性があり、財務部門は2時間後に締め処理を行います。影響の確認、根本原因の特定、異常なデータの拡散防止、影響を受けたデータの修復、およびダッシュボードが再び信頼できることの証明をどのように行うか説明してください。
8%、2時間の期限、at-least-once配信、およびリリース時間は面接用の前提条件であり、業界のベンチマークではありません。主要なパスは、決済イベントソース、raw層、staging層、収益ファクトテーブル、セマンティック層、BIキャッシュというリネージを想定しています。決済代行業者は比較対象の候補であり、自動的に正解データ（ground truth）となるわけではありません。決済代行業者が決済日（settlement date）でグループ化し、ダッシュボードが決済イベント日（payment-event date）でグループ化している場合、両方の出力が正しくても差異が生じる可能性があります。
2026年の公開データエンジニアリング面接資料には、「ダッシュボードに誤った数値が表示される」というプロンプトが直接含まれており、データ品質、リネージ、バックフィル、SLA、インシデント対応、所有権が準備トピックとして挙げられています。コアスキルが指標のセマンティクス、データリネージ、品質アサーション、照合、安全なバックフィルであるため、カテゴリは data です。この質問は、完全なコンポーネント横断プラットフォーム設計を求めているわけではありません。
面接官が評価するポイント
第1のシグナルは、候補者が「数値の差異」と「異常なデータ」を区別できるかどうかです。ジョブをすぐに再実行すると、同じ不具合が再び書き込まれる可能性があります。優れた回答では、まず営業日、タイムゾーン、通貨、注文ステータス、そして収益がオーソリ（authorization）、売上確定（capture）、決済（settlement）、または返金後の純額（net amount）のいずれを意味するのかを確定させます。そうして初めて、8%の乖離が品質インシデントなのかセマンティクスの不一致なのかを判断できます。
第2のシグナルは、リネージを使用して最初の異常な境界（first bad boundary）を見つけられるかどうかです。最終的なダッシュボードのSQLを編集しても、不具合がどのようにシステムに入り込んだかを説明することはできません。有用な診断では、ソース、raw層、staging層、ファクトテーブル、セマンティック層、キャッシュにおいて、同じビジネスキーのカウント、金額、ステータスを比較します。目標は、上流側はまだ正しく、下流側で最初に誤りが発生した遷移箇所を特定することです。
第3のシグナルはインシデント制御です。財務部門の締め処理が迫る中、候補者は未検証の修正によって二次的なデータ破損を引き起こすことなく、復旧時間を短縮しなければなりません。そのためには、ダッシュボードに締め処理には安全でない旨のフラグを立て、異常なデータを使用するエクスポートやリバース同期を一時停止し、イミュータブルなraw入力を保持し、シャドウテーブルまたはバージョン管理されたパーティションにバックフィルを行う必要があります。
最後に、面接官は証拠の閉ループを求めています。ジョブの成功、行数の一致、またはダッシュボードが「正常に見える」ことだけでは復旧の証明にはなりません。優れた回答では、利用を再開する前に、ビジネスセマンティクスの照合、キーおよび結合カーディナリティのチェック、影響を受けたスライスの差分比較、重要なレコードの監査、財務部門の承認を組み合わせます。
回答前に明確にすべき質問
- 双方が収益を同一に定義しているか？ オーソリ、売上確定、決済、返金、チャージバック、税金、手数料、キャンセルされた注文の扱いをすり合わせます。定義が異なる場合は、予想される乖離をインシデントと呼ぶのではなく、まず比較可能なビューを構築します。
- どの時計とタイムゾーンが営業日を定義しているか？ UTC、加盟店の現地時間、代行業者の決済日によって異なる境界が引かれる可能性があります。その回答によって、影響を受けるパーティションと修復計画が変わります。
- 8%の乖離は金額の乖離か、件数の乖離か、それとも特定のスライスにおける乖離か？ 件数が正常で金額が過剰な場合は、高額イベントの重複、外国為替、または結合のファンアウトが示唆されます。件数が過剰な場合は、リプレイと重複排除のチェックの優先度が高くなります。
- 何が変更され、いつ有効になったか？ コードバージョン、ジョブランID、入力・出力データセット、最初の異常発生時刻を関連付けます。リリースのタイミングは有用な仮説になりますが、即時ロールバックを正当化する証明にはなりません。
- rawイベントはイミュータブルであり、安定した
event_idを持っているか？ もしそうであれば、チームは営業日を冪等に再構築できます。そうでない場合、復旧には上流の台帳またはスナップショットが必要であり、正確に再構築できない範囲についての明示的な境界が必要です。 - 返金と為替レートはいつ確定するか？ ダッシュボードがほぼリアルタイムの見積もりを約束している一方で、照合データがT+1にのみ完全な返金を含む場合、暫定値と確定値を分けて表示し、修正ウィンドウを定義します。
- どのコンシューマーがそのテーブルに依存しているか？ 財務エクスポート、経営陣向けダッシュボード、アラート、機械学習の特徴量、リバースETLではリスクが異なるため、封じ込めはビジネスへの影響に応じる必要があります。
- 現在の信頼できるバージョンは何か？ 検証済みのリリース前スナップショットまたはパーティションがあれば、タイムスタンプ付きの既知の正常なビューを一時的に提供できます。それがない場合は、古い数値を暗黙のうちに提供するのではなく、縮退状態を表示します。
30秒の回答フレームワーク
「私はまず、このダッシュボードを財務の締め処理用として凍結し、影響を受ける下流のエクスポートを一時停止しつつ、rawイベントを保持します。次に、収益の定義、営業日、通貨、返金ウィンドウをすり合わせ、8%の乖離が真の品質欠陥であることを確認します。リリースメタデータとリネージを使用して、ダッシュボードクエリからセマンティック層、ファクトテーブル、staging層を経てrawイベントへと遡り、各境界でユニークイベント数、純額、主要なステータスを比較します。最初の不一致箇所によって障害ドメインが特定されます。安定したイベントIDを使用して、影響を受けるパーティションをシャドウテーブルに冪等に再構築します。ソースからターゲットへの照合、結合カーディナリティのチェック、重要スライスの確認、財務サンプルの検証に合格した後、バージョンをアトミックに切り替えてキャッシュを更新します。最後に、指標定義、オーナー、アサーション、リリース識別子、アラートをデータコントラクトとランブックに組み込みます。」
ステップバイステップの詳細な回答
ステップ1：インシデントを判断できる事実を確立する。
検知時刻、最初に影響を受けた営業日、リリースバージョン、影響を受けるダッシュボード、締め処理の期限を記録します。「8%高い」という事象を、イベント数、注文数、売上確定額、返金後の純額という少なくとも4つの再現可能な数量に分割します。それらを通貨、地域、決済ステータス、時間ごとにスライスします。ブラウザのキャッシュをバイパスするためにダッシュボードクエリを直接実行し、次にセマンティック層によって生成されたSQLを実行します。SQLが正しいにもかかわらずページが誤っている場合、欠陥はフィルター、キャッシュ、またはプレゼンテーションにあります。ファクトテーブルをバックフィルしてはなりません。
指標を明示的な方程式として記述します。このシナリオでは、純収益は同じ営業日および通貨における成功した売上確定額から確認済みの返金およびチャージバックを差し引いたものを意味する場合があります。手数料、税金、為替差益が収益に含まれる場合は、それらを明示的に追加します。乖離を解消するために調査の途中で定義を変更しないでください。代行業者の決済レポートを比較対象として扱う前に、同じステータスと時間のセマンティクスにマッピングします。
ステップ2：影響を封じ込め、証拠を保全する。
ダッシュボードに「データ検証中」のマークを付け、最終信頼タイムスタンプと次回更新予定時刻を記載します。財務部門に対し、影響を受けたパーティションから締め処理を行わないよう伝えます。誤った金額を伝播させる可能性のあるエクスポート、レポート、リバース同期を一時停止します。リリース前のパーティションがすでに検証されている場合は、履歴全体をオフラインにするのではなく、影響を受けた営業日のみを隔離します。
rawイベントを削除したり、現在のテーブルを上書きしたり、パーティションを直ちに切り詰め（truncate）たりしないでください。ジョブログ、ランID、コードバージョン、データセットバージョン、入力パーティション、失敗したアサーションを保全します。OpenLineageのJob、Run、Datasetモデルは、これらの識別子がなぜ一緒に属しているかを示しています。どの実行がどの入力を読み取り、どの出力を生成したかを知ることが、影響範囲の特定と限定的な修復の再現性を可能にします。
ステップ3：リネージをたどって最初の異常な境界を特定する。
同じ営業日とビジネスキーについて、以下の下流から上流へのチェックリストを作成します。
| 境界 | 比較内容 | 典型的な証拠 |
|---|---|---|
| BIキャッシュ → セマンティック層 | クエリテキスト、フィルター、キャッシュ時刻、結果ハッシュ | 直接クエリは正しいが、ページが古いまま |
| セマンティック層 → 収益ファクト | 計算式、結合カーディナリティ、タイムゾーン、通貨 | 結合後に行数または金額が増大 |
| ファクトテーブル → staging | ユニークイベント、状態遷移、返金マッチング | 重複した event_id または未適用の返金 |
| staging → raw | パース済み件数、スキーマバージョン、拒否されたレコード | 新しいフィールドによってパースやデフォルト値が変更 |
| raw → 決済イベントソース | ソース件数、金額、リプレイバッチ、遅延イベント | 上流での重複送信または不完全なバッチ |
すべての層で同じ営業日、通貨、ステータスセットを使用します。まず集計値を比較し、次に差分をアンチ結合（anti-join）してビジネスキーをサンプリングします。不一致がある最初の境界を見つけることで、「パイプライン内のどこか」から1つの変換または転送ステップへと調査対象を絞り込めます。
リリース後の候補となる仮説には以下が含まれます：event_id による重複排除が行われていないat-least-onceリプレイ、複数行のディメンションに対する注文の結合ファンアウト、売上確定がイベント時間を使用しているのに対して処理時間でパーティション化された返金、一部のパーティションのみが完了した後にバッチ全体が再試行されたこと、複数の有効なバージョンに一致する為替レートの結合、または収益にデフォルトで含まれてしまう新しいステータス。これらは検証して棄却すべき仮説です。「ディメンションの結合がファンアウトしている場合、重複したディメンションキーを持つ通貨でのみ増幅が発生する」といった予測を各仮説に立て、コードを変更する前にそれをテストします。
ステップ4：復旧メカニズムを選択する。
欠陥がキャッシュのみにある場合は、関連するキーを無効化し、新しいクエリを検証します。セマンティックの計算式が誤っている場合は、修正のバージョン管理を行い、その指標を使用するすべてのダッシュボードを確認します。ファクトテーブルが破損している場合は、影響を受ける最小限のパーティションと信頼できる入力を特定し、シャドウテーブルまたは新しいデータバージョンに再構築します。
- イミュータブルな
event_idで重複排除します。イベントにバージョンがある場合は、明示的なバージョンルールまたは状態遷移ルールを適用します。 - 返金、チャージバック、通貨をビジネスキーによって関連付け、再実行しても同じ結果が得られるようにします。
- バックフィルの範囲を限定し、通常の増分ジョブが安全に続行できるようにウェアハウスの負荷を調整します。
- 本番環境を直接上書きするのではなく、シャドウ出力に対して構造、ビジネス、照合のチェックを実行します。
- 検証後、ビューまたはテーブルのバージョンをアトミックに切り替え、BIキャッシュを更新し、下流のジョブを再開します。
rawデータに重複が含まれていても安定したキーが存在する場合は、rawから再構築します。重要なイベントが欠落しており、上流に台帳やスナップショットがある場合は、そのソースから再抽出します。復旧可能なソースが存在しない場合は、完全な修復を主張してはなりません。財務部門に対し、確認された範囲、説明できない差異、および調整計画を伝えます。
ステップ5：3つのクラスのチェックで復旧を証明する。
構造チェックは、スキーマ、not null、ユニーク性、許容値、参照整合性をカバーします。dbtでは、組み込みの汎用データテストとして unique、not_null、accepted_values、relationships がドキュメント化されています。これらは重複キー、nullキー、未知のステータス、孤立レコードを検出しますが、ビジネスの照合を代替するものではありません。
ビジネスチェックは、指標の不変条件（invariants）を強制します。返金が二重に差し引かれてはならない、注文の純額がその成功した売上確定額を超えてはならない、ファクトテーブルの結合によって注文キーの数が予期せず増加してはならない、などです。照合では、営業日、通貨、ステータスごとにソースとシャドウの件数および金額を比較し、レコードレベルの差分を調査します。過剰カウントと欠落が互いに相殺される可能性があるため、合計の一致だけでは不十分です。
復旧ゲートを事前に定義します。影響を受けるスライスのすべてのハードアサーションに合格すること、ソースからターゲットへのすべての差分がセマンティクス、遅延到着ウィンドウ、または記録された例外によって説明されること、サンプリングされた売上確定、返金、複数通貨の注文がエンドツーエンドで追跡できること、財務部門が締め処理の定義を確認することです。次の実行で不具合が再現しないよう、少なくとも1回の通常の増分サイクルを観察します。
ステップ6：障害モードをガードレールへと変換する。
データコントラクトには、スキーマ、フィールドセマンティクス、営業日、通貨、ステータスマッピング、品質しきい値、サービス目標、オーナー、エスカレーションパスを含める必要があります。Data Contract CLIには、構造、セマンティクス、品質、サービスレベルを組み合わせ、CIまたは実際のデータに対してチェックできる機械可読なコントラクトが記載されています。
各チェックを最も早い有効な境界に配置します。取り込み時のスキーマおよびプライマリキーのチェック、変換後の結合カーディナリティおよびビジネス不変条件、配信前の鮮度、完全性、ソース照合です。鮮度と正確性は別々に扱います。期限通りに配信されても8%高いテーブルは依然として不合格です。コードバージョン、ランID、出力データバージョンをリリースメタデータに添付します。重要なパーティションをシャドウ実行し、読者を移行する前にデータを比較します。
アラートはアクション可能でなければなりません。データセット、営業日、失敗したルール、実際の値、しきい値、下流への影響、オーナーを指定します。リスクの低い探索用テーブルは警告後に継続できますが、財務収益テーブルはキーまたは照合の失敗時に公開をブロックする必要があります。インシデント後にバックフィルのランブックを追加し、重複、遅延返金、スキーマ変更、部分書き込み、結合ファンアウトのリハーサルを行って、復旧自体が冪等であることを証明します。
高品質な回答サンプル
「私はまずパイプラインを再実行することはしません。8%の乖離はセマンティクスによるものである可能性があり、再実行すると同じ書き込み欠陥が増幅される可能性があるためです。財務部門に締め処理用として影響を受ける営業日の使用を停止するよう伝え、最終信頼時刻を記録し、異常なパーティションからのエクスポートを一時停止し、調査のためにrawイベントと現在の出力の両方を保全します。
次に、双方の営業日、タイムゾーン、通貨、ステータスをすり合わせ、収益が売上確定額を意味するのか返金後の純額を意味するのかを判断します。代行業者が決済日ベースでレポートし、ダッシュボードが支払日ベースでレポートしている場合は、まず比較可能なビューを構築します。欠陥が確認されたら、8%を注文、イベント、売上確定、返金に分割し、時間、通貨、地域、ステータスごとにセグメント化して、いつどこで発生し始めたかを突き止めます。
ダッシュボードクエリからセマンティック層、ファクトテーブル、staging、raw層、決済ソースへと遡って追跡します。各層で、同じビジネスキーについてユニークイベント数、純額、レコード差分を比較し、正常から異常へと変わる最初の境界を探し、それをリリースおよびジョブランIDに関連付けます。セマンティック結合後に増加する通常のファクトテーブル注文数は、ファンアウトを示唆します。rawイベントとファクトイベントの重複は、at-least-onceリプレイ後の重複排除の欠如を示唆します。返金のみが少ない場合は、イベント時間、処理時間、または遅延ウィンドウの処理が疑われます。
影響を受けるパーティションのみをシャドウテーブルに再構築します。重複排除にはイミュータブルなイベントIDを使用し、返金および状態遷移ルールによって繰り返しのバックフィルが同じ出力を返すようにする必要があります。シャドウテーブルは、キー、not null、ステータス、参照整合性、結合カーディナリティ、ビジネス不変条件のチェックに合格しなければなりません。次に、営業日、通貨、ステータスごとにソースと出力を照合し、レコード差分を検査します。財務部門の承認を得て初めて、バージョンをアトミックに切り替え、キャッシュを更新し、下流のジョブを再開し、次の増分サイクルを監視します。
最後に、収益の定義、営業日、通貨、遅延修正ウィンドウ、オーナー、エスカレーションパスをデータコントラクトに記述します。取り込み、変換、配信の各境界にスキーマ、重複排除、カーディナリティ、鮮度、ソース照合のチェックを設けます。今後のリリースでは、影響を受けるパーティションをシャドウ実行し、ハードアサーションが失敗した場合は切り替えをブロックします。」
よくある間違い
- タイミングがリリースと一致しているという理由でロールバックする → 相関関係は因果関係を証明しません。セマンティクスや上流のデータも変更されている可能性があります → 最初の異常な境界とバージョンの証拠によって確認する。
- DAG全体を直ちに再実行する → 冪等でないジョブは書き込みを重複させ、破損を拡大させる可能性があります → まず封じ込めを行い、シャドウ出力への限定的なバックフィルを実行する。
- 代行業者のデータを絶対的な正解として扱う → 決済日、返金ウィンドウ、ステータス定義が異なる場合があります → 双方を同じビジネスセマンティクスにマッピングする。
- 合計金額のみを比較する → 過剰カウントと欠落が相殺される可能性があります → キー、件数、スライス、レコード差分も比較する。
- ジョブが成功したかどうかのみをチェックする → 成功はジョブが終了したことを示すだけであり、データが正しいことを示すわけではありません → 構造、ビジネス、ソース照合のアサーションを追加する。
- 本番環境で重複を直接削除する → これにより証拠が破壊され、ロールバックが安全でなくなります → rawデータを保全し、バージョン管理された出力を再構築する。
- キャッシュを更新せずにファクトテーブルを修正する → ユーザーには古い数値が引き続き表示され、修復が失敗したと判断されます → 検証済みの切り替え後に関連するキャッシュを無効化する。
- 鮮度をすべての品質と同等視する → 期限通りに届いたデータでも、重複していたり誤っていたりする可能性があります → 鮮度、完全性、正確性を別々に定義する。
- すべての欠陥に対して1つの汎用アラートを送信する → データセット、スライス、オーナーのないメッセージはアクションにつなげられません → 実際の値、影響範囲、エスカレーションパスを含める。
- 修復直後に復旧を宣言する → 次の増分実行で同じ欠陥が再作成される可能性があります → 通常の実行を観察し、新しいガードレールを検証する。
フォローアップの質問と回答
フォローアップ1：合計は一致していますが、注文レベルの照合で依然として差異があります。ダッシュボードを復旧できますか？
合計だけでは復旧できません。ある注文の過剰カウントと別の注文の欠落が相殺されている可能性があり、顧客、地域、税金のスライスは誤ったままになることがあります。ユニークな注文とイベントの差分の比較を続け、ステータス、通貨、返金関係ごとに各クラスを説明します。許容される遅延到着とセマンティクスの例外がリストアップされ、重要なコンシューマーがそれらを承認した後にのみ、合計の一致が復旧シグナルの1つになります。
フォローアップ2：rawイベントに安定した event_id がありません。どのように重複排除しますか？
まず、上流の台帳、トランザクションID、またはリプレイ可能なスナップショットを要求します。時間、金額、ユーザーから構築されたフィンガープリントは、2つの有効な支払いを誤ってマージしてしまう可能性があります。コンポジットキーが唯一の選択肢である場合は、フィールド、時間の許容範囲、競合ルールを指定し、シャドウテーブルで誤ったマージと見逃されたマージを測定し、レビュー用の例外キューを保持します。ユニーク性を証明できない場合は、ヒューリスティックな出力を正確な台帳と呼ぶのではなく、残りの不確実性を開示します。
フォローアップ3：バックフィルには6時間かかりますが、財務の締め処理は2時間後です。どうしますか？
ビジネスへの影響によって範囲を縮小します。8%の乖離が特定の通貨またはリリース後の2時間に集中している場合は、そのパーティションを優先し、検証済みのリリース前データ、影響を受ける範囲、保留中の調整内容を財務部門に提供します。バックフィルがそれでも締め処理に間に合わない場合、財務部門は代行業者または別の承認された一時的な照合データを使用し、後で調整を転記する必要があります。時間に間に合わせるために検証をスキップし、テーブル全体を未検証の出力で置き換えてはなりません。
フォローアップ4：1対多のディメンション結合がエラーの原因でした。再発をどのように防ぎますか？
ディメンションのビジネスキーのユニーク性と、有効期間が重複していないことをアサートします。結合の前後でファクトキーの数と行数を比較し、予期しない結合の増大に対して厳格なリリースゲートを課します。ディメンションが履歴バージョンを保持する必要がある場合、結合述語には有効期間内のイベント時間が必要です。ビジネスキーによってすべてのバージョンを結合することは無効です。境界タイムスタンプと重複バージョンのフィクスチャをテストします。
フォローアップ5：遅延返金によって毎日履歴が書き換えられます。ダッシュボードはいつ正確になりますか？
2つの約束を定義します。迅速な可視性と最終的な正確性です。当日のタイムスタンプ付き暫定純額を表示し、返金修正ウィンドウを定義します。そのウィンドウ内の遅延返金は冪等な修正をトリガーし、ウィンドウの経過後にほぼ確定したバージョンを公開します。その範囲外の返金は、個別の調整および監査プロセスに入ります。改訂可能な数値が確定値と誤認されないよう、ダッシュボード、データコントラクト、財務ポリシーは同じ成熟度ステータスを使用する必要があります。