GREENPLUM ЧТО ЗА ЗВЕРЬ И КАК ЕГО ПРИРУЧИТЬ / ДМИТРИЙ ПАВЛОВ

• Приветствие от Романа Пономарева и Дмитрия Павлова.  

• Дмитрий Павлов - руководитель по развитию дата-платформы в Яндекс Клауд и админ сообщества Greenplum в России.  

• Тема обсуждения: Greenplum и его использование.  

• Дмитрий Павлов рассказывает о своем опыте работы с Greenplum.  

• Работал в государственном ведомстве, банке Тинькофф и компании Арена Дата.  

• С 2020 года возглавляет платформу хранилищ данных в Яндекс Облаке.  

• Greenplum - массивно-параллельная система.  

• Различие между честными и нечестными MPP архитектурами.  

• Greenplum как пример честной MPP архитектуры.  

• Теоретически неограниченная горизонтальная масштабируемость.  

• Линейный рост производительности при добавлении серверов.  

• Высокая отказоустойчивость и возможность обслуживания запросов при выходе из строя половины кластера.  

• Greenplum подходит для сложных запросов с небольшим количеством параллельных запросов.  

• Используется в сценариях дата-хаусов и загрузки данных.  

• Не подходит для большого количества параллельных простых запросов.  

• Эффективное выполнение JOIN-операций локально и распределенно.  

• Три типа индексов и возможность решения задач дата-сайнс внутри СУБД.  

• Поддержка аналитических функций на пяти процедурных языках.  

• Гримплам подходит для аналитиков, которые хотят работать с данными вручную.  

• Он не делает предварительных оптимизаций, что обеспечивает честность производительности.  

• Гримплам выглядит как PostgreSQL сервис для пользователей.  

• Гримплам состоит из мастер-сегмента и сегментов.  

• Мастер-сегмент принимает входящие подключения и транслирует их на сегменты.  

• Сегменты обрабатывают запросы, а их зеркала обеспечивают реплику данных.  

• Гримплам реализует трехфазный коммит через синхронную репликацию.  

• Мастер-инстанс ожидает подтверждения от всех сегментов и рапортует клиенту.  

• Все средства работы с PostgreSQL работают с Гримпламом из коробки.  

• Некоторые средства, такие как Debiver и SAS, понимают структуру таблиц Гримплама.  

• Гримплам поддерживает транзакции и антиспам, что важно для строгих систем.  

• Он имеет несколько уровней изоляции транзакций и поддерживает несколько способов обращения к себе.  

• Платформенный фреймворк позволяет расширять возможности Гримплама.  

• Он включает логические сегменты и сервис Pyx, управляемый мастером.  

• Платформенный фреймворк поддерживает плагины для связи с внешними системами, такими как HDFS и HBase.  

• Платформенный фреймворк позволяет параллелить запросы на основе логических сегментов и сегмент-серверов.  

• В кластере Гримплама может быть несколько сегмент-серверов, что обеспечивает параллельность на уровне всего кластера.  

• Гримплам поддерживает внешние таблицы для работы с различными системами.  

• Взаимодействие кластер-кластер позволяет масштабировать систему при росте данных.  

• Позиционирование и шардирование помогают оптимизировать производительность.  

• Позиционирование позволяет нарезать таблицы на партиции для оптимизации доступа.  

• Шардирование делит таблицу на сегменты для повышения производительности.  

• Гримплам позволяет комбинировать типы хранения данных для разных партиций.  

• Схемы хранения с сжатием позволяют управлять уровнем сжатия и типом хранения.  

• Объединение внешних данных и позиционирования улучшает производительность.  

• Разные партиции могут храниться в разных системах для оптимизации затрат и доступа.  

• Условия по ключу позиционирования позволяют сканировать только нужные партиции.  

• Условия из корневого запроса могут быть переданы во внешнюю систему для фильтрации.  

• Пример использования: загрузка данных из Sabana в Гримплам для анализа чеков.  

• Использование пушдауна в Гримпламе позволяет фильтровать данные по дате.  

• Это сокращает время загрузки данных с нескольких часов до нескольких минут.  

• Пример: загрузка данных из Sabana сократилась с пяти терабайт до трехсот гигабайт.  

• Рекомендуется использовать механизм выгрузки в Griplam для построения решений.  

• Griplam гибкий и масштабируемый, подходит для больших объемов данных.  

• Встроенные процедурные языки: Python, R, Java, Perl, C.  

• Python часто используется в Griplam, аналогично PostgreSQL.  

