เส้นทางของ Roblox สู่ 2 ล้านล้านเหตุการณ์การวิเคราะห์ต่อวัน

ทุกวัน มีผู้ใช้เฉลี่ย 97.8 ล้านคน* เข้าเยี่ยมชม Roblox เพื่อสื่อสาร สร้างสรรค์ และเล่นร่วมกัน การมีปฏิสัมพันธ์เหล่านี้ร่วมกันสร้างข้อมูลเหตุการณ์วิเคราะห์ได้ถึง 2 เพตะไบต์ ขอบคุณระบบการรับข้อมูลที่สามารถปรับขนาดได้ใหม่ เราสามารถบรรลุเป้าหมายสำคัญได้เมื่อไม่นานมานี้: ระบบของเราสามารถประมวลผลเหตุการณ์ได้มากกว่า 2 ล้านล้านครั้งต่อวัน ระบบนี้ช่วยให้เกิดการปรับแต่งให้เหมาะกับผู้ใช้แต่ละคน ความปลอดภัย และอัลกอริทึมทางเศรษฐกิจที่ขับเคลื่อนแพลตฟอร์ม Roblox

ก่อนหน้านี้ บริการคิวบนคลาวด์ได้รวบรวมข้อมูลการวิเคราะห์ที่สร้างโดย Roblox เข้าสู่ตารางเชิงตรรกะเดียวที่เรียกว่า events_hourly ซึ่งถูกแบ่งพาร์ติชันตามวันที่ ชั่วโมง และแท็กที่กำหนดไว้อย่างอิสระ เช่น web, mobile หรือ friendService นักวิทยาศาสตร์ข้อมูลและวิศวกรของเราอาศัยงานแบบแบทช์ที่จัดตารางเวลาไว้เพื่อดึงเหตุการณ์เฉพาะไปยังตารางที่จัดเตรียมไว้โดยเฉพาะ การสร้างและส่งเหตุการณ์วิเคราะห์ใหม่ไม่จำเป็นต้องมีสคีมาล่วงหน้า วิศวกรสามารถควบคุมสคีมาของตารางของตนเองได้ภายหลังที่ขั้นตอนการดึงข้อมูล การแปลงข้อมูล และการโหลด (ETL)

การตั้งค่านี้มีความยืดหยุ่นและช่วยให้วิศวกรสามารถทำงานได้อย่างรวดเร็ว แต่ก็มีความท้าทายเช่นกัน 

• เมื่อปริมาณของเหตุการณ์เพิ่มขึ้น การโต้ตอบกับข้อมูลจำนวน 2 ล้านล้านแถวที่แบ่งตามวันที่ ชั่วโมง และแท็กเพียงอย่างเดียวกลายเป็นสิ่งที่ไม่ค่อยมีประสิทธิภาพมากขึ้น
• การล่าช้า 6 ชั่วโมงในตอนท้ายของวันสำหรับตาราง events_hourly และการล่าช้า 24 ชั่วโมงสำหรับช่วงเวลาที่สร้างขึ้นใน events_daily ทำให้เกิดช่วงเวลาที่ท่อข้อมูลถูกบล็อก 
• การจัดการสิทธิ์ในระดับชุดข้อมูล, ระดับชั้น, การเก็บรักษา และการแจ้งเตือนกลายเป็นเรื่องซับซ้อนมากขึ้น 
• เอกสารบันทึกเหตุการณ์ ประวัติความเป็นมา และความเป็นเจ้าของขาดหายไป ส่งผลให้ข้อมูลไม่สามารถใช้งานได้และมีปัญหาในการตรวจสอบย้อนกลับ 
• โครงสร้างพื้นฐานสำหรับการรับข้อมูลที่สร้างขึ้นด้วยบริการคิวบนคลาวด์ มีค่าใช้จ่ายในการรับข้อมูลบนคลาวด์อยู่ที่ 23 Gbps

การวิเคราะห์ข้อมูลในอดีตพึ่งพาการดึงข้อมูลจากตารางเชิงตรรกะเดียวผ่านกระบวนการแบบแบทช์จำนวนมาก ซึ่งจำเป็นสำหรับการรันคำสั่งค้นหาขนาดใหญ่ที่มีประสิทธิภาพ—แต่ก็ทำให้กระบวนการช้าลงด้วย การใช้บริการ backend สำหรับการรับข้อมูลเพื่อส่งเหตุการณ์เหล่านี้ไปยังตารางเฉพาะ ช่วยขจัดกระบวนการดึงข้อมูลแบบแบทช์ด้วยการกำหนดโครงสร้างข้อมูล (schema) ให้กับเหตุการณ์วิเคราะห์และกำหนดตารางปลายทางไว้ล่วงหน้า 

