Hadoopの概要とSQLの使用

Hadoopは、大量のデータを保管・処理するオープンソースのフレームワークとして、2000年代初頭にリリースされました。Hadoopはコモディティハードウェア上での並列処理により、大規模なマシン群で分散処理を行います。

一般にHadoopのジョブはJavaで記述されていますが、その複雑さから、SQLの記述を好むアナリストも多くいます。このため、SQLを記述してHadoopのクラスタ上で実行させるいくつかの処理エンジンが開発されています。

Hadoopの核となる強みは、そのモジュラー設計にあります。従来のリレーショナルデータベース管理システム(RDBMS)やMPPデータウェアハウスではファイルストレージ、処理エンジン、データ管理システムが1つのプラットフォームに統合されていますが、Hadoopではこれらのコンポーネントがそれぞれ独立して動作します。Hadoopは巨大なソフトウェアカテゴリーであり、そのエコシステムは数十ものソフトウェアベンダーやサポート/サービスプロバイダー、アプリケーションで構成されています。

他の多くの分析データウェアハウスとは異なり、Hadoopのソフトウェアはコモディティハードウェア上で動作する設計になっています。つまり、ソフトウェアアーキテクチャ全体がハードウェアから独立して個別に動作します。

こうしたHadoopの2つの特色を活用すれば、経験豊富なデータベース管理者やDevOpsチームは段階的にデータスタックのすべてをカスタマイズすることができます。すでにHadoopのクラスタを運用されている場合は、ベンダーごとの利点や短所について知っておくことが重要になります。

HadoopでSQLを使うメリット

コスト効率の良さと柔軟性

Hadoopの大きな強みの一つとして、オープンソースであること、そしてコモディティハードウェア、あるいはどのソフトウェアプロバイダーにも縛られない一般のハードウェアで実行できる点が挙げられます。

Hadoopクラスタへのマシンの追加も低コストに抑えられるので、組織にとっては大きなメリットとなります。また、様々なHadoop技術を試して、いつでもプロセスを最適化できるのも魅力です。その間、ハードウェアスタック全体を交換する必要はありません。

たとえば、Hadoopクラスタをデータウェアハウスとして使用するプロビジョニングに関心がある場合は、まずHiveなどのSQLエンジンを追加し、SQLでデータにクエリを実行します。その後、ハードウェアはそのままで、Hiveの代わりにPrestoやSparkなど別のSQLエンジンを使用することも可能です。Hadoopベースのシステムは相互運用性があり、他のオンプレミス型データウェアハウスベンダーと比較して柔軟性が非常に優れています。

アジリティ

Hadoopではデータを格納する際にスキーマを宣言する必要がありません。Hadoop分散ファイルシステム(HDFS)は、膨大な量の非構造化データを保存し、データを分析したいときだけスキーマを宣言する、費用効果に優れたシステムです。このため、クラスタにデータを書き込む際に、制限される可能性があるスキーマを前もって宣言する必要がなくなります。

Hadoopのインフラストラクチャは、SQLだけでなくさまざまなプログラミング言語に対応しており、機械学習の分析や、1つのクラスタで複数のプログラミング言語を並列処理することに関心のある多くの開発者に支持されています。

SQLエンジンが開発される前は、Hadoopで実行するコードを記述するためには専門知識が必要でしたが、HadoopのSQLエンジンが開発されたことで、Hadoopクラスタに対してANSI準拠のSQLを実行できるようになりました。ビジネスユーザーはこれらの技術を活用して、あらゆるSQLベースのレポーティングツールをHadoopクラスタに接続することができます。

信頼性とパフォーマンス

Hadoop、特にHadoop分散ファイルシステム(HDFS)は一般に企業のデータスタック内に実装されますが、これには主に2つの理由があります。1つは、HDFSが耐障害性にとても優れていること(クラスタ内のマシンで障害が発生してもデータにアクセス可能)、そしてもう1つはHadoopのMapReduceフレームワークにより極めて大量のデータを処理できることです。

Hadoopエンジンで使用される一般的なSQL

Hadoopのアーキテクチャ

「(西部開拓時代に)数頭の牛に重い荷物を引かせていた頃、一頭では丸太を動かせなくても、彼らはもっと大きな牛を育てようとはしませんでした。私たちも、大きなコンピュータを作るのではなく、大きなコンピュータシステムを作るべきなのです。」 - Grace Hopper

Hadoopの開発者が考案したいくつかのコンセプトは、以来、ビッグデータ分野のイノベーションの促進力となっています。

水平方向のスケーリング

Hadoopは各ノードを個別に拡張するのではなく、同じサイズのマシンをデータベースシステムに追加する水平方向の直線的なスケーリングを行う設計になっています。

この原理を利用することにより、ユーザーはHadoopクラスタを効率的かつ簡単にスケーリングでき、Hadoopクラスタをスケールアウトしてもその性能を維持することができます。

データ移動なし

