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

背景情報

新しい EMR コンソールは、EMR によってリリースされた次世代のクラウドネイティブなオープンソースビッグデータプラットフォームです。ユーザーエクスペリエンスの向上に役立つ新しい開発プラットフォーム、新しいリソース形式、新しい分析シナリオをユーザーに提供します。新しい EMR コンソールで提供される機能については、新しい EMR コンソールの発表をご参照ください。

ECS 上の EMR は、EMR の主要なリソース形式の 1 つであり、新しい EMR コンソールで強化された機能を提供します。新しい EMR コンソールは、DataLake、Dataflow、オンライン分析処理（OLAP）、カスタムといったタイプのクラスターを提供します。Hadoop やデータサイエンスなど、古い EMR コンソールで提供されるクラスタータイプと比較して、新しい EMR コンソールで提供されるクラスタータイプは、クラスター管理効率とエンジンパフォーマンスの大幅な向上に役立ちます。DataLake クラスターは、Hadoop クラスターのアップグレードバージョンです。DataLake クラスターの複数の機能を活用できます。詳細については、DataLake クラスターをご参照ください。

準備

古いクラスターの全体アーキテクチャを整理する

現在のビッグデータビジネスアーキテクチャを整理し、古いクラスターのユースケースを特定し、次の項目に注意してください。

• サービスとサービスバージョン：古いクラスターで実行されているサービスとサービスバージョンを記録します。これは、アップグレードの互換性と機能更新の要件を評価するのに役立ちます。

• メタデータストレージタイプ：古いクラスターで使用されているメタデータストレージタイプを確認し、新しいアーキテクチャでのメタデータ管理システムの接続と移行ポリシーを計画します。古いクラスターで使用されているメタデータストレージタイプは、Data Lake Formation（DLF）またはセルフマネージド ApsaraDB RDS のいずれかです。

• データストレージアーキテクチャ：古いクラスターのデータストレージアーキテクチャを分析して、後続のデータ移行パスの設計の基礎を提供します。データストレージアーキテクチャは、ローカル Hadoop 分散ファイルシステム（HDFS）、オブジェクトストレージサービス（OSS）、またはブロックモードの JindoFS のいずれかです。

• ユーザー認証アーキテクチャ：古いクラスターにデプロイされている OpenLDAP、Ranger、Kerberos などのサービスを使用するかどうかを確認します。これは、移行後に新しいアーキテクチャが既存のセキュリティメカニズムをシームレスに継承できるようにするのに役立ちます。

• スケジューリングシステム：スケジューリングの一貫性とタスクのスムーズな移行を維持するために使用される開発およびスケジューリングシステムを確認します。

複数の古いクラスターをアップグレードする場合は、ビジネスの継続性と安定性を確保するために、古いクラスターのデータを一度に 1 つずつ移行することをお勧めします。次に、実際のビジネス要件と優先順位に基づいて移行シーケンスを決定し、実行可能な移行計画を策定して、各古いクラスターから新しいクラスターへのデータのスムーズな移行を確保します。

古いクラスターの詳細情報を整理する

• インスタンス構成を表示する

  新しい EMR コンソールでクラスターを作成すると、古いクラスターのインスタンスに関する基本情報を新しいクラスターに適用できます。詳細については、新しい EMR コンソールでクラスターを作成するをご参照ください。古いクラスターのソフトウェアとハードウェアの構成を表示して整理する必要があります。その他の構成は、新しいクラスターに直接適用できます。

  EMR on ECS ページで古いクラスターの [基本情報] タブと [ノード] タブでクラスターとノードグループの構成を表示し、次の表に記載されている情報に注意してください。

  構成タイプ	構成項目	整理するコンテンツ
  ソフトウェア構成	クラスターバージョン サービスバージョン 実際に使用されているコンポーネント Hive メタデータストレージタイプ	古いクラスターで使用されているサービスとそのバージョン。
  ハードウェア構成	クラスターが存在するゾーン 各ノードグループの仕様と課金方法	古いクラスターが存在するゾーン、および古いクラスターの各ノードグループのハードウェア構成（vCPU、メモリ、システムディスク、データディスクなど）。