เราเลือกใช้ Protobuf (proto) เป็นภาษาสำหรับกำหนดโครงสร้างข้อมูล (schema language) ของเหตุการณ์วิเคราะห์ที่ Roblox นี่เป็นการเลือกที่เป็นธรรมชาติ เนื่องจาก proto และ gRPC เป็นเฟรมเวิร์กสำหรับสร้างบริการที่เราชื่นชอบ นอกจากนี้ proto ยังให้การสนับสนุนที่ยอดเยี่ยมสำหรับการกำหนดตัวเลือกแบบกำหนดเอง ซึ่งเราใช้ประโยชน์ในการรวบรวมเมตาดาต้าเพิ่มเติม เช่น การเป็นเจ้าของ การเก็บรักษา ช่องทางซอฟต์แวร์ที่ใช้ในการทำงาน และโครงสร้างของเหตุการณ์ 

หลังจากเลือกภาษาของสคีมาแล้ว เราได้ตรวจสอบว่าจะเกิดอะไรขึ้นเมื่อมีการอัปเดตสคีมาและการอัปเดตใดที่ควรอนุญาต เพื่อให้รองรับผู้บริโภคปลายทางจำนวนมากที่สุดที่ใช้สคีมาที่เผยแพร่ ทีมข้อมูลจึงได้นำโหมดการย้อนกลับแบบต่อเนื่อง (backward transitive mode) ที่อธิบายไว้ใน Schema Registry มาใช้ ด้วยวิธีนี้ การเพิ่มและการลบฟิลด์แบบนุ่มนวล (soft deletion) จะได้รับอนุญาต ซึ่งช่วยให้สามารถเปลี่ยนแปลงสคีมาได้โดยไม่จำเป็นต้องประสานงานกับผู้บริโภคปลายทาง 

ในตัวอย่างข้างต้น เราสามารถเพิ่มและลบฟิลด์ได้โดยการอัปเดตไฟล์โปรโต

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

ตัวอย่างเช่น เราได้สร้างโปรโตไทปลินเตอร์แบบกำหนดเองเพื่อตรวจสอบว่าแต่ละสคีมา มีข้อมูลเมตาดาตาที่จำเป็นและสอดคล้องกับมาตรฐานของ Roblox เรายังได้สร้างโปรโตไทป์ปลั๊กอินเพื่อแปลสคีมาของเหตุการณ์เป็นภาษาการกำหนดข้อมูลของ Hive เพื่อให้ตาราง Hive ที่เกี่ยวข้องยังคงสอดคล้องกันไม่ว่าสคีมาจะถูกสร้างหรืออัปเดตที่ใด เครื่องมือทั้งหมดนี้ถูกรวมเข้ากับ CI/CD pipeline และทำงานโดยอัตโนมัติเมื่อมีการสร้าง pull request สิ่งนี้ช่วยให้วิศวกรสามารถตรวจจับปัญหาของสคีมาได้ตั้งแต่เนิ่นๆ และตรวจสอบเหตุการณ์ในตาราง Hive ทดสอบก่อนที่จะมีการรวมสคีมา ผลลัพธ์คือ การปรับใช้สคีมาไปยังการผลิตง่ายเพียงแค่การรวมเท่านั้น 

เมื่อมีประสบการณ์ของนักพัฒนาที่ได้รับการปรับปรุงให้มีประสิทธิภาพแล้ว เราได้ตรวจสอบว่าเหตุการณ์ควรถูกสร้างเป็นแบบจำลองและแปลงเป็นโปรโตคอล (proto) ที่ใดในกระบวนการรับข้อมูล (ingestion pipeline) การขอให้ผู้ผลิตเหตุการณ์นำโปรโตคอลที่ถูกจัดรูปแบบเป็นไบต์ (serialized proto bytes) ไปใช้และส่งกลับมาอาจเป็นการเปลี่ยนแปลงที่มีผลกระทบต่อหลายทีมอย่างมาก เพื่อแก้ไขปัญหาและมอบคุณค่าอย่างค่อยเป็นค่อยไป เราได้แยกความพยายามในการสร้างแบบจำลองออกจากผู้ผลิตเหตุการณ์โดยการปรับปรุงบริการระบบหลังบ้านสำหรับการรับข้อมูล (ingestion backend service) ให้สามารถแปลงเหตุการณ์ที่เข้ามาเป็นโปรโตคอลได้ ขณะนี้ เหตุการณ์ที่ถูกแปลงแล้วจะถูกเก็บรวบรวมไว้ในไฟล์พาร์คเก็ต อัปโหลดไปยังระบบจัดเก็บข้อมูลแบบกระจาย และลงทะเบียนเป็นตาราง Hive แยกแต่ละรายการ

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