Hadoopは当初、未加工データをRDBMSへ送る前に格納しておく非構造化データのデータレイクとして開発されました。Javaを記述できる開発者にとっては、リレーショナルデータベースに移される前の非構造化データにアクセスし、直接分析することができるため、これは非常に便利でした。けれどもビジネスユーザーは、これらのデータのクリーニングが完了してリレーショナルデータベースに送られるまで待たなければならず、さらにそのデータを使用する前にSQLを用いてアクセスする必要がありました。

その後、Hadoopの強力なSQLエンジンが開発されたことにより、アナリストやビジネスユーザーはデータの移動を待たずにクラスタから直接アクセスできるようになりました。よりリアルタイムに近い分析が可能になり、さらにアナリスト専用のデータウェアハウスが不要なため、企業のデータアーキテクチャを簡素化することができます。

スキーマオンリード

データを直接データベースに書き込めるようになる前の旧システムでは、データベース内のデータ構造を指定するスキーマを宣言する必要がありました。スキーマの作成は、データベースにデータを正しく書き込むために必要なETL(抽出、変換、ロード)処理において重要な要素でした。

このプロセスはスキーマオンライトと呼ばれ、かつてはこれがデータベースにデータを書き込む唯一の方法でした。スキーマオンライトフレームワークのメリットとしては、データベース内のデータがロバストである(書き込まれるすべてのデータがアナリストにとって有用であることが分かっている)、一貫性がある(全データが同じ構造)、クリーンである(エンドユーザーがアクセスできる)ことが挙げられます。

しかし、スキーマオンライトにはいくつかの重大な欠点があります。ETL処理の管理者はデータが書き込まれる前にそのデータがどのように使われ、分析されるかを把握しておく必要があるため、たいていは利用できるデータセットが限られます。そのデータについて明確なユースケースがない場合は、データが破棄されたり、収集されない可能性があり、履歴データの分析ができなくなります。

Hadoopをはじめとする最新のデータレイクではこの仕組みが大きく変わり、データベースでのデータの扱い方を細かく宣言するのではなく、外部ソースのデータをデータレイクに書き込み、そのデータを読み込む時だけ変換するようになっています。この新しいフレームワークは、分析するデータをデータベースから読み込む時にアナリストがスキーマを定義することから、「スキーマオンリード」と呼ばれています。

このスキーマオンリードのフレームワークでは、分析するデータのスキーマを宣言する前にデータ内容を理解しておかなければならないため、アナリストがより積極的に関与する必要がありますが、一方で分析の幅や柔軟性が広がるほか、すぐにスキーマを指定できないからという理由でデータが除外されることもなくなります。さらに、アナリストは実行する分析のタイプに応じて最も意味のあるスキーマを自在に指定することができます。つまり、分析内容をスキーマに合わせるのではなく、スキーマを分析内容に合わせられるのです。

Hadoopアーキテクチャの3つの主要コンポーネント

Hadoopのアーキテクチャはすぐに複雑化しがちですが、最新のHadoopのデプロイは次の3つのコアコンポーネントで構成されています:

  • Hadoop分散ファイルシステム(ストレージ)
  • MapReduce(処理)
  • Apache Hadoop YARN(リソース配分)

Hadoop分散ファイルシステム(HDFS)

HDFS開発のきっかけとなった最も大きな課題の一つが、パフォーマンスを維持したまま、膨大な量のデータを格納するためにストレージを拡張することでした。

HDFSへのデータのロード

HDFSは、多数の個別のマシンにデータを分散し、データをすぐに取り出して処理できるようインデックス化するソリューションとして開発されました。

HDFSにロードされた様々なデータフォーマットの未加工データは、まずブロックと呼ばれる小さなファイルに分割されます。ブロックは、データノードという個別のストレージマシン上にあるクラスタに均等に分散されます。次に、各ブロックの場所はNameNodeという特殊なノードに割り当てられます。NameNodeはクラスタ全体でブロックの場所をインデックスに追加すると同時に、これらのデータノードへのアクセスを管理します。

3回ずつ複製

HDFSは各ブロックをそれぞれ3回複製し、そのコピーを別々のデータノードに格納します。この複製パターンにより、一台のマシンで障害(大規模な障害となる可能性が高い)が発生しても、クラスタ全体では引き続きデータを使用することができるため、HDFSの耐障害性は極めて高くなります。また、一つのコピーが失われても、HDFSがクラスタ内にある他のコピーを使って自動的に複製を行うため、常にデータの高可用性が保証されます。

MapReduce

MapReduceは、HDFS内の多数のノードに分散されたデータを処理するためのフレームワークです。MapReduceはその名前からも分かるように、次の2つのフェーズで構成されます:

  • Map(マップ)フェーズ - HDFSに格納された各ブロックファイルで処理を実行
  • Reduce(集約)フェーズ - 結果を統合

MapReduce実行前のデータの準備

MapReduceを実行する前に、MapReduceの両フェーズで必要となるデータを特定し、処理の準備を行う必要があります。MapReduceのタスクを実行すると、HDFS全体のブロックに格納されているデータの場所を確認し、そのフォーマットを判定します。MapReduceでは、このようにしてHDFSに格納されている多様なファイルフォーマットのデータを処理します。

