Записки из промышленности

Наука о данных полного цикла (FCDS)

Ключ к масштабированию организаций, основанных на данных

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

На протяжении своей карьеры я встречал так много способов решения проблемы масштабирования, основанного на данных. Черт, я лично попробовал по крайней мере половину из них ... Я рад сообщить, что я нашел рецепт, который мне понравился, и который, как мне кажется, работает достаточно хорошо, чтобы о нем можно было рассказать.
Я Я пишу эту статью, чтобы рассказать вам об этом, о моем опыте работы с ней, о том, почему я считаю ее отличной, и некоторыми советами для читателей, которые хотели бы предпринять шаги для серьезной оценки / внедрения ее в своих организациях.
Для того, чтобы чтобы этот рецепт был воспроизводимым, он должен быть хорошо задокументирован и назван (эта статья и тот разговор).

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

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

Достижение этого решения, как философии, так и технологий, необходимых для его реализации, было совместным усилием многих коллег @Waze и @Google. Мне посчастливилось работать с такими профессиональными и целеустремленными людьми, которые помогали экспериментировать, пока это решение не было найдено.

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

Эта статья представляет мой собственный (Дэниел Маркус) набор убеждений и не имеет отношения к какой-либо конкретной организации. Таким образом, он весьма самоуверен. Я очень самоуверен в том, чем увлекаюсь, и это одно из них :)

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

Эта проблема

Определение успеха

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

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

Ожидания руководства часто несколько расплывчаты (очень удивительно…), но довольно часто звучат примерно так:

Успешное информационное [научное] подразделение должно способствовать принятию решений и трансформировать способ ведения нашего бизнеса.

Это могут быть решения на микроуровне (например, на уровне транзакции) или на макроуровне (например, на чем мы должны сосредоточить рост?). Единственное, что здесь имеет значение, это то, что они основаны на данных или, как некоторые любят говорить, «интеллектуально».

Давайте попробуем разбить это на бизнес-KPI (или OKR для нашей организации данных).
Успешное и масштабируемое подразделение по науке о данных должно оптимизировать для:

  • Влияние на бизнес - создаваемые нами артефакты (будь то модель, анализ, понимание, отчет, информационная панель, презентация) преобразуются в измеримые результаты, которые влияют на наш бизнес.
    Эти результаты могут проявляться в виде стратегии и руководство по принятию решений (часто называемое «аналитикой науки о данных») или как прямая оптимизация ключевых показателей эффективности, таких как доход с учетом улучшенной модели (например, обнаружение мошенничества, прогноз CTR).
  • Скорость - время на понимание (будь то решение, новое понимание бизнеса или готовая к производству модель машинного обучения) должно быть минимизировано. Здесь нет практического правила, это во многом зависит от характера проекта, но суть в том, что не заставляйте продукт сдерживаться при принятии решений, потому что вы медлите из-за неэффективности.
  • Качество: информирование и принятие решений - это большая ответственность. Точная и понятная информация, основанная на тщательно проверенных и чистых данных, имеет важное значение для принятия качественных решений. Нет лучшего способа подорвать доверие к вашей единице данных, чем производить идеи, заставить бизнес действовать в соответствии с ними и только после этого осознать, что ваши идеи ошибочны. Читатели с небольшим пробегом по праву могут подумать, что «это неизбежно». Это очень верно, хотя цель здесь - свести к минимуму такие случаи.
    Вы, наверное, догадались, что качество и скорость - это компромисс, которым вам нужно управлять. Поскольку вы знаете об этом, вы можете обсудить варианты со своими заинтересованными сторонами и принять обоснованные решения о том, где провести границу между ними (которая различается для каждого проекта / продукта).
    Измерение этого атрибута сложно и часто представляет собой комбинацию количественного (например, количество открытых вопросов, количество итераций продукта в заданный период времени) и качественного (например, опросы заинтересованных сторон).
  • Устойчивость - зрелая организация, основанная на данных, будет переоценивать решения, принимаемые в процессе своего роста. Поэтому крайне важно, чтобы эти решения могли быть пересмотрены с учетом новых данных, обновленных предположений, но при этом, насколько это возможно, сопоставимы с предыдущими точками принятия решений. Чтобы обеспечить такой способ работы, код (генерирующий идеи / обучающие модели машинного обучения) должен быть идеально воспроизводимым, автоматизированным (повторный запуск одним нажатием кнопки) и хорошо написанным. У устойчивых продуктов часто есть артефакты, такие как подробная документация, достаточно хорошая, чтобы новые сотрудники (или даже вы в будущем) могли вернуться, понять ее, доверять ей, настроить ее и дать новые результаты.

