🌸 Дорогие девушки! 🌸

Поздравляю вас с 8 Марта! 🎉

Пусть ваши запросы всегда выполняются мгновенно, джойны будут только удачными, а данные — чистыми и структурированными. Пусть в вашей жизни будет столько же радости, сколько строк в крупнейших базах данных, и столько же успешных решений, сколько индексов в оптимизированном запросе!

Будьте вдохновением для мира технологий, ведь именно благодаря вам data-driven будущее становится еще ярче! 💡

С праздником! 💐

В инженерии данных примерно такая же история, или нет? 🫡

🙄 Apache Iceberg vs Delta Lake vs Hudi: выбор формата для AI/ML

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

😕 Почему формат имеет значение?

Традиционные хранилища данных сталкиваются со следующими проблемами:
🔜 Отсутствие транзакций ACID - риск конфликтов чтения/записи
🔜 Отсутствие управления версиями данных — трудно отслеживать изменения
🔜 Медленные запросы — большие наборы данных замедляют аналитику

▶️▶️ Apache Iceberg — решение для аналитики и пакетной обработки

📌 Зачем?

✔️ Обработка исторических наборов данных
✔️ Необходимость оптимизации запросов и развития схемы
✔️ Пакетная обработка является приоритетом

📌 Преимущества

✔️ ACID-транзакции с моментальной изоляцией
✔️ Возможность вернуться в прошлое - восстановление предыдущих версий данных
✔️ Скрытое разделение - ускоряет запросы
✔️ Поддержка Flink, Trino, Presto, Spark ⭐️

📌 Использование

✔️ BI и анализ тенденций
✔️ Хранение данных для обучения модели машинного обучения
✔️ Логи аудита и сценарии отката

▶️▶️ Delta Lake — решение для рабочих нагрузок, связанных с AI, ML и потоковыми данными

📌 Зачем?

✔️ Потоковая передача данных имеет решающее значение для ML
✔️ Нужны настоящие транзакции ACID
✔️ Работа в основном с Apache Spark ⭐️

📌 Преимущества

✔️ Глубокая интеграция со Spark ⭐️
✔️ Инкрементальные обновления (позволяют избежать полной перезаписи набора данных)
✔️ Z-Ordering – группирует похожие данные для более быстрых запросов
✔️ Возможности отката и восстановления

📌 Использование

✔️ Конвейеры машинного обучения в реальном времени (обнаружение мошенничества, прогнозная аналитика)
✔️ Рабочие процессы ETL
✔️ Обработка данных IoT и логи

▶️▶️ Apache Hudi — решение для обновлений в реальном времени

📌 Зачем?

✔️ Необходимость быстрой аналитики в реальном времени
✔️ Данные нуждаются в частых обновлениях
✔️ Работа с Apache Flink, Spark ⭐️ или Kafka

📌 Преимущества

✔️ Транзакции ACID и управление версиями
✔️ Слияние при чтении (MoR) – обновление без перезаписи целых наборов данных
✔️ Оптимизировано для машинного обучения в реальном времени (обнаружение мошенничества, рекомендации)
✔️ Поддержка микро-пакетирования и потоковой передачи

📌 Использование

✔️Обнаружение мошенничества (банковские операции, мониторинг безопасности)
✔️ Рекомендательные системы (электронная коммерция, стриминговые сервисы)
✔️ AdTech (торги в реальном времени, персонализированная реклама)

🧐 Какой формат лучше всего подходит для AI/ML?

😀 Iceberg — для исторических данных и бизнес-аналитики
😀 Delta Lake — для AI/ML, потоковой передачи и Apache Spark ⭐️
✔️ Hudi — для частых обновлений и машинного обучения в реальном времени (обнаружение мошенничества, рекомендации, AdTech)

🔜 Полный обзор можно найти в статье по ссылке

📊 Как избежать хаоса с данными?
Способы обеспечения согласованности показателей в хранилище

Если ты работаешь с аналитикой, ты, вероятно, сталкивался с ситуацией, когда один и та же метрика рассчитывается по-разному в разных отделах. Это приводит к путанице, снижает доверие к данным и замедляет процесс принятия решений. Расскажу основные причины этой проблемы и два эффективных варианта решения.

🧐 Почему показатели расходятся?
Причина кроется в спонтанном росте аналитики:
🔘 Аналитик пишет SQL-запрос для расчёта метрики.
🔘 Затем другие команды создают свои собственные версии на основе этого запроса, внося незначительные изменения.
🔘 Со временем возникают расхождения, и команда аналитики тратит всё больше и больше времени на устранение несоответствий.

Чтобы избежать такой ситуации, стоит внедрить единые стандарты управления метриками.

✏️ Два подхода к обеспечению согласованности

▶️▶️Семантический слой
Это промежуточный слой между данными и инструментами аналитики, где метрики определяются централизованно. Они хранятся в статических файлах (например, YAML) и используются для автоматической генерации SQL-запросов.

🙂 Плюсы:
✔️ Гибкость — адаптируется к различным запросам без предварительного создания таблиц.
✔️ Прозрачность — единые определения доступны для всех команд.
✔️ Актуальность — данные обновляются в режиме реального времени.

🙄 Минусы:
✖️ Требует инвестиций в инфраструктуру и оптимизацию.
✖️ Может увеличить нагрузку на вычисления (это ты сможешь решить с помощью кэширования).

📌 Пример инструмента: Cube.js - одно из немногих зрелых open-source решений.

▶️▶️Предварительно агрегированные таблицы
Здесь заранее создаются таблицы с предварительно вычисленными метриками и фиксированными измерениями.

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

🙄 Минусы:
✖️ Сложно поддерживать по мере увеличения количества пользователей.
✖️ Возможны расхождения, если метрики определены в разных таблицах.

😎 Какой метод выбрать?
Оптимальный подход - гибридное использование:
🔘 Реализуй семантический слой для масштабируемости.
🔘 Используй предварительно агрегированные таблицы для критических показателей, где важна минимальная стоимость вычислений.

#de #engineering #chaos