はじめに
HDInsight4.0ではHiveは3.1.0が採用されていて、HDInsight 3.6で使われている2.1からメジャーバージョンアップされている。主だった機能追加としては、マテリアライズドビュー、クエリ結果のキャッシュ、デフォルトでACID準拠テーブルになったこと等がある。HDInsight3.6と4.0では異なるMetastore schemaが必要になるので、両バージョン間で Hive metastoreを共有することができない。これはHDInsight3.6でHiveを使っている場合に、4.0にマイグレーションする際に、Hive metastoreのアップグレードが必要になるという事である。そこで、できるだけマイグレーション元のHDInsight3.6でのワークロードに影響を与えずに、同じHive metastoreを4.0用にアップグレードする方法を試してみた。
1. 既存のHive metastoreのバックアップ
まず既存のHive metastoreを安全に動かしたままでアップグレード作業ができるようにするために、既存のHive metastoreをコピーする。アップグレード作業は一度実施すると元に戻すことが非常に困難なので、現行で稼働している環境には影響を与えないように作業したほうがよさそうである。
Hive metastoreはAzure SQL Databaseで稼働しているので、SQL Databaseの機能を使って取得されている自動バックアップを別のデータベースとして復元してあげればOK。以下のような感じ。
2. アップグレードスクリプトの実行
DBを別名で復元完了したら、そのHive metastoreに対してスキーマのアップグレードスクリプトを実行する。既存のHDInsight 3.6 Hive LLAPクラスターの管理ブレードを開き、下記のようにScript actionを実行する。
| 項目 | 設定 | 補足 |
|---|---|---|
| Script type | - Custom | 専用のBashスクリプトを実行するためCustomを選択 |
| Name | 任意の名前 | アンダースコア等は使えないみたい |
| Bash script URI | https://hdiconfigactions.blob.core.windows.net/hivemetastoreschemaupgrade/launch-schema-upgrade.sh | このURIのまま利用する |
| Node type(s) | Head | Headのみにチェックを入れる。ほかに入れない |
| Parameters | ServerName DatabaseName UserName Password | これらの4つをスペース区切りで指定 ※サーバ名のところに.database.windows.netは含めない※ |
スクリプトの実行が完了したら、該当のSQL DatabaseでHive metastoreのスキーマ バージョンを確認する。以下のようにdbo.VERSIONテーブルに対してクエリを実行して、SCHEMA_VERSIONが3.1.0と表示されればOK。
※私の環境だとスクリプト実行前のSCHEMA_VERSIONは2.1.2000になっていた。
これでHDInsight4.0のHive metastoreとしてアタッチできるようになる。HDInsight4.0のHive LLAPクラスターを新規作成 (作成されているものがあればそれを使用) して、アップグレード済みのHive metastoreのSQL Databaseを設定する。新規作成の場合は、作成中に外部metastoreを設定する箇所があるので、そこで設定。既存のクラスターに対して設定する場合は、以下のURLを参照。
https://docs.microsoft.com/ja-jp/azure/hdinsight/hdinsight-use-external-metadata-stores
また、もともとのデータが入っているストレージアカウントへのアクセス権をHDInsight 4.0のクラスターにも付与しておく必要がある。
3. Hiveテーブルのマイグレーション
HDInsight3.6のHiveテーブルはデフォルト設定が非ACIDで、設定によりACID準拠に変更する。HDInsight4.0の場合はデフォルトでACID準拠テーブルになる。よって、使い方によってはこれらが混在することになる。HDInsight3.6と4.0のACIDテーブルはACIDデルタの仕様が異なるため、これをマイグレーションする必要がある。
下準備としてテーブルに対して圧縮を実行する。これにより、一貫性が保証された状態を強制的に作れる。
HDInsight4.0クラスターにSSHログインしてから、BeelineでHiveに接続。
beeline -u 'jdbc:hive2://ヘッドノード:10001/;transportMode=http'
そして、ALTER TABLE文で圧縮を実行する。
ALTER TABLE テーブル名 compact 'major';
これらの下準備が完了したら、ようやく実際のHive metastoreをマイグレーションすることが可能になる。公式ドキュメントによると、移行を了するとHDInsight4.0のHiveテーブルは下記のようになる。既存のアプリケーションでこれらにアクセスしているものがあれば、設定やコードなどを調整する必要がある。
| HDInsight3.6 | HDInsight4.0 |
|---|---|
| 外部テーブル | 外部テーブル |
| 非トランザクションマネージドテーブル | 外部テーブル |
| トランザクションマネージドテーブル | マネージドテーブル |
マイグレーションを実行するためにhiveユーザーにスイッチする。
sudo su - hive
以下のコマンドを実行してマイグレーションを実行する。${{STACK_VERSION}}の部分は実際のバージョンを指定。ディレクトリを見ればわかる。
/usr/hdp/${{STACK_VERSION}}/hive/bin/hive --config /etc/hive/conf --service strictmanagedmigration --hiveconf hive.strict.managed.tables=true -m automatic automatic --modifyManagedTables --oldWarehouseRoot /apps/hive/warehouse
このコマンドが成功するとマイグレーションが完了し、HDInsight4.0のHiveから利用可能になる。この状態でHDInsight4.0クラスターは既存のHDInsight3.6クラスターとは独立して動作確認することができる。この環境でしっかりと移行前の動作確認を行い、確認が取れたら切り替えするという段取りになるだろう。そして必要に応じて以前のHDInsight3.6やそのHive metastoreを削除ということになる。
参考リンク
- Azure HDInsight 3.6 Hive ワークロードを Hive HDInsight 4.0 に移行する
- Azure HDInsight での外部メタデータ ストアの使用
- Prepare Hive for upgrade
- Register and Install Target Version
- データベースの自動バックアップを使用した Azure SQL データベースの復旧