■ 1. 主張の概要
- 「ビッグデータ」時代は終わりを迎えつつある
- データ規模の問題を理由にした新技術への投資は、多くの場合で実際の問題を解決しなかった
- 現在は、データサイズではなくデータをどう活用するかに焦点を移すべき時代にある
- 本記事の根拠はBigQueryのクエリログ、顧客対応、ベンチマーク結果、業界アナリストとの対話などに基づく
■ 2. 著者の背景
- Google BigQueryの創設エンジニアであり、ビッグデータ普及の推進者として世界中の会議で講演を行った
- 2018年にプロダクトマネジメントに転身し、顧客との対話と製品メトリクス分析を担当した
- BigQueryの利用実態を分析する中で、「ビッグデータ」を持たないユーザーが大多数であることを発見した
■ 3. ほとんどの組織はビッグデータを持っていない
- BigQueryの顧客データ:
- 大多数の顧客の総ストレージは1テラバイト未満
- 頻繁に利用する顧客の中央値は100GB未満
- 顧客のデータサイズはべき乗則分布に従う
- 業界アナリスト（Gartner、Forresterなど）の見解:
- 大多数の企業のデータウェアハウスは1テラバイト未満
- 一般的な目安は100GB程度のオーダー
- 投資家がポートフォリオ企業を調査した結果:
- 大規模B2B企業でも約1テラバイト程度
- 大規模B2C企業でも約10テラバイト程度
- 一般的な業務では膨大なデータは生成されにくい:
- 1,000顧客、1日100明細の受注でも1日1MB未満
- 100万件のマーケティングリードでも数ギガバイト程度
- NoSQLやNewSQLの停滞と、SQLite・PostgreSQL・MySQLの堅調な成長がこの実態を裏付ける
■ 4. ストレージとコンピュートの分離とその偏り
- ストレージとコンピュートの分離は過去20年で最も重要なアーキテクチャ変革
- S3・GCSなどのオブジェクトストレージの普及により、柔軟なスケーリングが可能になった
- 実態として、ストレージはコンピュートよりはるかに速く増大する:
- データは時間軸に沿って線形に蓄積される
- 分析は主に直近のデータに対して行われるため、コンピュート需要はほぼ横ばい
- 実例として、ある大手小売業者がオンプレミスからクラウド移行後にストレージは300倍（100TB→30PB）増加したが、コンピュート費用はごくわずかにとどまった
- オブジェクトストレージの活用により、分散処理が不要なケースも多い
■ 5. ワークロードのサイズは実際には小さい
- BigQueryの年間1,000ドル以上支出顧客の分析結果:
- クエリの90%は処理データ量が100MB未満
- テラバイト規模のクエリは極めて少数
- 巨大なデータを持つ顧客も、日常的には少量のデータしかクエリしない
- 大規模クエリはレポート生成目的が多く、パフォーマンスは優先されない
- データ処理量を削減する技術的手法:
- カラム射影（Column Projection）
- パーティションプルーニング（Partition Pruning）
- セグメント除去（Segment Elimination）
- 圧縮データへの演算、述語プッシュダウン
- 経済的なインセンティブも処理量削減を促す:
- ステージ上で行ったペタバイトクエリは小売価格で5,000ドルの費用がかかる
- クエリを小さくすることで、インスタンスサイズの縮小、コスト削減、並列実行数の増加につながる
■ 6. ほとんどのデータはほとんどクエリされない
- データアクセス頻度は鮮度に強く依存する:
- 処理データの大部分は24時間以内のもの
- 1週間経過すると直近1日比で約20分の1の頻度
- 1ヶ月以上経過したデータはほぼアクセスされない
- ストレージの年齢分布はフラットだが、アクセス分布は直近に集中する:
- 直近1ヶ月が全ストレージの5%でも全アクセスの80%を占める
- 結果として、実際のワーキングセットサイズは想定より管理しやすい
■ 7. ビッグデータの境界は後退し続けている
- 「ビッグデータ」の定義は「1台のマシンに収まらないデータ」であるが、該当するワークロードは年々減少している
- ハードウェアの進化:
- 2006年のAWS EC2初期インスタンスはシングルコア・2GBのRAM
- 現在の標準インスタンスは64コア・256GBのRAM（RAMで約2桁の向上）
- メモリ最適化インスタンスでは24TBのRAMや445コアも選択可能
- コストスケールの変化:
- クラウドではコンピュートコストはほぼ線形にスケールする
- 2004年のDremelペーパーで3,000並列ノードを要した処理が、現在は単一ノードで実行可能
■ 8. データはリスクでもある
- 「ビッグデータ」の別の定義は「削除対象を判断するコストより保持コストが低い状態」
- データ保持に伴う法的・規制上のリスク:
- GDPRやCCPAにより、特定データの利用追跡・削除義務が発生する
- データレイクに放置された個人データは法令違反につながる可能性がある
- データは訴訟においてリスク要因になり得る:
- セキュリティバグやSLA違反を示すログが訴訟に利用される可能性がある
- メール保持期限と同様に、データ保持期限を設けることがリスク管理として有効
- データの「ビット腐敗」問題:
- フィールドの意味の変化やデータバグの蓄積により、歴史データの解釈が困難になる
- 時代ごとの参照フィールドの違いなど、複雑なビジネスロジックが生じる
- データ保持の目的を明確にすることが重要:
- 同じ質問を繰り返すなら集計データの保持で足りる
- 将来のための保持なら、実際に必要になる可能性の評価が必要
■ 9. ビッグデータの1%に該当するか
- 以下の問いに一つでも「否」があれば、ビッグデータへの大規模投資は不要である可能性が高い:
- 本当に大量のデータを生成しているか
- そのデータを一度に大量に使う必要があるか
- データが1台のマシンに収まらないほど大きいか
- 単なるデータホーダー（溜め込み癖、捨てる事への恐怖症的な意味）ではないか
- 集計・要約では要件を満たせないか
- 大多数の組織は実際のデータサイズに見合ったツールを選択することが合理的