Важно отметить, что такой состав KPI хорошо подходит для бизнеса, управляемого данными («отрасли»). Это, конечно, не относится к чистым исследованиям и академической работе с данными (например, компромисс между скоростью и качеством находится в сильном предпочтении качества). Многие зрелые организации, работающие с данными, действительно нанимают ученых-исследователей - они в меньшей степени ориентированы на бизнес, но их исследования соответствуют бизнес-целям и в конечном итоге должны повлиять на производство. Эти исследователи могут существовать в одном и том же подразделении по науке о данных или в другом, хотя очень высокоуровневые цели бизнеса всегда заключаются в отличном продукте, росте и прибыли. Эти цели и являются движущей силой приведенного выше определения успеха подразделения по науке о данных.

Жизненный цикл науки о данных

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

  • Циклический - жизненный цикл науки о данных всегда цикличен. Работая с данными, создавая идеи / модели и проверяя их с заинтересованными сторонами / экспериментируя, вы чаще обнаруживаете новые проблемы, чем не знакомитесь с данными. Это может потребовать дополнительной очистки данных, повторения определений предположений, целей, измерений и т. Д. Поэтому этот жизненный цикл рассматривается как циклический, когда вы всегда можете вернуться к предыдущему шагу и возобновить цикл с этой точки.
  • Исследования VS Производство - цикл очень часто включает и то, и другое. Сначала вы начинаете с изучения предметной области, пробуя разные подходы и создавая прототипы. Иногда на этом этапе вы даже не знаете, выполнимо ли то, что вы пытаетесь сделать. Когда у вас будет артефакт, которым вы довольны, вы попытаетесь его «продакшенировать» - настроить и сделать его доступным для производственной инфраструктуры вашей организации, позаботьтесь о развертывании, ресурсах, масштабе, задержке, стоимости, мониторинге, оркестровке и т. Д. .
    Эти два разных шага в цикле сильно отличаются друг от друга и в традиционных организациях требуют разных функций (например, инженер VS) и реализации. Это огромная часть проблемы, которую мы здесь пытаемся решить.
  • Эксплуатация - последний этап цикла, на котором у вас уже есть развернутая производственная реализация, например модель prod ML / панель инструментов в реальном времени / отчет, отправленный руководству. На этом этапе вам необходимо убедиться, что ваша работа непрерывно работает - измеряется, отслеживается и выдает предупреждения, если что-то выходит из строя (например, перекос данных, дрейф концепции, аномалии, плохая производительность и т. Д.). Пренебрежение этой частью практически превращает вашу работу в «разовую». Хотя это хорошо для некоторых проектов, очень опасно иметь что-то в производстве / использовании для решений, которые вы не можете воспроизвести и / или настроить и исправить, если проблема позже обнаружится (в вашей работе или даже с данными, на которые вы полагаетесь). на, потому что, очевидно, вы молодцы, вы не ошибаетесь).

Я лично в некоторой степени связан с этим (ориентированным на ML) жизненным циклом науки о данных. Он описывает прототипирование как цикл сам по себе, что я считаю очень верным.

Проблемы науки о данных

Вышеупомянутый многофункциональный цикл очень сложен для создания эффективной, масштабируемой с организационной точки зрения работы с данными.
Дополнительный взгляд на эту проблему представлен в статье Google - Скрытый технический долг в системах машинного обучения (NIPS 2015). < br /> Резюмировать это на одной картинке -

