はじめのProfessional Cloud Data Engineer認定取得講座⑤Cloud Bigtable スキーマ設計ガイド、BigQueryのパーティション分割、線形回帰について説明します！

クラウド

今回も、Professional Cloud Data Engineer認定取得するために、私が勉強した内容をアウトプットしていきます。

今回は、Cloud Bigtable スキーマ設計ガイド、BigQueryのパーティション分割、線形回帰について説明します！

ぜひ、最後までご覧いただけると嬉しいです！

Cloud Bigtable スキーマ設計ガイド

この記事では、Cloud Bigtableのスキーマを設計する際の基本的な概念とベストプラクティスについて説明します。BigtableはスケーラブルなNoSQLデータベースですが、そのパフォーマンスと効率性はスキーマ設計、特に行キーの設計に大きく依存します。

Cloud Bigtableの概要

Cloud Bigtableは、Google Cloudが提供するフルマネージドのNoSQLデータベースサービスで、ペタバイト級の大規模データをミリ秒単位で処理できるスケーラビリティと高パフォーマンスを特徴とします。タイムシリーズデータ、IoTデータ、分析ワークロードなどに最適化されており、Apache HBaseと互換性があるため既存のHBaseアプリケーションの移行も容易です。高可用性と自動スケーリング機能により、運用負荷を最小限に抑えつつ信頼性の高いデータ基盤を構築できます。

Bigtableデータモデルの基本

  • Bigtableは、行キー、列ファミリー、列修飾子、タイムスタンプによってインデックス付けされた、スパース（疎）で分散型の永続的な多次元ソートマップです。
  • 行は行キーによって辞書順にソートされて格納されます。
  • 列は列ファミリーにグループ化され、列ファミリー内に多数の列修飾子を持つことができます。
  • 各セルには複数のバージョンをタイムスタンプ付きで保持できます。

スキーマ設計の主な目標

  1. 読み取り/書き込み負荷の均等な分散
    特定のノードにアクセスが集中する「ホットスポット」を回避することが最も重要です。
  2. 必要なクエリのサポート
    アプリケーションが必要とするデータを効率的に取得できるようにスキーマを設計します（特に効率的な行スキャン）。
  3. パフォーマンスの最適化
    一般的なクエリで読み書きされるデータ量を最小限に抑えます。関連するデータは近くに（同じ行や隣接行に）格納します。
  4. データサイズの管理
    個々のセルや行が過度に大きくならないようにします。

主要な設計要素とベストプラクティス

  1. 行キーの設計 (最も重要)
    • ホットスポットの回避：単純なタイムスタンプやシーケンス番号など、連続的に増加/減少する値をキーの先頭や末尾に使用しないでください。これがホットスポットの主な原因です。
    • 負荷分散：書き込み/読み取りをテーブル全体に分散させるために、フィールドプロモーション、タイムスタンプの逆順利用、タイムスタンプのバケット化、ソルティング（キーへのハッシュプレフィックス追加）などのテクニックを検討します。
    • クエリの効率化：関連するデータをまとめて読み取れるように、行キーを設計します。例えば、関連アイテムに共通のプレフィックスを付け、範囲スキャンを効率化します。（書き込み分散と読み取り効率はトレードオフになる場合があります）。
    • 短さ：可能であれば行キーは短く保ちます。ストレージとネットワーク帯域幅を節約できます。
    • 可読性：デバッグしやすいように、人間が読める文字列の使用が推奨されます（バイナリも可）。
  2. 列ファミリーの設計
    • 関連データのグループ化：同時にアクセスされることが多い列は、同じ列ファミリーにまとめます。データはファミリーごとにまとめて格納されます。
    • 少数を維持：列ファミリーの数は少なく（通常は数個程度）保つことが推奨されます。多すぎるとパフォーマンスに影響が出る可能性があります。
    • 短い名前：列ファミリー名も短い方が効率的です。
    • アクセス制御とGC：アクセス制御やガベージコレクションポリシー（例：最新Nバージョンを保持、保持期間）はファミリー単位で設定できます。
  3. 列修飾子の設計
    • 多数・動的利用が可能：1つの列ファミリー内に数百万の列修飾子を持つことができます。特定のタイムスタンプやイベントIDなどを修飾子として使い、データを格納する「ワイドテーブル」設計も可能です。
    • 短い名前：静的で再利用される修飾子の場合は、短い名前が推奨されます。
  4. 関連データの扱い方
    • アクセスパターンに応じて、関連データを同じ行の異なる列／ファミリーに入れるか、共通プレフィックスを持つ隣接行に格納するかを検討します。
    • Bigtableには組み込みのセカンダリインデックスはありません。必要な場合は、アプリケーション側で別途インデックス用テーブルを管理するなどの対策が必要となり、複雑さが増します。

パフォーマンスに関する考慮事項

  • Tallテーブル vs Wideテーブル：アクセスパターンに応じて、行数を多く列数を少なくする（Tall）か、行数を少なく列数を多くする（Wide）かのトレードオフを理解します。
  • セル／行サイズ：個々のセル値（推奨 < 100KB）、行全体のサイズ（推奨 < 10MB）を適切な範囲に保つことがパフォーマンス上重要です。
  • クライアント側の最適化：バッチ処理、適切なフィルタリング、効率的なクライアントライブラリの利用も重要です。

