Ссылка на выступление: https://www.youtube.com/watch?v=iNgsyboLpb0
or
https://vk.com/video-147464741_456239346

Сложность: 1/3 Легко и понятно

Кому будет интересно: всем, кто строит или собирается строить платформу данных.

✨ Краткий пересказ и выводы по докладу Максима Стаценко ✨

На конференции Максим Стаценко предложил революционный взгляд на хранение и обработку данных. Он начал с исторической параллели, сравнив эволюцию физики (от Ньютона до Эйнштейна) с необходимостью менять подходы к данным сегодня.

🔍 Основные проблемы:
1️⃣ Устаревшие методы хранения данных — мозг и древние системы уже не справляются с современными объемами.
2️⃣ Сложности в аналитике — задержки в данных, ручные процессы и отсутствие единой культуры аналитики создают хаос.
3️⃣ Проблемы бизнеса — например, в рекламе: клики с задержкой, антифрод-системы, меняющие данные, и отсутствие актуальности для топ-менеджеров.

🚀 Предложенные решения:
- 4 типа API для работы с данными:
- Первое состояние события.
- Последнее состояние.
- Дельта (изменения).
- Актуальное состояние для запросов.
- Автоматизация процессов — минимизация ручного труда и человеческого фактора.
- Идемпотентность — корректная работа с изменениями данных.
- Культура тестирования — написание тестов для данных и покрытие финансовых расчетов мониторингами.

💡 Выводы:
1️⃣ Данные — это живой организм. Они меняются, и нужно уметь с этим работать.
2️⃣ Технологии — это только половина успеха. Важно менять культуру разработки: писать тесты, автоматизировать процессы и договариваться о новых подходах.
3️⃣ Эффективность = гибкость. Новые API и автоматизация позволяют быстрее реагировать на изменения и снижать задержки.

📌 Итог:
Доклад Максима — это не просто про данные, а про новый образ мышления. Чтобы оставаться в тренде, нужно не только внедрять современные технологии, но и менять подходы внутри команд.

Ссылка на выступление: https://www.youtube.com/watch?v=Wi4-RJq5Q1w

Сложность: 2/3 (Есть технические моменты, но в целом понятно)
Кому будет интересно: администраторам баз данных, инженерам данных, архитекторам Data Platform и всем, кто работает с Greenplum. Если с Greenplum не работали, смотреть не рекомендую.

✨ Краткий пересказ и выводы по докладу Дмитрия Немчина (Tinkoff) — Greenplum Worst Practices ✨

Дмитрий Немчин, руководитель команды администраторов бэк-энда хранилища данных Тинькофф, поделился опытом работы с Greenplum и основными ошибками, которые могут возникнуть при его использовании. Greenplum — это мощная MPP-система, построенная на PostgreSQL, но даже у таких технологий есть свои подводные камни. 🌊

🔍 Основные проблемы:
1️⃣ Параллельность и нагрузка:
• Установка большого количества сегментов на мощных машинах приводит к перегрузке CPU и дисков.
• Система становится нестабильной при высокой нагрузке.
2️⃣ Синхронизация метаданных:
• Автосинхронизация через DataGrip создает лишнюю нагрузку на мастер-ноду.
• Это замедляет выполнение обычных запросов.
3️⃣ Распределение данных:
• Неравномерное распределение данных между сегментами вызывает перекосы.
• Это приводит к проблемам с производительностью.
4️⃣ Администрирование:
• Ошибки, такие как удаление данных всех сегментов, могут привести к падению всей базы.
• Важно учитывать особенности Greenplum при администрировании.
5️⃣ Воркфайлы:
• Маленькие воркфайлы занимают много места на диске.
• Требуется правильная настройка параметров для оптимизации.

🚀 Предложенные решения:
• Равномерное распределение данных:
Ключ к стабильной работе Greenplum.
• Отказ от автосинхронизации метаданных:
Снижает нагрузку на мастер-ноду и ускоряет выполнение запросов.
• Регулярная вакуумация:
Помогает избежать проблем с bloating (пустые места после удаления данных).
• Настройка параметров воркфайлов:
Оптимизация использования дискового пространства.
• Ресурсные группы в Greenplum 5:
Гибкое управление нагрузкой и производительностью.

