ตรวจสอบโครงสร้างการจัดเก็บล็อกอีเวนต์และข้อมูลที่โหลดไม่สำเร็จ: การส่งล็อกอีเวนต์ ตอนที่ 4

Hive Analytics · 29 ตุลาคม 2569 · อ่าน 5 นาที

ในบรรดาอีเวนต์ที่ส่งไปยัง Hive Analytics อีเวนต์ที่ผ่านเกณฑ์การเก็บข้อมูลจะถูกจัดเก็บใน t_raw_event_log ของชุดข้อมูล BigQuery ของแต่ละบริษัท ส่วนอีเวนต์ที่ไม่ผ่านเกณฑ์จะถูกจัดเก็บใน t_raw_event_log_rescue พร้อม JSON ต้นฉบับและเหตุผลที่ถูกกักกัน หากไม่พบอีเวนต์ในตารางปกติ ให้ตรวจสอบสาเหตุที่ถูกกักกันจาก errorReason, errorStackTrace และ rawData ในตาราง rescue ตัวอย่างเช่น หาก eventTime ไม่เป็นไปตามรูปแบบ RFC 3339 อีเวนต์จะถูกกักกันด้วยข้อผิดพลาด 201 (DATETIME_INVALID) ในกรณีนี้ให้แก้ไขรูปแบบเวลา ส่งอีเวนต์อีกครั้ง แล้วตรวจสอบว่าอีเวนต์ถูกจัดเก็บในตารางปกติแล้ว

ตรวจสอบผลการจัดเก็บอีเวนต์ที่ส่งไป

"ส่งข้อมูลเกมเป็นล็อกอีเวนต์: การส่งล็อกอีเวนต์ ตอนที่ 3" ได้อธิบายวิธีส่งข้อมูลเกมจริงเป็นล็อกอีเวนต์ไปแล้ว ตอนนี้จะดูโครงสร้างการจัดเก็บอีเวนต์ที่ส่งไป รวมถึงเหตุผลที่อีเวนต์ซึ่งจัดเก็บไม่สำเร็จถูกกักกันและวิธีตรวจสอบ

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

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

โครงสร้างการจัดเก็บอีเวนต์ของ Hive Analytics

ข้อมูลอีเวนต์

อีเวนต์ที่ Hive Analytics เก็บได้ตามปกติจะถูกจัดเก็บในตาราง t_raw_event_log ของชุดข้อมูล BigQuery ของแต่ละบริษัท ตารางนี้แบ่งพาร์ทิชันรายวันตาม dateTime และจัดเก็บข้อมูลพื้นฐานของอีเวนต์พร้อมกับพร็อพเพอร์ตี้

ฟิลด์	ชนิดข้อมูล	คำอธิบาย	วิธีสร้าง
`userId`	STRING	ค่าที่ระบุผู้ใช้ตามบัญชี	ส่งเป็นพร็อพเพอร์ตี้ที่จำเป็น
`identifierProvider`	STRING	ระบบที่ออกตัวระบุผู้ใช้	ส่งเป็นพร็อพเพอร์ตี้ที่จำเป็น
`deviceId`	STRING	ค่าที่ระบุผู้ใช้ตามอุปกรณ์	ส่งเป็นพร็อพเพอร์ตี้ที่จำเป็น
`appId`	STRING	ค่าที่ระบุแอปที่เกิดอีเวนต์	ส่งเป็นพร็อพเพอร์ตี้ที่จำเป็น
`appIdGroup`	STRING	ค่าที่รวมหลายแอปเป็นเกม (โปรเจกต์) เดียว	สร้างอัตโนมัติจาก `appId`
`dateTime`	TIMESTAMP	เวลาที่เกิดอีเวนต์ซึ่งแปลง `eventTime` เป็น UTC	สร้างอัตโนมัติโดยแยกวิเคราะห์ `eventTime`
`eventName`	STRING	ชื่อที่ใช้แยกอีเวนต์	ส่งเป็นพร็อพเพอร์ตี้ที่จำเป็น
`checksum`	STRING	ค่าแฮชที่สร้างจากข้อมูลอีเวนต์	สร้างอัตโนมัติจากข้อมูลอีเวนต์
`bigqueryRegistTimestamp`	TIMESTAMP	เวลาที่อีเวนต์ถูกจัดเก็บใน BigQuery	สร้างอัตโนมัติเมื่อจัดเก็บ
`attributes`	JSON	พื้นที่จัดเก็บพร็อพเพอร์ตี้ที่กำหนดเองและพร็อพเพอร์ตี้ที่เก็บอัตโนมัติ	สร้างอัตโนมัติโดยจัดพร็อพเพอร์ตี้ที่ส่งมาให้เข้ากับโครงสร้าง

