AWSとGoogle CloudとHadoop（やその元になったGoogleサービス）を対比。
Amazon S3 ≒ Google Cloud Storage ≒ オンプレ（HDFS / GFS）
巨大なデータを、安価に、壊れないように保存するための仕組み。
安価な構成: 特別な高級ハードウェアではなく、普通のハードウェア（サーバーやハードディスク）を大量に並べて巨大な保存スペースを作る。
自動バックアップ: どこかのハードディスクが1台や2台壊れてもデータが消えないよう、自動的にデータを3つ以上の場所にコピーして保存する仕組み（レプリケーション）を持っている。
| 特徴 | Amazon S3（AWS） | Storage（Google Cloud） | オンプレ（GFS / HDFS） |
|---|---|---|---|
| 実体 | AWSが管理する、インターネット経由の「純粋なデータ保存スペース」。 | Googleが管理する、インターネット経由の「純粋なデータ保存スペース」。仕組みはS3とほぼ同じ立ち位置。 | 自分たちで用意した「サーバー（CPU＋ハードディスク）」の集まり。 |
| 拡張方法 | ユーザーは何もしなくてよい。データを入れれば入れるだけ、容量が無限に自動拡張される。 | 同様にユーザー側での容量管理は不要。データを入れれば入れるだけ自動拡張される。 | 容量が足りなくなると、サーバーを丸ごと1台買い足してネットワークに繋ぐ作業が必要。 |
| 計算方法との関係 | 保存に特化している。計算するときは、別の計算用サーバー（EC2やEMRなど）を必要な時にだけ起動してS3に接続する。 | 同様に保存に特化。計算するときは、Dataprocなど別の計算用サービスを必要な時にだけ起動してGCSに接続する。 | データを保存しているサーバーそのものに計算（MapReduceなど）をさせる。 |
Amazon EMR / AWS Glue ≒ Google Cloud Dataproc ≒ オンプレ（Hadoop MapReduce）
大量のデータを並列で処理・加工する役割
大量データの並列処理: 1台のコンピューターでは処理できないテラバイト・ペタバイト級のデータを、数百〜数千台のマシンに分散して同時に計算する。
データの変換（ETL）: 散らばった生データ（ログやCSVなど）を読み込み、きれいに整えて、分析しやすい形に変換して別の場所（S3など）に書き出す。
| 特徴 | Amazon EMR / Glue（AWS） | Dataproc（Google Cloud） | オンプレ（Hadoop MapReduce） |
|---|---|---|---|
| 処理のスピードと仕組み | EMRやGlueの主流である「Apache Spark」は、データをメモリ（RAM）上で処理するため、MapReduceより最大100倍高速。 | DataprocもSpark/Hadoopを動かせるマネージドサービスで、同じくメモリ処理のSparkが主流。ストレージはHDFSではなくGCSを使う設計。 | データを処理する際、一工程ごとにハードディスク（ストレージ）への書き込みが発生するため、処理が遅い。 |
| サーバーの管理 | EMR： 処理するときだけ自動で数百台のサーバーを起動し、終わったら消せる（使った分だけ課金）。Glue： サーバーの存在すら意識しない（サーバーレス）。 | 処理するときだけクラスターを起動し、終わったら消せる（使った分だけ課金）。さらに「Dataproc Serverless」を使えば、クラスターの管理自体が不要になる。 | 処理をするために、常に数千台のサーバーを自前で起動・維持しておく必要がある（使っていなくても電気代や管理費がかかる）。 |
Amazon DynamoDB ≒ Google Cloud Bigtable ≒ オンプレ（Apache HBase）
大量のデータから特定のデータを一瞬で読み書きするデータベース
超高速レスポンス（低レイテンシー）: データ量がペタバイト級に増えても、アクセスが1秒間に数百件〜数百万件に激増しても、常に「1桁ミリ秒（1000分の数秒）」という超高速でデータを返す。
NoSQL（キー・バリュー型 / ワイドカラム型）: 行と列でガチガチに固められた従来のRDB(SQL)とは違い、特定のキー（鍵）を指定して一直線にデータを取り出す仕組み。データの構造（項目）を後から自由に追加・変更できる柔軟性を持っている。
| 特徴 | Amazon DynamoDB（AWS） | Bigtable（Google Cloud） | オンプレ（Apache HBase） |
|---|---|---|---|
| データの管理単位（アーキテクチャ） | 進化型KVS（ドキュメント/ワイドカラム対応）：基本の骨組みは、列を後からいくらでも横に広げられるワイドカラム型（KVS）。その中にJSONのような複雑なデータの塊（ドキュメント）をそのまま丸ごと放り込める柔軟な構造に進化。 | ワイドカラム型の元祖サービス。巨大な1つのスプレッドシートのような構造で、データは「行（Row Key）」ごとにアルファベット順で並べられて管理される。 | Google BigtableをモデルにHadoopエコシステム向けに作られたOSS実装。データの並び方や設計思想はBigtableとほぼ同じ。 |
| 運用のハードル | 完全サーバーレス： データの読み書きの回数や、保存したデータ量だけで課金される。小さな個人アプリから、Amazonのプライムデーのような超巨大イベントまで自動で伸縮する。 | フルマネージドではあるが、DynamoDBほどの完全サーバーレスではなく、クラスター（ノード）を明示的に確保して動かす方式。オートスケーリング設定はできるが、自前HBase運用に比べると圧倒的に楽、という立ち位置。 | 安定して高速に動かすためには、最低でも数台（できれば数十台）のサーバー（ノード）をクラスターとして維持する必要があり、初期コストが高い。 |
キー・バリュー型（ドキュメント型）とは？
鍵（Key）と中身（Value）がペアになって保存されている、非常にシンプルなデータ構造のこと。コインロッカーのようなイメージ。
- キー（Key）： ロッカーの番号。世界に一つだけで絶対に重複しない
- バリュー（Value）： ロッカーの中に放り込まれている荷物（データ）そのもの
なぜ超高速なの？
従来の一般的なデータベース（SQL）は、Excelのように列と行が複雑に組まれており、データを検索するときは「A列が〇〇で、かつB列が××のデータを上から順番に探す…」という複雑な探索（計算）をする。そのためデータが増えると重くなる。
一方、DynamoDBのようなキー・バリュー型は、「105番のロッカーを開けて」と指示するだけ。データが100万件あろうが1億件あろうが、目的のロッカーへ一直線に向かうため、常に一瞬（1桁ミリ秒）でデータを取り出すことができるのが最大の強み。
DynamoDBは、ロッカーの中に入れる「バリュー（荷物）」の形として、JSONという書類（ドキュメント）のような複雑な階層構造のテキスト形式をそのまま丸ごと放り込める柔軟性（ドキュメント型としての特徴）を、ワイドカラムな骨組みの上に持たせている。
ワイドカラム型は、ロッカーの中にさらに細かく仕切られた小さな引き出し（カラム）が大量に並んでいるイメージ。鍵（行キー）でロッカーを開けたあと、3番目の引き出し（列）のデータだけを読み込むことができる。そして引き出しは10個だったり100個だったり、後からいくらでも横に広げる、ワイドにできるためワイドカラム型と呼ばれる。
AWSタイムライン
2006年3月：Amazon S3誕生。巨大なデータ保存庫。AWSというクラウドサービスのほぼ最初のサービスとして誕生。クラウドの歴史が始まる。
2009年4月：Amazon EMR誕生。Hadoopをクラウドで動かす基盤として登場（当時はまだMapReduce処理が全盛期）。
2012年1月：Amazon DynamoDB誕生。リアルタイムを支える超高速NoSQLデータベース。
2012年11月： Amazon Redshift誕生。大量のデータを高速で集計・分析（SQLクエリ）するための超巨大なデータベース。普通のビジネスマンやアナリストが、使い慣れたSQLでペタバイト級のデータを一瞬で集計できる。企業のデータ分析が一気に大衆化。
2016年11月： Amazon Athena誕生。S3のデータに直接SQLを投げるサーバーレス・クエリの決定版。S3に置いてあるデータ（CSVやログなど）に対して、データベースに移し替えることなく、S3にある状態のまま、直接SQLを投げて一瞬で集計できるサービス。データはあるけどわざわざデータベース（Redshift）を起動してインポートするのは面倒という常識を破壊。現在のデータレイク（S3に全部貯める）という設計思想を決定づけた主役。
2017年8月：AWS Glue誕生。サーバーの管理を不要にし、Apache Sparkなどを使ったモダンなデータ加工を自動化する、サーバーレスETLとして登場。
2017年11月： Amazon SageMaker誕生。貯まったビッグデータを使って、AI（機械学習・ディープラーニング・生成AI・LLM）のモデルを開発・学習・デプロイするためのオールインワン環境。ビッグデータの最終ゴールを、集計からAIによる予測や生成へとシフト。Glueなどできれいに加工したビッグデータを、そのままAIの学習に流し込むための心臓部。
AWSの進化
- 貯める（S3）から始まり、
- 処理する（EMR）
- 分析する（Redshift/Athena/Glue）
- AIで活用する（SageMaker）へと発展してきた
AWSでビッグデータシステムを組む場合、S3 + Glue + Redshift/Athena + SageMakerの組み合わせが王道
Amazon S3が革命的だった理由
以下の条件を、世界で初めて同時に満たしたから。
- 初期費用ゼロ、使った分だけの従量課金： 数億円の初期投資をせずとも、クレジットカード1枚で使い始められる。
- API（ネット経由）での全自動操作： 人間がサーバーをセットアップするのではなく、プログラム（HTTPリクエスト）から一瞬でデータを保存・取得できる。
- 容量が最初から「実質無限」： ユーザー側で「来年はデータが何ギガ増えるか」を予測してハードディスクを買い足す必要がなくなった。
AWS誕生の経緯
IT革命があって、ビッグデータが溢れるようになって、GoogleとYahoo!が頑張って、Hadoopが生まれたから。
詳しくはこれ → 書籍『AI 70年：思考する機械からChatGPTへの道のり』