Процесс состоит из трех действий:
- Выгрузка из Яндекс.Метрики в metrika_report.py. Итоговый файл data/data_metrika.csv.
- Обработка базы costs_db.csv в costs_processing.py. Итоговый файл data/data_costs.csv.
- Объединение результатов первых двух пунктов в main.py и подсчет столбца cost_per_visit. Итоговый результат складывается в data/joined.csv.
Параметры запуска (например, дата выгрузки LOAD_DATE) лежат в файле config.py. Описание параметров и функций приведено в коде.
python metrika_lib.py
python costs_processing.py
python main.py
Чем такое построение процесса отличается от примеров в jupyter notebook:
-
Для получения нового отчета добавьте в metrika_lib.py новую функцию по аналогии с функциями attendance и traffic_sources. Скорее всего это будет функция из одной строчки. Обычно библиотеки вроде metrika_lib.py можно сильно упростить с помощью классов, но здесь для учебных целей специально используются только функции.
-
Обратите внимание на небольшие размеры каждой функции. В случае возникновения ошибки можно проверить каждое действие ETL-процесса, вызвав его с помощью функции с заданными параметрами. И относительно быстро скорректировать код. Также можно внести изменения в код, изменяя только одну функцию:
- Для усовершенствования запросов к API Я.Метрики изменяйте request_report. Например, иногда сеть мигает или сервис кратковременно недоступен. Можно добавить алгоритм экспоненциальной задержки в request_report, не трогая остальной код.
- Для изменения формата отдаваемых данных изменяйте reformat_api_report. Здесь конечно не обойдется без проверки последующих отчетов, которые рассчитаны на определенный формат.
- Для добавления/изменения параметров запроса к API Я.Метрики смотрите make_request_params.
-
Конфигурация расчета вынесена в отдельный файл config.py. Обычно за запуск отвечает отдельная система запуска и мониторинга ваших скриптов. Можно посмотреть в сторону Airflow. Статья на Хабре об использовании этой системы в Mail.ru.