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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#tech