В DataScience проекте бардак? Как это исправить и не допускать в будущем

1. ВВЕДЕНИЕ
2. АСПЕКТЫ, СВЯЗАННЫЕ С  КОДОМ ПРОЕКТА
3. ПРОРАБОТКА/РЕВИЗИЯ ИНФРАСТРУКТУРЫ ПРОЕКТА 
4. КАК МЫ МОЖЕМ ПОМОЧЬ?
   1. ВВЕДЕНИЕ
   2. АСПЕКТЫ, СВЯЗАННЫЕ С  КОДОМ ПРОЕКТА
   3. ПРОРАБОТКА/РЕВИЗИЯ ИНФРАСТРУКТУРЫ ПРОЕКТА 
   4. КАК МЫ МОЖЕМ ПОМОЧЬ?

ВВЕДЕНИЕ

Ваш datascience проект дорос до определенного уровня и начал набирать обороты. Но вы столкнулись с тем, что релизы все больше и больше откладываются, количество багов нарастает, и команда не может с ними справиться.  Давайте разберемся, что с этим можно сделать?

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

АСПЕКТЫ, СВЯЗАННЫЕ С  КОДОМ ПРОЕКТА

Зачастую datascience специалисты мало заботятся о качестве кода и/или производительности. Подобный подход вполне оправдывает себя на исследовательской стадии, при создании MVP или когда код пишется в одиночку (без команды). Однако c развитием проекта, при расширении команды или при подготовке production кода подобный "творческий беспорядок" может приводить к проблемам.      
Справедливости ради, стоит сказать, что работа с кодом больше ориентирована на  среднесрочную и долгосрочную перспективу, т.к. объем работ обычно велик и результаты трудно получить за неделю-две. Но тем не менее если этим не начать заниматься планово, проект может стать неуправляемым.

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

1. ДОВЕДЕНИЕ DATASCIENCE КОДА ДО PRODUCTION-QUALITY СОСТОЯНИЯ 
   ***КАК ПРАВИЛО DATASCIENCE СПЕЦИАЛИСТЫ ЭТО В ПЕРВУЮ ОЧЕРЕДЬ НАУЧНЫЕ РАБОТНИКИ, А НЕ PYTHON РАЗРАБОТЧИКИ. ТАКЖЕ ОНИ РЕЖЕ РАБОТАЮТ В БОЛЬШИХ КОМАНДАХ, КОГДА КАЧЕСТВУ КОДА УДЕЛЯЕТСЯ БОЛЬШЕЕ ВНИМАНИЕ.***

• использование осмысленных имен для переменных и функций
• использование ООП (например наследование от базовых классов)
• следование DRY принципу
• обработка исключений
• запуск python скриптов с параметрами из командной строки
• аннотация типов данных
• документирование функций и комментирование кода
• сверка кода с общепринятыми стандартами (PEP-8) с помощью линтеров и форматтеров кода

2. ТЕСТЫ 
   ***РЕДКИЙ ГОСТЬ В DATASCIENCE КОДЕ. РОЛЬ ТЕСТОВ ВОЗРАСТАЕТ В ДОЛГОСРОЧНОЙ ПЕРСПЕКТИВЕ, А ТАКЖЕ ПРИ СОЗДАНИИ СЛОЖНЫХ СИСТЕМ.***

• использование возможностей тест-фреймворков (pytest, unittest)
• использования coverage для отслеживания уровня покрытия кода тестами

3. ОПТИМИЗАЦИЯ ПРОИЗВОДИТЕЛЬНОСТИ 
   ***ПРИ ПЕРЕНОСЕ КОДА НА СЕРВЕР, МОГУТ ВОЗНИКНУТЬ ПРОБЛЕМЫ С ПРОИЗВОДИТЕЛЬНОСТЬЮ, КОТОРЫХ НЕ БЫЛО ПРИ ЛОКАЛЬНОЙ РАЗРАБОТКЕ.***

• профилирование кода (memory profiling + cpu profiling)
• оптимизация python кода (лучшие практики для numpy, scipy, pandas)
• оптимизация AI/ML/DeepLearning компонентов (миграция на более современные библиотеки)
• использование Intel Math Kernel Library (MKL) библиотек

4. ВЫЧИСЛЕНИЯ НА GPU 
   ***GPU ИСПОЛЬЗУЮТСЯ ДЛЯ УСКОРЕНИЯ ВЫЧИСЛЕНИЙ.***

• решение сопутствующих проблем с управлением памятью (особенно при использовании tensorflow)