เมื่อเก็บอีเวนต์ contents_success ได้ตามปกติ ข้อมูลพื้นฐานและค่าพร็อพเพอร์ตี้ของอีเวนต์จะถูกจัดเก็บไว้ในแถวเดียวดังภาพด้านล่าง หากส่งอีเวนต์เดียวกันซ้ำ อาจมีข้อมูลซ้ำถูกจัดเก็บ เมื่อค้นหาข้อมูลดิบโดยตรง แนะนำให้ตัดข้อมูลซ้ำโดยใช้ checksum

ผลการค้นหา t_raw_event_log ใน BigQuery ที่ข้อมูลพื้นฐานและ attributes ของอีเวนต์ contents_success ถูกจัดเก็บในแถวเดียว — ข้อมูลพื้นฐานและค่าพร็อพเพอร์ตี้ของอีเวนต์ถูกจัดเก็บไว้ในแถวเดียวใน `t_raw_event_log`

โครงสร้างการจัดเก็บพร็อพเพอร์ตี้ของอีเวนต์

พร็อพเพอร์ตี้ที่ส่งมาพร้อมอีเวนต์หรือเก็บอัตโนมัติจะถูกจัดเก็บในรูปแบบ JSON ในฟิลด์ attributes ภายใน attributes จะแบ่งเป็น hiveAttributes และ eventAttributes ตามวิธีเก็บพร็อพเพอร์ตี้

ประเภท	คำอธิบาย	ค่าหลัก
`hiveAttributes`	พร็อพเพอร์ตี้ที่ถูกเพิ่มอัตโนมัติระหว่างการประมวลผลข้อมูลของ Hive Analytics	`_dataSource`
`eventAttributes`	พร็อพเพอร์ตี้ที่ส่งมาพร้อมอีเวนต์หรือเก็บอัตโนมัติจากไคลเอนต์	`eventTime` ต้นฉบับ พร็อพเพอร์ตี้ที่กำหนดเอง พร็อพเพอร์ตี้ที่ SDK เก็บอัตโนมัติ

เมื่อดู _dataSource ใน hiveAttributes จะแยกได้ว่าอีเวนต์ถูกส่งมาทางใด เช่น Hive SDK หรือเซิร์ฟเวอร์เกม ส่วนใน eventAttributes จะเห็นพร็อพเพอร์ตี้ที่กำหนดเองซึ่งเกมส่งมาโดยตรงและค่าจริงของพร็อพเพอร์ตี้เหล่านั้น พร็อพเพอร์ตี้ฝั่งไคลเอนต์ที่เก็บอัตโนมัติผ่าน Hive SDK ก็อยู่ในพื้นที่นี้ด้วย ดูรายละเอียดเพิ่มเติมได้ที่ โครงสร้างการจัดเก็บเหตุการณ์ บนเว็บไซต์นักพัฒนา Hive

ข้อมูลที่ถูกกักกัน

อีเวนต์ที่ไม่ผ่านเกณฑ์การเก็บข้อมูล เช่น พร็อพเพอร์ตี้ที่จำเป็นและรูปแบบของค่า จะโหลดไม่สำเร็จและถูกกักกันไว้ใน t_raw_event_log_rescue ของชุดข้อมูล BigQuery ของแต่ละบริษัท ตารางกักกันจะจัดเก็บ JSON ต้นฉบับที่ส่งมาพร้อมเหตุผลที่ถูกกักกัน หากไม่พบอีเวนต์ในตารางปกติ ให้ตรวจสอบในตาราง rescue ว่าอีเวนต์นั้นถูกกักกันหรือไม่

