Хочу поделиться вакансией моего друга, Виталика Минаева, в ML Autotasking Старший DS инженер

ML Autotasking - это про выставление задач менеджерам по продажам. Направление горячее, импакт на бизнес большой!

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

Могу порекомендовать и Виталика, и команду. Будет интересно!

Резюме скидывайте напрямую Виталику в телегу – @vminaev88 =)

Впечатления с Fintech Data Day

Вчера выступал на Fintech Data Day. Доклад назывался - еком vs банки: отличия инфраструктуры данных на примерах.

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

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

А так конечно приятно, что меня позвали. Здорово, что появилась новая классная конфа🔥

Ecom vs Банк: о в подходах работе с данными

Всем привет! Последнее время маловато пишу. Думаю так будет до конца лета, а потом начну новый сезон!

Как обещал, хочу поделиться о чем я рассказывал на Fintech Data Day. Вообще, я занимаюсь алгоритмами монетизации в Авито. И это совсем не то, что обычно понимают под словом финтех, хотя это тоже про деньги. Я был на конференции как человек из другой индустрии, у меня была задача сделать доклад на стыке. Тем более, что в банке я тоже прилично проработал.

Недолго думая я решил рассказать про 3 кейса, почему в некоторых продуктовых ecom компаниях очень быстро идет работа с области аналитики и DS. Сами идеи небольшие и как раз уместятся в один пост.

Активное использование событий как источника данных

Во многих компаниях, в т. ч. в банках, доставка данных в хранилище данных строится на базе технологии CDC, change data capture. При всех плюсах у этого подхода есть пару недостатков: CDC реплики делать дорого и дорого поддерживать, а структуры баз данных сервисов не предназначены для аналитических запросов. Поэтому создание витрин напрямую из сырых реплик требует значительных ресурсов и сложных методологий (привет 6-я нормальная форма и data vault). Зато, в хранилище всегда лежит точная копия данных.

Но часто прямо 100%-ная точность не нужна. В итоге вы же считаете агрегированные метрики или достаете небольшой семпл конкретных примеров. Если потеряете одну строчку - ну ничего страшного. Продуктовые компании этим активно пользуются и часть своей аналитики строят на событиях. Это когда вы в середине какого-то процесса отправляете сообщение в формате JSON с какими-то данными и они летят в сторону хранилища. Получается сильно быстрее: и само событие добавить дело нехитрое, и потом на стороне аналитики джойнить нужно меньше. Пропадают события нечасто, но такое может быть. И уж если пропадет, то пропадет насовсем. Такая плата за эффективность.

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

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

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

Поэтому работу с продом нужно не запрещать, а нужно создавать безопасные подходы работы.

Прямой доступ аналитиков к некоторым продовым API

И развивая предыдущую историю. Аналитикам и DS-ам нужно в некоторых сценариях ходить в продовые API. Например, где-то можно нужно запустить тест. Где-то нужно поискать баги. Где-то получить данные в моменте. Если на каждую проблему откатывать сервис, уходить в тестовый контур, и пытаться воспроизвести проблему, то можно фичи делать бесконечно. С дата-центричными сервисами такое плохо работает.

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

Спасибо что дочитали! Надеюсь было интересно ❤️

#tech