Теперь поясним картину :)
Это означает, что когда специалист по данным (в данном случае реализуя модель машинного обучения - красный прямоугольник, но давайте немного обобщим) проводит свое исследование, он сосредотачивается только на сути создание понимания - например, обучение модели / измерение KPI (самое интересное!). Загвоздка в том, что, когда она хочет произвести продакшн этого фрагмента кода, появляется так много других «скрытых» блоков, которые ей теперь нужно реализовать и позаботиться о том, чтобы интегрировать его в готовую к производству систему.

TL; DR - Если специалисты по данным не тратят большую часть своего времени на то, где они приносят добавленную стоимость, - это злейший враг масштабирования организации, основанной на данных.

Проблема в том, чтобы сделать это:

  • Ухудшение скорости - оптимальное состояние означало бы, что ее исследовательский код «мгновенно производимый», а все остальные части (серые прямоугольники) предоставляются сразу же (без использования каламбура). К сожалению, это не обычный случай.
    * Время специалиста по данным - многие из вышеперечисленных проблем приводят к осознанию того, что на самом деле специалист по данным в реальной жизни не тратит большую часть своего время, когда она приносит добавленную стоимость. Вместо этого ее постоянно тянут к операционной и «производственной» (например, масштабной) работе, которой мешают передачи, и в итоге она становится менее эффективной версией себя. Если специалисты по данным не тратят большую часть своего времени на то, где они приносят добавленную стоимость, - это злейший враг масштабирования организации, основанной на данных.
  • Качество снижено из-за недостаточной фокусировки и чрезвычайной сложности.
    * Набор навыков - традиционный набор навыков в области науки о данных не включает масштабирование (разработка программного обеспечения), автоматизация и мониторинг (инженер по надежности программного обеспечения / DevOps), а иногда даже не включает сбор данных (передается другим инженерам - худшая ошибка в истории… мы вернемся к этому позже).
    Крайний случай - это исследование специалиста по данным код должен быть реализован на другом языке / техническом стеке SWE (инженером-программистом) для работы с производственным стеком. Помимо скорости, это опасно во многих отношениях! Эвристика, разные пакеты делают разные вещи, перекос в обучении и т. Д.
  • Устойчивое развитие сложно достичь и традиционно не считается важным фактором. Это, в свою очередь, вызывает желание сократить время проекта, пропуская «не связанные с данными» части, такие как автоматизация, воспроизводимость, мониторинг, полная документация и т. Д.
    * Техническое обслуживание - масштабируемые продукты, управляемые данными созданы для длительного использования, а не разового производства. Это означает, что все эти страшные серые коробки не перестанут появляться у вас после того, как вы «закончите» проект. Помните цикличность? Когда срабатывает предупреждение, производительность модели ухудшается, данные меняются или обновляется технический стек - специалист по данным возвращается к работе по обслуживанию. Чем больше серых ящиков, тем больше требуется обслуживания.
  • Влияние на бизнес - время до получения практического результата (= производства) значительно выше, чем при чистом исследовании. В зрелых организациях это может означать необходимость в непропорционально большой рабочей силе для поддержки продуктов, управляемых данными. В то же время для средней организации продукты, основанные на данных (в основном ML), обычно терпят неудачу, занимают гораздо больше времени, чем ожидалось, или дают «полусырые» / «интеллектуальные» результаты.
    * Передача данных - в значительной степени противоположны продуктивности. Не поймите меня неправильно, я не утверждаю, что я или кто-либо другой должен брать на себя все и работать без коллег. Я говорю о том, что чем больше может владеть отдельный участник, тем больше повышается производительность, в то время как оптимальным решением будет владение всем жизненным циклом продукта. Передача исследовательской работы SWE, автоматизация - SRE, а мониторинг - Ops - это серьезный удар по скорости и качеству.
    * Право собственности - когда у вас много людей, вовлеченных в разные фазы проекта, оживает очень тонкий баланс собственности. Где моя часть заканчивается, а твоя начинается? Кому принадлежит весь процесс? Конечный продукт? Артефакты? Решение принимается? Оповещения? Воспроизводимость и обновления при изменении данных или предположений?

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

Решение

А что, если бы я сказал вам, что все эти проблемы разрешимы? (или, по крайней мере, с возможностью оптимизации). Предлагаемое решение - это образ жизни полного цикла в области науки о данных, который я пропагандирую здесь. Я намеренно называю это образом жизни, поскольку он состоит из философии, культуры и технологий.

