GoogleとHadoopとEzmeral（エズメラル）

[Masazumi_Koga]

MapRと機械学習の書籍「Hadoopクラスター構築実践ガイド」の著者がビッグデータを語るシリーズ。前回は、ビッグデータの「3V（スリーブイ）」をご紹介しました。今回は、このビッグデータの3Vに真剣に立ち向かった企業の取り組みの歴史ついてご紹介します。さらに、その企業の取り組みを元にして生まれたビッグデータ分析基盤フレームワークのHadoopの誕生過程と、そこから発展したEzmeral Data Fabric（MapR）の関係も併せてご紹介します。

■検索エンジンの課題は、まさにビッグデータの3V

「インターネットに公開されている全てのデータ整理し、カタログ化する」

そんなこと、実現できるわけがないと思われるかもしれません。しかし、インターネットに散らばるデータの量、保存方法、データ形式などの要素を踏まえ、気が遠くなるレベルの量のビッグデータの取り扱いに真剣に悩み、そして、完全克服した巨大企業があります。それは、Google社です。

Google社は、これらのビッグデータの諸問題を解決すべく、さまざまな技術の検討を行いましたが、ビッグデータの3Vが自社にとって大きな壁になりました。

1990年代当時は、一般に、巨大なリレーショナルデータベース（通称、RDBMS、または、単にRDB）にデータを集約する方式が普通でした。RDBMSによるアプローチは、企業に蓄積した履歴データなどを使用し、将来の事業計画を立案するといった処理も行われていました。また、ログ解析、購買分析、傾向分析といったデータ分析業務にもRDBMSは、一定の役割を果たしました。RDBMSに保存されるデータは、一般に、表形式で表される「構造化データ」です。身近なものだと、エクセルの表で表される数値データが構造化データの代表例です。

しかし、彼らが主に取り扱うデータは、Webページの文章、SNSのメッセージ、画像、動画など、表形式で表せないような、「非構造化データ」なのです。当初、多くの企業は、これらの新しいデータをRDBMSを応用したデータウェアハウス（通称、DWH）に組み込むことを試みました。ところが、すぐに性能が頭打ちになることが判明しました。従来のデータウェアハウスを処理するように設計されたソフトウェアでは、これらの新しい非構造化データには向いておらず、あまりにも多いデータ容量に対して、性能面や価格で対応しきれなくなったのです。

そこでGoogle社は、従来のリレーショナルデータベースでは、ビッグデータを取り扱うことはもはや不可能であるという結論に達し、新しい仕組みをゼロから作ることにしたのです。

Google社の検索エンジンは、1996年に19番目に登場しました。当時、海外では、検索エンジンの会社がすでに乱立していて、Google社に限らず、多くの会社は、検索エンジンの市場で優位に立つために、インターネット全体のカタログを作成したいと考えていました。これを成功させるためには、ビッグデータの3Vが提示する課題に、今までにない革新的な方法で対処する必要がありました。

■ビッグデータの3Vにおけるボリューム（Volume）

ここで話題にしているデータは、想像を絶する量です。Webページの単語は、日を追うごとに大量に発生します。そのような増え続けるインターネット全体のすべてのWebページのすべての単語をカタログ化するのです。これは、一般的なリレーショナルデータベースでは到底処理しきれない膨大な量のデータです。

■インターネットの全データの生成速度に対応する必要がある

以前にご紹介したビッグデータの3Vでの検討事項にあるように、データが収集される速度を検討する必要があります。インターネット全体で数十億のWebページがあり、毎日何百万、何千万もの更新が行われます。大量に毎日生成されるWebページのすべての単語が処理対象になるのです。このレベルのコンテンツの更新に対応するには、驚異的な速度でデータを取り込み、処理する機能が必要です。

■気の遠くなる種類のデータの多様性に対応

さらに、収集されているデータには、様々な種類があります。一般的なリレーショナルデータベースでは、特定の方法で編成された特定の種類のデータを期待します。そのため、画像データ、音声データ、映像コンテンツは、リレーショナルデータベースでカタログ化することはできません。WebサイトにそれらのWebコンテンツが整理されて保管されているとしても、あるWebサイトのデータが別のサイトとどのように比較されるかを知る方法はありません。

