See the engineering behind real-time personalization at Tripadvisor’s massive (and rapidly growing) scale Tripadvisor се обидува да го процени ова веднаш штом ќе се вклучите со сајтот, а потоа да ви понуди повеќе релевантни информации на секое кликнување - во прашање на милисекунди. Во оваа статија, Дин Полин (Лидер за инженеринг на податоци на TripAdvisor во тимот за услуги и производи за вештачка интелигенција) дава поглед на тоа како тие ја зголемуваат оваа персонализација. Тоа се базира на следното AWS re:Invent разговор: Прелиминарна ориентација Во зборовите на Дејн... Да почнеме со брз преглед на тоа кој е 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, почнуваме да го персонализираме она што го гледате користејќи модели за машинско учење кои ги пресметуваат резултатите врз основа на вашата моментална и претходна активност во пребарувањето. Препорачуваме хотели и искуства за кои мислиме дека ќе бидете заинтересирани. Ние ги сортираме хотели врз основа на вашите лични преференции. Препорачуваме популарни точки од интерес во близина на хотелот што го прегледувате. Моделот на TripAdvisor кој служи архитектура Tripadvisor работи на стотици независно скалабилни микро-услуги во Kubernetes on-prem и во Amazon EKS. Нашата ML Model Serving Platform е изложена преку една од овие микро-услуги. Оваа портална услуга извлекува повеќе од 100 ML модели од услугите на клиентите – што ни овозможува да извршиме А / Б тестови за да ги најдеме најдобрите модели користејќи ја нашата платформа за експериментирање. ML моделите главно ги развиваат нашите Научници за податоци и Инженери за машинско учење кои користат Jupyter Notebooks на Kubeflow. Тие се управуваат и обучуваат користејќи ML Flow, а ние ги распоредуваме на Seldon Core во Kubernetes. Магазин со карактеристики Магазинот на карактеристики главно служи за кориснички карактеристики и статички карактеристики. Статичките карактеристики се складираат во Redis бидејќи тие не се менуваат многу често. Ние секојдневно управуваме со цевки за податоци за да ги вчитаме податоците од нашиот офлајн магацин за податоци во нашиот Магазин на карактеристики како статички карактеристики. Корисничките функции се испорачуваат во реално време преку платформа наречена Посетителска платформа. Ние извршуваме динамички CQL барања против ScyllaDB, и . we do not need a caching layer because ScyllaDB is so fast Нашата функција продавница обезбедува до 5 милиони статички функции во секунда и половина милион кориснички функции во секунда. Што е ML карактеристика? Функциите се вметнувачки променливи на ML моделите кои се користат за да се направи предвидување. Некои примери за статички карактеристики се награди што ресторанот ги освоил или удобностите што ги нуди хотелот (како што се бесплатен Wi-Fi, пријателски на домашни миленици или фитнес центар). Корисничките карактеристики се собираат во реално време додека корисниците пребаруваат низ сајтот. Ние ги зачувуваме во ScyllaDB за да можеме да добиеме молња брзи барања. Некои примери на кориснички карактеристики се хотели прегледувани во текот на последните 30 минути, ресторани прегледувани во текот на последните 24 часа, или рецензии поднесени во текот на последните 30 дена. Технологијата што ја поттикнува посетителската платформа ScyllaDB е во срцето на Платформата за посетители. Ние ги користиме микро-услугите Spring Boot базирани на Java за да ја изложиме платформата на нашите клиенти. Ова се имплементира на AWS ECS Fargate. Ние работиме со Apache Spark на Kubernetes за нашите дневни задачи за задржување на податоци, нашите офлајн на онлајн работни места. Потоа ги користиме тие работни места за да ги вчитаме податоците од нашиот офлајн магацин на податоци во ScyllaDB, така што тие се достапни на живо на сајтот. Ние исто така користиме Amazon Kinesis за обработка на настани за следење на корисниците. Поток на податоци на платформата за посетители Следниот графикон покажува како податоците течат низ нашата платформа во четири фази: произведување, внесување, организирање и активирање. Податоците се произведуваат од страна на нашата веб-страница и нашите мобилни апликации. Некои од тие податоци вклучуваат нашиот Cross-Device User Identity Graph, настани за следење на однесувањето (како што се прегледи на страници и кликови) и настани за стриминг кои одат преку Kinesis. Микро-услугите на Посетителската платформа се користат за собирање и организирање на овие податоци.Податоците во ScyllaDB се чуваат во два клучни простори: Посетителскиот кључен простор, кој го содржи Графот за идентитет на посетител Посетител метричен клучен простор, кој содржи факти и метрики (нештата што луѓето ги направија додека го пребаруваа сајтот) Ние ги произведуваме производите за податоци, секојдневно печатени, во нашиот офлајн складиште за податоци – каде што тие се достапни за други интеграции и други цевки за податоци за да се користат во нивната обработка. Еве еден поглед на Посетител платформа по броеви: Зошто две бази на податоци? Нашата онлајн база на податоци е фокусирана на сообраќајот на веб-страниците во реално време. ScyllaDB ја исполнува оваа улога со обезбедување на многу ниски задоцнувања и висок промет. Ние користиме краткорочни TTLs за да ги спречиме податоците во онлајн базата на податоци да растат на неограничено време, а нашите задачи за задржување на податоци гарантираат дека ги чуваме само податоците за активноста на корисниците за вистинските посетители. Нашето офлајн складиште за податоци ги задржува историските податоци што се користат за известување, создавање на други производи за податоци и обука на нашите ML модели. Ние не сакаме големи офлајн податоци процеси кои влијаат на перформансите на нашата живо сајт, па имаме две одделни бази на податоци кои се користат за две различни цели. Платформа за посетители Microservices Ние користиме 5 микро-услуги за Платформата за посетители: Visitor Core управува со графиконот на идентитетот на корисникот на различни уреди врз основа на колачињата и идентитетот на уредот. Посетител Метрик е нашиот мотор за пребарување, и тоа ни дава можност за изложување на факти и метрики за специфични посетители. Ние користиме домен специфичен јазик наречен јазик за пребарување на посетители, или VQL. Овој пример VQL ви овозможува да ги видите најновите факти за трговија кликнете во текот на последните три часа. Visitor Publisher и Visitor Saver се справуваат со патот за пишување, пишување на податоци во платформата. Покрај зачувување на податоци во ScyllaDB, ние исто така ги пренесуваме податоците во офлајн складиштето на податоци. Visitor Composite го поедноставува објавувањето на податоците во задачите за обработка на партиите. Тој ги апстрахира Visitor Saver и Visitor Core за да ги идентификува посетителите и да ги објавува фактите и метриките во еден API повик. Roundtrip Microservice Латенција Овој графикон илустрира како нашите микро-услуги латенции остануваат стабилни со текот на времето. Просечната латенција е само 2,5 милисекунди, а нашиот P999 е под 12,5 милисекунди. Нашите клиенти за микро-услуги имаат строги барања за задоцнување. 95% од повиците мора да се завршат за 12 милисекунди или помалку. ScyllaDB Латенција Еве скратен преглед на перформансите на ScyllaDB во текот на три дена. На врвот, ScyllaDB обработува 340.000 операции во секунда (вклучувајќи ги и пишувањата и читањата и бришењата), а процесорот се колеба на само 21%. ScyllaDB обезбедува microsecond пишување и millisecond читање за нас. Поделување на податоци во ScyllaDB Оваа слика покажува како ги партиционираме податоците во ScyllaDB. Посетителскиот метрички клучен простор има две табели: Факт и сурова метрика. Примарниот клуч на табелата Факт е Посетителскиот ГУИД, Типот на Факт и Создаден на датум. Композитниот клуч за партиција е Посетителскиот ГУИД и Типот на Факт. Клупскиот клуч е Создаден на датум, што ни овозможува да ги сортираме податоците во партиции по датум. Колоната со атрибути содржи JSON објект кој го претставува настанот што се случи таму. Некои примери Факти се Термините за пребарување, Прегледи на страници и Резервации. Ние ја користиме стратегијата за нивото на компакција на ScyllaDB бидејќи: Оптимизиран за опсег на барања Се справува со висока кардиналност многу добро Тоа е подобро за читање тешки работни оптоварувања, и имаме околу 2-3X повеќе читања отколку пишува Зошто ScyllaDB? Нашето решение првобитно беше изградено со користење на Cassandra on-prem. Но, како што се зголеми скалата, исто така и оперативното оптоварување. Тоа бараше посветена оперативна поддршка за да можеме да управуваме со надградби на базата на податоци, резервни копии итн Исто така, нашето решение бара многу ниски латенции за основни компоненти. Нашиот систем за управување со кориснички идентитети мора да го идентификува корисникот во рок од 30 милисекунди – и за најдобра персонализација, бараме нашата платформа за следење на настани да одговори во 40 милисекунди. Критично е нашето решение да не го блокира рендерирањето на страницата, така што нашите SLAs се многу ниски. Извршивме Проверка на концептот со ScyllaDB и откривме дека пропустот е многу подобар од Cassandra и оперативното оптоварување беше елиминирано. Сакавме целосно управувана опција, па мигриравме од Cassandra на ScyllaDB Cloud, по стратегија за двојно пишување. Тоа ни овозможи да мигрираме со нула прекин на времето додека обработуваме 40.000 операции или барања во секунда. Подоцна, мигриравме од ScyllaDB Cloud на ScyllaDB "Донесете ја вашата сметка" модел, каде што можете да имате ScyllaDB тим да ги распоредите ScyllaDB базата на податоци во вашата сопствена AWS сметка. Овој дијаграм покажува како изгледа распоредувањето на BYOA на ScyllaDB. Во центарот на дијаграмот, можете да видите 6-ноден ScyllaDB кластер кој работи на EC2. ScyllaDB Monitor ни дава Grafana табла, како и Prometheus метрики. ScyllaDB Manager се грижи за автоматизација на инфраструктурата како што се активирање на резервни копии и поправки. Со оваа имплементација, ScyllaDB би можел да биде ко-лоциран многу блиску до нашите микро-услуги за да ни даде уште пониски латенции, како и многу поголем промет и перформанси. Заедно, се надевам дека сега имате подобро разбирање на нашата архитектура, технологиите кои ја поддржуваат платформата и како ScyllaDB игра критична улога во овозможувањето да се справиме со исклучително високиот обем на TripAdvisor. Од Cynthia Dunlop Синтија е старши директор за содржина стратегија во ScyllaDB. Таа е пишување за развој на софтвер и квалитет инженеринг за повеќе од 20 години.