Почему ты должен мне доверять? (не следует слепо доверять всему, что вы читаете, но подумайте об этом и попробуйте, если вы думаете, что это интересно).
Это было испытано в боевых условиях и (вроде как. пока.) работает для меня и мои коллеги.
Этот подход на самом деле довольно привлекателен для специалистов по данным, поэтому убедить людей попробовать его не так уж и сложно - я обещаю вам меньше ворчливой работы и больше интересных вещей.
Это было разработан путем экспериментов. Я (лично) сделал почти все ошибки в книге. Эти ошибки действительно помогли выявить проблемы и попытаться найти решения.
Эти ошибки проявляются в следующем:

  • Проекты в области науки о данных / машинного обучения, которые так и не были реализованы
  • Проекты в области науки о данных / машинного обучения, которые ужасно провалились при выходе на рынок
  • Неэффективное (мягко говоря) сотрудничество и передача DS: SWE
  • Необходимо «перекодировать» для производства - например, перевести код Python ML на Java, поскольку это то, что используется бэкэнд-командой.
  • Непропорциональная эксплуатационная нагрузка

Если вы узнаете некоторые (или все) из вышеперечисленного, возможно, это найдет отклик у вас.

Разработка полного цикла означает, что один инженер владеет всем жизненным циклом продукта.

Хотя эта концепция может быть новой для специалистов по работе с данными, читающих это, инженеры из аудитории, возможно, уже знакомы с концепцией разработчика полного цикла.
Это довольно интересная идея.
Заимствование ее для данных наука и создание того, что мы называем наукой о данных полного цикла (FCDS), - это наше решение для масштабирования организации, занимающейся обработкой данных.

Эффективные специалисты по данным

Мы определили успех и признали проблемы. Следующим шагом будет создание нашего профиля эффективного специалиста по данным в контексте решения (FCDS), которое мы хотели бы создать.
Это будет выглядеть примерно так:

  • Сосредоточьтесь на том, что у вас получается лучше всего. В большой организации, состоящей из нескольких функций (например, инженеров, ученых, аналитиков), эффективность максимальна, когда люди сосредотачивают свое время на том, где они приносят наибольшую добавленную стоимость. В программном обеспечении это означало бы сосредоточиться на бизнес-логике, а не на шаблонах и операциях. Для специалистов по обработке данных «логическая» часть - это в основном разработка функций и манипулирование данными. Использование творческих способностей и знаний в предметной области для получения нужных данных, обдумывание функций, которые могут оказать наибольшее влияние на решение проблемы, и обеспечение их (или творческого прокси) доступности для использования. Кроме того, важно разработать правильные показатели, методы оптимизации и план экспериментов для их измерения. Любой DS согласится с тем, что сосредоточение внимания на данных (качество и богатство) и измерениях (например, оптимизация для правильной метрики), хотя и менее привлекательно, но гораздо более важно для успеха, чем сама модель. Операции не должны быть в центре внимания и не должны отнимать значительную часть времени специалистов по обработке данных (см. Раздел «Нет операций» ниже).
    Честно говоря, «обучение» моделей путем вызова `.fit` /` .transform` или даже hp -настройка с использованием модного пакета очень механична, и вы не добавляете в нее особой ценности по сравнению со свежим выпускником. Это те части, которые наиболее восприимчивы к AutoML, заменяющему работу DS (я большой поклонник) и сокращающих ваши усилия в соответствии с принципом Парето. В большинстве коммерческих (ориентированных на прибыль) организаций почти всегда применяется правило Парето, и 80% желаемых результатов за 20% затраченного времени достаточно, чтобы иметь возможность принимать решения, быстро экспериментировать и переходить к следующему проекту. . Этот факт еще более усиливается в сегодняшнем мире супер-данных, где наука о данных определяет практически каждое решение - в очереди так много проектов, что редко стоит превышать 80% для одного.
  • Независимость. Одна и та же IC разрабатывает и владеет всеми этапами от исследований до обслуживания производственного уровня. Не только это, но и той же самой микросхеме нужно сосредоточиться только на логике, а не на операциях! Звучит идеально, но безумно, правда? На самом деле, в 2021 году все будет не так безумно.
    Однако я хочу напомнить, что жизненный цикл продукта не заканчивается производством, он включает в себя работу, постоянный мониторинг и проверку, периодическую переподготовку / повторную проверку предположений и многое другое. Вы все равно должны владеть всем этим, главное - сделать их достаточно простыми, чтобы они соответствовали стандартному набору навыков DS и были почти бесплатными с точки зрения усилий.
  • No-Ops: мы сказали, что DS не должна касаться операций, но кто-то должен это сделать. Верно? Мониторинг, оркестровка, развертывание, масштабирование, управление задержками и качеством данных имеют решающее значение для надежной производственной системы. Тем не менее, для подавляющего большинства продуктов для анализа данных они выглядят очень похоже. Монитор производительности модели, непрерывная оркестровка обучения, непрерывное развертывание модели и структура проверки данных - все это легко интегрируется (и почти «копируемо») в наши дни. Это означает, что настройка их для вашего продукта должна быть вопросом простой конфигурации или, в лучшем случае, копирования / наследования существующей конфигурации. Это сделает все «бесплатным» для настройки, но как насчет обслуживания? Ключ к этой части уравнения - непрерывный. Непрерывное обучение, проверка данных, развертывание (модели и данные - хранилище функций AKA) имеют решающее значение для обеспечения работоспособности системы. Постоянно работающая система и быстрое обнаружение проблем с использованием непрерывных операций (CI / CD / CT) - вот как зрелая система данных устраняет нагрузку на обслуживание.

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

