Описание задачи:

Предварительный анализ задачи определения мошеннических финансовых операций

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

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

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

Вам предлагают принять участие в проектировании и построении такой системы.

В ходе детального обсуждения проекта с представителями заказчика выяснились следующие моменты:

1. Руководство готово выделить на реализацию данного проекта не более 10 млн. руб. (не считая зарплат специалистам). Через три месяца оно хотело бы увидеть первые результаты, что позволило бы понять, стоит ли дальше развивать проект. В случае положительного решения, проект нужно завершить за полгода.

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

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

4. Если система определит корректную транзакцию как мошенническую, эта транзакция будет отклонена, а пользователь будет недоволен. Опыт бизнес-аналитиков подсказывает, что если доля таких транзакций превысит 5 %, то начнется отток клиентов из компании.

5. Представители компании не готовы размещать разрабатываемый модуль на собственных вычислительных ресурсах.

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

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

1. Сформулировать цели проектируемой антифрод-системы в соответствии с требованиями заказчика.

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

3. Проанализировать особенности проекта с использованием, например, MISSION Canvas. Это позволит выделить специфику проекта и формализовать требования к нему, подобрать инструментарий и критерии оценки.

4. Попытаться декомпозировать планируемую систему, определить ее основные функциональные части.

5. Определить задачи, решение которых необходимо для достижения поставленных целей с учетом проведенного анализа. Задачи рекомендуется фор- мулировать по принципу S.M.A.R.T. На текущий момент, пока не конкретизированы детали антифрод-системы, они могут быть представлены в доста- точно общем виде. Но они позволят сформировать некоторый roadmap по реализации проекта.

6. Создать GitHub-репозиторий для проекта и разместить в нем сформулированные задачи (∼ 5 задач) на Kanban-доске в GitHub Projects со статусом «Новые».

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

Анализ приведён в файле solution_concept.md

1. Создать новый backet в Yandex Cloud Object Storage и скопировать в него содержимое предоставленного Вам хранилища с использованием ин- струмента s3cmd. Для проверки преподавателем данный basket необходимо сделать общедоступным, а точку доступа к нему привести в README-файле Вашего GitHub-репозитория.

2. Создать Spark-кластер в Data Proc с двумя подкластерами со следующими характеристиками: а) Мастер-подкластер: класс хоста s3-c2-m8, размер хранилища 40 ГБ. б) Data-подкластер: класс хоста s3-c4-m16, 3 хоста, размер хранилища 128 ГБ.

3. Соединиться по SSH с мастер-узлом и выполнить на нём команду копирования содержимого хранилища в файловую систему HDFS с использовани- ем инструмента hadoop distcp. Для проверки преподавателем необходимо вывести содержимое HDFS-директории в консоль, а снимок экрана с этой информацией привести в README-файле Вашего GitHub-репозитория.

4. Пользуясь тарифным калькулятором Yandex Cloud, оценить месячные затраты для поддержания работоспособности созданного кластера. Оценить, насколько использование HDFS-хранилища дороже, чем объектного.

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

5. Предложить способы для оптимизации затрат на содержание Spark-кластера в облаке и попробовать их реализовать.

6. В соответствии с достигнутыми результатами, изменить статус ранее созданных задач на Kanban-доске в GitHub Projects. Возможно, некоторые задачи нужно будет скорректировать, разделить на подзадачи или объединить друг с другом.

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

1. s3://mlopss3storage0001/afraud/

2. 

3. 

4. 

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

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

Объём данных для анализа очень скромен и самым быстрым с архитектурной точки зрения будет использование Spark в standalone режиме с хранением на "локальном" SSD этой виртуалки. Обсуждение кластерных конфигираций будут иметь смысл только если в память одной виртуалки не влезет весь требуемый датасет. Пока выглядит так, что влезет.

Также открытым является вопрос о возможности параллельного анализа данных в данном датасете. Если это возможно, то при реализации честного data locality для каждой datanode, с быстрой хранилкой на ней, можно обеспечить производительность приближающуюся, но точно меньшую чем на одной "большой" виртуалке.

В любом случае сетевые задержки при организации RDD/Dataframe, чтение данных с нелокальных дисков/сетевых FS, транзакционные издержки на шафлинг и т.п. будут очень значительны, что приведёт к большому требуемому времени аренды ресурсов и соответсвенно затратам.

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

Что касается HDFS в кластере Spark - на мой взгляд ни hdfs, ни yarn, ни hive в данной задаче не нужны и скорее вредны из-за внесения дополнительных неустранимых задержек на этапе размещения задачи. При таком объёме данных особой выгоды от их распределения и распределённого управления ресурсами совершенно нет.

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