• （オプション）サービス構成をエクスポートする

  クラスターの日常の O&M では、ユーザーはビジネス要件に基づいてサービスのデフォルト構成を調整したり、追加のカスタム構成を追加したりすることがよくあります。構成情報を異なるクラスター間で効率的に移行するために、EMR の構成エクスポート機能を最大限に活用して、古いクラスターのすべての構成を一度にエクスポートし、新しいクラスターの初期化中に構成を一度にインポートできます。これにより、サービス構成を迅速かつ簡単に移行できます。または、新しいクラスターが起動した後、サービス管理ページでサービスの構成を手動で 1 つずつ変更および調整することもできます。

  1. サービス構成をエクスポートします。

     サービス構成のエクスポートとインポートを参照して、数回クリックするだけでサービス構成ファイルをエクスポートします。

     説明

     • [構成ファイルを選択]：編集済みの構成ファイルのみを選択することをお勧めします。複数の構成ファイルを選択できます。

     • [エクスポートモード]：Hadoop クラスターの場合、このパラメーターを [カスタムまたは変更された構成のみをエクスポート] に設定することはできません。

     • [エクスポート形式]：[JSON] を選択します。こうすることで、サービス構成を新しいクラスターに簡単にインポートできます。

     次の表に、エクスポートされた構成ファイルのパラメーターを示します。

     パラメーター	説明
     ApplicationName	サービスの名前。
     ConfigFileName	構成ファイルの名前。
     ConfigItemKey	構成項目の名前。
     ConfigItemValue	構成項目の値。

  2. 構成ファイルを変更します。

     古いクラスターからエクスポートされた構成情報を慎重に確認し、新しい環境に必要な構成項目をフィルタリングして保持し、不要な構成を削除します。

     • YARN 関連リソースのパラメーター設定を調整する場合は、新しいクラスターの実際のハードウェアリソース仕様を考慮して、新しいクラスターにインポートする構成項目の設定が合理的であることを確認する必要があります。

     • 資格情報プロバイダーなどの JindoFS 関連の設定を構成している場合は、OSS または OSS-HDFS 関連の構成に基づいて設定を調整することをお勧めします。詳細については、OSS または OSS-HDFS の資格情報プロバイダーを構成するをご参照ください。

  3. 構成ファイルのサービス構成を、新しいクラスターのプリセット構成として使用します。詳細については、このトピックの「（オプション）カスタムソフトウェア構成」をご参照ください。

• （オプション）ブートストラップアクションを整理する

  インスタンス構成の表示のフェーズで、古いクラスターにブートストラップアクションスクリプトが構成されているかどうかを確認できます。ブートストラップアクションスクリプトが構成されている場合は、各ブートストラップアクションスクリプトの機能を評価して、新しいクラスターで使用するかどうかを決定する必要があります。

  新しいクラスターで使用するブートストラップアクションスクリプトについては、次の操作を実行してスクリプトを調整し、新しいクラスターで正しく実行できるようにします。

  • ブートストラップアクションスクリプトのオープンソースコンポーネントのバージョンに関連する情報を変更します。情報には、JAR パッケージ名とパスが含まれます。古い EMR コンソールと新しい EMR コンソールのファイルパスの詳細については、頻繁に使用されるファイルのパスをご参照ください。

  • スクリプトの実行中にオブジェクトストレージサービス（OSS）からオブジェクトをダウンロードする必要がある場合は、対応する OSS コマンドを変更する必要がある場合があります。詳細については、ブートストラップアクションの管理をご参照ください。

  スクリプトを変更した後、スクリプトを OSS にアップロードします。新しいクラスターを作成するときに、ブートストラップアクションスクリプトの変更された OSS パスを入力します。

  重要

  本番クラスターにブートストラップアクションスクリプトをデプロイする前に、スクリプトがテスト環境での検証に合格していることを確認してください。

• （オプション）自動スケーリングルールを整理する自動スケーリングルール

  古いクラスターに自動スケーリングルールが構成されている場合は、構成されている自動スケーリングルールを表示し、インスタンスの最大数、インスタンスの最小数、グレースフルシャットダウン、トリガーモード、トリガールールなどの情報に焦点を当てます。新しいクラスターを作成した後、自動スケーリングルールを再構成します。詳細については、自動スケーリングルールの追加をご参照ください。古いクラスターに構成されている自動スケーリングルールを表示するには、次の手順を実行します。

  1. [自動スケーリング] タブに移動します。

     1. EMR コンソールにログオンします。左側のナビゲーションペインで、[EMR on ECS] をクリックします。

     2. 目的のクラスターを見つけ、[クラスター ID/名前] 列でクラスターの名前をクリックします。

     3. 表示されるページで、[自動スケーリング] タブをクリックします。

  2. 自動スケーリングルールを表示します。

     [自動スケーリング] タブで、目的の自動スケーリンググループを見つけ、[アクション] 列の [ルールの構成] をクリックします。[自動スケーリングの構成] パネルで次のパラメーターに焦点を当てます。

     • インスタンスの最大数

     • インスタンスの最小数

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

     • トリガーモード

     • トリガールール（スケールアウトとスケールイン）

  説明

  新しいクラスターの [自動スケーリングの構成] パネルで、[インスタンスタイプ選択モード]、[課金方法]、[インスタンスタイプ]、[グレースフルシャットダウン] などのパラメーターを構成できます。詳細については、ノードグループの管理をご参照ください。

