Расширение Airbnb в области домов, впечатлений и услуг потребовало пересмотра структуры моделирования данных для их автономного хранилища данных. Основная задача заключалась в достижении баланса между согласованностью и гибкостью, чтобы избежать разрозненности данных и технического долга. Был выбран сбалансированный подход, сочетающий централизованные принципы с децентрализованными рекомендациями по моделированию. Три основополагающих принципа обеспечили согласованность: отсутствие гибридных моделей, единообразное именование идентификаторов и четкая организация пространств имен. Рекомендации по моделированию позволили командам выбирать между раздельными или монолитными моделями на основе общих и уникальных атрибутов, будущего развития и нижестоящих потребителей. Продуктовые домены, такие как списки, доступность, местоположение и взаимодействие с гостями, выбрали раздельные модели из-за отличительных атрибутов. Напротив, сквозные концепции, такие как сообщения, платежи и поддержка клиентов, выиграли от монолитной модели для унифицированного представления. Автономное хранилище данных выступает в качестве важного слоя трансляции, стандартизируя необработанные производственные данные для аналитики. Управление долгом данных, включая миграцию устаревших таблиц, было значительным предприятием, требующим тщательного общения и проверки. Эта структура обеспечила масштабируемую и согласованную основу для меняющихся потребностей Airbnb в данных.

Airbnb разработала Sitar Agent — легковесный сайдкар для Kubernetes, предназначенный для надежной доставки динамических изменений конфигурации тысячам экземпляров сервисов. Доставка конфигурации начинается с того, что разработчики создают или обновляют значения через Git или пользовательский интерфейс, которые затем сохраняются в Sitar Service. Периодически полное состояние конфигураций упаковывается в сжатые снимки и загружается в AWS S3. Когда запускается под сервиса, Sitar Agent сначала загружает эти снимки из S3 на смонтированный диск, что обеспечивает быструю загрузку. Затем он синхронизируется с Sitar Service для получения любых изменений, сделанных с момента создания снимка, сигнализируя о готовности основному контейнеру приложения. После запуска агент непрерывно опрашивает Sitar Service на предмет обновлений каждые несколько секунд. Основной контейнер приложения считывает конфигурации с смонтированного диска, используя клиентскую библиотеку Sitar, которая кэширует значения и обнаруживает изменения в файлах. Ключевым решением при проектировании было сохранение Sitar Agent в виде отдельного сайдкар-контейнера, а не интеграция его в основной контейнер, что позволило приоритизировать надежность, эксплуатационную безопасность и поддержку нескольких языков вместо незначительной экономии средств. Система использует модель извлечения (pull model), при которой агент опрашивает Sitar Service, оптимизированную с помощью кэша на стороне сервера и доступа к базе данных на основе токенов для снижения нагрузки. Для своего локального хранилища ключ-значение на диске Airbnb выбрала SQLite вместо устаревшей реализации на базе Sparkey из-за превосходной параллельности, производительности и поддержки нескольких языков в SQLite. Встроенный механизм ведения журнала с упреждающей записью (Write-Ahead Logging) в SQLite позволяет выполнять параллельные чтения во время записи, а его более простая операционная модель была предпочтительнее более высокой производительности, но большей сложности RocksDB. Эта надежная конструкция сайдкара гарантирует быструю и надежную доставку критически важных конфигураций по всему обширному парку сервисов Airbnb.

Пандемия COVID-19 представляла собой вызов для прогнозирования, поскольку она нарушила исторические закономерности, сделав традиционные модели ненадежными. Восстановление спроса было асинхронным и неравномерным географически, с различными сроками развертывания вакцин и открытия границ. Ожидание местных данных на каждом восстанавливающемся рынке означало бы прогнозирование вслепую в течение длительных периодов. Решением Airbnb было смотреть в стороны по географическим регионам, а не только назад во времени. Они заметили, что восстановление происходило последовательно, причем одни коридоры испытывали изменения раньше других. Ключевым сигналом было среднее время бронирования, которое сокращалось во время сбоев и увеличивалось во время восстановления. Сравнивая время этих изменений времени бронирования между регионами, такими как Европа и Северная Америка, они могли предположить, как один рынок, вероятно, отреагирует на открытие, основываясь на опыте другого. Это позволило им использовать апостериорное распределение из раннего коридора как информативное априорное распределение для более позднего. Этот механизм распространения априорных данных обеспечил обучение и прогнозирование в реальном времени, даже на рынках с ограниченными местными данными. Подход требовал глобального присутствия с детальными данными и иерархической байесовской модели. Эта методология применима не только в кризисных ситуациях, но и, например, для прогнозирования влияния внедрения новых функций продукта или изменений в законодательстве. Она позволяет немедленно учиться на рынках ранних последователей, чтобы информировать прогнозы для тех, кто еще не столкнулся с изменениями.

Airbnb перешла от использования графовой базы данных PaaS к созданию внутренней инфраструктуры графа знаний для повышения производительности. Граф идентификации, имеющий решающее значение для доверия и безопасности, первоначально полагался на реляционные базы данных, а затем на графовую базу данных SaaS, сталкиваясь с проблемами масштабируемости и задержек. Новая, управляемая внутри компании инфраструктура, построенная на основе JanusGraph и DynamoDB, предоставляет единую платформу. Для удовлетворения потребностей Airbnb в производительности были реализованы ключевые оптимизации, такие как пользовательские транзакции и параллельное выполнение запросов. Эта платформа поддерживает многопользовательские операции с обеспечением соблюдения схемы. Оптимизация запросов на стороне клиента, включая переписывание запросов Gremlin, еще больше повысила производительность. Внутренняя графовая инфраструктура значительно увеличила масштабируемость и улучшила стабильность системы. Достигнут прирост производительности по различным шаблонам запросов, что привело к ускорению времени отклика API при чтении. Самоуправляемая система обеспечивает более быстрое разрешение инцидентов. Новая система масштабировалась до 10-кратного увеличения QPS записи по сравнению с предыдущим решением. Миграция привела к значительному снижению задержки P99 для сложных запросов. Граф знаний Airbnb теперь поддерживает критически важные варианты использования.

Виадук — это ориентированная на данные сервисная сетка Airbnb, теперь выпущенная как проект, управляемый сообществом, со стабильным API. Он служит интерфейсом на основе GraphQL для доступа и взаимодействия с различными источниками данных. Цель Viaduct — предоставить центральную схему для данных организации, обеспечивая при этом децентрализованную разработку. В отличие от GraphQL Federation, Viaduct распределяет разработку через модули, размещенные в общей многопользовательской среде выполнения. Команды вносят вклад, создавая модули с SDL и резольверами, уделяя основное внимание логике предметной области. Viaduct также может функционировать как подграф в рамках федеративной архитектуры. Выпуск 1.0 включает новые функции, стабильность благодаря аннотациям и автоматизированные выпуски. Airbnb стремится к участию сообщества, используя GitHub для обсуждения архитектуры. В статье освещаются предстоящие обсуждения на GraphQLConf 2026 инженерами Airbnb, демонстрирующие возможности Viaduct. К ним относятся вероятностное тестирование, мониторинг, решения для шардинга и генерация фиктивных данных с использованием LLM. В объявлении поощряется участие тех, кто стремится унифицировать слои данных или внести вклад в проект.

Основная проблема заключается в том, что системы наблюдаемости могут выходить из строя, когда выходит из строя инфраструктура, которую они отслеживают, создавая циклические зависимости. Airbnb, как и многие организации, столкнулась с этой проблемой, когда их конвейер метрик зависел от тех же систем, которые он наблюдал. Эту цепочку зависимостей необходимо было разорвать, чтобы обеспечить надежный мониторинг, особенно во время сбоев. Чтобы решить эту проблему, Airbnb изолировала вычисления, используя выделенные кластеры Kubernetes, управляемые командой Cloud. Они переосмыслили работу сети, построив собственный уровень входящего трафика Layer 7 на основе Envoy, чтобы обойти сервисную сетку для телеметрии, обеспечивая приоритезацию и изоляцию. Метрики имеют уникально большой объем, поэтому выделенный сетевой путь позволяет избежать перегрузок и потенциальных сбоев. Airbnb также внедрила мета-мониторинг, отслеживая сам стек наблюдаемости для выявления потенциальных проблем. Важной частью мета-мониторинга является использование механизма "Dead Man's Switch" для обнаружения сбоев в системе мониторинга. Этот общий подход создает надежную цепочку сигналов, которая защищает от скрытых сбоев в настройке наблюдаемости. Ключевым выводом является отношение к мониторингу как к производственной системе, обеспечивающее его надежность, превосходящую надежность наблюдаемых систем. Это имеет решающее значение для обеспечения оперативного реагирования на инциденты и поддержания доверия пользователей и бизнеса. Эти принципы применимы повсеместно и включают в себя изоляцию областей сбоев для надежной разработки системы.

