Несмотря на нынешнюю популярность инженерии данных, существует большая путаница в том, что такое инженерия данных и чем занимаются инженеры данных. Инженерия данных в той или иной форме существует с тех пор, как компании начали проводить работу с данными, — например, предиктивный анализ, описательную аналитику и отчёты — и оказалась в центре внимания вместе с развитием науки о данных в 2010-х годах. Для целей этой книги очень важно определить, что означают термины «инженерия данных» и «инженер данных» (data engineer).

Во-первых, давайте посмотрим на то, как описывается инженерия данных, и определим некоторую терминологию, которую мы сможем использовать в этой книге. Существует бесконечное количество определений инженерии данных. В начале 2022 года поиск Google с точным соответствием запросу «что такое инженерия данных?» возвращает более 91 000 уникальных результатов. Прежде чем мы дадим наше определение, вот несколько примеров того, как некоторые эксперты в этой области определяют инженерию данных:

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

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

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

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

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

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

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

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

Появление инженера данных, возможно, уходит своими корнями в хранилища данных, датированные 1970-ми годами, когда хранилище бизнес-данных сформировалось в 1980-х годах, а Билл Инмон официально ввел термин «хранилище данных» (data warehouse) в 1989 году. После того, как инженеры IBM разработали реляционную базу данных и язык структурированных запросов (SQL), а Oracle популяризировала эту технологию. По мере роста зарождающихся систем данных предприятиям требовались специальные инструменты и конвейеры данных для отчётности и бизнес-аналитики (BI). Чтобы помочь людям правильно моделировать свою бизнес-логику в хранилище данных, Ральф Кимбалл и Инмон разработали соответствующие одноименные методы и подходы к моделированию данных, которые широко используются до сих пор.

Хранилища данных положили начало первой эпохе масштабируемой аналитики с появлением новых баз данных с массово-параллельной архитектурой (MPP), которые используют несколько процессоров для обработки больших объёмов данных, поступающих на рынок, и поддерживают беспрецедентные объёмы данных. Такие должности, как инженер BI, разработчик ETL и инженер хранилища данных, удовлетворяли различные потребности хранилища данных. Хранилища данных и BI-инженерия были предшественниками современной инженерии данных и до сих пор играют центральную роль в этой дисциплине.

Интернет стал массовым явлением примерно в середине 1990-х годов, создав целое новое поколение компаний, ориентированных на него, таких как AOL, Yahoo и Amazon. Бум доткомов породил массу активности в области веб-приложений и серверных систем, поддерживающих их — серверах, базах данных и хранилищах. Большая часть инфраструктуры была дорогой, монолитной и лицензированной. Поставщики, продающие эти серверные системы, вероятно, не предвидели масштаб данных, которые будут создавать веб-приложения.

Перенесёмся в начало 2000-х, когда бум доткомов конца 90-х прогорел, оставив после себя небольшую группу выживших. Некоторые из этих компаний, такие как Yahoo, Google и Amazon, превратятся в мощные технологические компании. Первоначально эти компании продолжали полагаться на традиционные монолитные реляционные базы данных и хранилища данных 1990-х годов, доводя эти системы до предела. Поскольку эти системы вышли из строя, потребовались обновлённые подходы для обработки растущего объёма данных. Новое поколение систем должно быть экономически эффективным, масштабируемым, доступным и надежным.

Одновременно с бурным ростом объёма данных стандартное оборудование, такое как серверы, оперативная память, диски и флэш-накопители, также стало дешёвым и повсеместным. Ряд инноваций позволил осуществлять распределённые вычисления и хранение данных в огромных вычислительных кластерах в огромных масштабах. Эти инновации положили начало децентрализации и разрушению традиционно монолитных сервисов. Началась эра «больших данных».

Оксфордский словарь английского языка определяет большие данные как «чрезвычайно большие наборы данных, которые можно анализировать с помощью вычислений, чтобы выявить закономерности, тенденции и ассоциации, особенно связанные с человеческим поведением и взаимодействиями». Ещё одно известное и краткое описание больших данных — это три V данных: velocity, variety, и volume (скорость, разнообразие и объём).