• (オプション) クラスターの負荷を表示する

  クラスター負荷を表示して、古いクラスターの毎日のリソース使用量を確認できます。これは、新しいクラスターに必要なハードウェア構成を評価するのに役立ちます。または、古いクラスターと新しいクラスターが同じハードウェア構成を使用するように、クラスター構成をスムーズに移行することもできます。次に、クラスターの実行中のリソース使用率に基づいて、新しいクラスターのハードウェア構成を変更できます。

  • 方法 1：メトリックを表示する

    クラスター負荷メトリックを表示し、YARN サービスと HDFS サービスのリソース使用率に焦点を当てます。詳細については、サービスメトリックの表示をご参照ください。

  • 方法 2：EMR Doctor の毎日のクラスターレポートを表示する

    EMR Doctor は、クラスター内のコンピューティングリソース、YARN スケジューリングリソース、HDFS ストレージリソースのグローバル分析結果を含む毎日のクラスターレポートを提供します。クラスター内の既存データの総量、ホットデータとコールドデータの分布、クラスター内のコンピューティングタスクの分布を表示できます。詳細については、レポートで毎日のクラスターレポートと分析結果を表示するをご参照ください。

    説明

    古い EMR コンソールで EMR Doctor を使用するには、EMR Doctor をアクティブ化する必要があります。EMR Doctor をアクティブ化する方法の詳細については、EMR Doctor のアクティブ化（Hadoop クラスター）をご参照ください。

移行計画を策定し、移行時間を決定する

ビッグデータビジネスの状況と古いクラスターの実際の構成に基づいて最終的な移行オブジェクトを決定し、次の重要な情報を明確にしてから、後続の移行操作を参照して、人的資源と移行サイクルを合理的に計画します。

• 新しいクラスターの製品バージョンとサービス。サービスとコンポーネントの互換性については、このトピックの 製品バージョンとオプションサービス（少なくとも 1 つを選択）をご参照ください。

• 新しいクラスターのメタデータストレージと管理方法。DLF 統合メタデータまたはセルフマネージド RDS を選択します。

• 新しいクラスターのストレージソリューション。OSS-HDFS または OSS を選択します。

ステップ 1：新しい EMR コンソールでクラスターを作成する

新しいクラスターを作成する

新しいクラスターの作成方法については、クラスターの作成をご参照ください。インスタンス構成の表示のフェーズでソートした設定に基づいてパラメーターを構成できます。次の構成に注意してください。