Airbnb столкнулась с проблемой надежного выполнения сложных рабочих процессов, таких как страховые претензии. Существующие решения, такие как внешние механизмы оркестровки, имели недостатки, включая операционную сложность и зависимость от поставщика. Чтобы решить эти проблемы, Airbnb создала Skipper, встроенный механизм рабочих процессов, который работает внутри каждой службы. Skipper отдает приоритет лаконичности, отсутствию единых точек отказа и использованию существующей базы данных. Основой конструкции Skipper являются рабочие процессы, которые определяют логику и действия, инкапсулирующие отдельные операции. Долговечность достигается за счет механизма повторного воспроизведения, сохраняющего результаты действий в базе данных. Повторное воспроизведение позволяет рабочим процессам возобновляться с того места, где они были прерваны. Поля состояния сохраняются для эффективности, используя сигналы для обновления состояния рабочего процесса. Тестирование рабочих процессов с помощью Skipper упрощено, так как ему не нужно настраивать очереди или имитировать какую-либо инфраструктуру. Этот подход обеспечивает надежное выполнение без добавления зависимостей или снижения производительности.

Airbnb разработала внутреннюю систему хранения для обработки 50 миллионов образцов в секунду и 2,5 петабайт временных рядов данных. Этот переход был необходим из-за огромного объема данных, генерируемых обширной инструментовкой кода по всей эволюционирующей продукции и инфраструктуре. Основной инженерной задачей было сохранение и обслуживание этого огромного набора данных с высокой производительностью. Для управления таким масштабом Airbnb приняла многоарендную архитектуру, изолируя арендаторов по сервису или процессу для стабильной группировки и атрибуции. Они реализовали шардирование shuffle для изоляции рабочих нагрузок арендаторов, повышая отказоустойчивость за счет обеспечения того, чтобы арендаторы записывали и запрашивали только подмножество узлов. Операционную сложность, особенно настройку арендаторов и управление конфигурацией, решала консолидированная плоскость управления, автоматизирующая настройку и упрощающая обновления конфигурации. Ключевыми требованиями для системы были обработка более 50 миллионов образцов в секунду, поддержка многочисленных панелей управления и оповещений, а также поддержание низких времен выполнения запросов. Первоначальная проверка с помощью тень-clusетров показала проблемы с надежностью, задержки уплотнения и медленную производительность запросов, особенно с большими данными. Решение этих проблем началось с обеспечения надежности одного кластера, сосредоточившись на стабилизации записей, чтений и уплотнения через бенчмаркинг, ограничители и изоляцию путей запросов. Система была сделана отказоустойчивой с помощью компонентов, осведомленных о зонах, развернутых по три зоны. Были реализованы ограничения на реплику и контроли на уровне арендатора для эффективного управления флотом и защиты системы. Затем была принята много-кластерная архитектура для уменьшения радиуса действия сбоев и повышения гибкости. Этот много-кластерный подход, однако, ввел сложности в открытие метрик, запросы и операционные накладные расходы. Эти сложности были смягчены с помощью инструментов для сопоставления арендатор-кластер и автоматизированных стратегий развертывания с помощью операторов Kubernetes. Введение Promxy с пользовательскими улучшениями облегчило меж-кластерные запросы и оповещения. Ключевые выводы из этого пути включают значительную стоимость меж-кластерных запросов и важность согласованности развертывания, достигаемой за счет автоматизации и стандартизированных развертываний. Философия эволюционировала в сторону рассмотрения кластеров как одноразовых ресурсов, подобных "скоту", а не критических, уникальных "домашних животных", что позволяет легче масштабировать и обслуживать. В конечном итоге, создание этой платформы требовало сочетания архитектурных инноваций, операционной строгости и культурного сдвига в управлении ожиданиями.

Airbnb превращается в более социальную платформу, делая акцент на связях в сообществе через "Впечатления". Платформа уделяет приоритетное внимание конфиденциальности пользователей, проводя различие между внутренними данными пользователей и общедоступными профилями. Пользователи контролируют видимость своих профилей, выбирая, какая информация будет отображаться во "Впечатлениях". Для управления этим Airbnb использует уникальные идентификаторы пользователей (User IDs) и идентификаторы профилей (Profile IDs) для различных контекстов, что обеспечивает гибкие настройки конфиденциальности. Это позволяет пользователям иметь несколько профилей, например, профили хозяина и гостя, которые при необходимости хранятся отдельно. Airbnb использует систему разрешений под названием Himeji, обеспечивающую доступ с минимальными привилегиями и надежную безопасность данных. Реализация включала автоматизированные аудиты, командное сотрудничество и рефакторинг с помощью ИИ для обеспечения правильного использования идентификаторов. Типобезопасность и тщательное тестирование были крайне важны для поддержания целостности данных во время миграции. В конечном итоге, принципы конфиденциальности Airbnb направлены на то, чтобы сбалансировать социальные функции с контролем пользователей над личной информацией. Такой подход призван способствовать как общению, так и конфиденциальности в сообществе Airbnb. Эта система внедрена для того, чтобы пользователи могли уверенно общаться и делиться информацией с другими.

Миграция включала в себя перемещение большого конвейера метрик из StatsD в OpenTelemetry и Prometheus, с целью предварительного сбора метрик. Первоначальный акцент был сделан на инструментировании с использованием OpenTelemetry Protocol (OTLP) для внутренних сервисов и Prometheus для рабочих нагрузок с открытым исходным кодом, с StatsD в качестве резервного варианта. Подход с двойной записью, использующий общую библиотеку метрик, облегчил переход на OTLP. Это привело к улучшению производительности и доступу к функциям Prometheus, таким как гистограммы. Однако метрики высокой кардинальности вызвали регрессию производительности, которую устранили, используя дельта-темпоральность для выбранных сервисов. Был реализован конвейер агрегации на основе Prometheus с использованием vmagent для снижения затрат и обеспечения преобразований. Возникла проблема, когда функция rate() в Prometheus недосчитывала определенные счетчики из-за событий сброса. Они реализовали нулевую инъекцию во время агрегации для исправления расхождений, что было сделано прозрачно для пользователя. Это обеспечило решение проблемы со счетчиками и гарантировало точное представление данных. Наконец, команда создала готовую к будущему инфраструктуру метрик, внедрив эти изменения.

Джонатан Вудард, бывший профессиональный футболист, сменил карьеру на разработку программного обеспечения, увлекшись кодированием. Он присоединился к программе ученичества Connect Engineering в Airbnb, найдя новую среду для обучения и роста. Программа ученичества обеспечила структурированное обучение, командную работу и наставничество, что было крайне важно для его перехода. Во время программы он изучал разработку серверной части, область, которую он изначально не рассматривал. Он преуспел, в конечном итоге получив постоянную должность в команде разработки безопасности Airbnb. Его работа сосредоточена на управлении идентификацией и доступом, а также управлении уязвимостями, сталкиваясь с новыми вызовами интеграции LLM. Вудард видит параллели между футболом и инженерной безопасностью, особенно в ситуациях высокого давления и командной работе. Он приписывает свой успех своей команде и культуре сотрудничества в Airbnb. Он делится своим опытом, чтобы поощрять нетрадиционные пути карьерного роста в сфере технологий. Сейчас он может поддерживать новых учеников в качестве выпускника-хоста. Он считает работу захватывающей, опираясь на свой опыт для принятия быстрых решений.

Прогностические модели Airbnb, имеющие решающее значение для финансового планирования, столкнулись с серьезными нарушениями во время пандемии COVID-19. Основная проблема заключалась в том, что исторически стабильная взаимосвязь между бронированиями и датами поездок стала крайне нестабильной. Чтобы решить эту проблему, Airbnb разделила свое прогнозирование на два компонента: общий объем бронирований и структуру времени ожидания. Они разработали модели B-DARMA, специально предназначенные для обработки изменяющихся пропорций, связанных со временем ожидания бронирования. Удивительно, но даже после восстановления общего объема бронирований структура времени ожидания демонстрировала устойчивые изменения, не возвращаясь к допандемическим показателям. Airbnb использовала метрику расхождения распределений для мониторинга и количественной оценки этих долгосрочных изменений, которая стала жизненно важным инструментом для диагностики состояния модели. Эти устойчивые изменения напрямую повлияли на прогнозирование доходов, движение денежных средств и операционные решения, подчеркнув важность точного моделирования распределений. Чтобы улучшить прогнозирование, они разработали возможность учиться на структурных разрывах, позволяя моделям адаптироваться к изменениям. Разделив и проанализировав эти компоненты, Airbnb создала более устойчивые модели прогнозирования, способные обнаруживать и адаптироваться к структурным сдвигам.

