DWH/RDBMSとHadoopの特徴比較

RDMSとの相違点を知る

連載の最終回となる本稿では、DWH(RDBMS)と新しいテクノロジーでもあるHadoopとの特徴について比較解説することにしたい。

まずお伝えしたいのは、時代が進み、よりデータを活用したいビジネス上のニーズが出現し、データがビッグデータ化した。そのデータを活用するデータ基盤がRDBであり、Hadoopであるという点だ。

RDBは秀逸なテクノロジーであり、実際何十年にもわたりトランザクショナルな処理からアナリティカルな目的にまで利用されてきた。しかし、前述のようにビッグデータの時代となって分析やデータ活用にはRDBだけで対処するには難しい「新しい」要望がデータ基盤に求められるようになり、それに合わせた新テクノロジーが登場してきた。

それがHadoopである。ゆえに、ここで比較している特徴はどちらが良い悪いではなく、適材適所だということをご理解いただきたい。

いくつかのクライテリアがあるが、主なものを挙げると以下となる。

• コスト
• データの移動の必要性
• データの種類
• スキーマ定義

利用する側で一番注目するのは、データ量あたりのコストだろう。「ビッグデータ」というキーワードから一番容易に浮かぶポイントでもある。

DWHはもともと基幹系のシステム用に作られているため、基幹システムを支える機能も豊富に含まれ、かつ基幹データは決して多くはない。よって高価であるのに対し、大量のデータを使って利用することをそもそもの目的としているHadoopの場合はデータ容量当たりのコストは圧倒的に安くなる。1テラバイト当たりのコストは、DWHが40,000ドルなのに対し、Hadoopではわずか1,000ドル未満と、40倍以上もの開きがあるとのことだ(ウォール・ストリート・ジャーナルがレポートを出しているので、参照されたい)。

次に、ビッグデータで注目するべきポイントであるデータの移動についても理解する必要がある。

従来型は前回に述べた通り、例えばNASストレージにログをためてDWHに移動して活用といったデータの移動が伴っていたが、Hadoopはデータのあるところでデータを処理するので移動は不要となる。TBやPBクラスになるとデータの移動はコストが高すぎるため、できるだけ移動させないことが重要だ。

もちろん、処理できるデータの種類は、DWHでは構造化データのみとなるが、Hadoopではあらゆるデータを処理することが可能となっている。昨今注目のディープラーニングなど画像を活用したソリューションも新しいデータ基盤の方が適しているだろう。

そして、もう1つ重要なポイントがスキーマについてである。

RDBはスキーマを作ってデータを入れる、つまりデータの使い方はあまり変化しないことが前提だが、分析は試行錯誤しながら進めるため、事前のスキーマ定義は難しい。Hadoopであればデータをとりあえず入れて、後から目的に合わせスキーマを定義することができる。

その他、実際の運用上重要となる既存のスキルや資産をどう新しい仕組みに使うかにも言及しておこう。

RDBと言えば、SQLでのアクセスだが、Hadoopもここに来てSQLアクセスのニーズを受けて進化しており、いくつものSQLエンジンがHadoopにも揃うようになった。この進化は大きな意味があり、従来の技術やスキルと新テクノロジーを橋渡しする役も担い、採用への敷居を下げている。

並列分散へのシフトが加速するソリューションベンダー

Hadoop上のSQLソリューションもさまざまなものが提供されているが、多くの企業ではニーズに応じていくつかのソリューションを使い分けている(以下参照)。

ここで、ある企業のマーケティング部門でのMapRの活用例を簡単に紹介したい。

同部門では、30億レコード(容量としては数十GB)のPOSデータを利用した集計処理をしたかった。しかし、容量よりもそのレコード数ゆえに既存の汎用RDBMSでは、CPUを増やし、SSDを採用しても、集計処理がタイムアウトしてしまい、活用できない状態に陥っていた。

そこで取り入れたのが新しいデータ基盤であるMapRである。7台のサーバによる並列処理で、お客様の要望の1分以内に集計処理を終えるという目標を容易に達成することができたのである。

集計処理や検索はRDBMS同様に行え、かつそれが並列分散で行われる上、同部門はRDBMSよりも多い量のデータを安価に処理できるようになった。今後データ量の桁が増えても、パフォーマンス要件が上がっても、スケールアウトさせることで、対応もできる。これは従来のRDBMSに固執しなかったからこそ実現したケースだと言えるだろう。

また、SAP HANAやHewlett Packard Enterprise VerticaとMapR (Hadoop)との組み合わせも注目に値する。

HANAやVerticaといったスケールアウト型のDWHの泣き所は、x86サーバの内蔵ストレージを使うため、そのストレージの管理にある。MapR (Hadoop)はファイルシステムであり、データ圧縮やバックアップ、スナップショットといった一般的なストレージの機能を持つため、この泣き所を解消できる。

さらに、SAPはHANAとHadoopにあるデータを透過的に検索するために「Vora」という製品を出した。これはSpark上で動くのだが、SparkはHadoopから提供されるので、より親和性が上がるのである。

このような特性から、DWHベンダーやSASといったアドバンスド分析の老舗ベンダーなども、今や次々とHadoopへとシフトしていっている。これはつまり、ビッグデータ化によってディスク領域もCPUもスケールさせる必要があるため、スケールアウト型の並列分散へとシフトしているということを意味する。

ビジネスニーズが変わり、単なるBIレポートだけではなく、機械学習やデータマイニングを利用した顧客動向分析や傾向分析、さらにはディープラーニングとデータ活用が進むと、それに伴う量や、種類、数という点でもデータが変わる。

ディープラーニングなどはわかりやすい例で、画像を活用する。そうなると、必然的にデータ基盤が変わるのである。ビッグデータ時代とはそういったビジネスニーズの変化があり、それを満たすのに必要になるHadoopという新データ基盤が登場したのである。

しかし、Hadoopは基本バッチ処理である。市場のニーズはバッチ型にとどまらずにリアルタイム化していく。そこで登場してきたのが、MapReduceに代わると言っては言い過ぎかもしれないが、新しいデータ処理フレームワークであるSparkだ。

Hadoopの解説の次は、よりリアルタイムに処理ができる、今話題の新フレームワーク「Spark」について新たにご紹介していく。