BigQuery Cost Control Checklist: partition, cluster, prune และกัน query แพง

BigQuery เป็นเครื่องมือที่ทรงพลังมากสำหรับงาน analytics เพราะมันทำให้ทีม query ข้อมูลจำนวนมากได้เร็วพอสมควรโดยไม่ต้องมานั่งดูแล cluster เองเยอะ แต่ข้อดีนี้ก็มีด้านที่ต้องระวังเหมือนกัน

ยิ่ง query ง่าย
ยิ่งคนกล้ายิง query ใหญ่
ยิ่ง schema หลวม
ยิ่งเผลอ scan ข้อมูลเกินจำเป็น
และสุดท้ายบิลก็เริ่มโตแบบที่ทีมเพิ่งมารู้ตัวตอนปลายเดือน

หลายทีมไม่ได้เจอปัญหาเพราะ BigQuery แพงโดยธรรมชาติ แต่เจอเพราะระบบไม่มีวินัยเรื่องการออกแบบตารางและการเขียน query ตั้งแต่ต้น พอ event data โตขึ้น report เยอะขึ้น และมีคนใช้มากขึ้น cost ก็เริ่มพุ่งแบบเงียบ ๆ

คำถามที่เจอบ่อยมีลักษณะนี้

ทำไม query นี้วิ่งแค่ไม่กี่วินาทีแต่ cost สูง
ทำไม dashboard เดิมเปิดบ่อย ๆ แล้วเริ่มแพง
ทำไม table เดียวกันบาง query ถูกมาก บาง query แพงมาก
partition ก็มีแล้ว ทำไมยัง scan เยอะ
cluster ใส่ไปแล้วแต่ไม่เห็นผล
จะรู้ได้ยังไงว่า query ไหนกำลัง full scan โดยไม่จำเป็น

บทความนี้สรุป checklist ที่ใช้ได้จริงสำหรับการคุม cost ของ BigQuery โดยเน้นวิธีคิดที่ช่วยลดปัญหาตั้งแต่ระดับ schema และ query design ไม่ใช่รอไปแก้ตอนค่าใช้จ่ายเริ่มบาน

TL;DR

สรุปให้สั้นที่สุด

BigQuery จะแพงเมื่อคุณ scan ข้อมูลมากเกินความจำเป็น
ดังนั้นการคุม cost ที่ได้ผลที่สุดมักไม่ใช่การห้ามคน query แต่คือการทำให้ตารางและ SQL เอื้อต่อการ scan ให้น้อยลงตั้งแต่ต้น

ถ้าจะเริ่มให้ถูก ควรเริ่มจาก 4 เรื่องนี้

partition ให้ตรงกับ time-based access pattern
cluster ตาม field ที่ถูก filter บ่อยจริง
เขียน query ให้ prune partitions ได้
ลดการอ่าน columns และ rows ที่ไม่จำเป็น

ถ้า table ถูกออกแบบดีและทีมมีวินัยเรื่อง query cost มักจะลดปัญหาไปได้เยอะมากก่อนต้องไปใช้มาตรการหนักกว่านั้น

ก่อนคุม cost ต้องเข้าใจก่อนว่า BigQuery แพงจากอะไร

ในหลายกรณี cost ของ BigQuery เกี่ยวข้องกับการอ่านข้อมูล ไม่ใช่แค่จำนวนแถวที่ query คืนกลับมา

นี่คือจุดที่หลายคนพลาด

query หนึ่งอาจคืนมาแค่ 20 แถว
แต่ถ้ามันต้อง scan ข้อมูลจำนวนมากก่อนถึงจะหา 20 แถวนั้นเจอ cost ก็ยังสูงอยู่ดี

ดังนั้นเวลา query แพง คำถามที่ควรถามคือ

query นี้อ่านข้อมูลเท่าไร
filter ที่เขียนอยู่ช่วย prune ได้จริงหรือไม่
table ถูก partition หรือ cluster ในแบบที่ query ใช้งานจริงหรือไม่
มีการอ่าน columns ที่ไม่จำเป็นหรือไม่
query นี้เป็น ad hoc analysis หนึ่งครั้ง หรือเป็น query ที่ถูกยิงซ้ำทุกวันทุกชั่วโมง

BigQuery จะคุ้มมากเมื่อ schema และ query ช่วยกันทำให้การอ่านข้อมูลแคบลง แต่จะเริ่มแพงเมื่อทุกอย่างเปิดกว้างเกินไป