Airbnb перенесла свою платформу наблюдаемости с управляемого сторонним поставщиком сервиса на собственное решение, основанное на технологиях с открытым исходным кодом. Основной мотивацией было снижение затрат и получение большего контроля над данными и рабочими процессами. Первоначальная стратегия миграции предполагала сначала перенос сложного сервиса, но это оказалось неэффективным. Пересмотренная стратегия сосредоточилась на миграции более простого сервиса, чтобы доказать осуществимость и заложить прочный фундамент. Новый подход отдавал приоритет полной миграции над немедленным улучшением запросов, чтобы избежать перегрузки пользователей слишком большим количеством изменений. Они создали инструментарий для преобразования, чтобы сопоставить существующие панели мониторинга и оповещения с новой системой. Они сосредоточились на миграции намерений запросов, а не на прямых преобразованиях, исправляя ошибочные шаблоны. Внедрение механизма метаданных обеспечило точную типизацию метрик в новой системе. Они приняли PromQL, широко понятный язык запросов, и интегрировали инструментарий на базе искусственного интеллекта для помощи в генерации запросов. Миграция также позволила заменить устаревший фреймворк оповещений. Этот комплексный пересмотр привел к созданию превосходного инструментария, согласованности данных и значительному улучшению опыта разработчиков.

Команда Airbnb разработала модель рекомендаций направлений, чтобы помочь пользователям на ранних этапах планирования поездки. Эта модель решает проблему пользователей, которые еще не определились с направлением или датами поездки. Модель предсказывает намерения пользователей относительно направления, анализируя их действия на платформе Airbnb, такие как поиски и бронирования. Ключевым нововведением является интеграция разнообразных сигналов, балансировка активного и пассивного поведения пользователей и включение знаний о местоположении. Модель использует архитектуру трансформера, рассматривая действия пользователей как токены для понимания их предпочтений. Данные для обучения специально разработаны для учета как активных пользователей, близких к бронированию, так и пассивных пользователей на начальном этапе планирования. Многозадачное обучение используется для прогнозирования направлений как на уровне региона, так и на уровне города, улучшая понимание местоположения. Модель обеспечивает работу автоподсказок и уведомлений по электронной почте о брошенных поисках, помогая пользователям находить потенциальные направления. В автоподсказках она предлагает рекомендации по городам, что приводит к увеличению бронирований, особенно в неанглоязычных регионах. Электронные письма о брошенных поисках содержат объявления в рекомендуемых районах, поощряя завершение бронирования. Ориентируясь на этап исследования, модель стремится вдохновить, уменьшить трение при принятии решений и повысить вовлеченность пользователей. Эта структура обеспечивает основу для персонализации на протяжении всего процесса планирования поездки, включая время поездок и ценовые предпочтения.

Наблюдаемость как код (OaC) в Airbnb определяет оповещения, панели мониторинга и SLO через код, отражая методы разработки программного обеспечения. Хотя этот процесс обеспечивает дисциплинированное определение оповещений, проверка поведения оповещений в рабочей среде была серьезной проблемой. Этот пробел приводил либо к чрезмерному шуму оповещений, либо к пропущенным инцидентам, что затрудняло рабочий процесс разработчиков. Чтобы решить эту проблему, Airbnb создала доступные циклы обратной связи для предварительного просмотра и проверки поведения оповещений до отправки кода. Это нововведение значительно сократило циклы разработки с недель до минут. Цель OaC компании состоит в том, чтобы команды разработчиков получали готовый мониторинг от команд платформы, достигая "нулевого касания". Однако управление 300 000 оповещений делало итерации и проверку изменений OaC дорогостоящими и рискованными. Традиционные обзоры кода и модульные тесты не могли предсказать, как оповещения будут вести себя с реальными данными, что приводило к многонедельному процессу проверки. Airbnb перестроила свою платформу OaC, ориентируясь на разработку local-first, отчеты об изменениях и массовое обратное тестирование на основе исторических данных. Это позволило инженерам быстро и эффективно проверять шаблоны оповещений. Основные выводы включали в себя приоритет совместимости над новизной, внедрение надежных ограждений и владение всей областью разработки для улучшения опыта разработчиков. Результатом стала успешная миграция 300 000 оповещений в Prometheus, сокращение циклов разработки и значительное снижение шума оповещений, способствующее культуре гигиены оповещений.

В 2025 году Airbnb значительно продвинула свои исследования в области искусственного интеллекта и машинного обучения, сосредоточившись на улучшениях платформы для путешествий и проживания. Компания активно участвовала в ключевых конференциях по машинному обучению, таких как KDD и CIKM, расширяя свое присутствие на мероприятиях, посвященных NLP и оптимизации. Исследователи публиковали статьи, представляли результаты и развивали сотрудничество, внося вклад в академическое сообщество. KDD была посвящена поиску и ранжированию, с работами по чередованию, контрфактической оценке и расширению аудитории. CIKM продемонстрировала достижения в области рекомендаций, оптимизации карт и методов ранжирования для объявлений. На EMNLP Airbnb представила исследования по поддержке клиентов на основе LLM, включая методы agent-in-the-loop и суммирования. На COLING Airbnb дебютировала с работой по представлению знаний для поддержки клиентов. Airbnb также выступила на MIT CODE, исследуя долгосрочную динамику ранжирования и принятие решений на основе данных. Их результаты продемонстрировали прогресс в поиске, рекомендациях и обслуживании клиентов благодаря инновационным приложениям ИИ. Исследовательские инициативы Airbnb включали наставничество для начинающих исследователей и содействие изучению технологий с открытым исходным кодом.

Платформа Sitar от Airbnb управляет динамическими изменениями конфигурации, чтобы избежать перезапусков сервисов и обеспечить быстрое реагирование. Эта платформа построена на четырех основных элементах: уровне для разработчиков, плоскости управления, плоскости данных и клиентских компонентах. Уровень разработчика облегчает создание и проверку конфигураций, используя Git-ориентированный рабочий процесс для контроля версий и совместной работы. Плоскость управления организует развертывание изменений, обеспечивая проверку схемы, авторизацию и поэтапные выпуски. Плоскость данных обеспечивает масштабируемое хранение и надежное распространение обновлений конфигурации агентам сервисов. Агенты в каждом сервисе получают конфигурации и кэшируют их локально для быстрого доступа и отказоустойчивости. Ключевые проектные решения включают Git-ориентированные рабочие процессы, поэтапные развертывания и разделение плоскостей управления и данных. Эта архитектура обеспечивает более безопасные и предсказуемые развертывания, предоставляя командам больше гибкости в управлении конфигурациями. Устранение инцидентов происходит быстрее, с использованием интегрированных инструментов наблюдаемости для обнаружения и устранения проблем. Платформа оптимизирует опыт разработчиков и постоянно улучшает безопасность, наблюдаемость и удобство использования. Airbnb постоянно улучшает Sitar, уделяя особое внимание стратегиям развертывания, тестированию и реагированию на инциденты. Эта работа имеет решающее значение для поддержания надежной, адаптируемой и удобной для разработчиков инфраструктуры.

Анна Сулькина, старший директор по разработке Airbnb, рассказывает о своем пути в технологической индустрии. Ее вдохновили брат и первые дни компьютерной техники в Украине, что привело ее к изучению программирования. После иммиграции в Америку она столкнулась с языковыми барьерами, которые поначалу были сложнее, чем само программирование. Ее карьера развивалась от диагностики оборудования до фронтенда и, в конечном итоге, до инфраструктуры, с возрастающей ответственностью за руководство. Она работала в Twitter во время значительных событий, узнав о важности проектирования для неизбежных сбоев в сложных системах. Анна также возглавила внедрение GraphQL в Twitter, что привело к повышению производительности. Она присоединилась к Airbnb, потому что ей нравился продукт и она видела возможность улучшить опыт разработчиков. В Airbnb она сосредоточена на создании надежных платформ для инженеров, способствуя формированию сильной культуры. Она подчеркивает баланс компании между устоявшимися системами и инновационным решением проблем, а также возможность работать удаленно. Наконец, Анна проводит параллели между своей карьерой, бегом по пересеченной местности на длинные дистанции, стратегией и командной работой.

