Перевод подготовлен при поддержке сообщества аналитического курса DataLearn и телеграм-канала Инжиниринг Данных
От автора: Я пришел в индустрию чуть больше года назад, читая различные статьи на западных ресурсах, я заметил тренд на инжиниринг данных. Мне понравилась статья о развитии индустрии данных от авторитетного автора и этим переводом я решил поделиться с Вами.
Предисловие
Я присоединился к FAANG в 2011 году как BI-инженер. К моменту переезда в 2013 я был инженером данных.
Я не получал повышения и не менял должность, вместо этого руководство осознало, что наша работа выходит за рамки классического бизнес-анализа. Роль, которую мы создали сами для себя, была совершенно новым направлением.
Моя команда была на передовой этой трансформации. Мы развивали новые компетенции, новые пути решения задач, новые инструменты, и, чаще всего, отвергали традиционные подходы.
Мы были первопроходцами, мы были Инженерами Данных!
Инжиниринг данных?
Data Science как направление находилось в подростковом возрасте, самоутверждающимся и самоопределяющимся. В тоже время инжиниринг данных был подобно младшему брату, находился примерно в таком же статусе, получал подсказки от брата, определил себя и нашел свою собственную идентичность. Как и дата саентисты, инженеры данных пишут код. Они заинтересованы в аналитике и визуализации данных.
В отличии от старшего брата и вдохновленные им, инженеры данных разрабатывают ПО, инструменты, инфраструктуру, фреймворки и сервисы. По факту, можно утверждать, что инжиниринг данных гораздо ближе к разработке ПО, чем к Data Science.
В связи с ранее существовавшей ролью, инжиниринг данных можно рассматривать как совокупность бизнес-аналитики и хранение данных, которая привносит большое количество элементов из разработки ПО. Это направление также объединяет компетенции вокруг так называемых «Big Data», экосистемы Hadoop, потоковой обработки и распределенных вычислений.
В маленьких компаниях, где еще не сформировалась команда по инфраструктуре данных, роль инжиниринга данных может охватывать операционные процессы, связанные созданием и использованием инфраструктуры данных организации. Это включает в себя такие задачи, как настройка и использование таких инструментов, как Hadoop, Hive, HBase, Spark и прочее.
В небольших компаниях люди, как правило, используют услуги, предлагаемые гигантами на массовом рынке или получают поддержку от специализированных компаний, что по сути является субподрядом для направления инжиниринга данных.
В больших компаниях, как правило, существует отдел и создание обязанностей для управления рабочим процессом по мере роста необходимости команд в инфраструктуре данных. В таких организациях обязанности автоматизации некоторых процессов обработки данных находятся руках инженеров данных и команды разработки инфраструктуры и эти команды взаимодействуют для решения больших проблем.
В то время как инженерный аспект становится все более значимым, другие аспекты первоначальных функций бизнес инжиниринга становятся второстепенными. Такие области, как создание и сопровождение группы отчетов и системы мониторинга не являются основным направлением деятельности инженера данных.
Теперь у нас есть лучший инструмент самообслуживания, где аналитики, дата саентисты и основные потребители данных становятся все более ориентирующимся в данных и могут самостоятельно определять потребности в данных.
ETL меняется
Мы также наблюдали переход от инструментов ETL (Extract, Transform, Load (Извлечь, трансформировать, загрузить)) к более программному подходу. Продуктовый Ноу-Хау на таких платформах как Informatica, IBM Datastage, Cognos, AbInitio или Microsoft SSIS не является распространенным среди современных инженеров данных и заменяется более общими инструментами разработки ПО наряду с изучением платформ, таких как Airflow, Oozie, Azkabhan или Luigi. Инженеры данных также довольно часто разрабатывают и используют свои собственные оркестраторы или планировщики задач.
Существует множество причин, по которым некоторые части ПО не разрабатываются с помощью инструментов «Drag bad drop» и поэтому код становится лучшим решением для использования. Хотя споры по этой теме могут выйти за рамки этой статьи, легко сделать вывод, что эти же причины применимы к написанию ETL инструментов, так и к любому другому ПО. Код предполагает разные уровни абстракции, позволяет использовать все логические операции привычным способом, хорошо интегрируется с системой управления версиями, прост в представлении и совместной работе. Тот факт, что инструменты ETL эволюционировали до предоставления графических интерфейсов, кажется важным поворотом в истории обработки данных и, безусловно, заслуживает свой собственный интересный пост
Давайте подчеркнем тот факт, что абстракции, предоставляемые традиционными инструментами ETL, не являются целевыми. Конечно, необходимо отметить сложность обработки, вычисления и хранения данных. Но я бы сказал, что решение заключается не в том, чтобы базовые объекты ETL (такие как источник/цель, агрегаты, фильтры) ограничивались лишь переносом данных, абстракции имеют более высокий уровень.
Например, обязательным требованием для данных является потребность эксперимента в рамках А/В теста: Зачем весь эксперимент? Какие методы использовать? Какой процент пользователей необходимо взять? Какие показатели планируется достичь в ходе эксперимента? Когда стоит начать эксперимент? В этом случае у нас есть представление, которое обозначает точную высокоуровневую потребность, проведены сложные статистические вычисления и обоснованы их результаты. Мы предполагаем, что добавление новой информации для эксперимента приведет к дополнительным вычислениям и получению результатов. Важно отметить, что в этом примере входные параметры не являются самой целью для ETL инструмента, а лишь помогают достичь зафиксированных требований.
Для современного инженера данных традиционные ETL инструменты в значительной степени устарели, а логика может быть не выражена кодом. В результате необходимые требования не могут быть интуитивно выражены в этих инструментах. Теперь, понимая, что роль инженера данных заключается в основном в ETL процессах, и то, что необходим принципиально новых набор инструментов и методик, можно утверждать, что это приводит к восстановлению направления с нуля. Новый стек, новые инструменты, новые требования и во многих случаях новое поколение людей.
Структура данных меняется
Традиционные подходы построения хранилища данных, такие как «звезда», которые определили наш подход к устройству данных для аналитических целей, связанные с БД, менее востребованы, чем когда-либо ранее. Традиционная передовая практика хранения данных проигрывает на меняющемся стеке. Хранение и вычисления дешевле, чем раньше, и с появлением распределенных баз данных, которые линейно масштабируются, дефицитным ресурсом является время работы инженеров.
Вот некоторые изменения, наблюдаемые в методах построения хранилища данных:
- Дальнейшая денормализация: структура суррогатных ключей может быть сложной, и это делает используемые таблицы менее читаемыми. Использование естественных, понятных человеку ключей и атрибутов на самом деле становится все более распространенным, уменьшая необходимость в сложных соединениях, которые могут быть тяжелыми для распределенных баз данных. Также обратите внимание, что возможность кодирования и сжатия в таких форматах, как Parquet или ORC, внутри баз данных, таких как Vertica, устраняет большую часть потерь производительности, которые обычно связаны с денормализацией. Такие системы научились самостоятельно нормализовать данные.
- BLOB: современные базы данных поддерживают BLOB-объекты через собственные типы и функции. Это открывает новые возможности в структуре данных и может позволить таблицам хранить несколько атрибутов одновременно, когда это необходимо.
- Динамические схемы: с появлением Map Reduce, растущей популярностью хранилищ документов и поддержкой BLOB-объектов в базах данных становится легче развивать схемы баз данных без выполнения DML. Это облегчает итеративный подход к складированию и устраняет необходимость получения полной информации до начала разработки.
- Регулярный Snapshot изменений (хранение полной копии изменений после каждого ETL цикла) в качестве общего способа обработки медленно меняющихся измерений (SCD) - это простой общепринятый подход, который требует особых усилий инженера данных, и который, в отличии от классического подхода, легко понять при написании ETL и запросов. Также легко и относительно дешево денормализовать атрибут в таблице, чтобы отслеживать его в момент транзакции. Оглядываясь назад, сложные методы моделирования SCD интуитивно непонятны и снижают доступность.
- Соответствие, измерения и метрики по-прежнему чрезвычайно важны в современных хранилищах данных, но с необходимостью быстрого перемещения хранилищ данных, с участием большого количества команд и ролей, участвующих в этих процессах, становится менее важным и больше походит на компромисс. Консенсус и согласованность могут происходить в качестве фонового процесса в областях, недоступных большинству пользователей.
Кроме того, в более общем плане можно сказать, что с коммерциализацией отрасли и тем, что все больше людей разбирается в данных, чем раньше, меньше необходимости в предобработке и хранении результатов в хранилище данных. Например, у вас может быть сложный Spark-скрипт, который проводит сложный анализ только по требованию и не планируется как часть хранилища данных.
Роли и обязанности
Хранилище данных
Хранилище данных - это копия данных транзакций, специально структурированных для запроса и анализа. - Ральф Кимбалл
Хранилище данных - это предметно-ориентированный, интегрированный, меняющийся во времени и энергозависимый сбор данных в поддержку процесса принятия решений руководством. - Билл Инмон
Хранилище данных также актуально, как и ранее, и инженеры данных отвечают за многие аспекты его строительства и эксплуатации. Хранилище данных является целью для инженера данных и оно притягивает его.
Современное хранилище данных скорее общественный институт, чем исторически сложившийся, объединяя дата саентистов, аналитиков и разработчиков для его разработки и эксплуатации. Данные просто слишком ориентированы на деятельность компании, чтобы иметь ограничения на то, какие роли могут управлять ее потоком. Несмотря на то, что это позволяет масштабировать данные в соответствии с потребностями организации, это часто приводит к гораздо более хаотичной, вечно меняющей форму, несовершенной инфраструктуре.
Команда инженеров зачастую имеет персональные сертификаты доступа к особо важным областям в хранилище данных. Например, есть набор «основных» схем , которыми управляет команда инженеров данных, где сформулировано и используется соглашение об уровне обслуживания (SLA), строго соблюдаются правила создания наименований, бизнес-метаданные и документация высочайшего качества, а соответствующий код пайплайна следует набору конкретно определённых передовых практик.
Это также становится обязанностью инженеров данных, которые становятся «центром передового опыта» благодаря сформулированным стандартам, передовой практики и процессов сертификации объектов данных. Команда может эволюционировать, чтобы принять участие или возглавить образовательную программу, разделяя свои основные компетенции, чтобы помочь другим командам стать лучшими пользователями хранилища данных. Например, одна компания из FAANG имеет образовательную программу «Лагерь данных», а другая разрабатывает аналогичную программу «Университет данных» в рамках которых инженеры данных проводят сессии, которые учат людей использовать данные.
Инженеры данных также являются «библиотекарями» хранилища данных, документируя и организуя метаданные, формируют необходимые файлы или извлекают их из хранилища данных. В быстро растущей, быстро развивающейся, немного хаотичной экосистеме данных управление метаданными и инструментами становятся жизненно важным компонентном современной платформы данных.
Роли и обязанности
Поскольку данные становятся более стратегически важными, чем когда-либо, компании впечатляюще увеличивают бюджеты для своей инфраструктуры данных. Это вынуждает инженеров данных все чаще заниматься настройками производительности и оптимизировать процессы обработку и хранение данных. Так как бюджеты в этой отрасли редко сокращаются, оптимизация часто происходит с помощью увеличения объема ресурсов или попыток ограничить их экспоненциальный рост использования.
Зная, что сложность инжиниринга данных увеличивается, мы можем предположить, что сложность оптимизации такого стека и процессов может быть такой же сложной. Там, где возможно легко получить огромные преимущества с небольшими усилиями, обычно применяются законы об уменьшении прибыли.
Инженер данных безусловно заинтересован, в том, чтобы построить инфраструктуру, которая масштабируется вместе с компанией, и всегда быть внимательным к ресурсам.
Интеграция данных
Интеграция данных, практика интеграции бизнеса и систем через обмен данными, также важен и сложен, как и ранее. Так как программное обеспечение как услуга (SaaS) становится новым обычным способом работы компаний, необходимость синхронизирования источников данных в этих системах становится все более важной. Для функционирования не только SaaS нужны актуальные данные, зачастую мы бы хотели перенести данные, сгенерированные на стороне исполнителя в наше хранилище данных, чтобы их можно было проанализировать совместно с остальными нашими данными. Конечно, у SaaS часто есть собственное аналитическое решение, но им обычно не хватает перспективы, которую предлагают остальные данные вашей компании, поэтому часто необходимо интегрировать некоторые из сторонних данных.
Позволение SaaS переопределять отправляемые данные без интеграции и совместного использования общего первичного ключа является катастрофой, которую стоит избегать любой ценой. Никто не хотел бы вручную вести два списка сотрудников или клиентов в двух системах, и хуже всего разбираться в несоответствиях своих HR-данных в хранилище данных.
Хуже всего то, что исполнительный директор компании часто принимает решение по сделке с поставщиками SaaS без учета проблем интеграции данных. Рабочая нагрузка систематически преуменьшается поставщиками, чтобы повысить их продажи, и вынуждает инженеров данных переделывать их работу. Не говоря о том, что типичные SaaS API часто плохо спроектированы, непонятно задокументированы и «гибки», следовательно, можно ожидать спонтанного изменения без предварительного уведомления.
Сервисы
Инженеры данных работают на более высоком уровне абстракции, и в некоторых случаях это означает необходимость сервисов и инструментов для автоматизации работы, которую инженеры данных, дата саентисты или аналитики выполняют вручную.
Вот несколько примерных сервисов, которые могут создавать и использовать инженеры данных или инженер по инфраструктуре данных.
- Прием данных: сервисы и инструменты направленные на «очистку» баз данных, загрузки логов, получение данных из внешних источников или API, …
- Вычисления метрик: фреймворки для расчета и организации метрик, связанные с потребностями, ростом или сегментацией
- Обнаружение аномалий: автоматизация потоков данных для оповещения сотрудников об аномальных событиях или о значительном изменении тенденций
- Управление метаданными: инструмент, позволяющий создавать и использовать метаданные, облегчая поиск информации в хранилище данных
- Эксперименты: А/В тестирование и экспериментальные фреймворки зачастую являются критически важной часть аналитики компании со значительным влиянием инжиниринга данных
- Инструменты: аналитика начинается с определения событий и атрибутов, связанных с событиями, инженеры данных заинтересованы в том, чтобы обеспечить высококачественный сбор данных
- Сессионизация: пайплайны, которые специализируются на понимании действий во времени, позволяя аналитикам понимать поведение пользователей
Как и разработчики-программисты, инженеры данных должны постоянно стремиться автоматизировать свои рабочие процессы и строить структуру, которая позволит им с каждым разом решать более сложные задачи. Несмотря на то, что особенности рабочих процессов, которые могут быть автоматизированы, различаются в зависимости от внешних условий, необходимость их автоматизации распространена в большинстве направлений.
Необходимые навыки
Фантастический SQL: если английский является языком бизнеса, то SQL - это язык данных. Насколько успешным вы можете быть бизнесменом, если плохо говорите по-английски? (Не является обязательной способностью на территории Российской Федерации