Комментарии

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

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

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

Хотя прогнозируется, что 80% предприятий будут использовать API-интерфейсы GenAI или приложения с поддержкой GenAI, только 25% банков внедрили критически важные данные в целевую архитектуру, и это только одна отрасль. Таким образом, необходимо отказаться от хранилищ данных и перейти к более современным фабрикам данных и ячейкам данных.

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

В ходе такого перемещения может происходить тиражирование и синхронизация данных, но чаще всего выполняется интеграция (извлечение из различных источников и объединение для дальнейшего использования), обычно в автоматизированном режиме. Для работы с поточными данными применяются высокомасштабируемые надежные конвейеры с определенными соглашениями об уровне обслуживания, регламентирующими производительность, допустимую задержку и вероятность ошибок. Если архитектура управления данными распределенная, она может быть построена по принципу сетки (Data Mesh) или матрицы (Data Fabric); важную роль при этом также может играть система управления нормативно-справочной информацией (НСИ).

Для организации конвейеров данных применяются технологии разного уровня сложности: в числе самых простых — обратные HTTP-вызовы (webhook), механизмы публикации-подписки и сервисы IFTTT, к более сложным относятся микросервисы. Конвейеры могут иметь различную архитектуру: пакетная обработка, когда группы записей перемещаются от системы к системе по мере завершения обработки; событийно-зависимая архитектура; архитектуры Lambda и Kappa, сочетающие обработку реального времени и пакетную; конвейеры на основе микросервисов.

Существует масса облачных платформ для построения конвейеров данных с функциями интеграции и работы с потоками. Популярны, в частности, бессерверные архитектуры наподобие AWS Lambda и Google Cloud Functions. Конвейеры реализуют на разных языках программирования, но исследователи и инженеры данных обычно пользуются Python. Возможности интеграции данных и создания конвейеров также есть во многих СУБД, хранилищах данных, системах организации озер данных, платформах ИИ и машинного обучения.

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

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

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

Важная функция конвейеров, особенно для регулируемых отраслей, — отслеживание «родословной» данных (data lineage): соответствующие механизмы позволяют выяснять происхождение и все изменения данных на протяжении их жизненного цикла. Такие функции есть в платформах каталогов данных и руководства данными и системами ИИ.

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

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

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

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

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

Развития архитектуры баз данных сулит обширный спектр тенденций и возможных проблем:

Пограничные вычисления

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

Конфиденциальность и безопасность данных

В эпоху растущих объемов данных сохранение конфиденциальности и безопасности данных приобретает первостепенное значение (Jonny Bairstow, (2024)). По мере ужесточения нормативной базы и роста киберугроз приходится учиться хорошо ориентироваться в сложном ландшафте управления данными для того, чтобы обеспечить соответствие строгим нормам и усилить систему безопасности, защищая тем самым конфиденциальную информацию от возможных утечек и несанкционированного доступа и использования.

Федеративная модель управления данными

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

Квантовые базы данных

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

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

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

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

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

Бессерверная и микросервисная модели: в чем разница?

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

Микросервисы. Данное технологическое решение представляет собой более компактную разновидность сервис-ориентированной архитектуры (SOA), дающую программистам полный доступ к необходимым библиотекам, размещенным на облачных серверах. Оно позволяет развертывать множество функциональных модулей, а также ряд протоколов и API-интерфейсов, включая JSON, RESTful, AMQP, SOAP и другие.

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

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

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

Ключевые факторы, которые следует учитывать при выборе модели развертывания

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

— Бюджет: оцените краткосрочные и долгосрочные затраты каждой модели развертывания. Учитывайте первоначальные инвестиции в оборудование и программное обеспечение, а также текущие расходы на обслуживание, поддержку и инфраструктуру.
— Настройка. Учитывайте уровень настройки, необходимый вашей организации. Если вам нужны широкие возможности настройки или уникальные функции, вы можете предпочесть локальную или размещенную модель, которая обычно обеспечивает большую гибкость в этой области.
— Безопасность. Оцените требования безопасности вашей организации и убедитесь, что выбранная модель развертывания адекватно решает ваши проблемы. Это может включать меры физической безопасности, стандарты шифрования данных и соблюдение соответствующих нормативных рамок.
— ИТ-ресурсы. Изучите внутренние технические знания и возможности вашей организации. Выбор размещенной модели или модели SaaS может быть более подходящим, если у вас нет необходимых ИТ-ресурсов для управления локальным развертыванием.
— Масштабируемость. Учитывайте масштаб, в котором вам необходимо использовать программное обеспечение. Модели SaaS и хостинговые модели обычно предоставляют лучшие возможности масштабирования, которые можно легче настроить в соответствии с меняющимися потребностями организации.

Локальное развертывание включает установку программного обеспечения и управление им на вашей собственной инфраструктуре и оборудовании. Хостинговое развертывание означает, что ваше программное обеспечение размещается на сервере и в инфраструктуре стороннего поставщика, что обычно требует меньшего участия со стороны вашей организации. SaaS (Программное обеспечение как услуга) — это облачная модель доставки программного обеспечения, при которой программное обеспечение полностью управляется поставщиком и доступно пользователям через Интернет.

А каковы тогда основные различия между моделями локального, размещенного и SaaS-развертывания?

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

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

Хотелось бы услышать ваше мнение о преимуществах и недостатках размещенного развертывания и развертывания SaaS?

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

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

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

Каковы модели развертывания облачных вычислений?

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

Спасибо за ответ, также еще очень волнует вопрос — каковы проблемы облачных вычислений?

Существуют три различных типа сервисов облачных вычислений: Инфраструктура как услуга (IaaS), Платформа как услуга (PaaS) и программное обеспечение как услуга (Saas). IaaS предоставляет виртуализированные вычислительные ресурсы, PaaS предоставляет платформу для разработки и развертывания приложений, а SaaS предоставляет программные приложения через Интернет.

Каковы различные типы сервисов облачных вычислений?

Многие из вас слышали про мировой успех облачных компаний и таких компаний как Amazon Web Services, Microsoft Azure и Google Cloud Platform. Сейчас мы видим, как отечественное облако активно развивается – Яндекс Облака, Mail.ru облако и Сбербанк тоже работает в этом направлении.

Лично у меня нет опыта работы с отечественным облаками и пока они еще достаточно молодые, но, я очень надеюсь, что они справятся с задачей и у нас появятся конкурентно способные облачные провайдеры.