Питер Коулз, глава отдела экономики политики и директор по науке о данных в Airbnb, прошел путь от обучения в государственной школе в Милуоки до получения докторской степени по экономике в Стэнфорде. Его раннее увлечение рынками началось с детского бизнеса по продаже камней. Активно участвуя в академических конкурсах, он позже получил степень по математике в Принстоне, прежде чем заняться экономикой. На его обучение в аспирантуре Стэнфорда повлиял нобелевский лауреат Джон Левин, который подчеркивал важность упрощения в исследованиях. До работы в Airbnb Коулз преподавал в Гарвардской школе бизнеса, где совместно с пионером в области проектирования рынков Элом Ротом вел курс. Там он исследовал механизмы подбора и писал тематические исследования о таких компаниях, как Zillow и Craigslist. Перейдя в технологическую индустрию, он присоединился к eBay, где занимался проектированием рынков и инициативами в области науки о данных. В Airbnb он создал команду экономистов для анализа краткосрочной аренды и ее влияния на города. Он также стал соучредителем Центральной стратегии и аналитики (CSI) для решения более широких организационных вопросов и проведения расследований в стиле криминалистики. В настоящее время он руководит работой по моделированию политических аспектов и оценке влияния Airbnb на общество, развивая сотрудничество с академическими исследователями.

Airbnb успешно запустила более 20 локально актуальных способов оплаты по всему миру всего за 14 месяцев, чтобы повысить доступность и снизить трения для гостей. Эти локальные платежные методы (LPM) включают цифровые кошельки, банковские переводы и схемы местных платежей, выходя за рамки традиционных платежей по картам. Предоставление LPM повышает конверсию, открывает новые рынки с низким использованием кредитных карт и предоставляет доступ для лиц без банковского обслуживания. В ходе обширных исследований Airbnb выделил более 300 вариантов оплаты и использовал структурированную систему для отбора лучших компаний для интеграции. Модернизированная платёжная платформа Airbnb, построенная на архитектуре, управляемой доменом, использовала логику оплаты для гибкости и масштабируемости. Эта реплатформинговая инициатива, известная как Payments LTA, превратилась из монолитной системы в ориентированную на услуги, ускорив выход на рынок. Поддомен обработки, ключевой для интеграции сторонних поставщиков, принял архитектуру на основе соединителей и плагинов. Эта стратегия, вместе с внедрением многошаговых транзакций (MST), значительно сократила время интеграции новых PSP и стандартизировала сложные платежные потоки. Интеграция LPM представляла собой сложности из-за разнообразия API и необходимости взаимодействия с внешними приложениями. Airbnb проанализировала сквозное поведение и стандартизировала их в три основных потока: Redirect, Async и Direct. Этот унифицированный фреймворк позволил значительно повысить повторное использование кода и снизить инженерные усилия для интеграции новых методов оплаты. Асинхронная оркестрация платежей была переработана для управления внешними действиями пользователей и уведомлениями webhook при успешных платежах. Подход, основанный на конфигурации, с использованием центральной конфигурации YAML, упростил интеграцию платежных методов за счёт консолидации логики и обеспечения автоматизированной генерации кода. Это сделало интеграцию в основном декларативной, сокращая время запуска с месяцев до недель. Платёжный виджет динамически отображает пользовательский интерфейс и правила валидации на основе конфигураций бэкенда, обеспечивая индивидуальный опыт оформления заказа. Улучшенная тестируемость через внутренний эмулятор PSP позволила разработчикам тщательно тестировать сценарии оплаты без использования нестабильных внешних песочниц.

Создание реалистичных поддельных данных GraphQL было постоянной проблемой в отрасли. Airbnb разработала решение, используя новую директиву клиента GraphQL, @generateMock, для автоматизации этого процесса. Эта директива позволяет инженерам добавлять контекст и URL-адреса дизайна к своим GraphQL-операциям. Инструмент командной строки Niobe интегрирует эту директиву в рабочий процесс генерации кода. Niobe собирает детали запроса, контекст схемы и информацию о дизайне для создания подсказок для больших языковых моделей. Модель Gemini 2.5 Pro используется из-за ее большого контекстного окна и эффективной производительности. После генерации LLM поддельные данные проходят проверку на соответствие схеме GraphQL для обеспечения типобезопасности. Если проверка не удалась, ошибки передаются обратно в LLM для исправления, создавая механизм самовосстановления. Этот подход устраняет ручное создание подделок, экономя время и усилия инженеров. Сгенерированные подделки очень реалистичны, соответствуют дизайнерским макетам и улучшают возможности прототипирования и тестирования.

Хранилище "ключ-значение" Airbnb, Mussel, изначально использовало простое ограничение скорости QPS, чтобы предотвратить перегрузку системы отдельными клиентами. По мере роста трафика и его усложнения этот подход оказался недостаточным из-за разницы в стоимости и перекоса трафика. Для решения этой проблемы Mussel развился до реализации многоуровневой системы качества обслуживания (QoS). Первый уровень, Resource-Aware Rate Control (RARC), взимает плату за запросы в Request Units (RU), которые учитывают строки, байты и задержку, отражая фактическую стоимость бэкенда. Эта система использует токенные корзины со статическими квотами RU для каждого вызывающего абонента. Второй уровень, сброс нагрузки, обеспечивает защиту в реальном времени при перегрузке емкости или возникновении горячих точек. Он сочетает в себе критичность трафика, коэффициент задержки, указывающий на нагрузку на систему, и политику очереди, вдохновленную CoDel. Это позволяет высокоприоритетному трафику оставаться отзывчивым и плавно снижать нагрузку на другой трафик при увеличении задержки. Третий уровень, обнаружение горячих ключей и защита от DDoS, выявляет и смягчает всплески идентичных запросов, нацеленных на конкретные данные. Он использует счетчик top-k в памяти для обнаружения в реальном времени, локальное кэширование на модулях диспетчера и объединение запросов, чтобы отправлять только один запрос на уровень хранения для дублирующихся поисков горячих ключей. Эти многоуровневые элементы управления значительно улучшили способность Mussel справляться со скачками трафика и поддерживать надежность. Основные выводы включают ценность раннего воздействия для проверки концепций, предпочтение локальных контуров управления для масштабируемости и использование механизмов, работающих в разных временных масштабах. Этот сложный стек QoS гарантирует, что Mussel остается быстрым и надежным даже в экстремальных и нестабильных условиях трафика.

Airbnb переработала свой основной key-value store, Mussel, с V1 на V2, чтобы удовлетворить растущие потребности в обработке данных в реальном времени. Mussel V2 решает проблемы операционной сложности, ограничений по емкости и проблем согласованности V1 с помощью облачного NewSQL бэкенда. Ключевые улучшения включают автоматизированное развертывание Kubernetes, динамическое шардирование по диапазону для лучшего управления емкостью и гибкие параметры согласованности. Новая архитектура включает в себя stateless сервис Dispatcher для трансляции API-вызовов и событийно-ориентированный путь записи с использованием Kafka для обеспечения долговечности. Возможности пакетной загрузки сохранены и улучшены за счет stateless контроллеров и stateful рабочих групп для высокой пропускной способности. Автоматическое истечение срока действия (TTL) теперь топологически осведомлено и более эффективно в масштабе. Миграция с V1 на V2 использовала сложную стратегию blue/green с двойной записью и теневым чтением для обеспечения нулевого времени простоя и отсутствия потери данных. Важные извлеченные уроки включают управление сложностями согласованности и важность предварительного разделения для партиционирования на основе диапазонов. Kafka сыграла решающую роль в поддержании конечной согласованности в процессе миграции. Mussel V2 успешно объединяет пакетную загрузку, высокоскоростную запись и низколатентное чтение на одной платформе, упрощая инфраструктуру данных для инженерных команд.

