🔖 キーワード索引

🎨 直感で掴む

📐 定義／数式

Hadoop（Apache Hadoop）：大規模データを商用クラスタで分散保存・並列処理するオープンソースフレームワークの総称

📐 Amdahl 法則 — 数式の詳細導出

Hadoop / Spark のクラスタ規模を決めるとき、 「ノードを 2 倍にすれば 2 倍速くなるか？」という素朴な期待は Amdahl 法則 によって裏切られます。 並列化できない逐次部分（シャッフル、 マスタノードでの集約、 ディスク I/O 待ち）が必ず存在するため、 ノード追加の効果は頭打ちになります。

Amdahl 法則の正式な定義

プログラム全体の実行時間を 1 とし、 そのうち並列化可能な割合を p、 逐次実行が必要な割合を (1-p) とします。 ノード数（並列度）を N としたとき、 スピードアップ S(N) は次式で与えられます：

🔬 数式を言葉で読み解く

分母の (1-p) は 逐次部分、 p/N は 並列化された部分が N ノードで分担されたあとの実行時間。 N を無限大にしても、 逐次部分 (1-p) が残るため、 スピードアップは 1/(1-p) で頭打ちになります。 これが Amdahl 限界。

数値例：p=0.9（90% が並列化可能）の場合

Hadoop ジョブの典型値として p=0.9（Map が支配的）を想定すると、 N を増やしたときの S(N) は次のようになります：

⚠️ 10 ノードで 5.26 倍にしかならない。 「ノード追加すれば線形に速くなる」は幻想であり、 SSDSE のような中小データで Hadoop を導入しても費用対効果が低い理由がここにあります。

🔬 数式を言葉で読み解く

🔬 HDFS の内部動作 — 書込み・読込みフロー

書込み（Write）フロー

1. クライアントが NameNode に「ファイル /user/me/log.csv を書きたい」と問い合わせ
2. NameNode がブロック ID と「最初のレプリカを書くべき DataNode リスト（3 台）」を返答
3. クライアントは パイプライン で書込み：DN1 → DN2 → DN3 と順次転送（並列ではない）
4. DN3 → DN2 → DN1 → クライアントへ ACK が逆向きに返る
5. すべてのブロックを書き終えたら NameNode に完了通知
6. NameNode はメタデータ（fsimage + edits log）を更新

読込み（Read）フロー

1. クライアントが NameNode にファイル名と読込み範囲を問合せ
2. NameNode が「ブロック ID とそれを持つ DataNode リスト」を距離順に返答
3. クライアントは 最も近い DataNode（同ラック優先）からブロックを直接読込み
4. もしレプリカが壊れていれば次の DataNode に自動フェイルオーバ

ポイント：NameNode は メタデータの仲介のみで、 実データは DataNode とクライアントが直接通信。 これが「NameNode はネックにならない」設計の核心。

🔬 MapReduce 最適化テクニック

🌊 バッチ vs ストリーミング — Lambda／Kappa アーキテクチャ

Hadoop は バッチ処理（一定期間溜めてから一括）に強いが、 リアルタイム性は弱い。 そこで派生したのが：

Lambda アーキテクチャ

同じデータを 2 つの経路で処理：

• バッチ層：Hadoop で日次集計（正確だが遅延 24 時間）
• ストリーミング層：Storm／Flink でリアルタイム集計（速いが近似）
• サービス層：両者の結果をマージ

複雑だが当時の現実解。 ヤフー、 Twitter、 LinkedIn が採用。

Kappa アーキテクチャ

Kafka + Flink／Spark Streaming だけで完結。 ストリーミング処理が信頼性を持つようになった現代の主流。 Hadoop バッチ層を不要にする思想。

🔐 セキュリティとガバナンス

Hadoop は元々セキュリティが弱かったが、 2010 年代後半から大幅強化：

• Kerberos 認証：MIT 発祥のチケット式認証。 全コンポーネントが Kerberos プリンシパルで動く
• Apache Ranger：細粒度アクセス制御（行・列・ファイル単位）。 監査ログ統合
• Apache Knox：クラスタへの外部アクセスを 1 つのゲートウェイ集約。 SSO 対応
• HDFS 暗号化：at rest（保存時）暗号化。 ゾーン単位で鍵を切替え
• TLS/SSL：DataNode 間、 クライアント間通信を暗号化
• Apache Atlas：データリネージ（系譜）追跡。 GDPR 対応

金融・医療・公共機関のオンプレ Hadoop はこれらを組合せて運用。 マイナンバー基盤など、 日本の機微情報処理にも使われている。

🔄 おすすめの学習ステップ

1. 本ページの 30 秒結論 を 3 回読み、 「HDFS / MapReduce / YARN の三本柱」を口頭で説明できるか確認
2. 本ページの Amdahl 法則シミュレーション を Python で動かし、 並列化の限界を体感
3. pandas で SSDSE-B-2026 を集計。 数百 KB のデータが瞬時に処理されることを確認
4. PySpark をローカルインストール。 同じ SSDSE データを spark で処理し、 起動オーバヘッドが大きいことを確認
5. Docker で Hadoop シングルノードを立てる（docker run apache/hadoop）。 HDFS の put/get/cat を試す
6. AWS EMR or GCP Dataproc でマルチノードクラスタを立てる（無料枠 or 数百円）。 本物の分散処理を体験
7. Spark に移行。 同じ処理が 10 倍速くなることを実感
8. クラウド DWH（BigQuery 無料枠）を試し、 「Hadoop を運用しない選択肢」も理解

🎓 学習達成度の自己チェック

1. Hadoop の三本柱（HDFS／MapReduce／YARN）を 30 秒で説明できるか？
2. 「データを動かさず計算を動かす」の意味を具体例で説明できるか？
3. Amdahl の法則から「並列化の限界」を計算できるか？
4. SSDSE-B-2026 に Hadoop を使わない理由を明確に言えるか？
5. 小ファイル問題が NameNode のどこを圧迫するか説明できるか？
6. MapReduce と Spark の本質的な違いは？
7. レプリカ 3 を 2 に減らすとどんな影響？
8. Combiner と Reducer の違いは？
9. クラウド DWH と Hadoop の判断基準は？
10. HDFS の Write フローを順を追って説明できるか？

10 問中 7 問以上 答えられれば実務レベル。 残りは関連用語ページを辿って補強。

📊 Hadoop バージョン履歴と主要機能

🛠 Hadoop エコシステム — 各ツールの詳細

Apache Hive

SQL 風言語 HiveQL で MapReduce / Tez / Spark ジョブを生成。 メタストア（テーブル定義の DB）がエコシステムの中核に。 2008 年 Facebook 発祥。 当時 Facebook の SQL ユーザに Hadoop を使わせるためのブリッジとして。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

-- Hive で SSDSE 風データを集計
CREATE EXTERNAL TABLE ssdse_b (
  year INT, code STRING, prefecture STRING,
  population BIGINT, births BIGINT
) ROW FORMAT DELIMITED FIELDS TERMINATED BY ','
LOCATION '/user/data/ssdse-b/';

-- 都道府県別の出生数 TOP10
SELECT prefecture, SUM(births) AS total_births
FROM ssdse_b
WHERE year = 2023
GROUP BY prefecture
ORDER BY total_births DESC
LIMIT 10;

Apache HBase

HDFS の上に乗る列指向 NoSQL。 Google Bigtable のクローン。 ランダム読み書きが必要なケース（ユーザプロファイル、 リアルタイムダッシュボード等）に使う。 LSM tree 構造。

Apache Sqoop

RDB（Oracle、 MySQL、 PostgreSQL）と HDFS 間のデータ移送ツール。 「sqoop import --connect ... --table users」で MySQL のテーブルが HDFS に。 ただし 2021 年に Apache Attic（メンテ終了）入り。 後継は Apache NiFi。

Apache Flume

ログを Web サーバから HDFS へリアルタイム転送。 source → channel → sink の設定で柔軟に構成。 Web アクセスログ収集の定番だったが、 Kafka に置き換わるケースが増加。

Apache Kafka

LinkedIn 発祥の分散メッセージキュー。 Hadoop の「取込み」を担う標準ツール。 トピック単位で publish/subscribe、 ログを再生可能。 Lambda／Kappa アーキテクチャの基盤。

Apache Oozie

Hadoop ジョブのワークフロー管理。 XML で「MR ジョブ A 完了後に Hive ジョブ B、 失敗時に C」を記述。 近年は Airflow に押されて利用減。

Apache Zookeeper

分散システムの調整役。 NameNode HA、 HBase のリーダー選出、 Kafka のコンシューマグループ管理など、 Hadoop エコシステムのあちこちで使われる「裏方の主役」。

📈 規模の感覚 — SSDSE と本物のビッグデータの距離