เหตุผลหลักที่ถูกกักกัน	คำอธิบาย
ขาดพร็อพเพอร์ตี้ที่จำเป็น	ไม่มีพร็อพเพอร์ตี้ที่จำเป็นต่อการส่งล็อก หรือค่าว่างเปล่า
ใช้คำสงวน	ใช้ `attributes`, `eventAttributes`, `hiveAttributes` เป็นชื่อพร็อพเพอร์ตี้ที่กำหนดเอง หรือใช้ชื่อพร็อพเพอร์ตี้ที่ขึ้นต้นด้วย `_`
ชนิดข้อมูลที่ไม่รองรับ	ส่งออบเจกต์หรืออาร์เรย์ JSON เป็นค่าของพร็อพเพอร์ตี้ที่กำหนดเอง
รูปแบบ `eventTime` ไม่ถูกต้อง	ไม่สามารถตีความ `eventTime` เป็นรูปแบบ RFC 3339 ที่มีเขตเวลาได้
`eventTime` เกินช่วงที่อนุญาต	เวลาที่เกิดอีเวนต์อยู่นอกช่วงที่เก็บได้ (ย้อนหลัง 10 ปีถึงล่วงหน้า 5 ปี)
รูปแบบ JSON ผิดพลาด	ไม่สามารถตีความล็อกที่ส่งมาเป็น JSON ที่ถูกต้องได้

คำสงวนที่ใช้ในชื่อพร็อพเพอร์ตี้ไม่แยกตัวพิมพ์ใหญ่และเล็กของตัวอักษรภาษาอังกฤษ เช่น Attributes หรือ HIVEATTRIBUTES ก็ถือเป็นคำสงวนเช่นกัน จึงไม่ควรใช้เป็นชื่อพร็อพเพอร์ตี้ที่กำหนดเอง

โครงสร้างการจัดเก็บของตารางกักกัน

t_raw_event_log_rescue จะจัดเก็บข้อมูลพื้นฐานของอีเวนต์ที่อ่านได้จากล็อกต้นฉบับ ข้อมูลดิบ และสาเหตุที่ถูกกักกัน

ฟิลด์	ชนิดข้อมูล	คำอธิบาย
`userId`	STRING	ตัวระบุผู้ใช้ที่อ่านได้จากล็อกต้นฉบับ
`identifierProvider`	STRING	ระบบที่ออกตัวระบุผู้ใช้
`deviceId`	STRING	ตัวระบุอุปกรณ์ที่อ่านได้จากล็อกต้นฉบับ
`appIdGroup`	STRING	ค่าระบุเกม (โปรเจกต์) ที่อีเวนต์นั้นสังกัด
`dateTime`	STRING	ค่า `eventTime` ต้นฉบับที่ส่งมา
`eventName`	STRING	ชื่อที่ใช้แยกอีเวนต์
`bigqueryRegistTimestamp`	TIMESTAMP	เวลาที่อีเวนต์ถูกจัดเก็บใน BigQuery
`checksum`	STRING	ค่าแฮชที่สร้างจากข้อมูลอีเวนต์
`rawData`	STRING	JSON ต้นฉบับของอีเวนต์ที่ส่งมา
`errorReason`	STRING	รหัสที่แสดงสาเหตุที่อีเวนต์ถูกกักกัน
`errorStackTrace`	STRING	ข้อมูลโดยละเอียดเกี่ยวกับสาเหตุที่ถูกกักกัน เช่น ฟิลด์ที่ขาดหายไป

dateTime ของตารางปกติจะจัดเก็บค่า TIMESTAMP ที่แปลงมาจาก eventTime ส่วน dateTime ของตารางกักกันจะจัดเก็บ eventTime ต้นฉบับเป็นสตริง เพื่อให้เห็นปัญหาของค่าที่ส่งมาได้

ตรวจสอบเหตุผลที่ contents_success ถูกกักกัน

ส่วนนี้เป็นขั้นตอนการตรวจสอบข้อมูลที่ถูกกักกันใน BigQuery หลังจากส่งอีเวนต์ contents_success

การขอสิทธิ์ค้นหาข้อมูลใน BigQuery
การตรวจสอบเหตุผลที่ถูกกักกันต้องมีสิทธิ์ค้นหาข้อมูลดิบใน BigQuery หากต้องการใช้ BigQuery ให้ขอรับสิทธิ์ผู้ดูแลระบบ Hive Analytics ก่อน แล้วขอสิทธิ์ค้นหาข้อมูลใน BigQuery จากเมนูบัญชีของ Hive Analytics เมื่อได้รับสิทธิ์แล้ว ให้เข้าคอนโซล BigQuery ของ Google Cloud และตรวจสอบโปรเจกต์ Hive Analytics และชุดข้อมูลของบริษัทที่ได้รับสิทธิ์ค้นหาในแผง Explorer จากนั้นค้นหา t_raw_event_log_rescue ในชุดข้อมูลนั้น ดูรายละเอียดเกี่ยวกับการใช้ BigQuery ได้ที่ การตั้งค่า BigQuery บนเว็บไซต์นักพัฒนา Hive