Cloud Bigtable スキーマ設計ガイドのまとめ

Bigtableを効果的に利用するためには、アプリケーションのデータアクセスパターンに基づいた慎重なスキーマ設計が不可欠です。特に、ホットスポットを回避するための行キー設計は、パフォーマンスとスケーラビリティを達成するための最も重要な要素です。

BigQueryのパーティション分割

パーティション分割の概要

BigQueryのパーティション分割は、大きなテーブルを特定の基準（日付や整数範囲など）に基づいて、より小さなセグメント（パーティション）に物理的に分割して保存・管理する機能です。

イメージとしては、大きな本棚（テーブル）にある大量の本（データ）を、発行日別（パーティション）に棚を分けて整理するようなものです。

パーティション分割のメリット

パーティション分割を利用すると、主に以下のメリットがあります。

  1. クエリパフォーマンスの向上
    • クエリを実行する際に、条件に合致するパーティションのみをスキャン対象とすることができます（これをパーティションプルーニングと言います）。
    • 例えば、特定の日付のデータだけを問い合わせたい場合、テーブル全体をスキャンするのではなく、該当する日付のパーティションだけを読み込むため、処理が大幅に高速になります。
  2. コスト削減
    • BigQueryのオンデマンド料金は、クエリによってスキャンされたデータ量に基づいて課金されます。
    • パーティションプルーニングによりスキャンするデータ量を削減できるため、クエリにかかるコストを節約できます。
  3. データ管理の容易化
    • パーティション単位でデータの追加、削除、上書き、有効期限の設定などが可能です。
    • 例えば、「古い日付のパーティションだけを削除する」といった管理が効率的に行えます。

パーティション分割の種類

BigQueryでは、主に以下の3種類のパーティション分割方法があります。

  1. 時間単位の列によるパーティション分割
    • テーブル内のDATE型、TIMESTAMP型、DATETIME型の列の値に基づいてパーティションを作成します。
    • 最も一般的に利用される方法です。ログデータやトランザクションデータなど、時間軸でデータを分析することが多い場合に非常に有効です。
    • 分割の単位は、日次、月次、年次、時間単位から選択できます。
    • 例：order_date (DATE型) 列で日次に分割する。
  2. 取り込み時間によるパーティション分割
    • データがBigQueryに取り込まれた時刻に基づいて、自動的にパーティションが作成されます。
    • テーブル作成時に特別な列を用意する必要はありません。BigQueryが内部的に管理する _PARTITIONTIME という疑似列（TIMESTAMP型）がパーティションキーとして利用されます。
    • 分割の単位は基本的に日次ですが、時間単位も可能です（ただし、データ取り込み時に指定が必要）。
    • 例：ストリーミングインサートなどで日々追加されるデータの管理に適しています。
  3. 整数範囲によるパーティション分割
    • テーブル内のINTEGER型の列の値に基づいて、指定した範囲ごとにパーティションを作成します。
    • 例：user_id 列で、0-999、1000-1999、… のように1000区切りで分割する。

パーティション分割テーブルの作成方法（SQL例）

テーブル作成時に PARTITION BY 句を指定します。

  • 時間単位の列（日次）
    ＜SQL文（transaction_time列の日付部分で分割 ）＞
    CREATE TABLE mydataset.mytable (
    transaction_id INT64,
    transaction_time TIMESTAMP,
    amount FLOAT64
    )
    PARTITION BY DATE(transaction_time)
    OPTIONS (
    description="時間単位の列でパーティション分割されたテーブル"
    );
  • 取り込み時間（日次）
    ＜SQL文（取り込み時間で分割 (デフォルトは日次) ）＞
    CREATE TABLE mydataset.mytable_ingestion (
    message STRING,
    user_id INT64 )
    PARTITION BY _PARTITIONTIME
    OPTIONS (
    description="取り込み時間でパーティション分割されたテーブル"
    );
  • 整数範囲
    ＜SQL文（customer_idを0から10000まで100区切りで分割）＞
    CREATE TABLE mydataset.mytable_integer (
    customer_id INT64,
    product_name STRING
    )
    PARTITION BY RANGE_BUCKET(customer_id, GENERATE_ARRAY(0, 10000, 100))
    OPTIONS (
    description="整数範囲でパーティション分割されたテーブル"
    );

パーティション分割テーブルへのクエリ

パーティション分割のメリットを最大限に活かすには、クエリのWHERE句でパーティションキー列をフィルタリングすることが重要です。

  • 時間単位の列をフィルタリング
    ＜SQL文（特定の日付のパーティションのみスキャン）＞
    SELECT *
    FROM mydataset.mytable
    WHERE DATE(transaction_time) = '2025-04-17'
  • 取り込み時間をフィルタリング
    ＜SQL文（特定の期間のパーティションのみスキャン）＞
    SELECT *
    FROM mydataset.mytable_ingestion
    WHERE _PARTITIONTIME >= TIMESTAMP('2025-04-16') AND _PARTITIONTIME < TIMESTAMP('2025-04-17')
  • 整数範囲をフィルタリング
    ＜SQL文（該当する範囲のパーティションのみスキャン）＞
    SELECT *
    FROM mydataset.mytable_integer
    WHERE customer_id BETWEEN 100 AND 199

