Или: Как сделать бег Кесселя менее чем за 12 парсеков

Обзор

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

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

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

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

Подводные камни прошлого: почему мы потерпели неудачу

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

Ошибка 1: группы данных становятся разрозненными

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

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

В небольших современных командах по обработке данных довольно часто можно услышать фразу «все делают все». Недавно я разговаривал с клиентом, который напомнил мне: «Мы не можем позволить себе роскошь перебрасывать вещи через забор или ждать, пока нам их доставят. Если ты хочешь, чтобы что-то было сделано, ты должен сделать это сам».

Ошибка 2: группы данных создают свои собственные (разрозненные) процессы обработки данных и инструменты

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

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

Распространенным результатом является то, что мы называем конвейерными джунглями. Мы все их видели: архитектурные или технологические диаграммы, содержащие десятки узлов и, возможно, сотни соединений. Понимает ли хоть один человек всю систему от корки до корки? Возможно нет. Да начнется поиск виноватых!

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

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

Также важно помнить о конечном потребителе всей работы с данными. Группа данных в основном занимается системой данных. Обычно он не чувствует всей силы пропущенных SLA, неправильных выводов, разрозненных вариантов использования и т. д. И нередко бизнес-ориентированные команды соответственно скептически или недоверчиво относятся к команде данных. Я считаю, что большая часть этой осторожности проистекает из неэффективных процессов обработки данных, которые создают историю ненадежности данных. Оптимизируя продукт и повышая надежность команды обработки данных, компании могут научиться любить данные и взаимодействовать с ними так, как никогда раньше.

Ошибка 3: операционализация рабочих процессов машинного обучения чрезвычайно сложна (в лучшем случае)

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

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

Несмотря на то, что нет недостатка в инструментах машинного обучения, помогающих в любой конкретной части рабочего процесса машинного обучения, большинство из них оказались неэффективными. Как мудро выразилась Сара Катандзаро: Инструменты [ML] — дерьмо… Они не были созданы с учетом эргономики разработчика. Чего очень не хватает экосистеме машинного обучения, так это инструментов, которые определяют, как должно выполняться промышленное машинное обучение. Инструменты стремятся быть как можно более привлекательными и гибкими, но это создает экосистему инструментов с одноразовой функциональностью и отсутствием проторенного пути к операционализации вариантов использования ML. Таким образом, сложность рабочего процесса перекладывается на пользователей, которые тонут в технических долгах.

Там должен быть лучший путь.

Путь вперед

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

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

Ниже мы изложим методологию построения такой системы.

Шаг 1: Согласуйте группу обработки данных с производственным процессом

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

В предыдущей статье мы говорили о преимуществах использования лучших практик разработки программного обеспечения при создании команды специалистов по данным. На самом деле, не только группа специалистов по данным должна усвоить и использовать эти советы, а вся команда по обработке данных. Если вся команда не согласна, мы начинаем попадать в ловушки прошлого и оказываемся в джунглях конвейера. Здесь работает не один подход, но успешные группы данных часто используют ориентированный на git подход к данным, когда производственные среды автоматизированы с помощью систем CI/CD, а основное внимание уделяется созданию декларативной системы, в которой все версии и легко отслеживаются и обслуживаются. Работа по разработке может быть (и, скорее всего, будет) беспорядочной и сложной, но производственный процесс должен быть таким, чтобы все шероховатости были сглажены, прежде чем приступить к нему, и это была приятная скучная последовательность автоматизированных шагов, прежде чем выводится окончательный результат. Мы считаем, что этот подход, который также отстаивает dbt, должен лежать в основе процесса обработки данных в компании.

И еще раз повторюсь: это должно применяться ко всем командам. Саймон Спети недавно написал отличную статью, в которой рассказывается о последних тенденциях в оркестровке данных, включая переход к декларативным конвейерам, в том числе последней миле самого оркестратора данных, являющегося декларативным. Однако этот подход действительно оптимизирован только в том случае, если все шаги конвейера являются декларативными. Внедрение неоптимальных шагов в процесс обработки данных — это прямой путь к катастрофе, поскольку рабочий процесс данных хорош настолько, насколько хорош его самое слабое звено. Например, существует много способов, с помощью которых мы можем преодолеть разрыв между аналитикой и машинным обучением, но многие из них основаны на специальных процессах, которые развалятся под давлением производства, таких как блокноты Jupyter и произвольные скрипты Python. За свою карьеру я видел, как многие компании выстраивают звездный план в отношении инженерии и анализа данных, но затем испытывают трудности с машинным обучением, потому что специалисты по данным прибегают к неточным процессам, которые не подходят для производства. Переключение между аналитикой и машинным обучением часто сопряжено с опасностью именно потому, что рабочий процесс не продуман целостно.

Наконец, за последние пару лет было много дискуссий о данных как продукте или командах данных как продуктовых командах, и любой, кто верит в это утверждение, несомненно, должен рассматривать это как следствие. Было бы довольно нелепо разрабатывать продукты, не обращая внимания на то, как отдельные компоненты взаимодействуют, интегрируются и обеспечивают результаты — и точно так же это относится к команде данных. Объединив команды обработки данных в единый производственный процесс, мы обеспечиваем беспрепятственное получение результатов и настраиваем команду — и бизнес — на успех.