多種多様なWebサイトの様々な種類のデータを取り扱うことは、容易なことではなく、当然、従来のリレーショナルデータベースにうまく保存する術はありません。

■解決策は、新しい仕組みづくり

インターネット全体で生成されるビッグデータの取り扱いは、その量や種類からして、非常に厄介です。では、このデータ量や種類の問題をどのように解決したのでしょうか？

彼らは、まず、自社が置かれた状況を把握し、なにが問題なのかを明確にすることが始めています。当たり前かもしれませんが、自身のビッグデータの問題をきちんと説明して具体的に明記するのです。そして、彼らは、ビッグデータの3Vのどれが自社の状況に当てはまるかを考えました。データの記述、保存、または処理を困難にする原因は何で、どのような機能が必要なのかを徹底的に検討したのです。

そして、今までの仕組みでは、不可能という判断が下され、結論は、「あたらしい仕組みづくり」でした。その新しい仕組みとは、スケールアウトが可能なGoogleファイルシステム（GFS）、Bigtable（ビッグテーブル）、MapReduce（マップリデュース）の3つのコンポーネントで自社のビッグデータの問題に取り組むことでした。

GFS、Bigtable、およびMapReduceは、相互接続された安価なコンピューターの集合体（クラスターという）で複数のコンピューターが連係して機能します。今までの旧式のビッグデータソリューションでは、高価なスケールアップ型のハードウェアが必要であったため、このクラスターのアーキテクチャは、非常に革新的でした。

そして、彼らは、スケールアップ型の特殊なマシンに多額の費用をかけるのではなく、故障したときに簡単に交換できるコモディティハードウェアで構成されたビッグデータコンピューティング用のクラスター基盤を設計しました。

ちなみに、インターネット全体のあらゆるデータを整理し、検索できるためのデータ基盤をコモディティハードウェアの巨大クラスターで構成するという方針は、彼らのあらゆるクラウドサービスに広がり、現在でもその方針は貫かれています。

では、ビッグデータの3Vに対処すべく開発したGFS、Bigtable、MapReduceとはどのようなものなのか、ざっくり解説します。

■Hadoop HDFSの元となったGFS

GFSにおいて、ファイルは、チャンクとよばれる細切れになった小さいデータに分割されて保存されます。このチャンクは、GFSを形成するクラスター内のさまざまなノードに分散配置されます。チャンクは、異なるノードに複製されて配置されるため、ノード障害が発生し、そのチャンクが読み取り不可になったとしても、別のノードに正常なチャンクが存在するため、チャンクの元となるデータは保護されます。この設計思想は、オープンソースのApache Hadoopの分散ファイルシステムである「Hadoop Distributed File System（HDFS）」にも引き継がれているアーキテクチャーです。

■Bigtable

Bigtableは、GFSを使用してデータを保存および取得するためのデータベース管理システムです。Bigtableにおける「行」は、サブテーブルに分割され、クラスター全体に分散されるといった仕組みが備わっています。また、「列」からの高速な読み込みが得意であるため、列指向データベースに位置付けられています。当然のことながら、Bigtableは、膨大な量のデータを処理するように設計されており、クラスターに新しいノードを追加し、処理性能をスケールできます。

■MapReduce

彼らは、並列処理の仕組みであるMapReduceを利用して、GFSに保存されたデータを処理しました。MapReduceという名前は、2つのステップのmap処理とreduce処理の名前から取られています。

MapReduceプロセスは、Apache Hadoopによって有名になりましたが、実は、それほど新しいアイデアではありません。あまり知られていませんが、mapとreduceという名前は、1970年代の関数型プログラミング言語であるLisp（リスプ）で使用されていたものなのです。意外に歴史が古いということもあり、一般的な集計処理では、MapReduceのアルゴリズム（計算手順）が組み込まれている場合が少なくありません。

上図は、LispがMapReduceをどのように使用するかを示した例です。まず、1, 2, 3, 4 の入力リストがあるとします。この入力リストに対して、二乗を求めるsquare関数であるmap処理を適用します。すると、square関数によって、各入力の値は、1つの出力（この場合は1, 4, 9, 16）を生成します。map処理の結果に対して、reduce処理を行います。具体的には、加算関数により、リスト（1,4,9,16）を足すことで、合計値である「30」という単一の出力を生成します。これが、MapReduce処理です。この例では、計算処理ですが、単語の数を数えて、出現頻度の高い単語を出力するといった処理でも、MapReduceが利用できます。