💡 Выводы:
1️⃣ Greenplum — мощный инструмент, но требует внимательной настройки.
Ошибки в администрировании могут дорого обойтись.
2️⃣ Мониторинг и оптимизация — ключевые процессы.
Регулярная вакуумация, анализ статистики и настройка параметров помогают избежать проблем.
3️⃣ Используйте все возможности Greenplum.
Ресурсные группы и улучшенное управление нагрузкой делают систему более гибкой.

📌 Итог:
Доклад Дмитрия — это ценный опыт для всех, кто работает с Greenplum. Чтобы избежать проблем, важно не только знать особенности системы, но и регулярно оптимизировать процессы. А еще — учиться на чужих ошибках, чтобы не наступать на те же грабли. 😉

ORC и Parquet. О форматах и их использовании на базе HDFS / Александр Маркачев (билайн)

Ссылка на выступление:
https://www.youtube.com/watch?v=GM8vEhlBbF8
или
https://vkvideo.ru/video-152308462_456239403
Сложность: 2/3 (Есть технические моменты, но в целом понятно)

Кому будет интересно: Не рекомендую смотреть, если никогда не работали ни с одним их этих форматов.
Если при создании датасетов бездумно указывали parquet или ORC и хотите понять в чём же разница между этими двумя форматами, то must have.

✨ Краткий пересказ и выводы по докладу Александра Маркачева (билайн) — ORC и Parquet: форматы и их использование на базе HDFS ✨
Александр Маркачев рассказал о ключевых аспектах работы с форматами данных ORC и Parquet, их структуре, преимуществах и оптимизации для эффективного хранения и обработки данных на базе HDFS.

🔍 Основные тезисы:
1️⃣ Рост данных и задачи дата-инженеров:
• Объем данных растет экспоненциально: 97 зетабайт данных сейчас и 220 зетабайт ежедневно к 2025 году.
• Задача дата-инженеров — эффективно управлять данными, чтобы экономить место и обеспечивать быстрый доступ.
2️⃣ Основные форматы данных:
• Parquet и ORC — колончатые форматы, подходящие для хранения и быстрого доступа.
• Ключевые метрики качества: степень сжатия и скорость доступа.
3️⃣ Структура файлов:
• Parquet:
◦ Состоит из заголовка, групп строк, участков колонок и страниц.
◦ Заголовок содержит магическое число для идентификации.
◦ Группы строк и колонок позволяют читать данные по частям.
• ORC:
◦ Состоит из заголовка, страйпов, участков колонок, страниц и постскрипта.
◦ Постскрипт содержит метаданные в сжатом виде.
◦ Страйпы аналогичны группам строк в Parquet.
4️⃣ Сравнение форматов:
• Parquet:
◦ Лучше подходит для разработки, так как позволяет менять местами столбцы.
◦ Сжимает хуже, но работает быстрее благодаря более слабым алгоритмам сжатия.
• ORC:
◦ Поддерживает более мощные алгоритмы сжатия, что делает его предпочтительным для долгосрочной аналитики.
◦ Имеет поддержку ACID и спецсимволов.
5️⃣ Оптимизация данных:
• Маленькие таблицы:
◦ Оптимизация не имеет смысла, но отключение индексов и сортировка данных могут ускорить работу.
• Средние таблицы:
◦ Сортировка таблицы уменьшает нагрузку на кластер в три раза.
◦ Выбор меньшего блока данных ускоряет чтение.
• Большие таблицы:
◦ Требуют настройки индексов и использования блум-фильтров для уменьшения объема читаемых данных.

🚀 Рекомендации:
• ORC предпочтителен для долгосрочной аналитики благодаря мощным алгоритмам сжатия и поддержке ACID.
• Parquet лучше подходит для разработки и сценариев, где важна скорость доступа.
• Используйте сортировку данных и настройку индексов для оптимизации производительности.
• Для больших таблиц применяйте блум-фильтры и настраивайте размеры блоков.

💡 Выводы:
1️⃣ ORC vs Parquet:
• ORC лучше сжимает и подходит для аналитики, Parquet быстрее и гибче для разработки.
• Выбор формата зависит от задач: аналитика или разработка.
2️⃣ Оптимизация — ключ к эффективности:
• Сортировка данных, настройка индексов и использование блум-фильтров значительно улучшают производительность.
3️⃣ Spark 3.2 улучшил работу с ORC:
• Новые версии Spark оптимизировали работу с ORC, что увеличило скорость обработки данных.

📌 Итог:
Доклад Александра Маркачева — это отличный гайд по выбору и оптимизации форматов данных. ORC и Parquet — мощные инструменты, но их эффективное использование требует понимания их особенностей и правильной настройки.

