Привет, Хабр! Сегодня расскажем о том, почему и как мы решили мигрировать на Greenplum шестой версии с Greenplum пятой версии. Сразу скажем, что мы каждый день обрабатываем огромное количество данных — шутка ли, у одного из наших клиентов 80 млн пользователей, из которых каждый день активны до 90 тысяч из 178 стран.
Естественно, все эти пользователи генерируют терабайты информации, поэтому обработка этих данных, построение аналитических отчетов и прочие задачи — тот еще челлендж. Сегодня поговорим об аналитике и решении аналитических задач при помощи Greenplum, с описанием перехода с одной версии на другую со всеми сопутствующими задачами, вроде перестройки инфраструктуры.
Зачем нам вообще понадобился Greenplum?
Как и любая более-менее крупная компания, мы многое анализируем. Результаты анализа нужны для оптимизации работы, оценки развития разных продуктов и других задач. В большинстве компаний паттерн построения аналитики строится на получении данных из продуктовых сервисов. Данные нужно не просто получить, а еще и загрузить в хранилище, где проводить анализ данных. Аналитические запросы весьма ресурсоемкие, так что всегда есть риск что-то "уронить" из-за неправильно составленного запроса.
Мы решили отделить аналитические задачи от продуктовых сервисов, с чем отлично справляется Greenplum. Это аналитически распределенная OLAP-СУБД, к тому же, open-source, которая на рынке уже более 16 лет. Ее относительно просто адаптировать под собственную экосистему.
Достоинством Greenplum является еще и то, что продукт использует MPP-архитектуру с полным отсутствием разделяемых данных. Так, есть основной хост, на котором размещается мастер — это инстанс Postgres для обращения пользователей. Кроме того, есть несколько хостов, на каждом из которых располагаются сегменты, тоже инстансы Postgres, но к ним может обращаться лишь мастер.
Поскольку нет разделяемых данных — можно говорить о повышенной отказоустойчивости за счет создания зеркал как мастер-хоста, так и отдельных сегментов.
Еще один огромный плюс Greenplum — совместимость с PostgreSQL. Нам Greenplum понравился как раз благодаря этому, плюс важны были еще несколько моментов:
Кластер (MPP);
Полиморфное хранилище;
Собственный сетевой протокол взаимодействия;
Разграничение ресурсов;
Движок хранения для аналитической нагрузки (OLAP);
AD-HOC аналитика;
Построение отчетов в BI Tableau;
Аудит качества данных платформы;
Онлайн отчеты.
Вот статистические данные по нашему Greenplum:
886 таблиц (не включая партиции);
15 ТБ сжатых данных, 40 TB несжатых данных без индексов;
Индексов в системе на 7 ТБ;
Сбор данных с 40 сервисов/микросервисов компании;
В пике загрузка 27k событий в секунду.
Какое-то время мы работали с пятой версией Greenplum с PostgreSQL 8.3., но затем решили мигрировать на новую версию.
Миграция — почему и зачем
У нас было сразу несколько проблем, связанных с использованием устаревшей версии Greenplum:
Постоянно увеличивалась емкость кластера, ведь платформа растет, количество клиентов увеличивается, растет и объем данных.
В нашей сборке мы не использовали изоляцию ресурсов, такую как ресурсные очереди и ресурсные группы. То есть любой пользователь мог подключиться к нашему кластеру, выполнить любой запрос. Выполнение неоптимизированного запроса занимало большой объем ресурсов, что наносило ущерб работе других пользователей. При переезде на новый кластер стоит спланировать внедрение такого функционала.
Еще один аргумент за миграцию — отсутствие ограничений на размер схемы/таблиц.
И последнее — мы отставали от stable-сборки пятой версии Greenplum на целый год. Тому было несколько причин, но когда назрела необходимость апгрейда, мы решили не "догонять" stable-сборку предыдущей версии, а проапгрейдиться сразу на Greenplum 6.
Схема переезда
Нам удалось совершить бесшовную миграцию, если так можно выразиться. Схема ее выглядит следующим образом:
Сначала устанавливается новый кластер 6 версии Greenplum, выполняется миграция баз данных.
Посредством Greenplum выполняется бэкап таблиц, а также восстановление данных в новый Greenplum.
Запускаются дополнительные инстансы Kafka и запускается загрузка из kafka топиков в Staging таблицы Greenplum.
Пользователей переключают на новый кластер.
Здесь было важно предусмотреть один момент — у нас оставались пользователи, которые выполняли запросы в старой версии Greenplum. Для них мы оставили возможность переключения на старый кластер (временно). Если никаких проблем не возникало, аномалии не замечались, то старый кластер спустя определенное время отключался.
Важнейшей задачей компании был сбор данных для аналитиков из разных источников, включая базы данных микросервисов, приложения, внутреннего транспорта и других источников. Был разработан внутренний механизм, который доставляет данные из источников посредством стриминга. Кроме того, с другой стороны был размещен самописный компонент, который подключается к топикам kafka в виде стрима, берет данные и записывает их при помощи таблиц. Такая схема позволяет масштабироваться горизонтально.
Ну а теперь — о проблемах
Все, что выше, звучит неплохо, правда? Но, естественно, миграция такого уровня не может пройти совсем гладко. Возникло несколько проблем, о которых сейчас и поговорим.
Миграция схемы с 8.3 PG до 9.4 PG требовала ручного вмешательства. Нельзя просто взять и забэкапить все с пятой версии Greenplum и Postgres 8.3 на шестую с Postgress 9.4. Проблема в том, что меняются сами запросы к базе данных, поэтому многое приходилось реализовывать вручную.
Штатные инструменты бэкапирования и восстановления с S3 хранилища давали сбои (10% данных не грузились). На момент миграции у нас было около 800 таблиц, из которых 20-30 — весьма объемные, занимающие несколько терабайт каждая. Их бэкап мог занять 4-5 часов, и уже в конце процесса иногда возникала ошибка с сообщением невалидности данных. В этом случае приходилось либо использовать сторонние (т.е. не штатные) инструменты, либо обращаться к партнерам, которые все дополнительно фиксили.
Как оказалось, шестая версия Greenplum была сыроватой. Поэтому у нас периодически возникали неожиданные ошибки, причину появления которых мы не понимали. Скорее всего, сейчас этой проблемы уже нет. Запросы отваливались по segfault, primary сегменты падали и происходило переключение. Примеры таких багов, которые к моменту написания статьи либо решены, либо в стадии принятия PR.
https://github.com/greenplum-db/gpdb/pull/10273
https://github.com/greenplum-db/gpdb/pull/11538
https://github.com/greenplum-db/gpdb/pull/11894
https://github.com/greenplum-db/gpdb/pull/11988
Консультации с аналитиками. Раньше аналитический отдел выполнял сложнейшие запросы без всякой изоляции ресурсов. Сейчас, после того, как изоляция была внедрена, многие запросы перестали работать, поскольку не были оптимизированы. Первые несколько недель нам пришлось регулярно консультировать аналитиков, разбирая каждый проблемный запрос.
Что в итоге?
В течение нескольких месяцев мы решали возникающие проблемы, переписывали запросы и проводили массу консультаций. Но в итоге добились того, чего хотели изначально:
Стабилизировали работу кластера, теперь не страшно спать по ночам.
Большинство запросов выполняются без проблем, клиенты с разных команд гарантированно получают свой пул ресурсов, практически не влияя на работу друг друга.
Имеем последнюю актуальную версию сборки Greenplum.
Заключили соглашение с консалтинговой компанией, специализирующейся на Greenplum, имеем DBA as Service услугу поддержки, освободили ресурсы для решения других задач.
При миграции на новый кластер и, особенно, на новый мажорный релиз, имеем план Б, чтобы не остаться с единственным нерабочим кластером и злыми аналитиками).
2 базовых совета, если хотите повторить этот путь:
Заложите время на то, что все пойдет не по плану и вы потратите больше времени, чем планировали).
При таких глобальных изменениях в продукте, скорее всего вам придется переписывать запросы, так как план запросов сильно меняется, и это надо тоже учитывать.