Перевод подготовлен при поддержке сообщества аналитического курса DataLearn и телеграм-канала Инжиниринг Данных
Будущее Инженера Данных
В мире инжиниринг данных Maxime Beauchemin это тот, кто не нуждается в представлении.
Один из первых инженеров данных в Facebook и Airbnb, он разработал и написал открытый исходный код дико популярного оркестратора Apache Airflow, а вскоре после этого Apache Superset, инструмент для анализа данных. В настоящее время Максим является генеральным директором и соучредителем Preset, быстрорастущего стартапа, который предоставляет возможность для визуализации данных с поддержкой искусственного интеллекта для современных компаний.
Справедливо отметить, что Максим попробовал и даже спроектировал многие из самых эффективных технологий инжиниринг данных за последнее десятилетие и стал первопроходцем в этой роли в своем знаковом посте в блоге 2017 года, The Rise of the Data Engineer, в котором он ведет хронику многих своих наблюдений. Короче говоря, Максим утверждает, что для эффективного масштабирования аналитики и машинного обучения командам нужен был специализированный инженер для управления ETL процессами, создания пайплайнов и масштабирования инфраструктуры данных.
Несколько месяцев спустя Максим продолжил эту работу, размышляя о некоторых из самых больших проблемах инженера данных: работа была тяжелой, уважение было минимальным, а связь между их работой и фактически полученными достижениями бла очевидной, но редко признавалась. Быть инженером данных было неблагодарным занятием, но все более важным, работая с командами, создающими инфраструктуру, выполняющими задания и и выполняющими специфичные требования для аналитики и бизнес-аналитики. В результате возможность быть инженером данных являлась и благословением, и проклятьем.
Фактически, по мнению Максима, инженер данных был «худшим местом за столом».
Итак, пять лет спустя, где мы находимся?
Перед его основным докладом на IMPACT: The Data Observability Summit, я встретился с Максимом, чтобы обсудить текущее положение дел, включая децентрализацию современного стека данных, фрагментацию команд инженеров, рост влияния облачных технологий и то, как все эти факторы навсегда изменили роль инженера данных.
Скорость ETL и аналитики увеличилась
Максим вспоминает, что не так давно, когда инженеры данных выполняли Hive-джобы часами, требуя частого переключения между заданиями и управлением различными частями пайплайнов.
Если коротко, в это время было скучно и изнурительно.
«Это было бесконечное переключение между задачами и время, затрачиваемое на запуск операций с данными приводили к выгоранию», - говорит он. «Слишком часто 5-10 минут работы в 23:30 могут сэкономить 2-4 часа работы на следующий день и это не всегда хорошо».
В 2021 году инженеры данных могут очень быстро выполнять большие задания благодаря вычислительным мощностям BigQuery, Snowflake, Firebolt, Databricks и других облачных технологий. Этот переход от локальных решений и открытым исходным кодом к облаку и управляемому SaaS освобождает ресурсы для разработки данных для работы над задачами, не связанных с управлением БД.
С другой стороны затраты все более ограничены.
«Раньше было довольно дешево работать локально, но в облаке вы должны помнить о своих вычислительных расходах», - говорит Максим. «Ресурсы эластичны, а не бесконечны»
Так как инженеры данных больше не отвечают за управление вычислениями и хранилищем, их роль меняется от разработки инфраструктуры к более ориентированным на производительность элементам стека или даже специализированным ролям.
«Мы видим этот тренд на проектирование надежности данных, а инженер данных отвечает за управление (а не создание) инфраструктурой данных и контроль за производительностью облачных систем»
Труднее достичь консенсуса по управлению - и это нормально
В предыдущую эпоху структура данных была очень централизованной, при этом инженеры данных и технически подкованные аналитики были подобны «библиотекарями» для данных всей компании. Управление данными было специфичной ролью, и инженеры данных стали де-факто хранителями уровня доверия к данным, нравится им это или нет.
В настоящее время, предполагает Максим, широко признано, что управление распределено. У каждой команды есть своя аналитическая область, которой она владеет, используя децентрализованные данные для специализированных задач, меняя представление о том, как выглядят «хорошие» данные.
«Мы согласились с тем, что поиск консенсуса является обязательным во всех областях, но это не облегчает его», - говорит он. «Хранилище данных во многих смыслах является отражением организации. Если люди не договорятся о том, что они используют в хранилище данных или каковы целевые метрики, то это отсутствие консенсуса будет выражено в падении эффективности. Но, возможно, это нормально»
Возможно, Максим утверждает, что команда данных не обязательно несет исключительную ответственность за достижение консенсуса для бизнеса, особенно если эти данные используются по всей компании по-разному. Это по своей сути приведет к дублированию и замещениям, если команды не будут обсуждать, какие данные являются частными или передаются более широкому кругу пользователей.
«Теперь разные команды владеют данными, которые они используют и производят, вместо того, чтобы иметь одну централизованную команду, отвечающую за все данные в компании. Когда данными обмениваются между командами и предоставляют в более широких масштабах, необходимо быть более внимательными в предоставлении API для управления изменениями», - говорит он.
Что подводит нас к следующему пункту…
Управление изменениями по-прежнему является проблемой, но правильные инструменты могут помочь
В 2017 году, когда Максим написал свою первую статью: «Когда данные изменятся, это повлияет на всю компанию, но никто не будет уведомлен». Отсутствие такого управления изменениями было вызвано как техническими, так и культурными пробелами.
Когда исходный код или данные были изменены или обновлены, за ними следовали поломки, которые делали дашборды, отчеты и другие продукты связанные с данными фактически недействительными до тех пор, пока проблемы не будут решены. Это время простоя данных (периоды времени, когда данные отсутствовали, были неточными или ошибочными) было дорогостоящим, трудоемким и болезненным в исправлении. Слишком часто простои наносили удар молча, и команды должны были подумать, пытаясь выяснить, что пошло не так, кто пострадал и как они это могут исправить.
В настоящее время команды все чаще полагаются на DevOps и лучшие практики разработки ПО для создания более устойчивых инструментов и культур, которые приоритизируют безопасность связи и данных.
«Наблюдение за данными и историчность, безусловно, помогли командам выявить и устранить проблемы и даже получить информацию о том, что сломалось и кто пострадал», - сказал Максим. Тем не менее, управление изменениями также является культурой, как и технический стек. Если децентрализованные команды не следят за рабочими процессами, которые удерживают потребителей или даже команду центральной платформы данных в курсе, то эффективно обрабатывать изменения сложно.»
Если нет разграничения между тем, какие данные являются частными (используются только владельцами данных) или публичными (используются более широкой аудиторией), то трудно понять, кто использует какие данные, и когда данные ломаются, то что их сломало. Анализ историчности и первопричин поможет пройти половину пути. Например, в то время как Максим был в Airbnb, Dataportal был создан для демократизации доступа к данным и предоставления всем сотрудникам возможности исследовать, понимать и доверять данным. Тем не менее, в то время как инструмент подскажет им, кто пострадает от изменения данных, он все равно не упростил управление этими изменениями.
Данные должны быть неизменными, иначе последует хаос
Инструменты в значительной степени опираются на разработку ПО для вдохновления, и в целом это хорошо. Но есть несколько элементов данных, которые делают работу с ETL пайплайнами сильно отличными от кода. Один пример? Редактирование данных как код.
«Если я хочу изменить имя столбца, это будет довольно трудно сделать, потому что вам потребуется перезапустить ETL и изменить свой SQL-код», - сказал Максим. «Эти новые пайплайны и структуры данных влияют на вашу систему, и возможно будет трудно внедрить изменения, особенно когда что-то ломается»
Например, если у вас есть инкрементный процесс, который периодически загружает данные в очень большую таблицу, и вы хотите удалить некоторые из этих данных, вам необходимо приостановить пайплайн, перенастроить инфраструктуру, а затем развернуть новую логику после удаления новых столбцов.
Инструменты на самом деле вам не очень помогает, особенно в контексте дифференциальных нагрузок. Вставки все еще могут быть действительно болезненными, но есть некоторые преимущества, чтобы использовать их.
«На самом деле есть хорошие вещи, которые приходят из поддержки этого исторического послужного списка ваших данных», - говорит он. «Старая логика живет рядом с новой логикой, и их можно сравнить. Вам не нужно идти и ломать кучу действий, которые были использованы в прошлом».
Хранение важных активов информации (даже если они больше не используются) может обеспечить полезный контекст. Конечно, цель состоит в том, чтобы все эти изменения были четко задокументированы с течением времени.
Итак, какой стул выбрать? Задолженность данных или хаос пайплайнов.
Роль инженера данных разделяется
Как и в разработке ПО, роли и обязанности инженера данных меняются, особенно в более зрелых организациях. Инженера по базам данных вымирает, а потребности в хранении данных мигрируют в облако, и инженеры данных все больше отвечают за управление производительностью и надежностью данных.
По словам Максима, это, вероятно, хорошо. В прошлом инженер данных был «худшим местом за столом», ответственным за операционную работу кого-то другого с помощью инструментов и процессов, которые не совсем соответствовали потребностям бизнеса.
Теперь появляются всевозможные новые роли, которые облегчают процессы. Примером может служить инженер-аналитик. Придуманный Майклом Камински, редактором Locally Optimistic, инженера-аналитик представляет собой роль, которая занимается проектированием данных, и аналитикой данных и применяет аналитический , бизнес-ориентированный подход к работе с данными.
Инженер-аналитик похож на шепот данных, ответственный за то, чтобы данные не жили в изоляции от бизнес-аналитики и анализа.
«Инженер данных становится почти как хранитель хороших привычек работы с данными. Например, если инженер-аналитик перекапывает БД при каждом запуске с помощью dbt, у него могут развиться вредные привычки. Инженер данных является стражем врат, ответственным за обучение команд передовым практикам, в первую очередь эффективности, (обработка дополнительных нагрузок), моделирования данных и стандартов кода, а также полагаться на наглядность данных и DevOps, чтобы гарантироваться, что все относятся к данным с одинаковой осторожностью».
Операционная волатильность не исчезла, она только усилилась
Операционная волатильность, как обсуждалось в предыдущей статье Максима, относится к постепенному увеличению обязанностей с течением времени, и, к сожалению, это слишком распространенная реальность для инженеров данных. Хотя современные инструменты могут помочь сделать инженеров более продуктивными, они не всегда облегчают или упрощают их жизнь. На самом деле, они части могут приводить к большему объему работы с течением времени.
Тем не менее, даже с увеличением количества специализированных ролей и независимых команд операционная волатильность не исчезла. Некоторые из них только были переведены на другие должности по мере роста технической квалификации, а все больше и больше инвестируют в грамотность данных.
Например, Максим утверждает, что то, что инженер-аналитик ставит во главу угла, не обязательно то же самое, что и инженер данных.
«Заботятся ли инженеры-аналитики о стоимости эксплуатации своих пайплайнов? Они заботятся об оптимизации вашего стека или в основном заботятся о корректной интерпретации? Я не знаю». - он говорит. «Операционная волатильность является отраслевой проблемой, потому что скорее всего, инженеру данных все равно придется управлять «менее привлекательными» вещами, такими как следить за затратами на хранение или решение проблемы качества данных».
В мире инженера-аналитика также существует операционная волатильность.
«Как инженер-аналитик, все, что нужно мне сделать, это написать гору SQL-кода для решения проблемы, я, вероятно, буду использовать dbt, но это все еще гора шаблонного SQL-кода, что затрудняет написание чего-либо многоразового или управляемого», - говорит Максим. «Но это все равно тот вариант, который я бы выбрал во многих случаях, потому что он просто и легок».
Он предполагает, что в идеальном сценарии мы хотели бы что-то, что выглядело бы еще больше похоже на современный код, потому что мы можем создавать абстракции более масштабируемым способом.
Итак, что дальше для инженера данных?
Мой разговор с Максимом оставил мне много пищи для ума, но в целом, я склонен согласиться с его точкой зрения. В то время как структура отчетности данных и операционная иерархия становятся все более вертикальными, сфера охвата инженера данных становится все более горизонтальной и сосредоточена на производительности и надежности - что в конечном итоге хорошо.
Нацеленность на результат порождает инновации и скорость, что мешают инженерам данных создавать «океан данных», вынуждают выполнять слишком много задач или вообще выгореть. Больше ролей в команде означает, что традиционные задачи по разработке данных (выполнение ad-hoc запросов, моделирование, преобразование и даже построение пайалайнов) не должны лежать исключительно на их плечах. Вместо этого они могут сосредоточиться на том, что имеет значение: обеспечить надежность, доступность и безопасность данных на каждом этапе их жизненного цикла.
Меняющийся ландшафт инструментов отражает шаг к более целенаправленной и специализированной роли. DataOps упрощает планирование и выполнение заданий, облачные хранилища данных упрощают хранение и обработку данных в облаке, озера данных, позволяют создавать еще более детализированные и сложные сценарии использования обработки, наблюдаемость за данными и мониторинг приложений автоматизирует многие рутинные и повторяющиеся задачи, связанные с качеством и надежностью данных, обеспечивая базовый уровень работоспособности, который удовлетворяет всех.
С появлением этих новых технологий и рабочих процессов инженеры имеют фантастическую возможность владеть обработкой данных как продуктом. Построение гибких, масштабируемых, наблюдаемых и отказоустойчивых систем данных возможно только в том случае, если сами данные рассматриваются с помощью развивающегося, итеративного продукта. Вот где используются метаданные, относящиеся к конкретному направлению, обнаруживающие закономерности на основе машинного обучения и инструменты, которые могут помочь нам лучше понять, какие данные на самом деле имеют значение и что может пойти по пути вымирания.
По крайней мере, это то, что мы видим в нашем хрустальном шаре.
А что ты видишь в своем?)