พันธกิจของ Booking.com คือการทำให้ทุกคนสัมผัสโลกกว้างได้ง่ายขึ้น เพื่อช่วยให้ผู้คนค้นพบจุดหมายปลายทาง เราเป็นผู้โฆษณาการท่องเที่ยวชั้นนำบน Google Pay Per Click (PPC) โดยรวมแล้ว Booking Holdings ใช้เงิน 4.7 พันล้านดอลลาร์ในการทำตลาดในทุกแบรนด์ในช่วง 9 เดือนแรกของปี 2565[1] เราจะเรียกใช้ PPC ในขนาดของเราและมีประสิทธิภาพได้อย่างไร ในบทความนี้ เราต้องการแสดงให้เห็นถึงการใช้งานระบบคลาวด์สาธารณะอย่างกว้างขวาง โดยเฉพาะ Google Cloud Platform (GCP) ตั้งแต่การนำเข้าข้อมูล วิทยาศาสตร์ข้อมูล ไปจนถึงการเสนอราคาโฆษณาของเรา[2] GCP เป็นตัวเร่งในวงจรการพัฒนาของเรา บางครั้งลดเวลาออกสู่ตลาดจากเดือนเป็นสัปดาห์

ความท้าทายของ PPC คืออะไร?

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

การนำเข้าข้อมูลและการวิเคราะห์ตามขนาด

การส่งผ่านข้อมูลประสิทธิภาพ ไม่ว่าจะสร้างโดยผู้ให้บริการค้นหาหรือจากภายใน เป็นอินพุตหลักสำหรับอัลกอริทึมของเรา เราใช้ Google BigQuery ใน PPC อย่างกว้างขวางเนื่องจากขนาดธุรกิจของเรา (มีการจองห้องพักมากถึง 2 ล้านคืนต่อวัน) ทีมของเราดำเนินการค้นหามากกว่า 1 ล้านรายการต่อเดือน สแกนข้อมูลมากกว่า 2 PB BigQuery ช่วยเราประหยัดเวลาได้มาก แทนที่จะรอเป็นชั่วโมงใน Hive/Hadoop เวลาเฉลี่ยในการเรียกใช้การค้นหาของเราคือ 20 วินาทีสำหรับชุดข้อมูล และ 2 วินาทีสำหรับการค้นหาแบบโต้ตอบ[3]

นอกจากนี้ BigQuery ยังให้การสนับสนุนแบบเนทีฟสำหรับสคีมาข้อมูลที่ซ้อนกันและซ้ำกัน[4][5] เราใช้ประโยชน์จากคุณลักษณะนี้ในระบบการเสนอราคาโฆษณาของเรา รักษามุมมองข้อมูลที่สอดคล้องกันตั้งแต่สเปรดชีตของผู้เชี่ยวชาญด้านบัญชีไปจนถึงสมุดบันทึกของ Data Scientists ไปจนถึงข้อมูลในหน่วยความจำของระบบการเสนอราคาของเรา คุณลักษณะนี้ช่วยขจัดโค้ดเพื่อแยกวิเคราะห์ข้อมูล ลดหนี้ทางเทคนิคของเรา และลดเวลาในการพัฒนาของเรา

มุมมองแบบรวมสำหรับข้อมูลการดำเนินงาน

เราเก็บข้อมูลการดำเนินงานส่วนใหญ่ไว้ในฐานข้อมูลเชิงสัมพันธ์ เช่น MySQL ขณะที่เราพัฒนา เราจำเป็นต้องผสานรวมข้อมูลนั้นเข้ากับข้อมูลเชิงวิเคราะห์ในมุมมองเดียวที่รวมเป็นหนึ่งเดียวมากขึ้น ขณะนี้เราใช้ Spanner[6][7] ซึ่งเป็นฐานข้อมูล SQL ที่กระจายอยู่ทั่วโลก เนื่องจากมีคุณสมบัติพิเศษหลายอย่างที่เหมาะกับกรณีการใช้งานของเรา:

