第6回　Hiveでボトルネックとなってきたメタデータ、HBaseを使ってレイテンシの改善に挑む ―「Hadoop Summit 2016 San Jose」から

2016年6/28～6/30（米国時間）の3日間に渡って米サンノゼで開催された「Hadoop Summit 2016 San Jose」（⁠主催: Hortornworks／Yahoo!）では、2016年のHadoopトレンドを紹介する数多くの技術／事例セッションが行われました。本稿ではそのひとつ、Hortonwokrsによるセッション「hive HBase Metastore - Improving Hive with a Big Data Metadata Storage」をもとに、HiveのメタデータをHBaseでストアすることでHiveの低レイテンシ化を図る技術について紹介します。

Hiveのメタデータを保管する「メタストア」とは？

HadoopのデータをMapReduceではなく、多くのユーザが慣れ親しんだSQLで扱う、いわゆる"SQL-on-Hadoop"な技術の先駆けとして、いまも高い人気を誇るのがHiveです。最近ではSpark SQLやPrestoなどの勢いにやや押されがちなところもありますが、生みの親であるFacebookでの導入実績やコミュニティの活発さなどを見ると、やはりSQL-on-Hadoopのデファクトスタンダードと呼ぶにはHiveがもっともふさわしい技術であるように思えます。

現在、Hadoopとそのエコシステムはかつてのバッチオリエンテッドなソリューションとしての位置づけから大きく進化し、リアルタイム性を強く指向するようになっています。Sparkの急速な台頭はまさにそのあらわれであり、高い精度とパフォーマンスの両立が当然のように期待されるようになりました。

そうした中、高スループットなバッチ処理を前提に開発された技術であるHiveは、低レイテンシという観点からはやや不利な状況にあるのは事実です。このためHiveプロジェクトでは、Hiveのパフォーマンス向上を図るための取り組みが数多く行われてきました。カラムナ型ストレージのサポートやオプティマイザの改善などはその一環であり、結果、初期のころに比べるとHive自体のパフォーマンスは100倍以上も速くなっています。さらにHortonworksなどが中心となってStingerやLLAP（Live Long and Process）といったHiveの低レイテンシ化を実現するための技術も開発されており、「⁠Hiveは遅い」という認識はすこしずつあらためられてきているようにも思えます。

しかしここにきて、Hive自身のパフォーマンス強化だけでは追いつかない問題が表面化するようになりました。それが「メタストア（metastore⁠）⁠」の存在です。

Hiveはテーブルやパーティション、ロールなどのメタデータをメタストアというデータで保持しています。メタストア自体はリポジトリとして外部のMySQLやPostgreSQL、OracleなどのRDBMSを利用するしくみになっており、これによってHiveはメタデータやスキーマの管理に煩わされる手間から解放されています。なお、ネットワーク経由でメタストアデータベースに接続する際には、Hiveクライアントとメタストアの間にThriftサーバをプロキシのようにはさんで利用しますが、これ以外にもHive内部に組み込まれているDerby DBをメタストアとして利用することも可能です。

メタストアはHiveアーキテクチャの最大の要でもあり、Spark SQLやDrillなど他のSQL-on-Hadoopな技術もHiveのメタストアとの統合や連携を重視ししています。しかし、扱うべきデータ量の増大は当然ながらメタデータの量も爆発的に増加させることになり、Hiveアプリケーションの実行において「メタストアのプランニングタイムが無視できないレベルになりつつある。とくにメタデータのフェッチに費やす時間が非常に長くなっている」（⁠Hortonworks）というケースが目立つようになりました。Hive本体のパフォーマンス強化に加え、メタストア周りを見直さないとレイテンシの課題は解決しにくくなっているといえます。

メタデータの増大は、レイテンシのほかにもスケーラビリティや複雑性の問題をHiveにもたらしています。「⁠メタデータが増えるほどに、パーティションの数も増大する。また新しいタイプのメタデータ（splitの情報、ORCのRawGroupのインデックス情報など）が登場し、コールの数も増えている。（⁠メタデータの）サイズも種類も発生頻度も昔とは比較にならない」「⁠既存のORモデリングではもはや整合性を保てない」（⁠Hortonworks）など、Hiveは現在、メタデータ自身の"ビッグデータ化"向き合う必要性に迫られているのです。

トランザクションをどう実装するか