1つのファイルのデータが複数のブロックに分散されているため、InputSplitという別の関数を呼び出し、データをさらに小さい定義済みのまとまりに分割して処理します。InputSplitはデータを含まず、その代わりにバイトオフセットを使用します。MapReduceは、これに基づいてファイルを分割する論理パターンを決定します。

Mapフェーズ

入力データを特定して準備が整うと、Mapフェーズに移ります。Mapフェーズでは、Hadoopクラスタの各ノードですべての入力データを一度に処理し、これがマップとなります。次に、すべてのマップを並べ替えたり、適切なノードに配置したりしてシャッフルし、Reduceフェーズに進みます。

Reduceフェーズ

データがそれぞれ正しいノードに分割されると、Reduceフェーズが実行されます。Mapフェーズで得られた個別の結果をすべて一つの出力データにまとめます。このフェーズは基本的に、データのすべての結果を一つの回答にまとめる集計作業になります。

MapReduce処理の例

例として、Hadoopに関するこの記事をファイルとしてHDFSに読み込み、MapReduceタスクを実行して、「Hadoop」という用語が記事中で何回使用されているか調べるとします。まずファイルをHDFSに読み込み、別々のブロックファイルに分割します。このブロックをさらに別々のInputSplitに分割します。この時、記事中の単語が途中で切れないようにします(「Hadoop」のインスタンスが「Ha」と「doop」として2つのブロックファイルに分割された場合、そのインスタンスは計上されません)。

InputSplitの処理が完了すると、クラスタの各ノードにそれぞれInputSplitが割り当てられ、そのInputSplit内で「Hadoop」のインスタンスの数を個別にカウントします。このそれぞれのMapフェーズの結果がカウント数となり、その後シャッフルされます。そしてReduceフェーズで集約され、この記事の中で使用された「Hadoop」のインスタンスの合計が返されます。

また、IBMはローマでの国勢調査の実施に例えて、次のように説明しています。国勢調査員がローマの各地区に出向き、地区ごとのデータを集計します。そして本部に戻り、各地区の結果を集約してローマの総人口を算出します。

Apache Hadoop YARN - もう一つのリソース調整機能

Hadoop 2.0とYARNが発表されるまでは、MapReduceでごく基本的なワークロード管理やジョブのスケジューリングを行っていましたが、同じノードでMapReduce以外の分析アプリケーションを実行するのは非常に困難でした。実際のところ、分析アプリケーションを含むアーキテクチャはHadoop以外で実行しなければならず、このためHadoopのデータをHadoopインフラストラクチャの外にある外部ノードに移動する必要がありました。

YARNの登場は大きな変化でした。ついに、MapReduce以外の分析アプリケーションをHadoopクラスタで直接実行できるようになったのです。YARNは各ノードのリソースを、MapReduceのタスクや分析アプリケーションにバランスよくスマートに配置することで、それを実現しています。

Hadoopの制約

多数の小容量ファイルの扱い

Hadoopの制約の中でもよく知られているのが、非常に小容量のファイル、具体的にはHDFSのブロックサイズ(約64MB)よりも小さいファイルを格納・処理する際の問題です。Hadoopは極めて大容量のファイルを非常に効率よく処理できるよう最適化されていますが、小容量のファイルに関してはストレージと処理の両方の面で問題があります。

これについて、Clouderaのブログで分かりやすい例が紹介されています。1GBのファイルを各64MBの16つのブロックに分割した場合と、各100KBの10,000個のファイルに分割した場合とを比較すると、前者ではMapのタスクが16作られ、後者では10,000個作られます。物理的なストレージの使用量はどちらの場合も同じですが、後者のケースではパフォーマンスが劇的に低下します。

そこでClouderaは、Hadoopにおける小容量ファイルの扱いについて、HARファイルの作成、あるいはシーケンスファイルの作成という2つのソリューションを提示しています。

Hadoopの最適化

Hadoopは、データを専用のデータウェアハウスへ移すまで格納しておく非構造化データレイクおよびリファイナリー、あるいはクラスタ内で分析を実行する専用データウェアハウスのいずれかとしてデプロイできます。

Hadoopとデータウェアハウス

多くの組織は、主に開発者が使用する非構造化データレイクとしてHadoopを実装しています。そして専用のデータウェアハウスへデータを送る低コストのETL処理メカニズムとしてHadoopの処理フレームワークを活用し、アナリスト、ビジネスユーザー、分析アプリケーションがそれを使用できるようにしています。

データウェアハウスとしてのHadoopの活用

Hadoop 2.0とYARN、そしてHadoopエンジンで動作するANSI準拠のSQLの進化により、Hadoop上でクラスタ内分析を直接実行できるようになりました。このタイプの実装では、処理と分析はHadoop上で行われ、データを移動する必要がありません。

HadoopエンジンでSQLを使用する最大のメリットは、ビジネスユーザーやアナリストがHadoopのデータストアに対してSQLを実行できることです。この際、大規模なデータの移動が一切必要ない点も重要なポイントです。

アナリティクスを快適に

ビジネスインテリジェンス、ビッグデータ分析、顧客の360°ビュー。
Lookerはお客様のどんなニーズにもお応えします。当社のデータエキスパートにご相談ください。

デモをリクエスト