Виадук, ориентированная на данные сервисная сетка Airbnb, теперь с открытым исходным кодом. За пять лет использование Viaduct в Airbnb значительно выросло: трафик увеличился в восемь раз, а количество команд удвоилось. Он по-прежнему руководствуется тремя основными принципами: центральной схемой, размещенной бизнес-логикой и повторной входимостью. Центральная схема интегрирует данные по всей компании, делая Viaduct предпочтительной сеткой данных. Размещение бизнес-логики непосредственно в Viaduct, обеспечиваемое бессерверной платформой, упрощает операции для разработчиков. Повторная входимость позволяет размещенной логике взаимодействовать с другой логикой через фрагменты и запросы GraphQL, сохраняя модульность. Недавний капитальный ремонт, "Viaduct Modern", устраняет прошлые сложности, упрощая ориентированный на разработчиков Tenant API до двух типов резольверов: резольверы узлов и полей. Эта модернизация также вводит модульность арендаторов, формализуя "модули арендаторов" как единицы схемы и кода, принадлежащие одной команде, составленные через GraphQL. Модульность фреймворка также была улучшена, создавая более сильные границы абстракции между механизмом выполнения GraphQL, API арендатора и размещенным кодом. Новый API движка динамически типизирован, в то время как API арендатора статически типизирован, что позволяет осуществлять независимую эволюцию. Viaduct предлагает постепенную миграцию, одновременно запуская Classic и Modern Tenant API на новом движке. Другие улучшения включают расширенную наблюдаемость, более быстрое время сборки благодаря разработке, ориентированной на схему, и генерации непосредственно в байт-код, а также диспетчер для масштабирования Kubernetes и смягчения радиуса поражения. Airbnb открывает исходный код Viaduct, чтобы извлечь выгоду из вклада сообщества, и считает, что он может быть ценным как для крупномасштабных, так и для зарождающихся проектов GraphQL. Modern API в настоящее время находится в альфа-версии, но новый движок находится в полной производственной эксплуатации.

Airbnb разработала Viaduct, ориентированную на данные сервисную сетку, для улучшения модульности в своей микросервисной архитектуре. Традиционные сервисные сетки ориентированы на процедуры, в то время как Viaduct фокусируется на данных, используя схему GraphQL в качестве центрального организующего принципа. Эта схема определяет типы, запросы и мутации, абстрагируя зависимости сервисов от потребителей. Viaduct позволяет потребителям данных получать доступ к информации из нескольких микросервисов без прямых зависимостей, упрощая архитектуру. Центральная схема облегчает изменения API и схемы баз данных, повышая гибкость данных и снижая усилия по координации. Viaduct интегрирует бессерверные функции для производных данных, минимизируя количество и сложность микросервисов. Система, построенная с использованием graphql-java, предлагает такие функции, как детальный выбор полей, наблюдаемость данных и внутризапросное кэширование. Она использует инструменты экосистемы GraphQL и обеспечивает значительную часть трафика API Airbnb. Viaduct решает проблемы, связанные со спагетти-подобными графами зависимостей, распространенными в больших сервисно-ориентированных архитектурах. Переход к подходу, ориентированному на данные, направлен на оптимизацию доступа к данным и улучшение общей ремонтопригодности системы. Архитектура началась с чистой схемы и выросла, включив в себя многочисленные основные сущности. Решение, уже развернутое в продакшене, иллюстрирует приверженность Airbnb к развитию своей SOA.

Airbnb перенесла свой огромный монорепозиторий JVM с Gradle на Bazel, процесс, занявший 4,5 года. Основными причинами перехода стали превосходная скорость, надежность и унифицированная инфраструктура сборки Bazel. Кеширование и удаленное выполнение Bazel значительно ускорили время сборки и тестирования, повысив производительность разработчиков. Миграция устранила проблемы с ненадежностью Gradle, связанные с негерметичными сборками и конкуренцией за ресурсы. Опытный образец с сервисом Viaduct от Airbnb продемонстрировал эффективность Bazel, что привело к его более широкому внедрению. Важным компонентом стал автоматический генератор файлов сборки для минимизации усилий разработчиков и поддержания сосуществования систем сборки. Этот генератор эффективно анализировал исходные файлы, управлял зависимостями и поддерживал графы сборки с высокой детализацией. Миграция также включала решение таких задач, как поддержка сторонних библиотек нескольких версий и обеспечение совместимости развертывания. Наконец, тщательное тестирование, особенно тесты запуска и интеграционные тесты для сервисов, подтвердило корректность развертываний, собранных Bazel. В результате была достигнута значительно улучшенная система сборки с повышенной удовлетворенностью разработчиков.

Airbnb успешно обновил свою сервисную сетку Istio 14 раз, управляя десятками тысяч подов в десятках кластеров Kubernetes и тысячами виртуальных машин. Их процесс обновления ставит во главу угла отсутствие простоев и постепенное развертывание, позволяя проводить независимые обновления без вмешательства пользователя. Архитектура включает управляющий кластер для Istiod и несколько рабочих кластеров. Обновления следуют канареечной модели, запуская текущие и новые версии Istio параллельно. Это достигается путем координации обновлений управляющего плоскости (Istiod) и плоскости данных (istio-proxy). Важно отметить, что более старые версии istio-proxy не используются с более новыми Istiod; они обновляются атомарно. Центральный файл управления, rollouts.yml, определяет желаемое распределение версий Istio по пространствам имен. Для Kubernetes внутренний инструмент под названием Krispr вводит метки ревизии Istio в развертывания во время CI и при приеме подов. Этот механизм гарантирует обновление рабочих нагрузок, даже если они не развертываются часто. Для виртуальных машин обновления управляются демоном на хосте, mxagent, который устанавливает артефакты на основе тегов ВМ. Центральный контроллер, mxrc, обновляет эти теги в соответствии с rollouts.yml. Mxrc также отслеживает состояние ВМ, обеспечивая контролируемый процесс обновления. Такой подход эффективно отделяет обновления инфраструктуры от развертывания приложений. Непрерывные инвестиции Airbnb в поддерживаемость и безопасность позволили провести эти сложные, крупномасштабные обновления Istio.

Традиционно организации использовали дорогие автономные серверы с шардированием для масштабирования баз данных, но этот подход оказался проблематичным для обслуживания по мере роста спроса на данные. Запуск горизонтально масштабируемых, открытых баз данных в облаке с высокой доступностью, низкой задержкой и масштабируемостью по разумной цене является значительной проблемой. Airbnb приняла инновационную стратегию развертывания распределенного кластера баз данных на нескольких кластерах Kubernetes для улучшения надежности и эксплуатации. Управление сервисами с сохранением состояния, такими как базы данных, в Kubernetes является сложным, особенно в отношении замены узлов и обновлений, поскольку Kubernetes не осведомлен о распределении данных. Чтобы смягчить это, Airbnb прикрепила тома хранилища к узлам с помощью AWS EBS, что позволяет автоматически прикреплять их к новым виртуальным машинам через заявки на постоянный объем Kubernetes. Были разработаны пользовательские операторы Kubernetes для управления событиями замены узлов, которые категоризированы на инициированные базой данных, плановую инфраструктуру и неплановые сбои. Для инициированных базой данных и плановых событий операторы гарантируют, что все узлы запущены до замены и перехватывают исключения подов, чтобы координировать безопасные удаления. Неплановые сбои не могут быть скоординированы, но текущее обслуживание защищено блокировкой замен до тех пор, пока неисправное оборудование не будет исправлено. Чтобы обеспечить высокую региональную доступность, Airbnb развертывает каждую базу данных на трех независимых кластерах Kubernetes в разных зонах доступности AWS, ограничивая радиус действия проблем. Перераспределение кластеров баз данных гарантирует достаточную емкость даже в случае, если весь AZ, кластер Kubernetes или все узлы хранилища в зоне выйдут из строя. AWS EBS обеспечивает быстрое прикрепление для замены узлов и превосходную долговечность, позволяя создать высокодоступный кластер с только тремя репликами. Пиковые задержки в EBS смягчаются путем реализации таймаутов чтения хранилища и разрешения чтения из реплик для снижения задержки и избежания затрат на межзонный доступ, а устаревшие чтения еще больше оптимизируют производительность чтения. Эта много-кластерная стратегия Kubernetes, использующая AWS EBS и пользовательских операторов, позволяет открытым распределенным системам хранения достичь высокой доступности, низкой задержки и масштабируемости в облачных средах, обеспечивая надежное управление данными.

Airbnb принял SwiftUI в 2022 году, что улучшило производительность инженеров, но ввело новые проблемы с производительностью. Чтобы решить эти проблемы, Airbnb создал новые инструменты для выявления и проверки критических для производительности шаблонов кода. Архитектура функций компании использует декларативные шаблоны интерфейса пользователя и односторонние системы потока данных, что упростило принятие SwiftUI. Однако функции SwiftUI, использующие эту архитектуру, не показали ожидаемой производительности, и понимание характеристик производительности SwiftUI имеет решающее значение для создания функций с высокой производительностью. Алгоритм диффинга представлений SwiftUI, который определяет, когда тело представления необходимо переоценить, часто упускается из виду и не документируется официально. Алгоритм сравнивает каждое из сохраненных свойств представления, но общие шаблоны кода могут запутать его, что приводит к ненужным оценкам тела представления. Чтобы решить эту проблему, Airbnb создал новый макрос @Equatable, который генерирует соответствия Equatable для представлений, позволяя инженерам выбирать, какие свойства следует сравнивать при диффинге. Этот подход гарантирует, что представления могут быть диффед, и предотвращает появление регрессий позже. Кроме того, Airbnb реализовал пользовательское правило SwiftLint, чтобы помочь инженерам определить, когда тело представления слишком сложное и требует переработки в более мелкие, диффабельные части. Разбивая представления на более мелкие части, SwiftUI может эффективно обновлять только те части представления, которые фактически изменились, сохраняя производительность при росте сложности функций.

