Місяць активних релізів Apache Iceberg: що відбувається в екосистемі Lakehouse

Коротко: початок вересня 2026 року виявився дуже активним для Apache Iceberg і суміжної Lakehouse-екосистеми. PyIceberg 0.12 уже вийшов, Apache DataFusion 55.1.0 встиг перейти в реліз, iceberg-rust 0.11 проходить release-candidate цикл, Apache Polaris готує 1.8.0, а навколо REST Catalog активно обговорюють fine-grained access і catalog-owned labels. Головна тенденція цього періоду — екосистема дорослішає не лише технічно: дедалі більше дискусій стосується меж відповідальності між форматами, каталогами, execution engines та інтеграціями.

Вступ

Apache Iceberg давно перестав бути лише специфікацією формату таблиць. Навколо нього сформувався великий набір реалізацій, каталогів, engine integrations та інструментів керування інфраструктурою. Саме тому окремі релізи PyIceberg, iceberg-rust або DataFusion дедалі частіше мають прямий вплив на те, як працює Lakehouse у production.

Наприкінці серпня та у першій половині вересня 2026 року одразу кілька частин цього стека отримали нові релізи або увійшли в активну фазу підготовки до них. Частина подій належить безпосередньо Apache Iceberg, частина — сусіднім Apache-проєктам, що використовуються разом із ним.

У цій статті розберемо найважливіші зміни й дискусії та подивимося, яку спільну тенденцію вони формують для Lakehouse-архітектур.

Чому цей період важливий для data engineering?

Зараз змінюється одразу кілька шарів Lakehouse-стека:

• Python-клієнт Iceberg стає повноціннішим для write-сценаріїв і RESTCatalog;
• Rust-реалізація готує наступний реліз і паралельно переглядає межі інтеграції з DataFusion;
• DataFusion продовжує швидкий release cadence як важливий Rust-based query engine;
• Polaris розвивається як open catalog для Iceberg-таблиць;
• REST Catalog specification отримує нові пропозиції навколо finer-grained read restrictions і catalog-owned labels.

Тобто головна тема — не просто «більше релізів». Lakehouse поступово розділяє відповідальність між table format, catalog, execution engine і governance layer, і саме на межах між цими компонентами виникають найважливіші архітектурні рішення.

Що нового у PyIceberg 0.12?

Apache Iceberg Python 0.12.0 вийшов 1 вересня 2026 року, а офіційний release post Apache Iceberg був опублікований 3 вересня. Реліз охоплює роботу з початку лютого до кінця серпня та включає понад 470 merged pull requests від 58 contributors.

Серед ключових напрямів релізу — розширення REST Catalog support, зокрема read support для Iceberg views, розвиток write-path і покращення роботи з metadata operations.

Це важливий крок для PyIceberg, оскільки Python-реалізація дедалі менше виглядає як допоміжний metadata client і дедалі більше — як самостійний інструмент для повноцінної роботи з Iceberg tables у Python-centric data stacks.

Сам процес релізу також добре показує модель ASF: release candidates проходять перевірку signatures, checksums, LICENSE/NOTICE, source artifacts і build/test validation кількома учасниками спільноти до публікації.

Що відбувається з Terraform provider для Apache Iceberg?

Окремим напрямом став Apache Iceberg Terraform Provider 0.1.0 — інструмент для керування namespaces і tables через Terraform або OpenTofu.

Release candidate RC3 був винесений на голосування 27 серпня після попередніх ітерацій релізу. Саме такий цикл добре ілюструє суворість Apache release process: проблеми з LICENSE/NOTICE або dependency attribution можуть зупинити candidate навіть тоді, коли сам код працює коректно.

Для production-команд ця деталь важлива практично. IaC-провайдер навколо Iceberg означає, що table/catalog resources поступово стають частиною звичного infrastructure-as-code workflow, а не ручної конфігурації.

Що відбувається з iceberg-rust 0.11?

Rust-реалізація Apache Iceberg у вересні готує версію 0.11.0. 15 вересня спільнота відкрила голосування за RC2, після того як у попередніх ітераціях довелося виправляти packaging і publishing issues навколо crates.io.

