すべてのプロダクト
Search

このプロダクト

    E-MapReduce:Hadoop クラスターの DataLake クラスターへの移行

    ドキュメントセンター

    E-MapReduce:Hadoop クラスターの DataLake クラスターへの移行

    最終更新日:Jun 22, 2026

    このトピックでは、既存のレガシーデータレイククラスター (Hadoop) を DataLake クラスターに効率的に移行する方法について説明します。本ドキュメントでは、便宜上、ソースクラスターを「既存クラスター」、ターゲットクラスターを「新規クラスター」と呼びます。移行プロセスでは、既存クラスターのバージョン、メタデータタイプ、ストレージ方式を考慮し、それぞれに合わせた移行戦略と手順を提供します。

    背景情報

    E-MapReduce (EMR) の次世代コンソールは、EMR の次世代クラウドネイティブオープンソースビッグデータプラットフォームです。新しいユーザーエクスペリエンス、開発プラットフォーム、リソースモデル、分析シナリオを提供します。その特徴の詳細については、「お知らせ：EMR 次世代コンソールが利用可能になりました」をご参照ください。

    EMR の主要なリソースモデルの 1 つである EMR on ECS には、複数の機能更新が含まれています。特に、EMR 次世代コンソールでは、DataLake、Dataflow、OLAP、Custom といった新しいクラスターシナリオが導入され、既存のクラスターシナリオ (Hadoop や Data Science など) と比較して、クラスター管理効率とエンジン性能が大幅に向上しています。DataLake クラスターは、既存の Hadoop ベースのデータレイククラスターのアップグレード版です。DataLake クラスターにアップグレードすると、多くのメリットが得られます。詳細な機能比較については、「DataLake クラスター」をご参照ください。

    事前準備

    既存クラスターのアーキテクチャの確認

    現在のビッグデータアーキテクチャを確認し、既存クラスターのアプリケーションシナリオを明確にし、以下の点に注意してください：

    • サービス範囲とバージョン：各既存クラスターで実行されているサービスとそのバージョンを記録し、アップグレードの互換性と機能更新の要件を評価します。

    • メタデータタイプ：既存クラスターが使用しているメタデータタイプ (DLF または自己管理型 RDS) を確認し、新しいアーキテクチャでのメタデータ管理システムの統合と移行戦略を計画します。

    • データストレージアーキテクチャ：既存クラスターのデータストレージアーキテクチャ (ローカル HDFS、OSS、または JindoFS ブロックモード) を分析し、データ移行パスの設計に役立てます。

    • ユーザー認証・権限付与アーキテクチャ：OpenLDAP、Ranger、Kerberos などのサービスが使用されているかを確認し、新しいアーキテクチャが既存のセキュリティメカニズムをシームレスに継承できるようにします。

    • スケジューリングシステム：現在の開発およびスケジューリングシステムを確認し、移行中もタスクのスケジューリングが一貫してスムーズに行われるようにします。

    アップグレードする既存クラスターが複数ある場合は、業務継続性と安定性を確保するために、一度に 1 つずつ移行してください。実際のビジネスニーズと優先順位に基づき、実用的な移行順序と計画を作成し、既存クラスターから新規クラスターへのスムーズな移行を実現します。

    既存クラスターの詳細の確認

    • クラスターインスタンス設定情報の表示

      新しいプラットフォームで新規クラスターを作成する際に、既存クラスターの基本的なインスタンス情報を再利用できます。詳細については、「新規クラスターの作成」をご参照ください。特別な注意が必要なソフトウェアとハードウェアの設定を除き、既存クラスターと新規クラスターの両方で他のパラメーターに同じ設定を使用できます。

      既存の EMR on ECS クラスターの 基本情報 および Nodes ページで、クラスターとノードグループの設定を確認し、特に以下の点に注意してください：

      設定タイプ

      設定名

      確認する詳細

      ソフトウェア設定

      • クラスターバージョン

      • サービスバージョン

      • 実際に使用されているコンポーネントのリスト

      • Hive メタデータタイプ

      クラスターで現在使用されているサービスのリストと、それに対応するバージョン。

      ハードウェア設定

      • クラスターが存在するゾーン

      • 各ノードグループのインスタンスタイプと課金方法

      クラスターのゾーンと、各ノードグループのハードウェア仕様 (CPU、メモリ、システムディスク、データディスクなど)。

    • (オプション) クラスターサービスコンポーネント設定のエクスポート

      日常の運用保守 (O&M) 中、ユーザーは特定のニーズに基づいてデフォルトのサービスコンポーネント設定をカスタマイズしたり、カスタム設定を追加したりすることがよくあります。これらの設定をクラスター間で効率的に移行するには、EMR の設定エクスポート機能を使用して、既存クラスターからすべての設定を一括エクスポートします。その後、新規クラスターの初期化中にこれらの設定を一括インポートすることで、サービスコンポーネント設定を迅速に複製できます。または、新規クラスターの起動が成功した後、サービス管理インターフェイスで各サービス設定を手動で調整することもできます。

      1. サービス設定のエクスポート

        詳細については、「サービス設定のエクスポートとインポート」をご参照ください。ワンクリックで対象サービスコンポーネントの設定ファイルをエクスポートできます。

        説明

        • Select Configuration Files：編集された設定ファイルのみを選択します。複数選択が可能です。

        • エクスポートモード：現在の Hadoop クラスターは [カスタム設定または変更された設定のみをエクスポート] をサポートしていません。

        • Export Format：新規クラスターへのインポートを容易にするため、[JSON] 形式を選択します。

        エクスポートされた設定ファイルパラメーターは、次の表で説明されています。

        パラメーター

        説明

        ApplicationName

        サービス名。

        ConfigFileName

        設定ファイル名。

        ConfigItemKey

        設定項目名。

        ConfigItemValue

        設定項目に設定された特定の値。

      2. 設定ファイルの編集

        エクスポートされた設定情報を注意深く確認し、新しい環境に適用可能な必要な項目のみを保持し、不要な設定を削除します。

        • YARN 関連のリソースパラメーターを調整する際は、クラスターの実際のハードウェア仕様と密接に連携させてください。インポートするパラメーター値が新規クラスターにとって合理的であることを確認してください。

        • JindoFS 関連の設定 (例：Credential Provider) が存在する場合は、OSS/OSS-HDFS の設定に従って調整してください。詳細については、「OSS/OSS-HDFS Credential Provider の設定」をご参照ください。

      3. 編集した設定ファイルを「(オプション) カスタムソフトウェア設定」として適用し、新規クラスターのプリセット設定とします。

    • (オプション) ブートストラップアクションの確認

      「クラスターインスタンス設定情報の表示」の段階で、既存クラスターにブートストラップスクリプトが設定されているかどうかを確認します。ブートストラップアクションが存在する場合は、各スクリプトの機能を慎重に評価し、新規クラスターで再利用すべきかどうかを判断します。

      新規クラスターで必要なスクリプトについては、適切に実行されるように次のように調整します：

      • オープンソースコンポーネントのバージョンに関連する JAR パッケージ名とパスを更新します。既存および新しいプラットフォームのファイルパスについては、「共通のファイルパス」をご参照ください。

      • スクリプトが OSS からファイルをダウンロードする場合、対応する OSS コマンドを更新します。詳細については、「ブートストラップアクション実行スクリプト」をご参照ください。

      スクリプトを修正した後、OSS にアップロードし、新規クラスター作成時に更新された OSS アドレスを入力します。

      重要

      ブートストラップスクリプトを本番クラスターにデプロイする前に、ステージング環境で検証してください。

    • (オプション) 既存クラスターの Auto Scaling ルールの確認

      既存クラスターに Auto Scaling ルールが設定されている場合は、それらを確認します。特に、最大インスタンス数、最小インスタンス数、グレースフルシャットダウン、トリガー方法、トリガールールに注意し、新規クラスター作成後に Auto Scaling を再設定します。詳細については、「カスタム Auto Scaling ポリシーの作成」をご参照ください。

      1. Auto Scaling ページに移動します。

        1. E-MapReduce コンソールにログインします。

        2. 対象のクラスター名をクリックします。

        3. Auto Scaling タブをクリックします。

      2. Auto Scaling ルールの確認

        Auto Scaling タブで、Auto Scaling ルールが設定されているノードグループの [操作] 列にある Configure Rule をクリックします。特に以下の点に注意してください：

        • 最大インスタンス数

        • 最小インスタンス数

        • グレースフルシャットダウン

        • トリガー方法

        • トリガールール (スケールアウト、スケールイン)

      説明

      インスタンス選択方法、課金タイプ、インスタンスタイプ、グレースフルシャットダウンなどのパラメーターは、新規クラスターのノードグループプロパティパネルで設定します。詳細については、「ノードグループの管理」をご参照ください。

    • (オプション) 既存クラスターの負荷メトリックの確認

      クラスターのリソース負荷メトリックを確認して、既存クラスターの日々のリソース使用量を観察し、新規クラスターのハードウェア要件を評価します。または、最初に既存クラスターのハードウェア仕様を完全に一致させることでスムーズな移行を行い、その後、実際のリソース使用率に基づいて新規クラスターのハードウェア設定を調整することもできます。

      • 方法 1：クラスター監視の表示

        クラスターの負荷メトリックを確認し、特に YARN と HDFS の使用量に注意します。詳細については、「サービス監視メトリックの表示」をご参照ください。

      • 方法 2：EMR Doctor 日次レポートの表示

        EMR Doctor 日次レポートは、計算リソース、YARN スケジューリングリソース、HDFS ストレージリソースのグローバルな分析を提供します。総データ量、ホット/コールドデータの分布、計算タスクの分布を確認できます。詳細については、「クラスター日次レポートと分析の表示」をご参照ください。

        説明

        EMR Doctor は既存クラスターにインストールされている必要があります。詳細については、「EMR Doctor の有効化 (Hadoop クラスタータイプ)」をご参照ください。

    移行計画とタイムラインの定義

    現在のビッグデータワークロードと各既存クラスターの設定に基づき、最終的な移行目標を定義し、以下のキーポイントを明確にします。この情報を使用して、人的リソースとタイムラインを適切に計画します。

    • 新規クラスターのプロダクトバージョンとサービス範囲。サービスの互換性については、「プロダクトバージョンとオプションサービス」をご参照ください。

    • 新規クラスターのメタデータオプション (DLF または自己管理型 RDS)

    • 新規クラスターのストレージソリューション (OSS-HDFS または OSS)

    ステップ 1：新しい環境のクラスター構築

    新規クラスターの作成

    詳細な手順とパラメーターの説明については、「クラスターの作成」をご参照ください。「クラスターインスタンス設定情報の表示」で収集したクラスター設定の詳細に基づいてパラメーターを入力します。特に以下のパラメーターに注意してください。

    • プロダクトバージョンとオプションサービス

      「クラスターインスタンス設定情報の表示」で収集したサービスリストに基づき、互換性情報を参照して、新規クラスターに適したサービス範囲とバージョンを選択します。

      • コンポーネントの互換性に関する注意

        オープンソースコミュニティのサービスが進化するにつれて、DataLake シナリオの一部のサービスは Hadoop のものよりも高いバージョンを使用します。次の表は、下位互換性の範囲を示しています。既存クラスターのソフトウェアバージョンとこの表を使用して、新規クラスターのサービスバージョンを決定してください。

        既存クラスターのサービス

        下位互換性範囲 1

        下位互換性範囲 2

        下位互換性範囲 3

        下位互換性範囲 4

        Spark

        2.x

        3.x

        -

        -

        Hive

        2.x

        3.x

        -

        -

        Tez

        すべてのバージョンで完全互換

        -

        -

        -

        Delta Lake

        0.6.x

        0.8.0–1.1.0

        -

        -

        Iceberg

        0.12.x

        0.13.x

        -

        -

        Hudi

        0.6.x

        0.8.x

        0.9.x

        0.10.x

        Sqoop

        すべてのバージョンで完全互換

        -

        -

        -

        Ranger

        1.x

        2.x

        -

        -

        OpenLDAP

        すべてのバージョンで完全互換

        -

        -

        -
        説明

        • 下位互換性範囲は、この範囲内では上位バージョンが下位バージョンと互換性があることを示します。

        • 上記の互換性情報は参考用です。信頼できる詳細については、公式のオープンソースコミュニティのドキュメントをご参照ください。

        • オープンソースコミュニティの活動の変化や技術の進化により、一部のオープンソースサービスは新しい EMR プラットフォームではサポートされなくなりました。

          例えば、Hue、Zeppelin、Oozie などです。EMR Notebook または EMR Workflow に移行するか、対応するエンジンをクラスターに手動でデプロイしてください。

      • 適切なプロダクトバージョンの選択

        重要

        ソフトウェアバージョンの要件が満たされている場合は、最新の EMR プロダクトバージョンを選択して、より豊富な機能にアクセスしてください。

        DataLake シナリオでは、Alibaba Cloud EMR は EMR-3.x と EMR-5.x の 2 つのシリーズを提供しています。各シリーズには、統合されているサービスやバージョンが異なる複数のプロダクトバージョンが含まれています。新規クラスターを構築する際は、データレイクのアプリケーションシナリオと対象サービスの互換性要件に基づいてプロダクトバージョンを選択してください。次の表は、既存プラットフォームと新しいプラットフォームのバージョンのマッピングを示しています。

        既存クラスターのバージョン

        対応する新規クラスターのバージョン

        EMR-3.35.0：YARN 2.8.5、HDFS 2.8.5、Hive 2.3.7、Spark 2.4.7

        EMR-3.x シリーズ

        EMR-5.6.0：YARN 3.2.1、HDFS 3.2.1、Hive 3.1.2、Spark 3.2.1

        EMR-5.x シリーズ

      • HDFS と OSS-HDFS の選択に関する注意

        EMR バージョン 5.12.1 以降および 3.46.1 以降では、オプションサービスでクラスターのストレージ方法として HDFS または OSS-HDFS を選択できます。

        「移行計画とタイムラインの定義」で定義されたストレージソリューションに基づき、新規クラスター作成時にオプションサービスを設定する際に、対応するサービスを選択してください。

        新しいプラットフォームのクラスターのストレージ方法

        サービスの選択

        OSS

        OSS-HDFS

        OSS-HDFS

        OSS-HDFS
        説明

        Optional Services パラメーターで OSS-HDFS を選択した場合、クラスターストレージのルートパス を設定する際に、OSS-HDFS が有効になっているバケットをクラスターのルートストレージパスとして選択します。

    • メタデータの選択

      新しい EMR プラットフォームは、以下のメタデータストレージオプションをサポートしています。「移行計画とタイムラインの定義」で定義されたメタデータストレージソリューションに基づいて選択してください。メタデータ移行が必要な場合は、新規クラスター作成後に「メタデータ移行」をご参照ください。

      メタデータストレージ方法

      説明

      統合 DLF メタデータ (推奨)

      メタデータは Data Lake Formation (DLF) に保存されます。既存プラットフォームが既に DLF を使用している場合は、同じ DLF データカタログを設定します。新規クラスターは作成後に自動的に同じメタデータに接続されるため、移行は不要です。

      自己管理型 RDS

      自己管理型の Alibaba Cloud RDS インスタンスをメタデータベースとして使用します。このオプションを選択する際は、既存の RDS パラメーターを設定します。詳細については、「自己管理型 RDS の設定」をご参照ください。

      組み込み MySQL

      メタデータはクラスター上のローカル MySQL データベースに保存されます。

      重要

      このオプションはテスト専用です。本番環境では使用しないでください。

    • (オプション) カスタムソフトウェア設定

      既存クラスターからサービス設定をエクスポートした場合、またはクラスター作成中に設定をプリセットする予定の場合は、新規クラスター作成ワークフローでカスタムソフトウェア設定を有効にし、編集した設定を入力ボックスに貼り付けます。詳細については、「カスタムソフトウェアの設定」をご参照ください。

    • ハードウェア設定

      「クラスターインスタンス設定情報の表示」の段階で、各ノードのハードウェア設定を完全に理解できます。Master、Core、Task といった異なるノードタイプに対して、ビジネスニーズに基づいて適切なハードウェアリソースを選択します。

      • 新規クラスターを作成する際は、最新の ECS インスタンスファミリーとクラウドディスクタイプを使用して、新しいハードウェアの機能を活用してください。

      • 同じロールを持つノードグループを追加するには、クラスター作成後にノードグループ追加機能を使用します。

      • パブリックネットワークへの接続：ノードグループごとにこれを有効にします。有効にすると、グループ内のすべてのノードにパブリック IP アドレスが割り当てられます。

        Master ノードグループのパブリックネットワーク接続を有効にすると、パブリックネットワーク経由でマスターノードにログインしたり、EMR のアクセスリンクやポートマッピング機能を使用したりできます。

    (オプション) 新規ゲートウェイの作成

    ゲートウェイは主に、計算クラスターにジョブを投入し、隔離を提供するために使用されます。既存プラットフォームでゲートウェイクラスターを使用していた場合は、次のように新しいプラットフォームでゲートウェイを作成します。

    新しいプラットフォームでは、より柔軟なゲートウェイのデプロイメントオプションが提供されており、既存の ECS インスタンス上にゲートウェイをデプロイし、計算クラスターの設定を自動的に同期させることができます。ゲートウェイのデプロイメントを簡素化するために、EMR は EMR-CLI というツールを提供しており、これを使用すると、既存の Alibaba Cloud ECS インスタンス上に簡単にゲートウェイをセットアップできます。詳細については、「EMR-CLI を使用したゲートウェイのカスタマイズデプロイメント」をご参照ください。

    ステップ 2：移行と検証

    新しいクラスター環境を構築した後、既存クラスターからメタデータ、データ、ジョブを移行します。

    メタデータ移行

    既存および新しい EMR プラットフォームは、自己管理型 RDS、DLF、組み込み MySQL の 3 つのメタデータ管理方法をサポートしています。新しいプラットフォームでは、DLF メタデータサービスの使用を強く推奨します。既存クラスターと新規クラスターで使用されるメタデータ管理方法に基づき、以下の移行アプローチを使用してください。

    既存プラットフォームのメタデータ方法

    新しいプラットフォームのメタデータ方法

    移行方法

    DLF

    DLF

    データ移行は不要です。新規クラスターが既存クラスターと同じ DLF データカタログを指していることを確認してください。

    統合メタデータベース

    DLF

    詳細については、「EMR メタデータ移行のお知らせ」をご参照ください。

    ローカル MySQL

    DLF

    詳細については、「メタデータ移行」をご参照ください。

    自己管理型 RDS

    DLF

    詳細については、「メタデータ移行」をご参照ください。

    データ移行

    新規クラスターを作成した後、既存クラスターと新規クラスターのストレージの違いに基づいて以下の移行方法を使用し、データの正確かつ成功した移行を保証します。

    既存クラスターのストレージ

    新しいプラットフォームのストレージ

    移行方法

    OSS

    OSS

    データ移行は不要です。

    OSS

    OSS-HDFS

    データ移行には、「JindoDistCp ユーザーガイド」ツールを使用します。

    JindoFS ブロック

    OSS-HDFS

    HDFS

    OSS-HDFS

    データ正当性検証

    説明

    新規クラスターでデータ移行が不要な場合は、この検証ステップをスキップしてください。

    データ移行が完了したら、HDFS データと Hive データベース/テーブルの正当性を検証します。データの不整合が検出された場合は、影響を受けたジョブの再実行や欠損データの復元など、直ちに対策を講じてください。

    特定の要件に基づいて検証方法を選択してください。

    検証要件

    検証方法

    ファイル検証

    チェックサム値を比較して、ファイルが移行中に変更されたり破損したりしていないことを確認します。

    概算データ検証

    テーブルレベルの統計情報 (例：総行数 (count)、数値列の合計値 (sum)、平均値 (avg)、最小値 (min)、最大値 (max)) を確認して、全体的なデータ整合性を迅速に評価します。

    詳細データ検証

    行ごとの検証を実行して、すべてのデータ項目がソースクラスターと完全に一致することを確認し、より深い整合性と精度のチェックを提供します。

    ジョブ移行

    既存クラスターのジョブが新規クラスターで正しく実行されるように、スケジューリングシステムと環境に基づいて以下の移行戦略を適用してください：

    • EMR の既存の Data Studio を使用している場合は、EMR Workflow に移行してください。詳細については、「お知らせ：EMR 既存 Data Studio からの移行」をご参照ください。

    • 別の開発環境 (例：Alibaba Cloud DataWorks または自社構築プラットフォーム) を使用している場合は、その環境が提供する移行ガイドに従ってください。

      プラットフォーム固有の移行ドキュメントを注意深く参照し、計算クラスター情報の切り替えなどの設定を調整して、ジョブが新規クラスターで正しくスケジュールされ、実行されるようにしてください。

    ステップ 3：並行二重実行検証

    クラスター移行中のライブビジネスへの潜在的な影響を最小限に抑えるため、既存クラスターと新規クラスターの間で二重実行検証を実施します。これには、ライブトラフィックを新規クラスターに複製し、ジョブを同時に実行して、データ整合性とビジネスの正当性を包括的に検証することが含まれます。

    二重実行検証の方法は、開発環境、ビジネスの特性、データ処理のニーズによって異なるため、特定のシナリオと要件に合わせた柔軟な二重実行検証計画を設計することを強く推奨します。

    ステップ 4：既存クラスターの廃止

    データとビジネス運用の検証が成功したら、カットオーバーに進みます。ジョブのワークロードを既存クラスターから新規クラスターに徐々に移行し、すべてのビジネスが新規クラスターで安定して実行されるまで、新規クラスターでの処理量を段階的に増やしていきます。

    すべてのビジネスが完全に移行され、既存クラスターがアイドル状態になったら、「クラスターの解放」の手順に従って安全に廃止します。