次の方法で共有

Azure Data Lake Storage の移行のガイドラインとパターン

  • [アーティクル]

データ、ワークロード、アプリケーションを、Azure Data Lake Storage Gen1 から Azure Data Lake Storage Gen2 に移行することができます。 この記事では、推奨される移行方法について説明し、さまざまな移行パターンと、それぞれを使用するタイミングについて説明します。 読みやすくするため、この記事では、Azure Data Lake Storage Gen1 を Gen1 と呼び、Azure Data Lake Storage Gen2 を Gen2 と呼びます。

Note

Azure Data Lake Storage Gen1 は廃止されました。 提供終了のお知らせについては、 こちらを参照してください。Data Lake Storage Gen1 リソースにアクセスできなくなりました。

Azure Data Lake Storage Gen2 は Azure Blob Storage を基にして構築されており、ビッグ データ分析専用の機能セットを提供します。 Data Lake Storage Gen2 では、ファイル システム セマンティクス、ディレクトリ、ファイル レベルのセキュリティおよびスケーリングなどの Azure Data Lake Storage Gen1 の機能が、Azure Blob Storage の低コスト、階層型ストレージ、高可用性およびディザスター リカバリー機能と組み合わされています。

Note

Gen1 と Gen2 は異なるサービスであり、インプレース アップグレードのエクスペリエンスはありません。 Azure portal を使用して Gen2 への移行を簡略化するには、「Azure portal を使用して、Gen1 から Gen2 に Azure Data Lake Storage を移行する」を参照してください。

Gen1 から Gen2 に移行するには、次の方法が推奨されます。

手順 1:適応性を評価する

手順 2:移行を準備する

手順 3: データとアプリケーション ワークロードを移行する

手順 4:Gen1 から Gen2 に切り替える

手順 1:適応性を評価する

  1. Data Lake Storage Gen2 のオファリング (利点、コスト、一般的なアーキテクチャ) について確認します。

  2. Gen1 と Gen2 の機能を比較します。

  3. 既知の問題の一覧を確認して、機能のギャップを評価します。

  4. Gen2 では、診断ログ、アクセス レベル、Blob Storage ライフサイクル管理ポリシーなどの Blob Storage の機能がサポートされています。 これらの機能を使用することに興味がある場合は 現在のサポート レベルを確認してください。

  5. Azure エコシステムのサポート の現状を確認し、ソリューションが依存するすべてのサービスが Gen2 でサポートされていることを確認します。

手順 2:移行を準備する

  1. 移行するデータ セットを明らかにします。

    この機会を利用して、使用しなくなったデータセットをクリーンアップします。 すべてのデータを一度に移行することを計画しているのでない限り、この時間を使って、段階的に移行できるデータの論理グループを明らかにします。

    Gen1 アカウントで時系列分析 (または似たようなもの) を実行して、インベントリに長時間保存されているファイルやフォルダー、またはおそらく古くなったファイルやフォルダーを特定します。

  2. 移行がビジネスに与える影響を決定します。

    たとえば、移行の実行中にダウンタイムを許容できるかどうかを検討します。 これらの考慮事項は、適切な移行パターンを特定し、最適なツールを選択するのに役立ちます。

  3. 移行計画を作成します。

    これらの移行パターンをお勧めします。 これらのパターンのいずれかを選択するか、これらを組み合わせるか、独自のカスタム パターンを設計することができます。

手順 3:データ、ワークロード、アプリケーションを移行する

好みのパターンを使用して、データ、ワークロード、アプリケーションを移行します。 シナリオを段階的に検証することをお勧めします。

  1. ストレージ アカウントを作成し、階層型名前空間の機能を有効にします。

  2. データを移行します。

  3. Gen2 エンドポイントを指し示すように、ワークロード内のサービスを構成します。

    HDInsight クラスターの場合は、%HADOOP_HOME%/conf/core-site.xml ファイルにストレージ アカウントの構成設定を追加できます。 外部 Hive テーブルを Gen1 から Gen2 に移行する場合は、ストレージ アカウント設定を %HIVE_CONF_DIR%/hive-site.xml ファイルにも追加してください。

    各ファイルの設定は、Apache Ambari を使用して変更できます。 ストレージ アカウントの設定については、「Hadoop Azure サポート: ABFS — Azure Data Lake Storage Gen2」を参照してください。 この例では、 設定 fs.azure.account.key を使用して、共有キーの承認を有効にします。

    <property>
  <name>fs.azure.account.key.abfswales1.dfs.core.windows.net</name>
  <value>your-key-goes-here</value>
