Кто такой инженер по надежности данных?

С каждым днем ​​предприятия все больше полагаются на данные для принятия решений.

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

Это связано с несколькими причинами, в том числе:

• Возможность обработки данных из различных источников при низких затратах.

• Взрыв доступности и разнообразия инструментов обработки данных (влияющих на сотрудничество и принятие решений, помимо технической работы).

• Жесткие зависимости между активами данных, которыми управляют разные отделы внутри компаний.

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

==Инженерия надежности данных (DRE) решает проблемы с качеством и доступностью данных.==

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

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

Начнем с основного определения.

Что такое проектирование надежности данных (DRE)?

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

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

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

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

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

Примеры использования

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

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

Что касается предварительных проверок, вот соответствующий [кейс] (https://www.datafold.com/case-studies/thumbtack), в котором говорится о повышении надежности данных.

Что делает инженер по надежности данных?

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

Инженеры данных несут ответственность за разработку конвейеров данных и надлежащее тестирование своего кода. Тем не менее, инженеры по надежности данных несут ответственность за поддержку конвейеров в производстве, отслеживая инфраструктуру и качество данных. Другими словами, команды Data Engineering обычно выполняют модульные и регрессионные тесты, которые устраняют известные или предсказуемые проблемы с данными, прежде чем код будет запущен в производство. Команды DRE настраивают производственную среду для обнаружения неизвестных проблем, прежде чем воздействовать на конечных пользователей.

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

• Хранилища данных и приложения — от проектирования до развертывания — с использованием SQL или других инструментов обработки больших данных.

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

• Инструменты оркестрации конвейера, такие как Airflow или Dagster

• Инструменты мониторинга, такие как Grafana или New Relic

• Облачные вычисления

• Предоставление инфраструктуры, включая инструменты автоматизации, такие как Terraform

• IP-сети, VPN, DNS, балансировка нагрузки и брандмауэры

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

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

DRE, SRE и DevOps

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

Сходства между DRE, SRE и DevOps на этом не заканчиваются.

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

DRE разделяет дополнительный важный аспект с SRE и DevOps: командная культура. В DRE, SRE и DevOps все члены команды несут ответственность за успех или неудачу команды и ее решений. Как упоминалось ранее, инженеры по надежности данных являются доверенными консультантами, которые отстаивают передовые методы обеспечения надежности внутри компании. Тем не менее, результаты будут зависеть от того, насколько их коллеги (менеджеры, инженеры данных, аналитики инфраструктуры и т. д.) придерживаются таких практик.

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

Моей компании пора инвестировать в DRE?

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

• Компания выделила ресурсы для принятия решений по данным с помощью ML/AI.

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

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

Как и в случае с любыми инвестициями, компании должны иметь возможность измерить рентабельность инвестиций в DRE, прежде чем принимать решение вкладывать в них больше или меньше. Ожидается, что группы данных обсудят KPI и установят SLA с командой DRE для этого. Когда начинается обсуждение, записывается базовый уровень. Затем проводятся периодические встречи «планируй, делай, проверяй, действуй» (PDCA), чтобы проверить влияние и определить последующие действия.

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

Заключение

Теперь, когда вы знаете, что такое DRE, возможно, пришло время для разговора в вашей компании более глубоко погрузиться в тему. Или, может быть, вы хотите повысить уровень своих навыков, чтобы найти работу в качестве DRE. У одной компании — Datafold — есть набор основных продуктов, которые помогают запустить DRE:

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

• Data Diff обеспечивает простое регрессионное тестирование ETL одним щелчком мыши. Он автоматизирует регрессионное тестирование с интеграцией в процесс CI, поддерживая как GitHub, так и GitLab. Проверяйте каждое изменение исходного кода, чтобы вы могли легко увидеть, как изменения в вашем коде влияют на данные, полученные во всех строках и столбцах.

• Мониторинг данных позволяет командам DRE быстрее реагировать на инциденты с оповещением без кода всего одним щелчком мыши. Он основан на модели ML, которая изучает, как работают ваши данные, чтобы адаптироваться к сезонности и тенденциям в ваших данных для создания динамических пороговых значений.

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

Ранее опубликовано [здесь] (https://dzone.com/articles/the-rise-of-the-data-reliability-engineer)