เรื่องแรกที่ควรคิด: table นี้ถูกอ่านตามเวลาไหม

สำหรับ analytics table จำนวนมาก โดยเฉพาะ event tables, logs, facts, daily metrics หรือ historical records คำถามพื้นฐานคือ

คนจะ query table นี้ตามช่วงเวลาเป็นหลักหรือไม่

ถ้าคำตอบคือใช่ คุณมักควรเริ่มจาก partitioning ตามเวลา

เพราะ query analytics ส่วนใหญ่ไม่ได้อยากอ่านข้อมูลทุกปีทุกวันพร้อมกัน แต่สนใจช่วงเวลาใดช่วงเวลาหนึ่ง เช่น

7 วันล่าสุด
30 วันล่าสุด
ไตรมาสล่าสุด
เดือนนี้
ย้อนหลัง 12 เดือน

ถ้า table ไม่มี partition ตามเวลาเลย query เหล่านี้จะมีแนวโน้ม scan กว้างเกินไปง่ายมาก

Partition คืออะไรในทางปฏิบัติ

partition ใน BigQuery ช่วยแบ่งข้อมูลออกเป็นช่วงตาม field หนึ่ง ซึ่งในงาน analytics ส่วนใหญ่มักเป็น date หรือ timestamp

ประโยชน์ของมันง่ายมาก

ถ้าคุณ query เฉพาะช่วงวันที่เกี่ยวข้อง
BigQuery จะอ่านเฉพาะ partitions ที่ตรงกับช่วงนั้น
แทนที่จะ scan ทั้งตาราง

สิ่งนี้สำคัญมากต่อ cost เพราะช่วยลด data scanned ได้ตรงจุดที่สุดอย่างหนึ่ง

Partition ด้วยอะไรดี

ในหลายระบบ event table มักเหมาะกับ field อย่าง

event_date
หรือ event_timestamp

แต่ในทางปฏิบัติ การมี event_date แยกเป็น DATE มักทำให้ query และ governance ง่ายขึ้น เช่น

filter ชัด
group by ง่าย
partition pruning ตรงไปตรงมา
dashboard ใช้ง่าย

ตัวอย่าง query ที่ใช้ partition ได้ดี เช่น

select
  event_date,
  count(*) as total_events
from analytics.events
where event_date between '2026-04-01' and '2026-04-18'
group by event_date
order by event_date;

query แบบนี้บอกช่วงชัดเจน BigQuery จึง prune partitions ได้ง่าย

ปัญหาที่เจอบ่อย: มี partition แล้วแต่ query ยังแพง

นี่เป็นคำถามที่เจอบ่อยมาก และสาเหตุจำนวนมากมาจากการเขียน query ที่ไม่ช่วยให้ partition pruning ทำงานเต็มที่

ตัวอย่างเช่น

ไม่ filter partition field เลย
เอา function ไปครอบ partition field จน pruning ยากขึ้น
filter แบบหลวมเกินไป
query ผ่าน view ที่ซ่อน filter logic ไว้ไม่ชัด
table ถูก partition แต่คน query ไม่รู้ว่าต้องใช้ field ไหน

ตัวอย่างที่ดีกว่า:

where event_date >= '2026-04-01'
  and event_date < '2026-05-01'

มากกว่าการเขียนอะไรที่ทำให้ field เดิมถูกแปลงซับซ้อนโดยไม่จำเป็น

ทำไมควรระวังการครอบ field ด้วย function

เวลา BigQuery จะ prune partition ได้ดี มันชอบเงื่อนไขที่ชัดกับ partition field เดิม

ถ้าคุณทำแบบนี้บ่อย ๆ

where date(event_timestamp) = '2026-04-18'

บางกรณีอาจยังทำงานได้ตามที่หวัง แต่การพึ่งพา function wrapping เสมอ ๆ มักทำให้ query ไม่ชัดเท่าการมี field สำหรับ partition โดยตรง เช่น event_date

ดังนั้นในเชิงออกแบบ schema ถ้ารู้ว่าคนจะ query ตามวันบ่อย การเตรียม event_date ให้เป็น first-class field เลย มักช่วยทั้ง readability และ cost discipline

เรื่องที่สอง: clustering ไม่ได้แทน partition แต่เสริมกัน

หลายทีมใส่ cluster แล้วหวังว่าทุก query จะถูกลงทันที ซึ่งไม่ใช่แบบนั้น

