задний план

Интернет-реклама - это обычный метод монетизации бизнеса в интернет-индустрии. С инженерной точки зрения, структура и внедрение индекса рекламы напрямую определяют производительность службы всей системы. Эта статья основана на поисковой рекламной системе Meituan Dianping и обсуждает инженерные загадки рекламной системы с читателями.

Проблемные области

Индекс объявления должен иметь следующие основные характеристики:

1. Иерархическая структура индекса
2. Обновление индекса в реальном времени

Иерархическая модель доставки

Как правило, рекламная система может быть абстрагирована в следующую модель доставки и реализует логику обработки, такую ​​как поиск и фильтрация.

Между верхним и нижним уровнями иерархии существует отношение «один ко многим». Рекламодатель обычно создает несколько планов продвижения, и каждому плану соответствует долгосрочный KPI, такой как месячный бюджет и зона доставки. Несколько единиц продвижения в плане продвижения используются для более точного контроля доставки, например максимальной ставки за клик, дневного бюджета, условий таргетинга и т. д. Рекламный креатив — это материал, используемый для рекламного воздействия, который в зависимости от особенностей бизнеса может быть подчинен уровню рекламодателя или плана продвижения.

Механизм обновления в реальном времени

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

Отраслевые исследования

В настоящее время большинство выпускаемых систем индексации с открытым исходным кодом предназначены для поисковых систем общего назначения, которые в принципе не могут одновременно удовлетворять вышеперечисленным условиям.

• Apache Lucene
• Полнотекстовый поиск, поддержка динамических скриптов, реализовано в виде библиотеки
• Живая индексация поддерживается, но иерархии не поддерживаются
• Sphinx
• Полнотекстовый поиск; реализован как полный бинарник, вторичная разработка затруднена
• Живая индексация поддерживается, но иерархии не поддерживаются

Таким образом, рекламная индустрия либо индивидуальные решения на основе открытого исходного кода, либо с нуля разрабатывать свои собственные системы с закрытым исходным кодом. После долгих размышлений о соотношении затрат и выгод мы решили разработать собственную систему индексации рекламы.

дизайн индекса

Инженерная практика ориентируется на такие показатели, как стабильность, масштабируемость и высокая производительность.

Разложение дизайна

Этап проектирования можно разбить на следующие подтребования.

индекс в реальном времени

Обновить Stream Рекламная сцена, включающая поля индекса свойств и различных обновлений в реальном времени. В конкретном поле атрибута, связанного с автономным состоянием, полное обновление в пределах нескольких миллисекунд, более высокие требования в реальном времени.

Поле индекса, используемого для условий вспомогательных условий, может быть обновлено с лагом, например, в течение нескольких секунд. Использование стратегии деления и завоевания может значительно уменьшить сложность системы.

• Обновление поля атрибута: прямое изменение значения поля прямой таблицы, которое может быть выполнено за миллисекунды.
• Обновление полей индекса: процесс обработки, включающий вычисление в реальном времени потока обновления, инвертированного индекса и т. д., должен быть завершен всего за несколько секунд.

Кроме того, благодаря регулярному переключению полного индекса и добавлению добавочного индекса правильность данных обеспечивается моментальным снимком индекса.

Иерархия

投放模型的主要实体是广告主（Advertiser）、推广计划（Campaign）、广告组（Adgroup）、创意（Creative）等。 в:

• Рекламодатели и рекламные программы: определение различных полей статуса, используемых для управления показом рекламы.
• Группа объявлений: описывает атрибуты, связанные с рекламой, такие как ключевые слова ставок, максимальная ставка и т. д.
• Креатив: поля, связанные с представлением, кликом и т. д. рекламы, такие как заголовок, адрес креатива, адрес клика и т. д.

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

1. Найти список связанных docID из инвертированного индекса по критериям запроса
2. Для каждого docID соответствующую информацию о поле можно получить из основной таблицы.
3. Используйте поле внешнего ключа для получения информации о поле соответствующей вспомогательной таблицы соответственно.

Синхронная фильтрация различных значений поля реализована в процессе поиска.

Надежный и эффективный