5. СОЗДАНИЕ PYTHON БИБЛИОТЕКИ НА БАЗЕ КОДА 
   ***ЧАСТО ВОЗНИКАЕТ СИТУАЦИЯ, КОГДА ОДИН И ТОТ ЖЕ DATASCIENCE КОД НУЖEН В РАЗНЫХ ПРОЕКТАХ ЗАКАЗЧИКА, Т.Е. ЧТОБЫ КОД МОЖНО БЫЛО ПРОСТО ИМПОРТИРОВАТЬ.***

• создание элементов библиотеки (pyproject.toml, requirements.txt, etc.)
• публикация и установка из каталога или установка из репозитория с кодом

6. ИНТЕГРАЦИЯ С CLOUD СЕРВИСАМИ 
   ***МНОГИЕ PRODUCTION РЕШЕНИЯ БАЗИРУЮТСЯ НА ИСПОЛЬЗОВАНИИ CLOUD СЕРВИСОВ.***

• загрузка/скачивание файлов в/из AWS S3 или Google Drive прямо из кода

7. ВЗАИМОДЕЙСТВИЕ С DEVOPS КОМАНДОЙ (GIT/JENKINS/DOCKER) 
   ***ПРИ ИНТЕГРАЦИИ JENKINS/SONARQUBE, ПРИ СОЗДАНИИ DOCKERFILE, ПРИ НАСТРОЙКЕ МИКРОСЕРВИСОВ ПРАКТИЧЕСКИ ВСЕГДА НЕОБХОДИМО УЧАСТИЕ РАЗРАБОТЧИКА.***

• настройка GitHub/GitLab checks
• создание Dockerfile/Jenkinsfile
• формирование политики версионирования

Пример 1

В проекте нужно было максимально уменьшить время между отправкой текста сообщения до начала аудио стриминга этого сообщения (Text-to-Speech (TTS) процесс). Оптимизация python кода, распараллеливание процесса дало хороший эффект, однако этого все равно было недостаточно. На выручку пришли MKL библиотеки, когда без изменения кода, время TTS процесса уменьшилось на треть, а производительность отдельных матричных вычислений улучшилась на 60-80%.

ПРОРАБОТКА/РЕВИЗИЯ ИНФРАСТРУКТУРЫ ПРОЕКТА 

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

На наш взляд при аудите инфраструктуры необходимо обращать внимание на следующие моменты:

1. НЕОБХОДИМОСТЬ ПРОГНОЗИРОВАНИЯ ЗАГРУЗКИ ИНФРАСТРУКТУРЫ 
   ***РАНО ИЛИ ПОЗДНО ЛЮБОМУ РАСТУЩЕМУ СЕРВИСУ ПРИХОДИТСЯ ОЦЕНИВАТЬ СВОИ ТЕХНИЧЕСКИЕ ВОЗМОЖНОСТИ.  В ПЕРВУЮ ОЧЕРЕДЬ ЭТО КАСАЕТСЯ САМЫХ КРУПНЫХ И ДОРОГИХ В МАСШТАБИРОВАНИИ СЕРВИСОВ.***

• проведение нагрузочного тестирования
• использование CDN для снятия нагрузки

2. ЕСЛИ ПРОГНОЗИРУЕМЫЕ РАСХОДЫ НА ХОСТИНГ ПРЕВЫШАЮТ $100 000 В ГОД, ОБЯЗАТЕЛЬНО НЕОБХОДИМ ГЛУБОКИЙ АНАЛИЗ РЕЖИМОВ ИСПОЛЬЗОВАНИЯ ИНФРАСТРУКТУРЫ 
   ***РАЗНОГО РОДА ЛИМИТЫ МОГУТ РАЗДРАЖАТЬ ВАС, НО В ПЕРИОД ЭКОНОМИИ СПАСУТ ОТ СЛУЧАЙНОГО ПЕРЕПОТРЕБЛЕНИЯ И НЕЗАПЛАНИРОВАННЫХ ТРАТ.***

• более скромная конфигурация
• квоты на ресурсы (верхний порог потребления ресурсов)
• тонкая настройка конкретных сервисов (баз данных, брокеров сообщений, поисковых движков, и т.д.)
• более сложные решения с участием DevOps инженеров (например внедрение расписание операций с данными с учетом нагрузки)

3. ПРАВИЛЬНЫЙ ПОДХОД К МАШТАБИРОВАНИЮ 
   ***НУЖЕМ ЛИ ВАМ СЕЙЧАС AWS, GCE ИЛИ ДРУГОЙ ОБЛАЧНЫЙ ПРОВАЙДЕР? ДА, МОДНО, МОЛОДЕЖНО, МАШТАБИРУЕМО, НО СТОИТ В 10 РАЗ РЕШЕНИЙ НАПРИМЕР НА БАЗЕ ХОСТИНГА HETZNER.COM.***

