У новому випуску подкасту Confluent Developer головною темою стала еволюція Apache Iceberg — відкритого табличного формату, який за кілька років пройшов шлях від «заміни Hive» до фундаменту для сучасних AI‑та стрімінг‑систем. Гість розмови, Рассел Спітцер, principal software engineer у Snowflake та активний контриб’ютор в Iceberg, розповів, як спільнота переосмислює сам формат у версії v4, щоб він природно працював з мультимодальними даними, векторними фічами та високочастотними оновленнями.
Iceberg v4 задуманий не як косметичне оновлення, а як відповідь на дві нові домінуючі реальності: AI‑навантаження з масивними векторними колонками та multimodal‑контентом, а також стрімінг, де затримка коміту вимірюється мілісекундами, а не хвилинами. У центрі цієї трансформації — вертикально розділені таблиці, можливість оновлювати окремі колонки без переписування файлів і спільна робота з Apache Parquet над тим, як зберігати неструктуровані дані.
Від «Hive‑replacement» до AI‑платформи
Історично Apache Iceberg створювався як відповідь на обмеження Hive‑таблиць у світі data lake: потрібні були надійніші транзакції, еволюція схем, розумна робота з партиціями та маніфестами. Типовий сценарій — аналітичні запити по великих історичних наборах даних, де оновлення відбуваються пакетами, а затримка в хвилини не є критичною.
Сьогоднішні AI‑сценарії виглядають інакше. Моделі регулярно донавчаються, фічі змінюються, векторні подання документів, зображень чи подій можуть оновлюватися щодня або навіть частіше. До цього додаються мультимодальні пайплайни, де в одному контексті поєднуються текст, зображення, аудіо, відео та їхні векторні представлення. Усе це має жити в єдиній табличній моделі, бути доступним для SQL‑аналітики, а також для спеціалізованих AI‑движків.
Iceberg v4 позиціонується як відповідь саме на ці вимоги. Формат більше не мислиться лише як «data warehouse replacement». Його завдання — стати універсальним табличним шаром для систем, де:
- векторні колонки можуть бути гігантськими й часто оновлюваними;
- мультимодальні дані мають зберігатися або поруч із табличними даними, або бути надійно пов’язаними з ними;
- стрімінг‑навантаження вимагають мінімального часу коміту та стабільної транзакційної моделі.
Щоб це стало можливим, спільнота Iceberg переосмислює базові припущення про те, як виглядає таблиця та що означає «оновити дані».
Вертикально розділені таблиці: коли дані ростуть «убік»
Класична модель роботи з табличними форматами — горизонтальна. Додаємо нові рядки — фізично дописуємо їх «вниз» у файли. Видаляємо рядки — використовуємо delete‑файли або delete‑вектори, які логічно «вирізають» записи, не переписуючи весь файл. Усе це — горизонтальні операції над таблицею.
AI‑навантаження вносять іншу динаміку. Типовий сценарій: є базова таблиця подій, користувачів або документів, а поруч — одна чи кілька векторних колонок, які постійно змінюються. Наприклад, щодня додається новий embedding для кожного документа, згенерований оновленою моделлю. Ці вектори можуть бути:
- дуже довгими (сотні або тисячі чисел на один рядок);
- щільними або розрідженими;
- об’ємними в сумі, навіть якщо базова таблична частина змінюється мало.
У такій ситуації переписувати весь файл щоразу, коли змінюється одна векторна колонка, — надто дорого. Саме тут з’являється ключова інновація Iceberg v4: підтримка вертикально розділених таблиць.
Ідея полягає в тому, що таблиця може бути фізично розбита «по колонках». Частина колонок зберігається в одному наборі файлів, інша — в іншому. Формат дозволяє:
- зберігати різні колонки в окремих файлах;
- оновлювати або замінювати одну колонку незалежно від інших;
- логічно сприймати все це як одну таблицю з єдиною схемою.
Це означає, що векторну колонку можна винести в окремий фізичний шар і оновлювати її без торкання решти даних. Замість того, щоб переписувати файл із десятком колонок через зміну однієї, Iceberg v4 прагне дозволити замінити лише відповідний «вертикальний» фрагмент.
Для AI‑систем це змінює економіку оновлень. Додавання нової фічі або нового embedding‑виміру перетворюється з масового переписування файлів на керовану операцію над окремими колонками. Таблиця, умовно кажучи, «росте убік»: до неї додаються нові стовпці, які можуть бути фізично відокремлені від основних транзакційних даних.
Оновлення колонок без переписування файлів
Вертикальна декомпозиція таблиці в Iceberg v4 має ще одну важливу ціль: зробити можливим заміну окремої колонки в межах файлу без повного переписування цього файлу. У попередніх версіях формату будь-яка зміна на рівні колонки фактично означала створення нового файлу з усіма колонками, навіть якщо змінювалася лише одна.
Для AI‑пайплайнів, де векторні фічі можуть оновлюватися часто, це створювало серйозні витрати:
- зайве I/O при переписуванні великих файлів;
- зростання кількості файлів і фрагментація;
- додаткове навантаження на системи зберігання, особливо в об’єктних стораджах на кшталт S3.
У v4 формат прагне змінити цю модель. Ціль — дозволити операції на кшталт «замінити колонку X для цього набору рядків» без необхідності торкатися інших колонок у файлі. Технічно це означає:
- іншу організацію посилань між логічною таблицею та фізичними файлами;
- можливість «переадресувати» колонку на новий файл або сегмент, залишаючи інші колонки незмінними;
- застосування ідей, подібних до delete‑векторів, але вже на рівні колонок.
У результаті оновлення векторних фіч стає ближчим до операції «додати або замінити колонку» в логічній моделі, а не до «переписати всю партицію». Для інженерів це означає:
- менші вікна оновлення;
- можливість частіше оновлювати фічі без страху «забити» сховище;
- кращу відповідність між логікою AI‑пайплайна та фізичною організацією даних.
Це особливо важливо в умовах, коли LLM‑и та агентні системи стають частиною повсякденної розробки, а векторні бази та фіч‑стори інтегруються з lakehouse‑архітектурою. Iceberg v4 намагається зробити так, щоб табличний формат не був вузьким місцем у цій інтеграції.
Мультимодальні та неструктуровані дані: спільна робота Iceberg і Parquet
Ще один фронт змін у Iceberg v4 пов’язаний із мультимодальними даними. AI‑системи дедалі частіше працюють не лише з текстом, а й із зображеннями, аудіо, відео, 3D‑об’єктами та іншими типами контенту. Питання в тому, як усе це зберігати в табличному форматі, який історично орієнтований на структуровані колонки.
Спільнота Iceberg не розглядає це ізольовано. Ведеться активна співпраця з Apache Parquet — базовим колонковим форматом, на якому будуються більшість таблиць Iceberg. Обговорюється, де саме має жити логіка роботи з мультимодальними даними: у файловому форматі чи на рівні табличного формату.
Фактично розглядаються два основні підходи.
Вбудовування неструктурованих даних у файли таблиці
Перший варіант — зберігати мультимодальні або неструктуровані дані безпосередньо в тих самих файлах, що й інші колонки таблиці. Тобто зображення, аудіо або інші «важкі» об’єкти стають повноцінними значеннями колонок у Parquet‑файлах.
Цей підхід уже реалізують деякі формати, наприклад Lance. Для Iceberg і Parquet це означає:
- розширення можливостей Parquet для ефективного зберігання великих об’єктів;
- використання вертикальної декомпозиції таблиць, щоб виносити такі колонки в окремі файли;
- можливість працювати з мультимодальними даними в єдиному табличному просторі, не виходячи за межі формату.
Перевага такого підходу — цілісність. Усі дані, включно з неструктурованими, живуть у єдиній транзакційній моделі Iceberg. Оновлення, версіонування, гілки (branches) — усе це автоматично поширюється і на мультимодальні колонки.
Однак є й виклики. Багато типів неструктурованих даних уже мають добре оптимізовані формати: PNG, JPEG, MP4 тощо. Вони чудово стискаються, мають власні метадані й широко підтримуються інструментами. Вбудовувати їх усередину Parquet означає дублювати частину цих можливостей або втрачати деякі переваги нативних форматів.
Зовнішні посилання на неструктуровані файли
Другий підхід — не зберігати самі мультимодальні об’єкти в таблиці, а лише посилатися на них. У цьому варіанті рядок таблиці містить референс до зовнішнього файлу: наприклад, шлях в об’єктному сховищі, ідентифікатор у спеціалізованому сховищі зображень або інший стабільний ключ.
Логіка така: якщо PNG уже добре працює як PNG, а тисяча PNG‑файлів чудово пакується в архів, навіщо ламати цю модель? Таблиця Iceberg може стати шаром метаданих і зв’язків, а «важкий» контент залишиться там, де йому найкраще.
Цей підхід піднімає класичні питання:
- хто відповідає за життєвий цикл файлів і посилань;
- як забезпечити атомарність оновлень між таблицею та зовнішнім сховищем;
- як уникнути розсинхронізації, коли файл змінюється або видаляється, а посилання в таблиці лишається.
Саме тому в спільноті Iceberg це розглядається як задача табличного формату, а не окремих застосунків. Якщо визначити поведінку таких посилань на рівні формату — описати, що таке «reference type», як він виглядає, які гарантії дає, — тоді рушії запитів та інші системи зможуть узгоджено працювати з ними.
Обговорюється навіть можливість винести базове визначення структури таких посилань у Parquet, щоб воно було глобальним і не прив’язаним до конкретного табличного формату. А вже Iceberg накладав би свої правила транзакційності, версіонування та управління життєвим циклом.
У підсумку обидва підходи — вбудовування та зовнішні посилання — розвиваються паралельно. Ймовірно, різні типи мультимодальних даних вимагатимуть різних стратегій: щось зручніше зберігати всередині табличних файлів, щось — залишати у власних форматах і лише пов’язувати через посилання.
Чому це саме задача табличного формату
Ідея зберігати в таблицях посилання на зовнішні файли не нова. Так робили роками в різних системах: у реляційних базах, у data lake, у внутрішніх пайплайнах компаній. Проблема в тому, що кожен робив це по‑своєму.
Коли немає єдиного формального визначення, як мають поводитися такі посилання, виникають типові труднощі:
- різні системи по‑різному трактують атомарність оновлень;
- немає стандартних гарантій консистентності між таблицею та зовнішнім сховищем;
- інструменти не можуть безпечно «розуміти» ці посилання, бо їхня семантика не описана в самому форматі.
Спільнота Iceberg намагається винести цю логіку на рівень табличного формату. Якщо визначити, що таке «reference type», як він версіонується, які операції над ним дозволені, тоді:
- рушії запитів, які підтримують Iceberg, зможуть узгоджено працювати з такими колонками;
- інструменти керування даними знатимуть, як безпечно переміщувати, архівувати або видаляти пов’язані об’єкти;
- з’явиться можливість будувати крос‑системні гарантії, не покладаючись на неформальні домовленості.
Iceberg уже має деякі будівельні блоки для складних сценаріїв — наприклад, гілки (branches), які дозволяють будувати окремі стани таблиці, тестувати зміни й лише потім зливати їх у основну гілку. Ці механізми можуть стати основою й для роботи з посиланнями на зовнішні мультимодальні дані, хоча конкретні пропозиції ще формуються.
Важливо, що підхід залишається обережним: спочатку — визначити структуру й семантику, потім — дозволити екосистемі інструментів використати ці можливості.
Стрімінг і AI: чому формат має бути «щільним», а не «hairball»
Хоча деталі внутрішньої перебудови метаданих Iceberg v4 виходять за межі цієї статті, загальний вектор очевидний: формат намагається залишатися «щільним» і керованим, навіть коли навколо нього зростає складність AI‑та стрімінг‑сценаріїв.
У світі, де LLM‑и можуть писати код на будь‑якій мові, легко перетворити інфраструктурний проєкт на «hairball» — заплутану систему з надлишковими абстракціями, дублюванням і важко контрольованою поведінкою. Для Iceberg це неприйнятно: формат лежить у центрі критичних data‑пайплайнів, і будь-яка зайва складність тут множиться на масштаби кластерів і обсяги даних.
Тому навіть такі, на перший погляд, «високорівневі» функції, як підтримка мультимодальних даних або вертикально розділених таблиць, проєктуються з оглядом на:
- чітку транзакційну модель;
- мінімізацію I/O при оновленнях;
- можливість кешування й повторного використання метаданих;
- передбачувану поведінку в умовах стрімінгу.
Iceberg v4 намагається перенести ідеї, які вже добре зарекомендували себе на рівні даних (delete‑вектори, розділення файлів, імунтабельність), на нові області — колонки, мультимодальні посилання, метадані. Це дозволяє розширювати можливості формату, не жертвуючи його керованістю.
Висновок: формат, який наздоганяє AI‑реальність
Apache Iceberg v4 формується як відповідь на дуже конкретні виклики: AI‑системи, що працюють із векторами та мультимодальними даними, і стрімінг‑навантаження, де кожен зайвий запис у сховище має значення. Ключові кроки в цьому напрямку вже окреслені:
- підтримка вертикально розділених таблиць, де колонки можуть жити в окремих файлах і оновлюватися незалежно;
- прагнення дозволити заміну окремої колонки без переписування всього файлу;
- спільна робота зі спільнотою Apache Parquet над тим, як зберігати мультимодальні та неструктуровані дані;
- паралельна розробка двох стратегій для мультимодальних даних — вбудовування об’єктів у файли таблиці та використання зовнішніх посилань у рядках.
Усе це відбувається в межах відкритої спільноти, де остаточне визначення v4 ще потребує узгодження й голосування. Але напрямок уже зрозумілий: Iceberg перестає бути лише форматом для аналітичних lakehouse‑навантажень і перетворюється на табличний шар, спеціально спроєктований для епохи LLM‑ів, векторних баз і мультимодальних AI‑систем.
Якщо AI сьогодні змінює те, як ми пишемо код, то Iceberg v4 — спроба змінити те, як ми зберігаємо дані, щоб цей новий світ був не лише можливим, а й керованим.
Джерело
How AI Is Changing Apache Iceberg with Russell Spitzer | Ep. 30 | Confluent Developer Podcast