Руководство по принятию решений Microsoft Fabric: действие копирования, поток данных или Spark
Используйте это справочное руководство и примеры сценариев, чтобы решить, требуется ли действие копирования, поток данных или Spark для рабочих нагрузок с помощью Microsoft Fabric.
Важно!
Microsoft Fabric находится в предварительной версии.
свойства действие Copy, потока данных и Spark
| Действие копирования конвейера | Поток данных 2-го поколения | Spark | |
|---|---|---|---|
| Вариант использования | Перенос озера данных и хранилища данных, прием данных, упрощенное преобразование |
Прием данных, преобразование данных, первичной обработки данных, профилирование данных |
Прием данных, преобразование данных, обработка данных, профилирование данных |
| Основной пользователь разработчика | Инженер данных, интегратор данных |
Инженер данных, интегратор данных, бизнес-аналитик |
Инженер данных, специалист по обработке и анализу данных, разработчик данных |
| Основной набор навыков разработчика | ETL SQL JSON |
ETL М SQL |
Spark (Scala, Python, Spark SQL, R) |
| Написанный код | Без кода, низкий уровень кода |
Без кода, низкий уровень кода |
Код |
| Объем данных | От низкого к высокому | От низкого к высокому | От низкого к высокому |
| Интерфейс разработки | Мастер полотно |
Power Query | Ноутбука Определение задания Spark |
| Источники | Более 30 соединителей | Более 150 соединителей | Сотни библиотек Spark |
| Места назначения | Более 18 соединителей | Lakehouse, Azure SQL база данных, Azure Data Explorer, аналитика Azure Synapse |
Сотни библиотек Spark |
| Сложность преобразования | Низкий: упрощенный — преобразование типов, сопоставление столбцов, объединение и разделение файлов, плоская иерархия |
От низкого к высокому: Более 300 функций преобразования |
От низкого к высокому: поддержка собственных библиотек Spark и с открытым кодом |
Ознакомьтесь со следующими тремя сценариями, чтобы получить справку по выбору способа работы с данными в Fabric.
Сценарий 1
Лео, инженеру данных, необходимо принимать большой объем данных из внешних систем, как локальных, так и облачных. К этим внешним системам относятся базы данных, файловые системы и API. Лео не хочет писать и обслуживать код для каждого соединителя или операции перемещения данных. Он хочет следовать лучшим методикам уровней медальона, с бронзой, серебром и золотом. У Лео нет опыта работы со Spark, поэтому он предпочитает пользовательский интерфейс перетаскивания как можно больше с минимальным написанием кода. И он также хочет обрабатывать данные по расписанию.
Первым шагом является получение необработанных данных в lakehouse бронзового слоя из ресурсов данных Azure и различных сторонних источников (например, Snowflake Web, REST, AWS S3, GCS и т. д.). Ему нужен консолидированный lakehouse, чтобы все данные из различных бизнес-, локальных и облачных источников располагались в одном месте. Лео проверяет параметры и выбирает действие копирования конвейера в качестве подходящего варианта для необработанной двоичной копии. Этот шаблон применяется как к историческому, так и к добавочному обновлению данных. С помощью действия копирования Leo может загружать данные уровня Gold в хранилище данных без кода, если это необходимо, а конвейеры обеспечивают прием данных большого масштаба, который может перемещать данные в петабайтовом масштабе. действие Copy — это лучший вариант с низким кодом и без кода для перемещения петабайт данных в lakehouses и хранилища из различных источников, как по расписанию, так и по расписанию.
Сценарий 2
Мэри является инженером данных с глубоким знанием нескольких требований к аналитическим отчетам бизнес-приложений. Команда вышестоящий успешно реализовала решение для переноса исторических и добавочных данных нескольких бизнес-объектов в общий lakehouse. Марии была поручено очистить данные, применить бизнес-логику и загрузить их в несколько назначений (например, Azure SQL DB, ADX и lakehouse) для подготовки соответствующих групп отчетности.
Мария является опытным пользователем Power Query, и объем данных находится в низком или среднем диапазоне для достижения требуемой производительности. Потоки данных предоставляют интерфейсы без кода или с низким кодом для приема данных из сотен источников данных. С помощью потоков данных можно преобразовывать данные, используя более 300 параметров преобразования данных, и записывать результаты в несколько назначений с простым в использовании и очень наглядным пользовательским интерфейсом. Мэри рассматривает параметры и решает, что имеет смысл использовать Dataflow 2-го поколения в качестве предпочтительного варианта преобразования.
Сценарий 3
Адам — инженер данных, работающий в крупной розничной компании, которая использует lakehouse для хранения и анализа данных клиентов. В рамках своей работы Адам отвечает за создание и обслуживание конвейеров данных, которые извлекают, преобразуют и загружают данные в lakehouse. Одним из бизнес-требований компании является выполнение анализа отзывов клиентов для получения ценных сведений о взаимодействии с клиентами и улучшения их услуг.
Адам решает, что лучшим вариантом является использование Spark для создания логики извлечения и преобразования. Spark предоставляет распределенную вычислительную платформу, которая может обрабатывать большие объемы данных параллельно. Он пишет приложение Spark с помощью Python или Scala, которое считывает структурированные, частично структурированные и неструктурированные данные из OneLake для отзывов клиентов и отзывов. Приложение очищает, преобразует и записывает данные в таблицы Delta в lakehouse. Затем данные готовы к использованию для нисходящей аналитики.