Строим масштабируемые ETL/ELT-конвейеры обработки данных с Apache Spark и AirFlow: 4 совета дата-инженеру

Автор Категория , ,
Строим масштабируемые ETL/ELT-конвейеры обработки данных с Apache Spark и AirFlow: 4 совета дата-инженеру

В этой статье для дата-инженеров мы собрали лучшие практики построения масштабируемых конвейеров обработки данных, а также популярные рекомендации по проектированию ETL/ELT-процессов с Apache Spark, AirFlow и другими технологиями Big Data. Читайте далее, когда ELT лучше ETL и наоборот, чем хорош Apache Spark в конвейерах обработки Big Data, зачем нужен AirFlow, какие форматы файлов, а также виды озер и хранилищ данных более эффективны.

Озеро данных и процессы работы с ним: ETL или ELT

Сегодня хранение разнородной бизнес-информации в различных форматах (JSON, CSV, Parquet и пр.) в озере данных стало стандартом де-факто в мире enterprise. Причем ярким трендом является организация Data Lake не на локальных кластерах Apache Hadoop HDFS, а в облачных объектных хранилищах типа AWS S3 или Google Cloud Storage. Они отличаются высокой доступностью, надежностью, полностью управляются облачным провайдером и стоят довольно дешево. Однако, независимо от платформы Data Lake, хранящиеся в нем данные перед непосредственным использованием необходимо очистить и преобразовать в соответствующие структуры. Очищенные канонические данные чаще хранятся в корпоративном хранилище данных (КХД или DWH, Data Warehouse), которые поддерживают аналитические запросы (COUNT, SUM, GROUPBY) с очень низкими задержками. Такая скорость достигается за счет колоночных форматов хранения данных и ориентированных на OLAP табличных схем «звезда» и «снежинка», о которых мы писали здесь.

Впрочем, вопросы моделирования данных и использования колоночных форматов для их хранения – не единственные задачи, которые приходится решать дата-инженеру при проектировании Data Lake. Важны также процессы извлечения, преобразования и загрузки данных в корпоративное хранилище или озеро. Например, как будут обрабатываться ошибки в данных, уже преобразованных и загруженных в озеро/хранилище? Таким образом, необходим выбор между ETL и ELT-процессами.

ELT означает извлечение данных, их загрузку в озеро/хранилище, а затем преобразование для использования в BI-дэшбордах и других прикладных системах. Недостатком этого подхода является потребность в большом объеме для хранения данных и ELT-конвейеров из последовательности приложений извлечения, загрузки и преобразования данных. Если стоимость хранения данных – не проблема, ELT – отличный вариант. Иначе и для конфиденциальных данных следует рассмотреть альтернативу в виде ETL, которая после извлечения нужных данных сперва преобразует их и только потом загружает в Data Lake или DWH.

Также ELT лучше подходит для данных, преобразования над которыми носят изменчивый характер. Под преобразованиями понимается множество операций трансформации данных: от удаления NULL-значений и заполнения пропусков до расчета статистики, агрегирования и пр. В частности, такое часто встречается в кейсах веб-аналитики, где хорошо применяется ELT-подход. Например, если нужно сначала загрузить все взаимодействия с клиентами и транзакции в DWH, затем снова их преобразовать и, наконец, использовать в BI-задачах [1]. Для автоматизации этих операций используются специальные инструменты, например, Data Build Tool (DBT), который обеспечивает общую основу для аналитиков и дата-инженеров, позволяя строить конвейеры преобразования данных со встроенной CI/CD-поддержкой и обеспечением качества (data quality). DBT не выгружает данные из источников, а позволяет работать с теми данными, которые уже загружены в хранилище, компилируя код в SQL-запросы с поддержкой версионности [2]. Подробнее работу DBT-фреймворка мы рассматривали в этой статье на примере взаимодействия с Apache Spark и озера данных в облаке AWS S3.

Конвейеры обработки Big Data с Apache Spark

