Пока не совсем понимаю, зачем мне это, но, пожалуй, запишу в итоги года.

Так что зовите на конференции и в гости - прилечу.

Бизнес-классом 😁

Продолжаем итоги года.

Тут меня жарит нейросеть, причем по делу.

🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥

Решил залить одно из фундаментальных видео по Айсбергу за последнее время.

Докладывает Райан Блу (Ryan Blue), один из создателей формата Айсберг и судя по линкед-ину сотрудник Data Bricks. Видео открывает Iceberg Summit 2025 в апреде этого года и содержит описание нескольких фундаментальных изменений, которые ждут нас в формате Iceberg v3.

Самые фундаментальные изменения в Iceberg v3:

1️⃣ Оптимизация удалений, Delete Vectors. Сейчас в нагруженных таблицах, в которых много DELETE, UPDATE, MERGE накапливаются цепочки из множества delete файлов и манифестов. Натруально сотни и тысячи мелкий паркетов на 1 ГБ data файл. Оптимизация этого процесса - DV, который кстати уже применяется в Apache Paimon

2️⃣ VARIANT тип данных. Считаем что это такая Java-Parquet-Iceberg вариация JSON. То есть нам больше не придется писать JSON в строки и отдельно думать как это потом десериализовывать. Также, если формат вписан в айсберг, то сам формат сможет собирать по нему статистику: наличие/отсутствие полей, характерные значения, диапазоны суб-значений, сортировать по полям и т.д. То же самое, но для меня менее интересно - ГеоФормат.

3️⃣Row_id. Привет, ораклистам. Как насчет точно знать что вот это вот она, моя строка и в каком последнем снапшоте она последний раз менялась. Сколько сразу мыслей, как это облегчит многие процессы.

Отдельная благодарность за то, что недостатки айсберга активно признаются - это я про не всегда эффективную метадату. И придумываются способы ее улучшить в будущем - это уже Iceberg v4

Видео на английском, я отрезал из него приветствия и завершение и добавил русскоязычные тайм-коды. Посмотреть можно либо ниже в канале, либо перезалив на ВК, либо оригинал на YT.

Ставьте 🔥, если хотите больше таких разборов или даже видео-разбора докладов от меня на русском языке.

-----------------------------------
------ Архитектор данных -------
-----------------------------------

Смотрим Iceberg Summit 2025 - Часть 2

Сегодня видео с громким названием Fully managed Streaming Data Lake in the Iceberg, но именно здесь я сэкономил вам время, потому что 2/3 доклада это маркетинговый питч продукта RedPanda.

RedPanda - интересный продукт из мира стриминга, и здесь они много говорят о добавленной интеграции с айсбергом и как они хорошо решают задачи построения Стрим-Хауса там где стандартные методы Kafka-Connect-Sync справятся хуже. Техническая часть короткая по времени, но все равно любопытная. Ее можно смотреть с 19:28

Можно использовать как быстрый чек-лист - а как мы будем решать вот эти проблемы, когда с ними неизбежно столкнемся при построении StreamHouse


Что сделали инженеры Redpanda, их заявка на успех

🔬 Exactly Once доставка данных из топика RedPanda в таблицу Iceberg

🔬 Где Kafka + Kafka Connect это два отдельных сервиса, которые могут рассинхронизироваться с неприятными последствиями, в экосистеме RedPanda это одна система. Она и работает в режиме брокера, и синхронно заливает данные в хранилище Айсберг

🔬 Кросс-партиционирование. В одной точке задаем, как в итоге должна выглядеть партиционированная таблица для Айсберга, и RedPanda сама адаптируется под эти требования к разбиению данных

🔬 Есть трейд-офф между а) лагом между таблицей и топиком и б) размером итоговых паркетов и манифестов у айсберга. Мы можем писать часто и за счет этого минимизировать лаг, но тогда итоговые манифесты и паркеты будут маленькие. RedPanda утверждает, что в их системе этот трейд-офф можно задавать на уровне каждого стрима данных

🔬 Реализация Dead Letter. На тот случай, если по какой-то причине данные невозможно записать в Айсберг, есть отдельное чистилище для таких сообщений и данных. Почему нельзя записать? Потому что устаревшая схема, ошибки сериализации и т.д. Айсберг строго типизированный и если договорились, что число, то там должно быстро строго число, а если приехала строка, то фейл. Вот эти фейловые строки хорошо куда-то складывать для прозрачности и возможности дальнейшего процессинга, а не просто получать молча пропуски в данных.

🔬 Очень кратко заявили про сквозной менеджмент схем. Он совместим с Kafka Registry - на этом все

🔬 Очень кратко про совместимость в Iceberg Catalog. Совместим с REST. Дифирамбы совместимости с Snowflake, шпилька в сторону BigQuery. Сразу видно, с кем дружат и с кем нет


Ода продукту RedPanda

🐼 Drop-In Replacement для Kafka. Совместима с Kafka API
🐼 Быстрее, так как C++ и Raft Consensus
🐼 Более богатый набор фичей для построения пайплайнов, LowCode Yaml преобразования и джойны данных
🐼 Переписанный на C++ движок с логикой 1 поток на 1 ядро
🐼 Raft Consensus
🐼 Собственные либы для работы с форматами ProtoBuf, AVRO, Parquet и схемами всех этих форматов

Видео с тайм-кодами постом ниже или на ВК Видео. Оригинал на Ютубе.

Часть 1 - Разбор нововведений Iceberg v3

------------------------------------
------ Архитектор данных -------
------------------------------------