BigQuery เป็น Data Warehouse ที่ได้รับความนิยมเป็นอย่างสูงทั่วโลก และมีการใช้งานหลากหลาย Use-cases รวมถึงใช้ Business Intelligence หรือ App จากหลากหลายค่ายเข้ามาเชื่อมต่อจำนวนมาก ทำให้หลายท่านอาจสงสัยว่าการใช้งาน BigQuery ผ่าน App ต่าง ๆ นั้น มีค่าใช้จ่ายเพิ่มเติมนอกเหนือจากค่าบริการ BigQuery เองหรือไม่ โดยเฉพาะค่า Network Egress หรือค่าธรรมเนียมการดึงข้อมูลออกจากระบบ Google Cloud Platform (GCP)
เข้าใจสถาปัตยกรรมของ BigQuery กันก่อน
BigQuery เป็น Data Warehouse แบบ Serverless ที่ทรงพลัง ซึ่ง Google เป็นผู้ดูแลจัดการทั้งหมด ผู้ใช้จึงสามารถโฟกัสไปที่การใช้งาน Query โดยไม่ต้องกังวลเรื่องการดำเนินงานต่าง ๆ เช่น การสำรองข้อมูลหรือการบำรุงรักษา
สถาปัตยกรรม Serverless ของ BigQuery ประกอบด้วย 2 ส่วนหลัก :
- Distributed Storage เป็นส่วนจัดเก็บข้อมูลที่กระจายกันอยู่ทั่วโลก มีความแข็งแกร่งทนทานสูง
- Cluster Compute เป็นส่วนที่ประมวลผล สามารถรองรับ Query ที่ขนาดใหญ่ซับซ้อนได้
ระบบทั้ง 2 ส่วนสามารถปรับขนาดได้ตามการใช้งานโดยอัตโนมัติ ผู้ใช้จึงไม่จำเป็นต้องตั้งค่าล่วงหน้า BigQuery จึงสามารถรองรับข้อมูลขนาดใหญ่ได้อย่างมีประสิทธิภาพ รองรับทั้งการนำเข้าข้อมูลแบบ Real-time และการ Query ข้อมูลเป็นพันล้านแถว โดยหน่วยจัดเก็บข้อมูลและหน่วยประมวลผลสื่อสารกันผ่านเครือข่ายความเร็วสูงภายใน Data Center ของ Google
จะเกิดอะไรขึ้นเวลาเรา Query ข้อมูลบน BigQuery
เมื่อเราเรียกใช้ Query ข้อมูลบน BigQuery ไม่ว่าจะผ่านหน้าเว็บ BigQuery UI หรือเครื่องมือ BI ต่าง ๆ ข้อมูลจะถูกแปลงเป็นภาษา SQL และส่งไปยัง BigQuery โดยอัตโนมัติ เมื่อมีคำสั่ง SELECT เกิดขึ้น BigQuery จะดึงข้อมูลจากที่จัดเก็บแบบกระจาย (Distributed Storage) ไปยัง Worker Nodes ต่าง ๆ เพื่อการประมวลผลลัพธ์
ไม่ว่าจะใช้ระบบคิดเงินแบบ On-demand หรือ BigQuery Editions การประมวลผลผลลัพธ์จะเหมือนกันดังนี้
- สร้าง Job : ขั้นแรก BigQuery จะสร้าง Job ขึ้นมาหนึ่ง Job สำหรับ Query แต่ละครั้ง
- ประมวลผลลัพธ์ : Worker Nodes จะประมวลผลข้อมูลและสร้าง Temporary Table เก็บผลลัพธ์ชั่วคราว
- แสดงผลลัพธ์ : ผู้ใช้สามารถอ่านหรือแสดงผลลัพธ์จาก Temporary Table นี้ได้
- ลบ Temporary Table : โดยปกติ Temporary Tables จะถูกลบโดยอัตโนมัติหลังจาก 24 ชั่วโมง
สังเกตจากภาพด้านล่าง จะเห็นว่าผลลัพธ์จากการ Query ข้อมูลบน BigQuery จะถูกเก็บไว้ใน Temporary Table ซึ่งเป็นเหมือน Cache เก็บข้อมูลชั่วคราว ผู้ใช้สามารถคลิกเพื่อดูรายละเอียดของ Table นี้ได้
หลายคนอาจสงสัยว่าผลลัพธ์ที่เก็บใน Temporary Table นี้ จะเสียค่า Network Egress หรือไม่ ? เพราะโดยปกติ Cloud Provider แต่ละเจ้า จะเอาข้อมูลออกก็ต้องเสียค่า Network กันทั้งนั้น ซึ่งเราจะอธิบายให้กระจ่างกันครับ
การ Query แบบต่าง ๆ บน BigQuery อย่างลึกซึ้ง
ในบทความนี้ผมจะอธิบายวิธีการ Query แบบต่าง ๆ บน BigQuery 3 รูปแบบที่ผู้ใช้ส่วนใหญ่ใช้งานกัน พร้อมทั้งอธิบายประเด็นสำคัญเรื่องค่า Network Egress ว่ามีผลต่อการใช้งานอย่างไร
On-demand Query
วิธีการ Query แบบนี้เป็นที่นิยมมากที่สุด ผู้ใช้สามารถใช้งานผ่าน BigQuery UI หรือเครื่องมือ BI ต่าง ๆ เช่น Looker Studio
เมื่อมีการ Query ข้อมูล BigQuery จะแปลงคำสั่งเป็น SQL และส่งไปประมวลผลบน Cluster Compute ผลลัพธ์จะถูกเก็บไว้ใน Temporary Table ชั่วคราว
เบื้องหลังที่เป็น SQL จะมีลักษณะดังภาพด้านล่างนี้
ในส่วนนี้ ผู้ใช้ไม่ต้องเสียค่า Network Egress โดยได้มี Document ระบุในหมวด Data Extraction ที่เกี่ยวกับ Data Transfer ว่าจะไม่ถูกคิดค่าบริการเมื่อใช้ Query Results ใน GCP หรือจาก BigQuery APIs ครับ ซึ่งแอปฯ ส่วนใหญ่โดยพื้นฐานจะใช้ BigQuery APIs ยกเว้นถ้าเราใช้ BigQuery Storage Read APIs ซึ่งเป็นคนละตัวกันจะมีค่าบริการคนละแบบ โดยจะกล่าวถึงในหัวข้อถัดไปครับ
Data Extraction
BigQuery มีวิธีในการเอาข้อมูลออกไปทั้งก้อนโดยนอกเหนือวิธีการพื้นฐานข้างต้นดังนี้ครับ
1. Batch Export คือการ Export ข้อมูลทั้งตารางลง Cloud Storage ไปใช้ต่อหรือประมวลผล ซึ่งตรงนี้ไม่เสียค่าใช้จ่ายครับ แต่หากนำ Data จาก Cloud Storage ออกไปข้างนอกก็จะเสียค่า Egress ซึ่งจะเกิดขึ้น Cloud Storage ไม่ใช่ BigQuery
2. Export Query Results แต่หากต้องมีการ Query เพื่อควบคุมผลลัพธ์ด้วย ถ้าอิงจากข้อ 1 การ Export ไม่เสียค่าบริการครับ แต่การเขียน Statement ดังภาพข้างล่างเพื่อเลือก field ด้วยจะมีค่าบริการตามโมเดลคิดเงินที่เราเลือกไว้ครับ เช่น On-demand หรือ BigQuery Edtions ส่วนการ Egress ก็จะเหมือนข้อ 1 เลย คือคิดเงินจังหวะที่ข้อมูลออกจาก Cloud Storage
3. Streaming Reads หรือการใช้ Storage Read API การใช้ API ตัวนี้จะเร็วกว่าการอ่านข้อมูลจาก BigQuery ด้วย BigQuery APIs ปกติ กล่าวคือเรากำลังใช้ APIs ที่คุยกับ Table ใน Storage โดยตรง ไม่ผ่านหน่วยประมวลผลครับ โดยการใช้ API ตัวนี้จะต้องเขียนแอปฯ สร้าง Session ขึ้นมาคุยกันบน Protocol RPC แบบ Stream ไม่ได้คุยกันด้วย REST API แล้ว เป็นอีกหนึ่งเหตุผลที่ทำให้ API ตัวนี้ทำงานเร็ว ส่วนใหญ่จะใช้บน Library Java, Python เขียนไปดูดข้อมูลมาครับ
โดยหากเราเลือกใช้ APIs ตัวนี้เราจะเสียค่าใช้จ่ายประมาณ 3 ตัวครับ ตัวแรกคือ Streaming reads ซึ่งเราจะได้ Read ฟรี 300 TiB ต่อเดือน เกินกว่านั้นก็คิดตามตารางครับ
ตัวที่สองคือ Query หากเรามีการเขียน SQL Statement ควบคุมผลลัพธ์แบบข้อที่ 2 เราก็จะโดนคิดค่าบริการตามโมเดลคิดเงินที่เลือกไว้ครับ และตัวที่สามสุดท้ายคือ Egress Data Transfer ตาม Rate ปกติครับ ตัวอย่างนี้จะเป็น Internet Egress
จริง ๆ ถ้าเราเป็น Network Transfer ที่อยู่ภายใน Google ก็อาจจะไม่ได้เสียค่าใช้จ่ายครับ เราต้องเช็กตารางนี้อีกครั้งหนึ่ง
สำหรับ Storage Read API ก็จะแนะนำให้ใช้สำหรับเหล่า Developer ครับ เพราะทำงานได้ไวเหมาะกับ Application แต่ถ้าสาย Business Users ที่ไม่ได้ Dev เน้นใช้ SQL ก็คงจะไม่ได้ปฏิสัมพันธ์กับส่วนนี้เท่าไรครับ ยกเว้น BI Tools บางตัวที่เปิดให้ใช้ Storage Read API เพื่อความรวดเร็วในการดึงข้อมูลและใช้ขุมพลังสูงสุดของ BigQuery อย่าง Power BI และ Tableau
3rd Party Applications
ผู้พัฒนาส่วนใหญ่ก็ต้องการ App เรามีประสิทธิภาพสูงสุดใช่ไหมครับ ดังนั้นเขาจึงทำ Feature สำหรับใช้ BigQuery Storage Read APIs มาให้ด้วย เช่น Power BI, Tableau หากเราเชื่อมต่อ App เหล่านี้ไปที่ BigQuery โดยไม่ได้เปิด BigQuery Storage Read APIs แน่นอนครับว่าเราจะไม่เสียค่า Network Egress เสียแค่ค่า Query ธรรมดา แต่ถ้าเปิดใช้ก็จะเสีย Network ขาออกเหมือนที่ผมได้อธิบายในหัวข้อที่แล้วครับ
Power BI
ใน Power BI จะซ่อนเจ้าตัว Storage Read APIs ใน Advance Options ครับ ที่ชื่อว่า Use Storage API ถ้าเรา Set เป็น true ก็จะเป็นการเปิดใช้ Storage Read API ครับ ตาม Power BI Document นี้
Tableau
ใน Tableau เองก็มี Function นี้เช่นกันทำให้ใช้ Tableau Data Extracts ได้เร็วขึ้น ลองใช้ดูกับ BigQuery JDBC ตามประกาศนี้นะครับ
Conclusion
หลายท่านคงจะเข้าใจ Network Egress บน BigQuery กันมากขึ้นแล้วนะครับ โดยสรุปแล้วถ้าเรา Query ธรรมดา Basic เลย จะไม่เสียค่า Network Egress ถ้าเช็กใน Cloud Billing ก็จะเห็นเป็น SKU Analysis ธรรมดา
แต่ถ้าใช้ Options เป็นการ Query ผ่าน 3rd Party Tools ก็ต้องสังเกตดี ๆ ครับว่า เปิดการใช้ Storage Read APIs ไหม ถ้าเปิดก็มี Network Egress นิดหน่อยครับ ซึ่งไม่ต้องกังวลเลยมันค่อนข้างเล็กน้อยมาก เพราะส่วนใหญ่เราใช้ผลลัพธ์จาก Query ไม่ได้ดูดข้อมูลออกมาหลาย Terabyte ครับ เทียบกับผลลัพธ์และความเร็วนั้น มันค่อนข้างคุ้มค่ากว่ามาก ๆ ครับ
แต่หากเราดูด Data ออกมามากกว่า 1 Terabyte บ่อยครั้ง แสดงว่าเราเป็น Use-cases พิเศษที่ไม่ได้ทำเรื่อง SQL Analytics เพียงอย่างเดียว ก็อาจจะแนะนำเป็นการใช้ท่า Export Jobs แทน เหมือนที่แนะนำในหัวข้อข้างต้นนะครับ
หากท่านใดมีคำถามหรือต้องการปรึกษาผู้เชี่ยวชาญจากแทนเจอรีนในการออกแบบ Data Analytics Platform
หรือใช้บริการ Google Cloud อย่างการทำ Local Billing ก็สามารถปรึกษาทีมแทนเจอรีนได้ทันทีครับ
เรามีผู้เชี่ยวชาญที่ได้รับการรับรองในทุก ๆ สาขาพร้อมให้คำปรึกษาทุกท่าน