1. Spanner และ BigQuery บังคับทวีคูณซึ่งกันและกันผ่าน Federated Queries: เราจัดเก็บข้อมูลเชิงสัมพันธ์ที่เปลี่ยนแปลงอย่างรวดเร็วใน Spanner และเขียนข้อมูลเชิงวิเคราะห์เชิงผนวกลงใน BigQuery เมื่อการสืบค้นของเราครอบคลุมชุดข้อมูลทั้งสอง Federated Queries จะดึงข้อมูลที่สอดคล้องกับสแน็ปช็อตแบบเรียลไทม์จากทั้งสองร้านในทันที เราไม่จำเป็นต้องย้ายข้อมูลหรือใช้วงจรการพัฒนาเพื่อตั้งค่า (และบำรุงรักษา) ไปป์ไลน์ข้อมูล[8][9][10]
2. Spanner มีความสามารถในการวิวัฒนาการสคีมาที่ทรงพลัง: สำหรับตารางขนาดใหญ่ที่มีข้อมูลโฆษณาที่กำลังพัฒนา Spanner สามารถลดเวลาของการเปลี่ยนแปลงสคีมาเป็นนาทีหรือวินาที เมื่อเทียบกับวันในโซลูชันฐานข้อมูลเชิงสัมพันธ์ทั่วไป
3. ตารางแทรกช่วยให้เราสามารถจัดเก็บข้อมูล Ads API แยกจากข้อมูลภายในของเราโดยไม่ทำให้ประสิทธิภาพลดลง สำหรับข้อมูลที่มีโครงสร้างและลำดับชั้น ฟีเจอร์นี้ช่วยให้เราวางข้อมูลที่เกี่ยวข้องไว้ใกล้กัน เพิ่มพื้นที่เชิงพื้นที่ให้ได้มากที่สุด

ข้อมูลที่ส่งมอบอย่างมีคุณภาพในเวลาที่กำหนดเป็นหัวใจสำคัญของประสิทธิภาพของระบบของเรา สำหรับเวิร์กโฟลว์ที่ครอบคลุมระบบข้อมูลหลายระบบ เราเลือกใช้ Google Dataflow ซึ่งเป็นเฟรมเวิร์กไฮบริดแบบแบตช์/สตรีมมิงที่มีการจัดการ พร้อมการผสานรวมแบบเนทีฟกับ BigQuery และ Spanner

เราเห็นข้อดีสองประการของแนวทางนี้:

1. Dataflow ใช้ Beam ซึ่งเป็น API ที่แยกการประมวลผลบิ๊กดาต้าจากรายละเอียดการใช้งานแพลตฟอร์มรันไทม์ได้อย่างมีประสิทธิภาพ: ช่วยให้เราสามารถมุ่งเน้นไปที่การแก้ปัญหาสำหรับตรรกะทางธุรกิจและการขนานข้อมูล ทำให้การพัฒนาซ้ำเร็วขึ้น
2. ทำงานเป็นบริการที่มีการจัดการโดยมีการบำรุงรักษาน้อยที่สุด

การพัฒนาโครงสร้างพื้นฐานของเรา