Нагрузочное тестирование на уровне системы имеет решающее значение для обеспечения надежности и эффективности Airbnb, позволяя выявлять узкие места, оценивать пропускную способность, устанавливать базовые показатели производительности и обнаруживать ошибки. Impulse – это внутренняя платформа для нагрузочного тестирования как сервиса, которая предоставляет инструменты для генерации синтетической нагрузки, имитации зависимостей и сбора данных о трафике из производственной среды. Impulse включает в себя четыре основных компонента: генератор нагрузки, сборщик трафика, имитатор зависимостей и генератор API для тестирования. Генератор нагрузки позволяет владельцам сервисов проводить контекстно-зависимое нагрузочное тестирование, генерируя запросы "на лету" и имитируя зависимости. Сборщик трафика захватывает как входящий, так и исходящий трафик, позволяя Impulse точно воспроизводить производственный трафик во время нагрузочного тестирования. Имитатор зависимостей имитирует ответы зависимостей с заданным временем задержки, устраняя влияние между сервисами и снижая затраты на коммуникацию. Генератор API для тестирования создает HTTP API на этапе CI (непрерывной интеграции), позволяя инструментам нагрузочного тестирования отправлять трафик на эти синтетические API, что позволяет отрабатывать асинхронные потоки так, как если бы они были синхронными. Impulse разработан для минимизации ручного труда, бесшовной интеграции со стеком наблюдаемости Airbnb и предоставления командам возможности проактивно решать потенциальные проблемы. Платформа получила положительные отзывы, помогая командам выявлять и устранять потенциальные проблемы в их сервисах. Impulse в настоящее время внедряется в нескольких серверных службах поддержки клиентов и находится на рассмотрении у команд по всей компании.

Компания Airbnb усовершенствовала свою систему интерактивного голосового ответа (IVR), используя машинное обучение для лучшего понимания пользователей и более эффективной помощи агентам. Система IVR слушает, понимает и отвечает в режиме реального времени, позволяя звонящим описывать свои проблемы естественным образом и получать мгновенную поддержку. Система использует автоматическое распознавание речи, определение причины обращения и языковые модели для понимания пользователей и помощи агентам. Система автоматического распознавания речи была улучшена для снижения ошибок, а также разработана модель определения причины обращения для выявления намерения запроса звонящего. Система извлечения справочных статей предоставляет пользователям релевантную информацию, а модель перефразирования гарантирует, что пользователи понимают решение, прежде чем их перенаправят к агенту. Система улучшила удовлетворенность пользователей, снизила необходимость вмешательства человека и обеспечила более интуитивно понятный опыт голосовой поддержки.

Airbnb использует систему для определения ценности объявлений для гостей, рассчитывая пожизненную ценность объявления (LTV). Эта система включает в себя базовую, дополнительную и стимулированную маркетингом дополнительную LTV. Базовая LTV оценивает общее количество бронирований за 365 дней, используя машинное обучение и данные объявлений. Дополнительная LTV решает проблему каннибализации, оценивая ценность, добавленную каждым объявлением. Стимулированная маркетингом дополнительная LTV измеряет влияние инициатив Airbnb на ценность объявлений. Точное измерение базовой LTV имеет решающее значение, требуя обучения и оценки модели с течением времени. Учет дополнительности включает в себя оценку производственной функции для связывания предложения и спроса с бронированиями. Обработка неопределенности, особенно во время пандемии, включала в себя обновление оценок LTV с учетом фактических бронирований. Эта система LTV помогает Airbnb выявлять ценные объявления, формировать стратегии предложения и оценивать внутренние инициативы. Этот подход также может быть расширен на другие области, такие как Airbnb Experiences. Постоянное развитие системы направлено на улучшение опыта как для хозяев, так и для гостей.

Функция поиска Airbnb играет ключевую роль в помощи гостям найти идеальное жилье, но это сложная задача из-за большого количества доступных домов и сложных запросов поиска. Для решения этой задачи Airbnb создала систему поиска на основе встроенных представлений (EBR), чтобы сузить начальную группу подходящих домов до меньшего пула. Система EBR состоит из трех ключевых компонентов: создания обучающих данных, проектирования архитектуры модели и разработки стратегии онлайн-обслуживания. Pipeline обучающих данных использует контрастное обучение для отображения домов и запросов поиска в числовые вектора. Архитектура модели следует традиционному двухбашенному дизайну, где одна башня обрабатывает функции списка домов, а другая - функции, связанные с запросом поиска. Башня списка домов вычисляется офлайн ежедневно, что уменьшает онлайн-задержку. Для онлайн-обслуживания Airbnb исследовала приближенные решения ближайших соседей (ANN) и выбрала индексированный файловый индекс (IVF) из-за его лучшего баланса между скоростью и производительностью. Решение IVF группирует списки домов заранее и извлекает дома из верхних кластеров, рассматривая назначения кластеров как стандартный фильтр поиска. Система EBR привела к статистически значимому увеличению общего количества бронирований при тестировании A/B, эффективно учитывая контекст запроса и ранжирование домов более точно при извлечении. Система была полностью запущена в производстве поиска и электронной маркетинговой рассылки.

"Airbnb использовала подход, основанный на языковой модели (LLM), для миграции почти 3,5 тыс. файлов тестов компонентов React из Enzyme в React Testing Library (RTL). Изначально они оценили, что это займет 1,5 года, но завершили задачу всего за шесть недель. Миграция включала в себя рефакторинг файлов тестов, сохраняя намерение оригинальных тестов и покрытие кода. Они создали автоматизированный конвейер с валидацией, шагами рефакторинга и петлями повторных попыток. LLM получала все больше контекста, включая код компонента и связанные тесты, для улучшения успеха. Они использовали подход "выборка, настройка и обзор" для улучшения подсказок и сценариев, увеличивая завершенность с 75% до 97%. Автоматизация эффективно обработала подавляющее большинство миграции, оставив небольшой процент для ручных исправлений. Проект сохранил намерение тестов и покрытие кода и оказался намного быстрее и дешевле, чем ручная миграция. Этот опыт подчеркивает мощь LLM для крупномасштабных преобразований кода. Airbnb планирует расширить использование LLM для продуктивности разработчиков. Они также нанимают инженеров, которые любят решать сложные проблемы в масштабе."

Airbnb адаптировал свой алгоритм ранжирования для интерфейса карты, чтобы лучше соединить гостей с хозяевами. Первоначально алгоритм ранжирования основывался на вероятности бронирования, но этот подход не работает для карт, где внимание пользователя распределено равномерно между метками. Чтобы улучшить пользовательский опыт, Airbnb протестировал различные модели внимания пользователя, включая ограничение количества меток на карте и создание двух уровней меток на основе вероятности бронирования. Эти изменения привели к значительному улучшению бронирований и удовлетворенности пользователей. Компания также разработала алгоритм для повторного центрирования карты, чтобы отобразить объявления с самой высокой вероятностью бронирования, что еще больше улучшило бронирования и уменьшило количество перемещений карты. Несмотря на эти достижения, все еще существует проблема в представлении полного диапазона доступных объявлений на карте, которая является предметом будущей работы.

Airbnb имел значительное присутствие на конференции KDD 2024 в Барселоне, Испания, с тремя полными статьями ADS-трека, одним семинаром и семью статьями и приглашенными докладами, принятыми в основные конференционные материалы. Тематики работ охватывали глубокое обучение и ранжирование поиска, онлайн-экспериментирование и измерение, а также двухсторонние рынки. Вклад Airbnb в семинар по оптимизации двухсторонних рынков обсуждал эволюцию ранжирования контента, системы рекомендаций и добычи данных для решения задач производителей и потребителей на этих платформах. Работа Airbnb по моделированию намерений гостей для персонализации использует подход глубокого обучения для предсказания планов путешествия и производит несколько сигналов намерений пользователей. Компания также представила статью о понимании спроса гостей, сочетая экономическое моделирование с техниками причинно-следственного вывода для оценки чувствительности к цене среди сегментов гостей.

