BigQueryデータセットのストレージ消費単位

もともとは論理バイト単位で課金されていたのですが、2023年7月の料金改定から、データ圧縮後の物理バイトを課金の単位にすることもできるようになりました。
論理・物理というのはテーブル詳細画面にも記載されていて、論理がデータをそのまま保存した場合の容量で、物理は圧縮して実際にかかっている容量のことのようです。

料金

	論理バイト	物理バイト
アクティブ（USD/GB）	0.023	0.052
長期（USD/GB）	0.016	0.026

一見、物理バイトのほうが高く見えるのですが圧縮率が1/10になることもあるようで、その場合は物理バイトで課金したほうが安くなります。
物理バイトの場合はタイムトラベル用のストレージも含めて計算する必要があります。（逆に論理バイトはタイムトラベル用ストレージは考慮しなくて良いです)
また、90日間変更がないと自動的に長期のストレージとして扱われます。

クエリでどちらを選べば良いか調べよう

どちらがいいかはデータの内容によるのですが、便利なINFORMATION_SCHEMAを使った以下のクエリを実行してどちらが安いかを調べることができます。（公式ドキュメントの例を元に作成しました。）
active_logical_gib_priceなどの料金、usd_rate(為替レート)、region-asia-northeast1(リージョン)の部分は適切な値に変更してください。

1DECLARE
2  active_logical_gib_price FLOAT64 DEFAULT 0.023;
3DECLARE
4  long_term_logical_gib_price FLOAT64 DEFAULT 0.016;
5DECLARE
6  active_physical_gib_price FLOAT64 DEFAULT 0.052;
7DECLARE
8  long_term_physical_gib_price FLOAT64 DEFAULT 0.026;
9DECLARE
10  usd_rate FLOAT64 DEFAULT 155.;
11
12with
13    storage_sizes as (
14        select
15            table_schema as dataset_name,
16            sum(active_logical_bytes) / power(1024, 3) as active_logical_gib,
17            sum(long_term_logical_bytes) / power(1024, 3) as long_term_logical_gib,
18            sum(active_physical_bytes) / power(1024, 3) as active_physical_gib,
19            sum(long_term_physical_bytes) / power(1024, 3) as long_term_physical_gib,
20        from `region-asia-northeast1`.information_schema.table_storage_by_project
21        where total_logical_bytes > 0 and total_physical_bytes > 0
22        group by table_schema
23    ),
24    cost as (
25        select
26            *,
27            active_logical_gib * active_logical_gib_price
28            + long_term_logical_gib * long_term_logical_gib_price as logical_cost_usd,
29            active_physical_gib * active_physical_gib_price
30            + long_term_physical_gib
31            * long_term_physical_gib_price as physical_cost_usd,
32        from storage_sizes
33    ),
34    cost_in_yen as (
35        select
36            *,
37            cast(logical_cost_usd * usd_rate as int64) as logical_cost_yen,
38            cast(physical_cost_usd * usd_rate as int64) as physical_cost_yen,
39            cast(
40                (physical_cost_usd - logical_cost_usd) * usd_rate as int64
41            ) as diff_cost_yen_when_change_physical,
42        from cost
43    )
44select
45    dataset_name,
46    logical_cost_yen as l_cost,
47    physical_cost_yen as p_cost,
48    diff_cost_yen_when_change_physical as diff_cost,
49from cost_in_yen
50order by diff_cost_yen_when_change_physical

各数値の意味は以下の通りで、単位は全て日本円です。

l_cost: 論理バイトで計算した場合の金額
p_cost: 物理バイトで計算した場合の金額
diff_cost: 論理バイト -> 物理バイトと変更した場合の金額の差

出力例

dataset_name	l_cost	p_cost	diff_cost
web_log	20000	1800	-18200
keiba	8000	2000	-6000
web_mart	15	20	5
web_analysis	28000	30000	2000

diff_costの列を見てください。
上の例では、web_log, keibaのデータセットでは物理バイトで課金したほうが安くなります。
web_analysisデータセットがそうなんですが、ほとんどの列のカーディナリティが高くて圧縮率が低くならない場合や、毎日集計しているようなテーブルはタイムトラベル用ストレージが高くなり論理バイトで課金したほうが安くなるようです。
web_martのように日時や月次で集計したテーブルは容量が小さいのでどちらでも安いことが多いです。