ส่งออกข้อมูล LINE OA ไป BigQuery เอง กับจ้างทำ ETL สำเร็จรูป แบบไหนคุ้มกว่ากัน

ทีมการตลาดของบริษัทหนึ่งใช้ Google Sheets เก็บข้อมูลแชทจาก LINE OA มาสองปี วันหนึ่งไฟล์เริ่มโหลดช้าจนเปิดแล้วค้าง สูตร VLOOKUP ที่เคยทำงานปกติเริ่มพังเพราะแถวข้อมูลใกล้แตะขีดจำกัดของ Sheet เจ้าของธุรกิจถามหาสาเหตุ แล้วก็ถูกบอกว่า 'ข้อมูลเยอะเกินไปแล้ว ต้องย้ายไปที่อื่น'

จุดนี้เองที่หลายทีมเริ่มมองหา BigQuery เป็นที่เก็บข้อมูลถัดไป เพราะรองรับข้อมูลจำนวนมากและ Query เร็วกว่า Sheet หลายเท่า แต่คำถามที่ตามมาทันทีคือจะย้ายข้อมูลจาก LINE OA เข้า BigQuery อย่างไร เขียนเองหรือจ้างเครื่องมือสำเร็จรูป

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

สัญญาณอะไรบอกว่าถึงเวลาย้ายข้อมูล LINE OA จาก Sheet ไป BigQuery

Google Sheets มีขีดจำกัดจำนวนเซลล์ต่อไฟล์อยู่ที่ประมาณ 10 ล้านเซลล์ ฟังดูเยอะ แต่ถ้าธุรกิจบันทึกหลายคอลัมน์ต่อ Event เช่น User ID, ข้อความ, เวลา, สถานะ, แคมเปญที่มา และอีกหลายฟิลด์ ตัวเลขนี้จะหมดเร็วกว่าที่คิดเมื่อมี Event เข้ามาวันละหลายพันครั้งต่อเนื่องหลายเดือน

สัญญาณแรกที่ชัดที่สุดคือไฟล์เริ่มโหลดช้าจนกระทบการทำงานประจำวัน สัญญาณที่สองคือสูตรที่เคยคำนวณเร็วเริ่มค้างหรือ Error สัญญาณที่สามคือทีมเริ่มต้องแยกไฟล์เป็นหลายชีทตามเดือนเพื่อความเร็ว ซึ่งพอแยกแล้วการดึงข้อมูลย้อนหลังข้ามเดือนยิ่งยุ่งยากกว่าเดิม

อีกสัญญาณที่มักถูกมองข้ามคือความต้องการ Query ที่ซับซ้อนขึ้น เช่น อยากรู้ว่า Lead ที่มาจากแคมเปญหนึ่งเมื่อหกเดือนก่อนกลับมาซื้อซ้ำกี่คน คำถามแบบนี้ Sheet ทำได้ยากมากถ้าข้อมูลกระจายหลายไฟล์ ขณะที่ BigQuery ออกแบบมาเพื่อ Query ข้ามช่วงเวลายาวได้โดยไม่กระทบความเร็ว

สองเส้นทางหลักที่ใช้ส่งออกข้อมูล LINE OA เข้า BigQuery ได้จริง

เมื่อตัดสินใจย้ายไป BigQuery แล้ว คำถามถัดมาคือจะพาข้อมูลไปถึงตรงนั้นอย่างไร ทางเลือกหลักที่ทีมส่วนใหญ่ใช้กันมีสองแบบ คือเขียน Cloud Function รับ Webhook จาก LINE แล้วส่งเข้า BigQuery เอง กับใช้เครื่องมือ ETL สำเร็จรูปที่มี Connector ให้เลือกใช้โดยไม่ต้องเขียนโค้ดเอง

ตารางด้านล่างสรุปความต่างหลักของสองเส้นทางนี้ เพื่อให้เห็นภาพก่อนตัดสินใจว่าทางไหนเหมาะกับทีมและงบประมาณที่มีอยู่จริง:

เขียน Cloud Function เชื่อม Webhook เข้า BigQuery ทำอย่างไร

1. สร้าง Cloud Function ที่รับ HTTP Request จาก LINE Messaging API Webhook แล้วตรวจสอบลายเซ็นของ Request เพื่อยืนยันว่ามาจาก LINE จริง ไม่ใช่ Request ปลอมที่ยิงเข้ามาสุ่ม ๆ
2. แปลง Payload ของ Event ให้อยู่ในรูปแบบ JSON ที่ตรงกับ Schema ของตารางใน BigQuery ที่ออกแบบไว้ล่วงหน้า เช่น แยกฟิลด์ User ID, ประเภท Event, เวลา และข้อความออกเป็นคอลัมน์ที่ชัดเจน
3. ใช้ BigQuery Streaming Insert API เพื่อส่งข้อมูลเข้าตารางแบบเกือบเรียลไทม์ทันทีที่ Event เกิดขึ้น แทนที่จะรอ Batch เป็นรอบตามเวลาที่ตั้งไว้
4. ตั้ง Retry Logic และ Dead Letter Queue สำหรับ Event ที่ส่งเข้า BigQuery ไม่สำเร็จ เพื่อไม่ให้ข้อมูลหายไปเฉย ๆ เมื่อ BigQuery ตอบสนองช้าหรือมี Quota ชั่วคราว
5. เขียน Log การทำงานของ Cloud Function ทุกครั้งที่มี Event เข้ามา เพื่อให้ตรวจสอบย้อนหลังได้ว่า Event ใดถูกส่งสำเร็จหรือล้มเหลว โดยไม่ต้องเดาจากจำนวนแถวใน BigQuery เพียงอย่างเดียว