cluster มีประโยชน์เมื่อ query ของคุณ filter ด้วย fields บางตัวบ่อยจริง เช่น

event_name
tenant_id
actor_id
resource_type
resource_id

ถ้า table มี partition ตามเวลาแล้ว และภายในช่วงเวลานั้นคนยัง filter ตาม field พวกนี้บ่อย clustering จะช่วยให้ BigQuery ตัดพื้นที่อ่านภายใน partition แคบลงได้อีก

พูดง่าย ๆ คือ

partition ช่วยตัดช่วงเวลา
cluster ช่วยตัดข้อมูลภายในช่วงเวลานั้น

แล้วควร cluster ด้วย field ไหน

คำตอบที่ดีควรมาจาก query patterns จริง ไม่ใช่ field ที่ดูสำคัญในนามธรรม

ลองถามแบบนี้

dashboard ส่วนใหญ่ filter ด้วยอะไร
analyst ชอบเจาะด้วย field ไหน
report ที่รันบ่อยใช้ where clause แบบไหน
query ส่วนใหญ่เริ่มจาก tenant, event_name หรือ resource type หรือไม่

ถ้าคำตอบชัด เช่น table events ถูก query แบบนี้ตลอด

ช่วงเวลา 30 วันล่าสุด
เฉพาะ tenant หนึ่ง
เฉพาะ event_name บางตัว

field อย่าง tenant_id และ event_name ก็มักเป็น cluster candidates ที่มีเหตุผล

ปัญหาที่เจอบ่อย: cluster ไปเพราะคิดว่าน่าจะดี

การใส่ clustering โดยไม่ดู query patterns จริง อาจช่วยน้อยกว่าที่คาด หรือบางครั้งแทบไม่ช่วยเลย

ตัวอย่างเช่น

cluster ด้วย field ที่ไม่ค่อยถูก filter
cluster ด้วย field cardinality แปลกเกินโดยไม่มีเหตุผล
ใส่หลาย field มากเกินไปเพราะหวังครอบจักรวาล

สิ่งที่สำคัญกว่าการใส่ clustering คือรู้ว่ามันถูกใช้กับ query ชนิดไหนจริง

เรื่องที่สาม: prune ให้เป็น ไม่ใช่แค่มี partition

คำว่า prune ในบริบทนี้คือการเขียน query ให้ BigQuery ตัดข้อมูลที่ไม่เกี่ยวออกตั้งแต่ต้น

นี่ไม่ได้หมายถึงแค่ partition pruning อย่างเดียว แต่รวมถึงการลดทั้ง

ช่วงเวลา
rows ที่ไม่เกี่ยว
columns ที่ไม่จำเป็น

query ที่ดีจึงมักเริ่มจากคำถามว่า

จำเป็นต้องอ่านข้อมูลส่วนไหนจริง ๆ

แทนที่จะเริ่มจาก

ขอทุกอย่างมาก่อนแล้วค่อยกรองทีหลัง

นี่เป็น mindset ที่ช่วยลด cost มากกว่าการ optimize syntax เล็ก ๆ น้อย ๆ หลายเท่า

อย่าใช้ `SELECT *` ถ้าไม่จำเป็น

นี่เป็นคำแนะนำพื้นฐานที่ยังใช้ได้จริงมาก

SELECT * อาจสะดวกตอน exploratory analysis ระยะแรก แต่ใน query ที่ใช้ซ้ำหรืออยู่ใน dashboard / scheduled jobs มันมักทำให้ scan columns เกินจำเป็น

ถ้าคุณต้องการแค่

event_date
event_name
tenant_id
count(*)

ก็ไม่ควรอ่าน columns อื่นทั้งหมดมาด้วย

ตัวอย่างที่ดีกว่า:

select
  event_date,
  event_name,
  count(*) as total_events
from analytics.events
where event_date between '2026-04-01' and '2026-04-18'
group by event_date, event_name;

มากกว่าการเริ่มจาก select * แล้วค่อยห่อ query อีกชั้น

Query ที่ใช้ซ้ำควรถูกทำให้ lean กว่า ad hoc query

อย่าปะปน query สองประเภทนี้เข้าด้วยกัน

Ad hoc analysis

ใช้เพื่อสำรวจ, ลองสมมติฐาน, เปิดดูข้อมูล, สร้าง insight ครั้งเดียวหรือไม่บ่อย

Repeated workload

