Миссия Booking.com — сделать так, чтобы каждый мог познавать мир. Чтобы помочь людям находить направления, мы являемся ведущим рекламодателем путешествий в Google Pay Per Click (PPC). В целом Booking Holdings потратила 4,7 миллиарда долларов на маркетинг всех брендов за первые девять месяцев 2022 года[1]. Как мы можем запустить контекстную рекламу в нашем масштабе и эффективно? В этой статье мы хотим проиллюстрировать наше широкое использование общедоступного облака, в частности Google Cloud Platform (GCP). От приема данных, анализа данных до наших ставок на рекламу[2], GCP является ускорителем в нашем цикле разработки, иногда сокращая время выхода на рынок с месяцев до недель.

Каковы проблемы контекстной рекламы?

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

Прием данных и аналитика в масштабе

Получение данных о производительности, независимо от того, генерируется ли оно поисковым провайдером или внутренне, является ключевым входом для наших алгоритмов. Мы широко используем Google BigQuery в PPC из-за масштаба нашего бизнеса (до 2 миллионов бронируемых ночей в день). Наша команда в совокупности выполняет более 1 миллиона запросов в месяц, сканируя более 2 ПБ данных. BigQuery экономит нам значительное время — вместо того, чтобы часами ждать в Hive/Hadoop, наше среднее время выполнения запроса составляет 20 секунд для пакетных запросов и 2 секунды для интерактивных запросов[3].

BigQuery также предлагает встроенную поддержку вложенных и повторяющихся схем данных[4][5]. Мы используем эту функцию в наших системах ставок на рекламу, поддерживая согласованные представления данных из электронных таблиц наших специалистов по учетным записям, записных книжек наших специалистов по данным и данных в памяти нашей системы ставок. Эта функция устраняет необходимость в коде для анализа данных, снижает нашу техническую задолженность и сокращает время разработки.

Единое представление операционных данных

Мы хранили большую часть наших операционных данных в реляционных базах данных, таких как MySQL. По мере нашего развития нам все чаще требовалось объединять эти данные с аналитическими данными в одном едином представлении. Теперь мы используем Spanner[6][7], глобально распределенную базу данных SQL, потому что она имеет ряд уникальных функций, которые хорошо подходят для нашего варианта использования:

1. Spanner и BigQuery принудительно умножают друг друга с помощью федеративных запросов: мы храним быстро меняющиеся реляционные данные в Spanner и записываем ориентированные на добавление аналитические данные в BigQuery. Когда наши запросы охватывают оба набора данных, федеративные запросы немедленно извлекают в реальном времени согласованные со снимками данные из обоих хранилищ. Нам не нужно перемещать данные или тратить циклы разработки на настройку (и обслуживание) конвейеров данных[8][9][10].
2. Spanner обладает мощными возможностями эволюции схемы: для больших таблиц с меняющимися рекламными данными Spanner может сократить время изменения схемы до минут или секунд по сравнению с днями в более распространенном решении реляционной базы данных.
3. Чередующиеся таблицы позволяют нам хранить данные Ads API отдельно от наших внутренних данных без снижения производительности. Для структурированных и иерархических данных эта функция позволяет размещать связанные данные близко друг к другу, максимально увеличивая пространственную локальность.

Данные, доставленные качественно в нужный момент, лежат в основе производительности нашей системы. Для рабочих процессов, охватывающих несколько систем данных, мы предпочитаем использовать Google Dataflow, управляемую гибридную среду пакетной/потоковой обработки с встроенной интеграцией с BigQuery и Spanner.

В этом подходе мы видим два основных преимущества:

1. Dataflow реализует Beam — API, который эффективно абстрагирует обработку больших данных от деталей реализации платформы среды выполнения: он позволяет нам сосредоточиться на решении бизнес-логики и параллелизма данных, ускоряя итерацию разработки.
2. Он работает как управляемая служба с минимальным обслуживанием.

Развитие нашей инфраструктуры

Оптимизация работы GCP сопряжена с уникальным набором задач. В нашем масштабе небольшие затраты складываются, и это требует от нас глубокого обдумывания аспекта затрат на инфраструктуру на раннем этапе, во время проектирования, что было в такой же степени культурным изменением, как и изменением процесса. Например, в одной из наших первых агрегаций BigQuery у нас был большой запрос, который соединял статистические данные с метаданными, а затем агрегировал их. Из-за большого соединения и использования CURRENT_DATE() в качестве динамической функции наивная реализация BigQuery стоила бы 1 доллар за выполнение, а в течение дня — 1500 долларов. Стремясь снизить стоимость и повысить производительность, мы использовали BigQuery для агрегации, сохранили метаданные в MySQL и объединили две таблицы в памяти приложения. Такой подход позволил нам кэшировать результаты BigQuery с наличием динамических функций[11][12][13].

Дальнейшее развитие

В PPC мы добились огромного успеха, создавая наши системы в общедоступном облаке, в частности GCP. BigQuery, Dataflow и Spanner ускорили наши циклы разработки, сократили время выхода на рынок и доказали свою ценность для бизнеса. Мы хотели бы поблагодарить замечательную команду Google за их сотрудничество и партнерство с нами. У нас в Booking.com есть сложные, сложные проблемы, которые нужно решать. У нас невероятно талантливая и трудолюбивая команда PPC, и мы используем инновационные технологии, чтобы помочь людям открывать для себя путешествия интересным и творческим способом. Если вас это волнует, рассмотрите возможность сотрудничества с нами — подайте заявку на jobs.booking.com !

Особая благодарность Барису Гулю, Игорю Дралюку, Сергею Довгалю ( sdovgal ), Мустафе Эльбадри , Мартину Хенсеме и всей команде PPC Booking.com за помощь в написании этой статьи.

Сноски:

[1] Бронирование 3 кв. 2022 г. 10 кв.:https://s201.q4cdn.com/865305287/files/doc_financials/2022/q3/9fdc627b-3967-4970-aae0-b9581971f96d.pdf
[2] (Внутренний документ) Ретроспектива проектов PPC GCP
[3] (Внутренний документ) Резюме PPC BigQuery
[4] Описание Protobuf в Dremel:https://research.google/pubs/pub36632/ [5] Dremel: Десятилетие интерактивного анализа SQL в веб-масштабе:https://research.google/pubs/pub49489/
[6] Spanner: Глобально распределенная база данных Google:https://research.google/pubs/pub39966/
[7] Spanner: Становление системой SQLhttps://research.google/pubs/pub46103/
[8] Запрос F1:https://research.google/pubs/pub47224/ [9] F1 Молния HTAP:http://www.vldb.org/pvldb/vol13/p3313-yang.pdf
[10] F1: Распределенная база данных SQL, которая масштабируется:https://research.google/pubs/pub41344/
[11] Кэширование результатов BQ:https://cloud.google.com/bigquery/docs/cached-results
[12] (Внутренний документ) Контроль затрат BigQuery в PPC: BigQuery Cost Control
[13] (Внутренний документ) PPC — перенос агрегаций из onprem в BigQuery