メタストアが抱えている課題に対し、HortonworksらのHiveコミュニティメンバーが取り組んでいるのが、同じHadoopエコシステムのNoSQLストレージ技術であるHBaseとの連携です。つまり一般的なRDBMSだけでなく、HBaseをメタストアリポジトリとして活用する試みです。Hortonworksはこれを「HBase MetaStore」と呼んでいます。ビッグデータ化が進むメタデータを、ビッグデータの扱いを得意とするNoSQLで処理するというのは非常に興味深い着眼点です。

具体的なアーキテクチャとしては、Hiveクライアントとバックエンド（メタストアリポジトリ）をつなぐThriftサーバ上にインタフェース（RowStoreインタフェース）を実装する際、その実装クラスとしてRDBMSと接続するためのObjectStoreのほかに、HBaseと接続するためのHBaseStoreも実装し、新たに「HiveMetaStore Thrift Server」として機能させることを目的としています。

しかしここで問題になってくるのは、NoSQLデータベースであるHBaseはトランザクションレイヤをもたないことです。HBase MetaStoreはアトミックであることが求められます。テーブルやパーティションが作成されるたびに、そのデータを格納するストレージもディスクリプタによってひもづけられ、テーブル定義に変更があればパーティションも変更されます。トランザクションをサポートしないHBaseでは、これらが完全には担保されません。

これを解決するためにHBase MetaStoreでは、Thriftサーバとバックエンド（HBase）の間に、「⁠Omid（Optimistically transaction Management In Data-stores）」というトランザクションレイヤを介しています。Omidはもともと2011年にYahoo!でスタートしたオープンソースプロジェクトで、現在はApacheのインキュベーションプロジェクトとして開発が進められています。トランザクション機能を捨ててパフォーマンスとスケーラビリティを得たはずのHBaseですが、やはり大規模になればなるほど、トランザクションを扱いたいというユーザのニーズが出てくるのは当然の流れなのかもしれません。

Omidは分離レベルとしてSnapshot Isolationを採用しており、リード/ライトのいずれのモードでも、ロック/デッドロック/ブロックが行われないことを担保しています。もし2つのコンカレントトランザクションが同じデータにアクセスした場合は、後者のトランザクションがアボートされます。これは元の名前が"Optimistically（楽観的）"で始まっていることからもわかります。またオーバヘッドが小さいことも特徴のひとつです。

Omidの主要なコンポーネントは

Transaction Clients
Transaction Status Oracle（TSO）
Commit Table
Shadow Cells

とOmidのドキュメントには書かれていますが、Hortonworksは本セッションでHBase MetaStoreに特化するために以下のの3つに分けて説明していました。

TSO Server（Timestamp Oracle）: トランザクションのタイムスタンプを生成し、コンカンレントなトランザクションの衝突を避ける
TSO Client: TSOサーバと会話するクライアント、トランザクションメタデータをキャッシュする
Compactor: HBase内部のコプロセッサとしてデプロイ

ここで言う"Oracle"とは某データベース巨大企業のことではなく、タイムスタンプを指してこう呼んでいます。

なおHBase MetaStoreではすべてのトラフィックをOmid経由にするのではなく、揮発性データやコンフリクトの可能性が高い場合はOmidをバイパスし、トランザクション処理をしないことも可能です。

高レベルな「ACID」の担保をめざすHBase MetaStore

セッションではベンチマーク結果として、TPC/DSクエリを「ObjectStore」「⁠HBaseStore（Omidあり⁠）⁠」⁠「⁠HBaseStore（Omidなし⁠）⁠」で実行した場合のHiveメタストアのプランニングタイムをそれぞれ紹介しています。全体的にObjectStoreよりもHBaseMetaStoreのほうが短時間で済んでいるようですが、現時点ではOmidのあり／なしではそれほど大きな差はついていないようです。逆にいえば、トランザクションレイヤとしてOmidを介しても実行速度にほとんど変わりがないという点は評価されるといえます。ただし、Omidは現状、「⁠CPU使用率が非常に高い」（⁠Hortonworks）ため、効率的に利用するためにはもう少し改善が必要でしょう。

HBase MetaStoreは2015年9月にマージされたばかりの取り組みです。したがってやるべき課題も多い状況にありますが、もっとも重要なのは「トランザクションを扱うからこそACIDを高いレベルで担保することにある」とHortonworksはコメントしています。現在はメタデータのためのトランザクションサーバを新たに実装することも検討されているようです。

前述したように、高速化と大量データへの対応は時代のニーズであり、Hiveもその潮流から外れることはできません。今後もHBase MetaStoreのように、オリジナルの設計に大きく手を入れる取り組みは増えていきそうです。