UK
English
Deutsch
Español
Français
Italiano
Português
Nederlands
Polski
Bahasa Indonesia
Русский
العربية
עברית
日本語
한국어Dataflows Gen1 і Gen2 у Microsoft Fabric: вибір правильної архітектури staging та обчислень
By Mirko Peters ·
Порівняйте Dataflows Gen1 і Gen2 у Microsoft Fabric. Дізнайтеся, як сховище, staging обчислень і ємність впливають на вашу стратегію хмарного ETL.
Automatically translated with AI from the original post. Read the English original
Під час міграції ETL-навантажень до Microsoft Fabric вибір правильної архітектури staging і обчислень між Dataflows Gen1 і Gen2 безпосередньо впливає на продуктивність конвеєрів, витрати на ресурси та довіру до даних. Розуміння відмінностей у розподілі обчислень і роботі зі сховищем дозволяє уникнути дорогих архітектурних вузьких місць, поки ваша команда масштабує звіти.
Головне
- Dataflows Gen2 додає нативну інтеграцію з OneLake, що принципово змінює те, як дані проходять staging і зберігаються, порівняно з Gen1.
- Неправильний вибір варіанта обчислень під час розробки може призвести до несподіваного обмеження ємності та погіршення продуктивності у вашому робочому просторі Fabric.
- Gen1 значною мірою покладався на зовнішні механізми зберігання, тоді як Gen2 записує дані напряму в таблиці Fabric Lakehouse як пункт призначення за замовчуванням.
- Правильна конфігурація staging запобігає повторним перетворенням даних і оптимізує оновлення семантичних моделей Power BI.
- Узгодження вашої стратегії ETL з одиницями ємності Fabric допомагає організації уникнути неконтрольованих витрат на обчислення.
Розуміння архітектурного зсуву у Fabric
Перехід від застарілих dataflows Power BI до dataflows Microsoft Fabric — це не просто ребрендинг, а повна архітектурна перебудова того, як хмарні дані приймаються, перетворюються і зберігаються. У старому світі Gen1 dataflows створювалися переважно для живлення семантичних моделей Power BI. Вони працювали в дещо ізольованій екосистемі: перетворення даних відбувалися в Power Query Online, а результат зберігався у внутрішньому сховищі, яким повністю керувала служба Power BI.
З появою Microsoft Fabric Dataflows Gen2 створено з нуля, щоб використовувати OneLake як центральне сховище даних. Це означає, що кожне перетворення, яке ви застосовуєте через Power Query Online, більше не замкнене в закритому контейнері моделі. Натомість Gen2 поєднує самообслуговувану підготовку даних із корпоративною інженерією даних, записуючи дані напряму в таблиці Delta Parquet у відкритому форматі всередині Lakehouse у Fabric. Ця фундаментальна зміна впливає на те, як хмарні архітектори підходять до staging даних, використання обчислень і довіри до даних у звітності.
Зсув парадигми зберігання
У старих схемах, якщо бізнес-аналітику потрібно було очистити експорт з Excel, видалити порожні рядки та відформатувати дати, ці дані залишалися всередині межі сховища dataflow. Якщо іншому відділу потрібен був той самий очищений набір даних, йому часто доводилося брати дані зі звіту або створювати запит заново. Dataflows Gen2 вирішує це, роблячи Lakehouse пріоритетним місцем призначення. Щойно dataflow виконується, очищені дані одразу доступні як таблиці Delta, готові для блокнотів Spark, кінцевих точок аналітики SQL і прямої звітності DirectLake без додаткового переміщення даних.
Рішення щодо обчислень і проміжного збереження, яке більшість команд упускає
Одне з найважливіших архітектурних рішень, які стоять перед інженерами під час побудови Dataflows Gen2, — це керування етапами обчислень і проміжного збереження. На відміну від Gen1, де управління обчисленнями здебільшого було приховано і часом незрозуміло, Gen2 працює на базових одиницях ємності Fabric (CU). Якщо ваша організація не стежить уважно за тим, як і коли дані проміжно зберігаються під час оцінки запиту, ви ризикуєте витратити ресурси ємності швидше, ніж очікували.
Коли ви застосовуєте складні перетворення, Power Query визначає, чи можна перенести кроки назад до джерела даних, чи їх потрібно виконати локально в рушії dataflow. У Gen2 область проміжного збереження працює як проміжна зона приймання. У разі неправильного налаштування великі набори даних можуть багаторазово завантажуватися в пам'ять, оброблятися і записуватися назад, створюючи зайве навантаження на обчислення. Архітекторам слід оцінити свої вихідні системи, мережеву затримку та складність перетворень, щоб вирішити, чи варто перенести обробку на бік вихідної бази даних, чи дозволити Fabric виконати основну роботу.
Оптимізація одиниць ємності для робочих навантажень ETL
Ємність Fabric є спільним пулом для всієї організації. Якщо неоптимізований Dataflow Gen2 запускає планові оновлення в години пікового навантаження, він може спожити ресурси ємності, що обмежує роботу та впливає на відтворення звітів Power BI для керівників. Щоб цього уникнути, команди мають ізолювати важкі завдання ETL у виділених робочих областях із відповідними резервами ємності або планувати їх на години, коли навантаження мінімальне. Розуміння того, як фонові обчислювальні завдання взаємодіють з інтерактивними навантаженнями, є ключовим для стабільної роботи середовища Fabric.
Довіра через послідовну архітектуру
Головна мета модернізації конвеєрів даних — позбутися ручних правок у Excel, які псують бізнес-звітність. Коли звіти не працюють, причина рідко в нестачі даних; майже завжди справа в нестачі довіри. Коли користувачі бачать суперечливі цифри, бо один звіт бере дані з необробленого CSV, а інший — зі застарілого dataflow, інтерес до звітів різко падає.
Стандартизуючи роботу на Dataflows Gen2 і використовуючи архітектуру Lakehouse, організації створюють єдине джерело правди. Очищені дати, стандартизовані назви стовпців і перевірена бізнес-логіка фіксуються один раз у dataflow і автоматично передаються далі. Це зменшує людські помилки, усуває залежність від окремих настільних комп'ютерів і гарантує, що коли керівництво відкриває панель, цифри в ній надійні та придатні для аудиту.
Висновок
Перехід на Dataflows Gen2 і робота з ними вимагають іншого погляду на хмарне сховище, бюджети обчислень і управління даними. Почавши з одного повторюваного процесу з неструктурованими таблицями та правильно перенісши його в Lakehouse Fabric, ваша команда зможе створити масштабовані конвеєри, які витримають перевірку часом. Щоб дізнатися про базові концепції цієї еволюції та почути експертні думки про сучасні стратегії хмарних рішень Microsoft, обов'язково послухайте повний випуск подкасту M365 FM.
Поширені запитання
У чому головна різниця між Dataflows Gen1 і Gen2 щодо сховища?
Dataflows Gen1 зберігають перетворені дані всередині внутрішньої межі сховища Power BI, тоді як Dataflows Gen2 записують дані безпосередньо у таблиці Delta Parquet відкритого формату в Lakehouse Microsoft Fabric через OneLake.
Як Dataflows Gen2 впливають на одиниці ємності Fabric?
Gen2 dataflows використовують базову ємність Fabric під час етапів обчислень і проміжного збереження. Неоптимізовані перетворення або важкі оновлення в години пікового навантаження можуть вичерпати ресурс ємності та обмежити роботу інших навантажень.
Чи можуть Dataflows Gen2 замінити традиційні конвеєри Azure Data Factory?
Для самообслуговування підготовки даних, легкого ETL та трансформації даних із низьким рівнем коду Dataflows Gen2 є чудовою альтернативою. Проте для складної корпоративної оркестрації, логіки розгалуження та просунутої інженерії даних і далі найкращими інструментами залишаються Azure Data Factory або Fabric Pipelines.
Навіщо важлива фаза staging у Dataflows Gen2?
Фаза staging виконує роль проміжного майданчика для трансформацій даних. Правильне налаштування staging запобігає повторній обробці даних, оптимізує query folding і забезпечує ефективний запис до цільового Lakehouse.
Як Dataflows Gen2 підвищують довіру до даних у звітності?
Автоматизуючи очищення хаотичних ручних експортів і централізуючи трансформації в багаторазових таблицях Lakehouse, Gen2 усуває ручні обхідні шляхи в Excel і забезпечує узгоджені, надійні дані для всіх подальших звітів.