У Confluent давно звикли до масштабних експериментів із потоковими даними, але Warpstream — окрема історія. Це продуктова лінійка, якою нині керує Калеб Ґрілло, staff product manager в Confluent, і яка поєднує одразу кілька радикальних ідей: Kafka без дисків, модель BYOC (bring your own cloud), жорсткий акцент на вартості інфраструктури замість мікросекундної затримки та новий сервіс Tableflow на базі Apache Iceberg. Разом це виглядає як спроба переосмислити, якою має бути сучасна стрімінгова платформа в епоху дешевих об’єктних сховищ і дорогих керованих сервісів.
BYOC як вихід із глухого кута «керований сервіс vs контроль»
Warpstream у складі Confluent позиціонується як BYOC-продукт: клієнт «приносить» власну хмару або дата-центр, а Confluent постачає програмну логіку та контрольну площину. Це не просто ще один варіант розгортання, а відповідь на типову напругу між безпекою, контролем і зручністю.
Класичний керований Kafka-сервіс означає, що постачальник керує інфраструктурою у своєму акаунті, а клієнт довіряє йому не лише дані, а й IAM-права, мережеві налаштування, ключі доступу. Для великих організацій із жорсткими політиками безпеки це часто неприйнятно. Warpstream намагається зняти цю напругу за рахунок чітко розділених площин.
Уся дата-плейн-частина Warpstream — те, що безпосередньо приймає, зберігає й віддає повідомлення — працює всередині середовища клієнта: у його VPC або в його ж дата-центрі. Confluent не отримує крос-акаунтних IAM-привілеїв, не має технічної можливості «зайти» в обчислювальні ресурси клієнта й напряму торкнутися даних. Назовні виходить лише метадані, які потрапляють у контрольну площину Confluent.
Це розділення виглядає принциповим. З одного боку, клієнт зберігає повний контроль над своїми даними, мережею та політиками доступу. З іншого — отримує керований сервіс: оновлення, операційні практики, аналітику використання, інтеграцію з іншими продуктами Confluent. Для Warpstream це ще й спосіб відрізнитися від класичних «Kafka-as-a-service», які часто вимагають значно більшої довіри до провайдера.
Ключовим елементом цієї архітектури стає агентний процес, який розгортається у середовищі клієнта й фактично замінює роль Kafka-брокера. Саме агент — ядро дата-плейну Warpstream: він приймає трафік від продюсерів і конс’юмерів, працює з об’єктним сховищем, взаємодіє з контрольної площиною через метадані, але не передає самі повідомлення назовні.
Kafka без дисків: ставка на об’єктне сховище замість низької затримки
Найрадикальніша ідея Warpstream — відмова від традиційної моделі Kafka, де брокери тримають дані на локальних або мережевих дисках. Замість цього платформа реалізує «diskless Kafka»: усі повідомлення зберігаються в хмарному об’єктному сховищі.
Технічно це означає, що агент у VPC клієнта не виступає класичним брокером із локальними логами. Він радше координує запис і читання з об’єктного сховища, використовуючи його як основний носій. Локальні ресурси потрібні лише для обробки, кешування та координації, але не для довгострокового зберігання.
Цей підхід змінює базову економіку Kafka-кластерів. Традиційні розгортання орієнтовані на мінімальну затримку: локальні SSD, щільні кластери, високошвидкісні мережі, складні схеми реплікації. Усе це дорого, особливо в хмарі, де кожен гігабайт диска й кожен IOPS мають свою ціну. Об’єктне сховище, навпаки, оптимізоване під вартість і довгострокове зберігання, а не під мікросекундні затримки.
Warpstream свідомо робить ставку на інший компроміс: більша затримка в обмін на суттєво нижчі інфраструктурні витрати. Це не просто оптимізація, а спроба змінити саму розмову про Kafka: замість «як зробити ще швидше» — «скільки ми готові заплатити за ту чи іншу затримку».
У 2023 році Warpstream опублікував блог «Kafka is Dead, Long Live Kafka», де ця ідея була сформульована як стратегічна ставка: Kafka як протокол і екосистема залишаються, але архітектура під них може бути зовсім іншою. Дисклес-підхід дозволяє використовувати Kafka там, де раніше її вважали надто дорогою для великих обсягів історичних даних або довгої ретенції.
Вартість проти затримки: новий компроміс для стрімінгових систем
Традиційно Kafka асоціюється з низькою затримкою — мілісекунди від продюсера до конс’юмера. Warpstream фактично ставить під сумнів, чи справді всім потрібна така швидкість, якщо її ціна — кратно вищі рахунки за інфраструктуру.
Архітектура з об’єктним сховищем неминуче додає затримку: запис і читання з S3-подібних сервісів повільніші за локальний диск, а операції з невеликими блоками даних можуть бути особливо дорогими з точки зору латентності. Warpstream не намагається це приховати — навпаки, прямо говорить про «жертву затримкою» заради економії.
Зате інфраструктурні витрати змінюються кардинально. Об’єктне сховище в хмарі зазвичай на порядок дешевше за високопродуктивні диски, а модель оплати «за зберігання й запити» краще масштабується для великих обсягів історичних даних. Для багатьох сценаріїв — аналітика, аудит, подієві логи, довготривалі стріми для машинного навчання — додаткові десятки або навіть сотні мілісекунд не критичні, зате можливість зберігати роки даних за прийнятні гроші — вирішальна.
Warpstream фактично формалізує те, що багато команд робили неявно: будували складні пайплайни з Kafka, об’єктного сховища та окремих аналітичних систем, щоб зменшити навантаження на кластери. Тут же пропонується єдина платформа, де компроміс «затримка проти вартості» закладений в основу архітектури.
Це не означає, що модель підходить усім. Для біржових систем, платіжних шлюзів або критичних реального часу сценаріїв класична низьколатентна Kafka залишиться стандартом. Але для величезного класу задач, де важливіше масштаб і вартість, ніж мілісекунди, дискless Kafka відкриває новий простір рішень.
Агент замість брокера: як працює дата-плейн у VPC клієнта
Щоб поєднати BYOC-модель, дискless-архітектуру та вимоги безпеки, Warpstream використовує агентний підхід. Замість того, щоб розгортати повноцінні Kafka-брокери, клієнт запускає у своїй інфраструктурі кластери агентів.
Ці агенти виконують кілька ролей одночасно. Вони приймають підключення від продюсерів і конс’юмерів, реалізують протокольну поведінку Kafka, керують записом і читанням з об’єктного сховища, а також взаємодіють із контрольної площиною Confluent через метадані. При цьому жодні корисні дані не виходять за межі VPC або дата-центру клієнта.
Модель без крос-акаунтних IAM-привілеїв означає, що Confluent не може напряму керувати ресурсами клієнта. Уся координація відбувається через те, що агенти самі ініціюють зв’язок із контрольної площиною, передають туди лише службову інформацію — конфігурації, стани, метрики, — а натомість отримують інструкції щодо оновлень, масштабування, політик.
Для клієнта це виглядає як керований сервіс: є консоль, API, інтеграція з іншими продуктами Confluent, аналітика використання. Для служби безпеки — як внутрішня система, де дані ніколи не покидають контрольоване середовище, а зовнішній постачальник не має технічних важелів для прямого доступу.
Цей підхід також створює основу для подальших сервісів поверх Kafka-протоколу, зокрема для Tableflow, який використовує окремий тип агентного кластера для роботи з Apache Iceberg.
Ретенція без меж: новий сторедж-движок поверх об’єктного сховища
Перехід на об’єктне сховище як основний носій змусив Warpstream повністю перебудувати сторедж-движок. Класичні механізми Kafka — сегментовані логи на диску, політики видалення за часом або розміром, компактовані топіки — розраховані на файлові системи, а не на S3-подібні сервіси.
Warpstream використав цю необхідність як можливість. Новий сторедж-движок спроєктовано так, щоб підтримувати значно більші обсяги даних і довші періоди зберігання. Для деяких клієнтів це означає фактично «нескінченну» ретенцію на компактованих топіках: замість того, щоб видаляти старі записи, система зберігає останній стан ключів практично без обмежень у часі.
Об’єктне сховище природно підходить для таких сценаріїв: воно дешеве, масштабоване й не вимагає складного керування томами або RAID-масивами. Натомість виникають інші виклики — оптимізація кількості файлів, ефективна компакція, боротьба з «сміттям» у вигляді сирітських файлів, які більше не належать жодному логічному сегменту.
Новий сторедж-движок Warpstream враховує ці особливості. Він повинен не лише забезпечувати коректність і продуктивність Kafka-протоколу, а й працювати з об’єктним сховищем у режимі довготривалої експлуатації: мінімізувати витрати на запити, уникати вибуху кількості дрібних об’єктів, гарантувати, що видалені дані справді зникають, а не накопичуються у вигляді невидимого боргу.
Для клієнтів це відкриває можливість тримати в Kafka не лише «гарячі» дані останніх годин або днів, а й роки історії — без необхідності постійно вивантажувати все в окремі data lake-системи. Або, принаймні, значно відтермінувати момент, коли така міграція стає неминучою.
Tableflow і Apache Iceberg: «нижня половина» бази даних у BYOC
Наступний логічний крок Warpstream — зробити ці довготривалі стріми придатними для аналітики та батчевих сценаріїв без складних ETL-пайплайнів. Для цього з’являється Warpstream Tableflow — сервіс, який нині перебуває в режимі раннього доступу.
Tableflow матеріалізує Kafka-топіки як таблиці Apache Iceberg в об’єктному сховищі. По суті, це автоматизований міст між світом стрімінгу та світом табличних даних: повідомлення з топіків перетворюються на Parquet-файли, а поверх них будується Iceberg-метадані — маніфести, снапшоти, схеми.
Технічно Tableflow використовує окремий тип агентного кластера. Якщо «звичайні» агенти відповідають за протокол Kafka й логіку стрімінгу, то Tableflow-агенти спеціалізуються на табличному шарі: вони пишуть Parquet, оновлюють Iceberg-маніфести, виконують фонові операції з обслуговування таблиць.
Ці фонові задачі — критичний, але часто недооцінений аспект data lake-архітектур. Tableflow автоматизує компакцію файлів, щоб уникнути тисяч дрібних Parquet-об’єктів, які вбивають продуктивність; прибирає сирітські файли, що більше не належать жодному актуальному снапшоту; обробляє видалення, щоб логічно видалені рядки не залишалися фізично вічно.
Калеб Ґрілло описує Apache Iceberg не як «готове озеро даних», а як табличний формат і будівельний блок. Сам по собі Iceberg визначає, як організовані файли, як виглядають снапшоти, як еволюціонує схема. Але він не вирішує питання, хто й як буде створювати ці файли, коли їх компактувати, як чистити «сміття» й гарантувати, що таблиці залишаються в здоровому стані.
Warpstream Tableflow позиціонується як «нижня половина» бекенду бази даних, побудованого на Iceberg. Він не намагається стати повноцінним SQL-двигуном або BI-платформою, але бере на себе все, що стосується фізичного шару: перетворення стрімів у таблиці, керування файлами, підтримку метаданих. Поверх цього клієнт може використовувати будь-який сумісний двигун — від Spark до Trino чи Flink.
Важливо, що Tableflow у BYOC-варіанті Warpstream задуманий як керований сервіс із тим самим ядром функціональності, що й Confluent Cloud Tableflow. Різниця — знову ж таки в моделі розгортання: дата-плейн у VPC клієнта, контрольна площина в Confluent, без крос-акаунтних IAM-привілеїв, із виходом назовні лише метаданих.
Аналітика використання як частина продуктового циклу
Уся ця архітектура — від агентів до Tableflow — живе не у вакуумі. Warpstream, як і інші продукти Confluent, активно аналізує власне використання. Увесь consumption- і usage-трафік потрапляє в корпоративне сховище даних Confluent, де над ним проводять трендовий аналіз: доходи, витрати, маржа, ефективність різних конфігурацій.
Для продуктового менеджера на кшталт Калеба це не просто звітність, а інструмент перевірки гіпотез. Модель «жертвуємо затримкою заради вартості» має сенс лише тоді, коли це підтверджується реальними патернами використання: які обсяги даних клієнти зберігають, як довго, які профілі навантаження мають, де саме економія інфраструктури перекриває потенційні втрати від вищої латентності.
Така аналітика також критична для BYOC-моделі. Оскільки дата-плейн працює в середовищі клієнта, а Confluent не має прямого доступу до ресурсів, правильне ціноутворення й розуміння собівартості вимагають точного збору й інтерпретації метрик. Це продовження тієї ж логіки, яку Калеб колись застосовував до побудови системи білінгу Confluent Cloud, але тепер — у контексті нової архітектури.
Висновок: Kafka як протокол, а не як догма
Warpstream демонструє, що Kafka — це не лише конкретна реалізація брокерів і дисків, а насамперед протокол і модель роботи з подіями. Дисклес-архітектура, BYOC-дата-плейн, ставка на об’єктне сховище, розширена ретенція й Tableflow на Iceberg — усе це разом пропонує альтернативний шлях еволюції стрімінгових систем.
Цей шлях не універсальний. Він навмисно відходить від фетишизації мінімальної затримки й натомість оптимізує вартість, масштаб і інтеграцію з аналітичними сценаріями. Для організацій, яким потрібен повний контроль над середовищем, але водночас хочеться мати керований сервіс, модель BYOC із агентами в VPC виглядає особливо привабливою.
Блог «Kafka is Dead, Long Live Kafka» у 2023 році зафіксував цю зміну оптики: Kafka не «вмирає», а перероджується в нових формах. Warpstream — один із найпослідовніших експериментів у цьому напрямку, який показує, що жертва затримкою може бути не поразкою, а свідомою інженерною стратегією, коли на кону — масштаб, вартість і довгострокова цінність даних.
Джерело
Being Wrong in the Right Direction with Caleb Grillo | Ep. 29 | Confluent Developer Podcast