ImpalaとHiveの戦略について

投稿日: 2014/01/07

 

新年明けましておめでとうございます。皆様のおかげで今年も無事に新しい年を迎えることができました。

さて、新年最初の記事は、昨年暮れに CSO (Chief Strategy Officer) である Mike Olson (@mikeolson) が公開したブログポスト、Impala v Hive を紹介したいと思います。2014 年も Cloudera をよろしくお願い致します。

3日間でImpalaマスターに!


 

弊社は一年以上前に Cloudera Impala を公開しました。このローンチは弊社にとって好ましいものであり、弊社のプラットフォームはいくつかの点で良好なものとなりました。つまりそれは弊社のお客様にとって重要なことでした。また、弊社は従来は勝つことができなかったビジネスで勝利をおさめることができるようになりました。以前の製品はインタラクティブな SQL ワークロードに対応していなかったからです。

この副作用として、Impala の公開は Apache Hadoop エコシステムにおける SQL 市場のシェアを求めるベンダー間の激しい競争に火をつけ、様々な主張や反論が飛び交いました。パフォーマンスに関する大げさな主張はよく見られますが、(また、我々は我々の性能評価結果がかなり気に入っているのですが)、ここでは異なる方向からこの問題にアプローチしたいと思います。

私はよく、Impala を既存の Apache Hive プロジェクトの改良によってではなく、新たなプロジェクトとして一から開発するという Cloudera の決定について尋ねられます。既存のコードが存在するのであれば、そこからスタートするのが間違いなく最善である、という考え方によるものです。

しかし、それは違います。我々はその問題について長く、また真剣に思考した結果、最善の方法は、Hive とは異なる原理にもとづき設計される、新たなオープンソースプロジェクトを作り出すことであると結論づけました。それが Impala です。昨年一年間の我々の経験は、この戦略に対する確信を強めました。
弊社の思考の道筋をご案内しましょう。

Pig と Hive の起源

Hadoop の最初期のバージョンは、データを扱うための方法としてはただひとつ、MapReduce のみをサポートしていました。このプラットフォームは大量のデータを格納、処理、および、分析する目的で、Yahoo! と Facebook で幅広く用いられました。両社とも同プラットフォームがたいへん価値のあるものであることを理解しましたが、しかし、両社ともシステムから有用な成果を得るために、MapReduce の下で動作する Java コードを書くのに多大な時間を要しました。

両社は、より高速に動作することと、プログラマ以外がデータを直接扱えるようにすることを望みました。Yahoo! はその目的のために、Apache Pig という名称の独自の言語を作り出しました。Facebook は、おそらく人々に新たなスキルをトレーニングするよりも、既存のスキルを活用することを考え、Hive という名称の SQL システムを構築しました。

これら2つはきわめて似た原理で動作します。ユーザーは Pig か Hive のいずれかでクエリを打ち込みます。パーサはクエリを読み込み、ユーザーが何を望んでいるかを理解し、そして、一連の MapReduce のジョブを実行して動作させます。MapReduce を用いることにより、Pig と Hive は容易に構築できるので、Yahoo! と Facebook のエンジニアは他の新たな機能に時間をかけることができました。

歴史の代償

Hadoop に対する一般的な批判は、MapReduce がバッチデータ処理エンジンであることです。Hadoop はデータマネジメント業界を根本的に変化させる、たいへん有用なバッチデータ処理エンジンであることは明らかです。一方で、設計上、MapReduce はたいへん重い、高レイテンシの実行フレームワークであり、また、ジョブは開始するのが遅く、あらゆる種類のオーバーヘッドを有しているというのは公正な批判です。
そして、Pig と Hive はこれらの特性を引き継いでいます。

