この記事について
以下のドキュメントより、手順実施前の考慮事項までを翻訳したものです。
翻訳
このタスクについて
データレイクのリストアは、以下の状況で必要になります。
- 新しい環境にデータレイクの内容を移行するとき
- データレイクのリペアが失敗したとき
- データレイクを削除して再作成するとき
- アップグレードが失敗しロールバックが必要なとき
データレイクのリストアを行うと、既存のデータを削除した上で、特定のバックアップからデータを再作成します。この操作には、データベースのテーブルのドロップ、HBase のテーブルのドロップ、 Solr のコレクションの削除を含みます。
データレイクのバックアップおよびリストアの仕組みを利用する際は、他のソースのバックアップを利用するのを避けるべきです。この手順に示すバックアップの操作が、サービスのメタデータの非一貫性を極小化するためです。独立したデータベースによるバックアップのような、他のソースからデータをリストアすると、リストアの操作はデータレイクのメタデータにまたがる一貫性を保証できません。
このシステムでは、他のバックアップやリストアが進行中でないかどうかを確認します。
始める前に
データレイクのリストアを行っている間には、ダウンタイムがあります。なぜなら、いくつかのデータレイクのサービスが停止するからです。さらに、リストアの進行中はHMSおよびRangerのデータベースへのアクセスがブロックされます。データレイクのリストアを稼働させている間は、ワークロードを稼働させないようにしてください。
クラウドプロバイダー別の考慮事項
AWS の場合
以下のロールに、データレイクのリストアのためのIAMロール（ポリシーのJSONのリンクはこちら）を付与します。
- DATALAKE_ADMIN_ROLE
- RANGER_AUDIT_ROLE
- LOG_ROLE
IAMロールに関する詳細は、Cloud ストレージに対する最低限の設定（英語ドキュメント）をご覧ください。
データレイクのリストアのためのIAMポリシーの中で、${BACKUP_LOCATION_BASE}の部分を、バックアップを保存するロケーション名に変更してください。
Azure の場合
以下のロールが、バックアップの保存先に対する Storage Blob Data Contributor 権限を持っていることを確認してください。
- Data Lake Admin identity
- Ranger Audit Logger identity
GCP の場合
（省略）
メタデータを復元する新しい環境では、できるだけ同じデータバケット（AWSやGCPの場合）／ストレージアカウントやコンテナー（Azureの場合）、そして同じIAMロールやIDを使うことが強く推奨されます。
異なるデータバケット（AWSやGCPの場合）／ストレージアカウントやコンテナー（Azureの場合）およびIAMロールやIDを利用する場合は、以下の追加の確認事項が必要になります。
- 新環境に対するIAMロール／IDが、バックアップ先と旧環境のデータロケーションに対する読み書きの権限も持っていること
- 異なるデータバケット（AWSやGCPの場合）／ストレージアカウントやコンテナー（Azureの場合）を使用する場合、新しいロケーションには新たなデータが保存され、旧環境には依然として既存のデータが残ることによって、データが二つの異なるロケーションに分散されることを理解してください。この点が望ましくないこともあるでしょう。
Cloudera Data Warehouse を利用している場合
Cloudera Data Warehouse を利用しており、データレイクを新環境にリストアする場合、データレイクをリストアする前に Cloudera Data Warehouse のUIから以下の操作を行なってください。
-
手順①：データベースカタログおよび仮想ウェアハウスの情報を記録しておく
- データベースカタログに紐づく仮想ウェアハウスの数と名称
- 各仮想ウェアハウスおよびデータベースカタログに紐づく設定。特に、カスタマイズした設定
-
手順②：既存のCloudera Data Warehouse 環境に紐づく既存の仮想ウェアハウスと、ユーザー作成のデータベースカタログを削除する
-
手順③：Cloudera Data Warehouse の環境を Deactivate する（これにより、デフォルトのデータカタログが削除されます）
データレイクのリストア完了後、UI から Cloudera Data Warehouse の環境を activate し Cloudera Virtual Warehouse を再作成することができます
Cloudera Data Warehouse のメタデータおよびリストア後のデータレイクに関する重要な考慮事項
デフォルトのデータベースカタログに紐づく仮想ウェアハウスについては、以下の考慮事項が挙げられます。
- データベース、テーブルおよびビューなどのメタデータはリストアされます
- クラウドストレージのロケーション、たとえばS3バケットのオブジェクトなどが上記の手順②と③の後で削除／変更されていない限り、既存のテーブルに紐づくデータは参照可能です。
- Hue および DAS に保存されていたクエリの履歴は参照できなくなります
- 仮想ウェアハウスおよびデータベースカタログに加えた設定のカスタマイズは、リストア後は保存されません
- 仮想ウェアハウスおよびデータベースカタログのHive/Impalaのバージョンは、対応する Cloudera Data warehouse のバージョンに合わせて最新のものが適用されます。
デフォルト以外のデータベースカタログに紐づく仮想ウェアハウスについては、以下の考慮事項が挙げられます。
- メタデータやデータはリストアされず、可視化もされません。
内部の Ranger ユーザーのパスワードのリセット
リストアの処理のにおいて、RDSのデータベースは特に排除しない限りはリストアされます。Rangerの内部ユーザー（admin, keyadmin など）のパスワードはRDSに保存されていることに留意してください。RDSのデータベースがリストアされると、すべてのRanger の内部ユーザーのパスワードは、バックアップが最初に実施されたときのものに書き替わります。これは、SSOでRangerにログインするユーザーには影響を与えません。
影響を受けるユーザーアカウントは以下を含みます。
(ただし、下記のみではありません)
- admin ユーザー
- keyadmin ユーザー
- tagsync ユーザー
- usersync ユーザー
リストアのあと、Ranger の管理者アクセスを持つユーザーは必要に応じてRangerのUIにログインし、これらのユーザーのパスワードを変更することができます。
重要！
admin ユーザーはこの挙動に影響を受けるため、リストア先のDataLakeには少なくともひとつのSSOアカウントがRangerの管理者権限を持っているべきです。もしリストア後に admin ユーザーのパスワードがわからなかった場合、管理者アクセスを失う可能性を防ぐためです。