NTTデータデータエンジニア面接体験記：Spark・Flink・データレイクの完全評価

NTTデータデータエンジニア面接体験記：Spark・Flink・データレイクの完全評価

まず結論から：NTTデータのビッグデータ面接は本当にハードコアで、暗記だけでは通りません。3回の技術面接を受け、Hive SQL最適化からSparkの原理、Flinkリアルタイム計算とデータレイクアーキテクチャまで、各ラウンドで基礎理解と実戦経験を深く掘り下げられました。今日は面接プロセス全体を完全に振り返り、ビッグデータ面接を準備中の方の参考になればと思います。

背景：3年のビッグデータ経験、NTTデータプラットフォーム

大学で計算機科学を専攻し、中規模インターネット企業で3年間ビッグデータ開発に従事しました。主にオフラインデータウェアハウスの構築とリアルタイムデータパイプラインを担当。日常的にHiveでETLを書き、Sparkでバッチ処理、Flinkでリアルタイムストリーム処理、データレイクにはIcebergを使用していました。正直、3年間で多くの罠に踏み込みましたが、その罠が面接では逆にアドバンテージになりました——面接官は「どんな問題に遭遇し、どう解決したか」を好んで聞きます。

NTTデータのデータプラットフォームに応募したのは、友人のリファラルで、データ規模が大きく技術スタックが最新だと聞いたからです。履歴書を提出してから約2日でHRから電話があり、一次面接の日程を調整しました。

1. 面接プロセスの振り返り

一次面接：Hive+Sparkの原理（約60分）

一次面接の面接官は30代前半のテックリード。簡単な自己紹介の後、すぐに技術的な質問に入りました。

最初の質問で少し緊張しました：「Hive SQLの実行フローはどうなっていますか？SQLを書いてから最終的な結果が出力されるまで、どのようなステップを経ますか？」

解析→意味分析→論理計画→物理計画→実行の順序で説明し、CBOとRBOの違いを特に強調しました。面接官が追及：「CBOはどのように統計情報を収集しますか？統計情報が古くなったらどうしますか？」これは以前実際に遭遇したことがあったので、ANALYZE TABLEによる統計情報収集と動的パーティションプルーニングの原理を説明しました。

次にSparkについて：「Sparkのシャッフルプロセスはどうなっていますか？シャッフルライトとシャッフルリードはそれぞれ何をしますか？」MapReduceのシャッフルと比較しながら、SortShuffleManagerの3つの実装（BypassMergeSortShuffleHandle、UnsafeShuffleHandle、BaseSortShuffleHandle）と、それぞれがいつ使用されるかを説明。面接官は満足そうに頷きました。

その後、シナリオ問題：「500GBのHiveテーブルがあり、毎日10GBが増分書き込みされます。日次の集計統計を最適化するにはどうしますか？」パーティション戦略、小ファイルマージ、Z-Orderソート、SparkによるHive計算エンジンの代替案を説明。面接官がさらに追及：「このテーブルに10万のパーティションがある場合は？」パーティションプルーニングとパーティションレベルの統計情報最適化について説明しました。

一次面接の最後はオープンクエスチョン：「オフラインデータウェアハウスの最大のペインポイントは何だと思いますか？どう解決しますか？」データ遅延問題とLambdaアーキテクチャの複雑さについて説明し、Kappaアーキテクチャとデータレイクのソリューションを紹介。面接官は「いいですね、二次面接でこれらを深く掘り下げましょう」と言いました。

二次面接：Flinkリアルタイム計算+データレイク（約70分）

二次面接はよりシニアな技術エキスパートで、すぐにFlinkの質問から始まりました。

「FlinkのCheckpointメカニズムはどうなっていますか？Exactly-Onceセマンティクスはどのように保証されますか？」Chandy-Lamportアルゴリズムから説明し、バリアの整列・非整列モード、Flink Kafka Connectorにおける2相コミット（2PC）の実装について説明。面接官が追及：「Checkpointが常に失敗する場合、どうトラブルシューティングしますか？」Checkpointタイムアウト、状態のサイズ過大、バックプレッシャーなどの一般的な原因と調査方法を説明しました。

非常に実践的な質問：「Flinkのウィンドウトリガー遅延はどう処理しますか？例えば、イベントタイムウィンドウが既に発火した後、遅延データが到着した場合。」allowedLatenessとサイド出力ストリーム（Side Output）のソリューションを説明し、ビジネス面で下流と遅延データの処理戦略をどう調整するかも補足しました。

データレイク部分では：「IcebergとHudiの違いは何ですか？なぜIcebergを選んだのですか？」COWテーブルとMORテーブルの実装の違い、Icebergのメタデータ管理における利点（Hive Metastoreに依存しないスナップショット分離）を説明。面接官が追及：「Icebergのスナップショット有効期限メカニズムはどうなっていますか？スナップショットが期限切れになったが、Flinkジョブがまだそのスナップショットのデータを読んでいる場合はどうなりますか？」これは以前まさに踏んだ罠だったので、同時変更異常とデータファイル削除の問題、Snapshot IDによる読み取り一貫性の保証ソリューションを説明しました。

二次面接には設計問題もありました：「秒レベルのレイテンシでAD-HOCクエリをサポートするリアルタイムデータウェアハウスを設計してください。」Flink+Iceberg+Prestoのアーキテクチャを提案。FlinkがIcebergにリアルタイム書き込み、Prestoがクエリエンジン、Icebergのスナップショットメカニズムで一貫性を保証。面試官がデータ鮮度とクエリパフォーマンスのトレードオフについて追及し、Mini CommitとCompactionの戦略を説明しました。