Наука о данных полного цикла

Философия

End2end - или «завершение цикла», давайте немного поговорим о том, что это означает.
Специалист по данным обычно начинает с определения / определения проблемы, обдумывания правильных измерений и функций оптимизации. . Это требует глубокого понимания бизнеса, знания предметной области и коммуникативных навыков.
Затем она занимается исследованиями, обзором литературы, экспериментами и пробует различные подходы. Для этого требуется мышление, ориентированное на исследования, творческий подход, организованная методика и твердые хакерские навыки (немного удачи никогда не помешает).
Разработка / производство включает в себя кодирование, тестирование, интеграцию с производственными системами и заботу о ресурсах. Это требует навыков программирования (очевидно, что и все остальное, но мы говорим здесь о производственном уровне), сильного манипулирования данными и понимания, а также опыта в архитектуре / дизайне.
И последнее - измерения и операции, требующие способности глубоко погружаться, объяснять и предоставлять услуги заинтересованным сторонам.
Вы можете видеть, что владение полным циклом требует всесторонних специалистов по данным с широким спектром навыков.

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

Нет, вы определенно не слишком хороши для очистки собственных данных.

Вы утверждаете, что есть кто-то более подходящий, чем вы, тот, кто строит модель и отвечает за ее производительность, чтобы выяснить, какие данные подходят для фильтрации / очистки и как? Если это так, ты можешь просто остановиться здесь и поцеловать на прощание качественно.

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

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

В большинстве организаций запуск кода в производство - это задача SWE, как будто вы сделаете это неправильно, вы можете причинить вред. Кроме того, для этого могут потребоваться всевозможные технологии SWE / SRE, такие как CI / CD, о которых специалисты по данным ничего не знают. Мышление, которое действительно настраивает вас на провал.
Использование правильных инструментов, управляемых сервисов, тестирования, стандартных процедур для продвижения кода позволяет пятилетнему ребенку продвигать код в производство с минимальным риском причинения (серьезного) вреда.
А как насчет производственных проблем? Нужно ли мне, как специалисту по данным, теперь поддерживать производственные службы, вызывающие мои модели? Нужно ли мне носить с собой пейджер (не совсем) и отвечать на производственные проблемы в полночь?
Да, есть.
Продукт принадлежит вам. (не фактический сервер / сеть, а просто сервис, который выводит прогнозы). Вы лучше всех поддерживаете это. Вы единственный, кто будет знать, как это исправить, когда ваша модель начнет выводить мусор (а это произойдет).
Честно говоря, люди склонны думать, что это страшно, но если вы все сделаете правильно (как и все остальное), это легкий ветерок. И не всегда это должен быть вы… вот почему ротации по вызову - это вещь.