Чтобы ускорить вычисления с помощью распределенной обработки огромных наборов данных, дата-инженеры по всему миру чаще всего используют фреймворк Apache Spark. Являясь ускоренной версией Apache Hadoop, Spark запускает несколько рабочих процессов, которые обрабатывают фрагменты большого набора данных, используя методы MapReduce с хранением промежуточных вычислений в памяти, а не на диске. Spark может выполнять множество ETL/ELT-процессов для миллиардов записей, читая данные из различных источников, а также записывая их в разные места назначения: Hadoop HDFS, AWS S3 и пр. Например, дата-инженер может создать собственный гибридный ETL/ELT-конвейер, в котором один этап извлекает данные и загружает их в S3, где их преобразует другой этап, обогащая и добавляя новую информацию, а затем загружает в КХД.

Spark также поддерживает параллельные алгоритмы машинного обучения с использованием библиотеки MLLib, который разделяет данные между вычислительными узлами кластера и периодически обновляет параметры ML-модели во время обучения. Подробнее о новых и старых версиях этого Machine Learning пакета в Apache Spark мы рассказывали здесь. Наконец, отметим, что можно запустить этот и другие модули Apache Spark самостоятельно или использовать полностью управляемый облачный сервис в Amazon EMR или Databricks [1].

Организация конвейеров: оркестровка данных с помощью Airflow

Наконец, когда параллельная обработка данных стала действительно масштабной, возникает потребность в оркестраторе – способе систематически организовать выполнение отдельных заданий, т.е. свести их в единый конвейер. В области Big Data самым популярным инструментом такого класса стал Apache Airflow. Этот фреймворк позволяет планировать все задания в виде направленного ациклического графа (DAG, Directed Acyclic Graph), где каждый следующий шаг зависит от предыдущего, и контролировать особенности их выполнения с помощью операторов cron [1]. Как и другие Big Data фреймворки, Airflow также доступен и в формате облачного сервиса, например, Managed Workflows от Amazon, продукты компании Astronomer и среду Google Cloud Composer, о чем мы писали здесь.

Как хранить большие данные: выбор файловых форматов для озер и хранилищ

При том, что часто используемые в Data Science форматы файлов CSV и JSON отлично подходят для исследований, в масштабных случаях лучше применять Parquet, AVRO или Delta. Parquet – это колоночный формат, где данные структурированы по столбцам, а в AVRO – по строкам. Колоночная структура Parquet ускоряет обработку больших объемов данных благодаря возможности обращаться к отдельным столбцам. Также можно использовать формат Delta на основе Parquet, где добавлена история событий, журналы транзакций и некоторые другие функции. Все эти форматы поддерживают обработку данных в Apache Spark и хранение в AWS S3.

Также существуют разные варианты хранилищ данных. Например, Redshift от AWS, BigQuery от Google Cloud Platform и Snowflake. Также набирает популярность недавняя архитектура Lakehouse, которая объединяет озеро данных и хранилища [1]. Примером реализации этого подхода является Delta Lake от Databricks, о котором мы писали здесь, здесь и здесь.

Подводя итог рассмотренным практикам организации ETL/ELT-процессов для работы с озерами и хранилищами данных, рассмотрим пару распространенных кейсов. Например, можно построить ETL-конвейер, в котором необработанные данные считываются из озера на AWS S3 и преобразуются Spark-приложениями, а затем загружаются в хранилище данных Snowflake или Redshift. Далее вступают в работу BI-системы: Tableau, Looker или PowerBI, которые представляют итоговую информацию на наглядных дэшбордах для важных управленческих решений на основе данных.

В случае Data Science сценария можно сначала собрать данные из разрозненных источников внутри хранилища, преобразовать их с помощью Apache Spark и загрузить в AWS S3 в виде файлов Parquet, чтобы проанализировать их с помощью инструментов машинного обучения AWS SageMaker или Spark MLLib.

Больше интересных примеров организации озера данных, а также практического использования Apache AirFlow для построения ETL/ELT-процессов и разработки сложных конвейеров аналитики больших данных с Hadoop и Spark вы узнаете на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:

 

Источники

  1. https://towardsdatascience.com/how-to-build-data-engineering-pipelines-at-scale-6f4dd3746e7e
  2. https://medium.com/slalom-australia/aggregate-cloudtrail-logs-with-dbt-and-spark-d3196248d2d4