В 2003 году Google опубликовал статью о файловой системе Google, а вскоре после этого, в 2004 году, — статью о MapReduce — сверхмасштабируемой парадигме обработки данных. По правде говоря, большие данные и раньше имели предшественников в хранилищах данных MPP и управлении данными для экспериментальных физических проектов, но публикации Google стали «большим взрывом» для технологий обработки данных и культурных корней инженерии данных, какой мы её знаем сегодня. Вы узнаете больше о системах MPP и MapReduce в главах 3 и 8 соответственно.

Документация Google вдохновили инженеров Yahoo на разработку, а затем и на открытие исходного кода Apache Hadoop в 2006 году. Трудно переоценить влияние Hadoop. Инженеры-программисты, интересующиеся крупномасштабными проблемами данных, были привлечены возможностями этой новой технологической экосистемы с открытым исходным кодом. Когда компании всех размеров и типов увидели, что их данные выросли до многих терабайт и даже петабайт, родилась эра инженеров больших данных.

Примерно в то же время Amazon приходилось идти в ногу со своими растущими потребностями в данных и создавать эластичные вычислительные среды (Amazon Elastic Compute Cloud, или EC2), бесконечно масштабируемые системы хранения (Amazon Simple Storage Service, или S3), высокомасштабируемые базы данных NoSQL (Amazon DynamoDB) и многие другие блоки данных. Amazon решила предлагать эти услуги для внутреннего и внешнего потребления через Amazon Web Services (AWS), став первым популярным общедоступным облаком. AWS создала сверхгибкий рынок ресурсов с оплатой по факту использования, виртуализируя и перепродавая огромные пулы стандартного оборудования. Вместо покупки оборудования для центра обработки данных, разработчики могут просто арендовать вычислительные ресурсы и хранилище у AWS.

Поскольку AWS стал высокодоходным инструментом роста для Amazon, вскоре за ним последовали и другие публичные облака (public cloud), такие как Google Cloud, Microsoft Azure и DigitalOcean. Публичное облако, возможно, является одной из самых значительных инноваций 21-го века и породило революцию в способах разработки и развёртывания программного обеспечения и приложений для обработки данных.

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

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

Инженеры могли выбирать новейшие и лучшие технологии — Hadoop, Apache Pig, Apache Hive, Dremel, Apache HBase, Apache Storm, Apache Cassandra, Apache Spark, Presto и множество других новых технологий, появившихся на сцене. Традиционные корпоративные инструменты обработки данных с графическим пользовательским интерфейсом внезапно почувствовали себя устаревшими, а с появлением MapReduce в моду вошло проектирование на основе кода (code-first). Мы (авторы) были рядом в это время, и казалось, что старые догмы умерли внезапной смертью на алтаре больших данных.

Бурный рост инструментов обработки данных в конце 2000-х и 2010-х годах положил начало появлению инженеров больших данных. Чтобы эффективно использовать эти инструменты и методы, а именно экосистему Hadoop, включая Hadoop, YARN, распределённую файловую систему Hadoop (HDFS) и MapReduce, инженеры по работе с большими данными должны были обладать навыками разработки программного обеспечения и низкоуровневого хакинга инфраструктуры, но со смещенным акцентом. Инженеры больших данных обычно поддерживают огромные кластеры стандартного оборудования для доставки данных в большом масштабе. Хотя они могли время от времени отправлять запросы на включение в основной код Hadoop, они сместили свое внимание с разработки основных технологий на доставку данных.

