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 каталога фактически имеется слой логического разделения объектов.
Делая в питоне
можно увидеть только часть объектов которые есть на S3.
А сделав
вы приземлитесь в новый пустой каталог, и код вам ошибку не кинет! Я бы предпочел чтобы в этом месте мне кинули exception catalog not found, но сделано вот так.
Будьте внимательней и учитывайте при планировании работ
И подписывайтесь на канал в ВК, там в начале следующего года точно будут новые технические вебинары!
Хозяйке на заметку или как я только сейчас понял, что произошло на вебинаре.
Сетап
Есть связка 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, но сделано вот так.
Будьте внимательней и учитывайте при планировании работ
И подписывайтесь на канал в ВК, там в начале следующего года точно будут новые технические вебинары!
VK Видео
Больше, чем просто данные в S3: Iceberg как основа архитектуры Next-Gen КХД
Регистрируйтесь на вебинар, на котором мы разберем, как Apache Iceberg превращает Data Lake в полноценный Data Lakehouse — с ACID-транзакциями, эволюцией схем, time-travel, snapshot isolation (через Spark/Trino). Вас ждет теоретическая часть, воркшоп и ответы…
2👌7⚡3😨3❤2👍2
Картинка для сильных
Вот как датасет айсберга продвигается через 5 состояний сквозь вставки и удаления.
Картинка упрощенная, так как нет DELETE паркетов и манифестов к ним.
Потом во все это залетает конкурентная MVCC запись с помощью Catalog.
Рассказать все в деталях занимает примерно 1,5 часа с ответами на вопросы. Академическая пара.
Вот как датасет айсберга продвигается через 5 состояний сквозь вставки и удаления.
Картинка упрощенная, так как нет DELETE паркетов и манифестов к ним.
Потом во все это залетает конкурентная MVCC запись с помощью Catalog.
Рассказать все в деталях занимает примерно 1,5 часа с ответами на вопросы. Академическая пара.
1🔥11❤5🫡4👀2
Forwarded from topdatalab (Roman Zykov)
Прочитал, что в Авито работает 600 аналитиков. Какая жесть. Зачем столько?
Маленькие армии сеньоров-помидоров?
https://habr-com.cdn.ampproject.org/c/s/habr.com/ru/amp/publications/978496/
В век автоматизации AI звучит как оверхед
PS: В корпорациях есть одна тема, чем больше у тебя людей в подчинении, тем больше вес. Появляются маленькие императоры.
UK здесь не исключение
Маленькие армии сеньоров-помидоров?
https://habr-com.cdn.ampproject.org/c/s/habr.com/ru/amp/publications/978496/
В век автоматизации AI звучит как оверхед
PS: В корпорациях есть одна тема, чем больше у тебя людей в подчинении, тем больше вес. Появляются маленькие императоры.
UK здесь не исключение
🤔10💯3 1
Как посчитать нужное число аналитиков?
Берем среднюю цену аналитика. Допустим 10 млн. руб, считая все з/п, налоги, технику, место в офисе, съеденные печеньки и т.д.
Допустим аналитик растит эффективность своего БЮ +10% против его отсутствия.
Тогда эффективно держать 1 аналитика на каждый 100 млн. ЕБИДТы. Лучше на 150 потому что аналитики складываются в группы, группам нужны тимлиды, PM, и вообще с ростом хед-каунта предельная эффективность падает.
Получаем простое правило.
Каждому БЮ положен 1 фулл-тайм дата аналитик при достижении 100-150 млн. ЕБИДТы. Если ИТ компания, то можно брать выручку так как % маржинальность по ЕБИДТе высокая.
До того мелкие БЮ могут запрашивать аналитику как сервис из негоего общего котла дата-офиса - эта возможность также должна быть.
Если у Авито есть 60-90 млрд ЕБИДТы, то никаких вопросов большая цифра хедкаунта аналитиков не вызывает.
Ваш архитектор, отягощенный дипломом по экономике 😄
Берем среднюю цену аналитика. Допустим 10 млн. руб, считая все з/п, налоги, технику, место в офисе, съеденные печеньки и т.д.
Допустим аналитик растит эффективность своего БЮ +10% против его отсутствия.
Тогда эффективно держать 1 аналитика на каждый 100 млн. ЕБИДТы. Лучше на 150 потому что аналитики складываются в группы, группам нужны тимлиды, PM, и вообще с ростом хед-каунта предельная эффективность падает.
Получаем простое правило.
Каждому БЮ положен 1 фулл-тайм дата аналитик при достижении 100-150 млн. ЕБИДТы. Если ИТ компания, то можно брать выручку так как % маржинальность по ЕБИДТе высокая.
До того мелкие БЮ могут запрашивать аналитику как сервис из негоего общего котла дата-офиса - эта возможность также должна быть.
Если у Авито есть 60-90 млрд ЕБИДТы, то никаких вопросов большая цифра хедкаунта аналитиков не вызывает.
Ваш архитектор, отягощенный дипломом по экономике 😄
Telegram
Архитектор Данных
Прочитал, что в Авито работает 600 аналитиков. Какая жесть. Зачем столько?
Маленькие армии сеньоров-помидоров?
https://habr-com.cdn.ampproject.org/c/s/habr.com/ru/amp/publications/978496/
В век автоматизации AI звучит как оверхед
PS: В корпорациях есть…
Маленькие армии сеньоров-помидоров?
https://habr-com.cdn.ampproject.org/c/s/habr.com/ru/amp/publications/978496/
В век автоматизации AI звучит как оверхед
PS: В корпорациях есть…
👍13🔥5❤1💩1
Структура хранения Apache Paimon
Как похоже на Айсберг, не правда ли?
А по механике скорее MergeTree (LSN-дерево). Последовательный компакшен от маленьких кусочков в большие, да еще можно в процесс компакшена засунуть дедупликацию или агрегацию. Бывалые пользователи кликхауса точно найдут здесь много знакомых моментов.
В целом - формат более Write Optimised, в то время как Iceberg - Read Optimised. зато более подходит для частой вставки.
Я бы сказал, что более сложный для понимания формат чем Iceberg. С большим числом скрытых внутненних особенностей.
Вроде как можно подключить в Trino как таблицу. Проверим?
Как похоже на Айсберг, не правда ли?
А по механике скорее MergeTree (LSN-дерево). Последовательный компакшен от маленьких кусочков в большие, да еще можно в процесс компакшена засунуть дедупликацию или агрегацию. Бывалые пользователи кликхауса точно найдут здесь много знакомых моментов.
В целом - формат более Write Optimised, в то время как Iceberg - Read Optimised. зато более подходит для частой вставки.
Я бы сказал, что более сложный для понимания формат чем Iceberg. С большим числом скрытых внутненних особенностей.
Вроде как можно подключить в Trino как таблицу. Проверим?
👍18🤯2❤1
Закончил читать курс по DLH, Iceberg, Modern Data Stack. Полагаю, что несколько человек (и я точно в их числе) продвинулись в понимании этого стека.
Курс показал себя востребованным. В нашей небольшой группе наступил SOLD-OUT за неделю до старта самих занятий. Хочу сказать огромное спасибо слушателям! За то, что помогли этому курсу случиться. За терпение к неизбежным косяками первого запуска. За то, что занесли в процессе много полезных сервисов и статей. За то что огромное количество раз заставили задуматься: «Хмм, а почему это вот так?», или «Блин, а действительно, почему бы не попробовать сделать вот эдак!»
Что хочется сказать о самой технологии Lakehouse+Iceberg - несколько пунктов, в которые я верю и вижу подтверждения своей веры.
📈 Она точно рано или поздно будет во всех местах, где есть 100+ ТБайт полезных реально используемых данных.
🔬 С нее точно удобнее сразу начинать, если вы амбициозная команда, и ищете способ продолжить технологическую экспансию в точке, где 1 ТБайт данных на Postgres начинают уже скрипеть.
📈 Мы точно увидим активное развитие экосистемы в ближайшие годы. А сервисы, которые делают стек более удобным, безопасным, быстрым точно будут востребованы рынком.
Ссылка на запись та же. Второй поток стартует в феврале. До встречи в новом году!
Курс показал себя востребованным. В нашей небольшой группе наступил SOLD-OUT за неделю до старта самих занятий. Хочу сказать огромное спасибо слушателям! За то, что помогли этому курсу случиться. За терпение к неизбежным косяками первого запуска. За то, что занесли в процессе много полезных сервисов и статей. За то что огромное количество раз заставили задуматься: «Хмм, а почему это вот так?», или «Блин, а действительно, почему бы не попробовать сделать вот эдак!»
Что хочется сказать о самой технологии Lakehouse+Iceberg - несколько пунктов, в которые я верю и вижу подтверждения своей веры.
Ссылка на запись та же. Второй поток стартует в феврале. До встречи в новом году!
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
Архитектор Данных
Запускаю курс по Lakehouse, Iceberg, Modern Data Stack.
В этом году по этим темам я провел 2 вебинара, 3 доклада на конференциях, 1 круглый стол, 2 эфира, написал несколько статей и постов.
Все это время мне много пишут в личку с техническими и организацонными…
В этом году по этим темам я провел 2 вебинара, 3 доклада на конференциях, 1 круглый стол, 2 эфира, написал несколько статей и постов.
Все это время мне много пишут в личку с техническими и организацонными…
❤11 6👏5😁1
Пока не совсем понимаю, зачем мне это, но, пожалуй, запишу в итоги года.
Так что зовите на конференции и в гости - прилечу.
Бизнес-классом😁
Так что зовите на конференции и в гости - прилечу.
Бизнес-классом
Please open Telegram to view this post
VIEW IN TELEGRAM
🫡9😁6🏆5
Please open Telegram to view this post
VIEW IN TELEGRAM
3🤣29🔥10✍5😢3💯3🤡1
Решил залить одно из фундаментальных видео по Айсбергу за последнее время.
Докладывает Райан Блу (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.
Ставьте 🔥, если хотите больше таких разборов или даже видео-разбора докладов от меня на русском языке.
-----------------------------------
------ Архитектор данных -------
-----------------------------------
Докладывает Райан Блу (Ryan Blue), один из создателей формата Айсберг и судя по линкед-ину сотрудник Data Bricks. Видео открывает Iceberg Summit 2025 в апреде этого года и содержит описание нескольких фундаментальных изменений, которые ждут нас в формате Iceberg v3.
Самые фундаментальные изменения в Iceberg v3:
Отдельная благодарность за то, что недостатки айсберга активно признаются - это я про не всегда эффективную метадату. И придумываются способы ее улучшить в будущем - это уже Iceberg v4
Видео на английском, я отрезал из него приветствия и завершение и добавил русскоязычные тайм-коды. Посмотреть можно либо ниже в канале, либо перезалив на ВК, либо оригинал на YT.
Ставьте 🔥, если хотите больше таких разборов или даже видео-разбора докладов от меня на русском языке.
-----------------------------------
------ Архитектор данных -------
-----------------------------------
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
Архитектор Данных
Структура хранения Apache Paimon
Как похоже на Айсберг, не правда ли?
А по механике скорее MergeTree (LSN-дерево). Последовательный компакшен от маленьких кусочков в большие, да еще можно в процесс компакшена засунуть дедупликацию или агрегацию. Бывалые…
Как похоже на Айсберг, не правда ли?
А по механике скорее MergeTree (LSN-дерево). Последовательный компакшен от маленьких кусочков в большие, да еще можно в процесс компакшена засунуть дедупликацию или агрегацию. Бывалые…
🔥18❤4 4👍1
Media is too big
VIEW IN TELEGRAM
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
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
❤6👍2 1