Hadoopとは
Hadoopは、Apache Software Foundationが開発・公開しているオープンソースの分散コンピューティングプラットフォームです。Googleが2004年前後に発表した論文「Google File System(GFS)」と「MapReduce」の設計思想を参考に、Yahoo!のエンジニアだったDoug Cuttingらが中心となって開発を進め、2006年にApacheのトップレベルプロジェクトとして独立しました。名前の由来は、Cuttingの息子が持っていた黄色いぬいぐるみの象の愛称「Hadoop」だとされています。
Hadoopの本質は「安価なコモディティサーバーを大量に束ねて、1台の巨大なコンピューターであるかのように振る舞わせる」という設計思想にあります。HDFS(Hadoop Distributed File System)がデータを複数ノードに分割・複製して保存し、MapReduceやYARN上で動く処理エンジンがそのデータをノード間で並列処理します。高価な専用ストレージ(SAN/NAS)や大型サーバーを使わずとも、数十〜数千台規模のサーバー群でペタバイト級のデータを扱えるようにした点が、2000年代後半から2010年代にかけて「ビッグデータ」という言葉の普及を後押ししました。
現在ではApache Spark、クラウドオブジェクトストレージ、クラウドDWH(Snowflake、BigQueryなど)の台頭により、新規のビッグデータ基盤としてHadoop一式を選ぶケースは減っていますが、HDFSやYARN、Hiveといった構成要素は今も多くの既存システムで稼働しており、その設計思想(分散ストレージ+分散処理+コモディティハードウェア)は後続のあらゆる分散処理基盤の土台になっています。実務でデータ基盤を扱うエンジニアにとって、Hadoopのアーキテクチャを理解しておくことは、Spark・Kafka・データレイクなど周辺技術を理解するための前提知識としても価値があります。
仕組み・詳細解説
HDFSのアーキテクチャ
HDFSは「マスター・スレーブ型」の分散ファイルシステムです。クラスタ全体のメタデータ(ファイル名、ディレクトリ構造、どのブロックがどのノードにあるか)を管理するNameNodeと、実際のデータブロックを保持するDataNode群で構成されます。ファイルは既定で128MB(旧バージョンでは64MB)程度のブロック単位に分割され、各ブロックはデフォルトで3重に複製(レプリケーション)されて別々のDataNodeに格納されます。これにより、1〜2台のノードが故障してもデータが失われない耐障害性を実現しています。NameNodeの単一障害点(SPOF)問題は、Hadoop 2.x以降のHA(High Availability)構成やQuorum Journal Managerの導入によって緩和されています。
MapReduceの処理フロー
MapReduceは「Map(分割・変換)」「Shuffle(並べ替え・集約)」「Reduce(集計)」の3段階でバッチ処理を行うプログラミングモデルです。入力データをブロック単位に近い形で複数のMapタスクに分配し、各タスクがキーと値のペア(key-value)を出力します。Shuffleフェーズでは同じキーを持つデータが同じReduceタスクに集約され、最終的にReduceタスクが集計・書き出しを行います。処理のたびに中間結果をディスクに書き出す設計のため、Sparkのようなインメモリ処理エンジンと比べると反復処理やインタラクティブなクエリには不向きですが、巨大なバッチ処理を安定して完走させる堅牢性には定評があります。
YARNによるリソース管理
Hadoop 2.0で導入されたYARN(Yet Another Resource Negotiator)は、クラスタ全体のCPU・メモリを管理するResourceManager、各ノードのリソースを監視するNodeManager、個々のジョブの実行を管理するApplicationMasterから構成されます。YARNの導入により、MapReduce専用だったクラスタ上でSpark、Tez、Hiveなど複数の処理エンジンを同時に、かつリソースを競合なく共有しながら実行できるようになりました。この汎用リソース管理層の分離は、後のKubernetesによるコンテナオーケストレーションの発想にも通じる、Hadoopエコシステムの重要な転換点です。
Hadoopエコシステム(周辺プロジェクト)
「Hadoop」という単語は、狭義にはHDFS・MapReduce・YARN・Hadoop Commonの4モジュールを指しますが、広義には周辺のOSSプロジェクト群を含めた「Hadoopエコシステム」全体を指すことが多いです。代表的なものに、SQLライクなクエリでMapReduce/Tezジョブを実行できるHive、HDFS上で動くカラム指向NoSQLデータベースのHBase、データフロー記述言語を提供するPig、RDBMSとHDFS間のデータ転送を担うSqoop、ジョブのワークフロー管理を行うOozie、分散システムの協調処理(設定管理やリーダー選出)を担うZooKeeperなどがあります。実務では「Hadoopを使う」というとき、これらエコシステムのうちいくつかを組み合わせて構築されたデータ基盤全体を指しているケースがほとんどです。
具体例・ユースケース
Hadoopが得意とするのは「膨大な量のデータを、多少の遅延を許容しつつ確実にバッチ処理する」ワークロードです。代表的な活用例は次のとおりです。
- Webログ・アクセスログ解析:ECサイトやメディアサイトのアクセスログを日次バッチでHDFSに集約し、Hiveでユーザー行動を集計してレコメンドやアクセス分析に活用する構成。
- 通信事業者のCDR(通話詳細記録)処理:1日に数億件規模で発生する通話・通信明細データをHDFSに蓄積し、MapReduceやHiveで課金計算・不正利用検知の集計処理を行う。
- 金融機関のリスク計算バッチ:大量の取引データを対象に、夜間バッチでポートフォリオのリスク指標や与信スコアを再計算する用途。
- 機械学習の前処理・特徴量生成:数TB〜数PB規模の生データから、機械学習モデル学習用の特徴量テーブルをバッチ生成する下処理基盤として利用。
- アーカイブ・コールドストレージ:頻繁にはアクセスしないが保持義務のあるログや帳票データを、安価なコモディティディスク上のHDFSにアーカイブする用途。
いずれも共通するのは「リアルタイム性より、大量データの確実な処理・保管を優先する」バッチ指向の性質です。逆に、数秒〜数百ミリ秒での応答が求められるダッシュボードやAPIのバックエンドには、後述のとおりHadoop単体は不向きです。
メリット・デメリット
| 観点 | メリット | デメリット・注意点 |
|---|---|---|
| コスト | OSSのためライセンス費用は無料。コモディティサーバーでスケールアウトでき、専用の高価なストレージ製品が不要。 | 構築・運用に相応の専門知識が必要で、人件費・運用コストが高くつきやすい。クラウド移行時代にはむしろ割高になるケースも。 |
| スケーラビリティ | ノードを追加するだけで容量・処理能力を線形に拡張できる水平スケーリングが可能。 | スケールアップ・ダウンに時間がかかり、クラウドのような秒単位の弾力的な増減は苦手。 |
| 耐障害性 | データのレプリケーションにより、一部ノード故障時もデータ消失を防げる。 | レプリケーション分だけストレージ使用量が増える(実データの約3倍が目安)。 |
| 処理速度 | 大量データのバッチ処理を安定して完走させる堅牢性が高い。 | MapReduceはディスクI/Oが多く、反復処理やインタラクティブなクエリでは低速。Sparkと比較すると顕著に遅い場合が多い。 |
| 運用・保守 | エコシステムが成熟しており、事例・ノウハウ・エンジニア人材の蓄積が豊富。 | クラスタの構築・チューニング・監視・バージョンアップには専門的なインフラ運用スキルが必要。新規学習者は減少傾向で人材確保が難しくなりつつある。 |
| リアルタイム性 | HBaseなどエコシステムの一部で低レイテンシなランダムアクセスも可能。 | MapReduce自体はバッチ指向であり、ストリーミング処理やリアルタイム分析にはKafka+Spark Streaming等の別基盤との組み合わせが前提となる。 |
混同されやすい用語・類似技術との違い
Hadoopはビッグデータ関連技術の中でも特に他の用語と混同されやすい存在です。代表的な比較対象との違いを整理します。
| 比較対象 | 位置づけ | Hadoopとの主な違い |
|---|---|---|
| Apache Spark | インメモリ分散処理エンジン | SparkはHadoopの後継・補完として登場した処理エンジンで、中間データをメモリ上に保持するためMapReduceより高速な場合が多い。HDFSやYARN上で動かすこともでき、「Hadoopと対立する技術」ではなく「Hadoopのストレージ層・リソース管理層を活用しつつ処理部分を置き換える技術」という位置づけが実態に近い。 |
| データレイク | 生データを形式を問わず蓄積する保存戦略の概念 | データレイクは「構造化・非構造化を問わず生データをそのまま貯める」という設計思想(コンセプト)であり、HDFSはそれを実現する具体的な実装手段の一つに過ぎない。近年のデータレイクはHDFSの代わりにAmazon S3やAzure Data Lake Storageなどのクラウドオブジェクトストレージ上に構築されることが主流。 |
| HBase(NoSQL) | HDFS上で動くカラム指向NoSQLデータベース | HadoopがバッチファイルシステムとしてのHDFSであるのに対し、HBaseは行キー単位での高速なランダム読み書きを実現するデータベース。「Hadoopエコシステムの一部」であり、HadoopそのものとHBaseは包含関係にある。 |
| クラウドDWH(Snowflake・BigQuery等) | フルマネージドのクラウド型データウェアハウス | クラウドDWHはストレージと計算リソースが分離されたサーバーレス型のSQL分析基盤で、インフラ運用が不要。Hadoopは自前でクラスタ構築・運用する前提のOSSであり、運用負荷とコスト構造が大きく異なる。2025年時点では新規のデータ分析基盤としてクラウドDWHを第一候補にする企業が増えている。 |
| Apache Kafka | 分散メッセージングシステム | Kafkaはリアルタイムのデータストリームを受け渡す役割で、Hadoop(バッチ処理・蓄積)とは処理対象のタイムスケールが異なる。実務ではKafkaでリアルタイム収集し、HDFSやデータレイクにバッチで永続化するという組み合わせで使われることが多い。 |
実務ポイント:導入時の選定基準とワークフロー
オンプレミス構築 vs マネージドサービス
Hadoopクラスタは、自社データセンターにサーバーを並べてゼロから構築する方法と、クラウドのマネージドサービスを利用する方法に大別されます。代表的なマネージドサービスにはAmazon EMR(Elastic MapReduce)、Azure HDInsight、Google Cloud Dataprocなどがあり、クラスタの起動・スケーリング・パッチ適用などの運用負荷を大幅に軽減できます。オンプレミス構築ではCloudera Data Platform(旧Cloudera/Hortonworksが統合)のような商用ディストリビューションを使うケースが多く、サポート込みのライセンス費用は、ノード数や契約形態に応じて年間数百万円〜規模になることが一般的です(金額は契約条件により変動するため、必ず個別見積もりが必要)。
選定基準の考え方
- データ量とレイテンシ要件:バッチで十分ならHadoop(またはSpark併用)、準リアルタイム性が必要ならKafka+Spark Streamingやクラウドのストリーミングサービスを検討。
- 運用体制:インフラ運用専任のエンジニアを確保できるかどうかが、オンプレHadoop運用継続の可否を左右する。
- 既存資産:すでにHDFS・Hive上に構築されたレガシー資産が大量にある場合、無理に移行せずマネージドサービスへのリフト&シフトを優先する選択も現実的。
- コスト構造:オンプレは初期投資(CAPEX)中心、クラウドは従量課金(OPEX)中心。処理が間欠的ならクラウド、常時フル稼働ならオンプレが有利になりやすい、という一般的傾向がある。
典型的な分析ワークフロー例
Hive経由でHDFS上のデータを集計するワークフローの一例(イメージ)は次のとおりです。
-- 1. RDBMSの取引データをSqoopでHDFSへ取り込み
sqoop import --connect jdbc:mysql://source-db/sales \
--table transactions --target-dir /data/raw/transactions
-- 2. Hiveで外部テーブルを定義
CREATE EXTERNAL TABLE transactions (
txn_id STRING, user_id STRING, amount DOUBLE, txn_date STRING
)
ROW FORMAT DELIMITED FIELDS TERMINATED BY ','
LOCATION '/data/raw/transactions';
-- 3. HiveQLで日次集計(内部でMapReduce/Tezが実行される)
SELECT txn_date, COUNT(*) AS cnt, SUM(amount) AS total
FROM transactions
GROUP BY txn_date;
このように、取り込み(Sqoop)→蓄積(HDFS)→クエリ(Hive)→ワークフロー管理(Oozie等でスケジューリング)という一連の流れがHadoopエコシステムの典型的な実務パターンです。近年はSqoopの代わりにデータパイプラインツールやCDCツールを使い、HiveやSparkの代わりにクラウドDWHのSQLエンジンを使う構成に置き換えられつつあります。
2025〜2026年の最新動向
2025年から2026年にかけても、新規のビッグデータ基盤構築でHadoop(HDFS+MapReduce)一式をゼロから採用するケースは引き続き少数派です。新規プロジェクトの多くは、Apache Sparkをはじめとするインメモリ分散処理エンジンと、Amazon S3・Azure Data Lake Storage・Google Cloud StorageといったクラウドオブジェクトストレージやApache Icebergなどのテーブルフォーマットを組み合わせる「レイクハウス」構成に流れる傾向が続いています。
一方で、HDFSやHiveの上に構築された既存の大規模データ基盤は金融・通信・製造業などの大企業に依然として多く残っており、これらのレガシー環境の保守・段階的なクラウド移行(リプラットフォーム)は継続的な実務需要として存在しています。Amazon EMRやAzure HDInsight、Google Cloud DataprocといったマネージドHadoop/Sparkサービスは、こうした既存資産を活かしつつ運用負荷を下げる移行先として一定の需要を保っています。また、Cloudera Data Platformのような商用ディストリビューションも、オンプレミス環境での大規模データ処理基盤として企業利用が続いています。総じて「新規採用は減少、既存資産の保守・移行需要は継続」というのが2025〜2026年時点でのHadoopの位置づけと言えます。
よくある質問(FAQ)
Q. Hadoopとは何ですか?
A. Hadoopは分散ファイルシステム(HDFS)と分散処理・リソース管理(MapReduce/YARN)を提供するオープンソースのビッグデータ処理プラットフォームです。コモディティハードウェアを束ねてPB(ペタバイト)規模のデータを処理できる点が特徴で、Apache Software Foundationが開発しています。
Q. HadoopとApache Sparkの違いは何ですか?
A. HadoopのMapReduceは処理の途中経過をディスクに書き出すためI/Oが多く低速になりがちですが、Sparkは中間データをメモリ上に保持するため反復処理や対話的なクエリで高速に動作します。2025年時点では新規のビッグデータ処理エンジンとしてはSparkが選ばれる場合が多く、HadoopはHDFSによるデータ保管やYARNによるリソース管理の役割が主になっているケースが目立ちます。両者は競合というより、Hadoopの基盤(HDFS/YARN)の上でSparkが動く補完関係にあることも多いです。
Q. HadoopとHDFSは同じものですか?
A. 同じではありません。HDFSはHadoopを構成するコンポーネントの一つ(分散ファイルシステム)であり、Hadoop自体はHDFS・MapReduce・YARN・Hadoop Commonという複数モジュールの総称です。さらに広義には、Hive・HBase・Sqoop・Oozieなどの周辺プロジェクトを含めた「Hadoopエコシステム」全体を指してHadoopと呼ぶこともあります。
Q. これから新規にデータ基盤を構築する場合、Hadoopを選ぶべきですか?
A. 一般的には、新規構築であればクラウドDWH(Snowflake、BigQuery、Amazon Redshiftなど)やクラウドオブジェクトストレージ+Sparkの組み合わせの方が、運用負荷とコストの両面で有利になるケースが多いです。ただし、既存のHDFS/Hive資産が大量にある場合や、オンプレミス環境でのデータガバナンス要件が厳しい場合は、Hadoopベースの構成を維持・拡張する判断も引き続き合理的です。
Q. 2025〜2026年のHadoopの現状はどうなっていますか?
A. 新規構築でのHadoop MapReduceの採用は減り続けており、SparkとS3・ADLS等のオブジェクトストレージを組み合わせたレイクハウス構成が主流になっています。ただしHDFSを用いたレガシーシステムは金融・通信・製造業などに依然として多く残っており、Amazon EMR・Azure HDInsight・Google Cloud DataprocといったマネージドHadoop/Sparkサービスや、Cloudera Data Platformのような商用ディストリビューションで保守・段階的な移行が進められています。
関連用語
- Apache Spark - Hadoopの後継として広く使われるインメモリ分散処理エンジン
- ビッグデータ - Hadoopが処理対象とする大規模データの概念
- データレイク - HDFSが実装の一つとなる生データの蓄積戦略
- データウェアハウス - 構造化データを分析用に整理して格納する基盤
- Apache Kafka - リアルタイムのデータストリームをHadoop/データレイクに連携する分散メッセージング基盤
- ETL - Hadoop環境でのデータ取り込み・変換処理の基本パターン
- データパイプラインアーキテクチャ - Hadoopを含むデータ処理基盤全体の設計手法