そして、Google社は、MapReduceの仕組みを活用して、検索エンジン市場を支配しました。彼らは、わずか数年で競合他社に対して圧倒的な優位性を確立し、そして、今日に至っています。Google社は、さまざまな方法でMapReduceやそれを応用した処理の仕組みを駆使して、Web検索エクスペリエンスを向上させました。特に、Webページのコンテンツのインデックス作成を支援するために積極的に使用され、Webページの重要度を決めるための処理手順である「PageRankアルゴリズム」の処理エンジンとして利用され、検索結果におけるWebページの表示位置を決定するためにも使用されました。

上図は、Google社がWebページで単語カウントを実行するために使用したMapReduceアルゴリズムです。少し中身を見てみると、mapメソッドは、「キーと値の組み合わせ」を入力として受け取ります。ここで、キーは、ドキュメントの名前を表し、値は、ドキュメントに含まれるコンテンツです。MapReduceのmapメソッドは、ドキュメント内の各単語を読み込み、「単語」と「1」の組み合わせを出力します。その後、MapReduceのreduceメソッドは、入力として、先程のキーと値のリストを受け取ります。ここで、キーは単語を表します。値のリストは、その単語のカウントのリストです。この例では、値は1です。

そして、単語のカウントをループ処理で行い、単語の出現頻度を合計します。ループが完了すると、reduceメソッドは、単語 とその総数が出力されるといった具合です。このMapとReduceの処理を1つのコンピューターで行うのではなく、大量のコンピューターで行う、いわゆる分散型で処理することで、膨大な単語のカウント処理を高速に行うことが可能になったわけです。

以上のGoogle社のビッグデータへの取り組みをまとめると、こんな感じです。

• Bigtableを使用して、データを列と行に整理した
• GFSの分散ファイルシステムに全てのデータを保存した
• MapReduce対応のプログラムを開発し、チャンクに分割されたGFS上のデータを高速に処理した
• 最終的に、インターネット上のあらゆる形式のデータをカタログ化できた

■Hadoopの誕生

その後、数年の間に、Google社は、ビッグデータソリューションの一部を説明する論文を発表しました。そして、当時、Yahoo!に所属していたダグ‧カッティング氏は、Google File SystemとMapReduceの仕組みを実現させるための開発プロジェクトをスタートさせました。このプロジェクトは、後にカッティング氏の息子が持っていた黄色い象のぬいぐるみにちなんで名付けられたHadoop（ハドゥープ）と呼ばれるApache Foundationプロジェクトになりました。そして、Googleの論文に基づいて作られたHadoopは、オープンソースソフトウェアとして公開されました。

Apache Hadoopは、Google File System、BigTable、MapReduceのコンポーネントと同様に、コモディティハードウェアノードで機能する3つのコンポーネントで構成されています。

Hadoopの最下層は、HDFS（Hadoop Distributed File System）、つまりHadoop分散ファイルシステムです。HDFSは、ファイルをGFSと同様のチャンクサイズに分割し、クラスターのノード全体に分散します。Google  Bigtableと同様に、データはHBaseと呼ばれるアプリケーションを使用してHDFSに表形式で保存できます。

Hadoopも、Google File Systemが稼働するアーキテクチャーと同様に、内部ストレージを備えた普通のx86サーバーを並べたクラスターにインストールし、非常に大規模なデータに対して、並列処理による分析が可能です。

Hadoopはまた、MapReduceを利用してHDFSに保存されているデータを処理します。Hadoopに内包されている並列処理の仕組みとしては、現在も多くの欧米の企業で利用されています。この革新的なMapReduceが動くHadoopは、従来のデータウェアハウス（DWH）やデータ統合ソフトウェアと比較して、非常に大量のデータを収集し、かつ、整理する処理において、大幅なコスト削減を実現したのも確かです。