คือ query ที่รันทุกวัน ทุกชั่วโมง ทุกครั้งที่ dashboard เปิด หรือใช้ใน scheduled reports

query กลุ่มหลังควรถูก review เรื่อง cost มากกว่า เพราะถึง query จะไม่ได้แพงมากต่อครั้ง แต่ถ้าถูกเรียกซ้ำบ่อย cost สะสมจะสูงขึ้นเร็วมาก

หลายระบบไม่ได้เจ็บจาก query ใหญ่ครั้งเดียว แต่เจ็บจาก query กลาง ๆ ที่ถูกรันซ้ำตลอดวัน

อย่าดึงข้อมูลดิบถ้าใช้ aggregate ได้

อีกจุดที่ช่วยลด cost ได้มากคือการถามให้ตรงกับสิ่งที่ต้องการจริง

ถ้าสิ่งที่ต้องการคือ

count
sum
average
grouped metrics
trend รายวัน

ก็ไม่ควรดึง raw rows จำนวนมหาศาลออกมาก่อนแล้วค่อย aggregate ข้างนอก

BigQuery ถูกออกแบบมาสำหรับ aggregation อยู่แล้ว ดังนั้นยิ่ง push งานสรุปให้อยู่ใน query ได้มากเท่าไร มักยิ่งช่วยทั้ง cost และ downstream simplicity

Materialized thinking สำคัญกับ report ที่ใช้ซ้ำ

ถ้ามี query บางตัวที่แพงและถูกรันซ้ำมาก เช่น dashboard ผู้บริหาร, daily KPI, monthly finance summary, weekly operational reports บางครั้งสิ่งที่คุ้มกว่าคือ

สร้าง summary tables
pre-aggregate รายวัน
scheduled queries ไปเขียน intermediate tables
แยก hot analytics datasets ออกจาก raw events

เพราะถ้าคุณให้ทุก dashboard ไปอ่าน raw events ทั้งก้อนเองตลอด วันหนึ่ง cost จะเริ่มโตจาก repeated scans ที่จริง ๆ หลีกเลี่ยงได้

นี่ไม่ได้แปลว่าต้อง materialize ทุกอย่าง แต่แปลว่าควรแยกให้ออกว่าอะไรคือ exploratory query กับอะไรคือ production-grade reporting workload

Raw table กับ summary table ควรอยู่ร่วมกันได้

แนวทางที่ practical มากคือใช้สองชั้น

raw events สำหรับ exploration และ deep analysis
summary / reporting tables สำหรับ workloads ที่ถูกใช้บ่อยและรูปแบบคงที่

เช่น

analytics.events_raw
analytics.daily_event_counts
analytics.weekly_funnel_summary
analytics.tenant_usage_daily

วิธีนี้ช่วยลดการ scan raw tables ซ้ำ ๆ สำหรับคำถามเดิม

ระวัง joins ที่ใหญ่โดยไม่จำเป็น

BigQuery join ได้เก่ง แต่ไม่ได้แปลว่าควร join ทุกอย่างแบบไม่คิด

โจทย์ที่ควรถามคือ

join นี้จำเป็นจริงไหม
dimension table นี้เล็กพอไหม
query นี้ถูกใช้ซ้ำบ่อยหรือไม่
ควร flatten หรือสร้าง reporting layer ที่ join มาแล้วหรือเปล่า

โดยเฉพาะใน dashboard หรือ recurring reports ถ้าคุณ join raw large tables หลายตัวทุกครั้ง cost มักจะสูงขึ้นโดยไม่จำเป็น

บางครั้งการออกแบบ data model ให้ query ตรงขึ้น จะคุ้มกว่าการหวังว่า engine จะจัดการทุกอย่างให้

Partition expiration และ retention ก็เป็นส่วนของ cost control

อีกเรื่องที่ถูกมองข้ามคือไม่ใช่ทุกข้อมูลต้องถูกเก็บตลอดไปในชั้นเดียวกัน

ถ้าข้อมูลบางประเภทมี lifecycle ชัด เช่น

raw operational logs
temporary staging tables
short-lived intermediate datasets
debug events

การมี retention policy หรือ partition expiration ช่วยได้ทั้งด้าน cost และ governance

สิ่งสำคัญคือให้ทีมคุยกันให้ชัดว่า

data นี้ต้องเก็บกี่วัน กี่เดือน กี่ปี
raw กับ summary ต้องเก็บเท่ากันไหม
debug data ควร expire เองหรือไม่

