AWS Glue 5.1 на Spark 3.5.6: Що мають зробити дата-команди

Будь-який технічний лід, який запускав пакетний job у неділю вранці, знає той момент, коли невідповідність версій Spark спливає в треді Slack, який ніхто не хоче читати. AWS Glue двічі оновив свій runtime за дванадцять місяців, і якщо ваша команда досі прив'язує jobs до версії 4.0, ви відстаєте вже на два major-оновлення рушія. Поточний навчальний шлях від Amazon через серверний ETL веде безпосередньо до Glue 5.1, і розрив між тим, де знаходиться більшість команд, і тим, з чого мають стартувати нові проєкти, лише збільшився.

Що сталося

Як повідомляв tech-insider.org у матеріалі Надії Дюбуа від 21 серпня 2026 року, AWS Glue 5.1 був випущений 26 листопада 2025 року і тепер працює на Apache Spark 3.5.6, Python 3.11 та Scala 2.12.18. Цей реліз пішов слідом за Glue 5.0, який вийшов наприкінці 2024 року на Spark 3.5.4 і підняв рушій із базового рівня Spark 3.3.0, на якому застряг Glue 4.0. На практиці команди, що пропустили один цикл, стикаються з переходом одразу через два minor-версії Spark та зміною інтерпретатора Python в рамках однієї міграції.

Glue 5.0 приніс більше, ніж просто Spark. Він включав Java 17, Hudi 0.15.0, Iceberg 1.7.1 та Delta Lake 3.3.0, а також додав підтримку Amazon SageMaker Unified Studio та SageMaker Lakehouse. Glue 5.1 використовує ті самі версії Python і Scala, що й 5.0, і, за формулюванням самого AWS, додає покращення продуктивності та безпеки поверх оновлення до Spark 3.5.6.

Зміна з найбільшим операційним впливом відбулася у червні 2025 року, коли AWS додав підтримку Spark jobs у Glue 5.0 для прямого читання та запису в таблиці, зареєстровані в AWS Lake Formation, за умови що IAM-роль job має повний доступ до таблиць. Саме такі тихі оновлення функціональності перебудовують патерни доступу до lakehouse без гучних оголошень.

Технічна анатомія

Архітектура Glue принципово не змінилася. Як і раніше, є три ключові компоненти: Glue Data Catalog як спільне сховище метаданих, Crawlers для виявлення схем та Jobs як обчислювальний ETL-шар. Data Catalog залишається найважливішою частиною, оскільки його читають Athena, Redshift Spectrum, EMR та Lake Formation. Каталогізуйте дані один раз — і запитуйте їх із чотирьох рушіїв. Це і є реальний продукт.

Що змінилося — так це runtime. Перехід із Spark 3.3.0 у Glue 4.0 на Spark 3.5.6 у Glue 5.1 — це не патч-оновлення. Оптимізатор Catalyst поводиться інакше, значення за замовчуванням для adaptive query execution змінились, а Python 3.11 ламає все, що прив'язане до старої поведінки типізації або видалених модулів стандартної бібліотеки. Команди, з якими я працював у схожих діапазонах версій Spark, стабільно недооцінюють складність UDF-шару, особливо там, де pandas UDFs взаємодіють із версіями PyArrow. Якщо у вас є jobs на Scala 2.12, перехід буде відносно м'яким, оскільки Glue 5.x залишається на Scala 2.12.18. Тим, хто розглядає Scala 2.13, полегшення тут немає.

Зміна прямого читання/запису через Lake Formation заслуговує окремого абзацу. До червня 2025 року запуск Spark job проти таблиць, керованих Lake Formation, означав роботу в обхід моделі дозволів або відкат до читання лише через каталог. Тепер, якщо IAM-роль job має повний доступ до таблиць, Glue 5.0 Spark може звертатися до них безпосередньо. Саме це нарешті робить Glue дієздатним як основне обчислювальне середовище для lakehouse на базі Lake Formation, а не лише учасником на рівні метаданих. Для команд, що стандартизують на Iceberg через Lake Formation, це закриває реальний пробіл. Для команд, що використовують Delta, кероване Databricks, на тих самих даних, картина менш чітка; документація Databricks досі передбачає, що ви контролюєте обчислювальний рівень.

Деталь, яка варта уваги для чутливих до вартості навантажень: Glue Python Shell jobs запускають звичайний Python без розгортання Spark-кластера. Обчислення Glue ETL тарифікуються посекундно на основі DPU-годин, тому Python Shell job для легкого оркестраційного завдання може бути на порядок дешевшим, ніж Spark job, що витрачає більшу частину часу на запуск кластера. Це гроші, які команди залишають на столі, коли за замовчуванням обирають тип Spark для кожного job.

Хто постраждає найбільше

