BigQuery StandardSQLのレビュー観点表です。
BigQuery StandardSQLを複数人で利用し、運用にのせていく場合、早い段階からコードの品質担保する必要があります。 そのためのベストプラクティスを共有できるように、クエリレビュー観点をまとめます。
ソースをRawでコピー&ペーストすると、マークダウン対応のエディタ内で使いやすいです。
これらの観点に合わせることも重要ですが、プロジェクトの中で一貫性を保つことはもっと重要です。 特に、このレビュー観点を守るためにコードの後方互換性を壊すようなことは絶対にしないで下さい。 一貫性を崩すべき場合も有ります。疑問に思ったときは、あなたの判断を優先してください。そして、躊躇せずに質問して下さい。
- 社内のコーディング規約を守っているか
-
JOIN
はLEFT
/INNER
/FULL
を使い分けているか -
ON
やWHERE
、ウィンドウフレーム(ROWS、RANGE)は境界値で正常動作するか -
ARRAY_AGG
やSTRING_AGG
は固定長か、可変長ならユースケースのオーダーで制限を超えないか - 指数的爆発する
JOIN
を行っていないか - シャーディングは1,000テーブル未満か
- タイムゾーンは明らかか
- 再現性の確保が必要なのに、副作用を持つ関数を使っていないか
-
EXTERNAL_QUERY
やJavaScriptユーザー定義関数の型は適切か - 0始まりの文字列が
INT64
で比較されていないか - パーティション分割は上限(4,000)以内か
- シャーディングは1クエリの参照テーブル上限(1,000)以内か
- 有効精度に合わせて
NUMERIC
,FLOAT64
を選んでいるか -
UNION
を使う場合SELECT
の列順が同一である保証をしているか - 暗黙的にユニーク性を期待していないか
- 理解に十分なコメントがついているか
- データの値域は定義されているか
- エイリアスに意味のある名前がついているか
- 列挙型に
BOOL
を使わず無理にINT64
でフラグ管理していないか -
DATE
で十分なのにDATETIME
を使っていないか - 定義から外れた値は
ERROR
で拒否または無効化、許容できるか - 標準関数で代替できる関数を自作していないか
- なんでも
REGEXP_*
にしてないか - RANK/ROW_NUMBERは正しく使い分けているか
- クエリ パフォーマンスの最適化の概要に沿っているか
- 最終結果の無駄な
SELECT
を避ける - パーティション分割を検討する
- データを予め
JOIN
して非正規化する - 外部データソースを避ける
- 過剰なワイルドカード テーブル参照を避ける
-
JOIN
を使用する前にSELECT
やWHERE
、ON
、GROUP BY
、HAVING
でデータを削減する -
WITH
句やサブクエリの繰り返しを避ける - 日付別シャーディングよりパーティション分割を選ぶ
- テーブルの過度なシャーディングを避ける
- SQLクエリ経由のデータの繰り返し結合や変換を避けて実体化する
- JavaScriptユーザー定義関数を避ける
- 精度が許すなら近似集計関数を選ぶ
- パフォーマンスが最大化するようにクエリ オペレーションを並べ替える
-
JOIN
は最大、最小、2番目に大きい、3番目に大きいテーブルの順に結合する - 大規模な結果セットの実体化を避ける
- 大規模な並べ替えを避け、
LIMIT
を使用する - 自己結合よりウィンドウ関数を選ぶ
- パーティションの大きさに偏りがあるなら早めにフィルタする
-
CROSS JOIN
は事前に十分小さくするか、ウィンドウ関数を利用する - DMLによる更新、挿入は単一行より一括を選ぶ
- 最終結果の無駄な
- 最終結果、ウィンドウ関数以外でORDER BYが使われていないか
- SUM(IF(x))で計算できないか
- よく使うフィルタがあればクラスタ化する