ถ้าไม่คิดเรื่องนี้เลย table มักจะโตไปเรื่อย ๆ โดยไม่มีใครถามว่าจริง ๆ ยังต้องเก็บครบทุกอย่างหรือไม่

ระวัง wildcard tables แบบไม่จำเป็น

บางระบบใช้ wildcard tables หรือ sharded tables ต่อวัน/เดือนแบบเดิม ๆ ซึ่งบางครั้งอาจทำให้ query governance และ pruning ซับซ้อนกว่าการใช้ native partitioned tables

ถ้าคุณยังเลือกได้ การใช้ partitioned tables มักเป็นแนวทางที่อ่านง่ายและควบคุม cost ได้ดีกว่าในระยะยาว

Dry run, preview และ review culture ช่วยได้มาก

cost control ที่ยั่งยืนไม่ได้เกิดจาก schema อย่างเดียว แต่เกิดจากพฤติกรรมของทีมด้วย

ตัวอย่างพฤติกรรมที่ช่วยได้จริง เช่น

review query ก่อนเอาไปใส่ dashboard
ใช้ dry run หรือ estimate ขนาด scan ก่อน query ใหญ่
สอนทีมให้อ่านว่า query นี้น่าจะ scan เยอะแค่ไหน
ไม่เอา exploratory query ดิบ ๆ ไปใส่ recurring jobs ทันที

ในหลายทีม แค่เพิ่มวินัยเรื่อง review query ที่ถูกใช้ซ้ำ ก็ช่วยลด cost ได้เยอะโดยไม่ต้องเปลี่ยน infra ใหญ่โต

ตัวอย่าง schema ที่เอื้อต่อ cost control

สมมติคุณมี event table แบบนี้

create table analytics.events (
  event_name string not null,
  event_timestamp timestamp not null,
  event_date date not null,
  tenant_id string,
  actor_id string,
  resource_type string,
  resource_id string,
  request_id string,
  correlation_id string,
  metadata json
)
partition by event_date
cluster by tenant_id, event_name;

schema แบบนี้ช่วยได้หลายทาง

query ตามช่วงเวลา prune partitions ได้
query ต่อ tenant และ event_name มีโอกาสใช้ clustering ได้
field สำคัญอยู่ top-level ไม่ต้องแกะ JSON ทุกครั้ง
request/correlation context ยัง query ได้โดยไม่ต้อง scan metadata เสมอไป

นี่คือเหตุผลว่าทำไม cost control เริ่มตั้งแต่ schema ไม่ใช่เริ่มจากการไล่หาคนยิง query แพงทีหลัง

ตัวอย่าง query ที่ดีขึ้น

แบบที่เสี่ยงแพงกว่า

select *
from analytics.events
where date(event_timestamp) between '2026-04-01' and '2026-04-18';

ปัญหาคือ

ใช้ select *
ใช้ function กับ timestamp แทน field partition ที่เตรียมไว้
ไม่ได้จำกัด columns เลย

แบบที่ดีขึ้น

select
  event_date,
  event_name,
  tenant_id,
  count(*) as total_events
from analytics.events
where event_date between '2026-04-01' and '2026-04-18'
  and tenant_id = 'tenant_acme'
group by event_date, event_name, tenant_id
order by event_date;

query แบบนี้

ใช้ partition field ตรง ๆ
จำกัดช่วงเวลา
จำกัด tenant
อ่านเฉพาะ columns ที่จำเป็น
aggregate ให้เสร็จใน query

Summary tables ช่วยยังไง

ถ้าคุณมี dashboard ที่ทุกเช้าต้องการแค่ยอดรายวันต่อ tenant และต่อ event_name คุณอาจไม่จำเป็นต้องให้ทุกคนยิง raw events table ตลอด

คุณสามารถมี scheduled query ที่สร้างตารางเช่น

analytics.daily_event_counts

โดยเก็บ

event_date
tenant_id
event_name
total_events

แล้วให้ dashboard วิ่งจาก summary table นี้แทน

ผลคือ

query เร็วขึ้น
cost ต่ำลง
dashboard เสถียรขึ้น
logic กลางถูกใช้ซ้ำได้

Query governance สำคัญพอ ๆ กับ technical tuning

ถึง schema ดีแค่ไหน ถ้าทีมไม่มีวินัย cost ก็ยังบานได้อยู่ดี

สิ่งที่ควรมีอย่างน้อยคือ