Це ще один показник зрілості проєкту: питання вже не зводяться лише до реалізації специфікації Iceberg. Важливими стають release automation, crate dependency graph, compatibility і правильне пакування Python bindings через pyiceberg-core.

Чи варто відокремлювати iceberg-datafusion від iceberg-rust?

Одна з найцікавіших архітектурних дискусій стосується інтеграції Iceberg із Apache DataFusion. У серпні з’явилася пропозиція винести iceberg-datafusion з основного iceberg-rust repository в окремий repository.

Мотивація практична: DataFusion має власний швидкий release cycle, а інтеграція значною мірою залежить саме від нього. Водночас iceberg-rust продовжує використовувати цю інтеграцію для integration testing.

Обговорення показує типову проблему зрілої open-source екосистеми: модуль може формально жити в одному проєкті, але фактично еволюціонувати в ритмі іншого. У такій ситуації питання repository ownership і reviewer bandwidth стають частиною архітектури, а не лише організації GitHub.

Що відбувається у Apache DataFusion?

Apache DataFusion 55.1.0 був випущений 11 вересня 2026 року. Це окремий Apache-проєкт, але він важливий для Iceberg-екосистеми через Rust-native analytical query execution та інтеграції навколо iceberg-datafusion.

Тому його релізи варто розглядати не як «реліз Apache Iceberg», а як зміну в суміжному execution layer Lakehouse-стека. Саме цей поділ важливий для архітекторів: Iceberg відповідає за table format і metadata semantics, DataFusion — за query execution.

Яке місце займають Arrow і Parquet?

Apache Arrow і Apache Parquet — ще два фундаментальні шари, на яких стоять сучасні аналітичні системи. Вони тісно пов’язані з Iceberg, але мають власні release cycles.

arrow-rs 59.3.0 вийшов 25 серпня 2026 року як maintenance release із security та bug fixes, а 10 вересня вже вийшла major-версія 60.0.0.

parquet-java 1.18.1 був випущений 4 серпня 2026 року.

Цей приклад добре показує, наскільки легко змішати в одному інформаційному потоці різні Apache-проєкти. Для production-команди важливо відстежувати їх окремо, тому що сумісність змінюється не синхронно.

Що відбувається з Apache Polaris?

Apache Polaris — окремий open-source catalog project, який активно використовується в Iceberg-oriented Lakehouse architectures. 17 вересня 2026 року спільнота відкрила голосування за Polaris 1.8.0 RC0.

Перший candidate одразу отримав -1 через NOTICE concerns у bundled dependencies. Це типовий приклад Apache release governance: юридична коректність distribution artifacts є такою самою частиною release quality, як tests або runtime behavior.

Polaris важливий у цьому контексті, тому що дедалі більше Lakehouse-функцій переміщуються з execution engine на рівень catalog: access policies, metadata discovery, multi-engine coordination та interoperability.

Як змінюється підтримка Flink в Apache Iceberg?

У підготовці майбутнього Java-релізу Iceberg продовжується дискусія про підтримувану матрицю Apache Flink. Основна проблема — різні release cadences двох проєктів.

Для Iceberg важливо одночасно підтримувати достатньо свіжі Flink versions і не залишати production-команди без реалістичного upgrade path. Тому модель підтримки на кшталт LTS плюс кілька останніх релізів виглядає привабливо, але потребує компромісу з backward compatibility.

Для data engineering це не академічне питання: версія Iceberg runtime часто напряму визначає, чи можна оновити Flink cluster без одночасної великої міграції всього stack.

Що таке finer-grained read restrictions у REST Catalog?

Одна з важливих specification discussions у 2026 році стосується finer-grained read restrictions у Iceberg REST Catalog.

Ідея полягає в тому, щоб catalog міг повертати більш точні обмеження на читання даних, а клієнти й engines інтерпретували їх узгоджено. Це може охоплювати column projections та інші правила доступу.

Архітектурно це важливо тому, що access policy починає жити ближче до catalog layer, а не бути окремою конфігурацією Spark, Trino або іншого engine.

У multi-engine Lakehouse такий підхід дає шанс зберегти однакові правила доступу незалежно від того, який engine читає одну й ту саму Iceberg table.