SSDSE-B-2026 は本物のビッグデータより 10 億倍小さい。 概念理解のために Hadoop を学ぶのは有益だが、 SSDSE 解析で実際に使う場面は無い。 「いつ必要になるか」を見極める眼が大事。

🧪 教科書例：WordCount を MapReduce で書く（Java 風擬似コード）

MapReduce の「Hello World」とされる WordCount。 入力テキストの中で各単語の出現回数を数える。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

// Mapper
public class TokenizerMapper extends Mapper<Object, Text, Text, IntWritable> {
    private final static IntWritable one = new IntWritable(1);
    private Text word = new Text();

    public void map(Object key, Text value, Context context) {
        StringTokenizer itr = new StringTokenizer(value.toString());
        while (itr.hasMoreTokens()) {
            word.set(itr.nextToken());
            context.write(word, one);  // (単語, 1) を出力
        }
    }
}

// Reducer
public class IntSumReducer extends Reducer<Text, IntWritable, Text, IntWritable> {
    private IntWritable result = new IntWritable();

    public void reduce(Text key, Iterable<IntWritable> values, Context context) {
        int sum = 0;
        for (IntWritable val : values) sum += val.get();
        result.set(sum);
        context.write(key, result);  // (単語, 合計数) を出力
    }
}

// Driver
public class WordCount {
    public static void main(String[] args) throws Exception {
        Configuration conf = new Configuration();
        Job job = Job.getInstance(conf, "word count");
        job.setJarByClass(WordCount.class);
        job.setMapperClass(TokenizerMapper.class);
        job.setCombinerClass(IntSumReducer.class);  // 同じ Reducer を Combiner に流用
        job.setReducerClass(IntSumReducer.class);
        job.setOutputKeyClass(Text.class);
        job.setOutputValueClass(IntWritable.class);
        FileInputFormat.addInputPath(job, new Path(args[0]));
        FileOutputFormat.setOutputPath(job, new Path(args[1]));
        System.exit(job.waitForCompletion(true) ? 0 : 1);
    }
}

同じことを Hadoop Streaming（Python）で：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

# Hadoop Streaming の mapper / reducer は、本来 sys.stdin から 1 行ずつ受け取る。
# ブラウザや対話環境には標準入力が無いので、ここでは行のリストを渡して同じ動きを再現する。

def mapper(lines):
    """1 行を単語に割り、(単語, 1) を出す。実際は print で標準出力に流す"""
    out = []
    for line in lines:
        for word in line.strip().split():
            out.append((word, 1))
    return out

def reducer(pairs):
    """単語で並べ替えたペアを受け取り、同じ単語の数を足し合わせる"""
    out = []
    current, count = None, 0
    for word, val in sorted(pairs):
        if word == current:
            count += int(val)
        else:
            if current is not None:
                out.append((current, count))
            current, count = word, int(val)
    if current is not None:
        out.append((current, count))
    return out

lines = [
    '北海道 東北 関東',
    '関東 中部 近畿',
    '関東 近畿 九州',
]
pairs = mapper(lines)
print('map の出力（先頭 5 件）:', pairs[:5])
print('reduce の出力:', reducer(pairs))

同じことを Spark で書くと劇的に短い：

1
2
3
4
5
6
7
8
9

from pyspark.sql import SparkSession

spark = SparkSession.builder.appName('wc').getOrCreate()
text = spark.read.text('input.txt')
words = text.selectExpr('explode(split(value, " ")) AS word')
counts = words.groupBy('word').count()
counts.show()
spark.stop()
# 5 行で同じ処理。 これが Spark 普及の決定打

🔧 主要設定パラメータ — チューニングの肝

🔬 MapReduce の数式を言葉で読み解く

MapReduce は関数型プログラミングの map と reduce を分散システムに持ち込んだものです。 数式で表すと次の 3 段階：

数式を言葉で読み解く（詳細）

• Map フェーズ：入力キー k₁ と値 v₁ を受け取り、 中間キー k₂ と中間値 v₂ のペアのリストを出す。 例：行 ID と都道府県データ → (地方コード, 人口) のリスト。 並列化が容易。
• Shuffle フェーズ：同じ k₂ を持つ v₂ を集約。 ここで ネットワーク経由のデータ転送 が大量に発生し、 ボトルネックになりやすい（Amdahl 法則の (1-p) 部分）。
• Reduce フェーズ：キー k₂ ごとに list(v₂) を最終出力 v₃ に変換。 例：地方ごとの合計人口を出す。

SSDSE-B-2026 の例で言えば、 47 都道府県を 8 地方（北海道・東北・関東・中部・近畿・中国・四国・九州沖縄）に group by する処理は (都道府県コード, 人口) → (地方, 合計人口) の MapReduce そのものです。

🧮 実値で計算してみる

シナリオ A：SSDSE-B-2026（47 都道府県 × 12 年 = 564 行、 約 200 KB） を Hadoop で集計するのは 明らかに過剰。 1 台の pandas で 0.1 秒で終わる規模。

シナリオ B：SSDSE-B を市区町村レベル × 全国小売店 POS × 10 年に拡張すると、 たとえば 1700 市町村 × 1000 店舗 × 5000 日 × 100 商品 ＝ 約 850 億行、 1 行 200 byte と仮定して 17 TB。 ここで初めて Hadoop の出番。

HDFS ストレージ計算（架空のアクセスログ）：1 日 100 GB のアクセスログを 1 年保管。 元データ $D = 100 \times 365 = 36.5$ TB。 レプリカ $R=3$ で実使用 109.5 TB。 ブロック数 $N = 36.5 \times 10^6 / 128 \approx 285{,}156$。 NameNode メモリ $\approx 285{,}156 \times 150$ byte ≒ 43 MB（余裕）。 ただしファイルを 1 KB の小ファイル 1 億個で持つと NameNode が破綻 — 小ファイル問題 の典型。

🧮 数式に値を入れて手で計算する: HDFS ブロック数

合成データで 10 GB のファイルを 128 MB ブロックに分割した時の数とノード分散を計算する。

Step 1: ブロック計算

Step 2: レプリカ (3 倍) と分散

🐍 Python で再現

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

import math
file_mb = 10 * 1024
block_mb = 128
blocks = math.ceil(file_mb / block_mb)
replicas = 3
total = blocks * replicas
nodes = 20
per_node = total / nodes
print(f"ブロック数: {blocks}")
print(f"レプリカ込み: {total}")
print(f"ノードあたり: {per_node} ブロック ({per_node * block_mb} MB)")

📤 実行結果

💬 手計算 (Step 2) 12 ブロック/ノードと Python 出力が完全一致。

🎮 触って理解する

MapReduce の Map → Shuffle → Reduce を、 架空の短いテキストの ワードカウント（明記：下の単語列は説明用の 架空データ です）で 1 ステップずつ可視化します。 データを複数ノードに分割し、 各ノードが自分の近くのデータだけを数え、 同じ単語を同じ Reducer に集約して合計する — この 3 段を体感してください。

💡 3 つの視点で深掘り

🧱 データ局所性と耐障害（レプリケーション）

HDFS は各ブロックを 別ノードに複製（既定 R=3、 下図は R=2）します。 ノードを停止してみて、 レプリカがある限りデータが読めることを確認してください。

🐍 Python での実装例

① まず比較対象 — pandas でやる SSDSE-B-2026 集計（基準）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

import pandas as pd

# SSDSE-B-2026 を 1 台の pandas で読み込み・集計（数百 KB なので一瞬）
df = pd.read_csv('data/raw/SSDSE-B-2026.csv', skiprows=2, header=None, encoding='cp932')
df = df.rename(columns={0: 'year', 2: 'prefecture', 3: 'population', 18: 'births'})
recent = df[df['year'] == 2023]

# 都道府県別 平均出生数（実は 1 年 1 行なので合計と同じ）
print('--- 上位 5 県（出生数） ---')
print(recent.nlargest(5, 'births')[['prefecture', 'population', 'births']].to_string(index=False))

