Призыв к сообществу
Поделитесь найденными за последний год ОпенСорс инструментами, которые оказались полезны в работе по Data Engineering
Особо интересны
- BI, визуализация, доставка данных
- ETL
- No code / Low Code Pipeline
- Data Quality
Отдельная благодарность - кто поделится в коментах, как именно вы используете эти инструменты и как они изменили ваши подходы.
Поделитесь найденными за последний год ОпенСорс инструментами, которые оказались полезны в работе по Data Engineering
Особо интересны
- BI, визуализация, доставка данных
- ETL
- No code / Low Code Pipeline
- Data Quality
Отдельная благодарность - кто поделится в коментах, как именно вы используете эти инструменты и как они изменили ваши подходы.
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😁7🏆5
Please open Telegram to view this post
VIEW IN TELEGRAM
4🤣32🔥11✍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-дерево). Последовательный компакшен от маленьких кусочков в большие, да еще можно в процесс компакшена засунуть дедупликацию или агрегацию. Бывалые…
🔥22❤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
❤9👍3 1
Вот и закончилась первая четверть XXI века.
С праздником, дорогие. Спасибо что вы здесь.
С праздником, дорогие. Спасибо что вы здесь.
❤25🍾13 7🤝1
Смотрим 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
------------------------------------
------ Архитектор данных -------
------------------------------------
Сегодня видео с громким названием Fully managed Streaming Data Lake in the Iceberg, но именно здесь я сэкономил вам время, потому что 2/3 доклада это маркетинговый питч продукта RedPanda.
RedPanda - интересный продукт из мира стриминга, и здесь они много говорят о добавленной интеграции с айсбергом и как они хорошо решают задачи построения Стрим-Хауса там где стандартные методы Kafka-Connect-Sync справятся хуже. Техническая часть короткая по времени, но все равно любопытная. Ее можно смотреть с 19:28
Можно использовать как быстрый чек-лист - а как мы будем решать вот эти проблемы, когда с ними неизбежно столкнемся при построении StreamHouse
Что сделали инженеры Redpanda, их заявка на успех
Ода продукту RedPanda
Видео с тайм-кодами постом ниже или на ВК Видео. Оригинал на Ютубе.
Часть 1 - Разбор нововведений Iceberg v3
------------------------------------
------ Архитектор данных -------
------------------------------------
Please open Telegram to view this post
VIEW IN TELEGRAM
VK Видео
Iceberg Summit 2025 - RedPanda StreamHouse
Доклад команды Red Panda на Iceberg Summit 2025. Много маркетинга, но довольно любопытное описание интеграции Topic-Table для реализации Streamhouse. Описание фич вполне сойдет за базовый чек-лист построения Стрим-Хауса. 00:00 - Ода продукту RedPanda. 05:46…
❤6 3👍2
Media is too big
VIEW IN TELEGRAM
00:00 - Ода продукту RedPanda.
05:46 - RedPanda Iceberg Topics. Topic-Table интеграция
08:21 - StreamHouse - что это?
15:58 - StreamHouse as a Service
19:28 - Техническая сторона интеграции Topic-Table, Redpanda-Iceberg
05:46 - RedPanda Iceberg Topics. Topic-Table интеграция
08:21 - StreamHouse - что это?
15:58 - StreamHouse as a Service
19:28 - Техническая сторона интеграции Topic-Table, Redpanda-Iceberg