Що означає дискусія про table і column labels?

Окрема пропозиція додає optional labels до Iceberg REST Catalog load response. Йдеться про catalog-owned metadata — наприклад classification, ownership, domain або cost attribution — які catalog може повертати разом із інформацією про table.

Важливо, що сама пропозиція не визначає governance system і не перетворює labels на policy language. Labels задумуються як read-only catalog metadata, а те, як конкретна платформа використає їх для governance, lineage або access control, залишається поза межами специфікації.

Саме тут добре видно межу відповідальності: Iceberg стандартизує спосіб передати metadata, але не нав’язує повну governance-модель поверх нього.

Чим Lakehouse на Apache Iceberg відрізняється від традиційної бази даних?

Apache Iceberg — open table format для великих аналітичних datasets. Він додає transaction semantics, schema evolution, partition evolution, snapshots і time travel поверх файлів у object storage.

У Lakehouse storage, table format, catalog і compute engine можуть належати різним компонентам. Наприклад, дані лежать у S3, таблиця описана Iceberg metadata, catalog обслуговує Polaris або інша система, а query execution виконують Spark, Trino, Flink чи DataFusion.

Саме така модульність і породжує більшість дискусій цього періоду. Коли немає одного монолітного DBMS, потрібно чітко визначати, який шар відповідає за metadata, access policy, execution semantics та integrations.

Що означає цей період для data engineers?

Для практичної роботи висновки досить конкретні:

• відстежуйте release cycles Iceberg, PyIceberg, Rust implementation і execution engines окремо;
• перевіряйте compatibility matrix перед оновленням Spark/Flink/DataFusion integrations;
• сприймайте catalog як дедалі важливіший security і governance layer;
• не плутайте table-format release із релізами Arrow, Parquet, DataFusion або Polaris;
• для production upgrade перевіряйте не лише code changes, а й release notes, LICENSE/NOTICE та migration constraints.

FAQ: питання про Apache Iceberg

Питання: Що таке Apache Iceberg?

Відповідь: Apache Iceberg — open table format для великих аналітичних datasets. Він додає snapshots, ACID-like table operations, schema evolution, partition evolution і time travel поверх файлів у data lake.

Питання: Що таке PyIceberg 0.12?

Відповідь: Це Python-реалізація Iceberg, випущена у вересні 2026 року. Реліз розширює REST Catalog і view support та продовжує розвиток Python write-path.

Питання: Чи є DataFusion частиною Apache Iceberg?

Відповідь: Ні. Apache DataFusion — окремий Apache query engine. Він тісно інтегрується з iceberg-rust, тому його release cycle важливий для Rust-side Lakehouse stack.

Питання: Чи є Apache Polaris частиною Iceberg?

Відповідь: Polaris — окремий Apache catalog project, орієнтований на open Lakehouse і Iceberg use cases. Він взаємодіє з Iceberg, але має власне governance і releases.

Питання: Apache Iceberg vs Delta Lake — що обрати?

Відповідь: Обидва формати вирішують схожі Lakehouse-задачі. Iceberg широко орієнтований на multi-engine interoperability, тоді як Delta Lake має особливо глибоку інтеграцію з Databricks ecosystem. Вибір залежить від catalog, engines, governance і cloud stack.

Питання: Скільки коштує Apache Iceberg?

Відповідь: Apache Iceberg — open-source project під Apache License 2.0. Витрати виникають на storage, compute, catalogs та managed services, які використовуються разом із ним.

Висновок

Початок вересня 2026 року показує, наскільки великою стала екосистема навколо Apache Iceberg. PyIceberg уже випустив 0.12, iceberg-rust готує 0.11, DataFusion продовжує швидкий release cadence, Polaris розвиває catalog layer, а в REST specification активно обговорюють fine-grained access і labels.

Спільна тенденція тут важливіша за окремі номери версій: Lakehouse стає дедалі модульнішим. Table format, catalog, query engine, file format та governance більше не належать одному продукту, тому межі відповідальності між ними стають центральною архітектурною темою.

Для data engineers це означає, що стежити потрібно не лише за Apache Iceberg як таким, а за всім ланцюжком сумісності — від Arrow і Parquet до catalogs та execution engines.