Структура рекламного индекса относительно стабильна и слабо связана с конкретными бизнес-сценариями.Чтобы избежать скачков производительности виртуальной машины Java из-за механизмов динамического управления памятью и сборки мусора, в качестве языка разработки, наконец, используется C++11. Хотя Java может использовать память вне кучи, копирование данных в куче вне кучи по-прежнему сопряжено с большими накладными расходами при высоком параллельном доступе. Проект строго следует «стилю Google C++», что значительно снижает порог программирования.

В бизнес-сценарии «больше читать и меньше писать» необходимо отдавать приоритет обеспечению производительности «чтения». Извлечение – это процесс поиска в памяти, требующий больших вычислительных ресурсов. Чтобы обеспечить высокий уровень параллельной обработки ЦП, он обычно разработан как структура без блокировок. Для обеспечения эффективной и стабильной работы системы можно использовать такие технологии, как «одна запись, множество чтения» и отложенное удаление. Кроме того, разумное использование структуры массива дополнительно оптимизирует производительность чтения.

Гибкое расширение

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

логическая структура

С функциональной перспективы индекс состоит из двух частей и индексной таблицы. Как показано в том, что термин индекса реализован как фиг, преобразованный главной таблицей к DOCID; ряд таблицы для достижения положительных хранилищ данных и для достижения связанной основной таблицы и вторичной таблицы путем DociD.

Многоуровневая архитектура

Библиотека индексов разделена на три слоя:

1. Уровень интерфейса: предоставляет такие функции, как построение индекса, обновление, поиск, фильтрация и т. д.
2. Уровень возможностей: это ядро ​​​​системы для реализации функции индекса на основе инвертированного списка и положительного списка.
3. Уровень хранения: структура памяти индексных данных и постоянное хранилище в файлах

реализация индекса

Этот раздел будет описывать детали дизайна и задачи каждого слоя снизу вверх, начиная с слоя хранения.

уровень хранения

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

Абстрагируйте слой хранения как распределитель. Различные распределители могут быть настроены для различных сценариев использования памяти, таких как требования к непрерывности памяти и необходимости восстановления памяти.

Ниже приведены все распределители, основанные на mmap, где «память» относится к виртуальному адресному пространству вызывающего процесса. Фактическая логика кода также включает в себя сложное управление метаданными, которое не упоминается ниже.

Простая стратегия распределения

• LinearAllocator

• Выделять память в непрерывном адресном пространстве, то есть большой кусок памяти, при необходимости расширения пространства будет использоваться новое сопоставление файлов mmap, а старое сопоставление файлов будет выгружаться с задержкой

• Новые сопоставления вызывают перезагрузку таблицы страниц, сопоставления больших блоков памяти вызывают дрожание производительности из-за загрузки физической памяти.

• Обычно используется в сценариях с относительно фиксированными требованиями к пространству, например, в массиве сегментов HashMap.

• SegmentAllocator

• Чтобы решить проблему джиттера производительности LinearAllocator во время расширения, память может храниться в сегментах, то есть в каждом расширении задействован только один сегмент для обеспечения стабильной работы.

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

• Размер сегмента по умолчанию — 64 МБ.

стратегия интенсивного распределения

Частое добавление, удаление, изменение и другие операции с данными приведут к большому количеству внешних фрагментов. Использование операций сжатия может сделать занимаемую память более компактной, но трудно найти баланс между производительностью и сложностью за счет перемещения объектов. В инженерной практике стратегия выделения физической памяти Linux используется для реализации нескольких распределителей, более подходящих для бизнес-сценариев.

• PageAllocator
• Размер страницы составляет 4 КБ, предполагается, что используется система друзей (Buddy System) для достижения страницы распространения и восстановления.
• Распределение страниц происходит на основе SegmentAllocator, то есть сначала сегментация, а потом пейджинг

