Архитектор Данных

00:45 - Собираем конференцию по формату данных - серьезно?
01:25 - Зачем нужен формат Iceberg
10:57 - Новый тип данных: Гео (Geospatial)
13:44 - Variant тип данных. Json on Iceberg
16:24 - Шифрование на уровне таблицы
17:30 - Оптимизация удалений - Delete Vectors
21:02 - Сквозной Row_id и история изменений строк
28:08 - Недостатки метадаты Iceberg
36:21 - v4 metadata

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

Докладывает Райан Блу (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.

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

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

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

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

🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥

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

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

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

Закончил читать курс по DLH, Iceberg, Modern Data Stack. Полагаю, что несколько человек (и я точно в их числе) продвинулись в понимании этого стека.

Курс показал себя востребованным. В нашей небольшой группе наступил SOLD-OUT за неделю до старта самих занятий. Хочу сказать огромное спасибо слушателям! За то, что помогли этому курсу случиться. За терпение к неизбежным косяками первого запуска. За то, что занесли в процессе много полезных сервисов и статей. За то что огромное количество раз заставили задуматься: «Хмм, а почему это вот так?», или «Блин, а действительно, почему бы не попробовать сделать вот эдак!»

Что хочется сказать о самой технологии Lakehouse+Iceberg - несколько пунктов, в которые я верю и вижу подтверждения своей веры.

📈 Она точно рано или поздно будет во всех местах, где есть 100+ ТБайт полезных реально используемых данных.

🔬 С нее точно удобнее сразу начинать, если вы амбициозная команда, и ищете способ продолжить технологическую экспансию в точке, где 1 ТБайт данных на Postgres начинают уже скрипеть.

📈Мы точно увидим активное развитие экосистемы в ближайшие годы. А сервисы, которые делают стек более удобным, безопасным, быстрым точно будут востребованы рынком.

Ссылка на запись та же. Второй поток стартует в феврале. До встречи в новом году!

Структура хранения Apache Paimon

Как похоже на Айсберг, не правда ли?

А по механике скорее MergeTree (LSN-дерево). Последовательный компакшен от маленьких кусочков в большие, да еще можно в процесс компакшена засунуть дедупликацию или агрегацию. Бывалые пользователи кликхауса точно найдут здесь много знакомых моментов.

В целом - формат более Write Optimised, в то время как Iceberg - Read Optimised. зато более подходит для частой вставки.

Я бы сказал, что более сложный для понимания формат чем Iceberg. С большим числом скрытых внутненних особенностей.

Вроде как можно подключить в Trino как таблицу. Проверим?

Пятничное кадровое

ЛинкедИн-мышка!

Самые быстро развивающиеся продукты мира Data и Streaming

Ух ты какую штуку пропустил!

«И ты, САП!»
(С) Гай Юлий Лейкхаус

Как посчитать нужное число аналитиков?

Берем среднюю цену аналитика. Допустим 10 млн. руб, считая все з/п, налоги, технику, место в офисе, съеденные печеньки и т.д.

Допустим аналитик растит эффективность своего БЮ +10% против его отсутствия.

Тогда эффективно держать 1 аналитика на каждый 100 млн. ЕБИДТы. Лучше на 150 потому что аналитики складываются в группы, группам нужны тимлиды, PM, и вообще с ростом хед-каунта предельная эффективность падает.

Получаем простое правило.

Каждому БЮ положен 1 фулл-тайм дата аналитик при достижении 100-150 млн. ЕБИДТы. Если ИТ компания, то можно брать выручку так как % маржинальность по ЕБИДТе высокая.

До того мелкие БЮ могут запрашивать аналитику как сервис из негоего общего котла дата-офиса - эта возможность также должна быть.

Если у Авито есть 60-90 млрд ЕБИДТы, то никаких вопросов большая цифра хедкаунта аналитиков не вызывает.

Ваш архитектор, отягощенный дипломом по экономике 😄

Прочитал, что в Авито работает 600 аналитиков. Какая жесть. Зачем столько?

Маленькие армии сеньоров-помидоров?

https://habr-com.cdn.ampproject.org/c/s/habr.com/ru/amp/publications/978496/

В век автоматизации AI звучит как оверхед

PS: В корпорациях есть одна тема, чем больше у тебя людей в подчинении, тем больше вес. Появляются маленькие императоры.
UK здесь не исключение

Картинка для сильных

Вот как датасет айсберга продвигается через 5 состояний сквозь вставки и удаления.

Картинка упрощенная, так как нет DELETE паркетов и манифестов к ним.

Потом во все это залетает конкурентная MVCC запись с помощью Catalog.

Рассказать все в деталях занимает примерно 1,5 часа с ответами на вопросы. Академическая пара.

Tips & Tricks - Apache Iceberg

Хозяйке на заметку или как я только сейчас понял, что произошло на вебинаре.

Сетап

Есть связка S3 + Iceberg JDBC Catalog + Trino. Облачная связка на платформенных сервисах. Рядом с этим есть Jupyter Notebook, который общаемся с данными в S3 через PyIceberg. JDBC каталог шерится между Trino и PyIceberg.


Кэтч

Я работаю с Трино и создаю несколько таблиц. Потом хочу подключиться к этим же таблицам в PyIceberg, что-то поменять (докинуть колонку) и сразу же увидеть изменения в Трино. Красивая история про мульти-агентный Zero-Copy ETL.

Подключаюсь питоном к каталогу и не вижу в нем таблиц. Хм, каталог-то (JDBC host, login, pass, dbname) точно правильный и ошибок никаких при подключении нет. Что за ерунда? Иду в S3, там объекты точно есть.

Окей, думаю, давай-ка попробуем создать новую таблицу и просто залить туда данные. Создаю питоном схему (Iceberg namespace), создаю табличку, лью туда рандомный датасет. Все замечательно работает. Иду смотреть в S3 - чудо, рядом с Трино схемами по тому же пути в бакете появились новые объекты, созданные из питона!

Иду смотреть в Трино - питонячьих объектов нет. Да что за ерунда тут происходит?


Разгадка

Что происходит, я понял, глядя на таблицы в JDBC Postgres - см. картинку в первом комменте.

В одной инсталляции JDBC каталога - в одной постгресовой БД, схеме, в одной и той же таблице лежат объекты с разными catalog_name! То есть у JDBC каталога фактически имеется слой логического разделения объектов.

Делая в питоне

load_catalog(name='ice')

можно увидеть только часть объектов которые есть на S3.

А сделав

load_catalog(name='i_misprint_my_catalog_name')

вы приземлитесь в новый пустой каталог, и код вам ошибку не кинет! Я бы предпочел чтобы в этом месте мне кинули exception catalog not found, но сделано вот так.

Будьте внимательней и учитывайте при планировании работ

И подписывайтесь на канал в ВК, там в начале следующего года точно будут новые технические вебинары!

Призыв к сообществу

Поделитесь найденными за последний год ОпенСорс инструментами, которые оказались полезны в работе по Data Engineering

Особо интересны
- BI, визуализация, доставка данных
- ETL
- No code / Low Code Pipeline
- Data Quality

Отдельная благодарность - кто поделится в коментах, как именно вы используете эти инструменты и как они изменили ваши подходы.

👋На днях наткнулся на интересный проект — OpenIDE . Позиционируется как «наша новая открытая среда разработки».

Что это по факту? Взяли IntelliJ IDEA Community Edition, вытряхнули из неё всю телеметрию и проприетарные компоненты JetBrains, а затем прикрутили обратно то, без чего современный Java-разработчик чувствует себя голым: поддержку Spring и Docker.
То есть, по сути, нам вернули часть функционала платной Ultimate-версии, доступ к которой для нас сейчас, мягко говоря, затруднён.

Но давайте без иллюзий. Это не революция. Это реакция.

Нам не предложили принципиально новый инструмент, который изменит правила игры. Нам дали рабочий, «лицензионно чистый» молоток, чтобы мы могли продолжать забивать гвозди в текущих реалиях. Чтобы завтра к директору вашей госконторы не пришли люди в погонах с вопросом: «А на каком основании ваши программисты используют софт из недружественной юрисдикции?».

Все эти пляски про «серверы в России» — это не про удобство разработчика. Это про снижение рисков для бизнеса. Теперь ваша IDE ходит за плагинами не в Прагу, а, условно, в Мытищи. Это важно для юристов, но это не повод для инженерной эйфории.💯

Если вы работаете в энтерпрайзе, банке или госсекторе — для вас этот инструмент скоро станет стандартом де-факто. Он снимает головную боль с безопасников. Но вам нужно оценить его с позиции инженера: стабильно ли работает? Не тормозит? Все ли нужные плагины есть в их локальном маркетплейсе?

👉Делитесь мнением: кто уже пробовал? Как ощущения? И есть ли тут те, у кого в компании переход на отечественную IDE уже стал обязательным требованием?👈

#интересное

🤡Токсичный (it) архитектор🤡

Все видели это в "профессиональных" промтах:
- стань супер-экспертом в (чем-то)
- не ври мне, я майор НКВД

Наконец провели эксперимент

Что сделали:

Исследователи отправляли ИИ разные запросы. В одних промптах писали: "Представь, что ты топовый эксперт в такой-то сфере". В других: ты новичок. А потом сравнивали эти ответы с обычными, где вообще не задавали никакую роль.

Ну и фразы в духе "ты мировой эксперт" никак не улучшают точность ответов. Зато если попросить модель вести себя как ребёнок, или дурачок, качество ответов действительно падает, и ИИ начинает отвечать хуже.

Какие выводы:

- Назвать модель экспертом не значит сделать её умнее.
- Пару магических фраз в промпте не превращают ИИ в гения.
- Зато можно легко специально оглупить модель, если просить её играть глупую роль.

Как быть теперь тем, кто напродавал курсов, где учит простых смертных писать профессиональные промпты - не знаю.

Пейпер тут