One Big Tableについて検証してみた
はじめに
WED株式会社でデータエンジニアをしているryuya-matsunawaです。
弊社では、レシート買取アプリONEを運営しており、ユーザー情報や購買情報などのデータをBigQueryで管理しています。
現在、レシート枚数が10億枚を超える規模に達しており、BigQueryでの分析クエリにおける処理パフォーマンスやコストの最適化が課題となっています。特に、データが巨大化する中で頻繁に発生するジョイン処理がクエリの負荷を大きくしています。
そこで、近年注目されているOne Big Table (OBT) を採用した場合、どのような改善が見込めるのかを検証してみました。
One Big Tableとは
One Big Table (OBT) は、データモデリング手法の一つで、大量のデータを効率的に格納・処理するために設計されたアプローチです。従来のリレーショナルデータベース設計でよく見られる正規化モデルとは異なり、全ての関連データを1つの巨大なテーブルに統合するという特徴があります。
特徴
One Big Tableを採用することで、以下のような利点が期待できます。
-
シンプルなクエリ構造
- 分割された複数のテーブルをジョインする必要がないため、クエリがシンプルになり、開発効率が向上します。
-
パフォーマンス向上、コスト削減
- ジョイン処理の回避によってクエリ実行速度が向上し、スロット時間やスキャンするバイト数が削減されるため、処理コストが抑えられます。
-
BIツールとの親和性
- GUIベースでクエリを作成できるため、ダッシュボード作成やレポート生成が容易になります。
一方で、冗長性が高まるため、データの更新処理やストレージ消費が増加する可能性があるため、適切な運用設計が必要です。
検証内容
今回の検証では、receiptsテーブル(レシート情報)とusersテーブル(ユーザー情報)を対象とし、これらを結合するクエリのパフォーマンスを比較しました。
検証環境
- データ量
- receiptsテーブル: 1年分のデータ
- usersテーブル: receiptsテーブルに紐づくユーザー情報
測定指標
比較の項目として、以下の3点を測定しました。
- クエリ実行時間
- クエリの実行に要した実際の時間(秒)
- スロット時間
- クエリの実行に要したBigQueryのスロット時間。処理速度に直結します。
- 課金バイト数
- クエリの実行時にスキャンされたデータ量(GB)。コスト削減に直結します。
検証結果
前準備
検証環境を作成する際のクエリの差分を示します。
項目 | One Big Table | 通常のデータモデル | 差分 |
---|---|---|---|
実行時間 | 54秒 | 46秒 | +8秒 |
スロット時間 | 22時間 | 12.5時間 | +9.5時間 |
課金バイト数 | 351GB | 350GB | +1GB |
集計クエリ
ユーザー情報(性別や年代、居住地など)をもとに、レシート情報を集計するクエリの差分を示します。
項目 | One Big Table | 通常のデータモデル | 差分 |
---|---|---|---|
実行時間 | 3秒 | 8秒 | -5秒 |
スロット時間 | 0.5時間 | 2.5時間 | -2時間 |
課金バイト数 | 14GB | 23GB | -9GB |
結果
- 前準備のクエリでは、先にJOINする分スロット時間が増えるものの、実行時間はほぼ変わらず、課金バイト数もほぼ同じでした。
- 集計クエリでは、One Big Tableを採用することで、実行時間が短縮され、スロット時間と課金バイト数が削減されました。
これにより、One Big Tableを採用することで、頻繁に叩かれる集計クエリのパフォーマンス向上とコスト削減が期待できることが確認できました。
今後の課題
- ストレージ使用量の増加
- クエリのパフォーマンス向上は見られるものの、ストレージ使用量が増加するため、どれくらいのコスト増加が見込まれるのかを検証する必要があります。
- データ更新時の負荷
- ユーザー情報などの変化する可能性のあるデータを統合する場合、データ更新時の負荷がどれくらいかかるのかを検証する必要があります。
まとめ
今回の検証では、One Big Tableに変更することで、集計クエリの実行時間が短縮され、スロット時間と課金バイト数が削減されることが確認できました。
特に、頻繁に利用される集計クエリのパフォーマンス向上が期待できるため、もう少し検証を進めて、弊社でのOBTの採用を検討していきたいと思います。
Discussion