กติกาว่า recurring queries ต้อง review
naming ของ scheduled jobs ชัด
รู้ว่า dashboard ไหนยิง query อะไร
table raw กับ table reporting แยกชัด
ไม่ปล่อย exploratory SQL ไปอยู่ใน production BI โดยตรง

BigQuery cost control จึงเป็นทั้งเรื่อง data modeling และเรื่อง workflow ของทีมพร้อมกัน

ข้อผิดพลาดที่เจอบ่อย

1) มี partition แต่ไม่ได้ใช้ใน query จริง

นี่คือของที่เจอบ่อยที่สุด

2) ใส่ cluster แบบไม่ดู access pattern

สุดท้ายไม่ได้ช่วยอะไรเท่าที่หวัง

3) ใช้ `SELECT *` ใน query ที่รันซ้ำ

ทำให้ scan columns เกินจำเป็นตลอดเวลา

4) ให้ dashboard ยิง raw events table ตรง ๆ ทุกครั้ง

โดยไม่มี summary layer สำหรับคำถามที่ตายตัวอยู่แล้ว

5) ไม่แยก raw, intermediate และ reporting tables

ทำให้ทุกอย่างไปกองที่ table ใหญ่ตัวเดียว

6) ไม่คิดเรื่อง retention

ปล่อยข้อมูลโตไปเรื่อย ๆ โดยไม่มี lifecycle policy

รีวิวเชิง production-minded

Correctness

การคุม cost ที่ดีไม่ควรทำให้ข้อมูลผิดหรือรายงานเพี้ยน ดังนั้นการสร้าง summary tables หรือ pre-aggregations ต้องมีเจ้าของและ logic ที่ชัด ไม่ใช่ optimize จนความหมายของข้อมูลเริ่มไม่ตรง

Security

ยิ่งมี reporting layers และ derived tables มากขึ้น ยิ่งต้องคิดเรื่อง access control ด้วยว่าใครควรเห็น raw data, ใครควรเห็นเฉพาะ summary และ field ใดมีความอ่อนไหว

Efficiency

partition, cluster, prune และ materialized thinking ช่วยได้จริงเมื่อใช้ถูกจุด แต่จะได้ผลมากที่สุดเมื่อ schema, query patterns และ repeated workloads สอดคล้องกัน

Error handling

ปัญหาของ BigQuery cost control มักไม่แสดงเป็น error ตรง ๆ แต่แสดงเป็นบิลที่โตขึ้นและ workloads ที่อ่านเกินจำเป็น ดังนั้นการ review และ monitoring ต้องเกิดก่อนปัญหาจะสะสมยาว

Checklist สั้น ๆ ก่อนปล่อยตารางและ query ใช้งานจริง

table analytics ที่โตตามเวลามี partition แล้วหรือยัง
query ใช้ partition field ตรง ๆ หรือไม่
cluster fields อิงจาก filter patterns จริงหรือไม่
recurring queries เลิกใช้ SELECT * แล้วหรือยัง
dashboard สำคัญใช้ summary table ได้หรือไม่
raw tables กับ reporting tables แยกชัดหรือยัง
joins ที่ใช้ซ้ำบ่อยควรถูก materialize หรือไม่
retention และ expiration policy ถูกคุยแล้วหรือยัง
team มี query review discipline สำหรับ workloads ที่รันซ้ำหรือยัง
มีวิธีแยก exploratory workload ออกจาก production reporting หรือยัง

บทความที่ควรอ่านต่อ

สรุป

BigQuery cost control ไม่ได้เริ่มจากการห้ามคน query แต่มักเริ่มจากการออกแบบ schema และตารางให้สอดคล้องกับรูปแบบการอ่านจริง แล้วทำให้ query ที่ทีมใช้ประจำ scan เฉพาะข้อมูลที่จำเป็น

partition ช่วยตัดช่วงเวลา
cluster ช่วยแคบข้อมูลภายในช่วงนั้น
pruning ช่วยลดทั้ง rows และ columns ที่อ่าน
และ summary layers ช่วยลดการ scan raw tables ซ้ำ ๆ

สรุปสั้นที่สุดคือ

BigQuery จะคุ้มเมื่อคุณทำให้คำถามแต่ละข้ออ่านข้อมูลเท่าที่จำเป็นจริง
ไม่ใช่โยนข้อมูลทั้งก้อนให้ engine แล้วหวังว่าค่าใช้จ่ายจะคุมตัวเองได้