ทีมจัดเก็บข้อมูลภายในของเราได้สร้างระบบคิวในรูปแบบบริการ (QaaS) ขึ้นโดยใช้แพลตฟอร์มการสตรีมเหตุการณ์แบบกระจายที่เปิดแหล่งโค้ด QaaS เป็นทางเลือกที่ดีสำหรับการรับข้อมูลเหตุการณ์เพื่อการวิเคราะห์ เนื่องจากเหตุการณ์จะถูกติดตามในลำดับก่อนเข้า-ออกก่อน และจะถูกลบหลังจากช่วงเวลาการเก็บรักษาสั้น ๆ ที่ Roblox เราสร้างหัวข้อเฉพาะสำหรับแต่ละเหตุการณ์ที่มีการวางแผนไว้ และใช้การนับพาร์ทิชันเพื่อปรับขนาดสำหรับสตรีมเหตุการณ์ขนาดใหญ่ ทีมข้อมูลยังได้สร้างบริการเฉพาะเพื่อรับข้อมูลจาก QaaS สร้างไฟล์ parquet และอัปโหลดไฟล์ไปยังพื้นที่เก็บข้อมูลบนคลาวด์ที่มีความทนทาน

เมื่อมี QaaS และบริการเฉพาะสำหรับการสร้างและจัดเก็บไฟล์พาร์เกตแล้ว ทีมข้อมูลได้ดำเนินการเขียนข้อมูลแบบเงา (shadow writes) เป็นระยะเวลาหกเดือนเพื่อตรวจสอบความถูกต้องของข้อมูลและความสามารถในการขยายระบบ ในที่สุด หลังจากการตรวจสอบความครบถ้วนและความสมบูรณ์ของข้อมูลอย่างละเอียด เราได้ย้ายการรับข้อมูลวิเคราะห์ออกจากบริการคิวคลาวด์เดิมของเราได้สำเร็จ นี่เป็นก้าวสำคัญอย่างยิ่ง เราได้ลบค่าใช้จ่ายของทรัพยากรคลาวด์ออกจากเส้นทางการนำเข้าข้อมูลและลดความหน่วงระหว่างเหตุการณ์ที่เกิดขึ้นกับการลงสู่ทะเลข้อมูลของเราอย่างมีนัยสำคัญ ก่อนหน้านี้เรามีข้อตกลงระดับการให้บริการที่สามชั่วโมง ซึ่งเรามักจะพลาด—วันนี้เราสามารถทำได้เฉลี่ยเพียง 15 นาที 

สิ่งนี้ช่วยให้วิศวกรสามารถเขียนกระบวนการประมวลผลเหตุการณ์แบบเรียลไทม์จากเหตุการณ์ที่จัดรูปแบบไว้ล่วงหน้า โดยใช้ข้อมูลจาก QaaS เพื่อเสริมความปลอดภัยและฟีเจอร์แนะนำแบบเรียลไทม์ นอกจากนี้ เรายังได้เปิดตัวฟีเจอร์จับข้อมูลการเปลี่ยนแปลง (change data capture) ด้วยกรอบการทำงานการจัดรูปแบบเดียวกันและการนำเข้าข้อมูลผ่าน QaaS ซึ่งช่วยลดความจำเป็นในการสำรองฐานข้อมูลทั้งหมดได้อย่างมาก จากทั้งการวิเคราะห์ข้อมูลแบบเรียลไทม์และการสตรีมเหตุการณ์ ไปจนถึงการปลดล็อกกรณีการใช้งานใหม่ๆ ผลงานของเรายังคงเดินหน้าต่อไปในการสร้างนวัตกรรมและพัฒนาระบบข้อมูลที่ชาญฉลาด รวดเร็ว และคุ้มค่ามากยิ่งขึ้นในระดับองค์กร 

ขอขอบคุณคุณพอล มู่ สำหรับการมีส่วนร่วมที่มีคุณค่าในงานนี้

^{* ณ วันที่สิ้นสุดไตรมาสสามเดือนสิ้นสุดวันที่ 31 มีนาคม 2568}