• оценка потенциального трафика (анализ всплесков активности в прошлом и прогнозирование их в будущем)
• eсли ваша нагрузка предполагает 5000 одновременных пользователей, может стоит выбрать провайдера подешевле (при этом подготовив в случае успеха проекта быстрый переход на масштабируемое решение)

4. АУДИТ БЕЗОПАСНОСТИ ИНФРАСТРУКТУРЫ 
   ***ЭТО МОЖЕТ БЫТЬ СМЕШНО, НО ПАРОЛИ В ДУХЕ “123456” ИЛИ “ADMIN” ВСЕ ЕЩЁ ИСПОЛЬЗУЮТСЯ, ЗНАЧИТЕЛЬНО СНИЖАЯ БЕЗОПАСНОСТЬ.***

• резервное копирование (частота и правила)
• пароли и ключи доступа
• аптайм сервера
• физическая безопасность серверов в дата центрах и гарантии хостинга на случай чрезвычайных происшествий

5. АУДИТ ПЕРЕНОСИМОСТИ ИНФРАСТРУКТУРЫ 
   ***ДА, ВСЕ ЛЮБЯТ МОДНЫЕ ШТУЧКИ. ПРОГРАМИСТЫ, АНАЛИТИКИ НЕ ИСКЛЮЧЕНИЕ. НО ЗАДУМЫВАЛИСЬ ЛИ ВЫ О ТОМ, ЧТО БУДЕТ С ВАШИМ ПРОЕКТОМ НАПРИМЕР НА BIG QUERY, ЕСЛИ ВЫ ПОПАДЕТЕ ПОД САНКЦИИ? ИЛИ ЧТО МЕШАЕТ КЛАУД ПРОВАЙДЕРАМ В УСЛОВИЯХ ДЕФИЦИТА ЭЛЕКТРОНИКИ ПОДНЯТЬ ЦЕННИК НА ХОСТИНГ В 10 РАЗ? ТАКИЕ РИСКИ ТОЖЕ БЫЛО БЫ НЕПЛОХО УЧЕСТЬ.***

• альтернативой западным облачным сервисам может быть например sbercloud

6. СОЗДАНИЕ СИСТЕМЫ МОНИТОРИНГА 
   ***ЭФФЕКТИВНАЯ СИСТЕМА МОНИТОРИНГА ПОЗВОЛЯЕТ ОПЕРАТИВНО ВЫЯВЛЯТЬ СБОИ В РАБОТЕ СЕРВЕРОВ.***

• мониторинг серверов и сетей (при необходимости использование собственных метрик, а также конфигурация с учетом geo-распределенной инфраструктуры) с помощью prometheus и/или zabbix
• мониторинг ошибок в коде (sentry отлично подходит для python проектов) 
   

Пример 2

На проекте внезапно обнаружилось, что для поддержки инфраструктуры необходим значительный процент выделяемых средств. В целях экономии всерьез рассматривался вариант уменьшения команды разработчиков. Однако, проект в том момент еще не вышел на пиковую нагрузку, и выход был найден в переходе на услуги более дешевого cloud провайдера (пусть и в ущерб масштабируемости). Таким образом было выиграно время, за которое полная команда разработчиков смогла найти способ более рационального подхода к хостингу инфраструктуры.

ОРГАНИЗАЦИОННЫЕ РЕШЕНИЯ

Очень важный момент, но мы оставим это темой для следующей статьи.

КАК МЫ МОЖЕМ ПОМОЧЬ?

Вы хотите, чтобы ваш datascience проект был лучше? Наша команда уверена, что поможет навести порядок на вашем проекте: подготовить код к продакшн и оптимизировать расходы на инфраструктуру! Среди вариантов сотрудничества могут быть как предоставление отдельных специалистов для присоединения к проекту на продолжительное время, так и разовый аудит. Также возможно предоставление команды специалистов.

Приблизительный алгоритм наших действий в зависимости от нужд заказчика может включать:

1. Подписание NDA
2. Предварительный аудит кода (3ч времени разработчика, бесплатно) для оценки предполагаемых дальнейших временных затрат
3. Аудит кода (40 - 80ч времени senior разработчика)
4. Аудит инфраструктуры (20 - 40ч времени System Architecht + DevOps engineer)
5. Подготовка плана мероприятий, направленных на улучшение состояния проекта (10 - 20ч)
6. Реализация плана

От вас понадобится обеспечить доступ к коду и инфраструктуре проекта, а также предоставить данные по нагрузке.

Автор статьи: Павел Д. Технический директор (CTO) 54origins

Есть вопрос? Задавайте! Если Вам нужна помощь в организации работы на Data Science проекте, Вы можете получить бесплатную консультацию нашего CTO   ПОЛУЧИТЬ КОНСУЛЬТАЦИЮ

Также читайте: 

• Распознавание лиц с помощью Python и OpenCV
• Тестирование проекта в Python стэке