Установление стандартов для высокопроизводительных команд специалистов по обработке и анализу данных
Наука о данных — это область, которая сочетает в себе традиционную математику и статистику с мощью крупномасштабных вычислений и более современных методов машинного и глубокого обучения для получения информации из данных.
Дисциплина науки о данных сложна, экспериментальна по своей природе и подвержена большой степени неопределенности. Как и в случае со смежными областями, такими как разработка программного обеспечения, команде специалистов по данным необходимо контролировать разработку кода. Однако в дополнение к этому специалистам по данным также необходимо обрабатывать данные, которые подвержены постоянным изменениям, и проводить повторяемые эксперименты, такие как тестирование новых функций для модели машинного обучения.
Поэтому очень важно, независимо от того, являетесь ли вы командой, состоящей из одного специалиста по данным, работающей в одиночку, или большой командой, работающей вместе, вы разработали набор лучших практик. Эти стандарты гарантируют, что:
- Один специалист по обработке и анализу данных может позже воспроизвести свои собственные эксперименты, модели или идеи.
- Другие специалисты по обработке и анализу данных в команде могут воспроизвести все вышеперечисленное — это особенно важно, если вы поддерживаете рабочие модели.
- И один специалист по обработке данных, и другие члены команды могут опираться на существующую работу и не повторять одни и те же эксперименты, код, модели или анализ.
В следующей статье я дам довольно самоуверенное мнение о том, как и что использовать, чтобы установить лучшие практики для вашей команды по науке о данных. Каждая команда уникальна, поэтому вы можете адаптировать некоторые или все эти советы для удовлетворения конкретных потребностей вашей собственной команды.
Это второй пост в моей серии статей о лидерстве в науке о данных. Первая статья находится по ссылке ниже.
Учитесь быть лидером в области науки о данных
1. Стандарты кода
Высококачественный код гарантирует, что код, который пишет ваша команда, будет легко читать и понимать другим. Это помогает повысить воспроизводимость и расширяемость работы, которую выполняет команда.
Код должен быть чистым, хорошо структурированным и как можно более модульным. Рекомендуется выбрать общий стандарт кодирования. Если ваша команда работает с Python, Руководство по стилю Google Python может быть хорошим стандартом для принятия. Стили кодирования можно легко реализовать с помощью линтинга с использованием таких инструментов, как Pylint или Black, в качестве стандартной части процесса разработки.
Хороший стандарт кода должен включать стандартизированные соглашения об именах и использование строк документации для документации кода. Цель установления этих стандартов всегда должна состоять в том, чтобы сделать код как можно более читабельным и понятным, а также уменьшить умственную нагрузку на команду. Хороший стандарт кодирования сделает команду более эффективной, например, выполнение экспертной проверки кода становится быстрее, если код всегда соответствует ожидаемому стилю.
Стандарты кода можно автоматизировать с помощью проверок непрерывной интеграции (CI) в рамках рабочего процесса GitHub.
2. Виртуальные среды
Важнейшей частью воспроизводимости кода является встраивание процессов, позволяющих запускать код, написанный членом команды, на любом другом компьютере или в облачной среде.
Виртуальные среды являются распространенным методом для достижения этой цели. Виртуальные среды записывают сведения, связанные с зависимостями (инструментами) и их версиями, необходимыми для запуска определенного проекта.
Общие инструменты для создания виртуальных сред включают Poetry, Pipenv и Conda. Хотя они работают немного по-разному, на высоком уровне виртуальные среды работают, создавая и поддерживая файл, в котором хранится версия Python и все зависимости для проекта, а затем используя этот файл для создания изолированной среды на любой машине.
Если команды не могут воспроизвести точно такую же среду на разных машинах, велика вероятность того, что в отсутствие исходного создателя проекта код проекта не сможет работать без определенных усилий.
Как правило, для каждого проекта рекомендуется иметь собственную виртуальную среду. Я бы порекомендовал выбрать один инструмент для использования во всей команде для обеспечения единообразия и облегчения воспроизводства сред для всех членов команды. Например, моя собственная команда в настоящее время использует Poetry для управления средами во всех наших проектах.
3. Контроль версий
Все команды специалистов по данным должны использовать инструмент контроля версий, такой как Github, чтобы гарантировать, что копия всей работы надежно хранится за пределами вашего ноутбука и что изменения могут быть внесены в существующий код контролируемым образом.
Как правило, хорошей идеей является создание процесса запроса на вытягивание (PR), чтобы способствовать совместной работе, обеспечивать качество результатов и делиться знаниями. На мой взгляд, PR следует регулярно поднимать на протяжении всего жизненного цикла проекта, а очень больших PR следует избегать, насколько это возможно. Хорошей практикой является получение второго мнения о вашем коде и направлении проекта как можно чаще, чтобы избежать больших переписываний или ошибок.
В целом, при использовании Github следует применять следующие стандарты:
- Имейте стандартизированное соглашение об именах для филиалов.
- Поощряйте использование четких и описательных сообщений коммитов.
- Установите стандарт хорошего пиар-этикета.
- Ежедневно коммитить код.
- Повышайте PR как минимум в конце каждого двухнедельного периода или в конце каждого спринта, если ваша команда работает в спринтах.
4. Организованный код
Единая структура папок для всех проектов в вашей команде облегчит другим членам команды быстрое чтение и понимание кода любого проекта.
В Интернете есть много примеров предлагаемых структур папок для науки о данных. Наверное, лучшее, что я нашел, это шаблон Cookiecutter. Однако, по моему опыту, структура папок сильно различается в разных командах по науке о данных, поскольку конкретные используемые инструменты, методы и задачи сильно влияют на требования к стандартной структуре. Поэтому мой совет — использовать что-то вроде Cookiecutter, но адаптировать его под нужды вашей команды.
Я большой сторонник принципа дизайна KISS («будь проще, глупее») от Software Engineering и лично выберу самую простую структуру папок, которая соответствует потребностям команды. Структура папок моей команды для разработки показана ниже. Здесь вы можете видеть, что мы выбрали простую структуру, которая соответствует нашим очень конкретным потребностям, но она не обязательно будет соответствовать потребностям другой команды.
5. Документация
Надлежащая практика документирования — это еще один способ обеспечить воспроизводимость и повторяемость работы вашей команды. Документация должна быть записана стандартным способом и должна быть достаточно тщательной, чтобы гарантировать, что кто-то, не знакомый с проектом, сможет понять достаточно, чтобы запустить любой код, а также воспроизвести и понять любые результаты.
В целом, я бы включил следующие типы документации в список лучших практик для команды специалистов по обработке и анализу данных.
Документация по коду. Весь код должен сопровождаться минимальным объемом документации, необходимой для его понимания и запуска. Сюда входит добавление строк документа к функциям, включая файл README.md в папке проекта или репозитории, а также добавление аннотаций к коду, хранящемуся в Jupyter Notebooks.
Документация по продукту. Документация по продукту относится к информации, связанной с разработкой, дизайном и результатами проекта. Обычно эта документация может иметь форму документов Google, страниц Confluence или досок Miro. Конечными пользователями этого типа документации часто являются не технические заинтересованные лица и менеджеры по продукту.
6. Организованные тетради
Природа Jupyter Notebooks может легко привести к беспорядочному, трудночитаемому и невоспроизводимому коду. Поэтому при работе в блокнотах важно использовать те же рекомендации, которые уже изложены в этой статье, такие как контроль версий и стиль кода хорошего качества. Тем не менее, также важно добавить некоторые дополнительные рекомендации, относящиеся конкретно к использованию ноутбуков.
Вот список хороших стандартов, которые следует включить в передовой опыт записной книжки.
- Воспользуйтесь широкими возможностями аннотирования кода в своем блокноте, включая заголовки, заголовки разделов, примечания, изображения и диаграммы, чтобы сделать код и результаты максимально понятными.
- Включите все импортированные данные в одну ячейку в верхней части записной книжки.
- Убедитесь, что источник любых используемых данных является явным. Это может означать включение ссылок на сегменты облачного хранилища или запросы SQL в записную книжку.
- Сохраняйте блокнот простым, используя как можно меньше строк кода. Там, где имеет смысл абстрагировать сложный код на функции и модули и обязательно удалить любой избыточный код.
Из-за своей сложной и экспериментальной природы наука о данных — это область, которая в значительной степени выигрывает от стандартизированных подходов и лучших практик для команд. Все перечисленные выше рекомендации предназначены для обеспечения воспроизводимости, расширяемости и повторяемости проектов вашей команды.
Кроме того, хотя передовой опыт требует некоторого времени и усилий для внедрения и соблюдения, в долгосрочной перспективе он сэкономит бесчисленное количество часов и усилий при попытках повторного запуска и понимания проектов или при повторении уже выполненной работы.
Лучшие практики, которые я перечислил выше, ни в коем случае не являются исчерпывающими, и в зависимости от типа работы и инструментов, которые использует ваша команда, ваши лучшие практики могут отличаться. Эта статья задумана как руководство по началу работы с лучшими практиками и должна вдохновить вас на то, чтобы начать определять и устанавливать собственные стандарты для вашей команды.
Я включил список полезной дополнительной литературы в конце этой статьи, если вы хотите глубже погрузиться в передовой опыт для групп специалистов по обработке и анализу данных.
Спасибо за прочтение!
Полезные ресурсы
Передовой опыт IBM в области обработки данных