Большие данные быстро стали жертвой собственного успеха. Как модное слово, большие данные приобрели популярность в период с начала 2000-х до середины 2010-х годов. Большие данные захватили воображение компаний, пытающихся разобраться в постоянно растущих объёмах данных и бесконечном шквале бесстыдного маркетинга со стороны компаний, продающих инструменты и услуги для работы с большими данными. Из-за огромной шумихи компании часто использовали инструменты больших данных для решения небольших проблем с данными, иногда создавая кластер Hadoop для обработки всего нескольких гигабайт. Казалось, что все хотели принять участие в работе с большими данными. Дэн Ариэли написал в Твиттере: «Большие данные похожи на подростковый секс: все говорят об этом, никто толком не знает, как это сделать, все думают, что все остальные этим занимаются, поэтому все утверждают, что они это делают».

На рис. 1-2 показан скриншот Google Trends для поискового запроса «большие данные», позволяющий получить представление о взлете и падении больших данных.

Несмотря на популярность этого термина, большие данные потеряли популярность. Что случилось? Одно слово: упрощение. Несмотря на мощь и сложность инструментов больших данных с открытым исходным кодом, управление ими было трудоёмким и требовало постоянного внимания. Часто компании нанимали целые команды инженеров по большим данным, что обходилось в миллионы долларов в год, чтобы присматривать за этими платформами. Инженеры по работе с большими данными часто тратили слишком много времени на поддержку сложных инструментов и, возможно, не так много времени на предоставление аналитической информации и ценности для бизнеса.

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

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

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

Действительно, инструменты обработки данных распространились с поразительной скоростью (см. рис. 1-3). Популярные тенденции начала 2020-х годов включают современный стек данных, представляющий собой набор готовых продуктов с открытым исходным кодом и сторонних продуктов, собранных для облегчения жизни аналитиков. В то же время источники данных и форматы данных растут как по разнообразию, так и по размеру. Инженерия данных все чаще становится дисциплиной, где для достижения конечных бизнес-целей, подобно кубикам LEGO, взаимодействуют и соединяются различные технологии.

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

По мере того как инструменты и рабочие процессы упрощаются, мы наблюдаем заметный сдвиг в подходах инженеров данных. Вместо того, чтобы сосредоточиться на том, у кого есть «самые большие данные», проекты и сервисы с открытым исходным кодом всё больше внимания уделяют управлению данными, упрощению их использования и поиска, а также повышению их качества. Специалисты по обработке данных теперь знакомы с такими аббревиатурами, как CCPA (California Consumer Privacy Act) и GDPR (General Data Protection Regulation); разрабатывая конвейеры, они заботятся о конфиденциальности, анонимности, сборе мусора и соблюдении нормативных требований.

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

Инженерия данных схожа с наукой о данных? Есть некоторые споры, некоторые утверждают, что инженерия данных является поддисциплиной науки о данных. Мы считаем, что инженерия данных отделена от науки о данных и аналитики. Они дополняют друг друга, но совершенно разные. Инженерия данных предшествует науке о данных (рис. 1-4), то есть инженеры данных предоставляют входные данные, используемые учёными по данным (после инженерии данных), которые преобразуют эти входные данные во что-то полезное.

Рассмотрим иерархию потребностей науки о данных (рис. 1-5). В 2017 году Моника Рогати опубликовала эту иерархию в статье, которая показала, где искусственный интеллект и машинное обучение (МО) находятся рядом с более «приземленными» областями, такими как перемещение/хранение, сбор и инфраструктура данных.

Хотя многие учёные по данными, стремятся создавать и настраивать модели машинного обучения, в реальности, по оценкам, от 70% до 80% их времени тратится на работу в трех нижних частях иерархии — сбор данных, очистку данных, обработку данных — и только крошечная часть своего времени на анализ и МО. Рогати утверждает, что компаниям необходимо создать прочную основу данных (три нижних уровня иерархии), прежде чем заниматься такими областями, как искусственный интеллект и машинное обучение.

Учёные по данным, обычно не обучаются проектированию систем данных промышленного уровня, и в конечном итоге они выполняют эту работу бессистемно, потому что им не хватает поддержки и ресурсов инженера данных. В идеальном мире учёные по данным должны тратить более 90% своего времени на верхние уровни пирамиды: аналитику, экспериментирование и машинное обучение. Когда инженеры данных сосредотачиваются на этих нижних частях иерархии, они создают прочную основу для успеха учёных.

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