• 製品バージョンとオプションサービス（少なくとも 1 つを選択）

  インスタンス構成の表示のフェーズでソートされたサービスの互換性とサービスリストに基づいて、新しいクラスターにデプロイする特定のバージョンのサービスを選択できます。

  • サービスの互換性

    オープンソースコミュニティでのサービスのバージョンアップデートにより、DataLake クラスターの特定のサービスのバージョンは、Hadoop クラスターのバージョンよりも遅れています。次の表に、新しいバージョンのサービスの下位互換性を示します。古いクラスターのソフトウェアバージョン情報と次の表に記載されている情報に基づいて、新しいクラスターのサービスのバージョンを決定できます。

    古い EMR コンソールのクラスターサービス	下位互換性範囲 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、Ooize は新しい EMR コンソールではサポートされていません。これらのサービスの構成を EMR Notebook または EMR Workflow に移行するか、新しいクラスターに対応するエンジンを構築することをお勧めします。

  • 製品バージョン

    重要

    ソフトウェアバージョンが要件を満たしている場合は、最新の EMR バージョンを選択してより多くの機能を使用することをお勧めします。

    データレイクシナリオでは、Alibaba Cloud EMR は EMR V3.X および EMR V5.X の製品バージョンシリーズを提供します。各シリーズには複数の製品バージョンが含まれており、サービスとサービスバージョンは製品バージョンによって異なります。新しいクラスターを作成するときは、データレイクシナリオとサービス互換性の要件に基づいて適切な製品バージョンを選択する必要があります。次の表に、古いクラスターと新しいクラスター間の製品バージョンのマッピングを示します。

    古いクラスターの製品バージョン	新しいクラスターの製品バージョン
    EMR V3.35.0：YARN 2.8.5、HDFS 2.8.5、Hive 2.3.7、Spark 2.4.7	EMR V3.X シリーズ
    EMR V5.6.0：YARN 3.2.1、HDFS 3.2.1、Hive 3.1.2、Spark 3.2.1	EMR V5.X シリーズ

  • HDFS と OSS-HDFS の選択

    EMR V5.12.1、EMR V3.46.1、または EMR V5.12.1 もしくは EMR V3.46.1 より後のマイナーバージョンでは、オプションサービスから HDFS または OSS-HDFS を基盤となるストレージとして選択できます。

    

    新しいクラスターを作成するときは、このトピックの 移行計画を策定し、移行時間を決定する で決定したクラスターストレージソリューションに基づいてオプションサービスを選択します。

    新しい EMR コンソールのストレージ	選択するサービス
    OSS	OSS-HDFS
    OSS-HDFS	OSS-HDFS

    説明

    オプションサービスから OSS-HDFS を選択する場合は、[クラスターのルートストレージディレクトリ] パラメーターも構成して、OSS-HDFS が有効になっているバケットを新しいクラスターのルートストレージパスとして指定する必要があります。

• メタデータ

  新しい EMR コンソールでは、次のメタデータストレージタイプがサポートされています。このトピックの 移行計画を策定し、移行時間を決定する で決定したメタデータストレージソリューションに基づいてタイプを選択します。メタデータの移行が必要な場合は、新しいクラスターの作成後に、このトピックの メタデータを移行する を参照してメタデータを移行します。

  メタデータストレージタイプ	説明
  DLF 統合メタデータ（推奨）	メタデータは DLF に保存されます。古い EMR コンソールで DLF がすでに使用されている場合は、[DLF カタログ] パラメーターを古い EMR コンソールで指定された値に設定できます。新しいクラスターが作成されると、同じメタデータが自動的に同期されるため、メタデータを移行する必要はありません。DLFカタログ
  セルフマネージド RDS	メタデータはセルフマネージド Alibaba Cloud ApsaraDB RDS データベースに保存されます。セルフマネージド RDS を選択する場合は、既存の ApsaraDB RDS データベースのパラメーターを構成する必要があります。詳細については、セルフマネージド ApsaraDB for MySQL データベースを構成するをご参照ください。
  組み込み MySQL	メタデータはクラスターのローカル MySQL データベースに保存されます。 重要 このタイプはテスト環境でのみ使用されます。

• （オプション）カスタムソフトウェア構成

  古いクラスターのサービス構成をエクスポートした場合、またはサービス構成を新しいクラスターのプリセット構成として使用する予定の場合は、新しいクラスターの作成時に [カスタムソフトウェア構成] をオンにし、[カスタムソフトウェア構成] をオンにした後に表示されるフィールドにサービス構成をコピーできます。詳細については、ソフトウェア構成のカスタマイズをご参照ください。

• ハードウェア構成

  インスタンス構成の表示のフェーズでは、古いクラスターの各ノードのハードウェア構成を包括的に理解できます。ビジネス要件に基づいて、マスター、コア、タスクなどのさまざまなノードタイプに適切なハードウェアリソース構成を選択する必要があります。

  • 新しいクラスターを作成するときは、最新の Elastic Compute Service（ECS）インスタンスファミリとクラウドディスクタイプを選択して、更新されたハードウェア機能を使用することをお勧めします。

  • 新しいクラスターを作成した後、同じロールが割り当てられたノードグループを作成できます。

  • [パブリックネットワーク IP の割り当て]：ノードグループのインターネットアクセスを有効にするかどうかを決定できます。スイッチをオンにすると、ノードグループのすべてのノードがインターネットに接続されます。

    インターネット経由でクラスターのマスターノードにログオンする場合、またはオープンソースコンポーネントの Web UI にアクセスする機能を使用する場合は、マスターノードグループのスイッチをオンにする必要があります。

