Каково будущее Data Engineer? - 6 отраслевых драйверов

В мире обработки данных [Максим Бошемин] (https://www.linkedin.com/in/maximebeauchemin/) не нуждается в представлении.

Один из первых дата-инженеров в Facebook и Airbnb, он написал и открыл исходный код чрезвычайно популярного оркестратора Apache Airflow, за которым вскоре последовал Apache Superset, инструмент исследования данных, который штурмом берет ландшафт данных. В настоящее время Максим является генеральным директором и соучредителем [Preset] (https://preset.io/).

Справедливо сказать, что Максим испытал на себе и даже разработал многие из самых эффективных технологий обработки данных за последнее десятилетие и стал пионером в этой роли благодаря своему знаменательному сообщению в блоге 2017 года [The Rise of the Data Engineer] (https:/ /medium.com/free-code-camp/the-rise-of-the-data-engineer-91be18f1e603), в котором он ведет хронику многих своих наблюдений.

Короче говоря, Максим утверждает, что для эффективного масштабирования науки о данных и аналитики командам нужен был специализированный инженер для [управления ETL] (https://hackernoon.com/how-to-design-scalable-and-maintainable-etls-bfd1664211a7), создавать конвейеры и масштабировать инфраструктуру данных. Входите, инженер данных.

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

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

На самом деле, по мнению Максима, инженер данных был «худшим местом за столом».

Итак, пять лет спустя, где мы находимся?

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

Увеличилась скорость ETL и аналитики

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

Скажем прямо, это было скучно и утомительно одновременно.

«Это бесконечное переключение контекста и огромное количество времени, которое требовалось для выполнения операций с данными, привели к выгоранию», — говорит он. «Слишком часто 5-10 минут работы в 23:30. может сэкономить вам 2-4 часа работы на следующий день — и это не всегда хорошо».

В 2021 году инженеры данных смогут очень быстро выполнять большие объемы работ благодаря вычислительной мощности BigQuery, Snowflake, Firebolt, Databricks и других технологий облачных хранилищ. Этот переход от локальных решений и решений с открытым исходным кодом к облаку и управляемому SaaS высвобождает ресурсы инженеров данных для работы над задачами, не связанными с управлением базами данных.

С другой стороны, затраты более ограничены.

«Раньше было довольно дешево работать локально, но в облаке вы должны помнить о своих вычислительных затратах», — говорит Максим. «Ресурсы эластичны, а не конечны».

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

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

Труднее достичь консенсуса по вопросам управления — и это нормально

![Фото команды Icons8 на Unsplash] (https://cdn.hackernoon.com/images/DttJtZIouwez0hRqxMq7CdRoQP83-k8a3zcj.jpeg)

В предыдущую эпоху структура группы данных была очень централизованной, а инженеры по данным и технически подкованные аналитики выступали в роли «библиотекарей» данных для всей компании. [Управление данными] (https://hackernoon.com/what-exactly-is-data-governance-yx1t3wkw) было разрозненной ролью, и дата-инженеры стали де-факто хранителями доверия к данным — нравится им это или нет.

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

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

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

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

Что подводит нас к следующему пункту…

Управление изменениями все еще остается проблемой, но правильные инструменты могут помочь

В 2017 году, когда Максим написал свою первую статью, «когда данные изменятся, это повлияет на всю компанию, но никто не будет уведомлен». Это отсутствие [управления изменениями] (https://hackernoon.com/how-to-create-an-efficient-change-management-strategy) было вызвано как техническими, так и культурными пробелами.

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

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

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

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

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

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

Данные должны быть неизменяемыми, иначе наступит хаос

![Фото Бретта Джордана на Unsplash] (https://cdn.hackernoon.com/images/DttJtZIouwez0hRqxMq7CdRoQP83-zoc3zw7.jpeg)

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

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

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

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

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

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

Итак, выбери свой яд? Задолженность по данным или хаос в конвейере данных.

Роль инженера данных разделяется

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

По словам Максима, это, наверное, хорошо. В прошлом инженер данных был «[худшим местом за столом] (https://maximebeauchemin.medium.com/the-downfall-of-the-data-engineer-5bfb701e5d6b)», ответственным за операционную работу кто-то другой с инструментами и процессами, которые не совсем соответствовали потребностям бизнеса.

Теперь появляются всевозможные новые роли, которые немного облегчают эту задачу. Например, инженер-аналитик. Придумано [Майклом Камински] (https://www.linkedin.com/in/michael-the-data-guy-kaminsky), редактором журнала [Locally Optimistic] (https://locallyoptimistic.com/), инженером-аналитиком — это роль, которая сочетает в себе инженерию данных и аналитику данных и применяет аналитический бизнес-ориентированный подход к работе с данными.

Инженер-аналитик подобен шепчущему данные, который отвечает за то, чтобы данные не жили изолированно от бизнес-аналитики и анализа.

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

Оперативный крип никуда не делся — он просто распространился

Оперативное расползание, как обсуждалось в [предыдущей статье] Максима (https://maximebeauchemin.medium.com/the-downfall-of-the-data-engineer-5bfb701e5d6b), относится к постепенному увеличению обязанностей с течением времени, и, к сожалению, это слишком обычная реальность для дата-инженеров. Хотя современные инструменты могут помочь инженерам работать более продуктивно, они не всегда делают их жизнь проще или менее обременительной. На самом деле, со временем они часто могут привести к увеличению объемов работы или технического долга.

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

Например, утверждает Максим, приоритеты инженера-аналитика не обязательно совпадают с приоритетами инженера данных.

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

В мире инженера-аналитика тоже существует операционная ползучесть.

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

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

Итак, что дальше для инженера данных?

![Фото Вирджила Каясы на Unsplash] (https://cdn.hackernoon.com/images/DttJtZIouwez0hRqxMq7CdRoQP83-t3d3zml.jpeg)

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

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

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

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

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

По крайней мере, это то, что мы видим в нашем хрустальном шаре.