Набор навыков инженера данных охватывает «скрытые тенденции» инженерии данных: безопасность, управление данными, DataOps, архитектуру данных и разработку программного обеспечения. Этот набор навыков требует понимания того, как оценивать инструменты обработки данных и как они сочетаются друг с другом в жизненном цикле инженерии данных. Также важно знать, как данные создаются в исходных системах и как аналитики и специалисты по обработке данных будут поглощать и создавать ценность после обработки и хранения данных. Наконец, инженер данных манипулирует множеством сложных подвижных деталей и должен постоянно оптимизировать затраты, гибкость, масштабируемость, простоту, повторное использование и совместимость (Рисунок 1-7). Мы рассмотрим эти темы более подробно в следующих главах.

Как мы уже обсуждали, в недавнем прошлом от инженеров данных ожидали знаний и понимания, как использовать небольшую группу мощных и монолитных технологий (Hadoop, Spark, Teradata, Hive и многие другие) для создания решения по обработке данных. Использование этих технологий часто требует глубокого понимания разработки программного обеспечения, сетей, распределённых вычислений, хранения или других низкоуровневых подробностей. Их работа предполагалось посвятить администрированию и обслуживанию кластера, управлению накладными расходами, созданию конвейеров и заданий по трансформации, а также другим задачам.

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

Чего не делает инженер данных? Инженер данных обычно не строит модели машинного обучения напрямую, не создаёт отчеты или информационные панели, не выполняет анализ данных, не строит ключевые показатели эффективности (KPI — key performance indicators) и не разрабатывает программные приложения. Инженер данных должен хорошо понимать эти области, чтобы лучше всего служить заинтересованным сторонам.

Уровень сложности обработки данных внутри компании во многом зависит от зрелости данных компании. Это существенно влияет на повседневные должностные обязанности инженера данных и его карьерный рост. Так что такое зрелость данных?

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

Модели зрелости данных (data maturity model) имеют множество версий, вроде Зрелости Управления Данными (DMM - Data Management Maturity) и другие, и трудно выбрать ту, которая была бы одновременно простой и полезной для инженерии данных. Итак, мы создадим собственную упрощенную модель зрелости данных. Наша модель зрелости данных (рис. 1-8) состоит из трех этапов: начало работы с данными, масштабирование с помощью данных и управление с помощью данных. Давайте посмотрим на каждый из этих этапов и на то, что обычно делает инженер данных на каждом этапе.

Компания, начинающая работу с данными, по определению находится на самых ранних стадиях зрелости данных. Компания может иметь нечёткие, слабо определённые цели или вообще не иметь целей. Архитектура данных и инфраструктура находятся на самых ранних стадиях планирования и разработки. Принятие и использование, вероятно, низкие или отсутствуют. Команда обработки данных небольшая, часто до 10 человек. На этом этапе инженер данных обычно является специалистом широкого профиля и обычно выполняет несколько других ролей, например, учёного по данным или инженера-программиста. Цель инженера данных — действовать быстро, набирать обороты и повышать ценность.

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

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

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

• Получение поддержки со стороны ключевых заинтересованных сторон, включая высшее руководство. В идеале у инженера данных должен быть спонсор для критически важных инициатив по проектированию и построению архитектуры данных, соответствующей целям компании.
• Определение правильной архитектуры данных (обычно самостоятельно, поскольку архитектора данных, скорее всего, нет). Это означает определение бизнес-целей и конкурентного преимущества, которые вы стремитесь достичь с помощью своей инициативы в области данных. Работайте над архитектурой данных, которая поддерживает эти цели. В главе 3 приведены наши советы по поводу «хорошей» архитектуры данных.
• Выявление и проверка данных, которые будут поддерживать ключевые инициативы и работать в рамках разработанной вами архитектуры данных.
• Создание надежной основу данных для будущих аналитиков и инженеров данных, чтобы они могли создавать отчеты и модели, обеспечивающие конкурентоспособность. В то же время вам, возможно, придётся создавать эти отчеты и модели, пока такая команда не будет нанята.

