Vertica Eon в K8S — 3 года развития
Vertica — одна из первых широко используемых MPP баз на просторах айти ландшафта СНГ. Колоночное хранение, быстрые запросы на миллиардах строк, легендарные sort-merge джойны, которых нет больше ни у кого, позволяющие запускать свои грибницы. Но нынче на дворе 2024 год: как компания Vertica сменила уже 2 владельцев, доступ к веб ресурсам с территории РФ ограничен, поддержка брошена, а вокруг нас процветают облака или как минимум кубернетисы во всех ипостасях.
И все же начиная с версии 10.1 компания представила интересную возможность для тех, кто уже крепко подсел на эту иглу — движок Eon с запуском в K8S. Описывая в двух словах, это «та же самая по скорости» база данных, но использующая общее хранилище — S3 (во всех своих ипостасях от вендорских AWS, GCS до онпрем вариантов) или HDFS. К тому же есть отличная завлекалочка для новчиков — бесплатное использование кластера размером до 1 ТБ и до 3 нод вычисления. В конце этой статьи я оставляю свое абсолютно субъективное мнение о том, что у этих ребят получилось.
Введение
У нас в компании используется «железный» кластер вертики небольшого размера возрастом около 5 лет. Одна из важных для нас возможностей аналитической базы данных — наличие достаточно «легкой» операции delete, которая открывает возможности реализации CDC из продовых баз данных и простого обновления данных. В дополнение к основному DWH есть шардированный кластер clickhouse небольшого размера, развернутый в k8s через оператор, и потребность в дешевых (идеале бесплатных) аналитических базах данных для хранения изменяемых (update) данных объемом до 1 ТБ для специфичных потоков данных.
Дано: кластер Hadoop на своем железе, кластеры k8s на своем железе.
Хочется: мигрировать старый кластер на новое железо с «резиновым» хранилищем, отказаться от clickhouse и использовать только 1 систему (один диалект SQL, один набор драйверов и утилит) для всей аналитики, уметь поднимать и дешево содержать инстансы под маленькие потоки данных.
Решение: Vertica Eon с общим хранилищем на HDFS и поднятием кластера на k8s cluster/namespace по требованию через оператор, предоставляемый вендором.
Архитектура и обещания
Eon Mode and Enterprise Mode databases have roughly the same performance in the same environment when properly configured.
Enterprise Mode — классическое решение для MPP баз данных, кластер состоит из выделенных серверов, на каждом из которых локально хранятся данные и исполняются запросы. Хранение происходит с заданной избыточностью, распределение по узлам осуществляется по заданному ключу. Не наш выбор.
Enterprise Mode
Eon Mode — используется общее внешнее объектное хранилище и узлы, на которых нет долговременного хранения данных. НО: каждый узел содержит так называемый depot — место для кешировия данных (стандартный размер, заданный в операторе для volume каждого пода, составляет 500 Гб). Данные при поступлении в кластер сначала записываются в depot, а далее отправляются в общее хранилище (такого поведение по стандарту, но можно выключить специальным запросом).
Eon mode
Именно такой архитектурой и объясняется цитата в начале — мы достаем данные из локального хранения что в старом режиме, что в новом распределенном. Больше про архитектуру можно почитать здесь. Вместе с общим хранением мы получаем бонус в виде гибкого масштабирования вычислений под вычислительную нагрузку, более высокую отказоустойчивость и снижение затрат на обслуживание.
Kubernetes в этой истории
Начиная с версии 10.1 компания предоставляет так называемый в документации способ развертывания Containerized Vertica. Он идет отдельно от установки Eon, так как сам движок может запускаться и на выделенных серверах напрямую. В гитхабе проекта идет активная работа, и даже удивительно, что принимают пул реквесты со стороны комьюнити. Повторное удивление вызывает малое количество открытых проблем, а багов и вовсе нет.
Хочется заметить, что после достаточно сложной и подробной документации по установке сервиса руками с командами и прочим — установка кластера через оператор просто божественна по своей простоте и легкости настройки. Но стоит внимательно относится к тем стандартным параметрам, что присутствуют в документации.
Тестовый стенд
Вычислительные ресурсы: кластер состоит из 3 узлов с лимитом на память. Большее в бесплатной версии не допускается (да и не нужно).
Локальное хранилище: в поды подключено full-flash хранилище Pure с высоким приоритетом и ограничением в 20к IOPS.
Сеть: 2×10 гигабитных линка на каждый узел в кластере k8s и кластере hadoop. СХД использует отдельную сеть для подключения к серверам.
Общее хранилище: ванильный кластер Apache Hadoop на 10 серверах.
Версия оператора 2.0.1, версия вертики 24.1
Для тестирования использовался датасет размером примерно в 250 гигабайт и около 3 млрд строк, в качестве фоновой нагрузки использовался онлайн поток мощностью 1000 eps на вставку с частотой сброса раз в минуту. Операции схлопывания потока происходили раз в час — в эти моменты нагрузка становилась вида delete+insert.
Во время тестирования на нодах кластера всегда было свободно больше 50% памяти и процессора, сеть утилизировалась на 10–20%, дисковая подсистема имела достаточный запас производительности. Выявить физические ограничения железа для полученных результатов, к сожалению, не получилось.
А вот и субъективные выводы
When comparing a cloud-based Eon Mode database to an on-premises Enterprise Mode database, performance differences are typically due to the overall performance impact of a shared cloud-based virtual environment compared to on-premises dedicated hardware. An Enterprise Mode database running in the same cloud would have the same performance as the Eon Mode, in most cases.
Выводы относительно запуска вертики в k8s:
лимиты на процессор нежизнеспособны — вертика очень прожорлива до cpu, мы постоянно уходили в тротлинг на обычной вставке данных даже на таком небольшом потоке, что уж говорить до вычислений
лимиты на память, не смотря на наличие их в операторе, применять не стоит. Прогнозировать потребление памяти очень сложно, явно лимиты в вертику не передается — в итоге происходит отстрел подов со стороны k8s
исходя из двух пунктов выше поды придется размещать на выделенных узлах k8s — от такого «шумного» поведения будут страдать соседние сервисы
использование локального хранилища для кеширования и загрузки требует достаточно большого размера volume — не зря по умолчанию в операторе стоит 500Гб. При загрузке данных из hdfs через copy from parquet на малом размере уперлись как раз это ограничение
опция в операторе initPolicy для меня вышла очень непонятной. В случае указания там Create, при первом применения crd будет создан новый кластер в общем хранилище, но после удаления и нового применения оператор не станет создавать кластер с сообщением, что кластер в хранилище уже есть. Для исправления ситуации надо перевести значение в Revive. В каких случаях может понадобиться погасить кластер и развернуть заново -, а тут как раз смотрите пункт выше. Операция изменения размера обычно намного длительнее, чем отключение и включение кластера заново.
из плюсов оператор работает в пределах namespace, и следовательно и кластеры у нас ограничены namespace
Выводы относительно Eon в kubernetes:
на простых запросах с агрегациями проигрыш составлял примерно 3–5 раз по сравнению с Enterprise под нагрузкой
на сложных запросах с агрегациями проигрыш составлял до 10 раз
на сложных запросах-джойнах проигрыш составлял от 5 раз до бесконечности
в случае холодного старта кластера (то есть данные лежат только в HDFS и через кластер они не проходили) проигрыш даже в простых запросах составлял до 50–60 раз
операции вставки, конечно же, минимум в 2–3 раза длительнее (просто из-за пути данных сначала положить локально, а потом закомитить во внешнее хранилище)
Финальным штрихом тестирования стал приход алерта о невозможности выполнить любой запрос на выходных, на время которых кластер был оставлен с фоновой нагрузкой на вставку данных. Произошел упомянутый выше отстрел подов по памяти, и не смотря на успешный рестарт и вроде бы зеленые метрики со стороны системы кластер пришел в полную негодность — запросы зависли в пуле ресурсов, и попытка выполнить любой новый запрос заканчивалась сообщением о нехватке ресурсов в пуле. Помогло пересоздание кластера.
Эпилог
Так как оператор не позволяет разворачивать Enterprise mode в kubernetes, то с результатами нашего тестирования вся прогрессивная работа последних лет в компании Vertica выглядит полностью бесполезной :(Eon слишком медленный, оператор не позволяет разворачивать быструю версию кластера, а отсутствие возможности пробрасывать явно заданные ресурсы в кластер и корректно обрабатывать ООМ ставит крест вообще на любой попытке использовать вертику в k8s. Обидно.