print('全国計（出生数）:', recent['births'].sum())
print('行数:', len(recent), '/ メモリ:', df.memory_usage().sum() // 1024, 'KB')
# → 数百 KB。 Hadoop は完全に過剰

② MapReduce の発想を pandas で再現（教育用ミニ実装）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

import pandas as pd
from collections import defaultdict

df = pd.read_csv('data/raw/SSDSE-B-2026.csv', skiprows=2, header=None, encoding='cp932')
df.columns = ['year', 'code', 'prefecture'] + [f'col{i}' for i in range(3, df.shape[1])]
recent = df[df['year'] == 2023][['prefecture', 'col18']].rename(columns={'col18': 'births'})

# Map フェーズ：行を (キー, 値) に変換
def mapper(row):
    pref = row['prefecture']
    # 地域分類（東日本 / 西日本）をキーに
    east = ['北海道', '青森県', '岩手県', '宮城県', '秋田県', '山形県', '福島県', '茨城県',
            '栃木県', '群馬県', '埼玉県', '千葉県', '東京都', '神奈川県', '新潟県', '富山県',
            '石川県', '福井県', '山梨県', '長野県', '岐阜県', '静岡県', '愛知県']
    return ('東日本' if pref in east else '西日本', row['births'])

mapped = [mapper(row) for _, row in recent.iterrows()]
print('Map 出力（最初5件）:', mapped[:5])

# Shuffle フェーズ：キーでグループ化
shuffled = defaultdict(list)
for k, v in mapped:
    shuffled[k].append(v)

# Reduce フェーズ：キーごとに集約
reduced = {k: sum(v) for k, v in shuffled.items()}
print('Reduce 結果:', reduced)
# → これが MapReduce の最小モデル。 ノードに分散するなら mapped を分割して並列実行

③ PySpark で同じ集計（Hadoop 互換 API）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

from pyspark.sql import SparkSession
from pyspark.sql import functions as F

# ローカルモードで起動（クラスタ無しでも動く）
spark = SparkSession.builder.appName('ssdse_demo').master('local[*]').getOrCreate()

# HDFS にあるなら 'hdfs:///data/SSDSE-B-2026.csv'。 ローカルなら通常パス
df = spark.read.csv('data/raw/SSDSE-B-2026.csv', header=False, inferSchema=True,
                    encoding='cp932')
df = df.toDF(*([f'col{i}' for i in range(df.columns.__len__())]))

# 年度フィルタ・都道府県別集計
recent = df.filter(F.col('col0') == 2023)
agg = recent.groupBy('col2').agg(F.sum('col18').alias('total_births'))
agg.orderBy(F.desc('total_births')).show(5)

# 実行計画（Catalyst optimizer）を見る
agg.explain()

spark.stop()

④ HDFS を CLI で操作（参考。 Hadoop 環境が必要）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

# 注意: hadoop コマンドは Hadoop 環境（CDH/HDP/EMR 等）でのみ動作

# HDFS にローカルファイルをアップロード
# $ hadoop fs -put data/raw/SSDSE-B-2026.csv /user/me/

# 中身を確認
# $ hadoop fs -cat /user/me/SSDSE-B-2026.csv | head

# ブロック配置（どの DataNode に複製されたか）を確認
# $ hdfs fsck /user/me/SSDSE-B-2026.csv -files -blocks -locations

# レプリカ数を変更（既定 3 → 2 に減らしてストレージ節約）
# $ hadoop fs -setrep -w 2 /user/me/SSDSE-B-2026.csv

# 容量確認
# $ hadoop fs -df -h /
# $ hadoop fs -du -h /user/me/

⑤ Amdahl の法則をシミュレーション

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

import numpy as np
import pandas as pd

def amdahl_speedup(f, p):
    """並列化可能割合 f, ノード数 p のときの理論速度向上"""
    return 1.0 / ((1 - f) + f / p)

rows = []
for f in [0.5, 0.8, 0.9, 0.95, 0.99]:
    for p in [1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024]:
        rows.append({'f': f, 'p': p, 'speedup': amdahl_speedup(f, p)})

result = pd.DataFrame(rows).pivot(index='p', columns='f', values='speedup').round(2)
print('--- 速度向上倍率（Amdahl）---')
print(result)

# 教訓: f=0.99 でも p=1024 で 91 倍止まり。 100 倍が理論上限

🐍 Python 実装：Amdahl 法則のシミュレーション

🎯 このコードでやること：SSDSE-B-2026 の 47 都道府県データを「分散処理風」に分割し、 並列化可能割合 p=0.9 と p=0.7 の 2 通りで Amdahl 法則のスピードアップ曲線を計算する。

📥 入力データ：SSDSE-B-2026（47 都道府県 × 約 80 変数）。 各都道府県を 1 ブロック相当として扱う想定。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

import numpy as np
import pandas as pd

# Amdahl 法則の定義
def amdahl_speedup(N, p):
    """並列度 N、 並列化可能割合 p のスピードアップ S(N)"""
    return 1.0 / ((1.0 - p) + p / N)

# SSDSE 47 県を分散ブロックと見立てる
df = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='cp932', skiprows=[1])
n_blocks = len(df)  # 47 都道府県

# 2 つのシナリオ
N_list = [1, 2, 4, 8, 16, 32, 47, 100, 1000]
for p in [0.9, 0.7]:
    print(f"--- 並列化可能割合 p = {p} ---")
    for N in N_list:
        s = amdahl_speedup(N, p)
        print(f"  N={N:>4d} ノード → S(N)={s:.2f}x")
    print(f"  上限 S(∞) = {1/(1-p):.2f}x\n")
    </div>

📤 実行結果：

💬 結果の読み方：p=0.9 でも 47 ノードで 8.3 倍止まり。 p=0.7 だと 3.2 倍が事実上の天井。 SSDSE のような数十 MB 規模で Hadoop を使う場合、 逐次部分（シャッフル・ジョブ起動）が支配的 になり、 N を増やしても無駄が大きい。 これが「中小データに Hadoop は不向き」の数値的根拠です。

🐍 Python 実装：PySpark で SSDSE-B-2026 を MapReduce 風に処理

🎯 このコードでやること：SSDSE-B-2026 の 47 都道府県データを PySpark で読み込み、 「地方ごとの合計人口」を MapReduce 風に集計する。 ローカルモード（master='local[*]'）で動作確認。

📥 入力データ：SSDSE-B-2026 から「都道府県コード」「都道府県名」「総人口」の 3 カラム。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

from pyspark.sql import SparkSession
from pyspark.sql.functions import sum as F_sum, col, when

# Spark セッション起動（ローカルモード、 全 CPU 使用）
spark = SparkSession.builder \
    .appName('SSDSE-Hadoop-Demo') \
    .master('local[*]') \
    .getOrCreate()

# SSDSE-B-2026 を Spark DataFrame で読込
sdf = spark.read.csv(
    'data/raw/SSDSE-B-2026.csv',
    header=True,
    encoding='cp932',
    inferSchema=True
)
# 2 行目（説明行）を除去
header_row = sdf.first()
sdf = sdf.filter(col('SSDSE-2026') != header_row['SSDSE-2026'])

# 都道府県コード先頭 2 桁から地方を分類（Map ステップに相当）
sdf = sdf.withColumn('region',
    when(col('SSDSE-2026').substr(2, 2) <= '01', '北海道')
   .when(col('SSDSE-2026').substr(2, 2) <= '07', '東北')
   .when(col('SSDSE-2026').substr(2, 2) <= '14', '関東')
   .when(col('SSDSE-2026').substr(2, 2) <= '23', '中部')
   .when(col('SSDSE-2026').substr(2, 2) <= '30', '近畿')
   .when(col('SSDSE-2026').substr(2, 2) <= '35', '中国')
   .when(col('SSDSE-2026').substr(2, 2) <= '39', '四国')
   .otherwise('九州沖縄')
)

# 地方ごとに合計人口を集計（Reduce ステップ）
result = sdf.groupBy('region').agg(F_sum('総人口').alias('合計人口')) \
    .orderBy(col('合計人口').desc())
result.show()
    </div>

📤 実行結果：

💬 結果の読み方：関東 4,380 万人で日本の人口集中が顕著。 PySpark で書いても処理量は同じだが、 数 TB 規模になればクラスタが効く。 SSDSE 規模（数十 MB）では pandas の groupby が桁違いに速い。

🐍 Python 実装：dask による中間規模並列処理

🎯 このコードでやること：SSDSE-B-2026 を dask.dataframe で読み込み、 同じ集計を「ノード数 4」想定で実行。 pandas API と互換のため移行コストが低いことを確認。

📥 入力データ：SSDSE-B-2026 の同データを dask.dataframe で 4 パーティションに分割。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

import dask.dataframe as dd
import pandas as pd
import time

# SSDSE-B-2026 を pandas で読込
df = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='cp932', skiprows=[1])

# dask DataFrame に変換（4 パーティション）
ddf = dd.from_pandas(df, npartitions=4)

# 地方分類関数
def to_region(code):
    code_int = int(str(code)[1:3])
    if code_int == 1: return '北海道'
    elif code_int <= 7: return '東北'
    elif code_int <= 14: return '関東'
    elif code_int <= 23: return '中部'
    elif code_int <= 30: return '近畿'
    elif code_int <= 35: return '中国'
    elif code_int <= 39: return '四国'
    else: return '九州沖縄'

ddf['region'] = ddf['SSDSE-2026'].map(to_region, meta=('region', 'object'))