Это деликатный этап со множеством подводных камней. Вот несколько советов для этого этапа:

• Сила воли организации может ослабнуть, без достижения ощутимых успехов. Получение быстрых результатов подтвердит важность данных внутри организации. Просто имейте в виду, что быстрые победы, скорее всего, создадут технический долг. Разработайте план по сокращению этого долга, поскольку в противном случае это создаст трудности в будущем.
• Выйдите из кабинета и поговорите с людьми и избегайте закрытой работы. Мы часто видим, как команда данных работает в «пузыре», не общаясь с людьми за пределами своих отделов и не получая мнения и отзывы от заинтересованных сторон. Опасность в том, что вы потратите много времени, работая над вещами, малопригодными для людей.
• Избегайте недифференцированной тяжелой работы. Не ограничивайте себя ненужными техническими сложностями. По возможности используйте готовые решения «под ключ».
• Создавайте собственные решения и код только там, где это создаёт конкурентное преимущество.

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

В организациях, находящихся на втором этапе зрелости данных, цели инженера данных заключаются в следующем:

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

Мы вернемся к каждой из этих целей позже в книге.

Проблемы, на которые следует обратить внимание, включают следующее:

• По мере того, как мы становимся все более искушенными в работе с данными, возникает соблазн внедрить передовые технологии, основанные на общественном одобрении компаний Кремниевой долины. Это редко стоит использования вашего времени и энергии. Любые технологические решения должны основываться на ценности, которую они принесут вашим клиентам.
• Основным узким местом масштабирования являются не узлы кластера, хранилище или технология, а команда инженеров данных. Сосредоточьтесь на решениях, которые просты в развертывании и управлении, чтобы повысить производительность вашей команды.
• У вас возникнет соблазн представить себя технологом, гением данных, способным создавать волшебные продукты. Вместо этого переключите свое внимание на прагматичное лидерство и начните переход к следующему этапу зрелости; общайтесь с другими командами о практической полезности данных. Научите организацию потреблять и использовать данные.

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

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

• Создать автоматизацию для беспрепятственного введения и использования новых данных.
• Сосредоточиться на создании индивидуальных инструментов и систем, которые используют данные как конкурентное преимущество.
• Сосредоточиться на «корпоративных» аспектах данных, таких как управление данными (включая управление данными и их качество) и DataOps.
• Развернуть инструменты, которые предоставляют и распространяют данные по всей организации, включая каталоги данных, инструменты происхождения данных и системы управления метаданными.
• Эффективно сотрудничать с разработчиками программного обеспечения, инженерами машинного обучения, аналитиками и другими людьми.
• Создать сообщество и среду, где люди смогут сотрудничать и говорить открыто, независимо от их роли или положения.

Проблемы, на которые следует обратить внимание, включают следующее:

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

Инженерия данных — быстрорастущая область, и есть много вопросов о том, как стать инженером данных. Поскольку инженерия данных — относительно новая дисциплина, формального обучения для входа в эту область мало. В университетах нет стандартного пути инженерии данных. Хотя несколько учебных курсов по инженерии данных и онлайн-уроки охватывают случайные темы, общей учебной программы по этому предмету пока не существует.

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

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

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

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

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

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

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

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

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

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

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

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

• Генерация
• Хранение
• Поглощение
• Преобразование
• Предоставление

Фоновыми процессами жизненного цикла инженерии данных являются следующие:

• Безопасность
• Управление данными
• Операции с данными
• Архитектура данных
• Оркестровка
• Разработка программного обеспечения

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