しかし、その後、HDFSには、かなり制約があることがわかりました。一つは、従来のRDBMSが提供するような非常に柔軟なデータ管理・操作の仕組みが弱かったことが挙げられます。また、HDFS上でデータを取り扱うには、HDFSに関する高度なスキルが必要とされました。また、MapReduceを使った並列処理の手法は、データの一部（サブセット）を選択して処理するといった場合には、非効率であることもわかりました。そのため、これらの諸問題に対処するために、様々なオープンソースのプロジェクトが生まれ、Hadoopベースの環境に商用サポートの付加価値を提供するベンダーがいくつか登場しました。その商用サポートを提供するベンダーの一つが、MapR社（現、HPE）だったのです。

MapR社（現、HPE）は、Hadoopの概念をさらに進化させ、HDFSやHBaseよりも圧倒的に高速で安定したコンポーネントを作成しました。Javaで作られたHadoop分散ファイルシステム（HDFS）をC/C++で書き換えたことにより、Hadoop互換でありながら、超高速ファイルシステムを持つ「MapR Data Platform、通称、MapR」（現、Ezmeral Data Fabric）が生まれました。

Ezmeral Data Fabricは、上記で紹介したGoogleの分散ファイルシステム、BigTableやHadoop Hbaseと呼ばれる列指向型のNoSQLデータベース、そして、HBaseよりも圧倒的に高速な列指向型のNoSQLデータベースであるMapR-DB（現、Ezmeral Data Fabric Database）を実行できます。また、HadoopのMapReduce機能や、Hadoop上で動くエコシステムソフトウェアに関連するすべてのアプリケーションと完全に互換性があります。

さらに、Ezmeral Data Fabricは、ビジネスの厳格な基準に合わせて設計されており、Hadoopよりも高速、かつ、信頼性の高いエンタープライズ対応のデータプラットフォームソフトウェアです。GoogleのGFSやYahoo!のHadoopの取り組みを経て、今、Ezmeral Data Fabricは、BMW、メルセデスベンツ、アウディ、インドのマイナンバー基盤といった非常に大規模なデータ基盤に導入されています。また、日本でも、金融、製造、医療、通信、研究所など、100社を超えるお客様に導入され、高速分析が可能なNASとして利用されています。

インターネット全体のデータをカタログ化したいという夢からはじまり、黄色い象のHadoopを経て、Ezmeral Data Fabricは、今、日本の企業のデータ基盤に不可欠な存在になっています。

Hadoopで性能を稼ぐためには、8台～10台以上必要という意見がありますが、一方、Ezmeral Data Fabricは、非常に高速なMapRファイルシステムを持つことから、サーバー4台でスモールスタート始められ、Webブラウザ経由で、簡単にインストールできます。

たとえスモールデータであっても、競合に勝ち抜くためには、データ主導型の事業推進が不可欠です。是非、データ主導型のDXの切り札として、Ezmeral Data Fabricを検討してみてはいかがでしょうか。

Masazumi Koga (Twitter:  @masazumi_koga)

【書籍のご案内】HadoopとMapRと機械学習を学べる本

MapRは、Hadoop互換でありながら、Hadoop HDFS（Hadoop分散ファイルシステム）よりも圧倒的に高速なMapRファイルシステムを搭載しています。その非常に高いI/O性能に加え、高可用性NFSサービスを提供する単純なNASとしても利用できます。それらの使い勝手の良さから、大手自動車会社の自動運転車のAI開発基盤や、インド政府のマイナンバーシステムで採用されているデータ基盤ソフトであり、日本国内でも100社以上の導入実績を誇ります。本書では、その豊富な導入実績をもとに、頻繁に利用されている基礎技術を「Hadoopクラスター構築実践ガイド」に収録しています。主に、以下に挙げるMapRとその上で動くオープンソースソフトウェアのノウハウを学べます。
●Hadoop v3とMapR v6の構築手順
●運用管理手法
●Spark：SQL、Streaming、GraphX、R、MLlibの使用法
●ニューラルネットワークによる学習
●データベース操作（Hive、Impala、HBase、MapR-DB、Pig）
●データのインポートとエクスポート（Sqoop、Flume）
フライトデータ分析、植物の分類、おすすめ映画のタイトル表示、Wikipediaドキュメント分類といった具体例をもとに、ステップバイステップで学べる一冊です。