注意点

  • どの列で分割するか
    クエリで頻繁にフィルタリング条件として使われる列（特に日付関連）を選ぶのが効果的です。
  • パーティション数の上限
    1つのテーブルに対して作成できるパーティション数には上限があります（現在は4,000）。細かくしすぎると上限に達する可能性があるので注意が必要です。
  • パーティションキーの変更不可
    一度テーブルを作成すると、パーティションキーや分割方法を変更することはできません。変更したい場合は、テーブルを再作成する必要があります。
  • クラスタリングとの組み合わせ
    パーティション分割とクラスタリング（パーティション内のデータを特定の列でソートして保存する機能）を組み合わせることで、さらにクエリパフォーマンスを向上させることができます。

BigQueryを使い始めたばかりであれば、まずはよく使う日付やタイムスタンプの列で「時間単位の列によるパーティション分割（日次）」を試してみるのがおすすめです。データの量が増えてきた際に、その効果を実感しやすいでしょう。

線形回帰

線形回帰は「ある数値（原因になりそうなもの）を使って、別の数値（結果になりそうなもの）を予測するための、基本的な分析方法」の一つです。

ポイントは「線形」という言葉です。これは「直線的」という意味です。

実例

例えば、あなたがアイスクリーム屋さんだとします。

  • 知りたいこと：明日の「最高気温」が分かったら、「アイスの売上個数」がどれくらいになるか予測したい。
  • 使うデータ（原因になりそうなもの）：過去の毎日の「最高気温」と「その日のアイスの売上個数」のデータ。

このデータをグラフに点でプロットしていくと、なんとなく「気温が高い日ほど、アイスがよく売れる」という右肩上がりの傾向が見えるかもしれません。

線形回帰の目的

線形回帰は、このバラバラに見える点の集まり（データ）に対して、最も「それっぽい」直線を1本引く作業をします。コンピュータが、データ全体に一番フィットするような直線を計算して見つけてくれるのです。

この引かれた直線が、あなたの「予測モデル」になります。

線形回帰の方法

直線が引ければ、予測は簡単です。

  1. 明日の予想最高気温（例えば30℃）が分かったら、グラフ上で気温が30℃のところを見つけます。
  2. そこから真上に線を伸ばし、先ほど引いた「予測の直線」にぶつかった点を探します。
  3. その点が示す「売上個数」が、線形回帰による予測値（例えば「明日は150個くらい売れそうだ」）となります。

線形回帰の理由

世の中の現象は複雑ですが、「〇〇が増えれば、××も（だいたい）まっすぐ増える／減る」という直線的な関係で説明できることが意外と多くあります。線形回帰は、そのようなシンプルな関係性を捉えるのに適した、分かりやすい方法だからです。

線形回帰のメリット

  • 予測ができる：新しいデータ（明日の気温）から、結果（売上個数）を予測できます。
  • 関係性がわかる：「気温が1℃上がると、アイスの売上は何個くらい増えるのか？」といった、原因と結果の関係性の強さ（直線の傾き具合）を知ることができます。

線形回帰の注意点

  • 直線で表せない関係には弱い：例えば、「気温が低すぎても、高すぎても売れない」ような、山なりの関係の場合は、線形回帰だけではうまく予測できません。
  • 要因が一つとは限らない：アイスの売上は、気温だけでなく、曜日や天気（晴れ/雨）など、他の要因も影響しますよね。複数の要因を考慮する場合は、「重回帰分析」という、線形回帰を発展させた方法を使います。（今回はまず線形回帰を理解しましょう）

線形回帰のまとめ

線形回帰は、2つの数値の関係性を「直線」で捉え、一方の数値からもう一方の数値を予測したり、関係の強さを知ったりするための、シンプルで強力な分析手法です。データ分析の第一歩として、様々な分野で広く使われています。

まとめ

今回は、下記３点について説明しました。

  1. Cloud Bigtable スキーマ設計ガイド
  2. BigQueryのパーティション分割
  3. 線形回帰

BigtableやBigQueryといったGoogle Cloudのデータ基盤を活用するには、適切な設計と理解が重要です。スキーマ設計やパーティション分割の工夫により、パフォーマンスとコスト効率を大きく向上させることができます。また、線形回帰のような基本的な分析手法を活用することで、蓄積されたデータから有益な知見を引き出すことが可能です。これらの基礎を押さえることで、より効果的なデータ活用が実現できるでしょう。

これからも、Macのシステムエンジニアとして、日々、習得した知識や経験を発信していきますので、是非、ブックマーク登録してくれると嬉しいです！

それでは、次回のブログで！

スポンサーリンク
タイトルとURLをコピーしました