Люди часто спрашивают, должен ли инженер данных уметь программировать? Короткий ответ: да. Инженер данных должен обладать навыками разработки программного обеспечения промышленного уровня. Замечено, что характер проектов по разработке программного обеспечения, реализуемых инженерами данных, фундаментально изменился за последние несколько лет. Полностью управляемые сервисы теперь заменяют значительную часть усилий по низкоуровневому программированию, которые ранее ожидались от инженеров, использующих теперь управляемый открытый исходный код и простые предложения программного обеспечения как услуги (SaaS) по принципу «работы из коробки». Например, инженеры данных теперь сосредотачиваются на абстракциях высокого уровня или написании конвейеров в виде кода в рамках структуры оркестрации.

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

Какие языки должен знать инженер данных? Мы делим языки программирования для обработки данных на первичную и вторичную категории. На момент написания этой статьи основными языками обработки данных были SQL, Python, язык виртуальной машины Java (JVM) (обычно Java или Scala) и bash:

SQL
Самый распространенный интерфейс для баз и озер данных. После того, как SQL на короткое время был отодвинут на второй план из-за необходимости писать собственный код MapReduce для обработки больших данных, SQL (в различных формах) вновь стал лингва-франка для данных.
Python
Язык-мост между инженерией данных и наукой о данных. Всё большее число инструментов обработки данных написано на Python или имеет API-интерфейсы Python. Его называют «вторым лучшим языком во всем». Python лежит в основе таких популярных инструментов обработки данных, как pandas, NumPy, Airflow, sci-kit Learning, TensorFlow, PyTorch и PySpark. Python является связующим звеном между базовыми компонентами и часто является первоклассным языком API для взаимодействия с платформой.
Языки JVM, такие как Java и Scala.
Распространен для проектов Apache с открытым исходным кодом, таких как Spark, Hive и Druid. JVM, как правило, более производительна, чем Python, и может предоставлять доступ к функциям более низкого уровня, чем API Python (например, это относится к Apache Spark и Beam). Понимание Java или Scala будет полезно, если вы используете популярную платформу данных с открытым исходным кодом.
bash
Интерфейс командной строки для операционных систем Linux. Знание команд bash и удобство использования CLI значительно повысят вашу производительность и рабочий процесс, когда вам нужно писать сценарии или выполнять операции с ОС. Даже сегодня инженеры по данным часто используют инструменты командной строки, такие как awk или sed, для обработки файлов в конвейере данных или вызова команд bash из инфраструктур оркестрации. Если вы используете Windows, смело замените bash на PowerShell.

Инженерам по обработке данных также может потребоваться овладеть дополнительными языками программирования, включая R, JavaScript, Go, Rust, C/C++, C# и Julia. Разработка на этих языках часто необходима, когда они популярны в компании или используются с инструментами обработки данных, специфичными для конкретной предметной области. Например, JavaScript оказался популярным как язык для пользовательских функций в облачных хранилищах данных. В то же время C# и PowerShell необходимы компаниям, использующим Azure и экосистему Microsoft.

Хотя должностные инструкции описывают инженера данных как «единорога», который должен обладать всеми мыслимыми навыками работы с данными, не все инженеры данных выполняют один и тот же тип работы или обладают одинаковым набором навыков. Зрелость данных (data maturity) — это полезное руководство для понимания типов проблем с данными, с которыми может столкнуться компания по мере расширения своих возможностей обработки данных. Полезно взглянуть на некоторые важные различия в видах работы, которую выполняют инженеры по работе с данными. Хотя это простые различия, они проясняют, чем занимаются учёные по данным и инженеры данных, и позволяют избежать смешивания этих ролей в одно целое.

В науке о данных существует понятие специалистов по данным типа А и типа С. Учёные, работающие с данными типа А, где А означает анализ, сосредотачиваются на понимании и извлечении информации из данных. Учёные типа С, где С — «создание», имеют схожий опыт с учёными, работающими с данными типа A и обладают сильными навыками программирования. Учёный по данным типа Б создаёт системы, которые позволяют науке о данных работать в производстве. Заимствуя это множество учёных по данным, мы создадим аналогичное различие для двух типов инженеров данных:

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

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