# 地方ごとに集計（map → reduce 相当）
t0 = time.time()
result = ddf.groupby('region')['A1101'].sum().compute()
print(f'Elapsed: {time.time()-t0:.3f} sec')
print(result.sort_values(ascending=False))
    </div>

📤 実行結果：

💬 結果の読み方：dask は pandas と同じ API。 47 行では並列化の効果はほぼなく、 むしろ Spark 起動のオーバヘッドが目立つ（pandas の groupby: 約 0.003 秒）。 並列化の恩恵が出るのは 数億行以上。 「規模に応じてツールを選ぶ」のがエンジニアリングの基本。

🛡️ Hadoop の fault tolerance — 数式を言葉で読み解く

HDFS の特徴は レプリケーション（既定 3 系統）です。 1 つのブロックを別ノードに 3 つコピーしておくことで、 1 ノードが落ちてもデータが失われない。 ノード故障確率を q、 レプリカ数を r とすると、 ブロックが完全に失われる確率は：

数式を言葉で読み解く

• q：1 ノードが故障する確率（例：年間 q=0.02 = 2%）
• r：レプリカ数（HDFS 既定 r=3）
• P_loss：そのブロックが完全に失われる確率（全レプリカ同時故障）

q=0.02、 r=3 のとき P_loss = 0.02³ = 0.000008（百万分の 8）。 100 万ブロックでも期待損失 8 ブロック。 これが「HDFS は安心して TB 級データを置ける」根拠です。 一方で r=1 にすると q=0.02 そのままなので、 1 万ブロック中 200 ブロックが消失する計算。

📜 Hadoop 史 — 2004 → 2026 の主要トランジション

⚠️ よくある落とし穴

⚠️ よくある誤解

🧰 よく使う Hadoop コマンド集

HDFS 操作

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

# ファイル一覧
hadoop fs -ls /user/me/
hadoop fs -ls -R /user/me/   # 再帰

# ローカル → HDFS
hadoop fs -put local.csv /user/me/
hadoop fs -copyFromLocal local.csv /user/me/

# HDFS → ローカル
hadoop fs -get /user/me/data.csv ./
hadoop fs -copyToLocal /user/me/data.csv ./

# 中身確認
hadoop fs -cat /user/me/data.csv | head
hadoop fs -tail /user/me/log.txt

# 削除
hadoop fs -rm /user/me/old.csv
hadoop fs -rm -r /user/me/old_dir/    # 再帰
hadoop fs -rm -skipTrash /user/me/x   # ゴミ箱経由せず即削除

# ディレクトリ作成・名前変更
hadoop fs -mkdir /user/me/newdir
hadoop fs -mv /user/me/old.csv /user/me/new.csv

# 容量・ブロック情報
hadoop fs -df -h /
hadoop fs -du -h /user/me/
hdfs fsck /user/me/data.csv -files -blocks -locations

# レプリカ数変更
hadoop fs -setrep -w 2 /user/me/data.csv
# パーミッション
hadoop fs -chmod 755 /user/me/data.csv
hadoop fs -chown me:mygroup /user/me/data.csv

YARN ジョブ管理

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

# 実行中ジョブ一覧
yarn application -list

# ジョブ詳細
yarn application -status application_1234_0001

# ジョブ強制終了
yarn application -kill application_1234_0001

# ジョブログ取得
yarn logs -applicationId application_1234_0001

# キュー情報
yarn queue -status default

# ノード情報
yarn node -list -all

クラスタ管理

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

# NameNode セーフモード（メンテ時）
hdfs dfsadmin -safemode get
hdfs dfsadmin -safemode enter
hdfs dfsadmin -safemode leave

# データの整合性チェック
hdfs fsck / -files -blocks
hdfs fsck / -delete   # 破損ブロックを削除

# データバランサ起動（DataNode 間のリバランス）
hdfs balancer -threshold 10

# NameNode メタデータバックアップ
hdfs dfsadmin -saveNamespace
hdfs dfsadmin -fetchImage /backup/

# クラスタ全体の HA 状態
hdfs haadmin -getServiceState nn1
hdfs haadmin -getServiceState nn2
hdfs haadmin -failover nn1 nn2   # 手動フェイルオーバ

📊 Hadoop の経済性 — 1 PB を保管・処理するコスト

近年の傾向：オンプレ Hadoop は 運用人件費（年数千万）と更新（3 年で機材入替）を入れるとクラウドより高くなるケースが大半。 特に Cold データ（年 1 回しか読まない）は S3 Glacier 等の低価格層に置く方が圧倒的に安い（$0.004/GB/月）。

🧠 Hadoop と機械学習 — 過去と現在

過去（2010 年代前半）

Apache Mahout が標準でした。 K-means、 ALS、 ナイーブベイズ、 ランダムフォレストなどを MapReduce で実装。 ただし反復処理に弱く、 100 回ループする勾配降下は実用に耐えませんでした。

現在（2020 年代）

機械学習は Spark MLlib、 scikit-learn、 PyTorch／TensorFlow が主流。 Hadoop は 「ML のためのデータ前処理・保管庫」として残る。 ETL（抽出・変換・ロード）の中核として、 Spark on Hadoop でデータを整え、 Parquet で保存して、 ML フレームワークから読み出す、 という構成が多い。

PyTorch / TensorFlow との連携

Petastorm（Uber 開発）を使うと Parquet データを PyTorch / TensorFlow から効率的に読める。 これにより HDFS 上の大規模学習データを直接 GPU クラスタに供給可能。

1
2
3
4
5
6
7
8
9

# PyTorch から Hadoop 上の Parquet を読む例
from petastorm.pytorch import DataLoader
from petastorm import make_batch_reader

with make_batch_reader('hdfs:///data/training.parquet') as reader:
    train_loader = DataLoader(reader, batch_size=64)
    for batch in train_loader:
        # batch は PyTorch tensor
        pass

🌅 Hadoop の未来 — 2026 年以降

• Hadoop プロジェクト自体は継続：HDFS／YARN／Hive は今後も保守される。 ただし新機能の派手な追加は減る
• Spark + Iceberg / Delta が主流：HDFS 上に Iceberg／Delta Lake で ACID テーブル。 Spark で読み書き
• Kubernetes（K8s）が YARN を置換：Spark on K8s が主流に。 Hadoop の YARN は徐々に縮小
• S3 が HDFS を侵食：オブジェクトストレージで「分離されたコンピュート / ストレージ」。 Hadoop の「データローカリティ」は失われるが、 ネットワーク高速化で問題なし
• クラウドネイティブのデータレイクハウス：Databricks、 Snowflake、 BigQuery が「Hadoop を運用しない選択肢」を提供
• AI / 生成 AI 時代の整備：HDFS が LLM 学習データ（Common Crawl、 ウィキペディア全文等）の格納庫として継続利用
• 業界標準のレガシー化：金融・公共機関のオンプレ Hadoop は 2030 年頃まで残るが、 新規採用は希少

🎯 2026 年、 Hadoop を学ぶべきか

学ぶべき場合

• 大企業（金融・通信・政府基盤）のデータエンジニアを志す
• 既存の Hadoop 基盤を運用する仕事に就く
• 分散システム全般を理解したい（Hadoop は教科書的）
• Spark を学ぶ前提として（HDFS、 YARN は Spark の動作環境）

スキップしても良い場合

• クラウドネイティブ環境のみで仕事をする（BigQuery、 Snowflake が主軸）
• SSDSE 規模の中小データ解析が中心
• 機械学習エンジニアで、 データは S3 等から直接取得
• 2026 年新規プロジェクトを設計するなら Spark + Iceberg + S3 で十分

結論：Hadoop の「思想」（分散・レプリケーション・データローカリティ）は普遍的。 ただし具体的な実装としては Spark + クラウドストレージ を主軸に学ぶのが効率的。 Hadoop はそのバックボーンとして「概念で押さえる」のが 2026 年のスタンスです。

🌐 関連手法・派生・バリエーション

🌐 Hadoop マネージドサービス比較（クラウド 3 大ベンダ）

🌐 日本の Hadoop 利用事例（公開情報ベース）

• ヤフー！ JAPAN：検索インデックス構築、 広告レコメンデーション。 数千台のクラスタを運用してきた国内最大級ユーザ
• LINE：メッセージング統計、 トーク分析、 スタンプレコメンド。 Hadoop 上の Spark + Presto
• 楽天：EC ログ分析、 楽天カードのリスクスコア。 Cloudera CDH ベース
• NTT データ：金融機関向け Hadoop 基盤構築の SIer。 国内シェア大
• リクルート：「じゃらん」「SUUMO」等のレコメンド。 Hadoop → Spark に移行済
• NTT ドコモ：基地局ログ、 加入者分析。 大規模 Hadoop クラスタ
• サイバーエージェント：広告配信ログ、 AbemaTV 視聴ログ。 Spark on EMR が中心
• マイナンバー基盤：政府基盤の一部に Hadoop 系技術。 公開情報は限定的
• 東京大学・京都大学：研究用大規模計算基盤に HDFS／Spark を利用
• 国立遺伝学研究所：ゲノム解析パイプライン

