У подкасті Confluent Developer головна тема розмови з Расселом Спітцером, principal software engineer у Snowflake та одним з ключових контриб’юторів Apache Iceberg, — як формат таблиць Iceberg перебудовують під епоху AI та стрімінгових навантажень. Якщо раніше Iceberg сприймали як «новий Hive» для аналітичних запитів, то зараз спільнота фактично переписує внутрішню архітектуру метаданих, щоб зменшити затримки комітів до рівня, сумісного з реальним стрімінгом.
Центральна ідея Iceberg v4 у цій площині — радикально спростити й «ущільнити» метадані так, щоб кожен коміт перетворився на одну невелику операцію запису. Для цього змінюється структура дерева метаданих, вводяться delete‑vector‑подібні прийоми на рівні маніфестів, а розмір верхнього рівня метаданих цілеспрямовано обмежують сотнями кілобайт. Паралельно Iceberg уже сьогодні дає змогу працювати з гілками таблиць, що дозволяє безпечно тестувати зміни перед злиттям у продакшен.
Вузьке горлечко стрімінгу: чому коміти стали проблемою
Iceberg з’явився як відповідь на обмеження Hive-таблиць у файлових сховищах: потрібен був формат, який дає ACID‑гарантії поверх об’єктного сториджу, дозволяє еволюцію схем, time travel і масштабування до тисяч файлів. Для батч-аналітики це спрацювало блискуче. Але стрімінг і AI навантаження висунули інші вимоги.
У потокових сценаріях головне — не лише обсяг даних, а й частота оновлень. Коміти відбуваються постійно: кожні секунди або навіть частки секунди. Кожен зайвий мережевий раунд-тріп чи додатковий запис у сховище перетворюється на затримку, яка множиться на тисячі подій.
Класична модель Iceberg передбачає складну ієрархію метаданих: маніфест-листи, маніфести, файли даних. Кожен коміт — це не просто оновлення одного файлу, а серія операцій: створення нових маніфестів, оновлення посилань, запис нового «снапшоту» таблиці. Для великих батчів це прийнятно, але для низьколатентного стрімінгу — вже ні.
Саме тут Iceberg v4 намагається змінити правила гри: замість того, щоб «ворушити» велику кількість метаданих при кожному оновленні, спільнота прагне звести все до одного маленького, але дуже добре спроєктованого файлу верхнього рівня.
Нове дерево метаданих: один маленький файл замість каскаду оновлень
Ключова зміна Iceberg v4 — редизайн дерева метаданих так, щоб при кожному коміті перезаписувався лише один невеликий файл верхнього рівня. Усе інше має бути максимально незмінним (immutable) і придатним до кешування.
Ідея проста, але радикальна для поточної реалізації: усе, що можна зробити незмінним, стає незмінним. Усе, що часто змінюється, концентрується в одному компактному шарі.
Цей верхньорівневий файл метаданих у v4 цілеспрямовано проєктують так, щоб його розмір тримався приблизно в межах 400 кілобайт. Це не випадкове число. Воно відображає компроміс між достатньою інформативністю (щоб описати актуальний стан таблиці) та ефективністю доступу в об’єктних сховищах на кшталт Amazon S3.
S3 та подібні сервіси мають відносно високу латентність на операцію, але добре працюють із невеликими файлами, які часто читаються й зрідка перезаписуються. Якщо верхній рівень метаданих укладається в сотні кілобайт, його можна швидко завантажити, закешувати в клієнтів і оновлювати без відчутних затримок навіть при високій частоті комітів.
Решта дерева метаданих — маніфести, посилання на файли даних — у такій моделі стають здебільшого незмінними структурами. Вони можуть жити довго, кешуватися на стороні обчислювальних рушіїв і не брати участі в кожному окремому коміті. Це зменшує як кількість I/O‑операцій, так і ризик конфліктів при конкурентних оновленнях.
Коміт як одна I/O‑операція: що змінюється в роботі з файлами
Щоб звести коміт до одного запису, Iceberg v4 змінює не лише форму дерева метаданих, а й саму процедуру додавання нових файлів даних.
У поточних версіях Iceberg типовий коміт виглядає так: спочатку створюються нові маніфест-файли, які описують додані або видалені файли даних, потім оновлюється верхній рівень метаданих, який посилається на ці маніфести. Це означає щонайменше кілька операцій запису в сховище, а іноді й більше, якщо коміт великий або розбитий на кілька маніфестів.
У v4 логіка інша. Додавання нових файлів під час коміту має вимагати лише оновлення верхнього метаданого файлу. Тобто замість того, щоб спочатку писати окремі маніфести, а потім оновлювати посилання на них, система прагне звести все до одного атомарного кроку: запису нового варіанта верхнього рівня, який уже містить інформацію про нові файли.
Це не означає, що маніфести зникають як клас об’єктів. Але їхня роль змінюється: вони стають більш стабільними, рідше переписуються, а операції, пов’язані з інкрементальними оновленнями, концентруються у верхньому шарі. У результаті типовий стрімінговий коміт перетворюється на одну I/O‑операцію — перезапис невеликого файлу.
Для потокових систем це критично. Коли кожен мікробатч або навіть окремий запис вимагає лише одного швидкого оновлення метаданих, Iceberg перестає бути «важким» форматом, орієнтованим лише на великий аналітичний батч, і стає придатним для сценаріїв із низькою латентністю, де затримка вимірюється мілісекундами.
Delete‑vector для метаданих: як видаляти без переписування
Ще один важливий елемент редизайну — перенесення delete‑vector‑подібних технік із рівня даних на рівень метаданих. Iceberg уже давно вміє логічно видаляти рядки у файлах даних, не переписуючи самі файли: для цього використовуються delete files і delete vectors, які позначають, які рядки вважати неактуальними.
У v4 подібний підхід планують застосувати до маніфестів метаданих. Замість того, щоб переписувати маніфест-файл щоразу, коли певні записи в ньому стають неактуальними (наприклад, файл даних видалено або замінено), система зможе позначати відповідні рядки як «видалені», не змінюючи сам маніфест.
Це знову ж таки зменшує кількість операцій запису. Маніфести стають більш статичними, а інформація про актуальність окремих записів переноситься в інші структури, які легше оновлювати інкрементально. У поєднанні з невеликим верхнім файлом метаданих це створює багаторівневу систему, де:
- файли даних переважно незмінні;
- маніфести метаданих переважно незмінні, а зміни виражаються через «позначки видалення»;
- верхній рівень метаданих регулярно оновлюється, але залишається компактним.
Такий дизайн добре узгоджується з властивостями об’єктних сховищ: великі файли пишуться рідко й читаються багато разів, а невеликі файли можуть оновлюватися часто без відчутного впливу на загальну продуктивність.
Стрімінг без «другого джерела істини»: чому важлива єдина система
У дискусіях про мультимодальні дані та зовнішні посилання постійно виникає спокуса винести частину логіки в окрему strongly consistent базу — умовний «другий source of truth», який би відповідав за транзакційність і атомарність посилань на зовнішні об’єкти. Але кожен додатковий компонент у критичному шляху стрімінгу — це додаткова латентність.
У контексті Iceberg v4 цю ідею намагаються свідомо уникнути. Мета — зробити так, щоб усі гарантії цілісності, атомарності та узгодженості були реалізовані на рівні самого формату таблиць, без потреби в окремій транзакційній системі. Для цього вводяться обмеження, які спрощують модель:
файли розглядаються як незмінні протягом усього життєвого циклу;
зміни виражаються через додавання нових файлів і оновлення метаданих, а не через модифікацію існуючих об’єктів;
офсети та інші позиційні характеристики мають залишатися стабільними.
Така модель добре пасує до об’єктних сховищ, де перезапис файлу часто означає створення нового об’єкта. Вона також дозволяє уникнути складних протоколів двофазних комітів між різними системами. Якщо все, що потрібно для фіксації нового стану таблиці, — це запис одного невеликого файлу метаданих, то й стрімінгова латентність залишається під контролем.
Гілки таблиць як механізм безпечних змін
Поки Iceberg v4 ще в розробці, у спільноти вже є інструмент, який допомагає керувати складними змінами без ризику зламати продакшен-таблицю, — гілки (branches) таблиць.
Iceberg уже сьогодні підтримує модель, де таблиця може мати кілька паралельних гілок стану. Це дозволяє створити окрему гілку, виконати на ній серію змін, протестувати їх, перевірити консистентність зовнішніх посилань або мультимодальних структур, а потім, лише коли все валідовано, злити цю гілку в основну.
У контексті майбутніх можливостей v4 — зокрема роботи з зовнішніми референсами на неструктуровані файли — це особливо важливо. Коли таблиця містить посилання на об’єкти поза її власним файловим простором, помилки в управлінні життєвим циклом цих посилань можуть призвести до «битих» рядків, розсинхронізації або втрати даних.
Гілки дають спосіб відпрацювати ці сценарії в ізольованому середовищі: наприклад, побудувати нову структуру посилань, перевірити, що всі файли доступні й узгоджені, і лише потім зробити атомарне злиття гілки в основну. Це добре поєднується з ідеєю єдиного невеликого файлу-коміту: злиття гілки в такій моделі теж зводиться до оновлення верхнього рівня метаданих.
Від «Hive‑replacement» до стрімінгового ядра AI‑інфраструктури
Iceberg історично розвивався як формат для великих аналітичних систем — заміна Hive, Trino, класичних data warehouse‑підходів. У цих сценаріях головними були масштаб, гнучкість схеми, можливість працювати з петабайтами даних у файлових сховищах.
Сьогодні картина інша. AI‑системи, мультимодальні моделі, векторні сховища й стрімінгові конвеєри вимагають не лише масштабованості, а й низької латентності, частих оновлень, складних зв’язків між структурованими й неструктурованими даними. Формат таблиць, який претендує на роль «універсального шару даних» для таких систем, має вміти:
швидко фіксувати зміни без каскаду переписувань;
ефективно працювати з об’єктними сховищами;
забезпечувати транзакційність без зовнішніх «координаторів»;
дозволяти складні сценарії тестування й розгортання змін.
Редизайн метаданих у Iceberg v4 — спроба відповісти саме на ці виклики. Один невеликий файл верхнього рівня, delete‑vector‑подібні техніки для маніфестів, мінімізація кількості I/O‑операцій на коміт і вже наявна підтримка гілок таблиць разом формують архітектуру, яка набагато краще відповідає вимогам стрімінгу й AI‑навантажень, ніж початкова «Hive‑орієнтована» модель.
Висновок: метадані як головний фронт оптимізації
У світі, де обчислення стають дедалі дешевшими, а об’єктні сховища — дедалі універсальнішими, саме метадані часто визначають, чи зможе система працювати в режимі реального часу. Iceberg v4 демонструє, що оптимізація цього шару — не другорядне завдання, а ключ до того, щоб формат таблиць залишався актуальним у добу стрімінгу та AI.
Перенесення ідей незмінності, delete‑vector‑подібних технік і компактних структур із рівня даних на рівень метаданих дозволяє перетворити коміт із важкої багатокрокової операції на один швидкий запис невеликого файлу. У поєднанні з гілками таблиць це створює фундамент для більш гнучких, але водночас надійних конвеєрів даних — від класичної аналітики до складних AI‑систем.
Якщо Iceberg v3 був форматом, що навчив data lake поводитися як data warehouse, то Iceberg v4 прагне стати форматом, який дозволить data lake поводитися як стрімінгова платформа — без втрати тих самих ACID‑гарантій і відкритості, заради яких його й обирали.
Джерело
How AI Is Changing Apache Iceberg with Russell Spitzer | Ep. 30 | Confluent Developer Podcast