初期には、そのことは問題ではありませんでした。アナリティクスやレポーティングのために、自身の BI ツールを Hadoop に向ける人はいませんでした。Yahoo! と Facebook は、より多くのユーザーがデータを直接取り扱うことを望んでいました。それらのユーザーが、動作が行われている間に端末の画面を見つめながら、しばらくの間じっと座っていなければならなかったのだったとしても、それほど大きな問題ではありませんでした。遅いクエリは、クエリがないことよりましでしょう。これらの初期のワークロードの多くはデータ変換処理であり、クエリでもアナリティクスでもありません。バッチはこのことについては問題ありませんでした。

リレーショナルデータベースにデータを伝送するために ODBC や JDBC を利用するツールは、多くのベンダーから入手できます。これらのツールを Hadoop に対して動作するようにさせるのは、本当に大きな問題です。― データをそのような方法でカジュアルに扱いたいビジネスユーザーは膨大な数にのぼります。

そこで我々は初期の段階では初めてであった、広範に利用可能な Hive 用 ODBC ドライバを書き、リリースしました。そして既存の大手ベンダーは、各ベンダーのレポーティングツールを弊社のプラットフォームに接続するためにそのドライバを用いました。これらのツールを使用するのは耐え難いものでした。ユーザーはクエリを作成し、ボタンを押し、そして、待って、待って、待つのです。何十年にもわたる経験によって、人々はデータベースにリアルタイムの応答を期待するようになりました。MapReduce の上に構築された Hive は、期待に沿った結果を出すことができませんでした。

実際、Hive のパフォーマンスは、一部のベンダーのツールがまったく動作しないことを意味していました。それらのツールは、応答が速やかに返ってこなかったときに、データベースがクラッシュしたと想定し、ユーザにエラーを返したのです。
これには多くのユーザが怒りました。

Impala の開発

弊社では、SQL を Hadoop エコシステムにおいて先頭を走るものにしなければならないことを理解していました。そして、腰を据えて代替案に取り組み始めたのです。

データベース業界には、スケールアウトする分散クエリ実行エンジンの構築に関し、数十年の経験があります。これは学術的および商用の研究が活発な分野です。きわめて優秀で、きわめて高速の分散 SQL システムが多数存在しますが、それらのどれも MapReduce 型のアーキテクチャを使用していません。

ここで我々は、Hadoop アーキテクチャを初めて作り出した Google に目を向けました。Googleは、そのビッグデータへの SQL アクセスを得るための、MapReduce を基盤としない、独自の新たな分散クエリ実行エンジンを開発していました。

すべての選択肢を考え抜いた後に、まったく同じことを行おうと決めたのです。また、そのパフォーマンスについて楽観的だったので、Impala と命名しました。

同時に、我々はこのプロジェクトリーダーとして、Marcel Kornacker を雇いました。Marcel は一時期 Google で働いていましたし、また、1990年代にカリフォルニア大学バークレー校の大学院でデータベースシステムの研究をしていた人物です。彼は分散システムおよびデータベースカーネルの熟練エンジニアのチームを編成し、開発にとりかかったのです。

Cloudera クラスタ内のすべてのノードには Impala のコードが組み込まれており、SQL クエリが実行されるのを待っています。そのコードは、各ノード上でまさに MapReduce エンジンとともに、― そして、Apache HBase (MapReduce を基盤としていない) や、検索エンジン (MapReduce を基盤としていない)、ならびに、SAS および Apache Spark など、お客様が選択してデプロイできるサードパーティ製のエンジンと並んで動作します。これらのエンジンはすべてまったく同じデータへアクセスでき、ユーザは解決しようと取り組んでいる問題に応じて、そのうちのどれを使用するかを選択することができます。

Impala は SQL クエリを、今日 Hive が依存している map/shuffle/reduce などの他の処理フレームワークに翻訳する必要はありません。そのため、Impala はそれらのフェーズで被るレイテンシの影響を受けません。Impala クエリはすぐに結果を返します。Impalaは、MapReduce のような汎用分散処理システムとは異なり、SQL クエリの実行に関して一から設計されているので、その特定のワークロードについてははるかに優れたパフォーマンスを提供できるのです。

