мрр субд что это
Мрр субд что это
Сегодня поговорим про достоинства и недостатки массово-параллельной архитектуры для хранения и аналитической обработки больших данных, рассмотрев Greenplum и Arenadata DB. Читайте в нашей статье, что такое MPP-СУБД, где и как это применяется, чем полезны эти Big Data решения и с какими проблемами можно столкнуться при их практическом использовании.
Что MPP-СУБД и как это работает
Особенностью массово-параллельная архитектура (Massive parallel processing, MPP) является физическое разделение памяти узлов, объединенных в кластер [1]. В случае MPP-СУБД каждый узел кластера работает со только своими жесткими дисками, распараллеливая операции чтения и записи данных. После того, как каждый из узлов закончит свои вычисления и отсортирует их в нужном порядке, ему нужно получить необходимые данные от остальных серверов. Для этого каждый узел отправляет свою порцию данных на все остальные сервера по быстрой обособленной сети (interconnect). Поскольку информация уже отсортирована, то на каждом узле при получении данных происходит отбор только тех записей, которые нужны для обработки, а остальные сразу отсеиваются и не занимают места в оперативной памяти. В итоге чтение с жестких дисков происходит быстрее, обработка результатов — тоже, и общее суммарное время выполнения операции оказывается в 10-100 раз меньше, чем в традиционных СУБД [2].
Несмотря на такие оптимистичные показатели скорости, MPP-СУБД не предназначена для быстрой обработки индивидуальных транзакций, как, например, OLTP-система. К примеру, запись данных в MPP-базу происходит вовсе не мгновенно, а представляет собой последовательность целую шагов [3]:
Таким образом, массивно-параллельные СУБД предназначены для хранения и обработки больших объемов данных (до сотен ТБ), а не для оперативных транзакций и быстрого построения аналитических отчетов, как, например, колоночные базы Arenadata QuickMarts и ClickHouse, о которых мы писали здесь.
Типовая архитектура MPP-СУБД
Где и как используются массивно-параллельные базы данных в Big Data
На практике MPP-системы широко используются в области Big Data для предиктивной аналитики, регулярной отчетности и построения корпоративных хранилищ данных (КХД). В частности, построение аналитических моделей оттока клиентов (Churn Rate) – один из типовых вариантов применения MPP-СУБД [4]. Поэтому массивно-параллельные системы особенно востребованы в сфере торговли, где требуется анализировать большие объемы данных, например, сведения о товарах, клиентах и контрагентах, чеки и другая торговая информация. Именно поэтому крупный отечественный ритейлер X5 Retail Group выбрал MPP-СУБД Arenadata DB в качестве основы для своей распределенной аналитической платформы [5].
В свою очередь, Arenadata DB представляет собой коммерческий дистрибутив другого open-source проекта – распределенной СУБД для корпоративного сектора Greenplum. Сама система Greenplum базируется на свободной объектно-реляционной базе PostgreSQL с возможностью горизонтального масштабирования и столбцовым хранением данных, которое повышает эффективность их сжатия и снижает трафик для выполнения запросов [6]. Несмотря на open-source статус, Greenplum очень широко распространена в сегменте enterprise. Например, Тинькофф банк использует эту MPP-СУБД в качестве ядра для своего КХД [7].
Разумеется, Arenadata DB и Greenplum – не единственные представители систем MPP-класса на рынке Big Data СУБД. Среди проприетарных (и дорогих) систем наиболее известными считаются решения от Vertica, Teradata и Netezza [4]. К примеру, банк ВТБ построил свое КХД именно на Teradata, интегрировав ее с Apache Hadoop для распределенных вычислений [8].
Достоинства и недостатки массово-параллельной архитектуры
С учетом вышеописанных особенностей MPP-архитектуры, отметим ее основные преимущества для аналитических СУБД с позиции Big Data [9]:
Обратной стороной этих достоинств являются следующие недостатки:
Эти недостатки устраняются ведорами по мере развития MPP-систем. В частности, 6-ая версия Greenplum, вышедшая в конце 2019 года, позволяет оптимизировать распределение сегментов с помощью алгоритма consistent hashing. Он разрешает перераспределять только часть блоков при добавлении новых узлов в кластер, ускоряя фоновое перераспределение таблиц [9]. Что такое сегмент в кластере Greenplum и какие особенности эта архитектура накладывает на его использование, мы рассмотрим в следующей статье.
А практические навыки по администрированию и эксплуатации MPP-СУБД для эффективного хранения и аналитики больших данных вы получите на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
BI-cube
Эффективность и производительность BI
В чем разница между MPP и традиционными СУБД?
Часто приходится выслушивать комментарии по поводу того, что «как это так, что СУБД на основе MPP (massive parallel processing) работают настолько быстрее обычных СУБД? У нас же тут самая суперсовременная СХД и супербыстрый сервер с огромным количеством памяти».
Объяснение всему этому очень простое. Рассмотрим простой запрос — что-то типа такого:
select sum(f.amount), c.lastname
from transaction_fact f, customer c
where f.date between ’03/01/2013′ and ’03/31/2013′ and f.customerid = c.id
group by c.lastname
То есть, считаем сумму транзакций по каждому клиенту за период в один месяц и объединяем их по категориям клиентов.
Понятно, что если у нас 100 транзакций в месяц и 200 клиентов, то все будет работать быстро. А если 100 миллионов клиентов и 50 миллионов транзакций?
Вот тут начинается самое интересное. Как работает традиционная СУБД? Начитывает (через один, максимум два канала к СХД) все эти 50 миллионов транзакций и начинает производить вычисления. И, поскольку еще и существует связка по клиентам, то происходит чтение клиентов — и более быстрым с точки зрения СУБД будет использование HASH JOIN — то есть, прочитаются все 100 миллионов клиентов, отсортируются по ID, а потом произойдет выборка по lastname. Почему HASH JOIN, а не NESTED LOOP? Потому, что ходить 50 миллионов раз сначала по индексу, а потом по этому индексу читать запись из таблицы будет заведомо гораздо дольше, чем прочитать сразу всех клиентов и отсортировать.
Конечно, если количество разных клиентов за месяц было не очень большим, то, возможно, NESTED LOOP может оказаться быстрее, но… Во-первых, такая ситуация достаточно маловероятна, а во-вторых, как оценить это «не очень большим», чтобы оценить выгоду одного или другого метода? И, в-третьих, это же еще надо всю статистику правильно собрать, чтобы сделать правильный выбор. В данном случае, эти рассуждения только показывают трудности, с которыми приходится сталкиваться традиционным СУБД. Еще нужно принимать правильные решения: какие данные оставлять в кэше на сервере, какие из него удалять, и т.д.
В итоге, что мы имеем — чтение всех 50 миллионов транзакций и всех 100 миллионов клиентов, сортировка всех клиентов по ID, а потом еще и расчет по всем этим 50 миллионам транзакций с группировкой (которая, естественно, тоже операция весьма дорогая, потому что нужно опять отсортировать результат, хотя и слегка меньшего размера, скажем, в 5 миллионов записей — если считать, что в среднем клиент совершил примерно по 10 транзакций в месяц, но зато уже надо отсортировать по другому полю — по lastname). Очевидно, что все эти чтения с одного, пусть и быстрого, СХД, и разнообразные сортировки и группировки могут быть весьма дорогими и длительными операциями.
Что же происходит в MPP системах?
Рассмотрим простую MPP систему с 16 узлами (это, фактически, минимальная конфигурация для MPP систем). Делает эта MPP система абсолютно то же самое, что и традиционная СУБД — читает все 50 миллионов транзакций и 100 миллионов клиентов, но…
Каждый из этих 16 узлов работает со своими выделенными дисками, то есть чтение этих записей происходит в параллель. Кроме этого, каждый из этих узлов, соответственно, читает в 16 раз меньше записей — приблизительно, по 3 миллиона транзакций. После того, как прочитаны эти транзакции, начинается чтение клиентов, и клиенты читаются, соответственно, тоже в 16 независимых потоков — то есть, приблизительно, по 6 миллионов записей на каждый узел. Дальше еще интереснее. Очевидно, что отсортировать 6 миллионов записей гораздо быстрее, чем 100 миллионов. Каждый узел сортирует свою порцию клиентских записей, а заодно и свою порцию транзакций — по полю customerid.
Поскольку каждый узел должен сделать свою часть вычислений, то ему нужно получить необходимые данные по клиентам со всех остальных узлов — каждый узел начинает посылать свою порцию на все остальные узлы. Но это уже происходит по быстрой сети (interconnect), и, поскольку данные в каждом узле уже отсортированы, то на каждом узле при получении данных происходит отбор только тех записей, которые нужны для обработки существующих данных, а остальные сразу отсеиваются и не занимают места в оперативной памяти.
То есть, в итоге каждый узел так и работает со своими 3 миллионами записей, делает необходимые расчеты, сортирует результат и возвращает его, скажем, на один узел, который уже собирает результат и возвращает его клиенту. Поскольку записи уже возвращаются отсортированными, то результирующий узел только и должен, что проверить, есть ли у него уже записи с таким lastname, и добавляет туда, если нужно, результаты, пришедшие с других узлов.
В итоге — чтение с дисков происходит в разы быстрее, обработка результатов — тоже, и суммарное время выполнения операции оказывается в десятки, а то и в сотни раз быстрее, чем в традиционных СУБД.
Из нагруженной MPP СУБД — бодрый Data Lake с аналитическими инструментами: делимся подробностями создания
Все организации, которые имеют хоть какое-то отношение к данным, рано или поздно сталкиваются с вопросом хранения реляционных и неструктурированных баз. Непросто найти одновременно удобный, эффективный и недорогой подход к этой проблеме. А еще сделать так, чтобы на данных смогли успешно работать дата-сайентисты с моделями машинного обучения. У нас получилось – и хотя пришлось повозиться, итоговый профит оказался даже больше ожидаемого. Обо всех подробностях расскажем ниже.
Со временем в любом банке скапливаются невероятные объемы корпоративных данных. Сравнимое количество хранится только в интернет-компаниях и телекоме. Так сложилось из-за высоких требований регулирующих органов. Эти данные без дела не лежат — руководители финансовых учреждений давно придумали, как извлечь из этого прибыль.
У нас все началось с управленческой и финансовой отчетности. На основе этих данных научились принимать бизнес-решения. Часто возникала необходимость получить данные из нескольких информационных систем банка, для чего мы создали сводные базы данных и системы подготовки отчетности. Из этого постепенно сформировалось то, что сейчас называется хранилищем данных. Вскоре на основе этого хранилища заработали и другие наши системы:
Примерно к такой ситуации мы пришли два-три года назад. На тот момент у нас имелось хранилище на базе MPP СУБД Teradata с использованием ELT-инструмента SAS Data Integration Studio. Это хранилище мы строили с 2011 года вместе с компанией Glowbyte Consulting. В него интегрировали более 15 крупных банковских систем и при этом накопили достаточный объем данных для внедрения и развития аналитических приложений. Кстати, как раз в это время объем данных в основных слоях хранилища из-за множества разных задач начал расти нелинейно, а продвинутая клиентская аналитика стала одним из основных направлений развития банка. Да и наши дата-сайентисты горели желанием поддержать ее. В общем, для построения Data Research Platform звезды сложились как надо.
Планируем решение
Здесь надо пояснить: промышленные ПО и сервера – дорогое удовольствие даже для крупного банка. Далеко не каждая организация может позволить себе хранение большого объема данных в топовых MPP СУБД. Всегда приходится делать выбор между ценой и скоростью, надежностью и объемом.
Чтобы по максимуму использовать имеющиеся возможности, решили поступить вот так:
Так как нашей основной задачей было все-таки хранение структурированных больших данных, то в стеке Hadoop нас интересовали решения, максимально близкие к классическим SQL СУБД. Лидерами здесь являются Impala и Hive. Cloudera развивает и интегрирует решения Impala, Hortonworks – Hive.
Для углубленного исследования мы организовали для обеих СУБД нагрузочное тестирование, учитывающее профильную для нас нагрузку. Надо сказать, что движки обработки данных в Impala и Hive существенно отличаются — Hive вообще представляет несколько разных вариантов. Однако выбор пал на Impala – и, соответственно, дистрибутив от Cloudera.
Чем понравилась Impala
Sqoop и остальная архитектура
Следующим по важности инструментом в стеке Hadoop стал для нас Sqoop. Он позволяет перебрасывать данные между реляционными СУБД (нас, конечно, интересовала Teradata) и HDFS в Hadoop-кластере в разных форматах, включая Parquet. В тестах Sqoop показал высокую гибкость и производительность, поэтому мы решили воспользоваться им — вместо разработки собственных инструментов захвата данных через ODBC/JDBC и сохранения в HDFS.
Для обучения моделей и смежных задач Data Science, которые удобнее выполнять прямо на кластере Hadoop, мы использовали Spark от Apache. В своей области он стал стандартным решением — и есть за что:
На схеме показана верхнеуровневая архитектура Data Research Platform и смежных систем. Центральное звено — кластер Hadoop на базе дистрибутива Cloudera (CDH). Он используется для как для получения с помощью Sqoop и хранения данных КХД в HDFS — в поколоночном формате Parquet, допускающем использование кодеков для сжатия, например, Snappy. Также кластер обрабатывает данные: Impala используется для ELT-подобных трансформаций, Spark — для Data Science задач. Для разделения доступа к данным используется Sentry.
Impala имеет интерфейсы для практически всех современных enterprise-средств аналитики. Помимо этого в качестве клиентов могут подключаться произвольные инструменты, поддерживающие ODBC/JDBC интерфейсы. Для работы с SQL мы в качестве основных клиентов рассматриваем Hue и TOAD for Hadoop.
Для управления всеми потоками, которые указаны на схеме стрелочками, предназначена ETL-подсистема, состоящая из средств SAS (Metadata Server, Data Integration Studio), и ETL фреймворк, написанный на базе SAS и shell-скриптов с использованием базы для хранения метаданных ETL-процессов. Руководствуясь правилами, заданными в метаданных, ETL-подсистема запускает процессы обработки данных как на КХД, так и на Data Research Platform. В итоге мы имеем сквозную систему мониторинга и управления потоками данных вне зависимости от используемой среды (Teradata, Impala, Spark и прочее, если в том будет потребность).
Через грабли к звездам
Разгрузить КХД вроде бы просто. На входе и выходе реляционные СУБД, бери да переливай данные через Sqoop. Судя по описанию выше, у нас все шло очень гладко, но, конечно же, без приключений не обошлось, и это, пожалуй, самая интересная часть всего проекта.
С нашим объемом переливать все данные целиком каждый день можно было не надеяться. Соответственно, из каждого объекта хранилища нужно было научиться выделять надежный инкремент, что не всегда просто, когда в таблице могут изменяться данные за исторические бизнес-даты. Для решения этой задачи мы систематизировали объекты в зависимости от способов загрузки и ведения истории. Потом для каждого типа определили правильный предикат для Sqoop и способ загрузки в приемник. И наконец, написали инструкцию для разработчиков новых объектов.
Sqoop – очень качественный инструмент, но не во всех случаях и комбинациях систем он работает абсолютно надежно. На наших объемах недостаточно оптимально работал коннектор к Teradata. Мы воспользовались открытостью кода Sqoop и внесли изменения в библиотеки коннектора. Стабильность соединения при перемещении данных увеличилась.
По какой-то причине при обращении Sqoop к Teradata предикаты не совсем правильно конвертируются в WHERE-условия. Из-за этого Sqoop иногда пытается вытащить огромную таблицу и зафильтровать ее уже позже. Здесь пропатчить коннектор не удалось, но мы нашли другой выход: принудительно создаем временную таблицу с наложенным предикатом для каждого выгружаемого объекта и просим Sqoop перелить именно ее.
Все MPP, и Teradata в частности, обладают особенностью, связанной с параллельным хранением данных и исполнением инструкций. Если эту особенность не принимать в расчет, то может оказаться, что всю работу возьмет на себя один логический узел кластера, из-за чего выполнение запроса станет гораздо медленнее, раз этак в 100-200. Мы, конечно, не могли этого допустить, поэтому написали специальный движок, который использует ETL-метаданные таблиц КХД и выбирает оптимальную степень параллелизации задач Sqoop.
Историчность в хранилище – дело тонкое, особенно если использовать SCD2, при том что в Impala не поддерживаются UPDATE и DELETE. Мы, конечно, хотим, чтобы исторические таблицы в Data Research Platform выглядели абсолютно так же, как в Teradata. Этого можно достигнуть, комбинируя получение инкремента через Sqoop, выделение обновляемых бизнес-ключей и удаление партиций в Impala. Чтобы эту вычурную логику не пришлось писать каждому разработчику, мы упаковали ее в специальную библиотеку (на нашем ETL-сленге «загрузчик»).
Напоследок — вопрос с типами данных. Impala достаточно свободно относится к конвертации типов, поэтому с какими-то затруднениями мы столкнулись только в типах TIMESTAMP и CHAR/VARCHAR. Для даты-времени мы решили хранить данные в Impala в текстовом (STRING) формате YYYY-MM-DD HH:MM:SS. Этот подход, как оказалось, вполне позволяет использовать функции трансформации даты и времени. Для строковых данных заданной длины оказалось, что хранение в формате STRING в Impala ничем им не уступает, поэтому мы тоже использовали его.
Обычно для организации Data Lake копируют данные источников в полуструктурированных форматах в специальную stage-область в Hadoop, после чего средствами Hive или Impala устанавливают схему десериализации этих данных для использования их в SQL-запросах. Мы пошли по тому же пути. Важно отметить, что не все и не всегда имеет смысл тащить в хранилище данных, так как разработка процессов копирования файликов и установка схемы значительно дешевле загрузки бизнес-атрибутов в модель КХД с помощью ETL-процессов. Когда еще непонятно, в каком объеме, на какой срок и с какой периодичностью нужны данные источника, Data Lake в описанном подходе является простым и дешевым решением. Сейчас мы регулярно загружаем в Data Lake прежде всего источники, генерирующие пользовательские события: данные анализа заявок, логи и сценарии перехода автозвонилки и автоответчика Avaya, карточные транзакции.
Инструментарий аналитиков
Мы не забыли о еще одной цели всего проекта — дать возможность аналитикам пользоваться всем этим богатством. Вот основные принципы, которыми мы здесь руководствовались:
В заключение хотелось бы дать несколько общих советов коллегам, которые только начинают свой путь в создании больших хранилищ:
Массивно-параллельная база данных Greenplum — короткий ликбез
Для Hadoop и Greenplum есть возможность получить готовый SaaS. И если Хадуп — известная штука, то Greenplum (он лежит в основе продукта АrenadataDB, про который далее пойдёт речь) — интересная, но уже менее «на слуху».
Arenadata DB — это распределённая СУБД на базе опенсорсного Greenplum. Как и у других решений MPP (параллельной обработки данных), для массивно-параллельных систем архитектура облака далека от оптимальной. Это может снижать производительность аж до 30 % (обычно меньше). Но, тем не менее, эту проблему можно нивелировать (о чём речь пойдёт ниже). Кроме того, стоит покупать такую услугу из облака, часто это удобно и выгодно в сравнении с развёртыванием собственного кластера.
В гайдах явно указывается on-premise, но сейчас многие осознают масштаб удобства облака. Все понимают, что некая деградация производительности будет, но это настолько всё равно супер по удобству и скорости, что уже есть проекты, где этим жертвуют на каких-то этапах вроде проверки гипотез.
Если у вас есть хранилище данных больше 1 ТБ и транзакционные системы — не ваш профиль по нагрузке, то ниже — рассказ, что можно сделать как вариант. Почему 1 ТБ? Начиная с этого объёма использование MPP эффективнее по соотношению производительность/стоимость, если сравнивать с классическими СУБД.
Когда использовать?
Когда классическая single-node СУБД по архитектуре не подходит для ваших объёмов. Частый случай — новое хранилище данных объёмом больше 1 ТБ. MPP СУБД сейчас в тренде, и Greenplum — один из лучших на рынке по соответствию современным задачам. Особенно с учётом его опенсорсности. Есть ещё куча проприетарных систем с большим количеством фич из коробки: Террадата, Сап Хана, Экзадата, Вертика. Поэтому, если вы не можете позволить себе ананасов и рябчиков, то берите сливу.
Второй случай — когда у вас есть уже существующее хранилище данных на чём-то универсальном типа Оракла или Постгресса, но пользователи регулярно жалуются на медленные отчёты. И когда стоят новые задачи типа Big Data — когда пользователи хотят все данные и сразу, а что они с ними будут делать, они предсказать не могут. Есть много ситуаций, когда на действующем бизнесе нужны отчёты, которые актуальны только один день, а за сутки они не успевают рассчитаться. То есть нужных данных в принципе нет. В этом случае тоже удобно брать базы MPP и пробовать с SaaS в облаке.
Третий случай — когда у вас кто-то следует моде на Хадуп и решает стандартные задачи пакетной обработки структурированных данных, но не очень хорошо собрал кластер. Мы часто видим, что технология применяется немного и даже совсем не так, как должна. Например, на Хадупе не надо строить реляционную базу данных. Тем не менее, если в вашем Хадупе вдруг нет обработки в реальном времени либо она предполагалась, но админ и разработчик в ужасе сбежали, то тоже можно смотреть в сторону Greenplum в облаке: поддержка будет очень простой при сохранении возможности обработки огромных массивов данных.
Почему мало кто пробует?
Любые MPP СУБД требуют много мощностей. То есть много железа. По факту люди боятся пробовать до уровня proof of concept просто из-за цены входа. Не могут этого физически сделать. Одна из основных идей нашего SaaS — дать возможность поиграть со всем этим, не покупая кластер железа.
И регулярно встречаем заказчиков, которые говорят, что самостоятельно сопровождать, эксплуатировать и так далее не хотелось бы. А хотелось бы аутсорс. Это система аналитическая, и чаще всего она business-critical, но не mission-critical. Многие на Западе аутсорсят, у нас тоже началось недавно.
Что лучше всего делать на MPP?
Классическое корпоративное хранилище данных: по всем источникам данных вы получаете инкрементальные данные, а дальше из этого строятся витрины пользователям. Пользователи над этими витринами строят свои отчёты. «Я каждый день хочу видеть, как идут дела в бизнесе» — это оно.
Ещё пара слов про облачное решение
Раньше считалось, что инфраструктуры подобного плана слабо предназначены для облаков. Но на деле всё больше и больше заказчиков выходят в облака. Работа требует высокой производительности, так как в ней крутится очень много больших аналитических запросов, которые потребляют много ЦПУ, требуют много памяти и предъявляют высокие требования к дискам и сетевой инфраструктуре. Как результат, когда клиенты разворачивают распределённые СУДБ в облаке, они могут столкнуться с несколькими проблемами.
Первая — это недостаточная производительность сети. Так как это всё в облаке крутится в виртуальной среде, на одном гипервизоре может быть много машин. Виртуальные машины могут быть разбросаны по разным гипервизорам. Более того, в какие-то моменты они могут быть вообще разбросаны по разным дата-центрам, супервизоры на них могут крутиться виртуально. И из-за этого очень сильно страдает сеть. При переработке миллиарда записей в таблице нужно, скажем, 10 серверов, и он гоняет эти данные между всеми серверами. Внутри работает подвид, и даже внутри одного сервера работает много таких подвидов. Их может быть 10–20, и вот они все начинают во время выполнения запроса гонять данные по сети. Сеть падает, как озимые. Какой вывод из этого можно сделать? Используйте облака с высокой пропускной способностью каналов, например, Облако КРОК, которое на Infiniband даёт 56 Гб.
Вторая проблема — на всё это очень косо смотрят файрволы и DDoS-защиты. Накололись, решили. Перед использованием рекомендуем запланировать лишний час на перепроверку всех настроек.
Ещё важны незаметная живая миграция и обновление. Чтобы перетащить машину на другой гипервизор, а потом обратно, нужно не потерять пакеты. Необходимо шаманить с настройками в итоге. К примеру, мы почти сразу полезли за увеличением буфера обмена. MTU подняли до «джамбофрейма» 9 000.
Конечно, диски, которые HDD. Они очень не любят такую запись, особенно когда это очень-очень случайные сектора в очереди с остальными запросами. Решили разделением хранилища на сегменты: один — только для Greenplum, другой — общий. Нужно это для ситуаций, когда с десяток заказчиков разворачивает параллельно инсталляции Greenplum. MPP максимально утилизируют именно дисковую подсистему, облачные сервисы имеют интерконнект к хранилищу, и производительность там почти такая же, как у канала. Если все клиенты облака не делают расчёт MPP, то можно получить очень существенный выигрыш. Эффективное распределение мощностей в таких нагрузках очень хорошо работает.
И из-за собственной архитектуры Greenplum в облаке показывает себя по КПД лучше, чем Redshift, BigQuery и Snowflake.
Как выглядит развёртывание:
Архитектура «дышащая», то есть можно быстро развернуть простым множителем в конфигурации. Как пример — днём у нас работает пять ЦПУ, а вечером у нас поднимается 1 000 обработчиков, и работает десять ЦПУ. При этом не нужно делать баланс данных, потому что они лежат внутри одного хранилища. Из коробки доступно расширение, быстрое сжатие ещё нужно немного допиливать.
Сейчас для заказчика есть единая точка управления. Он приходит в одно место, кидает туда запрос вроде: «Разверните мне кластерный план на таких-то машинах», и наша поддержка развёртывает машины в облаке (у нас или у заказчика), располагает там Greenplum, запускает, настраивает и все настройки делает. То же самое касается мониторинга, управления, обновления. По мере автоматизации это будет уходить с поддержки на кнопки в личном кабинете.
Мы сначала поняли всё удобство такого подхода на внутренних проектах, а потом начали давать как SaaS заказчикам. У нас глубокая интеграция с S3 — это позволяет использовать Greenplum как систему с разделёнными слоями вычисления и хранения, или использовать S3 для бекапов, а Greenplum как ядро в составе КХД в облаке. Есть гибкое развёртывание сред для enterprise с помощью API КРОК и API ADCM.