Шаг 2. Координируйте работу группы данных по инструментам

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

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

  • Объедините все команды на одной платформе данных. Это может показаться очевидным, но наличие разных платформ для разных групп в команде данных сделает любой производственный процесс в несколько раз более сложным с самого начала. Важно, чтобы все работали на одной платформе, чтобы переходы между командами были максимально плавными. Вы можете разбить несколько сердец в процессе, но в результате рост производительности того стоит.
  • Избегайте инструментов, которые не вписываются в ваш производственный процесс. Это, вероятно, добавит сложности и технического долга, поскольку пользователи будут использовать их для вариантов использования.
  • Избегайте инструментов, которые не соответствуют методологии вашей компании. Например, если ваша компания принялаориентированный на git подход к данным, при котором производственные среды автоматизированы системами CI/CD через декларативную систему, в которой все управляется версиями, избегайте инструментов, которые: а) не хорошо интегрируются с git, б) не являются декларативными, в) не связаны с системами CI/CD, г) не автоматизированы или д) плохо управляют версиями ресурсов.
  • Избегайте инструментов с неуклюжей интеграцией. Создание собственных интеграций — это очень 2010-е, и поддерживать текущие версии — это кошмар.
  • Избегайте дублирования инструментов. Например: использование инструмента ELT для преобразования данных и платформы ML, которая включает инструмент подготовки данных, менее идеальна, чем инструмент ELT и платформа ML без инструмента подготовки данных. «Но разве больше не всегда лучше?» Не всегда. Перекрывающиеся инструменты часто будут немного (или сильно) спорить друг с другом и иметь более слабую интеграцию, чем те, которые имеют четкие границы. Пользователи оплачивают разницу. Кроме того, наличие нескольких способов сделать что-то просто создает дополнительные несоответствия в ваших процессах обработки данных.
  • Для пользователей современных стеков данных избегайте инструментов, не соответствующих современному стеку данных. Одним из больших преимуществ внедрения современного стека данных является сумасшедшая синергия, получаемая при каждом последующем добавлении в стек. Отклонение от известного пути, скорее всего, приведет к негативным последствиям.

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

  • Совместный магазин функций
  • Декларативный движок ИИ
  • Постоянные MLOps

К счастью, мы в Континуале строим такую ​​платформу!

Шаг 3. Проверка работоспособности рабочего процесса от разработки до производства

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

Надеюсь, это должно встать на свои места, если шаги 1 и 2 выше выполнены правильно. Если мы приняли ориентированный на git подход к данным, когда производственные среды автоматизированы системами CI/CD через декларативную систему, где все управляется версиями, то этот шаг, скорее всего, будет таким же простым, как создание декларативных входных данных. и создание запроса на вытягивание с изменениями в рабочей среде. И мы закончили.

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

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

Шаг 4. Позвольте строителям строить

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

Оперативный ИИ предписывает мировоззрение, в котором производственные процессы должны быть в значительной степени автоматизированы и предсказуемы. Если мы можем вернуться к нашему сравнению с программной инженерией, то это похоже на то, как системы CI/CD автоматизируют большую часть компиляции, тестирования и развертывания производственного кода, позволяя инженерам сосредоточить почти все свои усилия на разработке нового кода (и , конечно же, исправляя иногда неудачный интеграционный тест). Инженеры-программисты не просто создают код из предварительно написанных блоков существующего кода, и, соответственно, работающая система ИИ не полагается исключительно на заранее подготовленные функции и модели. Рабочий процесс производственного машинного обучения будет извлекать данные из хранилища функций, строить модели на основе последних данных, выполнять анализ данных и модели и развертывать модели в соответствии с заранее определенной политикой. Все, что происходит во время выполнения, уже должно определяться декларативным характером системы, но также ожидается, что специалисты по данным смогут вносить в этот процесс свои собственные настройки. Например, продвинутые специалисты по данным могут создавать свои собственные модели. Эти модели можно зарегистрировать в системе и объявить частью рабочего процесса при определении производственного процесса.

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

Кроме того, операционный ИИ позволяет легко использовать работу специалиста по обработке и анализу данных без необходимости разбираться во всех деталях того, как он реализован. Это отлично подходит для организаций, которые пытаются получить больше знаний в предметной области в рабочем процессе ML, поскольку декларативный характер системы позволяет любому, у кого есть доступ к данным и знания о них, начать создавать варианты использования ML. Не требуется никаких знаний в области машинного обучения, а также знаний в области кодирования или фреймворков машинного обучения. Пользователи могут быстро повторять функции, подключать их к любому количеству моделей и видеть результаты. Специалисты по данным также могут настраивать другие части конвейера, такие как преобразование функций, анализ модели, объяснимость и т. д., чтобы дать пользователям лучшее представление о том, насколько хорошо их использование работает, а также дать им быстрый и простой способ оценить модели, когда они вызываются в качестве эксперта. Действительно, это система, которая точно позволяет другим специалистам по данным, таким как инженеры данных и аналитики данных, выполнять рабочие процессы ML без необходимости использования инструментов ML. Мы также избежали запутанной интеграции и джунглей конвейера и можем легко и просто развертывать варианты использования ML в рабочей среде. Вот как выглядит преодоление разрыва!

Иди вперед и процветай!

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

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

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

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

Преодоление разрыва между аналитикой и ИИ в современной экосистеме стека данных

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

  1. Многие современные инструменты стека данных предоставляют декларативный интерфейс.
  2. Многие современные инструменты стека данных следуют передовым методам разработки программного обеспечения и имеют отличные рабочие процессы gitOps, которые легко обеспечивают рабочие процессы с помощью CI / CD или аналогичных.
  3. Поставщики приложили много усилий и усилий для оптимизации интеграции, чтобы вам не пришлось этого делать.

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

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

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

(Примечание: эта статья изначально появилась на Постоянном блоге)