Руководство по принятию решений Microsoft Fabric: действие копирования, поток данных или Spark

  • Статья

Используйте это справочное руководство и примеры сценариев, которые помогут вам определить, требуется ли действие копирования, поток данных или Spark для рабочих нагрузок Microsoft Fabric.

свойства действие Copy, потока данных и Spark

Действие копирования конвейера Поток данных 2-го поколения Spark
Вариант использования Миграция озера данных и хранилища данных
прием данных,
упрощенное преобразование		 Прием данных,
преобразование данных,
обработка данных,
профилирование данных		 Прием данных,
преобразование данных,
обработка данных,
профилирование данных
Основной пользователь разработчика Инженер данных,
интегратор данных		 Инженер данных,
интегратор данных,
бизнес-аналитик		 Инженер данных,
специалист по обработке и анализу данных,
разработчик данных
Основной набор навыков разработчика ETL
SQL
JSON		 ETL
M,
SQL		 Spark (Scala, Python, Spark SQL, R)
Написанный код Нет кода,
низкий код		 Нет кода,
низкий код		 Код
Том данных От низкой до высокой От низкой до высокой От низкой до высокой
Интерфейс разработки Мастер
брезент		 Power Query Ноутбука
Определение задания Spark
Источники 30+ соединителей 150+ соединителей Сотни библиотек Spark
Назначения 18+ соединителей Lakehouse,
База данных SQL Azure,
Обозреватель данных Azure,
Аналитика Azure Synapse		 Сотни библиотек Spark
Сложность преобразования Низкий
упрощенный — преобразование типов, сопоставление столбцов, слияние и разделение файлов, плоская иерархия		 Низкий и высокий:
300+ функции преобразования		 Низкий и высокий:
поддержка собственных библиотек Spark и open-source

Ознакомьтесь со следующими тремя сценариями, чтобы помочь в выборе способа работы с данными в Fabric.

Сценарий 1

Лео, инженер данных, должен принять большой объем данных из внешних систем, как локальных, так и облачных. К этим внешним системам относятся базы данных, файловые системы и API. Лео не хочет писать и поддерживать код для каждой операции соединителя или перемещения данных. Он хочет следовать за слоями медальона, с бронзовым, серебряным и золотым. Лео не имеет опыта работы с Spark, поэтому он предпочитает перетаскивание пользовательского интерфейса как можно больше, с минимальным кодом. И он также хочет обработать данные по расписанию.

Первым шагом является получение необработанных данных в бронзовом слое lakehouse из ресурсов данных Azure и различных сторонних источников (например, Snowflake Web, REST, AWS S3, GCS и т. д.). Он хочет консолидированного озера, чтобы все данные из различных бизнес-объектов, локальных и облачных источников располагались в одном месте. Лео проверяет параметры и выбирает действие копирования конвейера в качестве подходящего варианта для его необработанной двоичной копии. Этот шаблон применяется как к обновлению исторических, так и добавочных данных. При действии копирования Лео может загружать данные Gold в хранилище данных без кода, если возникает необходимость, а конвейеры обеспечивают прием данных с высоким уровнем масштабирования, которые могут перемещать данные петабайтового масштабирования. действие Copy — это лучший вариант с низким кодом и без кода для перемещения петабайт данных в озерах и хранилищах из разновидностей источников, либо с помощью специального или по расписанию.

Сценарий 2

Мэри является инженером данных с глубокими знаниями о нескольких требованиях к аналитическим отчетам бизнес-аналитики. Команда вышестоящий успешно реализовала решение для переноса исторических и добавочных данных нескольких бизнес-объектов в общее озеро. Мэри была поставлена задача по очистке данных, применению бизнес-логики и загрузке ее в несколько назначений (например, в базу данных SQL Azure, ADX и озеро) в подготовке к соответствующим группам отчетов.

Мэри является опытным пользователем Power Query, и объем данных находится в низком до среднего диапазона для достижения требуемой производительности. Потоки данных предоставляют интерфейсы без кода или низкокода для приема данных из сотен источников данных. С помощью потоков данных можно преобразовать данные с помощью 300+ параметров преобразования данных и записать результаты в несколько назначений с простым визуальным пользовательским интерфейсом. Мэри рассматривает варианты и решает, что имеет смысл использовать поток данных 2-го поколения в качестве ее предпочтительного варианта преобразования.

Сценарий 3

Адам является инженером данных, работающим в крупной розничной компании, которая использует lakehouse для хранения и анализа данных клиента. В рамках своей работы Адам отвечает за создание и обслуживание конвейеров данных, которые извлекают, преобразуют и загружают данные в lakehouse. Одним из бизнес-требований компании является выполнение аналитики проверки клиентов, чтобы получить аналитические сведения о опыте своих клиентов и улучшить свои услуги.

Адам решает, что лучше всего использовать Spark для создания логики извлечения и преобразования. Spark предоставляет распределенную вычислительную платформу, которая может параллельно обрабатывать большие объемы данных. Он пишет приложение Spark с помощью Python или Scala, который считывает структурированные, полуструктурированные и неструктурированные данные из OneLake для отзывов клиентов и отзывов. Приложение очищает, преобразует и записывает данные в таблицы Delta в lakehouse. Затем данные будут готовы к использованию для нисходящей аналитики.

Связанный контент