Процесс обработки партнерского распределителя кратко описан здесь.Чтобы эффективно управлять бесплатными блоками, каждый уровень ордера содержит FreeList свободных блоков. Установите максимальный уровень порядка=4, то есть начиная с порядка=0, от низкого к высокому, количество страниц в каждом блоке порядка 1, 2, 4, 8, 16 и т.д. соответственно. При размещении сначала найти наименьший блок, удовлетворяющий условиям, если нет, то найти блок большего размера на верхнем уровне, и разделить блок на двух «партнеров», один из которых выделяется и используется, а другой помещается в нижний уровень.

На следующем рисунке показаны изменения состояния до и после выделения блока памяти размером со страницу.Перед выделением распределитель начинает поиск FreeList с порядка=0 и не находит свободный блок до тех пор, пока порядок=4.

Разделите свободный блок на 2 партнеров с 8 страницами, используйте первую половину и смонтируйте вторую половину в FreeList с порядком = 3; повторяйте этот процесс уровень за уровнем, пока не будет возвращен требуемый блок памяти, а количество страниц не равно A. блок из 1 висит в FreeList с порядком=0.

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

Хотя PageAllocator эффективно предотвращает внешнюю фрагментацию, он не может решить проблему внутренней фрагментации. Чтобы решить проблему размещения таких небольших объектов, реализован распределитель кеша объектов (SlabAllocator).

• SlabAllocator
• Кэш объектов выделяется на основе PageAllocator, размер плиты указывается в страницах.
• Свободные объекты определяются как несколько SlabManager в соответствии с размером памяти, каждый SlabManager содержит PartialFreeList для размещения блоков, содержащих свободные объекты.

Процесс выделения памяти объекта заключается в получении блока, содержащего свободный объект, из соответствующего списка PartialFreeList и выделении объекта из блока. И наоборот, процесс освобождения является процессом, обратным выделению.

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

Уровень возможностей

Уровень возможностей реализует основные возможности хранения, такие как прямые и обратные списки, и поддерживает гибкое расширение возможностей индексирования.

Форвардный индекс

Также известен как индекс вперед (FROWS INDEX), I.E. Содержание восстановленного документа (DOC), указанное в данном виде, называемым в качестве таблицы таблицы стола или положительного перемещения (ключ). В отличие от положительного перемещения по поисковой системе структура данных таблицы энергии, таблица NoSQL Scene также может использоваться отдельно, такая как хэш кабинета Kyoto.

Таблица не только обеспечивает такие операции, как добавление, удаление, изменение и запрос по первичному ключу, но также реализует такие функции, как поиск, фильтрация и чтение с инвертированными таблицами. Как основная структура данных, таблица должна поддерживать частое чтение полей и различные типы положительной фильтрации строк, что требует эффективной и компактной реализации.

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

Кроме того, для сценариев NoSQL сопоставление первичных ключей с docID (файлами idx) можно реализовать с помощью HashMap, чтобы можно было поддерживать произвольный доступ первичных ключей к документам. Поскольку список docID инвертированного индекса может напрямую обращаться к прямой таблице, idx не используется для инвертированного поиска.

обратный индекс

Также известен как инвертированный индекс (Inverted Index), то есть через ключевое слово (Keyword) для извлечения содержимого документа. Для поддержки сложных бизнес-сценариев, таких как грубая логика сортировки алгоритма при обходе индексной таблицы, здесь абстрагируется интерфейс индексатора Indexer.

Особый индексатор необходимо только для реализации каждого метода интерфейса и регистрировать тип в индексировании. Экземпляр индексатора может быть получен через метод Newindexer на заводе. Диаграмма класса следующая:

В настоящее время реализовано три широко используемых индексатора.

• NoPayloadIndexer: самый простой инвертированный индекс, инвертированный список представляет собой простой список docID.
• DefaultPayloadIndexer: в дополнение к идентификатору документа в инвертированной таблице также хранится полезная информация о ключевом слове в каждом документе. Для бизнес-сценариев можно сохранить статический показатель качества или наивысшую ставку POI на каждом узле детализации. Таким образом, перед доступом к прямому списку может быть выполнена определенная фильтрация инвертированных предпочтений.
• GEOHashIndexer: хэш-индекс с географической привязкой.

Конструктивные идеи вышеуказанных индексаторов схожи, и описаны только две общие черты:

