Как последние улучшения Dataflow меняют наш подход к игре
Делиться
Среди множества анонсов с недавней конференции FabCon Europe в Вене, один из них, возможно, остался незамеченным, касался улучшений производительности и оптимизации затрат для Dataflows Gen2.
Прежде чем мы перейдем к объяснению того, как эти улучшения повлияют на вашу текущую настройку Dataflows, давайте сделаем шаг назад и кратко рассмотрим Dataflows. Для тех, кто впервые сталкивается с Microsoft Fabric, Dataflow Gen2 — это элемент Fabric, не требующий или требующий минимального программирования, используемый для извлечения, преобразования и загрузки данных (ETL).
Dataflow Gen2 предоставляет множество преимуществ:
- Воспользуйтесь более чем 100 встроенными коннекторами для извлечения данных из множества источников.
- Используйте привычный графический интерфейс Power Query для применения десятков преобразований к данным без написания единой строки кода — мечта многих разработчиков-любителей.
- Сохраните результаты преобразования данных в виде дельта-таблицы в OneLake, чтобы преобразованные данные могли использоваться различными механизмами Fabric (Spark, T-SQL, Power BI и др.).
Однако простота обычно имеет свою цену. В случае с Dataflows это оказалось значительно более высоким потреблением CU по сравнению с решениями, ориентированными на код, такими как блокноты Fabric и/или скрипты T-SQL. Это уже хорошо объяснено и рассмотрено в двух замечательных статьях в блоге моих коллег-MVP, Гилберта Кевовилье (Fourmoo): «Сравнение Dataflow Gen2 и Notebook по стоимости и удобству использования» и Степана Ресла: «Копирование действий, Dataflows Gen2 и блокноты против списков SharePoint», поэтому я не буду тратить время на обсуждение прошлого. Вместо этого давайте сосредоточимся на том, что настоящее (и будущее) принесет Dataflows!
Изменения в модели ценообразования
Давайте кратко рассмотрим то, что показано на иллюстрации выше. Ранее каждая секунда работы Dataflow Gen2 оплачивалась по тарифу 16 CU (CU расшифровывается как Capacity Unit (единица мощности), представляющая собой набор ресурсов — ЦП, память и ввод-вывод — используемых в синергии для выполнения определенной операции). В зависимости от размера мощности Fabric вы получаете определенное количество единиц мощности — F2 предоставляет 2 CU, F4 — 4 CU и так далее.
Вернемся к нашему сценарию с потоками данных. Давайте разберем это на примере из реальной жизни. Допустим, у вас есть поток данных, который выполняется в течение 20 минут (1200 секунд)…
- Ранее выполнение этого потока данных обошлось бы вам в 19 200 вычислительных единиц : 1200 секунд * 16 вычислительных единиц.
- Теперь выполнение этого процесса Dataflow обойдется вам в 8100 CU : 600 секунд (первые 10 минут) * 12 CU + 600 секунд (после первых 10 минут) * 1,5 CU
Чем дольше выполняется ваш Dataflow, тем больше потенциальная экономия в CU (единицах ресурсов) вы получите.
Это само по себе удивительно, но дело не только в этом. Конечно, приятно получать меньшую плату за тот же объем работы, но что, если бы мы могли сократить эти 1200 секунд, скажем, до 800? Это позволило бы сэкономить не только вычислительные ресурсы, но и время анализа, поскольку данные обрабатывались бы быстрее. И именно об этом и будут следующие два улучшения…
Современный оценщик
Новая функция предварительного просмотра, получившая название Modern Evaluator, позволяет использовать новый механизм выполнения запросов (работающий на .NET Core версии 8) для запуска потоков данных. Согласно официальной документации Microsoft, потоки данных, использующие Modern Evaluator, могут обеспечить следующие преимущества:
- Более быстрое выполнение потока данных
- Более эффективная обработка
- Масштабируемость и надежность
Приведенная выше иллюстрация демонстрирует различия в производительности между различными «вариантами» Dataflow. Не волнуйтесь, мы скоро проверим эти показатели в демонстрации, и я также покажу вам, как включить эти новейшие улучшения в ваших рабочих нагрузках Fabric.
Разделенные вычисления
Ранее логика потока данных выполнялась последовательно. Следовательно, в зависимости от сложности логики, выполнение определенных операций могло занимать некоторое время, из-за чего другие операции в потоке данных должны были ожидать в очереди. Благодаря функции разделенных вычислений (Partitioned Compute) поток данных теперь может выполнять части логики преобразования параллельно, тем самым сокращая общее время выполнения.
В настоящий момент существуют определенные ограничения на то, когда запустится функция распределенных вычислений. А именно, использовать эту новую функцию могут только коннекторы ADLS Gen2, Fabric Lakehouse, Folder и Azure Blob Storage. Подробнее о том, как это работает, мы поговорим позже в этой статье.
3, 2, 1… Мотор!
Итак, пришло время проверить данные, предоставленные Microsoft, и выяснить, есть ли (и в какой степени) прирост производительности между различными типами потоков данных.
Вот наша ситуация: я сгенерировал 50 CSV-файлов, содержащих фиктивные данные о заказах. Каждый файл содержит приблизительно 575 000 записей, таким образом, всего около 29 миллионов записей (примерно 2,5 ГБ данных). Все файлы уже хранятся в папке SharePoint, что позволяет провести корректное сравнение, поскольку Dataflow Gen1 не поддерживает OneLake Lakehouse в качестве источника данных.
Я планирую провести две серии тестов: во-первых, включу в сравнение Dataflow Gen1. В этом сценарии я не буду записывать данные в OneLake с помощью Dataflow Gen2 (да, я знаю, это противоречит назначению Dataflow Gen2), так как я хочу сравнивать «яблоки с яблоками» и исключить время, необходимое для записи данных в OneLake. Я протестирую следующие четыре сценария, в которых буду выполнять некоторые базовые операции по объединению и загрузке данных, применяя некоторые базовые преобразования (переименование столбцов и т. д.):
- Используйте Dataflow Gen1 (старый поток данных Power BI).
- Используйте Dataflow Gen2 без каких-либо дополнительных улучшений оптимизации.
- Используйте Dataflow Gen2, включив только современный инструмент оценки.
- Используйте Dataflow Gen2 с включенными функциями современной оценки и распределенных вычислений.
Во второй серии я сравню три варианта Dataflow Gen2 (пункты 2-4 из приведенного выше списка) с включенной записью данных в хранилище Lakehouse.
Давайте начнём!
Dataflow Gen1
Весь процесс преобразования в старой версии Dataflow Gen1 довольно прост — я просто объединил все 50 файлов в один запрос, разделил столбцы по разделителю и переименовал их. Так что ничего действительно сложного здесь не происходит:
Ко всем трем потокам данных Gen2 был применен один и тот же набор операций/преобразований.
Пожалуйста, имейте в виду, что с Dataflow Gen1 невозможно вывести данные в виде таблицы Delta в OneLake. Все преобразования сохраняются внутри самого Dataflow, поэтому, когда вам понадобятся эти данные, например, в семантической модели, вам необходимо учитывать время и ресурсы, необходимые для загрузки/обновления данных в режиме импорта семантической модели. Но об этом позже.
Dataflow Gen2 без улучшений
Теперь давайте сделаем то же самое, но на этот раз используя новый Dataflow Gen2. В этом первом сценарии я не применял ни одну из этих новых функций оптимизации производительности.
Dataflow Gen2 с современным оценщиком
Итак, настал момент истины — давайте теперь включим современный механизм оценки запросов для Dataflow Gen2. Я перейду в «Параметры», а затем на вкладке «Масштабирование» установлю флажок «Разрешить использование современного механизма оценки запросов»:
Всё остальное остаётся точно таким же, как и в предыдущем случае.
Dataflow Gen2 с современным оценщиком и разделенными вычислениями
В последнем примере я включу обе новые функции оптимизации в параметрах Dataflow Gen2:
Теперь перейдём к тестированию и анализу результатов. Я буду последовательно выполнять все четыре потока данных из конвейера Fabric, чтобы убедиться, что каждый из них работает изолированно от других.
И вот результаты:
Очевидно, что в данном конкретном сценарии разделение данных не имело большого значения, и я более подробно рассмотрю, как работает разделение данных, в одной из следующих статей, рассматривая различные сценарии. Dataflow Gen2 с включенным Modern Evaluator значительно превзошел все остальные , обеспечив экономию в 30% по сравнению со старым Dataflow Gen1 и примерно 20% экономии времени по сравнению с обычным Dataflow Gen2 без каких-либо оптимизаций! Не забывайте, что эта экономия также отражается на экономии CU, поэтому окончательная оценочная стоимость CU для каждого из используемых решений выглядит следующим образом:
- Dataflow Gen1: 550 секунд * 12 CU = 6600 CU
- Dataflow Gen2 без оптимизации: 520 секунд * 12 CU = 6,240 CU
- Dataflow Gen2 с Modern Evaluator: 368 секунд * 12 CU = 4,416 CU
- Dataflow Gen2 с современным оценщиком и секционированием: 474 секунды * 12 CU = 5,688 CU
Однако я хотел перепроверить и подтвердить точность своих расчетов. Поэтому я открыл приложение Capacity Metrics и посмотрел на показатели, которые оно собирает:
Хотя общий результат точно отражает цифры, отображаемые в журнале выполнения конвейера, точное количество использованных CU в приложении отличается:
- Dataflow Gen1: 7,788 CUs
- Dataflow Gen2 без оптимизации: 5,684 CU.
- Dataflow Gen2 с Modern Evaluator: 3,565 CUs
- Dataflow Gen2 с современным инструментом оценки и секционированием: 4,732 CU.
Таким образом, согласно приложению Capacity Metrics, Dataflow Gen2 с включенным Modern Evaluator потребил менее 50% ресурсов по сравнению с Dataflow Gen1 в этом конкретном сценарии! В ближайшие дни/недели я планирую создать больше тестовых сценариев и предоставить более полную серию тестов и сравнений, которая также будет включать время записи данных в OneLake (с использованием Dataflow Gen2) по сравнению со временем, необходимым для обновления семантической модели режима импорта, которая использует старый Dataflow Gen1.
Заключение
По сравнению с другими (ориентированными на код) вариантами, Dataflows (справедливо?) считались «самым медленным и наименее производительным вариантом» для загрузки данных в Power BI/Microsoft Fabric. Однако в мире Fabric все быстро меняется, и мне нравится, как команда Fabric Data Integration постоянно улучшает продукт. Честно говоря, мне любопытно посмотреть, как будет меняться производительность и стоимость Dataflows Gen2 с течением времени, чтобы мы могли рассмотреть возможность использования Dataflows не только для задач загрузки и преобразования данных с минимальным или полным отсутствием кода, но и в качестве жизнеспособной альтернативы решениям, ориентированным на код, с точки зрения соотношения стоимости и производительности.
Спасибо за прочтение!
Оговорка: Я не имею никаких связей с Microsoft (за исключением статуса Microsoft Data Platform MVP), и Microsoft не обращалась ко мне с просьбой написать эту статью и не предоставляла мне спонсорскую поддержку.
Источник: towardsdatascience.com
