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

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


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

Как выбрать паттерн проектирования конвейера?

При выборе паттерна проектирования конвейера данных необходимо учитывать различные факторы проектирования. Вот некоторые из них:

• Выбор форматов источника данных.
• Какие стеки использовать.
• Выбор инструментов преобразования данных.
• Выбор варианта извлечения данных: Извлечение-преобразование-загрузка (ETL), Извлечение-загрузка-преобразование (ELT) или Извлечение-преобразование-загрузка-преобразование (ETLT).
• Как управлять измененными данными.
• Как фиксируются изменения.

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

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

Основные компоненты конвейера:

• Источник данных
• Обработка
• Целевое хранилище

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


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

• Пакетные данные: Файл с табличной информацией (CSV, JSON, AVRO, PARQUET и ...), в котором данные собираются в соответствии с определенным порогом или частотой с помощью обычной пакетной или микропакетной обработки. Современные приложения, как правило, генерируют непрерывные данные. По этой причине микропакетная обработка является предпочтительным вариантом для сбора данных из источников.
• Транзакционные данные: Данные приложений, такие как RDBMS (реляционные данные), NoSQL, Big Data.
• Потоковые данные: Приложения реального времени, использующие Kafka, Google Pub/Sub (публикация/подписка), Azure Stream Analytics или Amazon Stream Data. Приложения потоковых данных могут взаимодействовать в режиме реального времени и обмениваться сообщениями, чтобы соответствовать требованиям. При проектировании архитектуры предприятия обработка данных в реальном времени и потоков является очень важным компонентом проектирования.
• Плоские файлы — PDF-файлы или другие нетабличные форматы, содержащие данные для обработки. Например, медицинские или юридические документы, из которых можно извлечь информацию.

Целевые данные определяются в зависимости от требований и потребностей дальнейшей обработки. Обычно целевые данные создаются для обеспечения работы нескольких систем. В концепции Data Lake данные обрабатываются и хранятся таким образом, чтобы аналитические системы могли получать информацию, а процессы AI/ML могли использовать данные для построения прогнозных моделей.

Архитектуры и примеры

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

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

Вот логическая схема конвейера хранилища данных:


Вот логическая схема конвейера Data Lake:


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

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

• Пакетный ETL-конвейер в GCP — источником могут быть файлы, которые необходимо загрузить в аналитический механизм Business Intelligence (BI). Облачное хранилище является средой передачи данных внутри GCP, а затем Dataflow используется для загрузки данных в целевое хранилище BigQuery. Простота такого подхода обеспечивает многократное использование этого паттерна и его эффективность при простых преобразованиях. С другой стороны, если нужно построить сложный конвейер, то этот подход не слишком эффективный и действенный

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

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

Схемы платформы GCP созданы в Google Cloud Developer Architecture.

Как выбрать архитектуру для конвейера данных?

Существует множество подходов к проектированию и реализации конвейеров данных. Главное — выбрать тот, который отвечает вашим требованиям. Появляются новые технологии, которые обеспечивают более надежные и быстрые реализации конвейеров данных. Google Big Lake — это новый сервис, который предлагает новый подход к вводу данных. BigLake — это механизм хранения, который объединяет хранилища данных, позволяя BigQuery и свободным фреймворкам, в частности, Spark, получать доступ к данным с тонким контролем доступа. BigLake обеспечивает повышенную производительность запросов в многооблачных хранилищах и открытых форматах, таких как Apache Iceberg.

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

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

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

Если вы планируете построить конвейер данных для проекта из области Data Science, то вам следует рассмотреть все источники данных, которые потребуются ML-модели для дальнейшей разработки. Процесс очистки данных — это большая задача для команды инженеров по обработке данных, которая должна иметь адекватные и достаточные наборы инструментов для преобразования. Проекты в области науки о данных работают с большими массивами данных, что требует планирования их хранения. В зависимости от того, как будет использоваться модель машинного обучения, должна применяться либо обработка в реальном времени, либо пакетная обработка.

Что дальше?

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