See the engineering behind real-time personalization at Tripadvisor’s massive (and rapidly growing) scale Apa jenis pelancong anda? TripAdvisor cuba menilai ini sebaik sahaja anda terlibat dengan laman web, kemudian menawarkan maklumat yang lebih relevan kepada anda pada setiap klik – dalam beberapa millisecond. Dalam artikel ini, Dean Poulin (Tripadvisor Data Engineering Lead pada pasukan Perkhidmatan dan Produk AI) memberikan pandangan tentang bagaimana mereka membolehkan personalisasi ini. Ia didasarkan pada AWS re:Invent talk berikut: Orientasi pra-perjalanan Dalam kata-kata Dean ... Diasaskan pada tahun 2000, TripAdvisor telah menjadi pemimpin global dalam perjalanan dan hospitaliti, membantu beratus-ratus juta pelancong merancang perjalanan mereka yang sempurna. TripAdvisor menghasilkan lebih daripada US$1.8 bilion dalam pendapatan dan merupakan syarikat yang didagangkan di bursa NASDAQ. Hari ini, kami mempunyai pasukan berbakat yang terdiri daripada lebih daripada 2,800 pekerja yang mendorong inovasi, dan platform kami melayani 400 juta pelawat unik setiap bulan - bilangan yang terus meningkat. Pada mana-mana hari, sistem kami menangani lebih daripada 2 bilion permintaan dari 25 hingga 50 juta pengguna. Setiap klik yang anda buat pada TripAdvisor diproses dalam masa nyata. Di belakang itu, kami memanfaatkan model pembelajaran mesin untuk menyampaikan cadangan yang disesuaikan – membawa anda lebih dekat kepada perjalanan yang sempurna. Di tengah-tengah enjin personalisasi ini ialah ScyllaDB yang berjalan pada AWS. Ini membolehkan kami menyampaikan latens millisecond pada skala yang hanya sedikit organisasi yang mencapai. . 425K operations per second on ScyllaDB with P99 latencies for reads and writes around 1-3 milliseconds Saya akan berkongsi bagaimana TripAdvisor memanfaatkan kuasa ScyllaDB, AWS, dan pembelajaran mesin masa nyata untuk menyampaikan cadangan peribadi untuk setiap pengguna. kami akan meneroka bagaimana kami membantu pelancong mencari semua yang mereka perlukan untuk merancang perjalanan mereka yang sempurna: sama ada ia mendedahkan permata tersembunyi, tarikan-tarikan yang perlu dilihat, pengalaman yang tidak dapat dilupakan, atau tempat-tempat terbaik untuk tinggal dan makan malam. [artikel] ini adalah tentang kejuruteraan di sebalik itu - bagaimana kami menyampaikan kandungan yang lancar dan relevan kepada pengguna dalam masa nyata, membantu mereka mencari apa yang mereka cari secepat mungkin. Perancangan Perjalanan Peribadi Sebaik sahaja anda mendarat di laman utama TripAdvisor, TripAdvisor sudah tahu sama ada anda seorang foodie, pengembara, atau pecinta pantai – dan anda melihat cadangan spot-on yang kelihatan dipersonalisasi untuk minat anda sendiri. Apabila anda menelusuri TripAdvisor, kami mula menyesuaikan apa yang anda lihat menggunakan model pembelajaran mesin yang mengira skor berdasarkan aktiviti penelusuran semasa dan terdahulu anda. kami mencadangkan hotel dan pengalaman yang kami fikir anda akan berminat. kami mengatur hotel berdasarkan keutamaan peribadi anda. kami mencadangkan tempat-tempat menarik popular berhampiran hotel yang anda lihat. semua ini disesuaikan berdasarkan keutamaan peribadi anda dan aktiviti penelusuran sebelumnya. Tripadvisor Model Melayani Arsitektur TripAdvisor berjalan pada beratus-ratus microservices yang boleh diperluas secara bebas dalam Kubernetes on-prem dan dalam Amazon EKS. Platform ML Model Serving kami dipaparkan melalui salah satu microservices ini. Perkhidmatan gateway ini merangkumi lebih daripada 100 Model ML dari Perkhidmatan Pelanggan – yang membolehkan kami menjalankan ujian A / B untuk mencari model terbaik menggunakan platform eksperimen kami. Model ML terutamanya dibangunkan oleh saintis data dan jurutera pembelajaran mesin kami menggunakan Jupyter Notebooks di Kubeflow. Mereka dikendalikan dan dilatih menggunakan ML Flow, dan kami melancarkan mereka di Seldon Core di Kubernetes. kedai ciri tersuai kami menyediakan ciri-ciri kepada Model ML kami, membolehkan mereka membuat ramalan yang tepat. Kedai Custom Feature Feature Store terutamanya melayani ciri-ciri pengguna dan ciri-ciri statis. ciri-ciri statis disimpan dalam Redis kerana mereka tidak berubah dengan kerap. kami menjalankan paip data setiap hari untuk memuat naik data daripada gudang data offline kami ke dalam Store ciri kami sebagai ciri-ciri statis. Ciri-ciri pengguna dihantar dalam masa nyata melalui platform yang dipanggil Platform Pengunjung. kami menjalankan pertanyaan CQL dinamik terhadap ScyllaDB, dan . we do not need a caching layer because ScyllaDB is so fast Store ciri kami menyediakan sehingga 5 juta ciri statik setiap saat dan setengah juta ciri pengguna setiap saat. Apa itu ML Feature? Ciri-ciri ialah variabel input kepada Model ML yang digunakan untuk membuat ramalan. Sesetengah contoh Ciri-ciri Statik adalah anugerah yang telah memenangi restoran atau kemudahan yang ditawarkan oleh hotel (seperti Wi-Fi percuma, mesra haiwan peliharaan atau pusat kebugaran). Ciri-ciri pengguna dikumpulkan dalam masa nyata apabila pengguna melayari laman web. Kami menyimpannya dalam ScyllaDB supaya kami boleh mendapatkan pertanyaan cepat kilat. Sesetengah contoh ciri-ciri pengguna adalah hotel yang dilihat dalam 30 minit yang lalu, restoran yang dilihat dalam 24 jam yang lalu, atau ulasan yang dihantar dalam 30 hari yang lalu. Teknologi yang membolehkan platform pelawat ScyllaDB adalah teras Platform Pengunjung. Kami menggunakan microservices Spring Boot berasaskan Java untuk mendedahkan platform kepada pelanggan kami. Ini digunakan pada AWS ECS Fargate. Kami menjalankan Apache Spark pada Kubernetes untuk kerja-kerja penyimpanan data harian kami, kerja-kerja offline kami ke dalam talian. Kemudian kami menggunakan kerja-kerja itu untuk memuat naik data daripada gudang data offline kami ke ScyllaDB supaya mereka boleh didapati di laman langsung. Kami juga menggunakan Amazon Kinesis untuk memproses peristiwa pelacakan pengguna. Platform Pengunjung Data Flow Graf berikut menunjukkan bagaimana data mengalir melalui platform kami dalam empat peringkat: menghasilkan, mengambil, mengatur, dan mengaktifkan. Data dihasilkan oleh laman web kami dan aplikasi mudah alih kami. Sesetengah daripada data ini termasuk Graf Identiti Pengguna Cross-Device kami, Peristiwa Penjejakan Perilaku (seperti pandangan halaman dan klik) dan peristiwa streaming yang melalui Kinesis. Microservices Platform Visitor digunakan untuk mengambil dan mengatur data ini. data dalam ScyllaDB disimpan dalam dua ruang kunci: Ruang kunci Kunci Pengunjung, yang mengandungi Graf Identiti Pengunjung The Visitor Metric keyspace, yang mengandungi Fakta dan Metrik (perkara yang orang lakukan semasa mereka menelusuri laman) Kami menggunakan proses ETL sehari-hari untuk mengekalkan dan membersihkan data dalam platform.Kami menghasilkan Produk Data, dipaparkan setiap hari, dalam gudang data offline kami – di mana mereka tersedia untuk integrasi lain dan paip data lain untuk digunakan dalam pemprosesan mereka. Berikut ialah pandangan Platform Pengunjung mengikut nombor: Mengapa dua pangkalan data? Pangkalan data dalam talian kami memberi tumpuan kepada trafik laman web dalam masa nyata. ScyllaDB memenuhi peranan ini dengan menyediakan latensi yang sangat rendah dan aliran yang tinggi. kami menggunakan TTL jangka pendek untuk mengelakkan data dalam pangkalan data dalam talian daripada berkembang tanpa batas, dan kerja-kerja penyimpanan data kami memastikan bahawa kami hanya menyimpan data aktiviti pengguna untuk pelawat sebenar. TripAdvisor.com mendapat banyak trafik bot, dan kami tidak mahu menyimpan data mereka dan cuba untuk menyesuaikan bot - jadi kami memadam dan membersihkan semua data itu. Penyimpanan data luar talian kami menyimpan data bersejarah yang digunakan untuk melaporkan, mewujudkan produk data lain, dan melatih Model ML kami.Kami tidak mahu proses data luar talian skala besar yang memberi kesan kepada prestasi laman langsung kami, jadi kami mempunyai dua pangkalan data berasingan yang digunakan untuk dua tujuan yang berbeza. Platform Pengunjung Microservices Kami menggunakan 5 microservices untuk Platform Pengunjung: Visitor Core menguruskan grafik identiti pengguna antara peranti berdasarkan kuki dan ID peranti. Visitor Metric adalah enjin pertanyaan kami, dan ia menyediakan kami dengan keupayaan untuk mendedahkan fakta dan metrik untuk pelawat tertentu. kami menggunakan bahasa khusus domain yang dipanggil bahasa pertanyaan pelawat, atau VQL. Contoh VQL ini membolehkan anda melihat fakta klik perdagangan terkini dalam tempoh tiga jam yang lalu. Visitor Publisher dan Visitor Saver menguruskan laluan penulisan, menulis data ke dalam platform. Selain menyimpan data dalam ScyllaDB, kami juga mengalir data ke gudang data dalam talian. Visitor Composite menyederhanakan penerbitan data dalam kerja pemprosesan batch. Ia merangkumi Visitor Saver dan Visitor Core untuk mengenal pasti pelawat dan menerbitkan fakta dan metrik dalam panggilan API tunggal. Perkhidmatan Microservice Latency Graf ini menggambarkan bagaimana latensi microservice kami kekal stabil sepanjang masa. Latens rata-rata hanya 2.5 milliseconds, dan P999 kami kurang daripada 12.5 milliseconds.Ini adalah prestasi yang mengesankan, terutamanya mengingat bahawa kami menangani lebih daripada 1 bilion permintaan setiap hari. Pelanggan microservice kami mempunyai keperluan latency yang ketat. 95% panggilan mesti diselesaikan dalam 12 millisecond atau kurang. ScyllaDB Latentiti Berikut adalah snapshot prestasi ScyllaDB dalam tempoh tiga hari. Pada puncaknya, ScyllaDB mengendalikan 340,000 operasi setiap saat (termasuk menulis dan membaca dan memadamkan) dan CPU melayang pada hanya 21%. ScyllaDB memberikan microsecond menulis dan millisecond membaca untuk kami. tahap prestasi yang cepat ini adalah sebab mengapa kami memilih ScyllaDB. Pembahagian data ke ScyllaDB Imej ini menunjukkan bagaimana kami memisahkan data ke dalam ScyllaDB. The Visitor Metric Keyspace mempunyai dua jadual: Fact dan Raw Metrics. Kunci utama pada jadual Fact ialah Visitor GUID, Fact Type, dan Created At Date. Kunci partition komposit ialah Visitor GUID dan Fact Type. Kunci cluster adalah Created At Date, yang membolehkan kita mengatur data dalam partisi mengikut tarikh. lajur atribut mengandungi objek JSON yang mewakili peristiwa yang berlaku di sana. Sesetengah contoh Fakta ialah Syarat Carian, Pandangan Halaman, dan Tempahan. Kami menggunakan ScyllaDB Strategy Leveled Compaction kerana: Ia dioptimumkan untuk pertanyaan rentang Ia menangani kardinalitas yang tinggi sangat baik Ia lebih baik untuk beban kerja yang berat membaca, dan kita mempunyai kira-kira 2-3X lebih banyak membaca daripada menulis Mengapa ScyllaDB? Penyelesaian kami mula-mula dibina menggunakan Cassandra on-prem. Tetapi apabila skala meningkat, beban operasi juga meningkat. Ia memerlukan sokongan operasi yang berdedikasi bagi kami untuk menguruskan peningkatan pangkalan data, cadangan, dan lain-lain Juga, penyelesaian kami memerlukan latensi yang sangat rendah untuk komponen teras. Sistem Pengurusan Identiti Pengguna kami mesti mengenal pasti pengguna dalam tempoh 30 millisecond – dan untuk personalisasi yang terbaik, kami memerlukan platform Pengesanan Peristiwa kami untuk bertindak balas dalam masa 40 millisecond. Adalah penting bahawa penyelesaian kami tidak menghalang penyerahan halaman sehingga SLA kami sangat rendah. Dengan Cassandra, kami mempunyai kesan kepada prestasi daripada pengumpulan sampah. Kami menjalankan Proof of Concept dengan ScyllaDB dan mendapati aliran jauh lebih baik daripada Cassandra dan beban operasi dihilangkan. Kami mahu opsyen yang diuruskan sepenuhnya, jadi kami bermigrasi dari Cassandra ke ScyllaDB Cloud, mengikuti strategi penulisan ganda.Ia membolehkan kami bermigrasi dengan masa henti semasa mengendalikan 40,000 operasi atau permintaan setiap saat.Selepas itu, kami bermigrasi daripada ScyllaDB Cloud ke model ScyllaDB "Bring Your Own Account", di mana anda boleh memohon pasukan ScyllaDB untuk mengimplementasikan pangkalan data ScyllaDB ke dalam akaun AWS anda sendiri. Diagram ini menunjukkan bagaimana penyebaran BYOA ScyllaDB kelihatan. Di tengah-tengah carta, anda boleh melihat cluster ScyllaDB 6 node yang dijalankan pada EC2. ScyllaDB Monitor memberi kita papan panduan Grafana serta metrik Prometheus. ScyllaDB Manager menguruskan automatik infrastruktur seperti memicu backup dan pembaikan. Dengan penyebaran ini, ScyllaDB boleh ditempatkan bersama sangat dekat dengan microservices kami untuk memberi kita latensi yang lebih rendah serta aliran dan prestasi yang lebih tinggi. Secara ringkas, saya berharap anda kini mempunyai pemahaman yang lebih baik mengenai seni bina kami, teknologi yang menggerakkan platform ini, dan bagaimana ScyllaDB memainkan peranan penting dalam membolehkan kami menangani skala yang sangat tinggi TripAdvisor. Maklumat lanjut Cynthia Dunlop Cynthia adalah Pengarah Senior Strategi Kandungan di ScyllaDB. Beliau telah menulis mengenai pembangunan perisian dan kejuruteraan kualiti selama lebih daripada 20 tahun.