Виджая Каза - это главный офицер по безопасности и руководитель инженерного отдела по доверию и безопасности в Airbnb, руководя командами, разрабатывающими технологии для защиты сообщества и обеспечения безопасности инфраструктуры. Она также является исполнительным сопредседателем Совета по разнообразию Airbnb Tech. Виджая выросла в большой семье в Индии, где от нее ожидали высоких достижений в учебе, и она развила сильную привязанность к науке и математике, изучая электротехнику в колледже. После колледжа она получила работу в Cisco в качестве инженера-программиста и случайно попала в поле безопасности, последовав за менеджером, который ей понравился. Она провела 17 лет в Cisco, руководя разработкой продуктов для портфеля безопасности стоимостью 1 миллиард долларов, и позже работала в FireEye и Lookout, стартапе в Сан-Франциско, специализирующимся в мобильной безопасности. Виджая была приглашена на должность CSO в Airbnb, на которую она была поначалу неохотна, но была впечатлена видением и миссией компании. Она присоединилась к Airbnb в 2019 году, привлеченная компанией к ее посвящению обеспечению положительного опыта пользователей и миссионерскому подходу. Виджая руководит двумя командами, Trust and Safety и Security, которые разделяют общую миссию по защите пользователей и платформы, но имеют разные техники, угрозы и области внимания. Вне работы Виджая занимается импровизационным комедийным искусством, которое научило ее важным урокам лидерства, таким как быстрое мышление и реагирование на новые ситуации в моменте. Она советует другим сохранять фокус, держать голову высоко и не отступать перед профессиональными неудачами.

Airbnb использует сегментацию на основе данных, чтобы понять модели доступности своих хозяев. Этот процесс включает в себя анализ коэффициента доступности, последовательности и сезонности листингов, чтобы отличать хозяев с похожими профилями. Применяя алгоритм кластеризации K-means, Airbnb идентифицирует восемь различных кластеров хозяев на основе их моделей доступности. Эти кластеры включают «Всегда доступен», «Короткая сезонность», «Мотивированный событиями» и другие, каждый с уникальными характеристиками и предпочтениями. Компания проверяет эти сегменты с помощью тестирования A/B, коррелирует их с известными атрибутами и проводит исследования пользовательского опыта, чтобы убедиться, что они соответствуют реальному поведению. Затем эта модель сегментации масштабируется до всех листингов с помощью алгоритма дерева решений и интегрируется в хранилище данных для использования различными командами. Этот подход помогает Airbnb разработать целевые стратегии, продукты и сообщения, чтобы лучше поддерживать своих хозяев и улучшить общий пользовательский опыт.

Airbnb разработала платформу потоковой обработки данных под названием Платформа сигналов пользователей (USP), чтобы улучшить пользовательский опыт через персонализацию. Платформа использует данные об взаимодействии пользователей, чтобы обеспечить индивидуализированные взаимодействия во время процесса бронирования. Она состоит из слоя трубопровода данных и слоя онлайн-обслуживания, с использованием потоковой обработки Flink для gầnко-временной обработки и пакетной обработки для коррекции данных и заполнения пробелов. USP поддерживает различные типы обработки событий пользователей, включая сигналы пользователей, сегменты пользователей и сеансы взаимодействия. Она также использует метрики, такие как задержка события, задержка инжекции, задержка задания и задержка преобразования, чтобы измерять производительность заданий потоковой обработки. Платформа позволяет разработчикам определять преобразования и сегменты пользователей, не беспокоясь о компонентах потоковой обработки. Чтобы улучшить стабильность заданий Flink, Airbnb использует резервные менеджеры задач, чтобы обеспечить непрерывную обработку в случае сбоя менеджера задач.

Airbnb разработала функцию фото-тура, основанную на ИИ, чтобы улучшить опыт гостей, предоставляя подробную информацию о списках. Эта функция использует трансформеры зрения для классификации и организации фото из списков в 16 разных типов комнат. Чтобы улучшить точность модели, Airbnb использовала предварительную подготовку, многозадачное обучение, обучение ансамбля и дистилляцию знаний. Процесс предварительной подготовки включал обучение модели Vision Transformer на миллионах фото из списков Airbnb. Многозадачное обучение использовало разнообразный набор данных, чтобы улучшить способность модели интерпретировать визуальную информацию. Обучение ансамбля объединило сильные стороны нескольких моделей для надежных прогнозов, а дистилляция знаний позволила развернуть модель эффективно, не жертвуя точностью. Фото-тур, основанный на ИИ, был запущен в рамках зимнего релиза Airbnb 2023 года, и компания продолжает совершенствовать модели для лучшего опыта пользователей.

Airbnb недавно принял Bazel, открытый исходный код инструмента сборки Google, в качестве своей универсальной системы сборки на платформах backend, web и iOS. Большой веб-монорепозиторий компании, состоящий из более чем 11 миллионов строк кода, представлял проблемы с настраиваемыми скриптами сборки и логикой кэширования, которые были трудны в поддержке и плохо масштабировались. Чтобы решить эти проблемы, Airbnb перешла на Bazel, который предлагал сложность, параллелизм, кэширование и производительность. Процесс миграции начался в 2021 году, но не было известных в отрасли примеров интеграции Bazel с веб-приложениями в крупном масштабе за пределами Google. Команда должна была преодолеть проблемы с производительностью при передаче больших файлов в удаленную среду и установила принципы миграции, которые включали улучшение или поддержание общей производительности и снижение влияния на разработчиков, вносящих вклад в монорепозиторий во время перехода. Чтобы подготовить репозиторий к Bazel, команда выполнила разрыв циклов и автоматизированную генерацию файла BUILD.bazel. Они также перенесли задания CI в Bazel, начиная с проверки типов, линтинга и тестирования модулей. Команда включила TypeScript, ESLint и Jest и ввела кэширование для уменьшения размера входных данных и улучшения производительности. Чтобы предотвратить регрессию, команда переместила тесты из "скрытых" в "обязательные" через атрибут правила и обеспечила единственный источник истины, не запуская тесты под настройкой Jest, которая заменяется. Они также написали скрипт для сравнения до и после Bazel, чтобы определить готовность к миграции с помощью метрик, таких как время выполнения тестов, статистика покрытия кода и частота сбоев. В параллель с миграцией CI команда обеспечила, чтобы разработчики могли запускать Bazel локально, чтобы воспроизвести и итерировать ошибки CI. Они предоставили локальный опыт Bazel, который равен или превосходит существующий опыт разработчика и производительность, позволяя разработчикам продолжать использовать знакомые инструменты и выбирать Bazel, когда это полезно.

Airbnb изменил способ путешествий людей по всему миру, но предоставление гостям соответствующих вариантов в результатах поиска стало все более сложным из-за разнообразных мест и типов недвижимости в их инвентаре. Чтобы решить эту проблему, Airbnb перешел от использования простых эвристик к продвинутым методам машинного обучения и обучения с подкреплением для преобразования процесса поиска местоположений. Первоначально Airbnb полагался на эвристику для определения картографических областей в зависимости от типа поиска, но эти эвристики имели ограничения и не могли различать различные типы поисков или адаптироваться к новым данным. Затем Airbnb исследовал статистику для улучшения поиска местоположений, создавая набор данных для каждого пункта назначения путешествия, в котором записывались места бронирования гостей при поиске этого пункта назначения. Однако этот статистический подход все еще имел ограничения и рассматривал все поиски местоположения одинаково, независимо от конкретных параметров поиска. Это привело Airbnb к мысли, что поиск местоположения может потребовать более продвинутых методов, таких как машинное обучение. Airbnb построил модель машинного обучения, которая могла учиться на различных параметрах поиска, таких как количество гостей и продолжительность пребывания, и предсказывать более соответствующие картографические области для каждого поиска. Система машинного обучения увеличила количество бронирований на 7,12% и уменьшила размер области поиска карты на 40,83%, что привело к кумулятивному увеличению на 1,8% в неотмененных бронированиях на платформе. Затем Airbnb ввел обучение с подкреплением в процесс поиска местоположения, позволяя системе непрерывно учиться на взаимодействиях гостей и корректировать область поиска карты на основе поведения бронирования гостей. Система обучения с подкреплением успешно исследовала больше для менее посещаемых мест и исследовала меньше для мест, которые часто ищут и бронировать, что привело к кумулятивному увеличению на 0,51% в неотмененных бронированиях и на 0,71% в рейтинге 5-звездных поездок. Путешествие Airbnb от простых эвристик к сложным моделям машинного обучения и обучения с подкреплением демонстрирует силу данных-ориентированных подходов в преобразовании сложных систем. Преобразование приводит к кумулятивному увеличению на 2,66% в неотмененных бронированиях, значительному достижению для компании, работающей в масштабе Airbnb.