หน้าจอค้นหา errorReason, errorStackTrace และ rawData ของ t_raw_event_log_rescue ใน BigQuery — ค้นหาข้อมูลที่ถูกกักกัน แล้วตรวจสอบรหัสข้อผิดพลาดและข้อมูลดิบ

เมื่อค้นหา t_raw_event_log_rescue ใน BigQuery พบว่า errorReason แสดงเป็น 201 เมื่อตรวจสอบ errorStackTrace และ rawData จะเห็นว่า eventTime ถูกส่งมาเป็น 2026-10-26T17:51:57+09:00+09:00 ซึ่งมีเขตเวลาซ้ำกัน ค่านี้ไม่ตรงกับรูปแบบ RFC 3339 จึงแยกวิเคราะห์เป็น dateTime สำหรับจัดเก็บไม่ได้

รหัสการกักกันและวิธีแก้ไข

errorReason	วิธีแก้ไข
100	ข้อความที่ส่งมาไม่ใช่ JSON ที่ถูกต้อง ให้ตรวจสอบรูปแบบ JSON ก่อนส่ง
200	ส่งฟิลด์ `eventTime` ในรูปแบบ RFC 3339 ที่มีเขตเวลา และส่งโดยให้ค่าเวลาของ `eventTime` อยู่ในช่วงที่อนุญาต (ย้อนหลัง 10 ปีถึงล่วงหน้า 5 ปี)
201	ส่งฟิลด์ `eventTime` ในรูปแบบ RFC 3339 ที่มีเขตเวลา
300	`attributes`, `eventAttributes`, `hiveAttributes` เป็นฟิลด์สงวนที่ไปป์ไลน์สร้างขึ้นอัตโนมัติ จึงไม่ควรใส่ไว้ในอีเวนต์โดยตรง ชื่อฟิลด์ที่ขึ้นต้นด้วย `_` สงวนไว้สำหรับใช้ภายในไปป์ไลน์ จึงไม่ควรใช้
400	ตรวจสอบว่ามีฟิลด์ที่จำเป็น (`userId`, `identifierProvider`, `deviceId`, `appId`, `eventName`, `eventTime`) ครบทุกฟิลด์ก่อนส่ง
401	ค่าพร็อพเพอร์ตี้ของอีเวนต์มีออบเจกต์ JSON (`{}`) หรืออาร์เรย์ (`[]`) ให้ส่งพร็อพเพอร์ตี้ทั้งหมดเป็นโครงสร้างแบนชั้นเดียว (สตริง/ตัวเลข) สตริง JSON (`"{...}"`, `"[...]"`) ก็จะถูกปฏิเสธเช่นกัน

หลังจากตรวจสอบรูปแบบและช่วงที่อนุญาตของ eventTime แล้ว ให้แก้ไขค่าให้มีเขตเวลาเพียงครั้งเดียว เช่น 2026-10-26T17:51:57+09:00 แล้วส่งอีกครั้ง จากนั้นค้นหาข้อมูลด้วยเงื่อนไขเดิมเพื่อตรวจสอบว่าอีเวนต์ที่แก้ไขแล้วถูกจัดเก็บใน t_raw_event_log ตามปกติ

เริ่มต้นใช้งาน Hive Analytics

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

Hive Analytics เป็นโซลูชันวิเคราะห์ข้อมูลสำหรับเกมโดยเฉพาะ ที่ช่วยวิเคราะห์อีเวนต์เกมที่เก็บได้ และตรวจสอบเหตุผลที่ถูกกักกันและข้อมูลดิบของล็อกอีเวนต์ที่ประมวลผลไม่สำเร็จ เพื่อหาสาเหตุของปัญหา ตรวจสอบสถานะการส่งอีเวนต์ในชุดข้อมูล BigQuery ของ Hive Analytics ได้เลยวันนี้