なぜ Hive を改良しないのか?

単刀直入に言えば、Hive がリアルタイム分散 SQL 処理にとっては間違ったアーキテクチャであるということです。並列 SQL データベースの世界はプレイヤーが密集している状況です。どの伝統的なリレーショナルデータベースベンダー (すなわち、IBM、Oracle、Microsoft、ParAccel、Greenplum、Teradata、Netezza、Vertica) も、MapReduce のようなものは用いません。シェアードナッシングでスケールアウトするシステムの次世代 (知名度が高いのは Google の F1 ですが、他にもそこまでは知られていない NuoDB などの選択肢もあります) はすべて、MapReduce の基盤にではなく、ネイティブの分散クエリ実行に依存しています。

Facebook は初期に、MapReduce 上に Hive を構築しましたが、それは Hadoop の SQL への最短の道だったからです。これは時間要件を前提にしたときに、賢明な決断でした。しかし、同社は最近、SQL を介したデータへのリアルタイムアクセスのための次世代クエリ実行エンジンである Presto を発表しました。Prestoは Impala と同様、分散クエリ実行エンジンとして新規に一から構築されています。

Hive を改良したり、MapReduce のチューンアップ、その他の高速化、および、レイテンシの短縮は確かに可能です。しかし、設計上、Hive は常に、オーバーヘッドが存在しますし、また、ネイティブの分散 SQL エンジンとして構築された後継システムが回避する、パフォーマンスに不利な条件が発生します。

Hive を良好に実行するために MapReduce をチューンアップすることは、別の理由でも間違っています。MapReduce は汎用バッチ処理ワークロードにおいて優れており、MapReduce を特定のクエリワークロードに特殊化する取組みは、SQLを使わないユーザに対して負担を課すことになり得ます。初期の時代には、単一のエンジンが Hadoop におけるすべての作業を行うという考えは意味がありました。今日では、(HBase、Apache Accumulo、Search、Myrrix、Spark その他の) 専用エンジンが急増しています。これらは総じて、各エンジンが特別にチューンアップされている他のワークロードを犠牲にすることなく、プラットフォームの機能を拡張します。

Impala コミュニティ

Cloudera では、2012年後半の Apache ソフトウェアライセンス下での発表前に、ほぼ2年間 Impala に取り組んできました。我々がそのようにしたのは、Hadoop 上でのリアルタイム SQL が重要な問題であると考えたからです。また、弊社は実際に製品を届けることができる前に弊社の意図を明らかにしようとは思っていませんでした。弊社には、 Impala 開発に取り組む重要なチームが存在しています。

Hive はリアルタイム SQL 用の最新の分散クエリエンジンと、パフォーマンスの面で競争することはできません。しかし、Hive エコシステムには MapReduce に依存しない構成要素があります。弊社はそれらを Impala と統合することに熱心に取り組んできました。そして、その成果として、Hive の機能強化にコントリビュートし続けています。

例えば、メタデータリポジトリとしての HCatalog や Hive メタストアのコミュニティと協力しています。多数の異なるエンジン間でデータを共有することはそれを記述するメタデータの共有を必要とするのであり、 HCatalog は弊社のエンタープライズデータハブ戦略の中核をなします。弊社による Hive メタストアや HCatalog の利用は、Hive、Impala、MapReduce、Pig、および REST の各アプリケーションがテーブルを共有できることを意味しています。

Twitter 社、Cloudera および Criteo 社は、Impala がアナリティクスデータベースワークロードをはるかに高速に実行できるようにするカラムナフォーマットである Parquet で協力しています。コントリビュートしている人たちは、Parquet を Cascading、Pig と、さらには Hive とさえも統合しようとしています。