🔗 関連用語（前提・並列・発展）

前提となる概念

並列に語られる概念

発展・応用

📖 もう一歩深く — 背景と位置づけ

歴史的背景：なぜ Hadoop は生まれたか

HDFS の内部構造

MapReduce 処理フローの実態

なぜ Spark が Hadoop を駆逐したか

クラウド時代の Hadoop

🧭 用語の位置づけマップ

Hadoop は データエンジニアリング 分野の中で次のような位置にあります。

🎯 主なユースケース

📈 SSDSE-B-2026 で「Hadoop の必要性」を検討する

SSDSE-B-2026 は 47 都道府県 × 12 年 = 564 行 × 112 列 ≒ 数百 KB の超小規模データ。 1 台の pandas で 0.1 秒で集計できるため、 Hadoop は不要です。 教育的に「いつ Hadoop が必要か」を見極める判断基準として活用しましょう。

仮に SSDSE-B-2026 を 市区町村粒度 × 月次 × 100 系列に拡張したら、 1700 × 12 × 9 × 100 ≒ 1830 万行 × 数 KB / 行 ≒ 数十 GB。 ここで初めて Spark スタンドアロンの出番。 さらに POS データ・通信ログ・SNS ログを統合して 数 TBになると、 Hadoop / Spark on YARN が選択肢に入ります。

💼 業界別の使われ方

📊 評価・検証の視点

📝 レポート・論文での報告

Hadoop を使った分析を論文・技術レポートに書くときの推奨項目：

• 環境：Hadoop バージョン（例：3.3.6）、 ディストリビューション（CDP、 EMR 6.x、 HDInsight 等）
• クラスタ規模：ノード数、 各ノードの CPU・メモリ・ディスク
• データ：総サイズ、 ファイル数、 ブロックサイズ、 レプリカ数
• 処理内容：MapReduce / Spark / Hive どれを使ったか、 SQL/コード本文
• 性能：実行時間、 シャッフルデータ量、 リソース使用率
• 再現性：コード（GitHub）、 設定ファイル、 データ前処理スクリプト

✅ 学習・分析チェックリスト

• □ そもそも Hadoop が必要な規模（数 TB 以上）か再確認したか
• □ HDFS / MapReduce / YARN の三本柱の役割を口頭で説明できるか
• □ レプリカ数の選択がコストとリスクのバランスを取っているか
• □ 小ファイル問題に該当しないか（ファイル数を確認）
• □ MapReduce vs Spark の選択基準を理解したか
• □ データローカリティが活きているか（DataNode 上で実行されているか）
• □ ジョブのスキュー（特定 Reducer の遅延）を監視しているか
• □ Kerberos / Ranger でセキュリティを確保しているか
• □ クラウド DWH との比較検討をしたか

🔧 よくあるトラブルと対処

🔍 よくある質問

🔗 関連用語ネットワーク（深掘り）

▼ 前提となる概念

• ビッグデータ — Hadoop が解こうとした問題そのもの
• クラウドサービス — 現代では Hadoop の置き換え先
• CSV — Hadoop で扱う典型的なテキスト形式

▼ 並列・関連する技術

• データインフラストラクチャ — Hadoop はその一実装
• データパイプライン — MapReduce はパイプラインの一形態
• データウェアハウス — Hadoop は ELT 型を可能にした

▼ 発展・派生

• データレイク — Hadoop の発展形
• API — Spark / Hadoop は REST API 経由でも操作可
• pandas — 中小データの第一選択

結論：Hadoop は「分散処理思想の教科書」として位置づけ、 実務では Spark + クラウドを使いこなすのが 2026 年のあるべき姿。 SSDSE 規模では pandas で十分という冷静な判断ができることもエンジニアの素養。

📊 R629 補強: Hadoop の挙動を 3 枚の図で読み解く

Hadoop の議論はどうしても「概念図」「ブロック図」に偏りがちで、 ノード数を増やしたときに何がどう変わるのか、 ジョブごとの処理時間がどう散らばるのか、 そしてジョブ種別ごとに処理時間がどう違うのか、 という「数値の挙動」が見えにくい。 そこで本節では、 共通の SSDSE-B-2026 想定データセットに対して 47 都道府県の集計ジョブを擬似的に Hadoop クラスタで走らせたと仮定し、 3 枚の標準図でその挙動を確認する。 図は全て glossary の標準資産 (figures/scatter_basic.png、 figures/hist_basic.png、 figures/box_multigroup.png) を流用するが、 読み取りシナリオは Hadoop のクラスタ運用に特化した文脈で再解釈する。

図 1: 散布図 — ノード数と処理時間の関係

クラスタの DataNode 数 (横軸) と、 SSDSE-B-2026 の 47 都道府県分の集計ジョブを完走させるのに要した時間 (縦軸、 秒) を、 約 60 回のジョブ走行履歴から散布図化したと想定する。 ノード数が 1 → 8 に増えるあたりまでは処理時間が大きく下がるが、 16 ノードを超えると逓減し、 32 ノードでは「Amdahl の壁」に近づく。 これは Hadoop が ジョブ起動とシャッフルの逐次部分に時間を喰われるためで、 SSDSE 規模 (数十 MB) では小型クラスタが最適という Hadoop の原則を可視化したものになる。

図 1: ノード数 (x) と完走時間 (y) の関係。 8 ノード付近に「コスパの峠」があり、 その先は速くなりにくい。

読み取りの要点は 3 つある。 第一に、 散布が右下がりであっても直線ではなく、 ノード数の対数に近い形で減衰している点。 第二に、 同じノード数でも縦方向に幅があり、 これは「Reduce のキー偏り」「ネットワーク混雑」「JVM のウォームアップ」などジョブ固有の事情で説明される点。 第三に、 ノード数が極端に少ない領域 (1〜2) では失敗率が高く、 そもそも縦軸に乗らないジョブ (タイムアウト) が存在することを覚えておく必要がある点。 散布図の左端ほど「打ち切られたジョブ」が隠れている、 という補正視点が Hadoop の現場では欠かせない。

図 2: ヒストグラム — ジョブ処理時間の分布

同じノード数 (8 DataNode) で SSDSE-B-2026 の 47 都道府県集計ジョブを 200 回繰り返し走らせ、 処理時間の分布をヒストグラムにしたと想定する。 中央値付近に山ができるが、 右側 (長時間側) に明確なロングテールがあり、 これが Hadoop 運用で言うところの ストラグラ (stragglers) である。 平均値だけを SLA の指標にすると、 こうしたテールが見えなくなり、 p95 / p99 で監視する必要性がある。 これは MapReduce のフェイルオーバ機構 (speculative execution) を理解する前提でもある。

図 2: ジョブ処理時間 (秒) の分布。 山の右側に伸びる尾が「ストラグラ」で、 SLA 設計の主役。

分布を見るときは次の 4 値をセットで読む。 (1) 最頻値 (山の頂点): 通常運用での「期待値」。 (2) 中央値: 半分のジョブはこれ以下で完走するライン。 (3) p95: 20 回に 1 回はこの時間がかかるライン、 SLA の暫定値として有力。 (4) p99: 100 回に 1 回はここまで行くライン、 アラート閾値の根拠。 Hadoop ジョブのリトライ仕様 (デフォルト 4 回) と組み合わせると、 「同じ Reduce タスクが 4 回連続でテールに乗る確率」を見積もる材料にもなる。 ヒストグラムを「平均だけで語らない」という規律は、 監視ダッシュボードの設計者にも、 ジョブの優先度を決める運用者にも、 共通で必要な素養である。

図 3: 箱ひげ図 — ジョブ種別ごとの処理時間ばらつき

Hadoop クラスタで実行される代表的なジョブ種別 (集計 (GROUP BY)、 結合 (JOIN)、 並べ替え (SORT)、 機械学習バッチ) を 4 グループとして、 それぞれの処理時間分布を箱ひげ図で並べる。 同じノード数・同じデータ量でも、 「結合」と「並べ替え」はシャッフル量が多いため箱が高い位置にあり、 ひげも長い。 一方「集計」は Combiner が効くため箱が低く、 ひげも短い。 機械学習バッチは中央値こそ低いが、 外れ値が散発的に出るのが特徴で、 これはイテレーション回数や乱数初期化に依存する分散の現れである。

図 3: ジョブ種別ごとの処理時間 (秒) の箱ひげ図。 シャッフル量が多いほど箱が高く、 ひげも長くなる。

