#статья дня
Все, наверное, знают о том, что существует поведенческий таргетинг — который определяет, какая реклама вам больше интересна.
И под капотом такой системы — полноценная big data-инфраструктура: события пишутся в логи, проходят обработку и попадают в key-value хранилище, откуда их читает рантайм показа рекламы.
Причем система должна работать так надежно, чтобы каждое событие обработалось ровно один раз (exactly-once), и так быстро, чтобы уложиться в миллисекунды на весь цикл.
Как этого добиться — рассказал в статье Руслан Савченко, разработчик динамических таблиц YTsaurus: https://habr.com/ru/companies/yandex/articles/939078/
Из интересного:
— События шардируются по хешу идентификатора. Это гарантирует, что все события одного пользователя обрабатываются одним воркером в рамках локальной транзакции.
— Дошли до низкоуровневой оптимизации аллокатора памяти и работы с ядром Linux, чтобы убрать провалы на высоких перцентилях.
— Вместо перезаписи всего protobuf-профиля система пишет бинарные дельты (через xdelta). Агрегатные колонки накладывают все накопившиеся дельты на оригинальный protobuf — получаем актуальную версию объекта
Все решения, на самом деле, можно применять не только к профилям. Прикольно, что в статье куча графиков — помогают разобраться. Советую почитать на досуге
#highload #db #database
Все, наверное, знают о том, что существует поведенческий таргетинг — который определяет, какая реклама вам больше интересна.
И под капотом такой системы — полноценная big data-инфраструктура: события пишутся в логи, проходят обработку и попадают в key-value хранилище, откуда их читает рантайм показа рекламы.
Причем система должна работать так надежно, чтобы каждое событие обработалось ровно один раз (exactly-once), и так быстро, чтобы уложиться в миллисекунды на весь цикл.
Как этого добиться — рассказал в статье Руслан Савченко, разработчик динамических таблиц YTsaurus: https://habr.com/ru/companies/yandex/articles/939078/
Из интересного:
— События шардируются по хешу идентификатора. Это гарантирует, что все события одного пользователя обрабатываются одним воркером в рамках локальной транзакции.
— Дошли до низкоуровневой оптимизации аллокатора памяти и работы с ядром Linux, чтобы убрать провалы на высоких перцентилях.
— Вместо перезаписи всего protobuf-профиля система пишет бинарные дельты (через xdelta). Агрегатные колонки накладывают все накопившиеся дельты на оригинальный protobuf — получаем актуальную версию объекта
Все решения, на самом деле, можно применять не только к профилям. Прикольно, что в статье куча графиков — помогают разобраться. Советую почитать на досуге
#highload #db #database
❤4👍4🫡3