• Функции на Python распараллеливаются на все сегменты кластера.  

• Возможность создания сложных структур функций, включая сегментные, мастер и финальные функции.  

• Возможность комбинирования разных языков в одной агрегативной функции.  

• Функции упаковываются в SQL-функции, что упрощает использование для аналитиков.  

• Пример использования Python для машинного обучения и применения моделей.  

• Пример задачи по предсказанию оценок ресторанов на основе отзывов.  

• Использование Python-пакетов для обучения и применения моделей.  

• Все функции упакованы в SQL-функции для удобства использования аналитиками.  

• Библиотека Madlib от университета Беркли предоставляет методы матстатистики и машинного обучения.  

• Поддержка Griplam делает Madlib более удобной и быстрой.  

• Возможность использования специализированных функций на Python для сложных задач.  

• Важность разграничения ресурсов между пользователями в больших системах.  

• Использование механизмов ресурсной очереди и ресурсной группы.  

• Рекомендация использовать ресурсную группу вместо старой очереди.  

• Возможность ограничения ресурсов по CPU, памяти и cost.  

• Изменение CPU в реальном времени, в отличие от памяти.  

• Оптимизатор запросов в СУБД, который выбирает оптимальный путь выполнения запроса.  

• Возможность ограничения запросов по сложности, например, по количеству попугаев.  

• Пример с финансовым директором, которому всегда должны быть доступны ресурсы.  

• Жесткая привязка ядер к пользователям для гарантированного выполнения запросов.  

• Ограничение дискового пространства для пользователей и групп.  

• Ограничение количества параллельных запросов для пользователей.  

• Возможность выполнения кода в Docker-контейнерах для повышения безопасности и производительности.  

• Ограничение функций, выполняемых в Docker-контейнерах, для суперпользователей.  

• Механизм поднятия контейнеров на каждом сегменте для выполнения кода.  

• Возможность ограничения ресурсов для Docker-контейнеров, таких как CPU и память.  

• Компрессия важна для аналитических СУБД, особенно для SSD.  

• Используется тип компрессии ZSTD, разработанный Facebook в 2015 году.  

• ZSTD сжимает данные лучше и быстрее, чем ZCLIP.  

• Ран кодинг позволяет хранить дельты между строками, что особенно эффективно для таблиц с повторяющимися значениями.  

• Ран кодинг сжимает данные в десятки и сотни раз, но уровень сжатия непредсказуем.  

• Компрессию можно применять как ко всей таблице, так и к отдельным колонкам.  

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

• Безопасность в Greenplum аналогична другим СУБД: группы, роли, наследование.  

• Можно использовать LDAP, Active Directory, Kerberos и другие системы.  

• Рекомендуется использовать Role Security через VIEWS, а не через встроенные функции.  

• Greenplum не подходит для задач, требующих большого количества однообразных запросов.  

• Greenplum лучше использовать для аналитических задач с небольшим количеством пользователей.  

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

• Greenplum требует правильной подготовки оборудования, сети и операционной системы.  

• Важно читать документацию и использовать опыт сообщества.  

• Неправильная настройка может привести к проблемам в production.  

• В Greenplum нужно мониторить множество метрик, включая CPU, память, диски и сеть.  

• Важно следить за состоянием вор-раунда и ресурсными группами.  

• Рекомендуется хранить метрики вечно для долгосрочного анализа производительности системы.  

• Настраивайте алерты для базы данных и реагируйте на них.  

• Для правильного мониторинга нужен опыт работы с Greenplum.  

• Бэкапы обязательны, даже при наличии двух кластеров и двух экземпляров СУБД.  

• Проверяйте бэкапы после создания, чтобы быть уверенными в их работоспособности.  

• Бэкапы помогают перемещать данные между средами и обновлять их.  

• Бэкапы полезны для обновления деф среды из прода и наоборот.  

• Greenplum масштабируется горизонтально, что важно для роста бизнеса.  

• Подготовка к расширению включает закупку серверов, подготовку места и коммутаторов.  

• В версии 6.0 Greenplum не требует перезапуска при добавлении новых серверов.  

• Рекомендуется снижать нагрузку на СУБД во время расширения для предотвращения проблем.  

• Greenplum поддерживает различные схемы хранения данных, включая звезду и снежинку.  

• Анкор-моделинг пока не поддерживается, но будет в версии 7.  

• Три правила для повышения производительности: выбор ключей распределения, использование колоночного хранения и сжатие данных.  

• Позиционирование по дате и другим полям улучшает производительность.  