Основной вывод из доклада

Apache Flink под капотом: distributed, stateful, realtime

Ссылка на выступление:
https://youtu.be/N0VIhpUf4qM?si=_g23HWZ5x07c-See
или
https://vkvideo.ru/video-147464741_456239315

Сложность: 3/3 (Технически насыщенный доклад, требует понимания Apache Flink и потоковой обработки данных)
Кому будет интересно: Всем, кто работает с Apache Flink или планирует его использовать. Подойдёт для первичного знакомства с Apache Flink.

✨ Краткий пересказ и выводы по докладу Валентины Предтеченской — Apache Flink под капотом: distributed, stateful, realtime ✨
Валентина Предтеченская подробно разобрала внутреннюю работу Apache Flink, фокусируясь на трех ключевых аспектах: распределенность (distributed), управление состоянием (stateful) и обработка в реальном времени (realtime). Доклад был ориентирован на практикующих инженеров, уже знакомых с Flink, и содержал множество технических деталей и примеров.

🔍 Основные тезисы:
1️⃣ Введение в Apache Flink:
• Flink — это фреймворк для распределенной обработки данных в реальном времени.
• Основные компоненты: JobManager, TaskManager, Task Slots.
• Flink решает задачи потоковой аналитики, поиска и рекомендаций.
2️⃣ Распределенный движок:
• Пример задачи: подсчет кликов по объявлениям в реальном времени.
• Использование Kafka для обработки событий.
• Работа с событиями пользователей, такими как клики.
3️⃣ Параллелизм и настройка:
• Параллелизм настраивается эмпирически через нагрузочное тестирование.
• Важно закладывать "запас" для надежности системы.
• Рекомендации по настройке параллелизма для конкретных операторов.
4️⃣ Управление состоянием (Stateful):
• Два типа состояния: HashMapState(в памяти) и RocksDBState (в файловой системе).
• Важно указывать TTL (время жизни) для данных, чтобы избежать неограниченного роста.
• Чекпоинты используются для синхронизации состояния между TaskManager'ами.
5️⃣ Реал-тайм обработка:
• Flink поддерживает два типа времени: Processing Time и Event Time.
• Watermark (ватермарка) — это механизм для отслеживания времени в потоке данных.
• Ватермарка помогает обрабатывать события с задержкой и избегать проблем с событиями из "будущего".
6️⃣ Оптимизация и производительность:
• Chaining (чейнинг) — оптимизация передачи данных между операторами в одном Task'е.
• Rebalance (ребаланс) — перераспределение данных между параллельными задачами.
• Использование Broadcast(бродкаст) для фильтрации данных, например, черных списков IP-адресов.
7️⃣ Проблемы и решения:
• События из будущего: могут нарушить логику обработки. Решение — чинить источник данных или отбрасывать такие события.
• Восстановление состояния: при падении TaskManager'а состояние восстанавливается из чекпоинтов.
• Эволюция состояния: изменение типов данных в состоянии требует осторожности, чтобы не потерять данные.

🚀 Рекомендации:
• Используйте чекпоинты для надежного восстановления состояния.
• Настройте TTL для данных, чтобы избежать неограниченного роста состояния.
• Оптимизируйте передачу данных с помощью чейнинга и ребаланса.
• Внимательно работайте с ватермарками, чтобы корректно обрабатывать задержки и события из "будущего".

💡 Выводы:
1️⃣ Flink — мощный инструмент для потоковой обработки:
• Подходит для задач, требующих низкой задержки и высокой надежности.
• Управление состоянием и чекпоинты делают его устойчивым к сбоям.
2️⃣ Оптимизация — ключ к производительности:
• Правильная настройка параллелизма, чейнинга и ребаланса значительно улучшает производительность.
• Использование ватермарок помогает корректно обрабатывать задержки в данных.
3️⃣ Эволюция состояния требует осторожности:
• Изменение типов данных в состоянии может привести к потере данных, если не спланировано заранее.
• Используйте сейф-пойнты для безопасного обновления логики без остановки стриминга.

📌 Итог:
Доклад Валентины Предтеченской — это глубокий dive в Apache Flink, который поможет инженерам лучше понять, как работает этот фреймворк под капотом. Flink — это не просто инструмент, а целая экосистема, требующая внимательной настройки и понимания внутренних механизмов.