ใช้เครื่องมือ ETL สำเร็จรูปส่งข้อมูลเข้า BigQuery ต่างจากเขียนเองตรงไหน

เครื่องมือ ETL สำเร็จรูปหลายตัวในตลาดมี Connector ที่รับข้อมูลจากแหล่งต่าง ๆ รวมถึงบางตัวรองรับ Webhook หรือ API ทั่วไป แล้วส่งต่อเข้า BigQuery ให้อัตโนมัติตามตารางเวลาที่ตั้งไว้ จุดเด่นคือทีมไม่ต้องมีคนเขียนโค้ดเองตั้งแต่ต้น

ข้อจำกัดที่มักเจอคือ Connector สำเร็จรูปส่วนใหญ่ยังไม่มี Connector เฉพาะสำหรับ LINE Messaging API โดยตรง ทีมจึงต้องอาศัยตัวกลางอย่าง Make หรือ Zapier ส่งข้อมูลจาก LINE ไปที่ปลายทางกลาง เช่น Webhook รับข้อมูลทั่วไปหรือฐานข้อมูลชั่วคราว ก่อนที่เครื่องมือ ETL จะดึงต่อเข้า BigQuery อีกที ทำให้เส้นทางข้อมูลมีจุดเชื่อมมากกว่าที่คิดตอนแรก

ข้อดีของทางนี้คือเมื่อ LINE เปลี่ยนโครงสร้าง API ผู้ให้บริการเครื่องมือ ETL มักอัปเดต Connector ให้โดยที่ทีมไม่ต้องแก้โค้ดเอง แต่ก็ต้องแลกกับการพึ่งพาผู้ให้บริการภายนอก ถ้าเครื่องมือนั้นเปลี่ยนราคาหรือหยุดให้บริการ Connector บางตัว ทีมก็ต้องหาทางแก้อีกครั้ง

ออกแบบ Schema ตารางใน BigQuery ให้รองรับข้อมูล Event จาก LINE OA

ไม่ว่าจะเลือกทางไหน จุดร่วมที่สำคัญเท่ากันคือการออกแบบ Schema ตารางให้เหมาะกับการ Query ในอนาคต ไม่ใช่แค่เก็บข้อมูลดิบเข้าไปเฉย ๆ ตารางที่ออกแบบดีควรแยก Event หลักออกเป็นคอลัมน์ที่ชัดเจน เช่น event_type, user_id, timestamp, campaign_source และ message_text

การใช้ Partitioned Table ตามวันที่ของ Event ช่วยให้ Query ที่กรองตามช่วงเวลาทำงานเร็วขึ้นมาก และช่วยลดค่าใช้จ่ายของ BigQuery เพราะ Query จะสแกนเฉพาะ Partition ที่เกี่ยวข้องแทนที่จะสแกนทั้งตาราง ซึ่งเป็นแนวทางเดียวกับที่อธิบายไว้ใน การเก็บ Event จาก LINE OA เพื่อวิเคราะห์ Funnel ระยะยาว

ควรเผื่อฟิลด์สำหรับข้อมูลที่ยังไม่ได้ใช้ตอนนี้แต่มีแนวโน้มต้องใช้ในอนาคต เช่น ฟิลด์เก็บ Attribution ID ที่เชื่อมกับ Tracking Link จากโฆษณา เพราะการเพิ่มคอลัมน์ทีหลังทำได้ แต่การย้อนไปกรอกข้อมูลเก่าที่ไม่เคยเก็บไว้ทำไม่ได้เลย

ต้นทุนที่มองไม่เห็นตอนแรกของทั้งสองเส้นทาง

• ค่า Query ของ BigQuery คิดตามปริมาณข้อมูลที่สแกน — ถ้า Schema ออกแบบไม่ดีหรือไม่มี Partition Query ที่ควรถูกเงินน้อยอาจกลายเป็น Query ที่แพงขึ้นเรื่อย ๆ ตามปริมาณข้อมูลที่เพิ่มขึ้นทุกเดือน
• ค่าดูแล Cloud Function ระยะยาว — เมื่อ LINE ปรับโครงสร้าง API หรือ Field ของ Event เปลี่ยน ทีมที่เขียนเองต้องมีคนคอยตามข่าวและแก้โค้ดให้ทันเวลา ไม่ใช่ตั้งแล้วลืมได้
• ค่าบริการรายเดือนของเครื่องมือ ETL — มักคิดตามปริมาณ Event หรือจำนวน Connector ที่ใช้ ถ้าปริมาณ Event โตเร็ว ค่าใช้จ่ายส่วนนี้อาจโตเร็วกว่าที่ประเมินไว้ตอนเริ่มต้น
• เวลาของทีมที่เสียไปกับการเรียนรู้เครื่องมือใหม่ — ทั้งสองทางต้องมีคนในทีมที่เข้าใจว่าข้อมูลไหลอย่างไร ถ้าไม่มีใครเข้าใจภาพรวม เมื่อเกิดปัญหาจะแก้ไม่ได้ไม่ว่าจะเลือกทางไหนก็ตาม