• Ремплам система гибкая, открытая и популярная.  

• Требует экспертизы, поэтому Яндекс.Облако предлагает сервис для работы с Ремпламом.  

• Сервис позволяет быстро начать работу с Ремпламом, фокусируясь на моделях данных и обработке запросов.  

• Выбор уровня и поколения CPU.  

• Настройка характеристик серверов и мастер серверов.  

• Рекомендация локальных SSD для продакшена, Network SSD для тестирования и Dev.  

• Ремплам лучше работает на выделенных серверах.  

• В облаке Яндекс.Облако используются Dedicated Hosts.  

• Dedicated Hosts обеспечивают высокую производительность и надежность.  

• Мониторинг системных и метрик Ремплама.  

• Возможность создания графиков и алертов.  

• Интеграция с бизнес-пользователями через сервис TIBCO.  

• CDC позволяет обновлять данные с минимальной задержкой.  

• Обращение к логам вместо баз данных снижает нагрузку.  

• Яндекс.Облако предоставляет сервис CDC из коробки.  

• Проблемы с загрузкой данных напрямую из баз.  

• Подход CDC решает эти проблемы, снижая нагрузку на базы.  

• Яндекс.Облако предлагает решение CDC из коробки, что упрощает эксплуатацию.  

• Бэкапы в Greenplum из коробки сделаны плохо и неэффективно.  

• Используются процедуры pg_dump, что создает большую нагрузку на базу данных и блокировки.  

• Изменения в таблицах несовместимы с выполнением бэкапов, что создает проблемы для больших инсталляций.  

• В облаке Greenplum бэкапы делаются на уровне row-level logs, что не блокирует таблицы и не нагружает базу данных.  

• Возможность создания тестовых кластеров из бэкапов.  

• Greenplum является частью экосистемы, включающей хранилище данных и другие сервисы.  

• Greenplum используется для хранения данных и аналитики в крупных компаниях, таких как М.Видео и Эльдорадо.  

• Данные могут храниться в Greenplum или промежуточном хранилище для надежности.  

• Greenplum интегрируется с другими сервисами, такими как Hadoop и DataLens.  

• В России более 40 компаний используют Greenplum в продуктовых и околопродуктовых проектах.  

• Основные пользователи: финтех и ритейл.  

• Рекомендация использовать чат в Telegram и бесплатный сервис для тестирования Greenplum.  

• Tarantool поставляется с оборудованием и имеет тонкие оптимизации на уровне железа.  

• Greenplum медленнее, но работает на любом железе и в облаках.  

• Tarantool дороже и требует специализированного оборудования.  

• В Greenplum были случаи, когда системные администраторы по ошибке обесточивали систему, что приводило к сбоям.  

• В версии 5.0 были проблемы с переключением сегментов, которые были исправлены в версии 6.0.  

• Основные проблемы связаны с сетью, а не с железом.  

• Greenplum подходит для сложной аналитики и консистентных данных.  

• ClickHouse ориентирован на большое количество пользователей и простую аналитику.  

• Greenplum и ClickHouse дополняют друг друга, позволяя рассчитывать витрины и предоставлять доступ к данным.  

• Бэкап в Greenplum теоретически не может быть сломан пользователем.  

• Проблемы могут возникнуть из-за поломок сегментов или сетевых отказов.  

• В Greenplum 6 многие проблемы были исправлены.  

• Кривые объекты могут создавать проблемы с бэкапом.  

• Пользователь не может создать такие объекты без админских прав.  

• Утилита GP First сканирует консистентность каталога перед бэкапом.  

• Greenplum копирует Tarantool, но с меньшим количеством оптимизаций.  

• Tarantool быстрее на единицу ресурсов, но дороже.  

• Greenplum может быть дешевле на единицу доллара за счет большего количества вычислительных ресурсов.  

• Вертика и Greenplum сравнимы по производительности.  

• Вертика выигрывает на проекциях, но Greenplum можно адаптировать для аналогичных задач.  

• Вертика дорогая система, но Greenplum может быть дешевле в облаке.  

• Рекомендуется использовать одну базу данных в кластере Greenplum.  

• Разграничение прав и ресурсных групп может заменить разделение на разные базы.  

• Для обмена данными можно использовать PQ, GPS-диск или PTS-3.  

• Физически ограничений на количество партиций нет, но рекомендуется не более тысячи.  

• Изменение таблицы с большим количеством партиций будет сложным.  

• Лучше использовать разные периоды для партиций для разных лет.  

• В Greenplum есть механизм транзакционности для обновления партиций.  

