Преобразование данных
В этой статье приведены общие сведения о преобразовании данных с помощью Azure Databricks. Преобразование данных или подготовка данных является ключевым шагом во всех рабочих нагрузках по проектированию данных, аналитике и машинному обучению.
Примеры шаблонов и рекомендации в этой статье посвящены работе с lakehouse tables, поддерживаемыми Delta Lake. Поскольку Delta Lake предоставляет гарантии ACID озера Databricks, при работе с данными в других форматах или системах данных может наблюдаться другое поведение.
Databricks рекомендует прием данных в озеро в необработанном или почти необработанном состоянии, а затем применение преобразований и обогащения в качестве отдельного шага обработки. Этот шаблон называется архитектурой медальона. См. статью "Что такое архитектура медальона lakehouse?".
Если вы знаете, что данные, необходимые для преобразования, еще не загружены в озеро, см . сведения о приеме данных в озера Databricks. Если вы пытаетесь найти данные Lakehouse для записи преобразований против, см. статью "Обнаружение данных".
Все преобразования начинаются с написания пакетного или потокового запроса к источнику данных. Если вы не знакомы с запросами данных, см. статью "Запрос данных".
После сохранения преобразованных данных в разностную tableможно использовать эти table в качестве функции table для машинного обучения. См . проектирование компонентов и обслуживание.
Примечание.
В статьях здесь рассматриваются преобразования в Azure Databricks. Azure Databricks также поддерживает connections на многих распространенных платформах подготовки данных. См. статью "Подключение к партнерам по подготовке данных" с помощью Partner Connect.
Преобразования Spark и преобразования Lakehouse
В этой статье основное внимание уделяется определению tranformations , так как они относятся к T в ETL или ELT. Модель обработки Apache Spark также использует преобразование слов соответствующим образом. Кратко: в Apache Spark все операции определяются как преобразования или действия.
- Преобразования: добавьте в план некоторую логику обработки. Примеры включают чтение данных, соединения, агрегаты и приведение типов.
- Действия: активация логики обработки для оценки и вывода результата. Примеры включают запись, отображение или просмотр результатов, кэширование вручную или получение количества строк.
Apache Spark использует отложенную модель выполнения , то есть ни одна логика, определенная коллекцией операций, не будет оценена до запуска действия. Эта модель имеет важные последствия при определении конвейеров обработки данных: только используйте действия для сохранения результатов обратно в целевой table.
Так как действия представляют собой узкие места обработки для оптимизации логики, Azure Databricks добавил множество оптимизаций в дополнение к тем, кто уже присутствует в Apache Spark, чтобы обеспечить оптимальное выполнение логики. Эти оптимизации учитывают все преобразования, инициируемые заданным действием одновременно, и найдите оптимальный план на основе физического макета данных. Кэширование данных вручную или возврат предварительных версий в рабочих конвейерах может прерывать эти оптимизации и привести к значительному увеличению затрат и задержки.
Поэтому мы можем определить преобразование lakehouse, чтобы быть любой коллекцией операций, применяемых к одной или нескольким tables lakehouse, что приводит к новому tableозера. Обратите внимание, что в то время как преобразования, такие как соединения и агрегаты, обсуждаются отдельно, можно объединить многие из этих шаблонов в одном шаге обработки и доверять оптимизаторам в Azure Databricks, чтобы найти наиболее эффективный план.
Каковы различия между потоковой и пакетной обработкой?
Хотя потоковая и пакетная обработка используют большую часть одного синтаксиса в Azure Databricks, каждая из них имеет собственную семантику.
Пакетная обработка позволяет определять явные инструкции по обработке фиксированного объема статических, не изменяющихся данных в виде одной операции.
Потоковая обработка позволяет определить запрос к несвязанным, постоянно растущим набору данных, а затем обрабатывать данные в небольших добавочных пакетах.
Пакетные операции в Azure Databricks используют Spark SQL или DataFrames, а потоковая обработка использует структурированную потоковую передачу.
Вы можете различать пакетные команды Apache Spark от команд структурированной потоковой обработки, анализируя операции чтения и записи, как показано в следующих table.
| Apache Spark | Структурированная потоковая передача | |
|---|---|---|
| Чтение | spark.read.load() |
spark.readStream.load() |
| Запись | spark.write.save() |
spark.writeStream.start() |
Материализованные представления views обычно соответствуют гарантиям пакетной обработки, хотя Delta Live Tables используется для поэтапного вычисления результатов, когда это возможно. Результаты, возвращаемые материализованным представлением, всегда эквивалентны пакетной оценке логики, но Azure Databricks стремится обрабатывать эти результаты постепенно, когда это возможно.
Потоковая tables всегда вычисляет результаты постепенно. Поскольку многие источники потоковых данных хранят записи только в течение нескольких часов или дней, модель обработки, используемая в потоковой tables, предполагает, что каждый пакет записей из источника данных обрабатывается только один раз.
Azure Databricks поддерживает использование SQL для записи потоковых запросов в следующих случаях использования:
- Определение потокового проигрывания tables в Unity Catalog с использованием Databricks SQL.
- Определение исходного кода для конвейеров Delta Live Tables.
Примечание.
Вы также можете объявить поток tables в Delta Live Tables с использованием кода для структурированных потоков на Python.
Преобразования пакетной службы
Пакетные преобразования осуществляются на четко определенных set данных в определенный момент времени. Преобразования пакетной службы могут быть однократными операциями, но часто являются частью запланированных заданий или конвейеров, которые регулярно выполняются для поддержания актуальности рабочих систем.
Добавочные преобразования
Добавочные шаблоны обычно предполагают, что источник данных доступен только для добавления и имеет стабильную schema. В следующих статьях содержатся сведения о нюансах инкрементных преобразований в tables, которые происходят при обновлениях, удалениях или изменениях schema.
- API APPLY CHANGES: упрощение отслеживания изменений с помощью Delta Live Tables
- Использование веб-канала изменений данных Delta Lake в Azure Databricks
- Update Delta Lake tableschema
- Delta table потоковое чтение и запись
Преобразования в режиме реального времени
Delta Lake обеспечивает практически доступ к большим объемам данных для всех пользователей и приложений, запрашивающих lakehouse, но из-за затрат на запись файлов и метаданных в облачное хранилище объектов невозможно достичь задержки в реальном времени для многих рабочих нагрузок, записываемых в приемники Delta Lake.
Для приложений потоковой передачи с крайне низкой задержкой Databricks рекомендует выбирать системы источника и приемника, предназначенные для рабочих нагрузок в режиме реального времени, таких как Kafka. Azure Databricks можно использовать для обогащения данных, включая агрегаты, соединения между потоками и присоединение потоковых данных с медленно изменяющимися данными измерения, хранящимися в lakehouse.