ตรวจสอบคุณภาพข้อมูลหลังส่งเข้า BigQuery แล้วอย่างไร

การส่งข้อมูลสำเร็จไม่ได้แปลว่าข้อมูลถูกต้องเสมอไป สิ่งที่ควรตรวจสอบเป็นประจำคือจำนวนแถวที่เข้ามาต่อวันเทียบกับจำนวน Event ที่ควรจะมีตามปริมาณการสนทนาจริง ถ้าตัวเลขต่างกันมากผิดปกติ อาจมี Event บางส่วนหลุดหายระหว่างทาง

อีกจุดที่ควรตรวจคือค่าว่างในคอลัมน์ที่ไม่ควรว่าง เช่น user_id หรือ timestamp ถ้าพบค่าว่างจำนวนมาก มักเป็นสัญญาณว่า Mapping ฟิลด์ระหว่างต้นทางกับปลายทางมีปัญหา ต้องกลับไปตรวจที่ Cloud Function หรือ Connector ที่ใช้อยู่

ทีมที่ทำงานร่วมกับ Dashboard บน Looker Studio หรือ Power BI ควรตั้ง Query ตรวจสอบคุณภาพข้อมูลแยกต่างหากจาก Query ที่ใช้แสดงผล เพื่อไม่ให้ปัญหาข้อมูลผิดพลาดไปปรากฏบน Dashboard ที่ผู้บริหารดูโดยไม่มีใครรู้ตัวก่อน

ธุรกิจแบบไหนที่ยังไม่จำเป็นต้องย้ายไป BigQuery

ไม่ใช่ทุกธุรกิจที่ต้องรีบย้ายข้อมูลไป BigQuery ทันทีที่ได้ยินชื่อ ถ้าปริมาณ Event ต่อวันยังอยู่ในหลักร้อยและทีมไม่มีคนที่ถนัดเรื่อง Cloud หรือ SQL เลย การอยู่กับ Sheet ต่อไปอีกสักพักพร้อมจัดระเบียบไฟล์ให้ดีขึ้นอาจคุ้มกว่าการลงทุนย้ายระบบ

สัญญาณที่บอกว่าควรรอก่อนคือทีมยังตอบคำถามพื้นฐานจาก Sheet ได้ครบ เช่น รู้ว่าเดือนนี้มี Lead กี่คน มาจากแคมเปญไหนบ้าง โดยไม่ต้องรอโหลดไฟล์นานผิดปกติ ถ้ายังตอบได้ในเวลาที่สมเหตุสมผล การย้ายไป BigQuery ตอนนี้อาจเป็นการแก้ปัญหาที่ยังไม่เกิดขึ้นจริง

เมื่อธุรกิจถึงจุดที่ต้อง ออกแบบเส้นทางข้อมูลทั้งระบบ จริง ๆ ควรเริ่มจากทดลองกับข้อมูลส่วนน้อยก่อน เช่น เลือกแคมเปญเดียวมาทดสอบทั้งกระบวนการตั้งแต่ต้นจนจบ ก่อนขยายไปทั้งธุรกิจ เพื่อลดความเสี่ยงที่จะพบปัญหาใหญ่หลังลงทุนเวลาไปมากแล้ว

สรุป

การเลือกระหว่างเขียน Cloud Function เองกับใช้เครื่องมือ ETL สำเร็จรูปไม่มีคำตอบที่ถูกต้องตายตัว ขึ้นกับทรัพยากรทีม งบประมาณ และความยืดหยุ่นที่ธุรกิจต้องการในระยะยาว ทั้งสองทางใช้งานได้จริงถ้าออกแบบ Schema และวางระบบตรวจสอบคุณภาพข้อมูลไว้ตั้งแต่ต้น

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

• เขียน Cloud Function เองให้ความยืดหยุ่นสูงกว่าแต่ต้องมีทีมเทคนิคดูแลต่อเนื่อง
• เครื่องมือ ETL สำเร็จรูปลดภาระเริ่มต้นแต่มีค่าบริการรายเดือนและข้อจำกัดของ Connector
• Schema ที่ดีต้องมี Partition ตามวันที่และเผื่อฟิลด์สำหรับข้อมูล Attribution ในอนาคต
• ต้องตรวจคุณภาพข้อมูลหลังส่งเข้า BigQuery เป็นประจำ ไม่ใช่เชื่อว่าส่งสำเร็จแล้วจบ

คำถามที่พบบ่อย