• Можно заморозить таблицу и перераспределить партиции.  

• Пользователь не получит битые данные благодаря транзакционности.  

• Были проблемы с загрузкой данных в Greenplum.  

• Появился драйвер для Spark, который может решить проблему.  

• Для тех, кто не хочет платить за поддержку, есть альтернативные методы загрузки данных.  

• Существует множество механизмов для работы с данными, в зависимости от их источника.  

• Для работы с HD-FS рекомендуется использовать нативный гримплановский S3.  

• Для данных, генерируемых программами, можно использовать GPS-диск.  

• В случае с Parquet можно использовать обычную ставку Sparc.  

• Для больших объемов данных можно использовать мастер-инсерт.  

• Для больших объемов данных можно использовать Kafka и Kafka Connector.  

• Kafka Connector работает шардированно и параллельно.  

• Для синхронизации данных можно использовать Datastream или самостоятельно.  

• Опыт использования различных уровней сжатия в Greenplum показал, что лучше использовать первый уровень.  

• Внешние файловые системы, такие как S3, могут быть более эффективными для хранения холодных данных.  

• Для доступа к старым данным можно использовать внешние файловые системы и перекладывать данные в Greenplum.  

• Механизм pushdown работает только по полям и партийциям в Hive.  

• В будущем ожидается переход на использование S3 и других движков поверх S3.  

• В Яндексе планируют прозрачную интеграцию с S3 на уровне таблиц Greenplum.  

• Важно проверять корректность бэкапов, восстанавливая их периодически.  

• Бэкапы проверяются на четность и контрольные суммы.  

• Восстановление бэкапов должно быть регулярным, чтобы избежать проблем с логикой восстановления.  

• Greenplum подходит для дата сайнс, но требует выгрузки данных для тренировок алгоритмов.  

• Для этого можно использовать различные методы, включая мастер-инсерт и Kafka.  

• Модели можно обучать вне Гримплама и использовать их в системе.  

• Это удобно для разработчиков, которые могут обучать модели на ходу.  

• Пользователи могут использовать обученные модели через API, не зная Python.  

• В М-Видео нет прямого запуска Python в Гримпламе.  

• Все данные выгружаются и обрабатываются вне системы.  

• Автовакуум в Гримпламе отсутствует, его нужно делать вручную.  

• Колонночные таблицы требуют VACUUM для корректной работы.  

• VACUUM создает две таблицы: строковую и карту видимости.  

• Рекомендуется изучать первоисточники для более глубокого понимания.  

• В Яндексе есть механизм репликации данных на другой кластер.  

• Механизм основан на бэкапах и инкрементах.  

• Репликация Гримплам-Гримплам появится позже, но пока используется репликация Гримплам-хаус.  

• Переключение нагрузки возможно, но требует обсуждения с командой.  

• Используется пулер соединений Odysseus для отслеживания здоровья кластера.  

• Проблемы с пулерами могут быть решены, но требуют внимания.  

• Мониторинг разрабатывается с нуля и будет развиваться как средство мониторинга.  

• Параллельно развивается направление перф диаг для улучшения запросов.  

• Мониторинг будет развиваться как средство мониторинга, но не как средство перф диаг.  

• GCP Performance Monitoring собирает метрики кластера и историю запросов.  

• Конфликтует с мониторингом готовых дистрибутивов, что вызывает сложности.  

• Технология GCP Performance Monitoring не оптимальна и может снижать производительность базы данных.  

• Планируется развитие автоматического сбора статистики и вакуума.  

• В PostgreSQL можно указать окно обслуживания для вакуума и анализа.  

• В первой версии GCP планируется более интеллектуальный подход к сбору статистики.  

• В GCP есть проблемы с вакуумом, особенно для временных объектов.  

• Вакуум не успевал пробегать по всей базе, что приводило к проблемам.  

• В компании X5 Tech также столкнулись с подобными проблемами.  

• Опыт миграции данных и расчетов на GCP есть, но это делалось через импорт-экспорт.  

• Для небольших или регламентных выгрузок можно использовать Peek.  

• GCP совместим с Tridata и имеет BC драйвер.  

• Peek используется как основной инструмент интеграции.  

• Проблемы с мониторингом работы Peek, но есть возможность использовать блок Fugue.  

• В Яндексе также планируют развивать мониторинг Peek.  

• Благодарность за участие в вебинаре и приглашение к использованию GCP.  

• Возможность бесплатного тестирования до января.  

• Фокус на корпоративных клиентах и помощь в реальных задачах.