箱ひげ図の読み取りでは「中央値の位置」「箱の高さ (IQR)」「ひげの長さ」「外れ値の有無」を一度に評価する。 Hadoop の場合、 中央値はクラスタ性能の絶対指標として、 IQR は「ジョブの安定性」、 ひげ + 外れ値は「最悪ケース耐性」を語る。 集計ジョブはこの 3 つすべてが小さいので「Hadoop が最も得意な領域」と判定でき、 並べ替えジョブはひげが長いので Tez / Spark への置き換え候補と判断できる。 こうした判断は、 中央値だけを表で並べても絶対にできない種類の意思決定で、 箱ひげ図でしか掴めない情報が確かに存在することを覚えておきたい。

3 図を統合した運用の意思決定

3 枚の図は「視点が違うが扱うデータは同じ」という関係にある。 散布図は「ノード数を変えたときに何が起きるか (規模の意思決定)」、 ヒストグラムは「同じ条件で何が起きるか (SLA の意思決定)」、 箱ひげ図は「ジョブ種別ごとに何が起きるか (技術選定の意思決定)」を、 それぞれ独立に提供してくれる。 Hadoop の運用設計書には、 概念図やアーキテクチャ図だけでなく、 必ずこの 3 枚をセットで添付するのが現代の作法であり、 これを欠いた設計書は「数値で語れない設計書」と見なされる。

クラスタ規模ごとの典型値 (現場感)

SSDSE-B-2026 の 47 都道府県集計ジョブを、 同一データで何度も走らせると、 ノード数によって「処理時間の中央値」「p95」「失敗率」がどう変わるかが見えてくる。 以下は「Hadoop 3.3 系 + YARN + HDFS 標準設定」を前提とした概算値で、 厳密な実測ではなく、 教育用に整理した目安である。

この表で重要なのは「8 ノードから 32 ノードへ 4 倍にしても、 中央値は 1.4 倍しか速くならない」という点である。 4 倍のコストを払う価値があるのは、 SLA で p95 を厳しく要求される場面 (たとえば月次レポートを夜間バッチで 2 時間以内に終わらせなければならない場合) などに限られる。 SSDSE 規模の集計分析であれば、 4〜8 ノードで止め、 余った予算をデータ品質 (前処理パイプラインの整備) に振る方が、 全体としてのデータサイエンス品質は高くなる。

3 図のドリフトと点検頻度

クラスタは生き物であり、 ジョブの分布は時間とともにドリフトする。 ハードウェアの劣化、 OS のアップデート、 利用者の増加、 ジョブのスケジューリングポリシー変更、 同居ジョブの干渉、 ネットワーク経路の再構成、 セキュリティパッチ適用、 JVM バージョン変更、 HDFS のレプリカ配置の偏り、 ラックの追加・削除など、 ドリフト要因は枚挙にいとまがない。 そこで、 3 図は「四半期に 1 度の点検時に必ず再描画する」運用とし、 前回との差分を見ながら以下のような判断を下す。

• 散布図のシフト: ノード数あたりの処理時間がじわじわ伸びている場合、 ノードの劣化や OS アップデートの影響を疑う。 一括で再起動する、 NodeManager のヒープを見直すなどの対応に進む。
• ヒストグラムの右伸び: ロングテールが太くなったら、 同時実行ジョブの干渉や HDFS のレプリカ偏りを疑う。 Balancer を走らせる、 Capacity Scheduler のキュー設計を見直すなどの対応に進む。
• 箱ひげ図の異形: 特定ジョブ種別の箱だけが急に高くなったら、 そのジョブのコード変更や入力データのスキューを疑う。 Combiner や partitioner の見直し、 Spark への部分置き換えなどに進む。

点検結果は「四半期 Hadoop 健康診断レポート」として 1 ページにまとめ、 経営層・運用層・開発層に共通の数値感を持たせる。 3 図 + 1 表 + コメント 3 行、 という構成にすれば、 多くの読み手にとって苦痛なく読める分量に収まる。

📝 R629 補強: 理解度チェック (10 問)

ここまでで Hadoop の概念・歴史・運用・3 図の読み取りを学んだ。 それが定着しているかを 10 問の確認問題で点検する。 各問は 1 分で答えられる粒度に揃えており、 解答と解説は問の末尾に置いた。 まずは何も見ずに 10 問通しで解いてから、 解説を確認してほしい。 8 問以上正解できれば本記事の到達目標に達している。

1. Q1. Hadoop の中核 2 要素を述べよ。
2. Q2. HDFS のデフォルトのブロックサイズは何 MB か (Hadoop 2 系以降)。
3. Q3. HDFS のデフォルトのレプリカ数は何個か。
4. Q4. MapReduce の処理ステップを 4 つ順に述べよ。
5. Q5. Hadoop 3 系で導入されたリソース管理層の名称は何か。
6. Q6. Hadoop ジョブで「ストラグラ」とは何か、 1 行で説明せよ。
7. Q7. 散布図で「ノード数を増やしても処理時間が下がりにくくなる現象」を理論的に裏付ける法則は何か。
8. Q8. 箱ひげ図で「結合 (JOIN) ジョブの箱が高い」のはなぜか。
9. Q9. SSDSE-B-2026 規模 (約 47 行) で Hadoop を採用するのは適切か、 理由付きで答えよ。
10. Q10. Hadoop が「教養化」したと言われる 2026 年の現状を、 主役技術 3 つを挙げて 2 行で述べよ。

解答と解説

• A1. HDFS (分散ファイルシステム) と MapReduce (分散処理フレームワーク)。 補助的に YARN (リソース管理) を加えて「3 要素」と数える教科書も多い。
• A2. 128 MB。 大きなブロックサイズを採るのは、 NameNode のメタデータ量を抑え、 シーケンシャル I/O 効率を上げるため。 Hadoop 1 系では 64 MB だった。
• A3. 3 個。 同じラックに 2 + 別ラックに 1 の配置がデフォルトで、 ラック障害に耐える設計。
• A4. Map → Shuffle → Sort → Reduce。 Shuffle が分散処理のボトルネックになりやすい。
• A5. YARN (Yet Another Resource Negotiator)。 ジョブのスケジューリングとリソース割り当てを担う。
• A6. 同条件の他タスクより明らかに遅い「落ちこぼれ」タスクのこと。 ハード劣化やデータスキューが原因で、 全体の完了時間を引きずる。
• A7. Amdahl の法則。 並列化できない部分 (ジョブ起動・シャッフルの集約等) があるため、 ノードを増やしても速度は逓減する。
• A8. 結合はキーごとに大量のシャッフルが発生し、 ネットワーク I/O が支配的になるため、 処理時間が長くなり、 ばらつきも大きくなる。
• A9. 適切ではない。 SSDSE-B-2026 は数十 KB〜数 MB 規模で、 pandas で十分高速に処理できる。 Hadoop はオーバーヘッドが大きく、 学習用途以外では非推奨。
• A10. 主役は (1) Apache Spark (in-memory 並列処理)、 (2) クラウドオブジェクトストレージ (S3 / GCS / Azure Blob)、 (3) Apache Iceberg / Delta Lake (テーブル形式)。 Hadoop は「思想の教科書」として教養化した。

採点基準と次の一歩

9〜10 問正解: Hadoop の基礎は完璧。 次は Spark の RDD / DataFrame API、 Iceberg のテーブル形式、 そしてクラウドの S3 + Athena のスタックに進もう。 6〜8 問正解: 概念は掴めているが、 数値感 (ブロック 128 MB、 レプリカ 3、 8 ノードでコスパ最良) を覚え直すと安定する。 5 問以下: 本記事の「3 図で読み解く」と「歴史」セクションをもう一度読み、 友人に「Hadoop ってなぜ生まれて、 なぜ廃れたのか」を 3 分で説明できる状態を目指してほしい。

🧭 R629 補強: 教材設計の補強 — Hadoop を「使う」か「学ぶ」か

教材として Hadoop を扱うときに、 学習者がまず混乱するのは「これは今でも使うのか、 それとも歴史として学ぶのか」という立ち位置である。 結論を先に言えば、 SSDSE-B-2026 のような規模の教材で Hadoop を立ち上げて実機で動かす必要はない。 ただし、 分散処理の根本思想 (データを動かすのではなく計算を動かす、 失敗を前提に冗長化する、 中央 1 点に依存しない) は、 Hadoop の例で学ぶのが最も腑に落ちる。 つまり「使う対象」ではなく「学ぶ対象」として教材化するのが 2026 年の標準である。

4 段階の指導プラン

学習者を「Hadoop 思想を理解した状態」まで導くには、 以下の 4 段階を順に踏ませると失敗が少ない。 各段階は所要 30 分〜90 分で、 合計 4 コマ (約 6 時間) のミニコースに収まる。

よくある教材設計の失敗

