วิธี TripAdvisor ให้การปรับแต่งแบบกําหนดเองแบบเรียลไทม์ด้วย ML

See the engineering behind real-time personalization at Tripadvisor’s massive (and rapidly growing) scale คุณเป็นผู้โดยสารชนิดใด? Tripadvisor จะพยายามประเมินสิ่งนี้ทันทีที่คุณมีส่วนร่วมกับเว็บไซต์แล้วจะให้ข้อมูลที่เกี่ยวข้องมากขึ้นทุกครั้งที่คุณคลิก – ภายในไม่กี่มิลลิสวินาที การปรับแต่งส่วนบุคคลนี้ได้รับการสนับสนุนโดยโมเดล ML ขั้นสูงที่ทํางานบนข้อมูลที่เก็บไว้ใน ScyllaDB ที่ทํางานบน AWS ในบทความนี้ Dean Poulin (Tripadvisor Data Engineering Lead on the AI Service and Products team) ให้ดูวิธีที่พวกเขาขับเคลื่อนการปรับตัวนี้ Dean ส่วนแบ่งความท้าทายทางเทคนิคที่เกี่ยวข้องกับการส่งมอบการปรับตัวแบบเรียลไทม์ในขนาดใหญ่ (และเติบโตอย่างรวดเร็ว) ของ TripAdvisor มันขึ้นอยู่กับ AWS re:Invent Talk ต่อไปนี้: การนําทางก่อนการเดินทาง ในคําพูดของ Dean ... ลองเริ่มต้นด้วยภาพถ่ายอย่างรวดเร็วเกี่ยวกับ Tripadvisor และขนาดที่เรามีการดําเนินงาน ก่อตั้งขึ้นในปี 2000 Tripadvisor ได้กลายเป็นผู้นําระดับโลกในด้านการเดินทางและการพักผ่อนช่วยให้ผู้โดยสารหลายร้อยล้านคนวางแผนการเดินทางที่สมบูรณ์แบบ Tripadvisor สร้างรายได้กว่า 1.8 พันล้านดอลลาร์และเป็น บริษัท ที่ซื้อขายอย่างเป็นทางการในสกุลเงินหลักทรัพย์ NASDAQ วันนี้เรามีทีมงานที่มีความสามารถมากกว่า 2,800 คนที่ขับเคลื่อนนวัตกรรมและแพลตฟอร์มของเราให้บริการผู้เข้าชมที่ไม่ซ้ํากัน 400 ล้านคนต่อเดือน – หมายเลขที่เพิ่มขึ้นอย่างต่อเนื่อง ในแต่ละวันระบบของเราจัดการกับคําขอมากกว่า 2 พันล้านจากผู้ใช้ 25 ถึง 50 ล้านคน ทุกคลิกที่คุณทําบน Tripadvisor จะได้รับการประมวลผลในเวลาจริง จากนั้นเราจึงใช้โมเดลการเรียนรู้เครื่องเพื่อให้คําแนะนําที่กําหนดเอง – ทําให้คุณใกล้เคียงกับการเดินทางที่สมบูรณ์แบบ ในใจกลางของเครื่องมือการปรับแต่งตัวบุคคลนี้คือ ScyllaDB ที่ทํางานบน AWS สิ่งนี้ช่วยให้เราสามารถให้ความล่าช้าในนาทีมิลลิสในระดับที่ไม่กี่องค์กรสามารถเข้าถึงได้ ในขณะที่การเข้าชมสูงสุดเรามีการโจมตี . 425K operations per second on ScyllaDB with P99 latencies for reads and writes around 1-3 milliseconds ฉันจะแบ่งปันวิธีที่ Tripadvisor ใช้พลังของ ScyllaDB, AWS และการเรียนรู้เครื่องแบบเรียลไทม์เพื่อให้คําแนะนําที่กําหนดเองสําหรับแต่ละผู้ใช้ เราจะสํารวจวิธีที่เราช่วยนักเดินทางค้นพบทุกอย่างที่พวกเขาต้องการเพื่อวางแผนการเดินทางที่สมบูรณ์แบบของพวกเขา: ไม่ว่าจะเป็นการค้นพบเครื่องประดับที่ซ่อนอยู่สถานที่ท่องเที่ยวที่ต้องเห็นประสบการณ์ที่น่าจดจําหรือสถานที่ที่ดีที่สุดในการเข้าพักและรับประทานอาหาร [บทความ] เกี่ยวกับวิศวกรรมที่อยู่เบื้องหลัง - วิธีที่เราให้เนื้อหาที่เหมาะสมกับผู้ใช้ในเวลาจริงช่วยให้พวกเขาค้นหาสิ่งที่พวกเขากําลังมองหาอย่างรวดเร็วที่สุดเท่าที่จะเป็นไปได้ การวางแผนการเดินทางส่วนบุคคล ลองจินตนาการว่าคุณกําลังวางแผนการเดินทาง เมื่อคุณเข้าสู่หน้าแรกของ Tripadvisor Tripadvisor จะรู้ว่าคุณเป็นคนชอบอาหารผู้ผจญภัยหรือคนรักชายหาด - และคุณจะเห็นคําแนะนําในสถานที่ที่ดูเป็นส่วนบุคคลเพื่อความสนใจของคุณเอง วิธีที่เกิดขึ้นภายในมิลลิสวินาที? เมื่อคุณเรียกดู Tripadvisor เราจะเริ่มปรับแต่งข้อมูลที่คุณเห็นโดยใช้รุ่น Machine Learning ซึ่งคํานวณคะแนนขึ้นอยู่กับกิจกรรมการเรียกดูในปัจจุบันและก่อนหน้านี้ เราขอแนะนําโรงแรมและประสบการณ์ที่คุณคิดว่าคุณจะสนใจ เราจัดเรียงโรงแรมตามความต้องการส่วนบุคคลของคุณ เราขอแนะนําจุดสนใจที่นิยมใกล้กับโรงแรมที่คุณกําลังดู ทั้งหมดนี้ได้รับการปรับแต่งตามความต้องการส่วนบุคคลของคุณและกิจกรรมการเรียกดูก่อนหน้านี้ รูปแบบของ Tripadvisor ที่ให้บริการสถาปัตยกรรม Tripadvisor ทํางานบนหลายร้อยไมโครเซิร์ฟเวอร์ที่สามารถปรับขนาดได้โดยอิสระใน Kubernetes on-prem และใน Amazon EKS แพลตฟอร์มการให้บริการรูปแบบ ML ของเราจะเปิดเผยผ่านหนึ่งในไมโครเซิร์ฟเวอร์เหล่านี้ บริการ gateway นี้สกัดมากกว่า 100 รุ่น ML จากบริการลูกค้า - ซึ่งช่วยให้เราสามารถดําเนินการทดสอบ A / B เพื่อค้นหารุ่นที่ดีที่สุดโดยใช้แพลตฟอร์มการทดลองของเรา รุ่น ML ส่วนใหญ่ได้รับการพัฒนาโดยนักวิทยาศาสตร์ข้อมูลและวิศวกรการเรียนรู้เครื่องของเราโดยใช้ Jupyter Notebooks บน Kubeflow พวกเขาได้รับการจัดการและฝึกอบรมโดยใช้ ML Flow และเราใช้พวกเขาบน Seldon Core ใน Kubernetes ร้านคุณลักษณะที่กําหนดเองของเราให้คุณสมบัติให้กับรุ่น ML ของเราซึ่งช่วยให้พวกเขาสามารถทําการคาดการณ์ที่แม่นยํา The Custom Feature ร้านค้า Feature Store ส่วนใหญ่ให้บริการคุณสมบัติของผู้ใช้และคุณสมบัติแบบคงที่ คุณสมบัติแบบคงที่จะถูกเก็บไว้ใน Redis เนื่องจากพวกเขาไม่เปลี่ยนแปลงบ่อย เราเรียกใช้ท่อข้อมูลทุกวันเพื่อโหลดข้อมูลจากคลังข้อมูลแบบออฟไลน์ของเราลงในฟีเจอร์สต็อกของเราเป็นคุณสมบัติแบบคงที่ คุณสมบัติของผู้ใช้จะถูกให้บริการในเวลาจริงผ่านแพลตฟอร์มที่เรียกว่าแพลตฟอร์มผู้เข้าชม เราดําเนินการคําถาม CQL แบบไดนามิกกับ ScyllaDB และ . we do not need a caching layer because ScyllaDB is so fast ร้านฟีเจอร์ของเราให้บริการถึง 5 ล้านฟีเจอร์เสถียรภาพต่อวินาทีและครึ่งล้านฟีเจอร์ผู้ใช้ต่อวินาที คุณลักษณะ ML คืออะไร คุณสมบัติเป็นตัวแปรอินพุตสําหรับโมเดล ML ที่ใช้ในการทําการคาดการณ์ มีคุณสมบัติสถิตและคุณสมบัติผู้ใช้ ตัวอย่างบางอย่างของคุณสมบัติสถิตคือรางวัลที่ร้านอาหารได้รับหรือสิ่งอํานวยความสะดวกที่โรงแรมนําเสนอ (เช่นอินเทอร์เน็ตไร้สายฟรี, สัตว์เลี้ยงที่เป็นมิตรหรือศูนย์ออกกําลังกาย) คุณสมบัติของผู้ใช้จะถูกเก็บรวบรวมในเวลาจริงในขณะที่ผู้ใช้เรียกดูเว็บไซต์ เราเก็บไว้ใน ScyllaDB เพื่อให้เราสามารถรับคําถามที่รวดเร็วได้ ตัวอย่างบางอย่างของคุณสมบัติของผู้ใช้คือโรงแรมที่ดูในช่วง 30 นาทีที่ผ่านมาร้านอาหารที่ดูในช่วง 24 ชั่วโมงที่ผ่านมาหรือความคิดเห็นที่ส่งในช่วง 30 วันที่ผ่านมา The Technologies Powering แพลตฟอร์มผู้เข้าชม ScyllaDB เป็นส่วนสําคัญของแพลตฟอร์มผู้เข้าชม เราใช้ microservices Spring Boot บน Java เพื่อเปิดเผยแพลตฟอร์มให้กับลูกค้าของเรา นี่คือการใช้งานบน AWS ECS Fargate เราเรียกใช้ Apache Spark บน Kubernetes สําหรับงานการเก็บข้อมูลประจําวันของเรา ออฟไลน์ไปยังงานออนไลน์ จากนั้นเราใช้งานเหล่านี้เพื่อโหลดข้อมูลจากคลังข้อมูลออฟไลน์ของเราไปยัง ScyllaDB เพื่อให้สามารถใช้งานได้บนเว็บไซต์สด นอกจากนี้เรายังใช้ Amazon Kinesis สําหรับการประมวลผลเหตุการณ์การติดตามผู้ใช้สตรีมมิ่ง การไหลของข้อมูลผู้เข้าชมแพลตฟอร์ม กราฟิกต่อไปนี้แสดงให้เห็นว่าข้อมูลไหลผ่านแพลตฟอร์มของเราในสี่ขั้นตอน: สร้างการดูดซับการจัดระเบียบและเปิดใช้งาน ข้อมูลที่ผลิตโดยเว็บไซต์และแอปพลิเคชันมือถือของเรา บางส่วนของข้อมูลนี้รวมถึงกราฟผู้ใช้ Cross-Device ของเราเหตุการณ์การติดตามพฤติกรรม (เช่น ครั้งที่เข้าดูหน้าและคลิก) และเหตุการณ์การสตรีมมิ่งที่ผ่าน Kinesis นอกจากนี้การแบ่งกลุ่มผู้ชมจะถูกโหลดลงในแพลตฟอร์มของเรา microservices ของ Visitor Platform ใช้ในการดูดซับและจัดระเบียบข้อมูลนี้ ข้อมูลใน ScyllaDB ถูกเก็บไว้ในสองพื้นที่คีย์: พื้นที่คีย์หลักของผู้เข้าชมซึ่งมีกราฟบุคลิกภาพของผู้เข้าชม พื้นที่คีย์เมตริกของผู้เข้าชมซึ่งมีข้อเท็จจริงและเมตริก (สิ่งที่ผู้คนทําในขณะที่พวกเขาเรียกดูเว็บไซต์) เราใช้กระบวนการ ETL ทุกวันเพื่อบํารุงรักษาและทําความสะอาดข้อมูลในแพลตฟอร์ม เราผลิตผลิตภัณฑ์ข้อมูลที่พิมพ์ทุกวันในคลังสินค้าข้อมูลออฟไลน์ของเรา - ที่พวกเขาสามารถใช้งานได้สําหรับการบูรณาการอื่น ๆ และท่อข้อมูลอื่น ๆ เพื่อใช้ในการประมวลผล นี่คือการดูแพลตฟอร์มผู้เข้าชมตามตัวเลข: ทําไมสองฐานข้อมูล ฐานข้อมูลออนไลน์ของเรามุ่งเน้นไปที่การเข้าชมเว็บไซต์สดแบบเรียลไทม์ ScyllaDB ทําหน้าที่นี้โดยการให้ความล่าช้าต่ํามากและส่งผ่านสูง เราใช้ TTL ในระยะสั้นเพื่อป้องกันไม่ให้ข้อมูลในฐานข้อมูลออนไลน์เติบโตได้ตลอดเวลาและงานการเก็บรักษาข้อมูลของเราให้แน่ใจว่าเราเก็บข้อมูลกิจกรรมของผู้ใช้สําหรับผู้เข้าชมจริงเท่านั้น Tripadvisor.com ได้รับการเข้าชมบอทจํานวนมากและเราไม่ต้องการเก็บข้อมูลของพวกเขาและพยายามปรับตัวบอท - ดังนั้นเราลบและทําความสะอาดข้อมูลทั้งหมด การจัดเก็บข้อมูลแบบออฟไลน์ของเราเก็บข้อมูลประวัติศาสตร์ที่ใช้ในการรายงานสร้างผลิตภัณฑ์ข้อมูลอื่น ๆ และการฝึกอบรมรุ่น ML ของเรา เราไม่ต้องการกระบวนการข้อมูลแบบออฟไลน์ขนาดใหญ่ที่ส่งผลกระทบต่อประสิทธิภาพของเว็บไซต์สดของเราดังนั้นเรามีฐานข้อมูลแยกต่างหากสองฐานข้อมูลที่ใช้สําหรับวัตถุประสงค์ที่แตกต่างกัน แพลตฟอร์มผู้เข้าชม Microservices เราใช้ 5 microservices สําหรับแพลตฟอร์มผู้เข้าชม: Visitor Core จัดการไดเรกทอรีส่วนบุคคลของผู้ใช้ระหว่างอุปกรณ์ตามคุกกี้และ ID อุปกรณ์ Visitor Metric เป็นเครื่องมือสอบถามของเราซึ่งช่วยให้เราสามารถแสดงข้อเท็จจริงและวัดสําหรับผู้เข้าชมที่เฉพาะเจาะจง เราใช้ภาษาเฉพาะโดเมนที่เรียกว่าภาษาสอบถามผู้เข้าชมหรือ VQL ตัวอย่าง VQL นี้ช่วยให้คุณสามารถดูข้อเท็จจริงการคลิกเชิงพาณิชย์ล่าสุดในช่วงสามชั่วโมงที่ผ่านมา Visitor Publisher และ Visitor Saver จัดการเส้นทางการเขียนการเขียนข้อมูลลงในแพลตฟอร์ม นอกเหนือจากการบันทึกข้อมูลใน ScyllaDB เรายังส่งข้อมูลไปยังคลังข้อมูลแบบออฟไลน์ ซึ่งทําด้วย Amazon Kinesis Visitor Composite ทําให้ง่ายต่อการเผยแพร่ข้อมูลในงานการประมวลผลแบทช์ มันอธิบาย Visitor Saver และ Visitor Core เพื่อระบุผู้เข้าชมและเผยแพร่ข้อเท็จจริงและตัวชี้วัดในแอปพลิเคชัน API เดียว Roundtrip Microservice ความล่าช้า ไดเรกทอรีนี้แสดงให้เห็นว่าความล่าช้าของไมโครบริการของเรายังคงมีเสถียรภาพตามเวลา ความล่าช้าเฉลี่ยเพียง 2.5 มิลลิวินาทีและ P999 ของเราต่ํากว่า 12.5 มิลลิวินาที นี่เป็นประสิทธิภาพที่น่าประทับใจโดยเฉพาะอย่างยิ่งเนื่องจากเราจัดการกับคําขอมากกว่า 1 พันล้านต่อวัน ลูกค้าไมโครเซสเซอร์ของเรามีข้อกําหนดความล่าช้าอย่างเข้มงวด 95% ของการโทรต้องเสร็จสิ้นภายใน 12 มิลลิวินาทีหรือน้อยกว่า หากพวกเขากําลังไปกว่านั้นเราจะได้รับ paged และต้องค้นหาสิ่งที่ส่งผลกระทบต่อความล่าช้า ScyllaDB ความล่าช้า นี่คือภาพถ่ายสั้น ๆ ของประสิทธิภาพของ ScyllaDB ในสามวัน ที่จุดสูงสุด ScyllaDB จะจัดการ 340,000 การดําเนินงานต่อวินาที (รวมทั้งการเขียนและอ่านและลบ) และ CPU จะเลื่อนลงที่เพียง 21% นี่คือขนาดใหญ่ในการกระทํา! ScyllaDB ให้การเขียน microsecond และอ่าน millisecond สําหรับเรา ระดับความสามารถในการทํางานที่รวดเร็วคือเหตุผลที่เราเลือก ScyllaDB การแบ่งข้อมูลไปยัง ScyllaDB ภาพนี้แสดงให้เห็นว่าเราแบ่งข้อมูลเป็น ScyllaDB ได้อย่างไร The Visitor Metric Keyspace มีสองตาราง: Fact และ Raw Metrics คีย์หลักในตาราง Fact คือ Visitor GUID, Fact Type และ Created At Date คีย์การแยกคอมโพสิตคือ Visitor GUID และ Fact Type คีย์การจัดกลุ่มคือ Created At Date ซึ่งช่วยให้เราสามารถจัดเรียงข้อมูลในพาร์ทิชันตามวันที่ คอลัมน์คุณสมบัติมีวัตถุ JSON ที่แสดงถึงเหตุการณ์ที่เกิดขึ้นที่นั่น ตัวอย่างบางอย่าง Facts คือ Search Terms, Page Views และ Bookings เราใช้กลยุทธ์การบีบอัดระดับของ ScyllaDB เพราะ: มันได้รับการเพิ่มประสิทธิภาพสําหรับคําถามช่วง มันจัดการกับ cardinality สูงเป็นอย่างดี มันดีกว่าสําหรับภาระงานที่หนักในการอ่านและเรามีการอ่านประมาณ 2-3 เท่ากว่าการเขียน ทําไม ScyllaDB โซลูชั่นของเราก่อตั้งขึ้นโดยใช้ Cassandra on-prem แต่เมื่อขนาดเพิ่มขึ้นภาระการดําเนินงานก็ต้องสนับสนุนการดําเนินงานที่ทุ่มเทเพื่อให้เราสามารถจัดการการอัพเกรดฐานข้อมูลการสํารองข้อมูล ฯลฯ นอกจากนี้โซลูชั่นของเราต้องใช้ความล่าช้าที่ต่ํามากสําหรับส่วนประกอบหลัก ระบบการจัดการข้อมูลผู้ใช้ของเราต้องระบุผู้ใช้ภายใน 30 มิลลิวินาที - และเพื่อการปรับแต่งที่ดีที่สุดเราต้องใช้แพลตฟอร์มการติดตามเหตุการณ์ของเราเพื่อตอบสนองภายใน 40 มิลลิวินาที มันเป็นสิ่งสําคัญที่โซลูชั่นของเราไม่บล็อกการ rendering ของหน้าเพื่อให้ SLA ของเราต่ํามาก ด้วย Cassandra เราได้มีผลต่อประสิทธิภาพจากการเก็บรวบรวมขยะ ซึ่งเป็นส่วนใหญ่ส่งผลต่อความล่าช้าห้าห้าห้าห้าห้าห้าห้าห้า เราทําการทดสอบแนวคิดด้วย ScyllaDB และพบว่าการส่งผ่านที่ดีกว่า Cassandra และภาระการดําเนินงานถูกกําจัด ScyllaDB ให้เราฐานข้อมูลการให้บริการสดที่รวดเร็วมากที่สุดด้วยความล่าช้าต่ําที่สุด เราต้องการตัวเลือกที่ได้รับการจัดการอย่างเต็มที่ดังนั้นเราย้ายจาก Cassandra ไปยัง ScyllaDB Cloud ตามกลยุทธ์การเขียนคู่ ซึ่งช่วยให้เราสามารถย้ายได้โดยไม่มีเวลาหยุดทํางานในขณะที่จัดการ 40,000 การดําเนินงานหรือคําขอต่อวินาที หลังจากนั้นเราย้ายจาก ScyllaDB Cloud ไปยังโมเดล "นําบัญชีของคุณเอง" ของ ScyllaDB ที่คุณสามารถใช้ทีม ScyllaDB เพื่อใช้ฐานข้อมูล ScyllaDB ในบัญชี AWS ของคุณเอง สิ่งนี้ช่วยให้เรามีประสิทธิภาพที่ดีขึ้นรวมถึงความเป็นส่วนตัวข้อมูลที่ดีขึ้น แผนภาพนี้แสดงให้เห็นว่าการใช้งาน BYOA ของ ScyllaDB ดูอย่างไร ในใจกลางของไดเรกทอรีคุณสามารถเห็นกลุ่ม ScyllaDB 6 แกนที่ทํางานบน EC2 และจากนั้นมีสองตัวอย่าง EC2 เพิ่มเติม ScyllaDB Monitor ให้เรา Grafana dashboards เช่นเดียวกับ Prometheus metrics ScyllaDB Manager จัดการการอัตโนมัติโครงสร้างพื้นฐานเช่นการเปิดตัวการสํารองข้อมูลและการซ่อมแซม ด้วยการใช้งานนี้ ScyllaDB สามารถวางอยู่ร่วมกันได้ใกล้กับไมโครบริการของเราเพื่อให้เรามีความล่าช้าที่ต่ํากว่าเช่นเดียวกับการส่งผ่านและประสิทธิภาพที่สูงขึ้น ขึ้นไปฉันหวังว่าคุณจะเข้าใจได้ดีขึ้นเกี่ยวกับสถาปัตยกรรมของเราเทคโนโลยีที่สนับสนุนแพลตฟอร์มและวิธีการ ScyllaDB เล่นบทบาทสําคัญในการช่วยให้เราสามารถจัดการกับ Tripadvisor ที่มีขนาดใหญ่มาก เกี่ยวกับ Cynthia Dunlop Cynthia เป็นผู้นําด้านกลยุทธ์เนื้อหาที่ ScyllaDB เธอเขียนเกี่ยวกับการพัฒนาซอฟต์แวร์และวิศวกรรมคุณภาพมานานกว่า 20 ปี