Введение
В нашем блоге мы часто обсуждаем разные инструменты для пространственного анализа.
Сегодня рассмотрим интересную задачу — подготовку данных для анализа.
Если вспомнить любую методологию анализа данных, будь то KDD (Knowledge Discovery in Databases), SEMMA (Sample, Explore, Modify, Model, Assess) или CRISP-DM (Cross-Industry Standard Process for Data Mining), то увидим, что все они включают в себя этапы поиска, извлечения, подготовки, очистки и трансформации данных для дальнейшего анализа и моделирования.
На рисунке — подготовка данных на примере CRISP-DM. Для автоматизации этих процессов многие компании разрабатывают специализированные решения — «Data pipelines» или «Конвейеры данных».
Давайте разберёмся, что это такое, как построить собственный конвейер.
Что такое конвейеры данных?
Итак, конвейер данных — это набор процессов и инструментов, автоматизирующих сбор, перемещение и обработку данных из различных источников в системы назначения.
Конвейер данных служит технологической магистралью, по которой передаются «сырые» данные, подвергаются необходимым преобразованиям, таким как очистка, фильтрация и агрегирование. В результате «прохождения» по конвейеру данные предоставляются в формате, пригодном для анализа.
Зачем нужны конвейеры данных?
Для разработки конвейеров данных есть несколько причин. В первую очередь — это интеграция данных из разнородных источников и подготовка их для анализа, и две менее очевидных — это организации решений для репликации данных и виртуализации данных.
Интеграция и обработка данных из разнородных источников
У большинства компаний есть множество приложений и источников структурированных и неструктурированных данных, которые плохо совместимы друг с другом.
Задача дата-инженеров – превратить разнородную информацию в данные, подходящие для анализа. С ростом объёма данных и появлением новых источников это становится всё более трудоёмким процессом.
Вот почему компании создают конвейеры данных: во-первых, конвейеры данных собирают данные из разрозненных разнородных источников, во-вторых — автоматизируют обработку и подготовку данных. И в-третьих — приводят данные к единому формату и преобразуют их для совместимости с разными системами, исправляя дублирования, пропуски и ошибки.
Если вы работаете с готовыми наборами данных или данными из одного источника, конвейер может и не понадобиться. Но если нужно на регулярной основе объединять данные из разнородных источников, конвейер может заметно упростить эту задачу.
Представьте, что вы хотите узнать, как средний балл учеников в районах города связан со средним доходом или численностью населения. Для этого нужно собрать данные о школах, доходах и численности населения в заданных районах. Один раз сделать это вручную можно, но если вам нужно повторять этот анализ регулярно – нужен конвейер данных.
Репликация и виртуализация данных
Кроме интеграции и подготовки данных для анализа конвейеры используются для решения ещё двух важных задач: организации репликации данных и виртуализации данных.
Репликация данных включает в себя непрерывное копирование данных в другое хранилище для обеспечения нужной производительности или для организации резервного копирования и восстановления после сбоев.
Виртуализация данных позволяет получать доступ к распределённым базам данных, а также к нескольким разнородным хранилищам данных и просматривать их как единую базу данных.
Пример простого конвейера данных
В этом примере у нас есть четыре источника данных: два структурированных (таблицы Excel) и два неструктурированных (это изображения и тексты на естественном языке).
С помощью нескольких шагов извлекаем структурированные данные из неструктурированных, стандартизируем названия и единицы измерения. После того как все данные будут совместимы, создаём единую базу данных.
Затем эта база данных может быть использована аналитиками, дата-сайентистами и бизнес-экспертами.
Схемы конвейеров данных (ETL и ELT)
В системах обработки данных применяются две основные схемы конвейеров данных — ETL (Extract, Transform, Load) и ELT (Extract, Load, Transform), каждая из которых имеет особенности и области применения.
ETL (Extract, Transform, Load). В этой схеме данные сначала извлекаются из различных источников, затем преобразуются в нужный формат, а затем загружаются в целевое хранилище данных. В основном ETL используется, когда данные хранятся в хранилище данных (Data warehouse). Эта схема часто применяется в ситуациях, когда необходимо обеспечить высокое качество и целостность данных до их загрузки в хранилище. Примером может служить интеграция данных из различных бизнес-систем для создания отчётов и аналитики.
ELT (Extract, Load, Transform). В архитектуре на основе ELT данные сначала загружаются в озеро данных (Data lake), и уже потом преобразуются в состояние, пригодное для использования. Эта схема используется, когда важно быстро загрузить большие объёмы данных, а трансформация может быть выполнена позже, в зависимости от потребностей. Примером применения ELT может служить анализ больших данных из интернета вещей (IoT), где сначала собираются сырые данные, а затем обрабатываются для создания аналитических моделей.
Структурированные, полуструктурированные и неструктурированные данные в конвейерах
Конвейеры данных работают со всеми типами данных: структурированными, такими как электронные таблицы и базы данных, полуструктурированными данными, такими как XML и JSON файлы, и неструктурированными данными, такими как тексты на естественном языке, изображения, видео- и аудиозаписи.
Структурированные данные легко анализировать с помощью SQL-запросов и ETL-инструментов. Для обработки неструктурированных данных требуются специализированные технологии, такие как NLP, распознавание изображений и обработка аудио/видео и другие.
В зависимости от целей конвейера, неструктурированные данные можно либо преобразовать в структурированные, либо оставить в исходном виде. Вот пример конвейера данных, в котором неструктурированные данные (изображения) остаются без обработки.
В этом примере создаётся хранилище структурированных данных и ссылок на файлы изображений.
Вместо того чтобы распознавать изображения и извлекать из них структурированные данные, мы создали каталог, связывающий изображения с соответствующими данными в базе данных.
Пользователь сможет по ссылке просматривать необработанные изображения для каждой строки электронной таблицы по мере необходимости.
Хранение данных: озёра данных, базы и хранилища данных и lakehouse
Данные могут храниться несколькими различными способами. Мы рассмотрим четыре основных: озёра данных (Data lakes), базы данных (Databases), хранилища данных (Data warehouse), а также относительно новое понятие — Data Lakehouse.
Давайте кратко разберём каждый из них.
Хранилище данных (Data warehouse)
Хранилище данных — это специализированная система для хранения, систематизации и анализа больших объёмов структурированных данных из различных источников.
Оно объединяет текущие и исторические данные для получения аналитической информации. Данные организуются в «витрины данных», как товары на полках на настоящем складе.
Хранилища данных используются для анализа тенденций, создания отчётов и информационных панелей.
С помощью ETL-процессов данные регулярно извлекаются из разных источников, очищаются, преобразуются в согласованный формат и загружаются в хранилище для последующего анализа.
Особенность хранилищ данных — это использование транзакций для обеспечения целостности данных. О том, что такое транзакции и требования ACID, можно почитать здесь.
Хранилища данных используют схему «при записи» (schema-on-write), где структура данных определяется перед их сохранением.
Примеры хранилищ данных: Arenadata DB, Greenplum, AWS Redshift, Apache Hive, Google BigQuery, Microsoft Azure Synapse Analytics, Snowflake, Teradata, IBM Db2 Warehouse и Oracle Exadata.
База данных (Database)
Базы данных — это системы для хранения, управления и извлечения структурированных данных. Несмотря на сходство с хранилищами данных, базы данных обычно используются для обработки транзакционных данных, ежедневных операций и приложений реального времени.
Существует несколько типов баз данных, включая реляционные базы данных, базы данных NoSQL и базы данных In-memory. Каждый тип подходит для конкретных требований к хранению и обработке данных.
Базы данных обеспечивают целостность данных, поддерживают параллельный доступ и предоставляют механизмы для запросов и извлечения данных. Примеры включают MySQL (реляционная), MongoDB (NoSQL) и Redis (In-memory).
Озеро данных (Data lake)
Современные компании часто работают с неструктурированными и полуструктурированными данными, поступающими в больших объёмах и с высокой скоростью. Для таких случаев традиционные хранилища данных не всегда подходят и могут быть неэкономичными.
Поэтому около десяти лет назад появились озёра данных — хранилища для необработанных данных в различных форматах. Они позволяют хранить большие объёмы данных всех типов: структурированных, неструктурированных и полуструктурированных.
В отличие от хранилищ данных, в озёрах данных используется схема «при чтении» (schema-on-read), что упрощает добавление данных любого формата. Данные можно просто загрузить «как есть», а их структура определяется только при анализе.
Озёра данных подходят для хранения различных типов данных, таких как файлы Parquet, JSON, изображения, видео, данные датчиков IoT и другие. Они особенно полезны для приложений с большими данными, предиктивной аналитики и машинного обучения, где требуются разнообразные наборы данных без предопределённой структуры.
Примеры платформ озёр данных включают Amazon S3, Azure Data Lake Storage, Google Cloud Storage и Hadoop Distributed File System (HDFS).
В хранилищах данных данные легче использовать, но сложнее хранить. А в озеро данных, наоборот, легко загружать и хранить в нём данные, но запросы к ним и их интерпретация может быть сложнее.
Lakehouse
Озёра данных предлагают множество преимуществ, но сталкиваются с серьёзными проблемами. Во-первых, они не поддерживают транзакции, что усложняет выполнение транзакционных операций и нарушает целостность данных. Во-вторых, качество данных в озёрах часто низкое из-за отсутствия стандартов и проверок при их загрузке. В-третьих, несогласованность данных затрудняет их использование для аналитики. В результате многие ожидания от озёр данных не оправдываются.
Lakehouse объединяет лучшие характеристики озёр данных и хранилищ данных.
От хранилищ данных Lakehouse «взяли» поддержку транзакций, что обеспечивает надёжность и целостность данных. А от озёр данных — способность хранить как структурированные, так и полуструктурированные и неструктурированные данные в одном месте.
Lakehouse поддерживает работу с известными инструментами анализа данных, такими как Apache Spark, Presto и Trino. Эти инструменты используются для обработки больших данных и выполнения сложных аналитических задач.
Ключевые технологии для работы с архитектурой Lakehouse включают в себя Apache Iceberg, Apache Hudi и Delta Lake.
Шесть компонентов конвейера данных
Источники данных
Источником данных для конвейера может быть любая система, содержащая данные, которые нужны вашему бизнесу. Это могут быть реляционные базы данных, корпоративные приложения, SaaS-инструменты, веб-приложения, API, службы передачи данных, неструктурированные файлы, облачные приложения и датчики Интернета вещей.
Источники данных можно разделить на внутренние и внешние по отношению к компании. Для каждой задачи требуются свои специализированные наборы данных, поэтому универсального рецепта и набора источников данных не существует.
Давайте рассмотрим, где искать данные и какие источники могут пригодиться в проектах анализа данных.
Внутренние данные компании
Создаются в рамках бизнес-процессов компании. Например, данные о маркетинговых кампаниях, профилях клиентов и их онлайн-активности, покупках и предпочтениях клиентов, и так далее.
Внешние данные
Эти данные получаются из открытых и коммерческих внешних источников. Что это могут быть за источники: данные из социальных сетей, демографические данные от организаций, таких как ООН, WorldPop и GeoNames, а также данные, собранные с разных веб-сайтов с помощью веб-скрейпинга (например, данные о продуктах в интернет-магазинах, мониторинга цен, извлечения информации из новостных сайтов, получения данных для анализа социальных сетей и многих других задач).
Государственные порталы, такие как data.gov.ru, предлагают обширные наборы данных по различным темам, от здравоохранения до транспорта. Есть много национальных порталов открытых данных и геопорталов, которые предоставляют доступ к самым разным наборам данных.
Также есть много наборов научных данных, которые публикуют университеты и другие научно-исследовательские организации (физике, химии, астрономии, биологии, землетрясениям, метеорологии и сельскому хозяйству).
Для поиска открытых данных можно использовать портал Ивана Бегтина Dateno (https://dateno.io/), Google Dataset Search, а также BASE, Datacite Commons и FinData и многие подобные поисковики результатов исследований и наборов данных.
Сторонняя аналитика
Предоставляется аналитическими платформами. Например, Google Analytics предлагает данные о посещаемости сайта и поведении пользователей, а Nielsen и Statista — коммерческие данные о потребительском поведении и рыночных тенденциях. Финансовые аналитики могут использовать данные от Bloomberg и Reuters для получения финансовой информации.
Специализированные источники данных для конкретных проектов
Часто требуются специализированные наборы данных. Например, данные интернета вещей (IoT) поступают от умных устройств и датчиков и используются для анализа в реальном времени. Для прогноза погоды полезны данные от OpenWeatherMap и Weather.com, а расписание рейсов и информация о полётах доступны на платформах FlightAware и FlightRadar24.
Сбор данных
Здесь сырые данные извлекаются из разных источников и поступают в конвейер.
На этом уровне используются инструменты приёма данных для подключения к различным источникам данных (внутренним и внешним).
В зависимости от источника и уровня вашего доступа, может потребоваться получение ключей API, учётных данных, и выполнение других требований безопасности.
Данные могут собираться с помощью вызовов API, push-механизмов и веб-хуков. Извлечение данных из источников может выполняться по расписанию, наступлению определённых событий или в режиме реального времени.
Обработка
Уровень обработки отвечает за преобразование данных в пригодное для использования состояние. Работа этого компонента настраивается в зависимости от специфики конкретного проекта.
Процесс может включать в себя несколько этапов: сортировка, валидация, верификация, преобразование в нужный формат, удаление дубликатов, фильтрация, сопоставление, разметка, очистка и агрегация данных из разных источников. Также здесь данные могут готовиться для машинного обучения, разработки статистических и математических моделей и преобразовываться в многомерные структуры для аналитики и отчётов.
В зависимости от конкретной архитектуры ETL или ELT, компонент обработки данных работает до или после компонента хранения данных.
В случае ELT после сбора данных этот этап обработки данных пропускается, и следующий этап после сбора данных — это их хранение. Чаще всего в этом случае данные сохраняются в озере данных. А обработка выполняется уже после сохранения для каждой конкретной задачи. После выполнения всех необходимых преобразований и анализа данные снова сохраняются. Они могут быть возвращены в то же озеро данных, но чаще всего помещаются в специализированное хранилище данных, предназначенное для хранения уже обработанных данных для конкретной задачи.
Хранение
Обычно этот компонент состоит из баз данных, хранилищ данных (для структурированных данных), озёр данных (для структурированных, полуструктурированных и неструктурированных данных) и lakehouse.
Использование
Важно не только построить конвейер данных, но и обеспечить доступность обработанных данных для каждого пользователя.
На этом этапе обработанные данные предоставляются в удобной и понятной форме. Они могут отображаться на BI-дашбордах и в отчётах, предоставляться напрямую через хранилища данных для выполнения пользовательских ad-hoc запросов, использоваться для уведомлений об изменениях, в интерфейсах и API для интеграции с другими приложениями и системами. Приёмниками обработанных данных могут быть платформы данных, инструменты Data Science и машинного обучения, средства Self-setvice аналитики и другие.
Управление и мониторинг
Этот компонент обеспечивает своевременный запуск и координацию обработки данных, контроль доступа, шифрование, сетевую безопасность, мониторинг использования и аудит.
Так как конвейер данных может давать сбои, важно настроить системы для мониторинга его состояния, анализа входных данных и регистрации ошибок.
Инструменты, такие как Grafana, Datadog и PagerDuty, позволяют визуализировать метрики, следить за состоянием систем в реальном времени и быстро реагировать на проблемы. Они помогают выявлять узкие места и устранять их до того, как они станут критичными.
Безопасность также включает в себя контроль всех операций и ведение журнала аудита. С системой управления и безопасности интегрированы все компоненты конвейера данных.
Кто разрабатывает и поддерживает конвейеры данных
Конвейеры данных разрабатывают и поддерживают инженеры данных. Они создают инфраструктуру для сбора и обработки данных, обеспечивают их доступность для дальнейшего использования.
Обработанные данные затем используют аналитики данных, бизнес-пользователи, дата-сайентисты и разработчики. Они применяют данные для аналитики в реальном времени, загрузки в панели мониторинга или приложения, а также для обучения моделей машинного обучения.
Какие бывают конвейеры данных?
Конвейеры данных можно разделить на несколько типов в зависимости от их назначения и используемых технологий.
Пакетная обработка (Batch Processing)
Конвейеры пакетной обработки обрабатывают данные по частям или пакетами и передают их блоками в течение определённых периодов времени, например, нескольких минут, часов или даже дней. Эти конвейеры распространены в традиционной аналитике.
Конвейеры пакетной обработки идеально подходят для задач, связанных с агрегированием больших объёмов данных, созданием отчётов, выполнением сложных вычислений. Например, ежедневная обработка транзакционных данных для создания отчётов.
К числу популярных инструментов пакетной обработки относятся: Informatica PowerCenter, IBM InfoSphere DataStage, Talend, Pentaho.
Обработка данных в реальном времени (Real-time Processing)
В отличие от пакетной обработки, конвейеры данных в режиме реального времени работают непрерывно. Они получают данные по мере их генерации, обрабатывают и передают их непрерывным потоком.
Потоковая обработка использует преимущества вычислительных мощностей (в основном облачных) для преобразования данных.
Эти конвейеры предназначены для обработки данных, которые постоянно меняются или требуют немедленных действий. Они используются для обновления показателей в реальном времени по мере поступления новых данных. Примерами применения могут быть мониторинг финансового рынка, социальных сетей, финансовых транзакций, эксплуатации оборудования и многих других задач.
Популярные инструменты для обработки данных в режиме реального времени: Hevo Data, Confluent, Estuary Flow и StreamSets.
Гибридная обработка
Архитектура Lambda обеспечивает сочетание пакетной и потоковой обработки, позволяя использовать преимущества обоих подходов.
Пример: аналитическая система, которая обрабатывает большие объёмы исторических данных в пакетном режиме и одновременно анализирует потоковые данные.
Конвейеры с открытым исходным кодом
Конвейеры данных с открытым исходным кодом позволяют использовать готовые решения и изменять исходный код, адаптируя их под свои требования. Такие инструменты, как Apache Airflow и Luigi, используются для управления рабочими процессами данных; Kedro от QuantumBlack помогает в управлении конвейерами данных, а Apache NiFi автоматизирует потоки данных
Конвейеры, управляемые событиями
Конвейеры, управляемые событиями, используют события для запуска операций обработки и интеграции данных в режиме реального времени. События могут генерироваться из различных источников, таких как действия пользователей, системные уведомления или изменения данных. Когда происходит событие, оно запускает серию предопределённых действий в рамках конвейера.
Например, в системе мониторинга транзакций каждое новое действие пользователя или изменение данных инициирует проверки и обновления. В системе управления логистикой каждое сканирование товара может обновлять данные в системе отслеживания. Такие конвейеры обычно работают в режиме реального времени, хотя иногда могут иметь небольшую задержку.
Решения для конвейеров, управляемых событиями, включают Apache Kafka, AWS Lambda, Azure Event Grid и Google Cloud Pub/Sub.
Облачные конвейеры данных
Облачный конвейер передаёт данные из различных источников в облачные хранилища или озера данных, служит мостом между локальными системами и облаком. Такие конвейеры могут может использоваться также и для миграции данных и для интеграции и обработки данных в облачной среде.
Облачные конвейеры данных обладают всеми преимуществами облачных технологий: масштабируемостью, экономичной моделью «оплата по мере использования», автоматическими обновлениями и поддержкой инфраструктуры, а также обеспечивают интеграцию с другими облачными сервисами.
Примерами облачных конвейеров могут быть AWS Data Pipeline, Google Cloud Dataflow, Azure Data Factory и другие.
Пример ELT конвейера пространственных данных
В этом разделе рассмотрим пример, как можно использовать современный стек для создания конвейеров пространственных данных.
E (Extract) — извлечение данных
Данные извлекаются в их исходном формате. Например, если у вас есть данные в облачном хранилище в формате GeoParquet или оптимизированный для облака GeoTIFF, вы просто извлекаете этот файл.
L (Load) — загрузка данных
Данные загружаются в исходном формате без каких-либо преобразований. Важно, чтобы система назначения поддерживало формат загружаемых данных. Идея простая: берём файл и используем подходящий инструмент, чтобы просто переместить его и загрузить «как есть» в своё хранилище. Например, для загрузки файлов в PostGIS, можно использовать GDAL, Yougrt или Airbyte.
Пример загрузки данных в облачное хранилище
Большинство облачных хранилищ данных, таких как BigQuery, Snowflake, Amazon Redshift и другие, имеют собственные встроенные инструменты для загрузки данных. Поэтому при загрузке данных в облачные хранилища чаще всего используются именно эти инструменты.
Например, для передачи данных из Amazon S3 (Simple Storage Service) в BigQuery можно использовать встроенный механизм передачи данных BigQuery. Для этого достаточно указать источник данных (Amazon S3), целевое хранилище (BigQuery) и запустить процесс передачи данных, который автоматически перемещает данные из Amazon S3 в BigQuery.
Пример прямого чтения данных из облака
В некоторых случаях можно использовать инструменты, такие как DuckDB, для прямого чтения данных из облачного хранилища.
Рассмотрим пример чтения файла из хранилища Amazon S3. DuckDB позволяет загрузить файл напрямую из S3 в локальную память. Затем данные из файла преобразуются и записываются в таблицу, доступную для запросов в памяти.
Таким образом, традиционная загрузка данных (Load) не требуется, поскольку данные читаются и обрабатываются непосредственно в оперативной памяти.
T (Transformation) — Преобразование данных
После того как данные извлечены из различных источников и загружены в целевое хранилище, приходит время для их преобразования. Этот этап выполняется непосредственно в хранилище данных.
В этом может помочь dbt (Data Build Tool). dbt — это инструмент для создания конвейеров данных с использованием SQL.
dbt подключается к различным базам данных через адаптеры. С его помощью можно написать структурированный SQL-код, который легко поддерживать и повторно использовать. dbt организует эти запросы в последовательные процессы и автоматически их запускает.
Есть распространённое заблуждение, что dbt сам обрабатывает данные. Это не так — на самом деле это клиент, который отправляет SQL-команды в облачное хранилище данных. Вычисления выполняются в хранилище.
dbt позволяет преобразовывать данные, как только они попадают в источник данных в SQL, используя уже имеющиеся вычислительные ресурсы.
dbt интегрирован с системами контроля версий, такими как git. Это позволяет разработчикам работать над проектом совместно, отслеживать изменения и избегать конфликтов. Также плюс dbt — это автоматическая генерация документации по всем выполненным преобразованиям данных.
Кроме того, dbt позволяет создавать тесты, используя SQL, что помогает поддерживать высокое качество данных и своевременно выявлять проблемы.
dbt совместим со многими платформами данных, таких как Amazon Redshift, Google BigQuery, Snowflake и другими.
Выполнение ELT локально, результат — в облако
Этот двухэтапный процесс позволяет загружать данные локально и преобразовывать их на локальном компьютере.
ingestr — это пакет, который перемещает данные между базами данных с помощью простых команд.
Автоматизация ELT
Посмотрим, что нужно сделать, чтобы процессы ELT выполнялись автоматически. Для этого нужно написать код для обработки процессов приёма данных и перемещения данных в облачное хранилище с помощью планировщика.
Подключение источников данных
Вы можете использовать необработанные файлы из облачного хранилища или подготовленные данные из локальных хранилищ.
Поставщики решений для конвейеров данных
Решения для конвейеров данных можно разделить на две основные категории: встроенные в платформы данных и независимые решения.
Конвейеры, встроенные в платформы данных: Google BigQuery и Cloud Dataflow в составе Google Cloud Platform, AWS Glue в Amazon Web Services, а также Azure Synapse Analytics и Data Factory в Microsoft Azure. Snowflake и Databricks (на базе Apache Spark) также предлагают свои конвейеры данных.
Сторонние решения представлены такими платформами, как Hevo Data (no-code платформа для создания конвейеров данных), Informatica, Fivetran, Talend и Segment и многими другими.
Как построить конвейер данных
Можно разработать свой конвейер или использовать подходящие готовые инструменты. Рассмотрим основные шаги.
Шаг 1. Планирование конвейера
Первым шагом является определение цели создания конвейера и его ценности для компании или продукта. На какие вопросы отвечаем на этом этапе:
- Какие цели создания конвейера?
- Как будем измерять успех конвейера?
- Для чего нужен конвейер (например: автоматизация сбора данных, улучшение аналитики, интеграция данных из разных источников, подготовка данных для машинного обучения, настройка репликации данных или что-то ещё)?
Сформулируйте ожидаемые результаты, например, снижение времени обработки данных и повышение точности отчётов.
Определите, какие данные нужно обрабатывать, и их источники, а также как будут использоваться обработанные в конвейере данные. Например, для ежедневных отчётов, ежемесячной аналитики, интеграции данных между разными системами, информационных панелей.
Укрупнённая схема плана на этом этапе может выглядеть просто: в левой части схемы – источники данных, справа – результат, а между ними — шаги, необходимые для перехода от источников к результату.
Простой пример может выглядеть примерно так.
Шаг 2. Сбор требований к конвейеру
Выясните, кто будет использовать или влиять на работу конвейера данных. Составьте список стейкхолдеров, включая представителей из бизнес-линий, аналитиков, инженеров данных, IT-отдел и бизнес-аналитиков. Проведите встречи и опросы для понимания их требований.
Определение требований к данным
Поймите, как данные будут использоваться, и какие требования к частоте их обновления. Например, данные о транзакциях за день должны быть доступны через час после завершения операционного дня.
Определите источники данных. Убедитесь, что все необходимые данные доступны. Уточните, будет ли использоваться пакетная или real-time обработка данных.
После выбора источников данных нужно решить, как данные будут извлекаться. Например, при инкрементальной загрузке извлекаются только новые данные с помощью временных меток, при полной — все данные, а при delta — только те данные, которые изменились с момента последней загрузки, без включения новых данных.
Определение нефункциональных требований
Убедитесь, что система может расти вместе с числом пользователей и объёмом данных. Продумайте механизмы автоматической обработки ошибок и восстановления после сбоев. Определите способы подключения систем-потребителей.
Шаг 3. Выбор инструментов и фреймворков для конвейера
Использование программного обеспечения сторонних производителей или разработка собственных конвейеров заметно различаются, когда речь заходит о бюджете и ресурсах. При выборе подходящих инструментов важно рассмотреть несколько критериев.
Тип проекта (open-source или коммерческие решения). Для небольших проектов можно использовать open-source инструменты, такие как Apache Airflow. Для масштабных проектов подойдут коммерческие решения.
Совместимость с текущей архитектурой. Выбирайте инструменты, совместимые с вашей текущей технологической средой. Например, Prefect подойдёт для Python-разработчиков, а AWS Glue — для интеграции с сервисами AWS.
Простота использования и поддержки. Например, Эпсилон Workflows предоставляет простой low-code инструмент для разработки процессов конвейера данных.
Бюджет. Разница в стоимости подходящих решений может быть существенной, поэтому при принятии решения о выборе варианта реализации важно учитывать финансовые ограничения.
Доступность квалифицированных специалистов. Например, для сложных конвейеров может потребоваться опытный дата-инженер или целая команда.
Шаг 4. Проектирование конвейера
Этот этап включает разработку архитектуры и описание каждого этапа процесса.
Необходимо детально проработать, как данные будут перемещаться и трансформироваться на каждом шаге конвейера.
Выбор источников данных и целевых систем данных
Определяем системы-источники и системы-потребители данных. Необходимо определить все потенциальные источники данных и целевые системы, куда эти данные будут передаваться. Важно учитывать формат данных (JSON, XML и другие) и методы подключения к источникам данных.
Также нужно определить, какие именно данные будут извлекаться и передаваться, частоту и объём этих данных. Должны быть установлены требования к качеству данных и меры для его обеспечения. Необходимо обеспечить безопасность данных при их передаче, а также организовать логирование и мониторинг процессов извлечения и загрузки данных.
Важно предусмотреть управление изменениями в источниках данных, чтобы изменения в схемах или структуре данных не нарушали процесс передачи данных.
Определение процессов сбора данных
Важно выбрать коммуникационный протокол для передачи данных, такой как HTTP (HyperText Transfer Protocol), MQTT (Message Queuing Telemetry Transport), или gRPC (gRPC Remote Procedure Calls).
Также нужно решить, будем ли использовать сторонние интеграционные инструменты, и если да, то какие именно. Определить, требуются ли промежуточные хранилища данных для временного хранения и обработки данных перед их конечной загрузкой.
Определяем, как будут обрабатываться данные
Во-первых, нужно выбрать стратегию обработки данных, например, будем ли мы использовать ETL или ELT процессы, и будем ли обрабатывать данные в реальном времени или пакетами. Также необходимо решить, будем ли мы обогащать данные дополнительными атрибутами, и если да, то какие это атрибуты и из каких источников будем брать значения.
Кроме того, важно определить, как мы будем удалять избыточные данные, включая установку критериев для удаления и определить методы очистки данных. Обеспечение качества данных является еще одним важным аспектом, включая валидацию, очистку и нормализацию данных.
Наконец, необходимо выбрать инструменты и технологии, которые мы будем использовать для обработки данных, например, такие как Apache Spark или Apache Flink.
Где будут храниться данные
Необходимо определить конечное место хранения данных для различных сценариев. Важно решить, будем ли мы использовать хранилища больших данных, такие как data warehouses или data lakes. Также необходимо выбрать, будут ли данные храниться в облаке или на локальных серверах, и в каком формате будут храниться обработанные данные.
Кроме того, следует учесть назначение данных и их использование, обеспечить меры безопасности для защиты данных в выбранном хранилище, определить, кто и как будет иметь доступ к данным, и как будут управляться права доступа. Также важно предусмотреть процессы резервного копирования и восстановления данных, обеспечить масштабируемость системы хранения данных по мере роста объема данных и удостовериться, что хранилище соответствует нормативным требованиям и правилам.
Проектирование процессов
Важно определить, какие задачи зависят друг от друга и какие можно выполнять одновременно, чтобы сэкономить время и ресурсы. Также нужно решить, как будем проверять промежуточные результаты и обрабатывать ошибки.
Настроить расписание для задач, определить, когда и как часто они будут выполняться.
Шаг 5. Реализация и тестирование
На этом этапе разрабатываем код, внедряем выбранные инструменты, настраиваем подключения к источникам данных и тестируем конвейер.
Шаг 6. Внедрение, поддержка и оптимизация производительности
После успешного тестирования конвейер развёртывается в промышленной среде. Настраивается расписание работы конвейера и мониторинг для отслеживания производительности и быстрого выявления ошибок. Этот этап включает в себя регулярное обслуживание и оптимизацию производительности конвейера.
Внедрение системы мониторинга
Мониторинг и протоколирование потока данных в конвейере позволяют выявить узкие места, которые замедляют поток данных или потребляют лишние ресурсы. Частые проблемы включают низкую скорость загрузки данных из источников, ресурсные ограничения и ресурсоемкие операции по преобразованию данных.
Для оптимизации производительности обычно применяются следующие методы: параллельная обработка, разделение больших наборов данных на более мелкие части (шардирование или партиционирование) и использование облачных сервисов.
Инструменты для построения конвейеров данных
1. AWS Data Pipeline
AWS Data Pipeline — это веб-сервис, ориентированный на построение и автоматизацию конвейеров данных. Сервис интегрируется со всей экосистемой AWS, обеспечивает хранение, обработку и создание отчётов. Конвейер данных AWS поддерживает передачу данных из локальных источников в облако и обратно.
2. Apache Airflow
Платформа для построения, планирования и мониторинга рабочих процессов конвейера данных. Предлагает веб-приложение и поддерживает команды Python для создания процессов конвейера вместо командной строки. Airflow интегрируется с основными облачными сервисами, включая Google Cloud Platform, Microsoft Azure и AWS.
3. Integrate.io
Платформа для интеграции данных, основанная на четырёх инструментах обработки данных: Xplenty, Dream Factory, FlyData и Intermix.io. Платформа предлагает возможности конвейера ETL, ELT и reverse ETL; создание API для поддержки использования данных в приложениях и системах; а также аналитику метаданных вашего хранилища данных.
4. Fivetran
Платформа интеграции данных, обеспечивающая архитектуру ELT для компаний, которые хранят данные в облаке. Предлагает конвейеры и готовые наборы данных. Поддерживает пользовательский код для запроса наборов данных и построения рабочих процессов.
5. Эпсилон Workflows
Позволяет создавать и автоматизировать конвейеры данных ETL и ELT в любом масштабе.
Подключается к различным источникам данных, загружает данные в выбранное место назначения, позволяет преобразовывать их с использованием no-code компонентов конструктора процессов и моделей машинного обучения, автоматически сохранять и публиковать результаты. Работает как с геоданными, так и с обычными.
Отличительной чертой Эпсилон Workflows является то, что любой желающий (даже тот, кто никогда не имел дела с программированием или SQL) может использовать необработанные данные и преобразовывать их с помощью простого no-code интерфейса.
Продумывая Эпсилон Workflow, мы придерживались правил построения решений self-service аналитики, и у нас получилось. Детали можно уточнить, посмотрев наше видео:
Заключение
По данным Statista, в 2020 году было сгенерировано, потреблено и сохранено 64,2 зеттабайта данных, и эта цифра продолжает расти. В условиях такого роста объёма данных конвейеры становятся всё более важными, а дата-инженеры, создающие и поддерживающие их, играют ключевую роль в аналитике и принятии решений.
Инструменты для построения конвейеров данных являются ключевыми элементами современной обработки информации, позволяя компаниям эффективно интегрировать и использовать данные. Существует множество архитектур и инструментов для проектирования и построения конвейеров данных.
Надеюсь, что эта публикация помогла вам разобраться в теме и подготовиться к выбору лучшего варианта для вашей компании.