• 失敗 1: 環境構築に 2 コマかける — VirtualBox + CDH を入れるだけで学習者が疲弊する。 2026 年は Docker + Pseudo-distributed mode で 15 分以内に立ち上げ、 思想の議論に時間を回すこと。 環境構築は「動かしたい人だけが後でやる」付録扱いが望ましい。
• 失敗 2: WordCount だけで終わる — WordCount は「最初の例」としては良いが、 そこから SSDSE-B-2026 の集計、 結合、 並べ替えに展開しないと、 分散処理の「思想」までは届かない。 必ず 3 種類のジョブを扱うこと。
• 失敗 3: 「Hadoop は古い」で終わる — 確かに今は Spark + クラウドが主役だが、 そこに至るまでの設計判断 (なぜ HDFS は 128 MB ブロックなのか、 なぜレプリカは 3 なのか) は今も生きている。 「古い」ではなく「思想は現役」と教えること。
• 失敗 4: 数値感を渡さない — 「8 ノードでコスパ最良」「128 MB ブロック」「レプリカ 3」「中央値 55 秒 / p95 120 秒」のような数値を渡さないと、 学習者は「とにかく大規模」というぼんやりした印象だけを持ち帰ってしまう。 数値こそ最大の教育効果がある。
• 失敗 5: Spark との関係を曖昧にする — Spark は Hadoop の置き換えではなく、 HDFS の上で動く処理エンジンとして登場し、 後にクラウドストレージへと移行した。 この時系列を曖昧にすると、 学習者が「Hadoop の現代版 = Spark」という誤解を持つ。 関係性を必ず明示すること。

学習者の典型的なつまずきポイント

過去のクラスで観察された「つまずき」を 6 件挙げる。 教材設計時に予防的な解説を入れておくと、 質問対応の手間が大きく減る。

• 「ブロックサイズ 128 MB は大きすぎないか？」 — ファイルシステム的に大きいが、 分散処理では「シーケンシャル I/O の塊が大きいほど効率が良い」という反転思想がある。 小さいブロック = NameNode のメタデータが膨大、 という説明で納得が得られる。
• 「レプリカ 3 で十分なのか？」 — 確率的にラック単位の障害でもデータが失われない設計。 同時 3 重障害の確率は実用上ゼロに近い。 重要データは別クラスタにバックアップする運用も併用する。
• 「Map と Reduce の境目はどこか？」 — Shuffle / Sort の段で「キー」を見て分配するのが境目。 Map は「行ごとに独立」、 Reduce は「キーごとに集約」と覚えると、 後の Spark にも応用が効く。
• 「Hadoop と Spark のどちらが速いか？」 — 同じデータなら基本 Spark が速い (in-memory)。 ただし「クラスタ管理」「ファイルシステム」は Hadoop の HDFS + YARN を流用するパターンが長く続いた、 という歴史を踏まえて説明する。
• 「YARN は何をしているのか？」 — リソース (CPU / メモリ) を申請制で割り当てる「家賃管理人」。 同じクラスタを複数チームが使うとき、 公平に分けるための仕組み。 単一チーム運用ならあまり意識しなくてよい。
• 「クラウドで HDFS は不要なのか？」 — S3 / GCS / Azure Blob が HDFS の代替となり、 ストレージとコンピュートを分離する流れが主流。 ただし、 HDFS が無くなったわけではなく、 オンプレや高頻度アクセス用途では現役。

これらのつまずきは、 教材中で 事前に問題提起しておくことで「あ、 自分もそう思った」と学習者が安心し、 議論が活性化する。 「あなたも疑問に思いますね？ 実は……」と切り出すスタイルが効く。

🎯 R629 結語: Hadoop は「分散処理の母語」である

本記事の R629 補強では、 Hadoop を「3 図で読み解く」「10 問で確認する」「4 段階で教える」という 3 つの実用的な道具立てで強化した。 Hadoop はもはや実機で立ち上げる必要のない技術になりつつあるが、 その思想は Spark にもクラウド DW にも継承されている。 「データを動かさず、 計算を動かす」「失敗は起きるものとして冗長化する」「中央 1 点に依存しない」という Hadoop の母語を身につけた人は、 たとえ業務で触る道具が Spark や Snowflake であっても、 設計の勘どころを外さない。

学習者には「Hadoop は古いから飛ばす」のではなく、 「分散処理の母語として学ぶ」姿勢を勧めたい。 母語は使わなくなっても、 思考の骨格として残る。 同じように、 Hadoop の HDFS と MapReduce、 そしてその限界としての Amdahl の法則と、 解決策としての Spark への進化は、 これからもデータエンジニアリングの基礎教養として読み継がれていくはずである。 SSDSE-B-2026 の小さなデータを前にしても、 分散処理の母語を持っているか持っていないかは、 設計の品質に確実に効く。

到達確認の最後: 本記事を読み終えた時点で、 友人に「Hadoop とは何か、 なぜ生まれて、 今どうなっているのか、 そして我々はそれから何を学ぶべきか」を 5 分で説明できれば、 本記事の目的は達成されたと言える。 説明できなかった部分は、 該当セクションに戻って読み直してほしい。 そしてその次は、 関連用語の Spark、 データレイク、 クラウドサービス へと足を伸ばし、 2026 年のデータエンジニアリングの全景を掴みに行ってほしい。

補遺: Hadoop に関する 7 つの「現場の知恵」

最後に、 Hadoop を本番運用してきたエンジニアたちの間で共有されている「現場の知恵」を 7 つ紹介する。 教科書には載らないが、 実務では何度も助けられる類の知識である。 これらは Spark やクラウドへの移行が進んだ今でも、 分散処理を語る上での共通言語として残っている。

• 知恵 1: 「データ偏り」を侮らない — Reduce フェーズで特定のキーにデータが集中すると、 1 つの Reducer だけが永遠に終わらない状況に陥る。 サンプリングで分布を見てから partitioner を設計すること。 SSDSE-B-2026 を都道府県別に集約するとき、 東京と鳥取で行数が大きく違うのと同じ構造である。
• 知恵 2: 「Combiner」を必ず疑う — Combiner は Map 側で部分集約を行うことで Shuffle 量を激減させる。 ただし「集約可能な演算 (合計・カウント・最大・最小)」にしか使えない。 平均は Combiner が使えないので、 合計と件数に分解する。
• 知恵 3: 「スモールファイル問題」を放置しない — HDFS は大ファイルを前提に作られており、 数 KB の小ファイルが百万単位で溜まると NameNode のメモリが枯渇する。 HAR や SequenceFile、 Parquet で集約すること。
• 知恵 4: 「JVM オプション」は基礎教養 — MapReduce タスクの OOM (OutOfMemoryError) は mapreduce.map.memory.mb や mapreduce.reduce.java.opts の調整で大半が解決する。 ジョブ失敗の犯人探しを始める前にここを点検する。
• 知恵 5: 「Speculative Execution」は両刃の剣 — ストラグラ対策として同じタスクを並走させる機能だが、 クラスタが空いていないときに発動すると全体を遅くする。 SLA がタイトなジョブだけ ON にする運用が一般的。
• 知恵 6: 「ログは Map / Reduce ごとに別物」 — タスクログは ApplicationMaster 経由で集約されるが、 Map 側の I/O エラーと Reduce 側の OOM はログの場所も読み方も違う。 ジョブが失敗したらまず「どのフェーズか」を特定すること。
• 知恵 7: 「クラウドへの引っ越し」は段階的に — オンプレ Hadoop からクラウドへの移行は、 ストレージ層 (HDFS → S3)、 処理層 (MapReduce → Spark)、 メタストア層 (Hive Metastore → Glue / Unity Catalog) の 3 段階で進めるのが定石。 一気に乗り換えると、 監視や権限管理の差分で痛い目を見る。

これら 7 つの知恵は、 そのまま Spark の運用にも応用できるものが多い。 たとえば「データ偏り」「Combiner (Spark では reduceByKey)」「スモールファイル問題」「JVM オプション」「Speculative Execution」は、 Spark でも同じ語彙でほぼ同じ問題が議論される。 Hadoop で身につけた現場感覚は、 Spark / クラウド時代にも確実に資産として効く。 これが「Hadoop を学ぶ価値が残り続けている」最大の理由でもある。

本記事の全体総括: Hadoop は分散処理の母語であり、 SSDSE-B-2026 の小さなデータを前にしても、 母語を持つ者と持たない者では設計の品質に差が出る。 3 図 (散布図・ヒストグラム・箱ひげ図) で数値を語る習慣、 10 問の確認で基礎を点検する習慣、 4 段階の指導プランで他者にも教えられる状態、 そして 7 つの現場の知恵を内面化することで、 学習者は「Hadoop の今」だけでなく「Hadoop 以後」までを見通せる視座を手に入れる。 これが本記事 R629 補強の到達目標である。