三次面接：システム設計+プロジェクト深掘り（約50分）

三次面接は部門責任者で、スタイルが全く異なり、マクロな思考とプロジェクトの深さに焦点を当てていました。

最初の質問：「最も挑戦的だったプロジェクトは何ですか？どんな問題に遭遇しましたか？どう解決しましたか？」以前取り組んだリアルタイムデータパイプラインの再構築プロジェクトについて、LambdaアーキテクチャからKappaアーキテクチャへの移行、状態移行、データ一貫性検証、バックフィル計算などの問題に遭遇したことを説明。面接官は詳細に追及：「状態移行の際、旧ジョブと新ジョブをどのくらい並行実行しましたか？データの重複をどう防ぎましたか？」デュアルラン検証と冪等書き込みのソリューションを説明しました。

システム設計問題：「データ遅延、データ損失、データ異常を検出でき、カスタムルールをサポートするデータ品質監視プラットフォームを設計してください。」リアルタイム検出（Flink CEP）、オフライン検出（Spark定期タスク）、ルールエンジン、アラートシステムの設計をアーキテクチャレベルで説明。面接官がルールエンジンの実装について追及し、Aviator式エンジンによる動的ルールのソリューションを説明しました。

最後にキャリアプランとデータプラットフォームに対する見解について。ストリームバッチ統一の方向を深めたいと述べると、面接官も同じ方向に取り組んでいると言い、Icebergのストリームバッチ統一における応用について少し話しました。

2. 面接問題まとめ

1. Hive SQLの実行フロー？CBOとRBOの違い？

2. Sparkシャッフルプロセス？SortShuffleManagerの3つの実装？

3. 500GBのHiveテーブルの日次集計最適化？10万パーティションの処理？

4. Flink Checkpointメカニズム？Exactly-Onceの保証方法？

5. Flink Checkpoint失敗のトラブルシューティング？

6. Flinkウィンドウトリガー遅延の処理？遅延データの処理？

7. IcebergとHudiの違い？Icebergを選ぶ理由？

8. Icebergスナップショット有効期限メカニズム？期限切れスナップショットの読み取り時の問題？

9. 秒レベルレイテンシでAD-HOCクエリをサポートするリアルタイムデータウェアハウスの設計？

10. LambdaからKappaアーキテクチャへの移行の課題？状態移行時の一貫性保証？

11. データ品質監視プラットフォームの設計？

12. オフラインデータウェアハウスの最大のペインポイント？解決方法？

3. 心得とアドバイス

1. 原理は徹底的に理解し、結論だけを暗記しない。トップ企業の面接官は掘り下げ質問が得意です。「Checkpointはスナップショットメカニズム」とだけ暗記していると、実装の詳細を聞かれた瞬間に露呈します。各トピックを「何か→なぜ→どう実装→何が問題か」の4レベルで理解することをお勧めします。

2. 実戦経験が最大のアドバンテージ。面接官は「どんな問題に遭遇したか」を好んで聞きます。具体的な罠の経験とソリューションを語れれば、100の標準回答を暗記するより価値があります。日常業務で意識的に問題を記録することをお勧めします。

3. シナリオ問題には自分の思考フレームワークを持つ。シナリオ問題に標準回答はありません——面接官が見たいのはあなたの思考プロセスです。私のフレームワーク：要件を明確にする→ボトルネックを分析する→ソリューションを提案する→トレードオフを議論する。

4. データレイク経験はプラス。現在のビッグデータ面接では、データレイクはほぼ必須です。Iceberg/Hudi/Delta Lakeの実戦経験があれば、必ず履歴書で強調してください。

5. システム設計はトップダウンで。大きなアーキテクチャから始め、各モジュールに徐々に深く入る。最初から詳細を語ると、全体観が欠けていると思われます。

4. FAQ

Q：ビッグデータ面接でアルゴリズムの重要度は？

バックエンド開発に比べ、ビッグデータ方向のアルゴリズム要件はそれほど高くありません。一次面接で中程度の難易度のアルゴリズム問題が出るかもしれませんが、SQLとビッグデータフレームワークの原理がより重視されます。中程度の難易度まで練習すれば十分です——より多くの時間を原理に費やしてください。

Q：データレイク経験なしで合格できますか？

合格できますが、不利になります。データレイクは現在のビッグデータのホットトピックで、面接官が高確率で質問します。実戦経験がなくても、基本概念とアーキテクチャ原理は理解しておきましょう——COWとMORの違い、スナップショット分離メカニズムなどを説明できるように。

Q：面接でプロジェクト紹介はどう話すべきか？

STARメソッドを使用：Situation（プロジェクト背景）→Task（あなたの役割）→Action（何をしたか）→Result（結果と影響）。ActionとResultに焦点を当て、特に遭遇した問題とソリューションを強調。面接官が聞きたいのは、プロジェクトがどれほどすごいかではなく、あなたの貢献と成長です。

Q：NTTデータのビッグデータ面接は通常何回？

通常3回の技術面接+1回のHR面接。技術面接は難易度が上がっていきます：一次は基礎原理、二次はリアルタイム計算とアーキテクチャ、三次はシステム設計とプロジェクトの深さ。HR面接は主に給与とキャリアプランについて。

Q：FlinkとSparkどちらを優先して準備すべきか？

両方準備してください。データプラットフォームはストリームバッチ統一を使用しており、面接でFlinkとSparkの両方が聞かれます。時間が限られている場合は、Flinkを優先することをお勧めします——リアルタイム計算が重点方向であり、面接でFlinkの割合が大きい傾向にあります。