Пост✨ Татьяна Дидова — Как мы тестировали 5 способов загрузки данных в Greenplum и что из этого вышло

✨ Татьяна Дидова — Как мы тестировали 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