Обобщая философию на картинке (источник):

Текущие отраслевые стандарты требуют, чтобы X (~ 3) человек работали над тем, чтобы довести продукт данных (например, модель машинного обучения) до производства.
FCDS обещает, что 1 независимый (полный цикл) специалист по данным сделает все в одиночку, быстрее и с лучшим качеством, уделяя больше внимания тому, где они приносят добавленную стоимость.
Кроме того, вы видите, что отраслевые DS недовольны, не так ли? Это потому, что он тратит большую часть своего времени на вещи, которые намного ближе к операциям (например, масштабирование и мониторинг), а не на вызов fit_transform (что ему действительно нравится).

Если я убедил вас до этого момента, но вы думаете про себя: «Теоретически все это круто, но нет никаких инструментов, позволяющих это сделать, и я не Google / Facebook, поэтому я не могу просто пойти и построить что-нибудь… »тогда я приготовил для вас сюрприз.

У нас есть технологии.

Технология

Мы хотим, чтобы технология позволила среднему специалисту по обработке данных замкнуть цикл продукта, сосредоточиться на логике и получить все остальное прямо из коробки.
Характеристики такой технологии:

  • Просто - понимать, использовать, работать
  • Управляемый - без серверов, без оборудования, только код
  • Настраиваемый - получайте простые вещи бесплатно, но достаточно гибкие, чтобы сойти с ума от 5%, которые потребуют выхода за рамки
  • Масштабируемость - автоматическая масштабируемая обработка данных, обучение, вывод.
  • Pythonic - даже не пробуйте что-то другое ... Нам нужно что-то готовое к производству, которое работает с большинством инструментов и кода сегодня и подходит для стандартного специалиста по данным. В наши дни практически нет других вариантов (я уже сказал, что это упрямство?).

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

В этом месте статьи стоит потратить минуту, чтобы убедиться, что вы понимаете, что «Полный цикл» (жизненный цикл продукта) ! = «Полный стек» (технический стек - например, backend и frontend)
На самом деле все наоборот! В отличие от полного стека, в полном цикле мы стремимся завершить весь жизненный цикл продукта с помощью одного стека! Стек специалистов по данным!
Python (и отличные управляемые сервисы) - это все, что вам нужно.

Выбор инструментов полностью зависит от вас, и я не пытаюсь убедить читателя в пользу одного из них. Дело не только в чистых технологиях, но и в том, что удобно вашей организации, поставщикам облачных услуг, личным предпочтениям, поддержке темного режима (очень важно) и т. Д.
Для полного раскрытия информации, я работаю в @Google, Waze, используя GCP управляемые сервисы (что мне очень нравится). Чтобы дать читателям обзор того, как может выглядеть такой стек, я очень грубо назову несколько инструментов в моем стеке FCDS (все масштабируемые и управляемые):

  • BigQuery: структурированное хранилище данных и обработка SQL
  • TFX
    * TensorFlow 2.x
    * tf.transform over Dataflow: пакетная и потоковая обработка, разработка функций встроена в модели TF, поэтому вы пишете код только один раз
    * Готовые компоненты для проверки данных, анализа модели, благословения модели (сравнение с предыдущими версиями модели) и развертывания
  • Платформа облачного искусственного интеллекта (CAIP) - ›теперь называется Vertex AI
    * CAIP Notebooks: Research & Exploration
    * CAIP Jobs: Training
    * Модели CAIP: вывод с высокой нагрузкой и малой задержкой
    * CAIP Pipelines: TFX как услуга
  • Более мелкие дополнения выходят за рамки данной статьи. Чтобы перечислить несколько: Git, Gerrit, Jenkins, Airflow через Cloud Composer

Распространенный метод, помогающий специалистам по обработке данных начать работу с новой технологией FCDS, заключается в предоставлении готовых к эксплуатации, готовых к разветвлению, протестированных полных шаблонов конвейера (от исследования данных до непрерывного обучения и развертывания). Я обнаружил, что это значительно сокращает время разработки и упрощает внедрение.

Культура

