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

Современный ландшафт данных ставит перед организациями беспрецедентные задачи, поскольку компаниям приходится обрабатывать тысячи документов в многочисленных форматах. Как отмечает Богдан Радута, руководитель отдела исследований FlowX.ai, это могут быть самые разные документы — от PDF-файлов и электронных таблиц до изображений и мультимедиа, которые необходимо объединить и переработать в содержательную информацию.

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

Однако традиционные подходы к инжинирингу данных не справляются со сложностью получения данных в различных форматах. «В то время как обычные конвейеры ETL [извлечение, преобразование и загрузка] отлично справляются с обработкой структурированных данных, они терпят неудачу, когда сталкиваются с неоднозначностью и изменчивостью информации реального мира», — говорит Радута. Это означает, что по мере роста разнообразия источников данных системы, основанные на правилах, становятся хрупкими и дорогими в обслуживании.

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

Учитывая всю шумиху вокруг искусственного интеллекта и данных, технологическая отрасль действительно должна быть способна справиться с таким уровнем неоднородности данных. Однако Джесси Андерсон, управляющий директор Big Data Institute, утверждает, что существует недостаточное понимание должностных ролей и навыков, необходимых для науки о данных.

По его словам, одно из заблуждений заключается в том, что специалистов в области науки о данных традиционно принимают за людей, которые создают модели и выполняют всю необходимую инженерную работу. Однако, «если вы захотите услышать, что что-то, связанное с данными, невозможно сделать, просто обратитесь в команду по хранению данных, всегда готовую сказать „нет“, и вам скажут: „Нет, это невозможно сделать“». Такое восприятие реальности не сулит отрасли ничего хорошего, поскольку проекты, связанные с данными, никуда не приводят.

Развитие менталитета

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

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

Другое определение — инженер-программист, обладающий специальными знаниями в области создания систем данных. Такие люди могут писать код и составлять SQL-запросы. Что еще более важно, они могут создавать сложные системы данных там, где человек, ориентированный на SQL, полностью полагается на менее сложные системы, часто используя инструменты low-code или no-code.

«Умение писать код — это ключевая часть инженера по данным, который является инженером-программистом», — говорит Андерсон. Поскольку от бизнес- и системного дизайна исходят сложные требования, инженеры по данным должны обладать навыками, необходимыми для создания таких сложных систем.

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

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

Уроки из научной сферы

«Когда недавно одна крупная фармацевтическая компания попыталась использовать ИИ для анализа годового объема данных о биопроцессах, она столкнулась со стеной, знакомой каждому инженеру по данным: данные были технически „доступны“, но практически непригодны для использования», — рассказывает Джастин Пронт, старший директор по продуктам компании TetraScience.

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

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

Например, анализ научных данных опирается на многомерные числовые наборы, которые, по словам Пронта, поступают из «невообразимого множества измерительных приборов, неструктурированных заметок, написанных учеными в стенах лабораторий, несогласованных пар „ключ-значение“ и рабочих процессов, настолько сложных, что самые короткие из них состоят из 40 шагов».

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

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

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

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

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

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

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

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

Инжиниринг потоков данных

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

Одной из перспективных областей ИИ, которую развивает технологический сектор, являются LLM. По словам Радуты, LLM предлагают принципиально иной подход к обработке данных. Вместо того чтобы полагаться на детерминированные правила преобразования, присущие инструментам ETL, «LLM могут понимать контекст и извлекать смысл из неструктурированного контента, эффективно превращая любой документ в источник данных для запросов», — отмечает он.

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

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