Инженеры данных типов А и Смогут работать в одной компании и даже быть одним и тем же человеком! Чаще всего инженера данных типа A нанимают первым, чтобы заложить основу, а потом либо он приобретает набор навыков инженера данных типа С, либо такой инженер нанимается по мере возникновения необходимости внутри компании.

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

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

Инженер внешних данных обычно сотрудничает с пользователями внешних приложений, таких как приложения для социальных сетей, устройства Интернета вещей (IoT) и платформы электронной коммерции. Этот инженер по данным проектирует, создает и управляет системами, которые собирают, хранят и обрабатывают данные о транзакциях и событиях из этих приложений. Системы, созданные этими инженерами по обработке данных, имеют цикл обратной связи от приложения к конвейеру данных, а затем обратно к приложению (Рисунок 1-10).

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

Инженер внутренних данных обычно фокусируется на деятельности, имеющей решающее значение для нужд бизнеса и внутренних заинтересованных сторон (Рисунок 1-11). Примеры включают создание и поддержку конвейеров и хранилищ данных для информационных панелей BI, отчетов, бизнес-процессов, анализа данных и моделей машинного обучения.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Согласно распространённому в отрасли мнению, учёные, работающие с данными, тратят от 70% до 80% своего времени на сбор, очистку и подготовку данных. По нашему опыту, эти цифры часто отражают незрелость методов науки о данных и инженерии данных. В частности, многие популярные среды обработки данных могут стать узкими местами, если их не масштабировать должным образом. Учёные по данным, которые работают исключительно на одной рабочей станции, вынуждены сокращать выборку данных, что значительно усложняет подготовку данных и потенциально ставит под угрозу качество создаваемых ими моделей. Кроме того, код и среды, разработанные на местах, зачастую сложно развернуть в производстве, а отсутствие автоматизации существенно затрудняет рабочие процессы обработки данных. Если инженеры данных выполняют свою работу и успешно сотрудничают, учёным по данным, не следует тратить время на сбор, очистку и подготовку данных после первоначальной исследовательской работы. Инженеры данных должны максимально автоматизировать эту работу.

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

Аналитики данных. Аналитики данных (или бизнес-аналитики) стремятся понять эффективность и тенденции бизнеса. В то время как учёные по данным смотрят вперёд, аналитик данных обычно фокусируется на прошлом или настоящем. Аналитики данных обычно выполняют SQL-запросы в хранилище данных или озере данных. Они также могут использовать электронные таблицы для вычислений и анализа, а также различные инструменты бизнес-аналитики, такие как Microsoft Power BI, Looker или Tableau. Аналитики данных являются экспертами в области данных, с которыми они часто работают, и хорошо знакомы с определениями, характеристиками и проблемами качества данных. Типичными последующими клиентами аналитика данных являются бизнес-пользователи, руководство и руководители.

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

Инженеры машинного обучения и исследователи искусственного интеллекта. Инженеры машинного обучения (инженеры МО) пересекаются с инженерами по обработке и анализу данных. Инженеры ML разрабатывают передовые методы ML, обучают модели, а также проектируют и поддерживают инфраструктуру, запускающую процессы ML в масштабируемой производственной среде. Инженеры ML часто обладают глубокими практическими знаниями в области ML, а также методов и фреймворков глубокого обучения, таких как PyTorch или TensorFlow.

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

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

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

Исследователи искусственного интеллекта работают над новыми передовыми методами машинного обучения. Исследователи ИИ могут работать внутри крупных технологических компаний, специализированных стартапов в области интеллектуальной собственности (OpenAI, DeepMind) или академических учреждений. Некоторые специалисты частично заняты исследованиями в сочетании с обязанностями по машинному обучению внутри компании. Те, кто работает в специализированных лабораториях МО, часто на 100% посвящают себя исследованиям. Исследовательские задачи могут быть направлены на немедленное практическое применение или на более абстрактную демонстрацию ИИ. DALL-E, Gato AI, AlphaGo и GPT-3/GPT-4 — отличные примеры исследовательских проектов в области машинного обучения. Учитывая темпы развития машинного обучения, эти примеры, скорее всего, через несколько лет будут казаться причудливыми. Мы предоставили некоторые ссылки в разделе «Дополнительные ресурсы».

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

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

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

