uz
Feedback

Firibgarlarga uchmang! Telemetrio bunday kanallarni topadi va belgilaydi 👉 Belgini ko‘rmoqchi bo‘lsangiz, obuna bo‘ling

Data Engineering Digest

Data Engineering Digest

Kanalga Telegram’da o‘tish

Краткие выжимки и обзоры лучших докладов с конференций по Data Engineering. Экономим ваше время, оставляя только полезное. Для тех, кто любит данные и хочет быть в курсе лучшего в индустрии. Присоединяйтесь! 📊 contact: @NickTselishchev

Ko'proq ko'rsatish
1 184
Obunachilar
Ma'lumot yo'q24 soatlar
+57 kun
+1230 kun

Ma'lumotlar yuklanmoqda

Obunachilarni jalb qilish
Okt '26
Oktabr '26
+128
0 kanalda
Sentabr '260
0 kanalda
Get PRO
Avgust '260
0 kanalda
Get PRO
Iyul '260
0 kanalda
Get PRO
Iyun '260
0 kanalda
Get PRO
May '260
0 kanalda
Get PRO
Aprel '260
0 kanalda
Get PRO
Mart '260
0 kanalda
Get PRO
Fevral '260
0 kanalda
Get PRO
Yanvar '260
0 kanalda
Get PRO
Dekabr '250
0 kanalda
Get PRO
Noyabr '250
1 kanalda
Get PRO
Oktabr '25
+5
0 kanalda
Get PRO
Sentabr '25
+41
0 kanalda
Get PRO
Avgust '25
+28
0 kanalda
Get PRO
Iyul '25
+22
0 kanalda
Get PRO
Iyun '25
+38
0 kanalda
Get PRO
May '25
+68
0 kanalda
Get PRO
Aprel '25
+789
5 kanalda
Get PRO
Mart '250
1 kanalda
Get PRO
Fevral '25
+140
2 kanalda
Sana
Obunachilarni jalb qilish
Esdaliklar
Kanallar
31 Oktabr0
30 Oktabr0
29 Oktabr0
28 Oktabr0
27 Oktabr+2
26 Oktabr0
25 Oktabr0
24 Oktabr0
23 Oktabr0
22 Oktabr+3
21 Oktabr+2
20 Oktabr+2
19 Oktabr+2
18 Oktabr0
17 Oktabr0
16 Oktabr0
15 Oktabr0
14 Oktabr+2
13 Oktabr0
Kanal postlari
✨ Сергей Харитонов — Физиология лидерства: как тимлиду оставаться в ресурсе Сложность: 1/3 (Про то, как не принять хронический стресс за обычную загрузку. Биологии нет. Если хочется про гормоны и гипофиз — смотрите само видео.) Кому будет интересно: Тимлидам, у которых «тяжёлый проект» длится уже который месяц Тем, кто в один день пишет стратегию и тушит пожары YouTube: https://youtu.be/szmgcI7Xftk Сергей Харитонов, молекулярный биолог, сам три года руководил отделом. Доклад не про то, как стать лидером. Доклад про то, как следить за своим ресурсом и не перекладывать своё состояние на команду. Стресс он не предлагает выключить. Краткосрочно это рабочий тонус: прилетело письмо от руководителя, аппетит пропал, отчёт, который неделю лежал, собрался за полтора часа. Ломает другое. Хронический стресс маскируется под нормальную работу («ну устал, проект тяжёлый»), и организм садится в устойчивое плохое состояние. Из него выходные на диване уже не вытаскивают. 🔍 Что давит именно на руководителя 1️⃣ Переработки. На слайде: 50–55 часов в неделю против обычной недели дают +35% к риску инсульта и +17% к риску смерти от ишемической болезни сердца. Даже если работа нравится, лишние часы остаются нагрузкой. 2️⃣ Ролевой конфликт. Сверху хотят максимум результата за минимум затрат, снизу — обратное. Посередине тимлид. Это не техника и не алгоритм: с каждым человеком в каждый момент решается заново. 3️⃣ Ролевая перегрузка. Стратегия и тушение пожаров в один день. Стратегия любит спокойствие и широкий контекст, пожар — туннель и скорость. Это разные режимы, а требуют оба сразу. 🛠 Как понять, что это уже не «выход из зоны комфорта» Самый ранний сигнал — сон: засыпаете полтора–два часа и просыпаетесь ночью; встаёте раньше будильника и не досыпаете оставшиеся полчаса; при стабильном графике каждый день ложитесь и встаёте в разное время, просыпаетесь уже уставшим; Критерий из доклада: один или несколько таких симптомов 3+ дня в неделю дольше 4 недель. Плохой сон почти всегда сопровождает стресс, но сам по себе стресс не доказывает. Если явных причин нет, смотрите на образ жизни, а не ставьте себе диагноз. Рядом идут раздражительность, утомляемость, просевшая память и отвращение к планированию. Если это появилось вдруг на фоне выросшей нагрузки — это уже хроника, а не полезный рост. ⚙️ Что делать с собой Три привычные вещи, но с оговорками, которые как раз полезны. Сон. Первым пропадает глубокий сон, даже если «вроде спите». Если ночные смены или чужие часовые пояса навязаны работой: в рабочие часы свет яркий и холодный, после смены — темнота, блэкаут, ложиться, а не идти гулять «пока светло». Держится это регулярностью. Натуральным совам, которым такой график и так комфортен и он не ломает работу, ничего менять не надо. Долго жить на сменном графике из-под палки спикер не рекомендует: растут риски по сердцу. Движение. Тяжёлая тренировка — тот же стресс, на котором строится адаптация. Если уже просыпаетесь разбитым и сон поехал, зал «чтобы разгрузиться» добивает. В таком состоянии нужна лёгкая активность и прогулки. Прогулка лучше, чем диван. Прогулка в парке или лесу лучше обычной: взгляд в зелёной зоне успокаивает вегетатику сильнее, чем тот же шаг по улице. Еда. После тяжёлого дня недостаточно полежать. Надо нормально поесть: на фоне стресса организм активнее теряет магний, алкоголь это усиливает. Эффект магния накопительный, вечерней таблетки спокойствия из него не получится. По кишечнику ориентир простой — около 30 г клетчатки в день. И рамка на долгую дистанцию. Даже когда острое отпустило, тело может ещё долго держать старый режим. Это марафон. Один отпуск состояние не обнуляет. Психотерапия, в первую очередь когнитивно-поведенческая, у него — нормальная первая точка входа, а не «когда уже совсем». Антидепрессанты по назначению психиатра он тоже не стигматизирует. Хронический стресс умеет усаживать в яму, из которой сам не вылезаешь. Препарат помогает задержаться в нормальном состоянии, пока нарабатываются другие реакции. После отмены их проще удерживать. Менять роль тимлида из-за этого не нужно: человек занялся своим состоянием. 👥 Что делать с командой Неотрегулированные эмоции руководителя — неоплачиваемая работа сотрудников. В KPI «успокаивал тимлида шесть раз за неделю» никто не напишет. Команда это чувствует, даже если делает вид, что нет. Модель, которую он советует почитать, — JD-R (Job Demands–Resources). Считаются две колонки. Demands — не «вся работа», а то, что регулярно выматывает: ночные выезды, холодные звонки, вечные пожары. Resources — то, чем компания помогает это тянуть: структура, развитие, поддержка. Людей ресурсами лучше не называть. Ресурс тратят, и потом искренне удивляются, что люди кончились. Ресурсы надо раздавать. Кто умеет добывать их сам, обычно быстро становится тимлидом и дальше должен раздавать другим. Самый сильный фактор против выгорания в исследованиях, на которые он ссылается, — одобрение руководителя. Сильнее плохой зарплаты и отсутствия выходных. Хвалите вслух и регулярно. Закрывайте спринты и тяжёлые проекты явной рефлексией, а не просто «ну, задеплоили». Такие сессии, по цифре из доклада, поднимают эффективность людей и команд на 20–25% за счёт того, что падает неопределённость. Командные тренинги по стресс-скиллам у него — рабочий инструмент, а не корпоратив для галочки. Люди лучше проживают тяжёлые периоды. На слайде был чек-лист тимлида, его имеет смысл сфотографировать с записи. Отдых. Пассивное «просто полежал» ощущение благополучия почти не улучшает. Рабочая модель, которую он назвал и не успел разобрать, — DRAMMA: Detachment — отключиться от работы Relaxation — расслабиться Autonomy — самому решать, как провести время Mastery — сделать что-то, в чём чувствуешь умение Meaning — чтобы у времени был смысл Affiliation — побыть с людьми Нормальный отдых снижает потребность в свободном времени. Ведущая на это сразу осадила: сначала сон, движение, еда, голова и команда, и только потом разговоры про то, что выходных нужно меньше. 💡 Вывод Хронический стресс тимлида — свойство среды, которое потом тащит команда. Следить проще всего по сну. Если сон уже поехал, тяжёлый спорт и «ещё немного потерпеть» ситуацию ухудшают. Работают сон, лёгкое движение, еда, внятное закрытие проектов, похвала и психотерапия, если яма уже устойчивая. 🤔 Ответы на вопросы Q: Как жить ночным тимлидам и командам в разных часовых поясах? A: Совам, которым так естественно, режим менять не надо. Если график навязан, спасает дисциплина света: ярко и холодно, пока работаете, темнота после смены. Долго так жить не стоит. Q: В команде на загрузке сыпется иммунитет. Чем поделиться с людьми? A: Работать со стрессом, а не с иммунитетом. Если не отпускает — к врачу, общих схем тут нет. Q: Тимлид на антидепрессантах. Это красный флаг? A: Нет. Назначенный препарат — способ выйти из устойчивого плохого состояния. Паузу в роли из-за этого делать не нужно. Q: Спорт при хроническом стрессе помогает или добивает? A: Тяжёлая нагрузка добивает, если уже есть плохой сон и усталость с утра. Нужны прогулки и лёгкая активность, лучше в зелёной зоне. Q: Как отличить полезный выход из зоны комфорта от сползания в хронику? A: Поехал сон, и устойчиво просели память, настроение и способность планировать. Это уже не полезный стресс.