Платформа автоматизации Airbnb v2 - это платформа разговорного ИИ, предназначенная для поддержки развивающихся приложений больших языковых моделей (LLM). Платформа позволяет разработчикам создавать приложения LLM, которые повышают эффективность и время отклика поддержки клиентов. Она включает в себя несколько ключевых компонентов, таких как workflow Chain of Thought, управление контекстом и guardrails framework. Workflow Chain of Thought использует LLM в качестве двигателей рассуждений для определения того, какие инструменты использовать и в каком порядке. Управление контекстом обеспечивает доступ LLM к необходимой контекстной информации, а guardrails framework контролирует коммуникации с LLM, чтобы обеспечить ее полезность, актуальность и этичность. Платформа развивается для адаптации к трансформационным технологиям, расширения возможностей инструментов Chain of Thought и исследования симуляции приложений LLM.

Airbnb разработала платформу под названием Sandcastle, чтобы помочь специалистам по обработке данных и специалистам по машинному обучению воплотить в жизнь свои идеи по разработке продуктов, основанных на данных и искусственном интеллекте, интерактивным образом. Sandcastle интегрируется с Onebrain, фреймворком для упаковки кода машинного обучения и прототипирования, а также с kube-gen, слоем генерации кода поверх Kubernetes. Эта платформа позволяет разработчикам создавать и делиться интерактивными веб-приложениями в течение 10-15 минут после проверки их кода. За последний год было разработано более 175 живых прототипов, 6 из которых использовались для задач с высоким уровнем воздействия. Эти прототипы посетили более 3,5 тыс. уникальных внутренних пользователей в течение более чем 69 тыс. отдельных активных дней.

Riverbed, часть технологического стека Airbnb, оптимизирует потребление данных из систем хранения записей для обновления оптимизированных для чтения хранилищ. Он использует архитектуру Lambda с компонентами потоковой и пакетной обработки. Потоковый аспект фокусируется на построении материализованных представлений из событий захвата изменений (CDC). Pipeline уведомлений потребляет события уведомлений и запрашивает зависимые источники данных для построения материализованных представлений, которые затем записываются в хранилища-приемники. Операция Join использует структуру, подобную DAG, для эффективного объединения источников данных, используя JoinConditionsDag для метаданных и JoinResultsDag для хранения результатов. Операция Stitch преобразует объединенные результаты в используемую модель, StitchModel. Riverbed поддерживает несколько приемников, включая Apache Hive и Kafka, для гибкости. Система потоковой передачи эффективно обновляет материализованные представления из событий CDC, обеспечивая масштабируемость, эффективное получение данных и улучшенные возможности фильтрации и поиска. Pipeline источника, обсуждаемый в следующем посте блога, играет решающую роль в параллельности и версионировании. Используя DAG-структуры данных, Riverbed оптимизирует соединения потоковых данных, сокращая использование памяти и повышая эффективность.

Команда по работе со СМИ Airbnb разработала систему создания открыток для бронирования групповых поездок, используя новаторский алгоритм сопоставления направлений. Система требовала локализованного текстового макета, гибкости дизайна и высокой производительности. Чтобы решить проблему локализованного текстового макета, был найден компромисс в ручном форматировании переводов для наиболее популярных направлений бронирования. Гибкая модель данных шаблона позволяла легко настраивать позиционирование текста и цвет. Чтобы улучшить производительность, была реализована асинхронная потоковая передача создания открыток, минимизирующая задержку и используя существующую инфраструктуру обслуживания медиа. Был разработан алгоритм сопоставления, чтобы сопоставить открытки с направлениями на основе уникального художественного оформления, популярных направлений, тегов таксономии и стандартного резервного варианта. Предварительное создание открыток для наиболее популярных направлений минимизировало использование стандартных открыток. Решение подчеркивает необходимость внутренних инструментов, возможностей обработки изображений и текста, а также логики сопоставления направлений. Открытки были хорошо восприняты и демонстрируют мощь возможностей медиа в улучшении группового туристического опыта Airbnb.

Система классификации данных Airbnb позволяет идентифицировать и защищать персональные данные, обеспечивая доверие и соответствие. Система состоит из трех столпов: каталогизации для поиска данных, обнаружения для идентификации персональных данных и согласования для подтверждения классификаций. Автоматическое обнаружение использует метаданные, контент и машинное обучение для классификации персональных данных. Вход человека подтверждает классификации, чтобы минимизировать ложные положительные результаты и облегчить разрешение. Метрики качества оценивают полноту, точность и скорость, чтобы обеспечить эффективность. Среди вызовов - постобработка классификации, неоднородные классификации и затраты на процесс. Airbnb выступает за "сдвиг влево", интегрируя классификацию данных в схемы данных на этапе создания, чтобы преодолевать эти вызовы. Этот подход позволяет владельцам данных управлять и аннотировать свои данные, используя информацию о происхождении для автоматической аннотации и уменьшения ручного труда. Система классификации данных Airbnb предоставляет всестороннюю рамку для организаций, сталкивающихся с аналогичными проблемами, поощряя защиту данных и соответствие.

Архитектура потоковой обработки Airbnb эволюционировала от Hadoop Yarn до Kubernetes, с заменой Spark Streaming на Flink в качестве основной платформы. Переход включал удаление Airflow в качестве планировщика задач и введение легковесного планировщика потоковых задач. Переход к Kubernetes обеспечил улучшенный опыт разработчика, улучшенный мониторинг и упрощение обнаружения сервисов. В текущей архитектуре есть пять основных компонентов: конфигурации задач, управление образом, CI/CD, портал Flink и runtime задач Flink. Преимущества архитектуры на основе Kubernetes включают более высокую скорость разработки, улучшение доступности и задержки задач, а также экономию средств. В будущем планируется улучшение доступности задач, включение автоматического масштабирования задач и изучение Flink Kubernetes Operator.

Фронтенд Airbnb обновился до React 18 с помощью системы обновления React, которая позволяет проводить инкрементальные и тестируемые обновления без необходимости в долгосрочном ветвлении функций. Модульное псевдонимирование и целевое окружение разделяют версии React на отдельные артефакты сборки и runtime-окружения. Различия в TypeScript были обработаны с помощью шимов, увеличения типов и прогрессивного исправления ошибок TypeScript. Комprehensive тестирование включало визуальную регрессию, интеграционное и юнит-тестирование, с юнит-тестами, запущенными как в React 16, так и в React 18. Прогрессивный ролл-аут контролировал трафик к обеим окружениям React 16 и 18, позволяя проводить внутреннее тестирование и постепенные обновления интерфейса. Система позволила тестировать предварительные версии React 19 canary без указания на React 18. Были зафиксированы улучшения производительности после принятия функций React 18, таких как новые корневые API и конкурентное рендеринг. Система поощряет непрерывные усилия по обновлению, избегая крупных, разовых изменений. Сосредоточение команды React на обратной совместимости облегчило такой подход к обновлению. Фронтенд Airbnb сейчас работает на React 19 beta, обеспечивая преимущество в будущих обновлениях React.

Усилия Airbnb по улучшению доступности веб-страниц были направлены на то, чтобы обеспечить читаемость текста при увеличении его размера на 200% (Увеличение текста). Увеличение масштаба в браузере, хотя и эффективное на настольных компьютерах, оказалось сложным на мобильных устройствах из-за ограниченного просмотра. Airbnb выбрала масштабирование шрифта, которое изменяет размер текста независимо от общего масштаба страницы. Чтобы поддержать масштабирование шрифта, Airbnb выбрала единицы rem, которые масштабируются пропорционально размеру шрифта на основе корневого элемента. Этот подход обеспечил последовательное масштабирование текста без влияния на другие элементы макета. Чтобы упростить переход на единицы rem, Airbnb автоматизировала процесс преобразования и предоставила инструменты дизайнерам для имитации масштабирования шрифта на этапе проектирования. Управление преобразованием в двух системах CSS-in-JS, React-with-Styles и Linaria, представляло дополнительные проблемы. Airbnb использовала поддержку пользовательских свойств Linaria и плагины post-CSS для преобразования большинства свойств, связанных с шрифтами. Была предоставлена возможность использовать единицы px, когда это необходимо. Реализация этих улучшений доступности значительно сократила количество сообщений об ошибках для функции "Увеличение текста" и улучшила пользовательский опыт для людей с нарушениями зрения. Отдавая приоритет потребностям пользователей и принимая лучшие практики, Airbnb продемонстрировала свою приверженность инклюзивному веб-дизайну.