</property>

    HDInsight、Azure Databricks、およびその他の Azure サービスを構成して Gen2 を使用するようにするために役立つ記事へのリンクについては、「Azure Data Lake Storage Gen2 がサポートされている Azure のサービス」を参照してください。

  4. Gen2 API を使用するようにアプリケーションを更新します。 これらのガイドを参照してください。

環境 [アーティクル]
Azure Storage Explorer Azure Storage Explorer を使用して Azure Data Lake Storage Gen2 のディレクトリとファイルを管理する
.NET .NET を使用して Azure Data Lake Storage Gen2 でディレクトリとファイルを管理する
Java Java を使用して Azure Data Lake Storage Gen2 のディレクトリとファイルを管理する
Python Python を使用して Azure Data Lake Storage Gen2 でディレクトリとファイルを管理する
JavaScript (Node.js) Node.js の JavaScript SDK を使用して Azure Data Lake Storage Gen2 でディレクトリとファイルを管理する
REST API Azure Data Lake Store REST API

  1. Data Lake Storage Gen2 の PowerShell コマンドレットおよび Azure CLI コマンドを使用するようにスクリプトを更新します。

  2. コード ファイル、Databricks ノートブック、Apache Hive HQL ファイル、またはワークロードの一部として使用されるその他のファイルで、文字列 adl:// が含まれる URI 参照を検索します。 これらの参照を、新しいストレージ アカウントの Gen2 形式の URI に置き換えます。 たとえば、Gen1 の URI adl://mydatalakestore.azuredatalakestore.net/mydirectory/myfile は、abfss://myfilesystem@mydatalakestore.dfs.core.windows.net/mydirectory/myfile になる可能性があります。

  3. Azure ロール、ファイルとフォルダー レベルのセキュリティ、および Azure Storage ファイアウォールと仮想ネットワークを含むように、アカウントのセキュリティを構成します。

手順 4:Gen1 から Gen2 に切り替える

Gen2 でアプリケーションとワークロードが安定していることを確認したら、Gen2 を使用してビジネス シナリオを満たすことができます。 Gen1 で実行されている残りのパイプラインをオフにし、Gen1 アカウントの使用を停止します。

Gen1 と Gen2 の機能の比較

次の表は、Gen1 の機能と Gen2 の機能を比較したものです。

領域 Gen1 Gen2
データの編成 階層構造の名前空間
ファイルとフォルダーのサポート		 階層構造の名前空間
コンテナー、ファイル、フォルダーのサポート
geo 冗長 LRS LRS、ZRS、GRS、RA-GRS
認証 Microsoft Entra マネージド ID
サービス プリンシパル		 Microsoft Entra マネージド ID
サービス プリンシパル
共有アクセス キー
承認 管理 - Azure RBAC
データ - ACL		 管理 - Azure RBAC
データ - ACL、Azure RBAC
暗号化 - 保存データ サーバー側 - Microsoft マネージドまたはカスタマー マネージド キー サーバー側 - Microsoft マネージドまたはカスタマー マネージド キー
VNET のサポート VNET 統合 サービス エンドポイント、プライベート エンドポイント
開発者エクスペリエンス REST、.NET、Java、Python、PowerShell、Azure CLI 一般公開 - REST、.NET、Java、Python
パブリック プレビュー - JavaScript、PowerShell、Azure CLI
リソース ログ クラシック ログ
Azure Monitor 統合		 クラシック ログ - 一般公開
Azure Monitor 統合 - プレビュー
エコシステム HDInsight (3.6)、Azure Databricks (3.1 以降)、Azure Synapse Analytics、ADF HDInsight (3.6、4.0)、Azure Databricks (5.1 以降)、Azure Synapse Analytics、ADF

Gen1 から Gen2 へのパターン