2
5 октября начнется 19-й поток программы Data Engineer от Newprolab Программа для junior- и middle-дата-инженеров, аналитиков,
5 октября начнется 19-й поток программы Data Engineer от Newprolab Программа для junior- и middle-дата-инженеров, аналитиков, backend-разработчиков, техлидов и тех, кто работает с data-командами и хочет лучше понимать современный стек DE 📌 Что внутри: – 10 недель обучения – 30 занятий: онлайн + записи – 10 практических лабораторных работ – облачный кластер и реальные данные – чат участников и поддержка команды программы 📌 Что получите на выходе: 1. Научитесь решать типовые задачи DE на практике 2. Систематизируете знания и закроете пробелы в современном DE-стеке 3. Поработаете с реальными данными и инфраструктурой, а не только с учебными примерами 4. Соберете практический опыт, который можно обсуждать на собеседованиях и использовать в работе 5. Все записи и материалы останутся у вас после окончания программы Преподаватели – практикующие специалисты из ведущих технологических компаний. На занятиях можно разбирать реальные кейсы, задавать вопросы и получать обратную связь 👉 Подробности и квиз – на сайте Квиз покажет, насколько программа подходит именно под вашу роль и задачи, даст персональные рекомендации и промокод на скидку ___ По всем вопросам пишите Алексею @snitsa
808
3
Прошу простить, уже долгое время не могу выделить время на полноценный пост о интересных докладах с конференциях. Но это не значит, что доклады я перестал смотреть) По итогам просмотра очередного доклада: https://www.youtube.com/watch?v=JeAP_L671CQ родился небольшой пост. На курсах по Clickhouse меня спрашивали: "А если у нас только логи, которые мы хотим анализировать, нам нужен Clickhouse или можно обойтись Elasticsearch?" Я ответил что-то вроде: а) Полнотекстовый поиск и расследование, объём умеренный, хранить недолго - оставайтесь на Elasticsearch. б) Отчёты, тренды, долгая история, SQL - берите ClickHouse, даже если источник только логи. Полнотекстовый поиск в CH тоже есть (индексы для полнотекстового поиска), но заставить их работать - тот ещё квест. в) Нужны оба сценария - это два разных хранилища: Elasticsearch на короткий операционный контур, ClickHouse на аналитику и длинное хранение. Одно другим не заменяется. А от меня хотели услышать цифры, сравнение производительности. А я их дать не смог) В этом докладе ссылочка на неплохую статью https://infostart.ru/1c/articles/1325649/ Сам доклад так же рекомендую)
712
4
5 октября начнется 19-й поток программы Data Engineer от Newprolab Программа для junior- и middle-дата-инженеров, аналитиков,
5 октября начнется 19-й поток программы Data Engineer от Newprolab Программа для junior- и middle-дата-инженеров, аналитиков, backend-разработчиков, техлидов и тех, кто работает с data-командами и хочет лучше понимать современный стек DE 📌 Что внутри: – 10 недель обучения – 30 занятий: онлайн + записи – 10 практических лабораторных работ – облачный кластер и реальные данные – чат участников и поддержка команды программы 📌 Что получите на выходе: 1. Научитесь решать типовые задачи DE на практике 2. Систематизируете знания и закроете пробелы в современном DE-стеке 3. Поработаете с реальными данными и инфраструктурой, а не только с учебными примерами 4. Соберете практический опыт, который можно обсуждать на собеседованиях и использовать в работе 5. Все записи и материалы останутся у вас после окончания программы Преподаватели – практикующие специалисты из ведущих технологических компаний. На занятиях можно разбирать реальные кейсы, задавать вопросы и получать обратную связь 👉 Подробности и квиз – на сайте Квиз покажет, насколько программа подходит именно под вашу роль и задачи, даст персональные рекомендации и промокод на скидку ___ По всем вопросам пишите Алексею @snitsa Реклама. НОЧУ ДПО «НЬЮПРОЛАБ», ИНН 7729461098, erid: CQH36pWzJqVKq9rQTHdoerUjCtLJwbma2q2Sq6DgPEKAP7
976
5
Ещё один доклад из которого не получился пост по причине того, что админ очень не любит spark) https://youtu.be/xhgsQIqkNYY?s+2
Ещё один доклад из которого не получился пост по причине того, что админ очень не любит spark) https://youtu.be/xhgsQIqkNYY?si=iSXHWg8Fyd-goJz4 Приложу три самых интересных для меня скринов из доклада
1 183
6
+4
Matn yo'q...
1 170
7
Мне очень нравится вопрос: Чем Parquet отличается от Iceberg? Если очень-очень грубо усреднить ответы, то получится что-то типа: Parquet - это файл с данными, а Iceberg - это данные + метаданные про этот файл. Но если Iceberg «умный» и уже хранит метаданные, почему в стеке Trino + S3 до сих пор живет Metastore? Какие функции он выполняет? На этот вопрос ответят в докладе Михаила Иванова "Что такое metastore и с чем его едят?" YT : https://www.youtube.com/watch?v=BJnOb_BJCLQ VK : https://vkvideo.ru/video-147464741_456239481 Привычного формата поста не будет, так как в докладе разбирают специфичный кейс компании, которой не подошли современные metastore и они пошли по пути написания своего решения. Я бы порекомендовал посмотреть первые 15 минут доклада для Junior/middle специалистов, а для Senior/Architector последние 15 минут доклада) Но доклад правда интересный) Покидаю интересные скрины с доклада следующим постом:
1 127
8
✨ Станислав Лысиков — StarRocks как ядро современной платформы данных Станислав Лысиков рассказал о внедрении StarRocks в продуктовом финтехе с данными до петабайта. Доклад — это честный разбор опыта перехода на новую аналитическую СУБД. Дисклеймер: Рекомендую не читать этот пост, а посмотреть доклад самим) Смотрится легко и очень интересно) YouTube: https://www.youtube.com/watch?v=oiPXIbX-cTw VK Видео: https://vkvideo.ru/video-147464741_456239483 Сложность: 2/3 (Технически насыщенный доклад, требует понимания архитектуры аналитических баз данных) Кому будет интересно: • Дата-архитекторам и инженерам • Всем, кто выбирает аналитическую СУБД для высокой нагрузки 🔍 Проблемы, которые привели к StarRocks • Старый стек: Микросервисы на MySQL + Go, но аналитика не масштабировалась • Требования к новой БД: ✔️ Дешевое внедрение и масштабируемость ✔️ Высокая скорость на потоковых данных ✔️ Open Source с активным сообществом 🏗 Архитектура и установка Два режима работы: 1 Share Nothing (данные + вычисления на одних нодах) 2 Share Data (отдельное хранилище) Минимальные требования: • 3 ноды для продакшна (рекомендуется 5) • NVMe диски, RAID не требуется • Репликация на уровне серверов Управление: • Готовность к Kubernetes (есть операторы) • Простое ручное развертывание через Helm ⚡️ Ключевые особенности StarRocks Производительность: • Разработан для лямбда-архитектуры • Высокая скорость запросов (сравнима с ClickHouse, быстрее Vertica/Spark) Поддержка форматов: • Нативные коннекторы к HDFS, Iceberg, JSON • Работа с Hive Metastore Уникальные фичи: • Data Recovery — восстановление случайно удаленных данных • Частичные UPDATE по условию • Хранение Kafka-оффсетов в БД (независимость от consumer groups) 🔄 Интеграция с данными Потоковая загрузка: • Нативная поддержка Kafka • Проблема с порядком сообщений решена через таймштампы Работа с Go: • Прямая работа с Go-структурами (команда без Java/.NET специалистов) 🛠 Проблемы и решения 1️⃣ Шардирование данных: • Двухуровневое (партиции + бакеты) • Автоматическое распределение при добавлении нод 2️⃣ Совместимость: • Драйвер через MySQL-протокол • Проблемы с некоторыми системами (например, Vertica) 3️⃣ Decimal типы: • Пришлось реализовывать кастомное решение 📊 Сравнение с аналогами StarRocks vs ClickHouse/Trino: • Выше скорость на аналитических запросах • Лучшая поддержка потоковой загрузки StarRocks vs Doris: • Разная кодовая база • Активное развитие отдельного сообщества 🤝 Сообщество и поддержка • Open Source: Активное развитие, быстрое исправление регрессий • В РФ: Доступна платная поддержка (решение Selena) • Коммерческие внедрения: Успешные кейсы в банках и телекоме 💡 Практические выводы ✅ Плюсы: • Простое развертывание и масштабирование • Высокая скорость работы с потоковыми данными • Активное сообщество ⚠️ Минусы: • Молодая экосистема (проблемы с некоторыми драйверами) • Требует адаптации под специфичные типы данных Итог: StarRocks — мощный вариант для построение DWH и для аналитики в реальном времени. Подходит для компаний, которые хотят быстро развернуть производительное решение без огромных затрат.
3 155
9
Продолжение предыдущего поста. Выводы и ответы на вопросы не влезли) 📝 Чего избегать: 1️⃣ С осторожностью соединять процессоры 2️⃣ Не усложнять процессор в погоне за оптимизацией ❔Ответы на вопросы: Q: Где брать готовые процессоры для NiFi A: Ожидать сервис от коммьюнити, сейчас никак Q: Можно ли отладить процессор в IDE? A: в NiFi есть эмуляция процессов, можно написать тест там. Возможно открыть PortDebug, поможет если уже процессор работает, но ведет себя аномально. Q: Как часто ты рекомендуешь использовать систему логгирования? A: Использую всегда. Трейсы пишу всегда, когда есть ошибки, ворнинги пишу, но стараюсь не перегружать ими. Q: Как дебажить ScriptedProcessor? A: Если его не выпилят в 2.0, я напишу функционал и выложу. для Groovy такое уже есть
3 190
10
Бронислав Житников — NiFi. Пишем код для codeless-системы Сложность: 2/3 (Если NiFi не трогали - пропускайте данный доклад. Это отличное подспорье для углубленного знакомства с NiFi) 📺: https://youtu.be/Lnta1yPIMrY?si=cuGJLbmET3cQvadf 📺 :VK 🔍 Условия: 1️⃣ В NiFi может не хватать встроенных процессоров 2️⃣ Иногда нужно избежать приземления данных на диск и для этого несколько процессоров собрать в один 3️⃣ Встроенный процессор иногда стоит доработать, либо исправить в нем ошибки ⚙️ Путь к необходимости писать код: 1️⃣ ExecuteStreamCode — позволяет запустить внешний скрипт 2️⃣ ExecuteScript — дает доступ к внутренним фишкам NiFi 3️⃣ ScriptedService — позволяет изменить часть логики 4️⃣ ScriptedProcessor — позволяет прописать всю логику процессора 🛠 Устройство NiFi: Для написания кода в большинстве случаев придется работать с NiFi API (Processors&Service) 1️⃣ ScriptEngine: докладчик рекомендует писать скрипты сразу на Groovy, так как Jython не даст свободы использования Python и при этом даст ограничения в работе с API 2️⃣ Можно писать свои модули сразу на Java 3️⃣ В версии 2.0 ожидается написание модулей на Python ⚙️ Шаги создания Processor: 1️⃣ Чтение Developers Guide 2️⃣ Применение Maven-Archetype — быстрый старт разработки, есть только часть процессоров и сервисов 3️⃣ Заполняем аннотации — могут определять поведение процессора, наполнять документацию, определять ключевые методы 4️⃣ Заполняем OnScheduled 5️⃣ Заполняем OnTrigger ⚙️ Аннотации поведения: 1️⃣ @InputRequirement — требует ли входящей очереди (обязательна, допустима, недопустима) 2️⃣ @TriggerWhenEmpty — требуется ли FlowFile. Позволяет запускаться процессору без файлов во входящей очереди. Для процессоров без входящих очередей не имеет смысла 3️⃣ @PrimaryNodeOnly — запуск только на ведущей ноде. Пригодится для процессоров без входящих очередей 4️⃣ @SupportBatching — возможность запускать длительный Run, снимая нагрузку с планировщика ⚙️ Аннотации документирования: 1️⃣ @CapabilityDescription — описание процессора 2️⃣ @UseCase — редко встречается, но очень помогают пользователям 3️⃣ @ReadAtrribute/@WriteAttribute — описывает, какие атрибуты приходят на вход и оказываются на выходе из процессора 4️⃣ @SeeAlso — справка о дополнительных источниках 📝 Расширенное документирование: 1️⃣ в каталоге resoursces создать docs, там создать каталог с полным именем процессора 2️⃣ Создать файл additionalDetails.html 🪛 Важные элементы разработки: 1️⃣ Properties — важно определить, как параметры обрабатываются; работают ли они с сервисами и с какими; определить наличие dynamic properties; настроить валидаторы и обязательность указания параметров 2️⃣ Relationships — заполнить имя, описание, обязательно указать настройку "выключен по умолчанию" 3️⃣ Lifecycle — c @OnAdded начинается создание экземпляра процессора; @Onscheduled — запуск процессора, при перезапуске NiFi так же вызывается @OnUnscheduled — остановка процессора, если его запуск больше не запланирован. Часть тредов могут быть активны после вызова метода с этой аннотацией. Лучше избегать применения в логике для выключения процессора @OnStopped — следует применять эту аннотацию к методу, срабатывающему при полной остановке процессора @OnRemoved — удаление экземпляра процессора @OnShutdown — избегать использования в логике, так как NiFi чаще останавливается нештатно ⚙️⚙️ OnTrigger — метод построения логики работы процессора 1️⃣ Проверить наличие файла 2️⃣ Помнить об экземплярах вызова, изменяемые данные должны быть внутри OnTrigger 3️⃣ Расчет только из атрибутов 4️⃣ Не изменять атрибуты во время изменения контента 5️⃣ Не забывать отправлять файлы в следующие отношения или удалять 6️⃣ session.penalize — позволяет определить период, когда файл не подлежит обработке, используется для обработки ошибок 7️⃣ context.yield — в случае отсутствия отклика БД процессор может не запускаться какое-то время, даже если расписание на него выставлено 8️⃣ ProcessSession — управляет обработкой файла 9️⃣ ProcessContext — определяет доступ к информации из процессора и среды
2 879
11
Николай Ижиков — One More Way to Make Backup in Ignite Сложность: 3/3 (Обязательно к прослушиванию, если вам интересна работа с OLTP-нагрузкой и технические подробности снятия бэкапов) Николай Ижиков, Platform V DataGrid Tech Lead, а также контрибьютор в Apache Kafka и участник PMC Apache ignite, рассказывает нам, как реализованы бэкапы в Platform V DataGrid, а главное — про cache dumps. YouTube: https://www.youtube.com/watch?v=A3EkvdGK4Jg VK Видео: https://vkvideo.ru/video-147464741_456239442 🔍 Условия: Кластер процессинга: 32 узла, 700 ГБ RAM на узел, 40к RPS на узел. Кластер токенизатора: 5 узлов, 550 ГБ RAM на узел, 500к RPS. ⚙️Падение СУБД 1️⃣ Однонодовая СУБД — после падения приложение не работает, Запросы не обслуживаются, данные теряются при простое. 2️⃣ Распределенная СУБД — спектр последствий разный. Может снижаться перфоманс, может теряться часть данных. ⚙️Метрики восстановления после аварии Recovery Point Objective — целевая точка восстановления, после которой мы теряем данные. Мы оцениваем время, в течение которого мы теряем данные за этой точкой. Recovery Time Objective — с её помощью мы оцениваем время, затраченное на восстановление системы после аварии. 🛠 Способы формирования бэкапов (рекомендуется изучить презентацию к докладу): 1️⃣ Apache Ignite: ребаланс данных, позволяет сохранить данные, если количество упавших нод меньше бэкап-фактора. 2️⃣ DataGrid: при ребалансе данных распределение партиций такое, что у стойки есть дублер. Позволяет восстановиться при падении стойки. 3️⃣ Apache Ignite: CDC обеспечивает асинхронную логическую репликацию данных. RPO ➡️ секунды, RTO ➡️ 0. Данные реплицируются в другой кластер через WAL, доступ к данным открывается после перемещения сегмента в архив. Из-за этого RPO сдвигается. 4️⃣ Data Grid: Online CDC внутри ноды есть буфер данных, который наполняется событиями и из него данные стримятся в соседний кластер. RPO ➡️ 0, RTO ➡️ 0. Растет потребление памяти, при переполнении используется классический CDC через WAL. 5️⃣ Снапшоты в Apache Ignite: системный процесс PME делает stop the world. Начатые транзакции заканчиваются, новые стоят на паузе. В этот момент происходит копирование партиций, изменения пишутся отдельно, после снятия резервной копии изменения накладываются поверх снимка. RPO ➡️ часы, RTO ➡️ 0 6️⃣ Apache Ignite: инкрементальный снапшот снимает только изменения в данных, но часто. Система не блокируется. RPO ➡️ минуты, RTO ➡️ минуты. В докладе даны ссылки на статьи по этому механизму. 🔮 Cache dump 📝Задачи и качества метода: 1️⃣ консистентный бэкап in-memory кэшей с учетом транзакций без прерывания пользовательской нагрузки; 2️⃣ Восстановление данных на любую топологию; 3️⃣ Поддержка CLI; 4️⃣ API offline обработка ⚙️⚙️ Механизм снятия дампа: 1️⃣ Stop the world 2️⃣ Данные консистентны; запуск писателей дампа 3️⃣ Для сохранения консистентности установка listener'ов на изменения кэша 4️⃣ Запуск транзакций 5️⃣ Итерация по партициям и запись row by row 6️⃣ Запись данных listener'ом 🪛 Тонкости: 1️⃣ Откатиться, если где-то ошибка — Distributed Process. 2️⃣ Не перегрузить ноды системным процессом - прежде всего операции пользователя. 3️⃣ Запоминание изменений каждого ключа — это дорого по памяти. 📝 Эффективная фильтрация: 1️⃣ Итератор по партиции не транзакционный Listener должен сохранить entry до изменения 2️⃣ Итератор сортированный (B+дерево) 3️⃣ У каждой записи есть уникальная версия. Версия выдается на primary. ❔Ответы на вопросы: Q: cache dump можно снимать не только для in-memory cache, но и для персистентного кэша? A: Можно, вопрос целесообразности. Для persistent cache есть более подходящие способы. Q: Уточнение по процессу: если версия ключа более новая, то итератор её пропускает. Как все значения ключей попадают в запись бэкапа? A: Если версия старше версии в момент снятия, то эти данные либо пришли после запуска процесса снятия бэкапа, либо старые данные были изменены во время снятия и эти изменения записаны listener'ом.
1 814
12
✨ Татьяна Дидова — Как мы тестировали 5 способов загрузки данных в Greenplum и что из этого вышло Сложность: 1/3 (Желателен минимальный опыт работы с Greenplum. Тем, кто в GP погружен максимально, вряд ли будет интересно, разве что про то, что sparkом тоже можно писать в GP, не через мастер) YouTube: https://www.youtube.com/watch?v=7EcieM3XoXE VK Video: https://vkvideo.ru/video-147464741_456239454 Татьяна Дидова, Tech Lead Data Engineer в АЭРО, знакомит слушателей со способами загрузки данных в GP. 🔍 Первый кейс: миграция с Oracle на Greenplum - "реализовать не хуже, чем есть на Oracle" 🔍 Второй кейс: Заказчика не устраивает процесс загрузки в ClickHouse, необходима реализация на Greenplum, результат должен быть сильно лучше. Условия: 1️⃣ На первом проекте сотни баз, на втором - около десятка. 2️⃣ Количество баз данных и объем данных растет, объем выгружаемых данных отличается между источниками: в одном источнике десятки гигабайт, в другом - тысячи строк. 3️⃣ При создании базы данных на Greenplum, как правило, есть возможность выбрать оптимальный для данного случая способ загрузки, но при постановке задачи сделать не хуже или лучше, чем уже есть при использовании других технологий, были сформулированы требования по времени загрузки. ⚙️ Способы загрузки данных non-parallel: Insert, Copy ✅ Нужен один сервер для развертки кода загрузчика ✅ Удобство отладки ⭕️ Высокая нагрузка на мастер-узел ⭕️ Низкая эффективность при большом объеме данных parallel: 1️⃣ PXF: ✅ Прямое подключение к источнику ✅ Достаточно знать SQL и credentials для подключения к источнику ⭕️ Сложность администрирования ⭕️ Сокращение ресурсов сегмента ⭕️ Повышение требований к источнику ⭕️ credentials в запросе создают проблемы с информационной безопасностью 2️⃣ Gpfdist: ✅ Оптимизация под работу с Greenplum ✅ Параметризация загрузки данных по сегментам ⭕️ Требовательность к производительности сети ⭕️ Необходимость управления несколькими экземплярами при больших объемах ⭕️ Масштабируемость ограничена ⭕️ Контроль портов 3️⃣ Spark-connector: ✅ Поддержка сложных трансформаций ✅ Расширение спектра источников ⭕️ Сложная первичная настройка ⭕️ Возможны проблемы с совместимостью ⭕️ Скорость загрузки может быть снижена Далее в докладе приводится сравнение по времени загрузки, нагляднее всего отраженное в презентации. 🛠 Варианты ускорения: 🔨Общие: 1️⃣ Удалить индексы перед загрузкой данных. Иногда пересоздать индексы быстрее, чем постепенно обновлять имеющиеся. 2️⃣ Отключить автоматический сбор статистики 3️⃣ Запустить VACUUM, если при загрузке были ошибки 🪛 Частные случаи: INSERT: попробовать COPY COPY: запустить несколько COPY PXF: оптимизация данных в источнике; изменение batch-size Gpfdist: использовать PIPE; не сжимать передаваемые данные по возможности Spark: расширить используемые ресурсы для execute node; изменить batch-size 📝 Архитектура 1: Spark используется для больших загрузок, маленькие загрузки идут посредством COPY 📝 Архитектура 2: Источники - это postgreSQL, используется PXF для загрузки. ❔Ответы на вопросы: Q: На чем была написана загрузка? A: Использовался Python, так как логика первого проекта была зашита в DAG Factory. Во втором проекте PXF подключения генерировались с помощью скриптов на Python, позже PXF загрузки переехали на dbt. Q: Делались ли замеры по использованию памяти? A: Делались, но сконцентрировались на времени загрузки 💡Выводы: <1 млн строк ➡️ non-parallel >1 млн строк ➡️ parallel: Высокая нагрузка при загрузке данных ➡️ PXF не подойдет Файлы CSV/TSV ➡️ может подойти Gpfdist Регулярные большие объемы данных ➡️ Spark connector
2 142
13
Почему формат «симулятор + ментор» работает лучше классических курсов За последние годы накопилось довольно много наблюдений о том, почему классическое онлайн-обучение по Data Engineering редко даёт нужный результат. Особенно если человек не просто «входит в IT», а хочет реально разобраться в архитектуре пайплайнов, orchestration, хранилищах и потоковой обработке. Коротко — типовая проблема: - Видео без связки с задачами → быстро забывается - Нет контекста, зачем делать то или иное → не формируется мышление инженера - Самостоятельная борьба с непониманием → упадок мотивации → dropout - «Игра в проект» вместо приближенной к продовой среды 📍 Поэтому я внимательно посмотрел на новый поток курса «Инженер данных» от Simulative, который стартует 11 июля. И кажется, там как раз попытались обойти эти узкие места. Курс построен как симулятор рабочей среды: — Используется стек, который встречается в большинстве дата-платформ: Spark, Kafka, Airflow, PostgreSQL, CI/CD — Все задания — это имитация типовых прод-задач — Формат сопровождения ментором из индустрии, который не просто проверяет, а помогает понять, почему архитектура пайплайна устроена именно так, где искать слабые места, как мыслить в продовом контексте. Ментор — Александр Дарьин (СберТройка, автор канала «Аналитик на минималках») — сам проходил путь с нуля и работает в инфраструктуре на стеке, близком к тому, что сейчас активно внедряется в крупных DLH-решениях (Kafka → S3 → Lake → витрины). 📌 Вывод, который напрашивается: если задача — не просто «поверхностно пройти курс», а подготовиться к настоящей инженерной работе — формат “симулятора + ментор” даёт больше эффекта, чем набор видео + ТЗ + чат поддержки. Кстати, если зайдете на поток до понедельника по промокоду DIGEST, получите скидку 25% 🔗 Оставляйте заявку P.S. Если есть подобные форматы, где действительно моделируются реальные процессы (CI/CD, отказоустойчивость, DAG-и, потоки, мониторинг) — делитесь, интересно собрать такую подборку.
777
14
✨ Валентин Пановский — Миграция на Iceberg: как кролик съел зеленую сливу и не умер Сложность: 1/3 (Интересная историческая справка в начале , нет сложного кода, в который необходимо вникнуть. Докладчик рассказывает понятным и доступным языком) https://www.youtube.com/watch?v=YWD7WcfFfk8 Валентин Пановский поделился опытом миграции с монолитного Greenplum на разделенную Lakehouse-архитектуру с Iceberg в страховой компании. 🔍 Проблемы старой системы Монолитная DWH на Greenplum: Высокая стоимость (лицензии + оборудование) Сложности с масштабированием Ограниченная гибкость для аналитиков Гетерогенная среда: 50-70 ТБ данных за 4 года Разные источники: MongoDB, Kafka, классические БД 🚀 Выбор новой архитектуры Требования: ✔️ Разделение storage/compute ✔️ Open Source решения ✔️ Снижение TCO (полная окупаемость к 2025) Выбранный стек: Хранение: S3 (Яндекс.Облако) + Iceberg Compute: Trino (основной) + Greenplum (легаси) Оркестрация: Dagster + dbt Каталог: OpenMetadata ⚙️ Реализация 1️⃣ Миграция данных: Таблицы переносились "в лоб" через Airflow. Самая большая таблица - до 60 ГБ). Основной объем — инкрементально (T+1) 2️⃣ Слои данных: Raw → ODS → DDS → Витрины Исторические данные: срезы раз в неделю + архив (6 месяцев) 3️⃣ Интеграции: MongoDB: CDC через Debezium → Kafka → Greenplum (PXF) Trino: Нативные коннекторы (проще чем в GP) 🛠 Проблемы и решения Деградация JOIN-ов: До 27% в не-OLAP сценариях Кастомные типы данных: Обработка на ETL-уровне Хранимые процедуры: Пришлось переписывать витрины Безопасность: Реализована через Trino + Keycloak 📊 Результаты ✅ Экономия: Снижение затрат на лицензии и оборудование Хранение в 10+ раз дешевле ✅ Гибкость: Разные движки (Trino/GP) работают с одними данными Легкое масштабирование в Kubernetes 🔮 Планы Переход с HMS на Nessie (branch-поддержка) Внедрение Data Vault вместо 3NF Автоскейлинг Trino на основе метрик 🤔 Ответы на вопросы Q: Как настраивали ИБ? A: Вопросы изоляции и безопасности решались на уровне trino через системы аутентификации и политик доступа. Q: Как решали проблему неконсистентных типов? A: На ETL-уровне. MongoDB оставили как есть (легаси) Q: Почему Parquet, а не ORC? A: Лучшая производительность в наших тестах Q: FTE не пробовали? A: Нет, проще перезапускать (макс. запрос — 45 мин) Q: Используете ли динамическое партиционирование? A: Пока в бэклоге 💡 Вывод: Миграция на Iceberg — сложный, но окупаемый процесс. Главные плюсы: гибкость, экономия и возможность использовать лучшие инструменты для разных задач.
999
15
⚡️Как сменить профессию и стать востребованным инженером данных? Инженер данных — один из вариантов развития профессии для те
⚡️Как сменить профессию и стать востребованным инженером данных? Инженер данных — один из вариантов развития профессии для тех, кто хочет брать на себя более сложные задачи, влиять на архитектуру решений и увеличивать свой доход. На вебинаре 1 июля в 18:30 по МСК Александр Дарьин, старший аналитик «СберТройка», расскажет, как вырасти в востребованную специализацию — инженера данных — и расширить свои возможности. Что обсудим: 🟠Личный путь Александра от рабочего на заводе до старшего аналитика за 2,5 года;; 🟠Какие навыки освоить и добавить — разберём дорожную карту инженера данных; 🟠Как ускорить рост — почему самообразование часто тормозит, а системное обучение даёт быстрые результаты; 🟠Где брать кейсы для портфолио — как пет-проекты помогают компенсировать отсутствие коммерческого опыта в дата-инженерии; 🟠Актуальные зарплаты и тренды — разберём вакансии и перспективы рынка в прямом эфире. Не упустите шанс получить чёткий план и мотивацию для уверенного старта в востребованной профессии! 🕗 Встречаемся 1 июля в 18:30 по МСК 😶Зарегистрироваться на бесплатный вебинар
539
16
⚡Как пройти тестовое на продуктового аналитика: разбор компании Билайн Если вы готовитесь к собеседованию или только делаете
⚡Как пройти тестовое на продуктового аналитика: разбор компании Билайн Если вы готовитесь к собеседованию или только делаете свои первые шаги в аналитике, для вас очень важно знать какие задания могут встречаться при приеме на работу. Наш вебинар приблизит вас к новой профессии. Егор Чеменев, опытный продуктовый аналитик из Wildberries проведет прямой эфир, посвященный созданию продуктового дашборда. Что разберём на реальном тестовом задании от Билайна? 🟠Посмотрим динамику маржи по неделям – напишем SQL-запрос и визуализируем данные; 🟠Посчитаем маржу в рублях и % – разберём в разрезе Сайта и Приложения; 🟠Проанализируем поведение клиентов – найдём % тех, кто любит и бонусы, и промокоды; 🟠Практическая часть по построению визуализаций в Superset. В конце вебинара будет разбор ваших кейсов в Q&A-сессии — задавайте вопросы и получайте фидбек от эксперта. 🕗 Встречаемся 27 мая в 18:30 по МСК 😶Зарегистрироваться на бесплатный вебинар
572
17
Отдельного поста заслуживают ответы на вопросы по выступлению команды Лемана Тех про LakeHouse. Я, пользуясь случаем, выражу благодарность комании querify labs (cedrus data) за организацию митапа. И, конечно, ребятам из Лемана Тех за то, что поделились своим опытом и готовы ответить на Ваши вопросы в комментариях к этому посту. --- Как разделили ресурсы? Ресурсные группы не настраивали, нагрузку разделили по разным кластерам. Сравнение производительности Greenplum и Trino? Trino медленнее Greenplum примерно на 20%, если у GP всё на SSD. Рассматриваете ли Paimon как каталог? Пока не тестировали, хотим подходить к вопросу с каталогом итеративно. Почему выбрали Avro? Технология удовлетворяла всем требованиям и хорошо знакомы с этой технологией, есть опыт работы. Данные отправляют вам или вы их запрашиваете? Команды не настраивают ничего сами, сервисная служба настраивает Debezium, дальше всё льётся в общую шину, а платформа данных уже самостоятельно забирает данные. Как боретесь с большим количеством файлов в S3? Сейчас поддерживаем вручную, планируется автоматизация. Используете ли FTE (Fault-tolerant execution)? Не используем, слишком медленно — просто перезапускаем при падениях. Какой функционал Iceberg используете для ускорения запросов? Индексы не накидывали, используем партиционирование и бакетирование. С сортировкой экспериментировали - большого эффекта не дала. Как обеспечиваете high availability? Пока всё в ручном режиме, координатор ни разу не падал. Почему выбрали HMS? Нужен был один каталог для работы с паркетами и Iceberg — HMS это закрыл. --- Задавайте свои вопросы по выступлению) Тема очень актуальная и животрепещущая) Пётр и Сергей, по возможности, ответят на них)
1 480
18
✨ Пётр Гуринов и Сергей Куприков: Опыт внедрения Lakehouse в компании Лемана Тех. Ссылка на выступление: https://www.youtube.com/watch?v=r70FGQWdEvc&t=950s Сложность: 2/3 (Сложного кода в докладе нет, но требуется понимание архитектуры DWH/DLH) Кому будет интересно: - Вообще всем, кто как-то связан с построением хранилищ данных. DLH это новая реальность, в которую обязательно нужно погрузиться. --- Компания с масштабной инфраструктурой (600 TB в DWH, 1.5 TB в S3) перешла на Lakehouse-архитектуру. Рассказываем, как, зачем и с какими проблемами столкнулись. --- 🔍 Проблемы старой архитектуры - Greenplum (Shared Nothing): - Данные невозможно оторвать от compute - Ограниченная масштабируемость - Высокие затраты на хранение - Pipeline до внедрения DLH: Источники собираются в Kafka. Flink вычитывает данные, складывает их в S3 в формате avro (слой raw). Далее Spark трансфармирует данные в parquet, складывает данные в S3 (слой ods). Оттуда данные попадают в GP, который является единой точкой входа всех сотрудников компании (любой сотрудник магазина может запросить доступ к DWH). --- 🚀 Переход на Lakehouse Требования к новой платформе: ✔️ Open Source ✔️ Разделение compute/storage ✔️ Cloud-ready/cloud agnostic ✔️ Низкий порог входа Выбранный стек: - Вычисления: Trino (поддержка ANSI SQL, активное комьюнити, лицензирование и гетерогенность источников) - Табличный формат: Iceberg (выбирали между Iceberg/Hudi/Delta Lake) - Хранение: S3 - Метаданные: HMS (планы на переход к Nessie для branch-поддержки) --- ⚙️ Реализация: - Кластеры Trino: - Ad hoc (пользователи/BI) - ETL (тех.учетки) - DQ (Data Quality) Интеграция: - Аутентификация через Keycloak + AD - Управление доступом: file-based ACL --- 🛠 Проблемы и решения Ограничения технологий: - Нет коннектора Trino → Greenplum (ходят через Master) - Iceberg: нет мультитранзакций, сложности с типами данных - Trino: нет временных таблиц, legacy spill-файлы 🛠 Мониторинг: - Мониторинг производительности с использованием Prometheus и Grafana. JMX Exporter снимает метрики и преобразует в формат Prometheus. Prometheus operator пушит их в VictoriaMetrics, которые визуализируются в Grafana. -Мониторинг пользовательских запросов из коробки имеет критическое ограничение: после рестарта вся история удаляется. Реализовали мониторинг с использованием Kafka event listener, оттуда пишем в CH и визуализируем в Grafana. Дашборды выложены в opensource: https://github.com/rugratko/grafana-trino-overview-preset - Кастомный сбор метрик запросов через Kafka → ClickHouse 🛠 Управление инфраструктурой: - GitOps + ArgoCD + Vault - Автоматические откаты --- 📊 Результаты ✅ Экономия: - Хранение дешевле в 10+ раз - Быстрое масштабирование в Kubernetes - Независимое масштабирование и отсутствие необходимости резервировать место заранее. ✅ Производительность: - Ускорение расчетов витрин - Легкий переход запросов с GP на Trino - Аналитики получают дополнительную точку входа для доступа к данным - Разные вычислительные движки могут использовать одни и те же данные. --- 🔮 Планы - Замена HMS на Nessie - Продуктивизация SCD2-таблиц - Автоскейлинг Trino на основе метрик - Копирование Iceberg-таблиц в Greenplum - Обслуживание (maintenance) Iceberg таблиц. Пока не актуально, так как сейчас данные append only --- 💡 Вывод: Lakehouse на базе Trino + Iceberg — гибкая альтернатива классическому DWH. Главные преимущества: разделение compute/storage, масштабируемость и экономия.
1 554
19
И приятный бонус. Александра любезно согласилась ответить на Ваши вопросы по докладу про airbyte в комментариях к этому посту)
1 274
20
✨ Александра Попова — Airbyte: 2 года в продакшене Ссылка на выступление: https://youtu.be/fgaBGc3VWWQ?si=jvH4kmqF8lyjc70- или Ссылка на выступление: https://youtu.be/fgaBGc3VWWQ?si=jvH4kmqF8lyjc70- Сложность: 2/3 (Практико-ориентированный доклад, требует базового понимания ETL-процессов) Кому будет интересно: - Архитекторам и простым инженерам, которые понимают, как дотащить данные от источника в хранилище. --- Александра поделилась опытом внедрения и эксплуатации Airbyte в СберЗдоровье с 2022 по 2024 год. Airbyte - один из мощных инструментов modern data stack, очень рекомендую к ознакомлению) --- 🔍 Ключевые моменты внедрения: 1️⃣ Проблемы до Airbyte (2021): - Разнородные скрипты для забора данных - Неэффективное управление ETL-процессами - Отсутствие стандартизации 2️⃣ Выбор Airbyte: - Большое комьюнити и готовые коннекторы - Python CDK для кастомных разработок - Поддержка инкрементальной синхронизации и CDC (на базе Debezium) 3️⃣ Архитектурные особенности: - Микросервисная архитектура (ядро на Java, коннекторы на Python/Java) - Развертывание в Kubernetes с разделением статических/динамических подов --- ⚙️ Функциональность Airbyte: ✔️ Методы синхронизации: - Full refresh - Incremental (с дедупликацией) - CDC (PostgreSQL, MySQL, SQL Server, MongoDB) ✔️ Расписания: - По временному интервалу - Cron (добавлен в 2023) - Ручной запуск --- 🛠 Практический опыт: Проблемы и решения: 1. Отсутствие коннектора к Greenplum → Разработан кастомный коннектор на основе PostgreSQL 2. Потеря точности времени → Переход на CDC для инкрементальных синхронизаций 3. Ограничения UI → Использование API и YAML-конфигов для управления 4. Проблемы с расписанием → Решены в новых версиях airbyte через cron 5. Мониторинг → Настройка через sql-exporter Производительность: - Обработка до 100 ГБ данных - Разделение нагрузки в Kubernetes - Оптимизация через cleanup-политики --- 📊 Текущая архитектура (2024): - Источники: БД (через CDC) и API - Назначения: Greenplum, ClickHouse (с предварительным созданием ReplicatedMergeTree-таблиц) - Оркестрация: Dagster для управления пайплайнами --- 💡 Преимущества Airbyte: ✅ Упрощение ETL-процессов ✅ Готовая поддержка 300+ коннекторов ✅ Гибкость через Python CDK ✅ Удобство мониторинга ⚠️ Ограничения: - Нет встроенного механизма бэкфила - Требует доработок для специфичных случаев - Cloud-функции (ролевая модель) недоступны в open-source --- 🤔 Ответы на вопросы: Q: Почему Airbyte вместо Airflow? A: Готовые коннекторы и унификация процессов Q: Как решается проблема бэкфила? A: Периодической полной перезаписью данных Q: Проблемы с CDC? A: Нет проблем со скоростью репликации Q: Почему не PXF для Greenplum? A: Ограничения ИБ и сложность поддержки --- 📌 Выводы: Airbyte отлично подходит для: - Забора данных из БД и API - Стандартизации ETL-процессов - Быстрого старта с минимальной разработкой Не подходит для: - Стриминговых сценариев - Сложных бэкфил-процессов
1 262