HBase から Bigtable へ移行する方法 2
次世代システム研究室の Y.I. です。
HBase を Google Cloud Platform (GCP) 上の Bigtable へ移行した話「 HBase から Bigtable へ移行する方法 」の続きです。今回は主にアプリケーションや Bigtable について知見をまとめます。
内容
- 概要
- Bigtable 移行メリット
- Bigtable 移行デメリット
- ハマった事
概要
今回 Playframework を利用した Java Web アプリケーションおよびデータストアも HBase から Bigtable へ移行しました。アプリケーションでは HBase を操作しているコードを Bigtable へ対応するように修正を行いました。Bigtable 移行メリット
・アプリケーションの変更がほぼ必要ない
HBase から Bigtable への移行に伴うアプリケーションの変更内容は2つだけで済みました。1つはライブラリーの変更、もう一つは HBase 接続コードを Bigtable 接続コードへの変更です。 Bigtable CRUD など各種操作について HBase 用コードを変更しなくても大丈夫なためコードの修正コストは著しく低く対応できました。こちらが一番のメリットと感じています。・build.sbt
libraryDependencies += "org.apache.hbase" % "hbase-client" % "1.1.2.2.3.2.9-1" libraryDependencies += "org.apache.hbase" % "hbase-common" % "1.1.2.2.3.2.9-1" ↓ com.google.cloud.bigtable" % "bigtable-hbase-1.x-shaded" % "1.14.1" ※ バージョンは時点のものになります。適宜最新バージョンに置き換えてください。
・接続コード
- HBase向け
Configuration newConfig = HBaseConfiguration.create();
newConfig.set("hbase.zookeeper.quorum", Play.application().configuration().getString("hbase.servers"));
newConfig.set("hbase.zookeeper.property.clientPort", Play.application().configuration().getString("hbase.port"));
newConfig.set("zookeeper.znode.parent", Play.application().configuration().getString("zookeeper.znode.parent"));
↓
- Bigtable向け
Configuration config = BigtableConfiguration.configure("{GCP projectId}", {Bigtable instanceId});
BigtableConfiguration.connect(config);
・運用コストが減る
Bigtable は GCP のマネージドサービスとして提供されているので、インフラ運用コストが削減できます。Bigtable 構築も主に node や disk 種類や必要ならばレプリケーションもWebコンソールで指定して起動できます。監視も Monitoring 機能がWebコンソールで提供されていて、Bigtable instance/table毎に R/W をはじめとした各種メトリクスをグラフで参照することができます。
バックアップも Web コンソールから取得できるなど、充実した機能が提供されています。
Bigtable へ移行したデメリット
正直なところあまりありませんが、あげるとしたら・情報が少ない
Google 公式のドキュメント以外に求めている情報に関する Bigtable についてのテックブログやQAなどがなかなか見つからないことが多いです。 HBase に関する情報を元に Bigtable へ適用してみるなどトライアンドエラーすることもありました。・Bigtable ブラックボックス
HBase と比較して Bigtable はコードなどブラックボックスになるため、問題調査の困難さが上がることがあります。ハマった事
・column family の versions指定が機能しない
Google 社提供のBigtable の cli ツール cbt を使用して column family に versions=1 ( cbt setgcpolicy <table> <family> maxversions=1 )を設定した際に versions = 1 が機能しませんでした。versions =1 を指定すると履歴データは持たない想定でしたがデータ更新があった際にいつまでも履歴データが削除されず参照すると複数の履歴データが参照できる状態になっていました。公式ドキュメントに負荷状況により最大7日間データが削除されないと記載がありましたので8日間様子を見てみましたが履歴が削除されることはありませんでした。[解決方法]
・Cloud Bigtable 用 hbase shell を使用して versions を指定する
create 'table_name',
{NAME => 'column_family', VERSIONS => 1, DATA_BLOCK_ENCODING => 'NONE', BLOOMFILTER => 'ROW', BLOCKCACHE => true}
こちらで作った table/column family はリアルタイムではありませんでしたが、1時間も待たずに履歴データが削除されました。特に情報がなく解決に苦労しました。ツール参照URL (公式URL)
cbt
https://cloud.google.com/bigtable/docs/cbt-overview?hl=ja
Cloud Bigtable 用 hbase shell
https://cloud.google.com/bigtable/docs/installing-hbase-shell?hl=ja
・bigtable-hbase lib 3種類あり
利用できるライブラリーが下記3つあり、調査用コードで bigtable-hbase-1.x を使って Bigtable に接続して CRUD 確認をとりましたが、本番コードで適用したところエラーとなり動作しませんでした。– bigtable-hbase-1.x
– bigtable-hbase-1.x-hadoop
– bigtable-hbase-1.x-shaded
公式URL
https://cloud.google.com/bigtable/docs/upgrading-clients?hl=ja
[解決方法]
・bigtable-hbase-1.x-shaded を使用する
今回の対応は shaded を使用することが正解でした。調査用コードでは動作していたので気づくまでに時間がかかってしまいました。BIgtable 系エラーが発生した際には他ライブラリーの使用を試してください。
・Bigtable 用 Key Visualizer 診断ツール 1テーブル30GB以上ないと利用できない
Key Visualizer は Bigtable のデータアクセス状況や負荷対策に有益な状況を取得できます。負荷対策のためにデータの偏りなどアクセス負荷を把握したかったのですが、1テーブルのデータサイズが30GB以上ないと利用できませんでした。移行前にデータを削減していたこともあり今回は残念ながら利用できませんでした。最後に
HBase から Bigtable への移行は想定よりも少ないコストで移行可能でした。データの移行はもちろん、Java アプリケーションの修正も connection 周りのみで済みました。 GCP を利用されていたら Bigtable の利用を検討されてもいいのではないでしょうか。次世代システム研究室では、グループ全体のインテグレーションを支援してくれるアーキテクトを募集しています。アプリケーション開発の方、次世代システム研究室にご興味を持って頂ける方がいらっしゃいましたら、ぜひ 募集職種一覧 からご応募をお願いします。
皆さんのご応募をお待ちしています。