移行パターンを選択し、必要に応じてそのパターンを変更します。

移行パターン 詳細
リフト アンド シフト 最も簡単なパターンです。 データ パイプラインがダウンタイムを許容できる場合に最適です。
増分コピー "リフト アンド シフト" に似ていますが、ダウンタイムは少なくなります。 コピーに時間がかかる大量のデータに適しています。
デュアル パイプライン ダウンタイムをまったく許容できないパイプラインに最適です。
双方向同期 "デュアル パイプライン" に似ていますが、より複雑なパイプラインに適した、いっそう段階的なアプローチです。

各パターンについて詳しく説明します。

リフト アンド シフト パターン

これは最も簡単なパターンです。

  1. Gen1 へのすべての書き込みを停止します。

  2. Gen1 から Gen2 にデータを移動します。 Azure Data Factory または Azure portal の使用をお勧めします。 ACL はデータと共にコピーします。

  3. インジェスト操作とワークロードで Gen2 をポイントします。

  4. Gen1 の使用を停止します。

リフト アンド シフト パターンのサンプル コードについては、リフト アンド シフト移行のサンプルを参照してください。

リフト アンド シフト パターン

リフト アンド シフト パターンを使用する場合の考慮事項

  • すべてのワークロードを Gen1 から Gen2 に同時に切り替えます。

  • 移行と切り替えの期間中にダウンタイムが予想されます。

  • ダウンタイムを許容できるパイプラインに最適であり、すべてのアプリを一度にアップグレードできます。

ヒント

Azure portal を使用してダウンタイムを短縮し、移行の完了に必要な手順の数を抑えることを検討してください。

増分コピー パターン

  1. Gen1 から Gen2 にデータを移動を始めます。 Azure Data Factory をお勧めします。 ACL はデータと共にコピーします。

  2. Gen1 から新しいデータを増分コピーします。

  3. すべてのデータがコピーされたら、Gen1 へのすべての書き込みを停止し、ワークロードで Gen2 をポイントします。

  4. Gen1 の使用を停止します。

増分コピー パターンのサンプル コードについては、増分コピー移行のサンプルを参照してください。

増分コピー パターン

増分コピー パターンを使用する場合の考慮事項:

  • すべてのワークロードを Gen1 から Gen2 に同時に切り替えます。

  • 切り替え期間中にのみダウンタイムが予想されます。

  • すべてのアプリが一度にアップグレードされるパイプラインに最適ですが、データのコピーにはより多くの時間が必要です。

デュアル パイプライン パターン

  1. Gen1 から Gen2 にデータを移動します。 Azure Data Factory をお勧めします。 ACL はデータと共にコピーします。

  2. Gen1 と Gen2 の両方に新しいデータを取り込みます。

  3. ワークロードで Gen2 をポイントします。

  4. Gen1 へのすべての書き込みを停止し、Gen1 の使用を停止します。

デュアル パイプライン パターンのサンプル コードについては、デュアル パイプライン移行のサンプルを参照してください。

デュアル パイプライン パターン

デュアル パイプライン パターンを使用する場合の考慮事項:

  • Gen1 パイプラインと Gen2 パイプラインがサイドバイサイドで実行されます。

  • ゼロ ダウンタイムをサポートします。

  • ワークロードとアプリケーションでダウンタイムを許容できず、両方のストレージ アカウントに取り込むことができる場合に適しています。

双方向同期パターン

  1. Gen1 と Gen2 の間に双方向のレプリケーションを設定します。 WanDisco をお勧めします。 既存のデータに修復機能が提供されます。

  2. すべての移動が完了したら、Gen1 へのすべての書き込みを停止し、双方向レプリケーションをオフにします。

  3. Gen1 の使用を停止します。

双方向同期パターンのサンプル コードについては、双方向同期移行のサンプルを参照してください。

双方向パターン

双方向同期パターンを使用する場合の考慮事項:

  • 段階的なアプローチがより効果的な、多数のパイプラインと依存関係が関係する複雑なシナリオに適しています。

  • 移行作業は多くなりますが、Gen1 と Gen2 に対してサイドバイサイドのサポートが提供されます。

次のステップ

関連項目