Генеральный директор. Генеральные директора (CEO — chief executive officer) нетехнических компаний обычно не интересуются деталями инфраструктур данных и программного обеспечения. Вместо этого они определяют видение в сотрудничестве с техническими руководителями и руководителями данных компании. Инженеры данных показывают, что можно делать с данными. Инженеры данных и их менеджеры создают карту того, какие данные доступны организации — как внутри компании, так и от третьих сторон — и в какие сроки. Им также поручено изучать изменения в архитектуре первичных данных в сотрудничестве с другими инженерами. Например, инженеры по данным часто активно участвуют в миграции в облака, переходе на новые системы данных или развертывании технологий потоковой передачи.

ИТ–директор. Директор по информационным технологиям (CIO — chief information officer) — это старший руководитель высшего звена, отвечающий за информационные технологии в организации; это внутренняя роль. ИТ–директор должен обладать глубокими знаниями в области информационных технологий и бизнес-процессов — одного этого недостаточно. ИТ–директора руководят организацией, занимающейся информационными технологиями, устанавливая текущую политику, а также определяя и реализуя важные инициативы под руководством генерального директора.

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

Технический директор. Технический директор (CTO — chief technology officer) похож на ИТ-директора, но смотрит шире. Технический директор владеет ключевой технологической стратегией и архитектурой для внешних приложений, таких как мобильные устройства, веб-приложения и Интернет вещей — всех важнейших источников данных для инженеров данных. Технический директор, вероятно, является опытным технологом и хорошо разбирается в основах разработки программного обеспечения и системной архитектуре. В некоторых организациях без ИТ-директора его роль играет технический директор, а иногда и операционный директор (COO — chief operating officer). Инженеры данных часто прямо или косвенно подчиняются техническому директору.

Директор по данным. Должность директора по данным (CDO — chief data officer) была создана в Capital One в 2002 году, чтобы признать растущую важность данных как бизнес-актива. Директор по данным отвечает за активы данных и стратегию компании. Они ориентированы на полезность данных для бизнеса, но должны иметь хорошую техническую подготовку. Директора по данным курируют продукты данных, стратегию, инициативы и основные функции, такие как управление основными данными и конфиденциальность. Иногда они управляют бизнес-аналитикой и разработкой данных.

Главный аналитик. Главный аналитик (CAO — chief analytics officer) — это вариант роли директора по данным. Там, где существуют обе роли, директор по данным фокусируется на технологиях и организации, необходимых для доставки данных. Главный аналитик отвечает за аналитику, стратегию и принятие решений в бизнесе. Он может курировать обработку данных и машинное обучение, хотя это во многом зависит от того, есть ли у компании роль директора по данным или технического директора.

Директор по алгоритмам. Должность директора по алгоритмам (CAO-2 — chief algorithms officer) — это недавнее нововведение в высшем руководстве, высокотехнологичная должность, ориентированная конкретно на науку о данных и машинное обучение. Директора по алгоритмам обычно имеют опыт работы в качестве индивидуальных участников и руководителей групп в проектах по науке о данных или машинному обучению. Зачастую они имеют опыт работы в области исследований в области МО и соответствующую ученую степень.

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

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

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

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

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

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

Для получения дополнительной информации о группах данных и о том, как их структурировать, мы рекомендуем Building Analytics Teams Джона Томпсона (Packt) и Data Teams Джесси Андерсона (Apress). Обе книги предоставляют четкую основу и взгляды на роли руководителей, работающих с данными, кого нанимать и как создать наиболее эффективную команду по работе с данными для вашей компании.

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

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

• Определение инженерии данных и описание того, чем занимаются инженеры данных.
• Описание типов зрелости данных в компании.
• Инженеры данных типов А и Б.
• С кем работают инженеры данных

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