BigQuery リリース チェックリスト

はじめに

この BigQuery リリース チェックリストでは、Google BigQuery を使用する商用アプリケーションのリリース前に完了しておいた方がよい作業について説明します。このチェックリストは、BigQuery 固有の作業に重点を置いています。また、全般的なチェックリストである Google Cloud Platform 向けリリース チェックリストを使用して、どのサービスでも同様に完了しておく必要がある作業を確認してください。

この BigQuery リリース チェックリストは、BigQuery に習熟しているデベロッパーの方を対象としています。このチェックリストは、BigQuery の初心者向けに使い方を説明するものではありません。

このチェックリストは、以下のセクションで構成されています。

  • アーキテクチャの設計と開発
  • 試験リリース
  • 最終リリース

これらのセクションは、アプリケーションのリリースに向けて、使用をおすすめする順番で記述されています。たとえば、最初は「アーキテクチャの設計と開発チェックリスト」にある手順から開始します。この手順では、アプリケーション開発の初期段階で実施することが適切な作業を取り上げています。同様に、「試験リリース チェックリスト」には、リリースが近付いた時期に実施することをおすすめする作業が記述されています。なお、チェックリストに挙げられている作業の正確なタイムラインとその所要時間は、実際のアプリケーション開発日程に応じて異なります。

アーキテクチャの設計と開発のチェックリスト

このチェックリストはアプリケーション開発の初期段階で使用することをおすすめします。各グループに対するチェックリスト作業を並行して進めてもかまいませんが、ソフトウェアのアーキテクチャに関連する作業は、可能な限り早い段階で実施することをおすすめします。この作業は完了に時間がかかるからです。

作業内容
コミュニティ / グループ / フォーラム
❑  
スタックのオーバーフローについて BigQuery のコミュニティ サポートに相談します。このサポートでは、有用な情報や実用的なアドバイスを得ることができます。
❑  
BigQuery - お知らせグループに登録します。
スキーマの設計
❑  
必要なクエリに基づいてスキーマを設計します。BigQuery はネストされたフィールドと繰り返しフィールド(type:RECORD)をサポートしています。非正規化されたテーブルで、論理的に 1 対他のリレーションシップを使用できます。このようなフィールドのアクセス方法を維持しながら、必要に応じて利用します。繰り返しフィールドのネストが解除された論理ビューの作成も検討します。クエリのコストを見積もります。
❑  
繰り返しフィールドは、ネストレベルが 1 または 2 を超えるとクエリでの使用が難しくなる場合があります。適切なネストレベルを検討します。
❑  
BigQuery では、結合でパフォーマンスが向上しますが、一部のクエリでは非正規化によってパフォーマンスが向上する場合があります。データモデルで結合性が重要かどうか検討します。
❑  
BigQuery では、DML を使用してテーブルを追加または更新できます。DML は、1 行の変更ではなく、更新、削除または挿入を一括で行う場合に使用します。更新パターンが OLAP システムと一致していることを確認します。
❑  
従来の RDBMS とは異なり、プライマリ / セカンダリまたは行 ID キーの概念はありません。必要な場合は、テーブル スキーマの列を識別します。
データ ボリュームの見積もり
❑  
初期アップロードでアップロードされるデータの量を計算し、基本レベルを求めます。
❑  
増分的にアップロードされるデータの量とその頻度(毎時 / 毎日 / 毎週)を計算します。
❑  
期限切れになるデータの量(ある場合)とその頻度を計算します。
クエリ処理の見積もり
❑  
BigQuery データセットで毎日実行されるクエリの種類を明らかにします。Stackdriver Monitoring は、リソースの使用状況、同時クエリ、データセット サイズに関して有益な診断情報を提供します。
❑  
テーブルのパーティショニング / シャーディング方法を決定します。たとえば、ある日に発行されたクエリがその日の間に収集されたデータと関係がある場合、1 日につき 1 つのテーブルを作成します。複数の日のデータを集計するには、テーブル ワイルドカードまたは \_PARTITIONTIME 疑似列を使用します。
❑  
BigQuery が 1 日に処理するデータの量を計算します(クエリの数 x 1 回のクエリで処理されるデータの量)。BigQuery では(行全体ではなく)個々の列の処理に対して請求されるので、計算ではそれを考慮する必要があります。また、クエリで列を参照すると列の完全なスキャンが実行されることにも注意してください。
割り当て管理
❑  
BigQuery でのデフォルトの割り当てを理解します。
❑  
以下の部分のうち該当するものについて割り当ての分析を行います。
  • BigQuery にデータを読み込むために必要な、1 日あたりの読み込みジョブの数。
  • 1 日に 1 つのテーブルで行われる BigQuery への読み込みジョブの数。
  • ストリーミング API を使用している場合、ストリーミング挿入の数、挿入の行サイズ、1 秒間の最大行数、リクエストあたりの最大行数、その他のストリーミング API 固有パラメータ
  • アプリケーションによって発行された BigQuery に対するクエリの数。
  • クエリを同時に実行するために使用された同時セッションの数。
  • BigQuery からデータを抽出するために実行されたエクスポート ジョブの 1 日あたりの数。
  • BigQuery のオペレーションを呼び出すための API であっても、レートおよび 1 日の単位で制限されます。詳細については API レート制限をご覧ください。