การเพิ่มประสิทธิภาพการทำงานของ GCP มาพร้อมกับความท้าทายที่ไม่เหมือนใคร ในระดับของเรา ต้นทุนเพียงเล็กน้อยเพิ่มขึ้น และสิ่งนี้ทำให้เราต้องคิดอย่างลึกซึ้งเกี่ยวกับมิติต้นทุนโครงสร้างพื้นฐานตั้งแต่เนิ่นๆ ในเวลาออกแบบ ซึ่งเป็นการเปลี่ยนแปลงทางวัฒนธรรมมากพอๆ กับการเปลี่ยนแปลงกระบวนการ ตัวอย่างเช่น หนึ่งในการรวม BigQuery แรกของเรา เรามีการสืบค้นข้อมูลขนาดใหญ่ที่รวมข้อมูลสถิติเข้ากับข้อมูลเมตา จากนั้นนำมารวมเข้าด้วยกัน เนื่องจากการรวมขนาดใหญ่และการใช้ CURRENT_DATE() เป็นฟังก์ชันไดนามิก การใช้งาน BigQuery แบบไร้เดียงสาจะมีค่าใช้จ่าย $1 ต่อการเรียกใช้ และในหนึ่งวันจะมีค่าใช้จ่าย $1,500 เพื่อลดต้นทุนและเพิ่มประสิทธิภาพ เราใช้ BigQuery ในการรวม เก็บข้อมูลเมตาใน MySQL และรวมสองตารางในหน่วยความจำแอปพลิเคชัน วิธีการนี้ช่วยให้เราแคชผลลัพธ์ของ BigQuery ได้โดยมีฟังก์ชันแบบไดนามิก[11][12][13]

การพัฒนาในอนาคต

ใน PPC เราประสบความสำเร็จอย่างมากในการสร้างระบบของเราบนคลาวด์สาธารณะ โดยเฉพาะ GCP BigQuery, Dataflow และ Spanner ช่วยเร่งวงจรการพัฒนาของเรา ลดเวลาออกสู่ตลาด และพิสูจน์คุณค่าทางธุรกิจ เราขอขอบคุณทีมงานที่ยอดเยี่ยมของ Google สำหรับความร่วมมือและการเป็นพันธมิตรกับเรา ที่Booking.comเรามีปัญหาที่ซับซ้อนและท้าทายให้แก้ไข เรามีทีมงาน PPC ที่มีความสามารถอย่างเหลือเชื่อและทำงานอย่างหนัก และเราใช้เทคโนโลยีที่เป็นนวัตกรรมเพื่อช่วยให้ผู้คนค้นพบการเดินทางในรูปแบบที่สนุกสนานและสร้างสรรค์ หากคุณสนใจสิ่งนี้ โปรดพิจารณาร่วมงานกับเรา — สมัครที่job.booking.com !

ขอขอบคุณเป็นพิเศษสำหรับ Baris Gul, Igor Dralyuk, Sergey Dovgal ( sdovgal ), Mustafa Elbadry , Martijn Hensema และทีมงาน PPC ทั้งหมดของ Booking.com ที่มีส่วนร่วมในบทความนี้

เชิงอรรถ:

[1] ยอดจองไตรมาส 3 ปี 2565 10Q:https://s201.q4cdn.com/865305287/files/doc_financials/2022/q3/9fdc627b-3967-4970-aae0-b9581971f96d.pdf
[2] (เอกสารภายใน) PPC GCP Projects Retrospective
[3] (เอกสารภายใน) สรุป PPC BigQuery
[4] คำอธิบายของ Protobuf ใน Dremel:https://research.google/pubs/pub36632/ [5] Dremel: ทศวรรษของการวิเคราะห์ SQL แบบโต้ตอบในระดับเว็บ:https://research.google/pubs/pub49489/
[6] Spanner: ฐานข้อมูลที่กระจายไปทั่วโลกของ Google:https://research.google/pubs/pub39966/
[7] ประแจ: กลายเป็นระบบ SQLhttps://research.google/pubs/pub46103/
[8] ข้อความค้นหา F1:https://research.google/pubs/pub47224/ [9] F1 สายฟ้า HTAP:http://www.vldb.org/pvldb/vol13/p3313-yang.pdf
[10] F1: ฐานข้อมูล SQL แบบกระจายที่ปรับขนาด:https://research.google/pubs/pub41344/
[11] การแคชผลลัพธ์ BQ:https://cloud.google.com/bigquery/docs/cached-results
[12] (เอกสารภายใน) การควบคุมต้นทุน BigQuery ใน PPC: การควบคุมต้นทุน BigQuery
[13] (เอกสารภายใน) PPC — การย้ายการรวมจาก onprem ไปยัง BigQuery