Некогда простое озеро данных (data lake) продолжает развиваться, становясь движущей силой корпоративной аналитики. Сегодня, когда искусственный интеллект стучится в двери корпораций, это приобретает все большее значение, сообщает портал Data Center Knowledge.

Когда в начале 2010-х возникла идея озера данных, оно показалось некоторым людям подходящей своему времени архитектурой. Data lake представляло собой репозиторий неструктурированных данных, использующий новые недорогие форматы облачного объектного хранения, такие как Amazon S3. В нем можно было бы располагать большие объемы данных, поступающих из Интернета.

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

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

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

Потребность в озерах данных

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

Amazon, Google, Yahoo, Netflix и др. создали свои собственные инструменты обработки данных. Они часто основывались на распределенных движках Apache Hadoop и Spark. Новые системы обрабатывали типы данных, которые были менее структурированы, чем традиционные реляционные типы данных, хранившиеся в аналитических хранилищах данных того времени.

Системным инженерам той эпохи эта архитектура принесла определенные преимущества. «Болотная», или «озерная» архитектура стала основой для первых приложений для поиска, обнаружения аномалий, оптимизации цен, клиентской аналитики, систем рекомендаций и многого другого.

Такая более гибкая обработка данных была насущной потребностью растущих веб-гигантов. То, что автор книги «Distributed Analytics» Томас Динсмор назвал «цунами» из текста, изображений, аудио, видео и других данных, просто не подходило для обработки в реляционных базах данных и хранилищах данных. Еще один их недостаток: затраты на хранение данных постепенно увеличивались по мере загрузки каждого пакета данных.

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

Эту эволюцию возглавили решения, созданные компаниями собственными силами, а также звездными стартапами, такими как Databricks и Snowflake, но еще многие другие находятся в стадии разработки. Их разнообразные архитектуры сегодня находятся под пристальным вниманием проектировщиков дата-центров, которые ищут новые возможности в области ИИ.

Эволюция Data Lake: от Lake к Lakehouse

В игре на поле data lake среди прочих принимают участие такие решения, как Amazon Lake Formation, Cloudera Open Data Lakehouse, Dell Data Lakehouse, платформа Dremio Lakehouse, Google BigLake, IBM watsonx.data, Microsoft Azure Data Lake Storage, Oracle Cloud Infrastructure, Scality Ring и Starburst Galaxy.

Как видно из этого перечня, тенденция заключается в том, чтобы называть предложения «озерами-хранилищами» (lakehouse), а не озерами данных. Название предполагает нечто более близкое к традиционным хранилищам данных, предназначенным для обработки структурированных данных. И, да, это еще одна натянутая аналогия, которая, как и data lake до нее, стала предметом тщательного изучения.

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

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

  • Новые форматы таблиц. Например, Delta Lake и Iceberg, построенные поверх облачного объектного хранилища, обеспечивают поддержку ACID-транзакций для Apache Spark, Hadoop и других систем обработки данных. Часто используемый формат Parquet может помогать оптимизировать сжатие данных.
  • Каталоги метаданных. Такие средства, как Snowflake Data Catalog и Databricks Unify Catalog, являются лишь некоторыми из инструментов, которые выполняют поиск данных и отслеживают их происхождение. Последнее свойство важно для обеспечения качества данных для аналитики.
  • Механизмы обработки запросов. Они предоставляют общий SQL-интерфейс для высокопроизводительного запроса данных самых разных типов, хранящихся в самых разных расположениях. В качестве примеров можно привести PrestoDB, Trinio и Apache Spark.

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

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

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

Проблемы безопасности и управления Data Lake

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

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

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

Новые форматы таблиц изменили это. В последние годы появились такие решения, как Delta Lake, Iceberg и Hudi, которые значительно улучшили поддержку обновления данных. По словам Мохана, стандартизация и широкая доступность таких инструментов, как Iceberg, дают конечным пользователям больше возможностей при выборе систем. Это приводит к снижению затрат и усилению технического контроля.

Озера данных для генеративного ИИ

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

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

«ИИ нового поколения преобразит управление данными», — полагает Ганапати «G2» Кришнамурти, вице-президент по озерам данных и аналитике AWS, создателя объектного хранилища S3 и множества облачных инструментов для обработки данных.

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

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

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

«Озера ИИ-данных приведут к созданию более гибких дата-центров», — считает Дипто Чакраварти, директор по продуктам Cloudera, пионера Hadoop, который продолжает предоставлять новые инструменты, ориентированные на данные.

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

«В определенные дни определенных месяцев команды по работе с данным хотят перенести данные онпремис. В других случаях они хотят перенести их обратно в облако. Но на перемещение всех этих рабочих нагрузок с данными туда и обратно существует „налог“», — отмечает Чакраварти.

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

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

В качестве примера Калвесберт приводит Watsonx.data — центральный репозиторий данных в экосистеме Watsonx: теперь он позволяет настраивать ИИ-модели, которые могут быть размещены в ИТ-среде предприятия.

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

«В ближайшем будущем ожидается расширение локальной обработки данных», — полагает Джастин Боргман, председатель правления и генеральный директор компании Starburst, которая превратила раннюю разработку движка запросов Trino SQL в полноценное предложение уровня озера-хранилища, которое может извлекать из него данные.

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

«Развитие ИИ приведет к тому, что больше данных вернется в локальный или гибридный мир. Предприятия вряд ли захотят отправлять все свои данные и модели ИИ в облако, потому что их перенос обходится дорого», — говорит Боргман.

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

Всегда ли чем больше данных, тем лучше?

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

Очевидно, что доступ к большому объему данных бесполезен, если их невозможно понять, считает Мерв Адриан, независимый аналитик компании IT Market Strategy. «Чем больше данных, тем лучше, если вы можете их использовать. Но если не можете, это не принесет вам никакой пользы», — поясняет он.

Адриан позиционирует такие программы, как Iceberg и Delta Lake, как предоставляющие описательный слой поверх обширных данных, которые помогут в аналитике с использованием ИИ и МО. Организации, инвестировавшие в эти технологии, увидят преимущества при переходе в этот новый дивный мир.

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

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

Озеро данных продолжает существовать в той или иной форме. Мохан выразил это словами: «Озера данных никуда не делись. Да здравствуют озера данных!».