Переход на FCDS - это большое изменение в культуре организации, основанной на данных.
Не только специалисты по данным могут полагаться только на себя (возможно, преувеличение), но теперь они вносят непосредственный вклад в производство!
Почти всегда это означает, что Требуется ориентированное на инженерное дело наращивание навыков специалиста по анализу данных.
Новая культура обработки данных теперь заимствует концепции из прочной инженерной культуры.
Теперь она находит признание в ценности:

  • Качество кода - мы не создаем единичные экземпляры, мы создаем долговечные производственные системы.
    * Проверки кода
    * Модульные тесты
    * Нет записных книжек для производственного кода ( просто для прототипирования) - на эту тему написано бесчисленное количество статей. TL; DR заключается в том, что зрелый код проекта, содержащий файлы .py в организованном порядке, очень отличается от файлов .ipynb.
    Его легко повторно использовать (импортировать), тестировать, изменять, универсальный, параметризуемый, интегрируемый с другими компонентами, не зависящие от данных и т. д. В основном это направляет вас на правильный путь к устойчивости. Да, я знаю, что в области портативных компьютеров существует несколько инструментов для решения некоторых из этих проблем. Я просто скажу, что вы можете накрасить свинью помадой, но она останется свиньей.
  • Качество системы
    * Исследовательская документация и обзоры
    * Разработка документации и обзоры
    * Определение успеха
    * Дизайн KPI / измерения
    * Дизайн эксперимента

Замечания по реализации

Профиль специалиста по данным полного цикла

В науке о данных есть много разновидностей. Подход FCDS достаточно универсален, чтобы его можно было применить ко многим из них, будь то машинное обучение, замена эвристик и алгоритмов, анализ продукта или традиционная статистика. Часто ожидается, что специалист по анализу данных сбалансирует эти разные типы проектов. Более того, каждый такой домен (например, ML) может включать в себя очень разные поддомены (например, системы рекомендаций, компьютерное зрение, NLP).

Вот почему наш подход предпочитает универсалов в области науки о данных (Stitch Fix) - хорошо разносторонних людей, которые могут глубоко погрузиться в новые области и типы работы и применить свою ориентацию на данные, набор технических навыков и знания предметной области в создавать успешные продукты. Эти люди действительно существуют, я работаю с ними! (Моя роль как менеджера - дать им понять, что они на это способны, и дать небольшие советы).
Достаточно ли большая ваша организация для специалистов? (противоположность универсалов) Будьте моим гостем, но вам, вероятно, нужны специалисты-исследователи, а не специалисты по данным.
Я редко встречал специалистов в позициях, ориентированных на воздействие на производство, которые преуспели бы лучше, чем великий универсал. Честно говоря, использование готовой керас-архитектуры / модели SOTA домена - это несколько часов работы для любого универсального специалиста.

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

Мы начинаем с малого, создаем прототип, строим прочный производственный конвейер (разветвляя шаблон, готовый в считанные минуты) и реализуем наивный базовый план (не обязательно даже модель!). Мы настраиваем измерения, а затем начинаем повторять и улучшать.

Теперь я перейду к самой спорной теме :)
Мы можем разделить мир на 2 типа специалистов по данным - ориентированных на отрасль и ориентированных на академию.
FCDS с упором на влияние производства и качество кода благоприятствует первому.
Очевидно, что иметь и то и другое - это здорово, но чтобы подчеркнуть здесь важность, я собираюсь заявить, что я предпочитаю нанимать отличного, гибкого инженера с интересом и приятным ощущением данных, а не кандидат без производственного опыта / плохие навыки программирования в любое время.

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

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

Красные флажки эффективности

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

