Специалистам по данным не нужно знать Kubernetes

Специалистамподаннымненужнознатьkubernetes

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

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

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

Хотя контейнеризация – это больше или менее понятная абстракция инфраструктуры – это относительно новая категория инструментов, и многие люди до сих пор путают ее с оркестровкой рабочих процессов. Последняя часть сообщения представляет собой сравнение различных инструментов оркестровки рабочих процессов и инфраструктуры, включая Airflow, Argo, Prefect, Kubeflow и Metaflow.

Роли и обязанности:

– Автоматизация ужасных бизнес-практик

– При необходимости напишите специальный SQL

НЕОБХОДИМЫЙ ОПЫТ:

– 21 лет опыта глубокого обучения на Python

– кандидатская диссертация по байесовскому моделированию

– Опыт НЛП на 7 языках

– 15 лет создания кластеров Hadoop с нуля

– Ник Хайцман 📊📈 (@NickDoesData) Февраль 13, 83249

Requirements for data scientists in real-time
Network latency from Vermont

Два реальных описания вакансий специалиста по данным


Оглавление

…. Ожидания полного стека

…. Разделение сред разработки и производства

…. Преодоление разрыва Часть I: контейнеризация

…. Устранение разрыва. Часть II: абстракция инфраструктуры

…. Сравнение рабочего процесса и абстракции инфраструктуры

…. Организация рабочего процесса: воздушный поток против префекта против Арго

…. Абстракция инфраструктуры: Kubeflow против Metaflow


Примечания

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

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

      Ожидания полного стека

      Около года назад я написал в Твиттере о

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

      То, чему я бы уделил приоритетное внимание, если бы я снова стал учиться на инженера машинного обучения:

      1. Контроль версий

      2. SQL + NoSQL

      3. Python

      4. Панды / Даск

      5. Структуры данных

      6. Prob & stats

      7. Алгоритмы ML

      8. Параллельные вычисления

      9. REST API

      15. Kubernetes + Airflow

      15. Модульные / интеграционные тесты

      – Chip Huyen (@chipro) Октябрь 16, 83249

      Твит, кажется, находит отклик у моей аудитории. После этого Юджин Ян написал мне, что он также написал о том, как Специалисты по обработке данных должны быть более сквозными . Эрик Колсон, главный специалист по алгоритмам Stitch Fix (который ранее был также вице-президентом по науке и разработке данных в Netflix), написал сообщение на тему « мощь универсального специалиста по науке о данных с полным стеком и опасности разделения труда через функции . »

      Когда я писал этот твит, я считал, что Kubernetes необходим для рабочего процесса DS / ML. Это чувство возникло из-за разочарования на моей собственной работе – моя жизнь в качестве инженера машинного обучения была бы намного проще, если бы я более свободно владел K8.

      Однако, поскольку я Узнав больше о низкоуровневой инфраструктуре, я понял, насколько неразумно ожидать, что специалисты по данным узнают об этом. Инфраструктура требует совсем другого набора навыков, чем наука о данных. Теоретически вы можете изучить оба набора навыков. На практике, чем больше времени вы тратите на одно, тем меньше времени вы тратите на другое. Мне нравится аналогия Эрика Бернхардссона о том, что ожидание специалисты по обработке данных знать об инфраструктуре – все равно что ожидать, что разработчики приложений знают, как работают ядра Linux . Я стал специалистом по данным, потому что хотел проводить больше времени с данными, а не с развертыванием экземпляров AWS, написанием файлов Docker, планированием / масштабированием кластеров или отладкой файлов конфигурации YAML.

      Data science infrastructure is a leaky abstraction Разделение разработки и производственная среда

      Так откуда же это необоснованное ожидание?

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

      Разработка

      Производство

      Шкала
      • Обычно только один экземпляр (или один компьютер)
        1. Не нужно беспокоиться об автомасштабировании

        Несколько экземпляров / узлы

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

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

      1. Необходимо выяснить, как сохранить данные / состояние при изменении экземпляров
      Состояние