1. Hypertable のことを初めて聞いた人のために簡単に説明をお願いしたい。
Hypertable はハイパフォーマンスでスケーラブルなオープンソースのデータベースで、Google の Bigtable をモデルに作られている。Google はこの数年間でスケーラブルなコンピューティングのための三つの重要なインフラを構築した。それらのインフラは、コモディティ PC で構成されているクラスタ上で動作するように設計されている。一つ目のインフラは、高い可用性をもち、グローバルな名前空間を提供してくれるファイルシステム Google File System（ GFS ） だ。GFS はマシン間（そしてラック間）でファイルデータを複製することによって、これまでのファイルシステムやストレージシステムでは達成されていなかった、どんな種類のハードウェア障害（電源供給やメモリやネットワークの問題など）にも影響されない高い可用性を実現している。二つ目のインフラは Map/Reduce と呼ばれる計算フレームワークだ。Map/Reduce は GFS と密接に連携して動作し、収集された膨大な量のデータを効率的に処理することを可能にする。三つ目のインフラが Bigtable と呼ばれているものだ。従来のデータベースに似ており、主キーを使って膨大な量のデータを整理し、それらを効率的に検索することができる。 Hypertable は Bigtable のオープンソース実装で、私たちが適切だと判断した部分に適宜改良を加えたものだ。
大きなトラフィックが見込まれる WEB サイトを運用するなら、スケーラブルなコンピューティングインフラの構築に気を配ったほうがよい。WEB サーバのログには、ユーザのサイト上での行動に関する重要な情報が含まれているし、そのログを解析して出てきた結果をよりよいサービスの提供に利用することができる。また、「商品 X を購入した顧客は他にどういう商品を買いそうか」「ページ Y を訪れたユーザは一回のセッションの間に平均何回くらいクリックするのか」といった情報なども手に入れることができる。
2. なぜこのプロジェクトを始めたのか？
Zvents のエンジニアリングチームがこのプロジェクトを始めたのは、データとデータ駆動エンジニアリングの価値を知っていたからだ。私たちは、情報の保存および処理に使われている従来のツールがスケールという点において適切に仕事をこなしてくれない、ということに気付いていた。プロジェクトを立ち上げたとき、オープンソースの Bigtable 実装は存在しなかったし、私たちはそれを自分たちの手で作り上げようと決心した。オープンソースを選んだのは、Bigtable のオープンソース実装が現れるのは必然の流れだと感じたからだ。
3. Hypertable を動かすのに Hadoop は必要か？
いや、Hypertable を動かすのに Hadoop が絶対に必要ということはない。Hypertable は、Hadoop が提供する HDFS のような、既存の分散ファイルシステム上で動作するように設計されている。裏側にあるファイルシステムとの間のインタフェースはブローカメカニズムを介して抽象化される。Hypertable は DFS のブローカプロセス用の標準プロトコルを使って裏側にあるファイルシステムと通信するので、ブローカさえ実装されていれば Hypertable はどんなファイルシステム上でも動かすことができる。私たちが使っている主な DFS ブローカは HDFS 用のものであるが、Kosmos ファイルシステム（ KFS ）用のブローカも使っているし、また「ローカルブローカ」と呼ばれるものがあり、ローカルにマウントされたファイルシステム上でデータの読み書きが行える。「ローカルブローカ」は私たちがテスト用に使っているものだが、これを使えば、FUSE を介してマウント可能なすべての分散ファイルシステム上で Hypertable を動かすこともできる。Hadoop 限定の話になるが、私たちは Hypertable のテーブルを Map/Reduce ジョブのインプットとして利用することのできる InputFormat 実装を書くつもりでいる。
4. Hypertable は HBase と比べてみてどうか？ なぜ HBase へのコントリビュートを選ばなかったのか？
Hypertable が HBase と異なる点は、Hypertable のほうがより高性能な Bigtable 実装であるということだ（英語版編集部注: 次週に HBase チームにもインタビューをする予定）。私は最初、Jim Kellerman 氏や Hadoop チームのほかのメンバーたちといっしょに HBase の開発作業を始めたのだが、その開発方針をめぐって意見の相違があった。実装言語の選択についての不一致が特に大きくて、私は C++ を推したのだが、彼らは Java の使用を強く主張していた。そんなこんなで、私は彼らと袂を分かち Hypertable プロジェクトを始めた。「Why We Chose C++ Over Java」という表題の下記ドキュメントに、私たちがなぜ Java ではなく C++ を選んだのか、その技術的な説明が書かれている。
http://code.google.com/p/hypertable/wiki/WhyWeChoseCppOverJava
初っ端から意見が分かれてしまったが、HBase チームとは今でも仲良くやっている。実際、先週などはみんなでランチに行って、お互いの実装の苦労話をしたりアイデアを交換したりして楽しい時間を過ごしている。
5.私はあまり詳しいわけではないが、Hadoop について自分で調べたところによると、Map/Reduce はデータのバッチ処理に非常に適しているとか。より多くのトランザクション要求や単独の要求にもとづくパラダイムに Hadoop を適用するにはどうすればよいか？
ご指摘のとおり、Map/Reduce はオフラインのバッチ処理システムだ。膨大な量の情報（ログなど）をオフラインでソートしたりフィルタリングしたりするのに優れている。これらの大規模なオフライン処理は、よりよいユーザエクスペリエンスを提供しようとしている運用中のサービスからの問い合わせに答えるため、情報を集めて大きなテーブルを作り出すことがよくある。この情報にはユーザごとのプロファイルや、クエリごとの統計データが含まれているかもしれない。そこで Hypertable の出番となる。Hypertable は、主キーによってインデックスされておりオンラインで検索することのできるデータを格納するために、スケーラブルなソリューションを提供してくれる。
6. Hadoop を使っていて気付いたもっともよい点は？
Hadoop は基本的に問題なく動作する。Zvents は Hadoop を使って成功しているし、他にも多くの人たちがオフライン製品の周辺環境に Hadoop を使っている。Yahoo は最近 WebMap の処理を Hadoop に移行した。彼らは自分たちが達成した最近の成果について下記のプレスリリースで述べている。
http://developer.yahoo.com/blogs/hadoop/2008/02/yahoo-worlds-largest-production-hadoop.html
7. では、もっともよくない点は？
Hadoop を利用する上でもっともよくない点は、おそらく、安定した 1.0 がリリースされないまま何年も過ぎてしまっていることだ。ときどき安定リリースを出そうとしてはいるし、プロジェクトは最近かなり安定してきたが。 Hadoop のもうひとつの問題は、分散ファイルシステムにおける同期処理のサポートが欠けていることだ。そのせいで Hadoop はコミットログの保存に適さない。この問題を解決するために彼らは活発に作業をしているし、私たちが Hypertable 1.0 をリリースする時までにはサポートされるはずだ。
8. バージョン 1.0 はいつごろのリリースを予定しているのか？
ベータリリースは来月か再来月ごろを目指している。1.0 はそのあとに続いてすぐにリリースされるはずだ。もしベータ版と 1.0 のリリースについて通知を受けたいなら、下記の Hypertable アナウンスメーリングリストに登録してほしい。http://groups.google.com/group/hypertable-announce
9. どのような企業が Hypertable を利用しているか？
まだアルファ版であるし、サービスを Hypertable 上に構築している企業は今のところない。しかし、かなり興味は寄せられており、ソフトウェアのダウンロード回数も 3,000 回を超えた。メーリングリストでは幅広いさまざまな人たちからの素晴らしいフィードバックも受け取っている。ネブラスカ州オマハ郊外の会社で働いているある人物からは退行不具合の報告を受けた。メーリングリスト上での何度かのやりとりのあと、彼は自分のマシンをファイアウォールの外側に置いて、私が VNC でアクセスしてデバッグできるようにしてくれた。おかげで私は問題を切り分けることができた。PST タイムゾーンの外でソフトウェアを実行したことによるタイムスタンプ変換の問題だった。そのほかには、ニューヨークにある Stony Brook University で学んでいる博士課程の学生が、Google Bigtable のベンチマークテストを Hypertable を使って期待できる結果を得られるように作り直してくれた。コミュニティによるこういったフィードバックはソフトウェアを安定させるのに大いに役立っている。先週、Facebook で 30 人ほどのエンジニアからなるグループに向けて Hypertable のプレゼンを行った。彼らはバックエンドで使われるツールのひとつとしてこういうインフラを必要としており、Hypertable の品質が製品利用できるレベルに近づいたら 2 ～ 3 ヶ月間試してみてもよいようなことを言っていた。1.0 がリリースされるころには Hypertable 上に構築された実運用アプリケーションが現れることを期待している。
10. Hypertable の今後について教えてほしい。
短期的な話をすると、高可用性にしっかりとフォーカスを当てていくつもりでいる。特にサーバのリカバリが重要だ。それが整い、十分にテストされたら、プロジェクトのステータスは「ベータ」に移行する。そのすぐあとには 1.0 のリリースがある。私たちは多くの WEB サービスアプリケーションで Hypertable が MySQL に取って代わることを期待しており、LAMP を LAHP に置き換えようと作業をしている。「 H 」はもちろん Hypertable の「 H 」だ。そのためには磐石な信頼性と継続的なパフォーマンス向上が必要だし、当面、チームは忙しい状態が続くだろう。
Doug 氏は 4 月 23 日、パロアルトで開かれる SDForum の Software Architecture & Modeling SIG において Hypertable のプレゼン(source)を行った。
原文はこちらです：http://www.infoq.com/news/2008/04/hypertable-interview