Pull to refresh
0
Karma
0
Rating
Дмитрий Чеклов @dcheklov

User

  • Followers 2
  • Following 1

Принцип адвоката Брофловски, или облачная балансировка нагрузки своими руками

А есть информация по тому, какой rps и на каком датасете дает оптимальные результаты при работе с NVMe на одном сервере. Объясню, в нашем случае, когда работаем с RAM, мы вообще не паримся с количеством инстансов, ограничение по сути — это слоты оперативной памяти, и мы ни разу не упирались в rps, запас по нагрузке в десятки раз больше, чем есть.

Принцип адвоката Брофловски, или облачная балансировка нагрузки своими руками

Отличная статья, хорошо, когда коллеги по цеху делятся опытом. Есть пару вопросов:

1. Вы пишите про использование Aerospike на NVMe дисках. У вас при этом гибридная схема хранения? Просто если все в RAM, то не понятно, какой прирост дает NVM?
2. Как синхронизируете Aerospike в разных локациях: родную синхронизацию или еще как?

Очень большой Postgres

Шардирование — и есть горизонтальное масштабирование. Репликация в статье приводится для общего обзора. Читайте внимательнее)

Оптимизация гиперпараметров в Vowpal Wabbit с помощью нового модуля vw-hyperopt

Kurtosis Попробовал исправленную версию, все работает, видимо это и правда из-за тегов.

Оптимизация гиперпараметров в Vowpal Wabbit с помощью нового модуля vw-hyperopt

Решил попробовать vw_hyperopt, сразу получил ошибку. Подробности описал в issue в официальной ветке vowpal wabbit на Github

Apache Spark или возвращение блудного пользователя

Тут скорее ответ выглядит так: у кого какой опыт с той или иной базой. Чтобы потестить базу в High Load проектах, нужно с этой базой в реальных условиях пожить 3-5 месяцев, чтобы узнать все плюсы и минусы. Так что HBase выбрали исходя из предыдущего опыта, а Cassandra испытывалась только на локальном компе)

Apache Spark или возвращение блудного пользователя

Если Cassandra вместо Spark, то смысла не вижу, тк основное требование у нас — это гибкость обработки и возможность использовать обычный язык программирования. Что бы там не предлагала Кэсси — мы всегда будем зависеть о ее ограничений. Если заметили, мы в реалтайме еще собираем HyperLogLog каждого аудиторного сегмента.

Из баз данных, которые из коробки предлагают все, что нам нужно было в этой задаче — VoltDB. Но я не могу ручаться за то, что с ней не было бы каких-то косяков и ограничений.

Apache Spark или возвращение блудного пользователя

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

Apache Spark или возвращение блудного пользователя

Вы в статье упустили важную часть, как раз про описание аудиторий, а также про модель данных (Event). В общем вся суть для чего мы вообще эту архитектуру задумали) Получилось очень сильно про Spark, но мало — какую задачу решает.

Apache Spark или возвращение блудного пользователя

Aerospike — хранит уже готовые профили пользователей, например таблица visitor_id; audiences[]. Когда в DSP приходит RTB-запрос, то используется именно Aerospike. Здесь пока ни одна другая база не показывала такие результаты быстродействия, низкий latency, и низкую загрузку процессора.

Mongo — хороша для кодеров, когда нужно сохранить объект в базу. Здесь Mongo со своей документ-ориентированной архитектурой вне конкуренции. Нагрузки практически не держит. В общем эта база только под специфические задачи осталась.

HBase — у нас пришла на смену Mongo, но пока не везде смогла вытеснить ее из-за ограничений. HBase интегрирован в кластер Hadoop и ее реально можно настроить на высокую отказоустойчивость и быстродействие. Также очень важна рандомная запись/чтение, что Mongo ну совсем никак не настроить

FrostNova Кстати а, что здесь Mongo делает, мы вроде ее уже выпилили?

DMP часть 1. Микросегментирование аудитории с помощью ключевых слов

С каждым поставщиком настроен cookie matching. Либо сразу наш пиксель на сайтах стоит

DMP часть 1. Микросегментирование аудитории с помощью ключевых слов

В первой версии нет такой задачи. Дальше будем пробовать, развивать, тестировать.

DMP часть 1. Микросегментирование аудитории с помощью ключевых слов

TF-IDF и прочие плюшки больше характерны для задачи классификации страниц. Здесь больше задача про пользователя.

Есть мысли попробовать следующее:
— Индексировать пользователей по LDA-топикам (то есть не все ключевые слова, а только те, что влияют на определение темы страницы)
— Сделать расширенный поиск. Рекламодатель вводит ключевые слова, а поиск осуществляется по тому, в какие топики входят эти слова.

DMP часть 1. Микросегментирование аудитории с помощью ключевых слов

1. Текст вынимается целиком абзацами, фильтруется и сохраняется в Solr. Заботу по поиску он уже берет на себя. Solr поддерживает большое количество операторов поиска.
2. В поиске Google, Yandex, Mail. А как же шифровка referer? Не знаю, посмотрите в GA, увидите там небольшой процент нешифрованного трафика, 3-8%. В рамках тех объемов, что мы получаем количество поисковых запросов достаточно много. В статье мы намеренно опустили, как мы его обрабатываем, т.к. задача это простая, только текст усложнили бы.

DMP часть 1. Микросегментирование аудитории с помощью ключевых слов

— Поставщики по-разному отдают: мы ставим коды (в этом случае в Kafka информация уходит с наших же серверов), присылают по протоколу zeromq, либо http протоколу. В общем маршрут до Kafka проходит в большинстве случаев еще через какие-нибудь сервисы.

— Spark — это VisitorActionReciever. Да не понятно, надо подправить.

— Spark на Java писали. Кстати, в статье есть кусок кода.

— Solr. Прямо скажем, из-за Cloudera. На уровне индекса Solr и ElasticSearch — это все Lucene. Возможно когда-нибудь попробуем ES для этой задачи, но если упремся в производительность Solr. На текущий момент все устраивает.

Hybrid Conf — первая конференция о programmatic-advertising в России

Рекламодателей/агентств было 30% по крайней мере. Да и цели не было делать это только для рекламодателей.

Targetix — разработка full-stack RTB технологий

Я думаю по мотивам этих вопросов лучше статью написать с бенчмарками. Пока стоит на слово поверить, 7 000 rps наш биддер держит, но пришли мы к этому тоже не за один день.

Targetix — разработка full-stack RTB технологий

Дополню расчет:

70 запросов / 24 потока (2 процессора по 6 ядер с включенным Hyper Threading) = 3 запроса на 1 поток за мс. Также учитывая, что каждый запрос не выполняется меньше, чем 10 мс, а 2-3 в среднем, то получаем 1 запрос на 1 поток на мс.

DSP на .Net под Windows. Джедайской Силы Пост

Сергей, конечно) Пиши
1

Information

Rating
Does not participate
Location
Россия
Registered
Activity