• Термин файла словаря: хранит ключевые слова, хэш подписи, смещение и длину файла публикации и т. д. В отличие от древовидной структуры префиксного сжатия, принятой в Lucene, здесь оно реализовано в виде хэш-таблицы, хотя пространство тратится впустую, но может обеспечить стабильную производительность доступа.
• Публикация файла перевернутого списка: список docID хранилища, полезная нагрузка и другая информация. Операция извлечения представляет собой последовательное сканирование перевернутого списка и выполнение каких-либо действий на основе логической операции между фильтром полезной нагрузки или перевернутой цепочкой. Как в полной мере воспользоваться преимуществами высокопроизводительного чтения индекса кэша — важный фактор при проектировании и реализации, который необходимо учитывать в процессе сканирования. . В распределении памяти на основе сегментов реализован segmentAllocator для достижения тонкого баланса между эффективностью и сложностью.

По деловым причинам структура списка пропуска Lucene не используется, поскольку количество документов в рекламной сцене не так велико, как в поисковой системе, и обычно это одна операция с перевернутым списком. Кроме того, если количество последующих документов растет слишком быстро и индекс часто меняется, рассмотрите возможность создания древовидной структуры B+ для элементов инвертированного списка, чтобы быстро находить и изменять инвертированные элементы.

интерфейсный слой

Уровень интерфейса взаимодействует с внешним миром через API и скрывает детали внутренней обработки. Его основная функция заключается в предоставлении услуг поиска и обновления.

конфигурационный файл

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

Видимый, Индекс строится в Таблице, но не обязателен, определение полей в Таблице Схемы ядра. При изменении схемы, например при увеличении индексов полей, необходимо перестроить индекс. Пространство не расширяет определение деталей здесь.

поисковый интерфейс

Извлечение состоит из поиска и фильтрации. Первый создает набор найденных идентификаторов документов, а второй выполняет различные базовые фильтры и бизнес-фильтрацию документов один за другим.

• Поиск: возвращает отфильтрованный набор результатов в положительной строке и внутренне объединяет вызовы DoSearch и DoFilter.
• DoSearch: запрашивать документ, возвращать исходный набор результатов, но не фильтровать результаты вперед
• DoFilter: выполнять фильтрацию положительных строк в наборе результатов, возвращаемом DoSearch.

Как правило, все функции можно реализовать, вызвав только поиск; DoSearch и DoFilter можно использовать для реализации более сложной бизнес-логики.

Ниже приводится описание синтаксиса поиска:

/{table}/{indexer|keyfield}?query=xxxxxx&filter=xxxxx

Первая часть — это путь, который указывает таблицу и индекс. Вторая часть — это параметры. Несколько параметров разделяются символом &, что соответствует формату параметра URI. Он поддерживает запрос, фильтр, фильтр полезной нагрузки, фильтр_индекса и т. д.

Правила извлечения для инвертированного индекса определяются параметром запроса. В настоящее время поддерживается только поиск индекса одного типа, а поиск комбинированного индекса может быть реализован с помощью index_filter. Логические операции, такие как AND, OR, NOT, могут поддерживаться следующим образом:

query=(A&B|C|D)!E

Дерево синтаксиса запроса генерирует код на основе Bison. Для операции объединения docID нескольких терминов, обычно используемых в бизнес-сценариях, путем изменения правил грамматики Bison временное хранилище для хранения результатов слияния документов двух смежных терминов устраняется, а документ предыдущего термина напрямую объединяется с текущим набор результатов. . Эта оптимизация значительно снижает накладные расходы на временные объекты.

Параметр filter определяет различные типы фильтрации значений полей таблицы положительных строк, а несколько пар "ключ-значение" разделяются символом ";", что поддерживает реляционные операции с однозначными полями и операции над множествами с многозначными полями.

Фильтр индекса полезной нагрузки определяется параметром payload_filter. В настоящее время поддерживаются только реляционные операции с полями с одним значением, а несколько пар "ключ-значение" разделяются символом ";".

Подробный синтаксис фильтра выглядит следующим образом:

Кроме того, индексный фильтр, определенный параметром index_filter, будет работать непосредственно с инвертированной цепочкой. Поскольку построение структуры данных извлечения более сложно, чем прямая фильтрация, этот параметр подходит только для сценариев, в которых вызванный список документов особенно длинный, а список документов, отфильтрованный по индексу, короткий.

набор результатов

Реализацию результирующего набора ResultSet см. в интерфейсе java.sql.ResultSet. Перемещайтесь по результирующему набору с помощью курсора, используя накладные расходы на частые вызовы встроенных функций.

Реализованный как класс-шаблон C++, основной интерфейс определяется следующим образом:

• Далее: переместите курсор на следующий документ, верните true в случае успеха, в противном случае верните false. Возвращает false, если это уже последняя запись в коллекции
• GetValue: чтение значения поля с одним значением, тип поля определяется общим параметром T. Если получение не удалось, вернуть значение по умолчанию def_value
• GetMultiValue: чтение значения поля с несколькими значениями, значение возвращает указатель на массив размера, возвращаемый параметром размера. Ошибка чтения возвращает null, размер равен 0

Обновить интерфейс

Обновления включают такие операции, как добавление, изменение и удаление документа. Тип параметра Документ представляет собой запись документа, содержимое — это содержимое поля документа, который необходимо обновить, ключ — это имя поля, а значение — соответствующее значение поля. Возвращает 0, если операция прошла успешно, и возвращает не 0, если операция не удалась.Информацию об ошибке можно получить через интерфейс GetErrorString.

• Добавить интерфейс Добавить: добавить новый документ в таблицу и индекс
• Изменение интерфейса. Обновление: изменение существующего содержимого документа, включая изменения в таблице и указателе.
• Удалить интерфейс Удалить: удалить существующий документ, который включает удаление данных из таблицы и указателя.

Служба обновлений подключена к потоку обновлений в реальном времени для индексации рекламных объявлений в реальном времени.

система обновления

В дополнение к механизму реализации индекса, описанному выше, производственная система также должна открыть поток обновлений между механизмом онлайн-доставки и продавцом, бюджетным контролем и защитой от мошенничества.

вызовы и цели

Основная задача системы обновления данных состоит в том, чтобы агрегировать, разбивать и вычислять исходную многомерную информацию и, наконец, выводить измерения и содержимое, требуемые механизмом онлайн-поиска.

Запуск вверх по течению может быть крайне нерегулярным из-за бизнес-сценариев. Чтобы избежать джиттера в потоке обновлений, пропускная способность обновлений в реальном времени должна быть оптимизирована, чтобы обеспечить достаточный запас производительности для обработки всплесков триггеров. Кроме того, обновление системы включает преобразование измерений «многие ко многим», а поддержание ремонтопригодности логики, такой как расчет и запуск обновлений, является основной проблемой, стоящей перед системой.

Дизайн пропускной способности

Хотя для обновления системы требуется много вычислительных ресурсов, оно по-прежнему является приложением с интенсивным вводом-выводом из-за необходимости запрашивать десятки внешних источников данных. Оптимизация механизма доступа к внешним источникам данных является основной целью оптимизации пропускной способности.

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

Многоуровневая абстракция

В дополнение к генерации данных модели доставки на стороне продавца, система обновлений также должна иметь дело с фильтрацией для различных бизнес-сценариев и различных типов эксклюзивной информации, представленной рекламными объявлениями. Бизнес-изменения могут включать в себя логическую корректировку нескольких источников данных, и только путем четкого и четкого разделения их на абстракции можно справиться со сложностью бизнес-итераций.

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

Определите данные как абстрактные типы, такие как таблица, запись, поле, значение и т. д., и определите их как тип, зависящий от пути Scala, что удобно для компилятора для проверки логики внутри программы.

Многоразовый дизайн

В сценариях многомерных вычислений функция обработки (DFP) для каждого поля должна быть максимально простой и многократно используемой. Например, DFP для каждого выходного поля (DF) описывает только обязательное поле исходных данных (SF) и логику расчета для этого поля и не описывает требуемый запрос или отношение маршрутизации между SF(1) и SF(n). .