ユーザーベースおよびロールベースの認可とアクセス制御は、データベースアプリケーションにとって重要です。Cloudera は、Impala のためのセキュリティポリシーを定義し、適用するために Sentry プロジェクトを作り、Oracle やその他のベンダーと協力しています。Sentry がないと、各 Hive ユーザーは他のあらゆる Hive ユーザに属するすべてのテーブルとすべてのレコードを参照できてしまうことになります。弊社は Sentry を Hive に統合するためのコードにコントリビュートしてきました。しかし、今日の段階でそれは商用の頒布には含まれていません。

誰が Impala を提供するのか?

オープンソースは、エンタープライズユーザーが、ソフトウェアとサービスのベストミックスを最善の価格で提供する企業とともに仕事ができることを意味しているのであり、素晴らしいものです。エンタープライズユーザーは単一のベンダーに閉じ込められることはありません。

Impala が成功するためには、多数の企業が提供でき、サポートするものでなければなりません。

もちろんみなさんは Impala を Cloudera から手に入れることができます。Impala は弊社のプラットフォームの中核をなすものであり、また、弊社のエンタープライズデータハブ戦略の中核です。これは、Impala が弊社の再販業者からも購入可能であることを意味します。Oracle は同社の Big Data Appliance において、Impala を含む Cloudera の完全なエンタープライズデータハブソフトウェアスイートを出荷しています。IBM の Softlayer 子会社、Verizon Business Systems、CenturyLink Savvis、T-Systems その他を含むクラウドベンダーが、各社が管理するクラウド内での「サービス型エンタープライズデータハブ」を提供しており、それらのなかに Impala が含まれています。

Amazon は Elastic MapReduce または EMR と呼ばれる独自のビッグデータサービスを提供しています。ちょうど先週、Amazon は、MapReduce および HBase とともに、同社の EMR 製品の一部として含まれるサードパーティ製のエンジンとしての Impala の提供を発表しました。Amazon のエンドースメントは弊社にとっては本当に素晴らしいものでした。これは弊社のアーキテクチャを信頼しているとみなしている証拠であり、また、潜在的なユーザーを新たに得ることができるのです。同様に、これはより多くのアプリケーションおよびツールのベンダーが Impala と統合することを意味しています。

私の見解では、もっとも興味深いのは、直接競合する Cloudera の競争相手が今ではお客様に対して Impala を提供しているという事実です。MapR のお客様は、同社の商用の製品に Impala を利用することができます。

5年間以上にわたり、Cloudera は Hadoop エコシステムにおける新たなオープンソースコードを構築し、出荷しています。弊社は、きわめて広範囲のプロジェクトにわたって働き、コントリビュートあるいはコミッターを擁しています。弊社は、競争相手にその製品の一部として取り上げられたプロジェクト ― Apache Flume、Apache Sqoop、Hue、Apache Bigtop ― を産み出してきました。

Impala はそのリストに連なる新たなひとつの例にすぎません。また、弊社のオープンソースプラットフォームへのコミットメントが深く、本物であるという証拠の新たな一つの側面にすぎません。これは口先だけの話ではありません。我々はその最初期から、自らの発言に従って生きてきました。みなさんが今日、弊社のパートナーと競争相手の双方を含む8つ以上の異なるベンダーから Impala を手に入れることができるという事実は、弊社のオープンソース戦略を間違いなく証明しています。

なぜこれほど多くの SQL エンジンがあるのか?

この世界を見渡してみてください。そうすれば、市場に存在するベンダーの数と少なくとも同じだけの数の、Hadoop 上で動作する SQL エンジンが存在していることがわかります。Cloudera は Impala を提供します。IBM は同社の BigSQL 製品を好むでしょう。Pivotal は明確に HAWQ にコミットしています。Hortonworks は Hive への忠誠を宣言しました。初期の参入者である Hadapt は、NoSQL ワークロードも引き受ける方向へと野心を拡大しましたが、依然として Hadoop フレームワーク上の SQL を提供しています。他にもまだあります。

