Корпоративные хранилища данных известны давно, и сегодня соответствующие технологии привели к созданию масштабируемых систем, способных обрабатывать большие объемы структурированных данных. Еще в период демократизации массово-параллельных СУБД и роста популярности Hadoop была в целом решена задача линейного масштабирования аналитических нагрузок, но с транзакционными базами такого не случилось. Однако, чтобы современному бизнесу делать правильные выводы в реальном времени, нужен немедленный доступ ко всем поступающим данным и их многоструктурный анализ. Хранилища здесь не подходят в том числе и по экономическим причинам — это дорогой инструмент, особенно при обработке больших объемов неструктурированных и квазиструктурированных данных.
Для хранения сведений из различных источников с целью их обработки всевозможными аналитическими инструментами начали создавать озера данных — вместилища сырых обычно неструктурированных, данных. Озера хороши для организации беспроблемного хранения, но на берегу остались такие важные функции, как поддержка транзакционной нагрузки и гарантированное обеспечение качества данных. А отсутствие в озерах согласованности, изоляции и безопасности данных делает практически невозможным смешивание операций добавления и чтения, а также пакетных и потоковых заданий.
Вместе с тем для цифровизации требуются недорогие масштабируемые емкости для данных, одинаково хорошо поддерживающие и приложения OLAP, и OLTP: аналитика через SQL-запросы, мониторинг в реальном времени, а многим приложениям искусственного интеллекта нужны и модели обработки неструктурированных данных, не имеющих четкой структуры. Попытки совмещения озер и хранилищ со специализированными СУБД, оптимизированными для потоковой обработки, аналитики временных рядов, графов и пр., вынудили компании собирать в своих локальных или облачных средах множество систем для решения разных задач и исследования данных в разных форматах. Но больше технологий не значит лучше — подобный зоопарк лишь усложнил владение данными и привел к недопустимым задержкам. Теперь инженеры по данным вынуждены строить и поддерживать ETL-конвейеры для перемещения данных между различными платформами.
Недавно появилась иная модель гибридной архитектуры данных, призванная объединить достоинства классических хранилищ с гибкостью озер — LakeHouse. Утверждается, что именно концепция «домов» у озера будет отвечать запросам цифровых предприятий. Дизайн подобных поселков основан на реализации структур и функций управления данными, аналогичных тем, которые используются в хранилищах, но поверх недорогого облачного хранилища данных в открытых форматах. Это сулит поддержку транзакционных нагрузок — конвейеры данных способны одновременно считывать и записывать данные, а также готовить данные для аналитических приложений. Можно использовать инструменты бизнес-аналитики для работы непосредственно с исходными данными, повышая их актуальность при минимальных затратах.
Открытая архитектура LakeHouse расширяет традиционную аналитику, совмещая гибкость озер со строгостью хранилищ, суля пользователям выполнение требований ACID: согласованность — несколько сторон одновременно считывают или записывают данные, обычно используя популярный инструментарий SQL-запросов; атомарность и полнота — применение апробированных схем и классических моделей хранилищ; изоляция хранения от вычислений для облегчения масштабирования. Открытость стандартизованных форматов хранения данных, таких как Apache Parquet или Iceberg, позволяет «домам» у озера через различные популярные инструменты напрямую обращаться к данным в условиях разнообразных рабочих нагрузок — от алгоритмов машинного обучения, распределенных вычислений и до SQL-запросов, которыми владеет любой бизнес-аналитик. Несмотря на то, что такие нагрузки требуют разных технологий, все они полагаются на один репозиторий данных, образованный, в частности, из физических файлов вроде JSON, что относительно недорого.
Возможно, гибридная архитектура поселений «домов» у озера скоро обзаведется эффективными технологиями, и тогда у нее будут все шансы на существование, однако LakeHouse пока еще в стадии становления и формирования инструментария. Потенциально приозерные поселения предоставляют гибкие и широкие возможности работы с данными, но они менее управляемы по сравнению с хранилищем, которое по аналогии можно сравнить с многоквартирным домом. Ключ к получению ценной информации для оперативного принятия бизнесрешений по-прежнему принадлежит СУБД.
Работа с данными для LakeHouse не сводится лишь к координации процессов хранения, сбора и обработки. При передаче через цифровые носители информация ведет себя как вода: она течет, смешивается, стремясь к самой низшей точке — потребителю. Тривиальное сливается с глубоким, ложное с истинным, доверенное с вредоносным, способным отравить «воду». Возможно поэтому, в отличие от классических хранилищ, ориентированных на инструменты бизнес-аналитики, парадигму LakeHouse часто называют ИИ-центричной — соответствующие инструменты не только могут наполнять из озера обучающие модели машинного обучения, но и фильтровать «воду», минимизируя риски информационного инфекцирования.
Цифровые технологии — это способ развития предпринимательского интеллекта как способности уловить благоприятные возможности и тенденции рынка, собрать воедино все необходимые ресурсы для выпуска востребованной продукции или услуги. Как бы то ни было, для наилучшего использования конвергентных данных компании все больше внимания сегодня уделяют оптимизации способов хранения, сбора и аналитики данных и, как следствие, проектированию «домов у озера».
Дмитрий Волков
DOI: 10.51793/OS.2023.36.65.002