Анатомия платформы данных
Прежде чем мы перейдем к рассмотрению Data Pipeline Design Patterns, мы рассмотрим различные термины из архитектуры данных (платформа данных, DWH, Data Lake и т.д.).
Различия между платформой данных, хранилищем данных и озером данных
Прежде чем углубляться в мир платформ данных, давайте разберем три часто путаемых понятия: платформа данных, хранилище данных и озеро данных.
Озеро данных
Озеро данных — это хранилище, которое содержит огромные объемы необработанных, неструктурированных, полуструктурированных и структурированных данных в их собственном формате. Оно предназначено для хранения данных из различных источников, таких как устройства IoT, социальные сети, web logs, датчики и многое другое.
Самая простая аналогия для понимания datalake — это сравнение с папкой Windows: вы можете хранить и организовывать гибким образом различные файлы независимо от их формата. Озеро данных поддерживает широкий спектр типов и форматов данных, включая текст, изображения, видео и т.д. (JSON, XML, CSV, Parquet, Avro), обеспечивая при этом основу для использования, например, в advanced analytics , машинном обучении или в проектах Data Science.
Хранилища данных
Хранилище данных — это централизованный репозиторий, в котором хранятся структурированные (или полуструктурированные), очищенные и обработанные данные из различных источников. Так же, как библиотека систематически хранит и организует книги для легкого доступа и поиска, хранилище данных организует структурированные данные из различных источников в централизованном репозитории.
Данные очищаются, преобразуются и структурируются в предопределенные форматы, что делает их оптимизированными для аналитических запросов и отчетов, обеспечивая при этом высокую производительность для бизнес-аналитики (BI) и процессов принятия решений.
Платформа данных
Платформа данных служит единой системой для эффективного управления и анализа больших наборов данных. Она объединяет такие компоненты, как базы данных, озера данных и хранилища данных для обработки структурированных и/или неструктурированных данных в зависимости от вариантов использования.
Эта инфраструктура предлагает инструменты и услуги для различных задач, связанных с данными, таких как прием, интеграция, преобразование, хранение, обработка, анализ и визуализация. Кроме того, используя облачные технологии, платформы данных обеспечивают масштабируемость, гибкость и экономическую эффективность во всех операциях компании с данными.
Общие компоненты платформы данных
Хотя архитектурные особенности платформ данных могут различаться, они обычно разделяют фундаментальные слои. Хотя эти слои могут быть организованы и вложены по-разному для решения конкретных вариантов использования (различных потоков данных), они, как правило, имеют одни и те же фундаментальные компоненты:
- Data sources (Источники данных): На этом уровне вы найдете все ваши источники данных. Они могут быть: структурированными, например, данные из вашей ERP, CRM, базы данных клиентов и т.д., полуструктурированными, например, NoSQL, Json, XML и т.д. или неструктурированными, например, PDF, изображения, видео, социальные сети…
- Ingestion: Платформам данных нужны механизмы для приема данных из различных источников данных в уровень хранения. Это может включать методы пакетного приема, потокового приема (в реальном времени) или их комбинацию. Распространенные инструменты и технологии, используемые для приема данных, включают Apache Kafka, AWS Kinesis или пользовательские процессы ETL.
- Storage (Хранение): Цель уровня хранения, как следует из его названия, заключается в хранении данных, при этом обрабатывая различные типы, поступившие из разных источников. Хранилище может включать традиционные реляционные базы данных, распределенные файловые системы, объектное хранилище или специализированные базы данных, такие как базы данных временных рядов.
- Processing (Обработка): После того, как данные сохранены (или связаны с приемом), их часто необходимо обработать и преобразовать, прежде чем их можно будет проанализировать или использовать приложениями. Обработка данных может выполняться пакетами или в режиме реального времени, часто путем создания ELT или ETL.
- Consumption (Потребление): На этом уровне предоставляются механизмы для запроса, анализа и визуализации данных для получения информации или принятия решений на основе данных. Такие технологии, как SQL-движки, инструменты визуализации данных, такие как Tableau или Power BI, и фреймворки машинного обучения, такие как TensorFlow или PyTorch, обычно используются для аналитики и BI.
8 ключевых паттернов проектирования data pipeline, которые нужно знать
Давайте представим компанию, которая собирает данные. Будь то транзакции клиентов, данные с IoT-датчиков или бесконечный поток мнений или комментариев из соцсетей. Для этого нужен надежный способ перемещать эти данные из точки А в точку Б, обрабатывая их по пути. Вот тут и вступают в игру паттерны проектирования data pipeline. Это, по сути, архитектурные чертежи для перемещения и обработки данных.
Почему выбор правильного паттерна для Data Pipeline так важен? Нужно подбирать подходящий паттерн под задачу: если вы используете batch-процессинг, то сможете сэкономить деньги, но пожертвуете скоростью; выберете потоковую обработку в реальном времени – получите мгновенные инсайты, но это может потребовать большего бюджета.
В этом руководстве мы разберем паттерны, которые помогут проектировать Data Pipeline.
Batch Processing Pattern (Паттерн пакетной обработки)
Представьте, что вы копите грязное белье всю неделю, чтобы устроить большую стирку на выходных. По сути, это и есть batch-процессинг для данных. Вместо обработки каждого элемента данных сразу по его поступлению вы собираете данные в одном месте и обрабатываете их по расписанию. Это как выделить «день стирки» для ваших данных.
Этот подход очень экономичен, так как системы не работают постоянно. Кроме того, он проще в управлении – идеально подходит для таких задач, как создание месячных отчетов или анализ исторических данных. Можно сказать, это подход «тише едешь – дальше будешь» в обработке данных.
Stream Processing Pattern (Паттерн потоковой обработки)
Теперь представьте, что у вас есть волшебная стиральная машина, которая может стирать каждый предмет одежды сразу, как только он загрязнился. Это и есть потоковая обработка. Она обрабатывает данные в реальном времени, по мере их поступления.
Этот паттерн нужен, когда важна мгновенная реакция – например, для обнаружения мошеннических транзакций или анализа настроений в соцсетях во время крупного события. Да, поддержка таких систем, работающих 24/7, может быть дороже, но если нужны мгновенные инсайты, альтернатив нет.
Паттерн проектирования Lambda Architecture
Вариант 1 — Унифицированный/Объединенный Serving слой
Вариант 2 — Отдельные Serving слои
Вот где начинается интересное.
Lambda-архитектура – это как иметь обычную стиральную машину для еженедельных стирок и ту самую волшебную машину для мгновенной стирки. Вы запускаете две системы параллельно – одну для пакетной обработки, другую для потоковой.
Это здорово, потому что вы получаете лучшее из обоих миров: обновления в реальном времени, когда это необходимо, плюс глубокая обработка данных в пакетном режиме для аналитики.
Минус? Вам придется поддерживать две системы, поэтому ваша команда должна быть достаточно гибкой, чтобы работать с разными технологиями, при этом сохраняя согласованность определений данных.
Паттерн проектирования Kappa Architecture
А что если есть способ получить что-то похожее на Lambda, но более минималистичное?
Разработчики Apache Kafka задали себе тот же вопрос и придумали архитектуру Kappa. Вместо того чтобы иметь оба слоя – пакетной обработки и потоковой – всё происходит в реальном времени, а весь поток данных хранится в центральном логе, таком как Kafka.
Это значит, что по умолчанию вы обрабатываете всё так же, как в паттерне Stream Processing. Но если вам нужна пакетная обработка для исторических данных, вы просто воспроизводите соответствующие логи.
Этот подход идеально подходит для работы с IoT-датчиками или аналитикой в реальном времени, где исторические данные – это просто коллекция прошлых событий, обработанных в реальном времени. Простота – в её главной силе: одна система для всех задач!
Паттерн ETL (Extract, Transform, Load)
Еще один классический подход к работе с данными – это ETL. Это похоже на подготовку еды: вы собираете все продукты (extract), готовите их (transform), а затем раскладываете по контейнерам (load).
Этот паттерн отлично подходит, когда вы точно знаете, что хотите сделать с данными, и вам нужно добиться стабильности при каждом запуске. Например, финансовая отчетность или соответствие нормативным требованиям, где нельзя допускать неожиданных изменений. Да, это немного старомодно, но традиционные методы остаются таковыми не просто так – они проверены временем.
Паттерн ELT (Extract, Load, Transform)
ELT меняет подход ETL с ног на голову. После того как вы «закупили продукты» (extract), вы сначала складываете их в холодильник (load), а уже потом решаете, что из них приготовить (transform). Вы загружаете данные в хранилище сразу, а затем определяете, как с ними работать.
Этот подход великолепен, если вы пока не знаете, как именно будете использовать данные, или если разные команды могут преобразовывать их по-разному. Он более гибкий, чем ETL, и отлично работает с низкой стоимостью современных систем хранения данных.
Паттерн проектирования Data Mesh
Здесь мы подходим к действительно современным подходам. Data Mesh превращает вашу организацию данных в федерацию независимых «государств». Вместо того чтобы одна центральная команда управляла всеми данными (и становилась узким местом!), каждая команда или отдел самостоятельно управляет своими пайплайнами данных.
Это идеально для крупных компаний, где, например, маркетинговая команда хочет использовать данные клиентов для своих целей, а продуктовая команда нуждается в совершенно других данных для аналитики функционала. Главное – убедитесь, что у вас достаточно процессов, чтобы избежать появления data silos (изолированных хранилищ данных).
Паттерн проектирования Medallion Architecture: Data Lakehouse
Data Lakehouse – это как «вилка-ложка» среди архитектурных паттернов, объединяющая лучшие черты data warehouse и data lake. Вы получаете структуру и производительность хранилища с гибкостью и масштабируемостью озера данных. Хотите запускать SQL-запросы на структурированных данных, при этом сохраняя сырые файлы для экспериментов ваших дата-сайентистов? Data Lakehouse справится с этим!
Данные в Medallion Architecture обычно проходят через три стадии:
- Bronze: Сырые данные попадают сюда первыми, сохраняясь в их изначальном виде. Это как цифровая зона разгрузки – данные сохраняются точно так, как были получены, со всеми «шероховатостями».
- Silver: На этом этапе данные очищаются, проверяются и приводятся в соответствие со схемами. Средний слой удаляет дубликаты, обрабатывает пропущенные значения и гарантирует качество данных.
- Gold: Финальная, доработанная стадия, где данные преобразуются в формат, готовый для аналитики. Здесь находятся агрегированные таблицы, производные метрики и бизнес-ориентированные представления, оптимизированные под конкретные задачи.
Event-Driven Data Architecture
К Data Lake можно также отнести и EDA подход.
Следующая диаграмма иллюстрирует идею использования микросервисов для приема данных в режиме реального времени и предоставления их для Data LakeHouse или Data Lake, используя возможности полуструктурированных данных.
Большинство новых исходных систем управляются через API, что означает, что они могут работать по принципу push/pull:
- Логика push-уведомлений работает с использованием потоковых API, которые экспортируют события (обычно в формате JSON) в тот момент, когда они происходят в источнике.
- Логика извлечения (pull) работает очень похоже на то, что мы называем «пакетной обработкой», где наши конвейеры данных отвечают за запрос информации из исходной системы, используя параметры для уменьшения объема данных, перемещаемых через конвейеры данных (дельты).
Сосредоточившись в основном на логике push, микросервисы, которые могут быть построены на многих языках, например, Python, .NET, Java и т. д., будут отвечать за подписку на конечные точки/вебхуки и передачу событий в определенный топик. Эти топики (topics) специфичны для каждого события и должны иметь уникальное соглашение об именовании или определение. Для этих частей некоторые технологии гарантируют постановку в очередь, репликацию и разбиение на разделы, например, Apache Kafka.
YouTube Videos
10 ETL Design Patterns (Data Architecture | Data Warehouse)
- Рассматриваются десять различных шаблонов проектирования ETL.
- Знание этих шаблонов необходимо для создания хранилища данных.
Data Architecture 101: The Modern Data Warehouse
- Важность выбора стратегии для обработки данных.
- Описание стереотипного подхода к современному хранилищу данных.
- Процесс пакетной загрузки данных в озеро данных.
Leave a Reply