Красные флаги включают:

  • Роли (весьма самоуверенные)
    * Специалисты по обработке данных занимаются чем-то другим, кроме создания инструментов. Это ошибка №1, и я не могу достаточно подчеркнуть ее важность. Инженеры по обработке данных - инженеры по программному обеспечению, они создают программные системы, которые относятся к области данных. Помните, мы говорили, что нам нужно склеить кучу разных инструментов, чтобы все работало на средней DS? Приспосабливайтесь к потребностям нашей организации, настраивайте надежные конвейеры CI / CD и т. Д. - все это есть инженерия данных.
    Создание конвейеров данных и информационных панелей (ETL / BI) - это роль специалиста по данным. Это важная часть цикла! Передача его кому-то другому означает, что мы не выполняем полный цикл. Если вы считаете, что некоторые ETL слишком сложны для DS, вы не используете правильные инструменты или не нанимаете подходящих специалистов по данным.
    Подробнее на эту тему в разделе Инженеры не должны писать ETL ( Stitch Fix)
    * У вас роль инженера ETL / BI. Как и выше, это означает, что ваши DS не выполняют полный цикл.
    * У вас роль инженера машинного обучения. Если вам нужен инженер для внедрения кода машинного обучения в производство, тогда ваши DS не выполняют полный цикл.
    * Вам нужна помощь SRE / Devops, чтобы продвигать код DS в производство.
  • Решение проблем
    * Проблемы с данными / моделями, обнаруженные пользователями, а не предупреждениями
    * Откат к предыдущей версии модели недоступен
    * Воспроизвести текущую производственную модель не так-то просто
    * Переобучение модели - ручное
  • Повторная реализация
    * DS необходимо заново реализовать свою собственную работу между исследованиями и производством
    * DS передает исследовательский код (разработка моделей / функций и т. Д.) Для SWE для перекодирования в производственный стек
  • Несовпадение
    * Данные, используемые для анализа / обучения (в автономном режиме), не совпадают с данными, используемыми для производства / вывода (онлайн).
    * В коде разработки функций используются эвристические методы / прокси-серверы для компенсации незарегистрированных данных

Сроки

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

Ответ положительный.

  • Небольшой стартап, создающий организацию данных? начните таким образом - вам все равно придется это делать, так как для вас очень дорого нанимать специалистов, а не универсалов, которые могут все это сделать. Вам просто нужно инвестировать в правильные инструменты, чтобы облегчить их жизнь.
  • Большая корпорация? Это самое сложное, поскольку культура уже существует и людям нравится то, что они делают. Но именно здесь вы увидите наибольшее влияние на скорость, качество и бизнес в целом.
  • Где-то посередине? Начните экспериментировать с этим подходом, пока вы не стали слишком большими, чтобы затруднить изменение культуры. Экспериментируйте, переходите медленно, сначала только некоторые проекты, инвестируйте в технологии (все равно это пойдет вам на пользу). Начните стирать границы между различными функциями, пусть DS медленно откусывает куски из DE / SWE / SRE, пока вы не сможете закрыть цикл.

Резюме

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

Такой подход должен создать успешную организацию данных, которая максимизирует

  • Скорость
    * DS может сосредоточиться на творческой стороне
    * Компоненты многократного использования и готовые шаблоны для производства, которые можно скопировать и вставить
  • Качество
    * DS очищает собственные данные
    * Готовые к работе средства проверки и мониторинга данных
  • Устойчивость
    * Автоматизация
    * Воспроизводимость
    * Масштабируемость
  • Влияние на бизнес
    * Время до практических действий / анализа сводится к минимуму
    * Одна DS полностью независима
    * DS владеет производственный продукт и артефакты
    * Удовлетворение
    ** DS заботится о производстве
    ** DS чувствует их влияние

Решается ли тогда масштабирование организаций, управляемых данными? Наверное, нет.
Я начал это примерно в 2020 году, сейчас он работает достаточно хорошо, но это только до тех пор, пока мы не дойдем до следующего набора проблем.
Кроме того, некоторые инструменты, необходимые для аккуратного завершения цикла, даже не там еще ... В наши дни развертывание масштабируемых служб обучения и вывода довольно легко найти, но когда дело доходит до хранилищ функций и «развертывания данных», это все еще большой беспорядок.

Я хотел бы поблагодарить своих многочисленных коллег @Waze и @Google, занимающихся различными функциями, которые внесли значительный вклад в эти усилия, экспериментируя, проводя мозговой штурм, поднимая проблемы и всегда стремясь делать что-то лучше.

Я также хотел бы поблагодарить Алона Паломбо и Филиппа Аджимана за подробный обзор этой работы и вклад в нее.