Кроме того, DFP не привязан к конечной выходной иерархии. Иерархическая привязка завершается при определении полей, содержащихся в выходном сообщении, то есть при определении сообщения необходимо определить, на каком уровне находится первичный ключ сообщения, и одновременно привязать ряд DFP к сообщение.

Таким образом, DFP просто описывает логику создания содержимого поля. Если в бизнес-сценарии необходимо разбить один и тот же DF на разные уровни, просто обратитесь к одному и тому же DFP в выходном сообщении этого уровня.

триггерный механизм

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

Чтобы реализовать механизм автоматического триггера для изменений источника данных, необходимо описать следующую информацию:

• Отношение ассоциации между данными: реализовать синтаксис для описания отношения отношения, то есть описывать отношение отношения при описании внешнего источника данных, а маршрутизация последующих запросов полей будет обрабатываться платформой.
• Информация о SF, зависящая от DFP: для простого DFP, который обрабатывает только один подраздел, зависимую SF можно закрепить во время компиляции с помощью настройки; для сложных DFP с несколькими источниками данных зависимую от DFP SF можно получить с помощью анализа исходного кода. не требуя от пользователей поддерживать зависимости

Производственная практика

Ранние поисковые рекламы были построены на основе структуры естественной поисковой системы. С развитием бизнеса система должна быть преобразована в соответствии с характеристиками рекламы. Новый Ad Index, который реализует чистые обновления в реальном времени и иерархическую структуру, был запущен на поисковой рекламе Meituan-Dianping. Эта архитектура также применима к различным информационным бизнес-сценариям.

структура системы

Являясь ядром всей системы, служба поиска и фильтрации рекламы (RS), построенная на основе индекса в реальном времени, выполняет функции поиска рекламы и различных бизнес-фильтров. Ежедневные бизнес-итерации можно выполнять, обновляя конфигурацию индекса.

Кроме того, чтобы повысить пропускную способность системы, несколько модулей достигли асинхронности на стороне сервера.

оптимизация производительности

Ниже приведена кривая производительности системы мониторинга: количество документов в индексе указано в миллионах, а единица задержки — миллисекунды.

Последующее планирование

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

JNI

Через JNI Table используется как отдельный NoSQL для обеспечения локального кэширования для Java. Например, модуль прогнозирования в реальном времени рекламной системы может использовать таблицу для хранения рекламных функций, используемых моделью.

SQL

Предоставляет синтаксис SQL, обеспечивает простую поддержку SQL и дополнительно снижает порог для использования. Предоставляет JDBC для дальнейшего упрощения вызовов Java.

использованная литература

• Apache Lucene http://lucene.apache.org/
• Sphinx http://sphinxsearch.com/
• "Understanding the Linux Virtual Memory Manager" https://www.kernel.org/doc/gorman/html/understand/
• Kyoto Cabinet http://fallabs.com/kyotocabinet/
• GNU Bison https://www.gnu.org/software/bison/

об авторе

Кан Куи: Архитектор группы поисковой рекламы рекламной платформы, руководил разработкой и внедрением системы индексации рекламы в реальном времени. Он хорошо разбирается в C++, Java и других языках программирования, а также глубоко изучает асинхронные системы и настройку фоновых служб.

Xiaohui: основная разработка поисковой рекламной группы рекламной платформы, отвечающая за разработку и реализацию потока обновлений в реальном времени. Являлся пионером языка Scala на рекламной платформе и использовал его в крупномасштабной инженерной практике.

Лю Чжэн: руководитель группы поисковой рекламы рекламной платформы, имеет многолетний опыт разработки серверной части Интернета и руководил многими реконструкциями системы.

Цай Пинг: человек, отвечающий за комментарии группы поисковой рекламы рекламной платформы, несет полную ответственность за архитектуру и оптимизацию системы комментариев.

Карьера

Друзья, которые заинтересованы в фоновой разработке Linux и заинтересованы в компьютерной рекламе, высокопроизводительных вычислениях, распределенных системах и т. д., пожалуйста, свяжитесь с нами по электронной почте liuzheng04@meituan.com.Если вы заинтересованы в нашей команде, вы можете следить за нашимистолбец.