これは既存のリレーショナルデータベースプレーヤーを数十年にわたり駆り立ててきたのと同じダイナミクスです。誰もが標準の言語仕様を実装し、すべてのベンダーがパフォーマンスとサービス拡大の面で競い合います。市場には、それらの製品を押しつぶして単一の製品にすることができる数よりも、はるかに多くの数の既存の製品が存在しています。率直に言って、あまりに多額の資金が賭けられており、投資の共有を駆り立てるには至っていません。

とはいえ、良いニュースがあります。これらの SQL、JDBC、および ODBC のエンジンにデータを伝送するアプリケーションは移植可能であり、ユーザーにとって難しいものではありません。オープンソースが基本であり、我々は  Impala が勝利すると信じています。それでも、言語標準の存在により、自社製品と連携するサードパーティ製品による最高のエコシステムとの組み合わせの性能ならびに純粋な計算能力双方の観点での競争をせざるを得ないと我々は認識しています。この競争のダイナミクスは、弊社のお客様にとっても、また市場全体にとっても最善のものでしょう。

Pig と Hive はどこへ行くのか?

Yahoo! が作成したデータフロー型言語である Pig は、既存のベンダーとの競争がありません。その言語は強力ですが、そのユーザ基盤は代替となる実装を提供できる大手ベンダーの注目を集めるには小さすぎます。Pig クエリを実行するのに MapReduce よりも優れた方法は存在するでしょうが、しかし、それがサポートするワークロード (ほとんどは変換です) をもとにしたときに、そのことは重要ではありません。このソフトウェアは現行の形式で十分良好であり、Pig コミュニティはその機能を強化し続けています。

他方で、Hive は SQL であり、そして SQL は宇宙でもっとも使われているデータベース言語です。誰もがそのことを知っています。誰もが Hive が高速になることを期待しており、多くの企業が Hive をサポートしています。

したがって、Hive は確実に、熾烈な競争圧力の下に置かれることになります。より多くの大手ベンダーが市場に参入するに伴い、それは着実に悪化します。弊社は、Hiveの実装がハイパフォーマンスのインタラクティブなクエリおよびアナリティクスの需要についていけるとは考えません。どれだけ厳しく鞭打っても、馬はそれほど速くは進めません。ユーザーや、ツールやアプリケーションを提供するベンダーは、より良い製品へと移行することでしょう。

Hive はデータ処理ジョブをうまく取り扱います。また、その目的でのみ、Hiveは Cloudera の顧客基盤で広く使用されています。なにしろ、Hive は過去5年間、Cloudera の商用の製品の一部になってきたのですから。Hive はインストールすればそのまま使えるので、弊社は引き続き Hive をサポートします。特に、Impala との重複領域を、上述の Hive の Sentry および Parquet との統合の場にしようと考えているのです。

しかし、我々は、弊社のエンタープライズデータハブに最上級のリアルタイムオープンソース SQL エンジンをもっている必要があります。データ分析、リアルタイムクエリ、および、ハイパフォーマンス SQL アプリケーションに関する弊社の将来に向けての賭けは、間違いなく Impala にあります。もちろんひいき目はあるかもしれませんが、それでも弊社は、Impala はすでに、Hadoop エコシステムで利用可能な SQL 製品としてはまさに最高の製品になっていると確信しています。顧客や市場における他のプレーヤーが Impala を取り入れることは非常に喜ばしいことです。また、今後のいくつかのリリースで公開するであろうサービスや新機能を楽しみにしていてください。

 

関連記事

Cloudera データアナリスト向けトレーニング (Impala のトレーニングもあります)

Impala の無料電子書籍

Spark を活用する:ビッグデータアプリケーション用の高速インメモリコンピューティング


Contact us

製品やサービス、サポート、トレーニングについてのより詳しい情報は、下記までお問い合わせください。

Cloudera全般(日本語)
info-jp@cloudera.com
二ユースレター購読 (日本語)
Clouderaからの日本語での二ユースレター購読希望の方は
info-jp@cloudera.com
件名: ML_SUBSCRIBE
でメールをお送りください