สวัสดีผู้อ่านทุกท่านครับ วันนี้เราจะมาเจาะลึกเรื่อง BigQuery Editions ซึ่งเป็นฟีเจอร์ที่น่าสนใจมากสำหรับผู้ที่ใช้งาน Google BigQuery โดยเฉพาะอย่างยิ่งกับผู้ที่ต้องการควบคุมค่าใช้จ่ายในการวิเคราะห์ข้อมูลขนาดใหญ่ BigQuery Editions นั้นเป็นรูปแบบการคิดค่าใช้จ่ายที่ยืดหยุ่นกว่าเดิม ทำให้เราสามารถปรับแต่งการใช้งานให้เหมาะสมกับ Workload ของเราได้มากขึ้น และที่สำคัญคือช่วยให้เราสามารถคาดการณ์ค่าใช้จ่ายได้แม่นยำยิ่งขึ้น
BigQuery Editions คืออะไร?
BigQuery Editions เป็นรูปแบบการคิดค่าใช้จ่ายของ Google BigQuery ที่ให้ความยืดหยุ่นในการเลือกใช้ทรัพยากร โดยจะคิดค่าใช้จ่ายตามจำนวน Slot Hour ที่ใช้งานจริง ซึ่ง Slot นั้นก็คือ หน่วยวัดกำลังการประมวลผลของ BigQuery นั่นเอง
โดยใน 1 Slot มองว่ามันเป็น CPU, RAM และ Network ที่ใช้ในการประมวลผลนั่นเอง สำหรับท่านใดที่ต้องการลงรายละเอียดกับ BigQuery Editions บทความนี้มีคำตอบครับ
Slot Auto Scaling: หัวใจสำคัญของ BigQuery Editions
Slot Auto Scaling คือกลไกที่ช่วยให้ BigQuery สามารถปรับขนาดทรัพยากรขึ้นลงได้โดยอัตโนมัติ ตามปริมาณงานที่เข้ามาในแต่ละช่วงเวลา ทำให้เราไม่ต้องเสียค่าใช้จ่ายมากเกินไปสำหรับทรัพยากรที่ไม่ได้ใช้งานเปรียบเทียบดังภาพข้างล่างครับ
การ Auto Scaling แบบรวดเร็วขยับตามการใช้งานทำให้ BigQuery สามารถ Utilize resource และ Cost ได้อย่างมีประสิทธิภาพครับ
ทำไมต้อง BigQuery Editions?
ควบคุมค่าใช้จ่ายได้แม่นยำ
โดยปกติแล้ว BigQuery จะคิดเงินแบบ On-demand โดย Default เป็นวิธีจ่ายตามข้อมูลที่ Scan ซึ่งหากข้อมูลมีขนาดใหญ่เราก็จะ scan ข้อมูลมากขึ้นและหากมี User มี Job ขนาดใหญ่แบบนี้ต่อเนื่อง เราก็อาจไม่แน่ใจว่า Cost จะวิ่งไปจบที่เท่าไร
ด้วยการคิดค่าใช้จ่ายตาม Slot Hour ทำให้เราสามารถคาดการณ์ค่าใช้จ่ายได้ล่วงหน้า กล่าวคือเราสามารถ Reserve slots เป็น Baseline slots ที่ 200 และ Max reservation size slot ที่ 200 ได้ การตั้งค่าแบบนี้จะทำให้ Slot ถูก Reserve ที่ 200 ตลอดเวลา ทำให้เราวางแผนได้ว่าแต่ละเดือนเราจะจ่ายที่เท่าไหร่
การตั้งค่าแบบนี้จะทำให้ไม่มีช่องว่างในการ Autoscale สังเกตว่า Autoscale Slots จะเป็น 0 แต่เราสามารถคำนวณได้ว่าเราจะเสียค่าใช้จ่าย $0.06 slot/hour หนึ่งเดือนมี 730 hours ค่าใช้จ่ายจึงคิดเป็น 730 hours x 200 slots x $0.06 slot/hour = $8,760/month ดังภาพข้างล่างครับ
การตั้ง Baseline slots เป็น 200 เปรียบเสมือนเราเช่าเหมาเครื่องไว้แล้ว เราจะ Query มากหรือน้อยก็จ่ายราคาเท่าเดิมครับ ซึ่งต่างจาก On-demand คือถ้าเราไม่ใช้เราก็ไม่เสียเงิน แต่ถ้าใช้งานมากก็ตั้ง Baseline slots ก็เป็นตัวเลือกที่คุ้มค่า
อีกตัวอย่างหนึ่งคือถ้าเราตั้ง Baseline slots ที่ 200 และ Max reservation size slots ที่ 400 จะมี Gap ให้ BigQuery สามารถ autoscaling ได้จาก 200 เป็น 400
เมื่อช่องว่างเผื่อให้ Auto scaling ตามการประมวลผลได้ ก็จะขึ้นอยู่กับการใช้งานครับว่าหนักหน่วงจน BigQuery ต้องขยายตัวหรือไม่ตาม Workload ข้างล่างเลย
หากเราประมาณ 100 – 200 Slots ก็จะอยู่ใน Baseline slots ที่เราจองไว้ เราจึงใช้ Slots used ที่ 200 ค่าใช้จ่ายก็ประมาณ $8,760/month แต่หากมีจังหวะที่ job ใช้งานมากกว่า 200 Slots ระบบจะ Autoscaled ให้อีก 100 รวมใช้ slots เป็น 300 เราจะเสียที่ $13,140/month
การใช้ 300 Slots สำหรับ Use case นี้เท่ากับว่าเรา Utilization resource ของเราประมาณ 75% แต่ถ้าเราใช้ 100% ก็คือเรา Slot ไป 400 Slots เท่ากับที่เราตั้ง Max reservation ไว้ครับ
สมมติเราใช้เต็มที่ 400 Slots ต่อเดือน ค่าใช้จ่ายเราจะเท่ากับ 730 hours x 400 slots x $0.06 slot/hour = $8,760/month = $17,520/month
นั่นหมายความว่าการตั้ง Baseline slots ที่ 200 และ Max reservation size slots ที่ 400 จะทำให้เราประมาณการค่าใช้จ่ายต่อเดือนของ BigQuery ต่ำสุดอยู่ที่ $8,760 สูงสุดอยู่ที่ $17,520 ในช่วงนี้ราคานี้ครับขึ้นอยู่กับ Workload นี่จึงเป็นไอเดียในการตั้งค่า Workload ทั้ง Baseline slots และ Max slots ให้เหมาะสมเพื่อการคาดการณ์ค่าใช้จ่ายได้อย่างแม่นยำครับมีอีกจุดหนึ่งที่ผมต้องการเน้นย้ำในตัว Slots กับราคาคล้ายเหมาจ่ายแบบนี้ครับ คือ On-demand ที่เป็น Pay as you go นั้น ราคา Query เริ่มต้น $6.25 per TiB (region US) จะได้ใช้ Slot เต็มสูบเลยคือ 2,000 Slots ขณะที่แบบ BigQuery Edtions เราเป็นคนกำหนด Slot usage เอง ดั้งนั้นบาง Jobs ใหญ่ๆ ที่หลายคน Query พร้อมกัน อาจทำให้ Concurrent สูงจนต้องต่อคิวกันใช้ตาม Concept Slot resource economy ทำให้อาจรู้สึกว่าช้ากว่าหรือเปล่า จริงๆ แล้วมันก็อาจจะกำลังต่อ Queue อยู่ก็ได้ครับ
ภาพตัวอย่างกรณีที่เรา Reserved ไว้ 1,000 slots แต่มี Concurrent ที่ Consume slots เกิน 1,000
ภาพตัวอย่างเคสที่ มี Slots อยู่ 2,000 จะมีการบริหารจัดการ Resource อย่างคุ้มค่าที่สุดด้วย Fair scheduling
ปรับขนาดได้ตามต้องการ
Slot Auto Scaling ทำให้เราสามารถปรับขนาดทรัพยากรขึ้นลงได้ตามปริมาณงานจริง จ่ายเท่าที่ใช้ จึงไม่จำเป็นต้องจ่ายหรือเช่า Server สำหรับ Data Warehouse แบบอื่นๆ ที่ต้องลงทุนสูงแต่ใช้จริงน้อย แถม BigQuery Editions ยังมีการ commitments แบบ 1 ปีและ 3 ปี ทำให้ได้ส่วนลดที่มากกว่าเดิม
ผมเปรียบ BigQuery Editions เหมือน Pay as you go แบบคิดค่าใช้จ่ายตาม slot usage หากเรา set baseline slot เป็น 0 และ max slot เป็น 100 ก็เท่ากับว่าเวลาใช้งานจริง BigQuery จะค่อย Autoscale slot ให้เป็น 100 ครับ
เหมาะสำหรับ Workload ที่มีความผันผวน
BigQuery Editions เหมาะสำหรับ Workload ที่มีปริมาณงานไม่คงที่ เช่น การวิเคราะห์ข้อมูลรายวัน หรือ การ ELT, ETLT หรือมหกรรมแคมเปญต่างๆ ที่ต้องกวาดข้อมูลจำนวนมากว่าวิเคราะห์ เช่น Black Friday, 11.11 เป็นต้น รวมถึงกรณีที่เราปั่นข้อมูลขนาดใหญ่ เช่น ทำ SCV (Single Customer View) กวาดข้อมูลลูกค้าเป็น 10 ปี ทุก Sales, ทุกพฤติกรรมกับ Business ในเครือ ตัว BigQuery Edtions เหมาะอย่างยิ่งสำหรับ Query ประเภทนี้ครับ
BigQuery Editions เหมาะกับงานประเภทใด?
BigQuery Editions เหมาะสำหรับงานวิเคราะห์ข้อมูลขนาดใหญ่ที่ต้องการความยืดหยุ่นและประสิทธิภาพสูง เช่น
- การวิเคราะห์ข้อมูลเชิงปริมาณ: เช่น การวิเคราะห์ข้อมูลการขาย, การวิเคราะห์พฤติกรรมผู้ใช้
- การสร้างรายงาน: เช่น การสร้าง Dashboard, การสร้าง Report ที่ปั่นข้อมูลหลายพันล้านแถว
- การสร้างโมเดล Machine Learning: เช่น การ Training model เช่น Matrix Factorization
การคำนวณค่าใช้จ่ายของ Job บน BigQuery
โดยปกติที่เราใช้ On-demand เราสามารถคำนวณแต่ละ Job ที่ Scan data ไปว่ากี่ TiB ก่อนนำมาคูณกับ Rate ใช่ไหมครับ เช่น $6.25/TiB ซึ่ง BigQuery จะมี Table หนึ่งที่ชื่อว่า Information Schema เป็นตารางที่เก็บ Metadata ต่าง ๆ ใน BigQuery โดยที่เราสามารถใช้ข้อมูลจาก INFORMATION SCHEMA เพื่อติดตามค่าใช้จ่ายในการประมวลผลข้อมูลได้ครับ
ตัวอย่าง Query ข้างต้นจะแสดง byte ที่ Scan ราย user_email ออกมาในรอบ 30 วัน
| SELECT user_email, SUM(total_bytes_billed) AS bytes_billed FROM `region-us`.INFORMATION_SCHEMA.JOBS WHERE job_type = ‘QUERY’ AND statement_type != ‘SCRIPT’ AND date(creation_time) BETWEEN date_sub(CURRENT_DATE(), INTERVAL 30 day) AND CURRENT_DATE() GROUP BY user_email; |
เราสามารถเขียน Query เพื่อคำนวณเป็น Cost ของ On-demand ต่อได้ดังนี้ครับ
| SELECT user_email, COUNT(job_id) as num_jobs, SUM(total_bytes_billed) AS bytes_billed, SUM(total_bytes_billed) / 1024 / 1024 / 1024 / 1024 * 6.25 AS cost, FROM `region-us`.INFORMATION_SCHEMA.JOBS WHERE job_type = ‘QUERY’ AND statement_type != ‘SCRIPT’ AND date(creation_time) BETWEEN date_sub(CURRENT_DATE(), INTERVAL 30 day) AND CURRENT_DATE() GROUP BY user_email; |
ลักษณะการคำนวณข้างต้นเราสามารถคำนวณกับ on-demand ได้อย่างตรงไปตรงมา และเราก็สามารถคำนวณ Slot ที่ใช้ผ่าน Field total_slot_ms ของแต่ละ Jobs ได้ครับว่าใช้ Slot เท่าไร มากหรือน้อยเพื่อที่จะวางแผนไปใช้ BigQuery Editions ได้ ซึ่งบน BigQuery documents จะมีตัวอย่าง Query ให้เรานำไปใช้ได้ครับ
แต่จุดสำคัญคือตรงนี้ หากเราคำนวณ Slot ที่ใช้ในแต่ละ Job ด้วย Information Schema เราจะทราบว่าแต่ละ Job ใช้ Slot เท่าไรเป็นตัวเลขจริง ไว้ประเมินความซับซ้อนหรือทรัพยากรที่ใช้ แต่ไม่สามารถเอา avg_slots ที่คำนวณได้ไปคูณกับราคาของ BigQuery Edtions ที่เป็น slot hours เช่น $0.04 สำหรับ Standard หรือ $0.06 สำหรับ Enterprise ได้
นั่นเพราะว่า Total_slot_ms ที่ใช้ของแต่ละ Job ไม่ได้หมายถึง BigQuery autoscale slot ไปเท่าไรแล้ว สมมติว่าใช้ไป 12.5 slot hours ใน Job นี้ แต่ Slot ที่ Scale ไปแล้วจริงๆ คือ 50 แล้วค่อยลดมาใช้เป็น 12.5 ในลำดับถัดไป
คล้ายกับเราเช่ารถแล้วเติมน้ำมันรถไป 50 ลิตร แต่ใช้ขับจริงๆ 12.5 ลิตร เราก็ต้องเสียค่าน้ำมันที่เติมตอนแรกไป 50 ลิตรนั่นเอง อันนี้เป็นวิธีเปรียบเปรยเฉย ๆ นะครับ ในเชิงเทคนิคอาจไม่ได้ต้องจ่าย 50 ลิตรซะทีเดียว มันก็จะมีเครื่องมือที่เอาไว้ Monitoring การ Scale ได้เรื่องที่ผมเล่ามาข้างต้นสัมพันธ์กับกระบวนการ Slot autoscaling ตรงนี้ผมอยากให้ศึกษา Best practices ให้ดีครับ โดยผมขออนุญาตยก 2 ข้อแรกขึ้นมาดังนี้
ข้อแรกบอกไว้ว่าให้ตั้งค่า Autoscaling slots ให้ดี (ก็คือ Baseline slots กับ Max slots) ตามการใช้งานทีผ่านมาและ Performance ที่คาดหวังครับ (สามารถใช้ Information schema ที่อธิบายข้างต้นได้) และหลังใช้แล้วก็ต้อง Monitor ด้วยนะครับ เพื่อปรับให้เป็นตามที่คาดหวัง ไม่ใช่ตั้งค่าแล้วจบเลย ปล่อยผ่าน อันนี้ต้องระวังครับ
ข้อสอง Autoscaler มีขั้นต่ำ 1 นาทีก่อนจะ Scale down ดังนั้นเราโดน Charge เริ่มต้น 1 นาทีครับ (ค่าใช้จ่ายก็คือ Slot hours ที่ Scale ขึ้นไป ณ ตอนนั้นหารด้วย 60) จึงต้องตั้งค่าให้ดีหากตั้ง Autoscale slots สูงไปแล้ว Job นั้นเสร็จไวมากในหลักวินาที เราก็เสียค่า Slots เต็ม 1 นาทีครับ
แต่ถ้าตั้ง Max slots น้อยลงครึ่งนึงของ Job ที่ใช้ปัจจุบัน ตัว Query นี้ก็จะใช้ Slots น้อยลง ส่งผลให้เวลาที่ประมวลผลมากขึ้น ซึ่งอาจจะลดการสูญเสีย Slots ที่ Scale ไปโดยเปล่าประโยชน์ได้ครับ แนะนำให้ Monitor job ผ่านเครื่องมือ Slot recommendations บน BigQuery ครับ
นี่ก็เป็นตัวอย่าง Best practices 2 ข้อแรกครับ ส่วนข้ออื่น ๆ ก็สามารถศึกษาได้ที่ Autoscaling best practices ได้เลย
ดังนั้นเราต้องทดในใจว่าถ้าเราตั้ง Baseline slot ที่ 0 และ Max slots ที่ 400 ก็มีโอกาสที่ Slot จะ Scale ไปถึง 400 ในแต่ละ Query ซึ่งอาจจะมากเกินความจำเป็นก็ได้ครับ เราจึงต้อง Monitor metadata เหล่านี้กับ Table อีกตัวนึงที่จะแนะนำให้รู้จักคือ RESERVATION_CHANGES กับ CAPACITY_COMMITMENT_CHANGE
วิธีการคำนวณค่าใช้จ่าย BigQuery Editions ที่ถูกต้อง
ปกติแล้วการแกะ Logs การใช้งาน BigQuery Editions ค่อนข้างซับซ้อนครับ เพื่อให้ออกมาในรูปแบบ Table เพราะต้องดูเทียบระหว่าง Baseline & Scaled slot change และ Committed slots change ซึ่ง Google ได้มีการทำ Script ไว้แล้วที่ Monitor autoscaling with information schema รองไปรันดูได้ครับ
เนื่องจากเราไม่ได้ใช้ BigQuery Editions แบบ Commitment รายปี จึงใช้ตัวอย่าง Script แบบ Non-covered scenarios ได้ครับ และภาพข้างล่างเป็นผลลัพธ์ตัวอย่างของ BigQuery Standard Edtions ของผมที่กำหนด Range ระยะเวลา 1 เดือน
เนื่องจากข้อมูลที่ทำ Report ผมมีขนาดใหญ่ประมาณ 3,200 ล้านแถว 2 TB การคิดแบบ On-demand แล้วหมุน Report บ่อยอาจทำให้เสียค่า Scan เยอะ จึงเป็นที่มาในการนำ BigQuery Project นี้เป็น Standard editions โดยกำหนด Baseline slots เป็น 0 และ Max slots เป็น 200 ครับ
ผลลัพธ์ที่ได้จากการคำนวณ Period เวลา 1 เดือน total_slot_seconds ของผมมีค่า 793350 เมื่อคำนวณเป็น Slot hours จะได้ประมาณ 220 Slot hours คิดเป็นเงินประมาณ $8.8 เท่านั้นเอง ซึ่งนี่ก็เป็นอีก 1 Use case ที่ผมใช้ครับ
เคล็ดลับในการลดค่าใช้จ่าย BigQuery Editions
- ปรับแต่ง Parameter ให้ดี: ไม่ว่าจะเป็นค่า Baseline slots หรือ Max slotsให้เหมาะสมกับขนาดข้อมูลหรือ BigQuery Project ที่จะใช้ Slots
- ออกแบบ Query ให้มีประสิทธิภาพ: ใช้ PARTITION BY, CLUSTER BY, และ WHERE clause เพื่อลดปริมาณข้อมูลที่ต้องประมวลผล
- ใช้ BI Engine: เพื่อ Cache เพื่อเก็บ Table ที่ถูกเรียกใช้บ่อย ๆ โดยปกติ BigQuery Enterprise Editions ขึ้นไปที่ Commitment slot จะมี BI Engine แถมมาให้ด้วย
- เลือก Edition ที่เหมาะสม: เลือก Edition ที่ตรงกับความต้องการใช้งาน เช่น ถ้าทำ ML บน BigQuery ML ด้วยก็เลือกเป็น BigQuery Enterprise Editions
สรุป
BigQuery Editions เป็นตัวเลือกที่น่าสนใจสำหรับผู้ที่ต้องการควบคุมค่าใช้จ่ายในการใช้งาน BigQuery โดยการทำความเข้าใจหลักการทำงานของ Slot Auto Scaling และการใช้เครื่องมือสำหรับ Monitor เช่น Slot recommendations จะทำให้เราสามารถวางแผนการใช้ทรัพยากรได้อย่างมีประสิทธิภาพครับ