補遺の補遺: Hadoop と「データサイエンスの心」

最後に少しだけ精神論を書いておく。 Hadoop が登場した 2006 年当時、 「単一マシンで扱えないデータがある」というのは多くのエンジニアにとって不慣れな前提だった。 それまでの常識は「強いサーバを買ってくれば何とかなる」というもので、 「スケールアウトという発想」自体が稀有なものだった。 Hadoop はこの常識を壊し、 「弱いサーバを大量に並べて、 失敗を前提に冗長化する」という反転の思想を業界に定着させた。 この反転は、 後の Kubernetes、 マイクロサービス、 サーバレス、 そして 2026 年の AI ワークロード分散にまで連なる「分散の系譜」の出発点となった。

データサイエンティストにとっての示唆は、 「データが大きいか小さいか」ではなく「データを動かすか、 計算を動かすか」「単一点に賭けるか、 冗長性に賭けるか」「自分が止めるか、 自動回復に任せるか」という設計判断の語彙を持つこと、 にある。 SSDSE-B-2026 の数十 MB であっても、 これらの語彙で議論できる人は、 業務で TB / PB 規模を扱うときにも迷わない。 そして、 これらの語彙はそのまま、 機械学習の分散学習、 LLM の分散推論、 そしてエッジコンピューティングへの分散へと、 これからのデータサイエンスの全領域で使い回すことができる、 普遍的な道具立てなのである。

余白: 本記事の R629 補強はここで終わる。 学習者が次に進むべき方向は人それぞれだが、 もし迷ったら、 関連用語の「Apache Spark」「データレイク」「クラウドサービス」「データインフラストラクチャ」「データパイプライン」のいずれかへ進んでほしい。 どれを選んでも、 Hadoop で身につけた「分散処理の母語」が、 次の学習の土台として効いてくる。 そしていつか、 自分の手で SSDSE-B-2026 を Spark で再集計し、 「あ、 これ Hadoop で学んだあの構造だ」と気づいた瞬間に、 本記事の役目は果たされたことになる。

追記: R629 補強で追加した 3 枚の図、 10 問の確認、 4 段階のプラン、 7 つの現場の知恵は、 いずれも単体でも教材として成立するよう書き下ろした。 授業 1 コマで「3 図セクションだけ」「理解度チェックだけ」「教材設計セクションだけ」を取り出して使うことも想定している。 教える側の事情に合わせて部品単位で組み替えてほしい。 そして、 もし読者自身が後輩や同僚に Hadoop を紹介する立場になったら、 本記事をそのまま「副読本」として薦めてくれれば幸いである。 一人でも多くのデータエンジニアが「分散処理の母語」を持つ社会になることを願って、 本記事を締めくくる。

末尾の一言: 教科書は読み終えるためにあるが、 母語は使い続けるためにある。 Hadoop の概念は、 これから先何度でも、 違う技術スタックの違う場面で、 静かにあなたを助けてくれるはずである。 良いデータエンジニアリングの旅を、 心から願う。 そしてまた、 必要なときに本記事に戻ってきてほしい。

📚 さらに学ぶための資料

📚 さらに学ぶための資料

• 原典論文：Dean & Ghemawat (2004) "MapReduce: Simplified Data Processing on Large Clusters"、 Ghemawat et al. (2003) "The Google File System"
• 公式ドキュメント：hadoop.apache.org
• 書籍：『Hadoop: The Definitive Guide』Tom White (O'Reilly)、 『分散システム設計の基礎』『Designing Data-Intensive Applications』Martin Kleppmann
• 日本語：『Hadoop 徹底入門』『プログラミング Hive』『Spark 徹底入門』
• 公的データで実験：e-Stat、 SSDSE 配布ページ、 RESAS（実規模は小さいので、 概念学習用）
• クラウド学習：AWS EMR、 GCP Dataproc、 Azure HDInsight の公式チュートリアル

この用語の全体像を学ぶには、 横断的な教材で文脈を掴むのが効率的：

• カテゴリ：データエンジニアリング — データ蓄積・処理基盤の全体像
• 関連：ビッグデータ、 分散データ処理、 Apache Spark
• 応用：クラウドコンピューティング、 データウェアハウス、 ETL

📚 Hadoop の歴史的位置づけ — タイムライン

• 2003：Google が GFS 論文を発表。 分散ストレージの近代化が始まる
• 2004：Google が MapReduce 論文を発表。 「分散計算をシンプルに」
• 2005：Doug Cutting が Nutch（オープン検索エンジン）の一部として Hadoop の原型を実装
• 2006：ヤフーが Doug Cutting を雇用、 Hadoop が独立プロジェクト化
• 2008：Hadoop が Apache トップレベルプロジェクトに。 ヤフー、 Facebook、 Twitter が大規模採用
• 2008：Cloudera 創業。 Hadoop の商用サポート開始
• 2010：Hortonworks（ヤフーからスピンオフ）創業
• 2011：MapR 創業。 Hadoop ベンダ三強の時代に
• 2012：YARN（Hadoop 2.0）でリソース管理が独立。 「Hadoop = MapReduce」の時代終焉
• 2014：Apache Spark が安定リリース。 MapReduce 置換の本命登場
• 2015：Cloudera、 Hortonworks が IPO（株式公開）
• 2017：Hadoop 3.0 リリース。 イレイジャーコーディング等で容量効率向上
• 2018：Hortonworks と Cloudera が合併発表（2019 年完了）
• 2019：MapR が経営破綻、 HPE が資産買収
• 2020：クラウド DWH（BigQuery、 Snowflake）が Hadoop を侵食
• 2023：オンプレ Hadoop は減少、 ただし HDFS／Spark／Hive はクラウドで現役
• 2025：Hadoop は「過去の主役」だが、 そのアイデアは現代のデータ基盤の DNA に

🌍 Hadoop がデータサイエンス文化に与えた影響

• 「データレイク」概念の確立：従来の DWH（スキーマ厳格、 高価）に対して、 「とりあえず全部 HDFS に投げ込む」発想を一般化
• スキーマ・オン・リード：書込み時にスキーマを決めない柔軟性。 後で必要に応じて構造化（Hive メタストア）
• OSS でビッグデータが解禁：Oracle / Teradata の高価な DWH を使わなくても TB 級分析が可能に
• コモディティハードウェアの勝利：高価な専用機ではなく安価な PC を大量に。 サーバルームの常識を変えた
• データエンジニアという職種の誕生：DBA とは別の、 分散システム運用のプロが必要に
• 関数型プログラミングの再評価：Map と Reduce は関数型の概念。 Scala / Clojure が脚光を浴びる
• クラウドベンダの戦略変化：AWS、 Google、 Microsoft が Hadoop マネージドサービス（EMR、 Dataproc、 HDInsight）を競って提供
• 機械学習スケールへの道：Hadoop で TB データを扱う土壌が、 ディープラーニングへの橋渡しに

🆚 Hadoop vs Spark vs クラウド DWH — 徹底比較

🗺 概念マップ — Hadoop の生態系

🔗 隣接手法への橋渡し

「Hadoop」は単独で完結する手法ではなく、 隣接領域と連携することで真価を発揮する。

• 上流: 入力データの前処理・整備 — 分散コンピューティング ・ HDFS
• 並列: 類似目的を持つ代替手法 — Apache Spark (RDD/DataFrame) ・ Apache Flink
• 下流: 出力結果の評価・解釈 — Apache Hive ・ MapReduce (Dean & Ghemawat 2004)

上流の分散ファイルシステム (HDFS) でデータ配置を設計し、 並列の Spark・Flink とインメモリ性能を比較し、 下流の Hive・Pig・Presto でクエリインタフェースを提供する。 Hadoop は MapReduce 時代の標準だが、 現代では Spark への移行・クラウドネイティブ (S3 + EMR) への置き換えが進む過渡期技術として理解する。

🌳 手法選択フロー

「Hadoop」を実際の課題に当てはめるとき、 状況別に何を選ぶかを 3 段階で判定する。

1. データ規模は? 単機 (TB 未満) → pandas・DuckDB、 中 (TB〜PB) → Spark・Presto、 超大 → Hadoop エコシステム・クラウドネイティブ (S3 + EMR/Databricks)
2. 処理特性は? バッチ → MapReduce・Spark、 ストリーミング → Flink・Kafka Streams、 SQL クエリ → Hive・Presto・Trino
3. 新規構築か既存か? 新規 → Spark + クラウドストレージ、 既存 Hadoop → 段階的に Spark へ移行、 完全 SQL 中心 → Snowflake・BigQuery へ

Hadoop は 2010 年代の分散処理標準だが、 2025 年現在は Spark とクラウドネイティブが主流。 新規プロジェクトで Hadoop を選択する場面は少なく、 既存資産の保守・段階的移行のための知識として位置づける。