❑  
割り当てが十分でない場合は、GWSC で割り当ての調整を申請します。
費用分析
❑  
データ量とクエリ処理の見積もりに基づき、BigQuery の料金と料金計算ツールを使用して BigQuery のストレージと処理の料金を計算します。
❑  
費用の最適化に関する以下の推奨事項を考慮します。
  • クエリでは関連のある列のみを選択します。where 句のフィルタに関係なく、BigQuery は選択された列の完全列スキャンを実行(および変更)することに注意してください。
  • テーブルを小さい単位にパーティショニング / シャーディングして、処理費用を最適化します。多くの場合、最適化とパフォーマンスの間にはトレードオフがあります。小さいテーブルが多すぎると、クエリで参照されている各テーブルを読み込む固定オーバーヘッドが、パフォーマンスに影響を与える可能性があります。
  • 1 つの大きいテーブルではなく、テーブルの小さいパーティションでクエリをテストします。
  • API を使用する場合は、クエリの構文を検証し、dryRun フラグを使用してデータ処理の統計情報を取得します。
  • クエリで不要になった古いテーブルは削除するか、テーブルに対して expirationTime を利用します。
セキュリティ
❑  
データセットへのアクセス権限とジョブ実行権限が正しく適用されるように、BigQuery の IAM ポリシーを慎重に検討します。次の点に注意してください。
  • プロジェクトのメンバーがセキュリティ ポリシーを遵守しているかどうか BigQuery 権限を監査します。bigquery.User 役割によって、ユーザーにプロジェクト内のジョブの実行が許可され、dataset.Viewer によって、特定のデータセットのすべてのテーブに対する読み取り可能性が制御されます。dataset.Editordataset.Owner は、ユーザーがテーブルまたはデータセットの変更を必要としている場合にのみ、それぞれ付与する必要があります。
  • 特定のデータセットをチームのメンバーで共有する必要がある場合には、データセット共有を使用するか、明示的な IAM 役割を使用します。
  • より細かいセキュリティ制御が必要な場合には、承認済みのビューによるアクセス制御を検討します。
BigQuery に先立つデータの前処理
❑  
BigQuery に読み込む前にデータの前処理を行って、費用とパフォーマンスを最適化することを検討します。たとえば、次のような前処理が可能です。
  • 必要のない型キャストと計算を事前に処理します。
  • 頻繁に使用する結合を事前に行います。
  • 指標および頻繁に実行する分析を事前に集計します。
❑  
BigQuery 自体、Cloud DataflowCloud Dataproc、ETL ツールを使用してデータを事前に処理します(変換、非正規化など)。
❑  
異なる種類のクエリのために、同じデータセットの構造を変えた複数のバージョンを用意することを検討します。
❑  
テーブルごとの DML ステートメントには 1 日の上限が設定されているため、段階的に変更を行うようにテーブルの更新 / 削除を計画します。
クエリの調整とテスト
❑  
予想されるデータ量でクエリをテストし、次の原則に従ってクエリを調整します。
  • 必要のない列を select 句から除去し、費用を削減してパフォーマンスを向上させます。
  • ネストされたクエリのコンテキストでは、where 句を効果的に使用して内側のクエリのデータをフィルタ処理し、外側のクエリで処理するデータを減らします。
  • 可能な場合は、フラット化を可能な限り内側にして、WHERE 句をその近くで使用します。
  • 正規表現などの処理量の多いフィルタを最後の方に移動します。
  • 元の同等のデータを使用できるときは、文字列のグループ化を行わないようにします(例: タイムスタンプと文字列のどちらを使用するか)。
  • ORDER BYLIMIT は最も外側のクエリで使うようにします。できる限り、ORDER BY は内側のクエリでは使わないようにします。
  • 偏りのある大きなグループに GROUP BY を使用すると、テイル レイテンシが増加する可能性があります。クエリのパフォーマンスを向上させるため、これらをフィルタリングします。
  • 自己結合よりも処理オーバーヘッドが少ないため、自己結合ではなく、IF/CASE または分析用の SQL 関数を使うようにします。
データの可視化
❑  
BigQuery は大きいデータセットのデータをクエリするためのツールです。データの可視化については、サードパーティのツールと強い結び付きがあります。
  • Google データポータル
  • Google スプレッドシートや Microsoft Excel などの Office 生産性ツール。
  • Tableau、BIME、Informatica などの市販ツール。
  • redash などの代替オープンソース ツール。

試験リリース チェックリスト

アプリケーションの商用リリースに先立ち、「試験リリース チェックリスト」を使用し、リリースに向けた準備体制をテストすることをおすすめします。

作業内容
❑  
ストリーミング API を使用してデータを読み込む場合は、負荷テストをシミュレートして、割り当て違反なしにデータが読み込まれることを確認します。
❑  
バッチジョブを使用してデータを読み込む場合は、負荷テストをシミュレートして、妥当な時間で割り当て違反なしに BigQuery にデータが読み込まれることを確認します。
❑  
実際のコストと比較してコストモデルを見直します。運用コストが予算内に収まることを確認してください。コストモデルを変更します。Google Cloud Platform の料金計算ツールでは妥当な見積もりが可能ですが、負荷テストで 1 日のデータ処理量がわかるまでは正確に計算できません。

最終リリース チェックリスト

リリース直前とリリース中は、「最終リリース チェックリスト」を使用します。

作業内容
❑  
ここまでチェックリストに沿って作業を完了していれば Google BigQuery でリリースを成功させられるようになっています。これで完了です。Google Cloud Platform 用リリース チェックリストの最終的なリリース チェックリストも確認することをおすすめします。
このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...

ご不明な点がありましたら、Google のサポートページをご覧ください。