（オプション）新しい EMR コンソールでゲートウェイを作成する

ゲートウェイは、ジョブを EMR クラスターに送信し、クラスターを安全に分離するために使用されます。古い EMR コンソールでゲートウェイクラスターをすでに使用している場合は、新しい EMR コンソールでゲートウェイを作成できます。

EMR は、新しい EMR コンソールでより柔軟なゲートウェイデプロイメントプランを提供します。これにより、既存の ECS インスタンスにゲートウェイをデプロイし、クラスターの構成の自動同期を実装できます。ゲートウェイのデプロイメントを簡素化するために、EMR は EMR-CLI ツールを提供します。これを使用して、Alibaba Cloud ECS インスタンスにゲートウェイを簡単にデプロイできます。詳細については、EMR-CLI を使用してゲートウェイをデプロイするをご参照ください。

ステップ 2：データの移行と検証

新しいクラスター環境を構築した後、メタデータ、データ、およびジョブを古いクラスターから新しいクラスターに移行する必要があります。

メタデータを移行する

古い EMR コンソールと新しい EMR コンソールは、DLF 統合メタデータ、セルフマネージド RDS、組み込み MySQL などのメタデータ管理モードをサポートしています。新しいクラスターを作成するときは、DLF 統合メタデータを選択することを強くお勧めします。次の表に、古い EMR コンソールと新しい EMR コンソールのさまざまなメタデータ管理モードのメタデータ移行計画を示します。

データを移行する

次の表に、古い EMR コンソールと新しい EMR コンソールのさまざまなストレージモードのデータ移行方法を示します。ビジネス要件に基づいて方法を選択して、古いクラスターのデータを新しいクラスターにスムーズかつ正確に移行できるようにします。

データを検証する

データが新しいクラスターに移行された後、HDFS データや Hive データベースとテーブルのデータなど、データの正確性を検証する必要があります。データの不整合が特定された場合は、すぐに問題のトラブルシューティングを行う必要があります。たとえば、影響を受けるタスクを再実行したり、不足しているデータを補足したりできます。

データ検証の要件に基づいて方法を選択できます。

ジョブを移行する

古いクラスターのジョブを新しいクラスターで期待どおりにスケジュールおよび実行できるようにするために、さまざまなスケジューリングシステムと環境で次の移行ポリシーが提供されています。

• 古い EMR コンソールの Data Platform でデータ開発機能を使用している場合は、古い EMR コンソールの EMR Data Platform から EMR Workflow にジョブを移行する必要があります。詳細については、古い EMR コンソールの EMR Data Platform からのデータ移行に関するお知らせをご参照ください。

• Alibaba Cloud DataWorks やセルフマネージド開発プラットフォームなど、別の開発環境を使用している場合は、関連する開発環境で提供されている移行計画に記載されている手順に従ってください。

  対応するプラットフォームの特定の移行ドキュメントを参照し、実際のデプロイ状況とビジネス要件に基づいて関連する構成を調整します。たとえば、コンピューティングクラスター情報などの主要な設定を変更して、ジョブが新しいクラスターで期待どおりにスケジュールされるようにすることができます。

ステップ 3：古いクラスターと新しいクラスターでダブルラン検証を実行する

クラスター間でデータを移行する場合、オンラインビジネスへの潜在的な影響を最小限に抑えるために、クラスターのダブルラン検証が必要です。プロセスには、オンライントラフィックの新しいクラスターへの複製と、新しいクラスターでのジョブの実行が含まれます。これは、データの一貫性とビジネスの正確性を確保するのに役立ちます。

ダブルラン検証の具体的な方法は、実際の開発環境、ビジネス特性、データ処理要件によって異なります。したがって、ビジネスシナリオと要件に基づいて適切なダブルラン検証計画を柔軟に策定することを強くお勧めします。

ステップ 4：古いクラスターをリリースする

ビジネスデータの検証が完了したら、データを配信できます。古いクラスターから新しいクラスターにジョブを徐々に移行し、新しいクラスターのジョブ処理量を徐々に増やして、すべてのジョブが新しいクラスターで安定して実行されるようにします。

古いクラスターのビジネスデータが新しいクラスターに完全に移行され、古いクラスターでビジネスデータが実行されなくなったら、クラスターのリリースに記載されている手順に従って、古いクラスターを安全かつ秩序立った方法でリリースできます。