ある大手メディア企業は、視聴者データ分析基盤としてオンプレミスで400ノードのHadoop/Sparkクラスターを運用しています。このクラスターの特徴： ・HDFSに25TBのデータを保持し、毎日3TBのログデータが追加される ・Apache Hive（メタストアはMySQL 5.7で稼働）でデータウェアハウス処理、Apache SparkでバッチおよびETL処理を実行 ・200本のHiveクエリと50本のPySparkジョブが本番稼働中 ・Apache Oozieでジョブスケジューリングとワークフロー管理を実施 ・クラスターの年間運用コストが$2.5M（ハードウェア保守・電力・冷却費含む） 移行要件： ・HiveクエリおよびPySparkジョブのコード変更を最小限に抑える ・既存のBIツール（Tableau）からのデータアクセス互換性を維持する ・HDFSデータを先行移行し、ジョブは段階的に移行する ・常時稼働クラスターをやめて変動する処理需要に応じたコスト最適化を実現する ・移行完了まで既存Hadoopクラスターとの並行稼働を維持する これらの要件を最も適切に満たす移行戦略はどれですか？
選択肢CのAWS DataSyncはHDFS（Hadoop Distributed File System）をソースとして直接サポートしており、オンプレミスエージェントを通じてHDFSからAmazon S3への継続的・増分的なデータ同期が可能です。毎日3TBが追加される動的なデータ環境でも、並行稼働期間中はデータを最新状態に保てます。 AWS Glue Data CatalogはApache Hive Metastore互換のAPIを提供しており、Amazon EMRはGlue Data Catalogをネイティブに統合できます。これにより既存のHiveクエリとPySparkジョブはテーブル定義の参照先変更のみで動作し、クエリ・ジョブコードの実質的な変更が不要です。 Amazon EMRのTransientクラスター戦略はジョブ実行時のみクラスターを起動して自動終了させるパターンであり、常時稼働に比べてコストを大幅に削減できます。Amazon MWAAはApache Airflowのマネージドサービスであり、OozieのDAGワークフローを移行する標準的な移行先です。TableauはAmazon AthenaのJDBC/ODBCドライバで既存接続を維持できます。 選択肢AのAmazon EMR常時起動（always-on）戦略は「変動需要に応じたコスト最適化」という要件に反し、高コスト構造をAWS上で再現するだけになる。RDS for MySQLをHiveメタストアとして使用することはGlue Data Catalog統合と比べてEMRとの連携が複雑になる。 選択肢BのAWS Snowball Edgeによるオフライン一括移行は毎日3TBが追加される動的データ環境での継続的な差分同期に対応できない。PySparkをLambdaに書き直すことはLambdaの15分実行時間制限のため長時間のSparkジョブに対応できず、「コード変更を最小限に」という要件に違反する。 選択肢DのAmazon Kinesis Data Firehoseはストリーミングデータの継続的取り込みに特化したサービスであり、HDFSのバルクデータ移行ツールとして設計されていない。HiveメタストアをDynamoDBで代替することはHive Metastore APIとの互換性がなく技術的に実現不可能であり、Tableauの強制置換も要件外となる。