Найважчий квартал чекає на команди, що запускають production Glue 4.0 jobs із великою кількістю PySpark UDFs і без дисципліни явного закріплення версій runtime. Два minor-версії Spark і перехід із Python 3.9 на 3.11 — це не просте перенесення. Регресійне тестування з'їсть реальний інженерний час. У десятиособовій дата-платформній команді двоінженерна міграційна робота на квартал — це двадцять відсотків вашої потужності, і це ще до того, як хтось відкриє тікет про зламаний downstream-запит в Athena.

iGaming- та fintech-компанії, що запускають заплановані пакетні ETL проти S3 data lakes, — очевидна група ризику, особливо там, де один і той самий каталог живить дашборди Athena для compliance-звітності. Незручна правда: якщо ви побудували свій стек звітності на Glue 4.0 у 2023 році і більше до нього не торкались, бо він просто працював, ви тепер відстаєте на три роки і два runtime, а годинник депрекації не зупиняється заради вашої зручності.

Команди lakehouse отримують змішані новини. Якщо ви зупинились на Iceberg поверх Lake Formation, Glue 5.0 і 5.1 — це перші релізи Glue, де вся картина складається від початку до кінця. Якщо ви зупинились на Delta Lake із Databricks-керованими обчисленнями і використовували Glue як дешевий вторинний рушій, ціннісна пропозиція стає тоншою. Delta Lake 3.3.0 входить до складу Glue 5.0, але операційний центр ваги для Delta залишається в іншому місці.

Команди, що використовують Snowflake як сховище, а Glue лише як рівень інгестії, здебільшого не зачеплені змінами lakehouse, але мають звернути увагу на оновлення до Python 3.11. Будь-який кастомний код конектора, написаний під семантику 3.9, потребує перегляду. Патерни інгестії Snowflake задокументовані в документації Snowflake, якщо ви переосмислюєте межі інтеграції.

План дій для дата-команд

Моя позиція: жоден новий проєкт Glue, розпочатий у Q3 2026, не повинен орієнтуватись на версію, старішу за 5.1. Розрив у runtime буде лише збільшуватись, а старт на 4.0 сьогодні — це підписка на міграцію, яку ви ще не оцінили.

Конкретні кроки на цей тиждень:

• Проінвентаризуйте ваші Glue jobs за версіями. Якщо ви не можете скласти таблицю кожного job і його runtime до п'ятниці, це перша проблема, яку треба вирішити. Одразу ж позначте jobs командою-власником.
• Явно закріпіть версії runtime. Не покладайтесь на значення за замовчуванням. У примітках до релізів версій Glue перераховані точні версії Hadoop, Iceberg, Hudi та Delta Lake для кожного релізу. Закріпіть їх у вашому IaC відповідно до цієї матриці.
• Перевірте UDFs на сумісність із Python 3.11. Все, що використовує distutils, застарілі API asyncio або старі патерни типізації, потребує уваги перед тим, як переключити job на 5.1.
• Перекласифікуйте jobs за типом. Будь-який job, який фактично є оркестрацією або легкою обробкою даних, слід перенести на Python Shell, а не Spark ETL. Glue тарифікується за DPU-годинами, а запуск Spark-кластера для 30-секундного навантаження — це чисті витрати.
• Протестуйте інтеграцію з Lake Formation у sandbox. Якщо ви використовуєте керовані таблиці, валідуйте шлях прямого читання/запису, доданий у червні 2025, із роллю, що має повний доступ до таблиць, перш ніж переналаштовувати production jobs.

Для команд, що оцінюють, чи є Glue взагалі правильним інструментом, чесна відповідь залежить від форми навантаження. Якщо ваші трансформації SQL-орієнтовані, а сховище є центром всесвіту, dbt разом із рушієм сховища перевершить Glue за ергономікою щоразу. Glue заробляє свої DPU-години тоді, коли у вас є реальні Spark-навантаження, нативні дані на S3 та каталог, яким ви хочете ділитися між рушіями.

Ключові висновки

• AWS Glue 5.1 вийшов 26 листопада 2025 року на Spark 3.5.6, Python 3.11 та Scala 2.12.18. Жоден новий проєкт не повинен орієнтуватись на старіший runtime.
• Перехід із Spark 3.3.0 на 3.5.6 від Glue 4.0 до 5.1 — це справжня міграція, а не версійне оновлення. Плануйте бюджет відповідно.
• Підтримка прямого читання/запису через Lake Formation, додана в червні 2025 року, робить Glue дієздатним як основне обчислювальне середовище для lakehouse під керуванням Lake Formation, якщо IAM-роль має повний доступ до таблиць.
• Glue Python Shell jobs повністю оминають Spark-кластер і є правильним вибором за замовчуванням для легких навантажень із тарифікацією за DPU-годинами.
• Data Catalog залишається реальною перевагою Glue: спільний доступ для Athena, Redshift Spectrum, EMR та Lake Formation із єдиного сканування.