В числе наиболее популярных сегодня на российском рынке аналитических СУБД особенно интересны два проекта с открытым исходным кодом: Greenplum и ClickHouse. Обе эти СУБД отлично справляются с большим количеством кейсов, связанных с аналитикой данных, а в случае комбинации их в одном стеке, можно обеспечить почти мгновенную одновременную обработку тысяч аналитических запросов. О том, какие архитектурные и функциональные особенности Greenplum и ClickHouse стоит учитывать, чтобы эффективно использовать их в рамках одной инфраструктуры, пойдёт речь в этой статье.
Почему одного Greenplum недостаточно
Когда заказчики обращались к нам за консультацией по планированию оптимальной архитектуры хранилища до нашего знакомства с ClickHouse, чаще всего мы останавливались на следующей классической схеме:
- Источники данных.
- Загрузка данных с помощью ETL-средств или CDC (Сhange Data Capture).
- Arenadata DB (продукт на базе Greenplum) в качестве целевой СУБД.
- ELT-решение (Informatica, NiFi или другие).
- Arenadata Hadoop для создания хранилища слабоструктурированных и неструктурированных данных.
- BI-системы.
- Пользователи.
Эта архитектура вполне эффективна, когда нужно обеспечить доступ к данным для нескольких сотен
пользователей.
При такой нагрузке на кластер средней производительности Greenplum способен обеспечивать время отклика
для
витрин данных в среднем диапазоне от нескольких секунд до десятков (в зависимости от разных условий).
Однако
однажды к нам обратились два заказчика, у каждого из которых были тысячи активных пользователей, и
каждому из
них нужно было обеспечить время обработки запроса не более двух секунд!
Стало очевидно, что одним Greenplum здесь не обойтись. Ведь эта СУБД не может держать больше шести сотен
параллельных подключений и консервативно работает с запросами, которые требуют очень короткого времени
отклика
(например, менее секунды). Конечно, можно повышать скорость с помощью различных оптимизаций, но до
определённых
пределов, так как работа с такими запросами, объективно говоря, не самая сильная сторона Greenplum.
Тогда мы обратили внимание на ClickHouse и выяснили:
- в ClickHouse нет понятия транзакции,
- она не поддерживает ANSI SQL 2008,
- не умеет делать локальные и распределённые JOIN,
- не совместима с PostgreSQL, но!
Эта СУБД очень и очень быстрая! Наши тесты показали, что на сопоставимом оборудовании по скорости
ответа
ClickHouse оказалась значительно быстрее Greenplum при работе с WHERE-условиями, с агрегациями, без JOIN
и
каких-либо глубоких трансформаций.
Учитывая этим особенности, мы решили реализовать такое решение: за построение витрин данных с помощью
ELT/ETL-инструментов будет отвечать Greenplum, а всю остальную работу с обработкой данных в витринах
будет
делать ClickHouse (см. рис. 2).
Для того, чтобы его реализовать нам было необходимо не только обеспечить быструю и корректную выгрузку данных из Greenplum в ClickHouse, но и наладить эффективное взаимодействие между ними. То есть учесть в решении задачи особенности каждой СУБД и придумать, как быстро доставлять данные из Greenplum в ClickHouse (ведь нельзя же просто взять и переложить таблицы из одной базы в другую!). Мы придумали. Но, прежде чем рассказать, как, остановимся на том, как устроены Greenplum и ClickHouse.
MPP-СУБД Greenplum
Greenplum — аналитическая, распределённая, массивно-параллельная СУБД с открытым исходным кодом,
основанная на
PostgreSQL. Она оптимальна для аналитической работы с неограниченным объёмом данных, построения больших,
надёжных и масштабируемых хранилищ.
Эта СУБД отличается высокой надёжностью. Благодаря MPP-архитектуре, а также мощным алгоритмам
оптимизации
Greenplum позволяет очень быстро обрабатывать «тяжёлые» аналитические запросы при работе с очень
большими
объёмами данных. В Greenplum реализована концепция Shared Nothing (без разделения ресурсов). Каждый узел
кластера участвует во всех вычислительных операциях и имеет собственные ресурсы для их выполнения
(оперативную
память, операционную систему, CPU и жёсткие диски). За счёт этого СУБД эффективно распараллеливает
нагрузку при
поступлении аналитических запросов, автоматически изолирует процессы разных пользователей друг от друга
и таким
образом разграничивает ресурсы кластера.
Архитектура Greenplum
Архитектура Greenplum представляет собой несколько экземпляров (инстансов) объектно-реляционной базы данных PostgreSQL, которые работают как единая СУБД. Элементами такой архитектуры являются:
- Мастер-хост (или мастер-сервер). На нём развёрнут мастер-сегмент (master instance, «мастер») — главный экземпляр PostgreSQL. Это точка входа в Greenplum: к ней подключаются пользователи и в неё приходят все SQL-запросы. «Мастер» не содержит никаких пользовательских данных и практически не участвует в их обработке. Он лишь принимает входящие подключения, собирает и систематизирует запросы, перераспределяя их дальше по сегментам. Мастер-сегмент координирует свою работу с другими экземплярами базы данных.
- Резервный мастер (secondary master instance). Экземпляр PostgreSQL, который используется, когда недоступен основной «мастер».
- Primary segment instance на сервер-сегментах (segment hosts). На одном сервер-сегменте может размещаться один или несколько (обычно от двух до восьми) логических сегментов (экземпляров PostgreSQL), которые хранят и обрабатывают данные. Каждый сегмент содержит свою часть данных, а процессы, его обслуживающие, выполняются в соответствующих экземплярах сегмента. К сервер-сегментам может обращаться только «мастер». Предполагается, что все сервер-сегменты должны быть настроены идентично, так как наилучшая производительность Greenplum достигается за счёт равномерного распределения данных и нагрузок.
- Mirror segment instance («зеркало»). Экземпляр PostgreSQL, являющийся зеркалом одного из логических сегментов. Для каждого из логических сегментов может быть только одно зеркало.
- Interconnect network (сетевой уровень архитектуры Greenplum). Связь между отдельными экземплярами PostgreSQL обеспечивается за счёт соединения сегментов с помощью интерконнектов. Использование нескольких interconnect-сетей позволяет повысить пропускную способность канала и обеспечить отказоустойчивость кластера (в случае отказа одной из сетей весь трафик перераспределяется между оставшимися).
Сильные стороны Greenplum:
- Поддержка ANSI SQL 2008 + 2012 extensions (OLAP и т. д.).
- Возможность выполнять локальные и распределённые JOIN.
- Поддержка реляционной модели данных, совместимость с PostgreSQL, а значит, и со всеми BI- и ETL-системами. Знакомый синтаксис SQL, который обеспечивает недорогую ETL-разработку.
- Соответствие требованиям ACID:
- Atomicity (атомарность) — гарантия, что каждая транзакция будет или выполнена полностью, или не выполнена вовсе.
- Consistency (согласованность) — гарантия того, что до выполнения транзакции и после база останется согласованной (консистентной).
- Isolation (изолированность) — гарантия того, что параллельные транзакции не оказывают влияния на результат выполнения отдельной транзакции.
- Durability (неизменяемость операций) — гарантия того, что внесённые изменения не будут отменены после подтверждения от системы, что транзакция выполнена.
- Отказоустойчивость, которая обеспечивается благодаря созданию зеркал каждого логического сегмента и резервного мастер-сервера.
- Горизонтальное масштабирование — возможность добавлять новые серверы и сегменты практически без простоя СУБД. Чем больше новых узлов добавлено, тем быстрее работает Greenplum.
- Возможность работать с данными из нескольких источников с минимальной предварительной обработкой.
Типовые сценарии применения Greenplum:
- Системы регулярной отчётности (управленческой, операционной, МСФО и т. д.).
- Предиктивный анализ: анализ текущих и прошлых данных или событий для прогноза будущих данных или событий. Например, в директ-маркетинге, целевой рекламе, управлении инвестиционными рисками, выявлении мошеннических схем.
- Ad-hoc аналитика: сегментация рынка, концепция продукта, эффективность рекламы, потенциал компании или бренда, каналы сбыта, эффективность продаж.
- Маркетинговый анализ: целевая аудитория, конкуренты, ценовые предложения.
- Финансовый скоринг: оценка кредитоспособности заёмщиков, оценка наиболее вероятных финансовых действий и др.
- Анализ клиентской базы: АВС-анализ (сегментация по объёму продаж и прибыли), XYZ-анализ (сегментация по частоте покупок или сделок).
- Анализ данных логистики: сроки доставки, затраты на перевозку, расходы на хранение груза.
Аналитическая СУБД ClickHouse
ClickHouse — высокопроизводительная колоночная СУБД с открытым исходным кодом, созданная компанией
«Яндекс» для
обработки аналитических запросов к структурированным большим данным в режиме реального времени.
Изначально эта
технология использовалась для построения интерактивных отчётов в «Яндекс Метрике». Постепенно
использование
ClickHouse распространилось на другие отделы компании, а потом и на внешних пользователей (после
расширения
пользовательской базы проект стал открытым).
Наиболее значимая особенность ClickHouse — очень высокая скорость выполнения SQL-запросов на чтение. Это
самая
быстрая колоночная OLAP-СУБД для своих типов запросов, которая способна масштабироваться до десятков
триллионов
записей с совокупным объёмом данных в несколько петабайт. ClickHouse позволяет сохранять поток данных
без
предварительной агрегации и быстро получать отчёты в любых разрезах, интерактивно выполнять
аналитические
запросы к данным, обновляемым в режиме реального времени.
В отдельных областях применения ClickHouse может быть выгоднее других систем ещё и с точки зрения
эффективности
использования ресурсов. В частности, в отличие от других популярных столбцовых СУБД для работы с
большими
данными, ClickHouse оптимизирована под использование HDD-дисков, то есть может обрабатывать данные,
которые не
помещаются в оперативную память. Это позволяет снижать стоимость эксплуатации системы за счёт того, что
жёсткие
диски дешевле RAM.
Из других значимых особенностей ClickHouse — она не поддерживает транзакции, точечные операции UPDATE и
DELETE,
а также не имеет оконных функций и полноценного оптимизатора запросов.
Архитектура ClickHouse
Архитектура ClickHouse выглядит иначе, чем в Greenplum. В этой СУБД на несколько серверов
устанавливается один
экземпляр, а запросы пользователей приходят напрямую к этим серверам. Для репликации данных и выполнения
распределённых DDL-запросов ClickHouse использует сервис координации ClickHouse Keeper. Это альтернатива
широко
известному сервису координации с открытым исходным кодом Apache ZooKeeper.
Небольшая ремарка о схожести и отличиях этих решений.
ZooKeeper реализован на языке Java, в то время как ClickHouse Keeper на C++. ClickHouse Keeper
предоставляет те
же гарантии, что и ZooKeeper (линеаризуемость записей, нелинеаризуемость чтений), также у него есть
совместимый
клиент-серверный протокол, чтобы стандартный клиент ZooKeeper мог использоваться с ClickHouse Keeper.
Однако
снэпшоты и журналы в ClickHouse Keeper имеют несовместимые с ZooKeeper форматы (хотя данные можно
конвертировать). Межсерверный протокол тоже несовместим с ZooKeeper, поэтому создать смешанный кластер
ZooKeeper
/ ClickHouse Keeper не получится. Система управления доступом (ACL) ClickHouse Keeper реализована так
же, как в
ZooKeeper. В целом ClickHouse Keeper можно использовать как равноценную замену ZooKeeper или как
внутреннюю
часть сервера ClickHouse.
Высокая скорость работы ClickHouse достигается за счёт определённых архитектурных особенностей:
- Векторные вычисления по участкам столбцов. Данные не только хранятся в столбцах, но и обрабатываются по векторам или по частям столбцов. Это снижает издержки на диспетчеризацию и позволяет эффективнее использовать CPU.
- Возможность физической сортировки данных по первичному ключу. Позволяет оперативно извлекать конкретные отдельные значения или значения диапазонов.
- Распараллеливание операций на несколько ядер процессора одного сервера.
- Распределённые вычисления на кластере за счёт шардирования.
- Поддержка приближённых вычислений с помощью агрегатных функций. Это снижает количество обращений к жёсткому диску и тоже повышает скорость обработки.
- Семплирование данных — выполнение запросов на части выборки, а также возможность агрегации ограниченного количества случайных ключей.
Особенности ClickHouse
-
Очень и очень высокая скорость обработки запросов!
ClickHouse обрабатывает OLAP-запросы в сотни тысяч раз быстрее, чем многие другие системы*: её производительность достигает петабайтов данных в секунду. Например, в «Яндекс Метрике» были зафиксированы такие показатели: до 1 миллиарда строк в секунду на одном сервере и до двух терабайт в секунду на кластере из 400 узлов. Такая скорость обработки изменила подход к работе аналитиков и Data Science.
* Бенчмарки ClickHouse’а можно посмотреть здесь. -
Линейная масштабируемость.
Для увеличения производительности СУБД достаточно просто добавить новые узлы в кластер. В ClickHouse есть функция Cross Data Center Replication (межцодовая репликация). Она синхронизирует данные между ЦОД, обеспечивая защиту от сбоев и высокоскоростной доступ к данным. За координацию репликации отвечает ClickHouse Keeper.
-
Высокая доступность и отказоустойчивость.
Все данные пользовательского кластера в ClickHouse всегда доступны на чтение и запись. Поскольку это полностью децентрализованная система, с её помощью можно построить СУБД с любым уровнем отказоустойчивости. Например, разместив данные в трёх дата-центрах и наладив репликацию, можно получить кластер с фактором репликации Х2, который способен выдержать полный отказ одного дата-центра.
-
Асинхронная репликация по умолчанию.
В ClickHouse по умолчанию используется асинхронная репликация. Это значит, что если данные записаны в любую реплику, то они будут гарантированно скопированы в другие реплики. Асинхронная репликация в ClickHouse работает в фоновом режиме и обычно занимает несколько секунд. Она позволяет поддерживать полную идентичность данных на разных репликах, автоматически восстанавливая их после сбоев. При необходимости можно использовать синхронный режим репликации. Для повышения надёжности асинхронной репликации в СУБД возможен кворумный режим записи данных. В этом случае запись считается успешной только после того, как информация корректно записана на несколько серверов — «набран кворум». Так обеспечивается линеаризуемость и имитация синхронных реплик. Если количество реплик с успешной записью не достигнет заданного кворума, то запись считается не состоявшейся и ClickHouse сам удалит этот блок из всех реплик для обеспечения целостности данных.
-
Быстрое сжатие данных.
Поскольку ClickHouse является колоночной СУБД, технология сжатия данных в ней работает в сотни раз быстрее, чем в строчных базах. За счёт использования современных алгоритмов компрессии LZ4 и ZSTD данные не только занимают меньше места в хранилище, но и значительно быстрее обрабатываются.
-
Поддержка SQL и расширяемость.
ClickHouse поддерживает диалект структурированного языка запросов, близкий к стандарту ANSI SQL, c расширениями, включающими в себя:
- массивы и вложенные структуры данных,
- вероятностные структуры,
- URI-функцию,
- возможность подключить внешнее key-value хранилище.
Также благодаря HTTP-интерфейсу можно писать собственные коннекторы на любом языке программирования. А благодаря специальным интеграционным движкам (engines) в качестве источника данных ClickHouse может использовать множество внешних хранилищ и баз данных.
-
Поддержка массивов и кортежей.
В ClickHouse «из коробки» поддерживаются массивы и кортежи. СУБД позволяет создавать таблицы данных с поддержкой на уровне запросов, где в одной из колонок, например, будет массив данных (множество чисел) или кортеж — массив из нескольких полей.
-
Возможности интеграции.
ClickHouse может подключаться к любой базе данных по JDBC и использовать её таблицы как свои. Также она может подключаться к другим экземплярам ClickHouse без дополнительной настройки, есть готовые интеграции с другими системами. В качестве инструментов подключения к СУБД можно использовать консоль, HTTP API, драйверы JDBS и ODBC и множество «обёрток» (wrapper) на Python, PHP, NodeJS, Perl, Ruby и R.
-
Лёгкая установка.
На операционных системах Ubuntu и Debian Linux СУБД ClickHouse ставится из готовых пакетов с помощью нескольких простых команд и не требует сложной настройки. Для организации работы СУБД в распределённом режиме потребуется ClickHouse Keeper.
-
Нет операторов UPDATE и DELETE.
Зато в ней есть операторы мутаций ALTER TABLE [db.]table UPDATE column1 = expr1 [, …] WHERE filter_expr и ALTER TABLE [db.]table [ON CLUSTER cluster] DELETE WHERE filter_expr. Также в ClickHouse встроены специальные движки таблиц CollapsingMergeTree и ReplacingMergeTree, которые с некоторыми оговорками позволяют реализовать бизнес-логику модификации и удаления данных.
-
Работа с таблицами.
Движок таблиц MergeTree позволяет:
- осуществлять неблокируемые запись и чтение;
- вставлять миллионы записей в секунду;
- партиционировать, реплицировать и семплировать данные;
- создавать таблицы и базы данных в runtime;
- загружать информацию, выполнять запросы без переконфигурирования и перезапуска сервера.
Типовые сценарии применения ClickHouse:
- Аналитика работы мобильных приложений: анализ количества скачиваний и регистраций, активности и вовлечённости пользователей, длительности сессий, количества рассылаемых приглашений и т. д.
- Web-аналитика: источники трафика, отказы, новые, постоянные и вернувшиеся посетители, длительность сессии, среднее количество просмотра страниц за один визит, конверсия, выполняемые действия, используемые устройства (мобильные или десктопные).
- Реклама и торги в реальном времени (технология продажи и покупки рекламных показов через аукцион).
- Розничная и электронная торговля: анализ покупательского спроса, учёт и анализ товарных запасов на складе, сбор и анализ данных онлайн-покупок пользователей и др.
- Бизнес-аналитика, банковские и финансовые операции: клиенты, финансы, продукты.
- Мониторинг различных технических и бизнес-метрик.
- Телекоммуникации и информационная безопасность: сбор и анализ информации об актуальных угрозах, выдача рекомендаций по их предотвращению, определение уязвимых мест в ИТ-инфраструктуре, сбор данных об используемом ПО и сроках действия лицензий.
- Онлайн-игры: активные пользователи, длительность сессии, отток, цена за установку, платежи и т. д.
- Обработка данных с IoT-устройств (Internet of Things, интернет вещей) и промышленных датчиков (обработка показателей с промышленных роботов, мониторинг линий производства в реальном времени).
Greenplum vs ClickHouse (сравнительная таблица)
| Greenplum | ClickHouse | |
| ACID (транзакционность) | Хорошо | Нет |
|
Возможность запускать несколько запросов в рамках одной транзакции. В Greenplum обеспечивается полная ACID-изоляция. В ClickHouse понятия транзакции не существует |
||
| Работа с запросами по WHERE-условиям | Хорошо | Отлично! |
|
Greenplum: в зависимости от объёма данных в базе выдаёт ответ за несколько единиц или
десятков
секунд. |
||
| FULL SCANS | Хорошо | Отлично! |
|
Режим FULL SCANS подразумевает полное сканирование всей базы данных с последующей выдачей объёмного запроса на внешний ресурс. У Greenplum с этим режимом работы всё хорошо, но ClickHouse благодаря своим агрегативным и лямбда-функциям работает намного быстрее |
||
| ANSI SQL | Хорошо | Минимально |
|
Greenplum поддерживает ANSI SQL 2008 + 2012 extensions (OLAP и т.д.). В целом он соответствует PostgreSQL 9.4 (на декабрь 2019). В ClickHouse поддержки ANSI SQL почти нет |
||
| Работа с JOIN | Хорошо | Минимально |
|
Greenplum корректно работает как с локальными, так и с распределёнными JOIN. Иногда случаются небольшие проблемы с JOIN-индексами (Greenplum не всегда их использует в JOIN). В ClickHouse работа с JOIN реализована слабо. Во-первых, правая часть JOIN должна помещаться в память одного сервера. А объединить две таблицы объёмом больше, чем память одного сервера, невозможно. Во-вторых, в ClickHouse планировщик не может решить, какой тип JOIN ему нужно выполнять в данном контексте. Поэтому всегда приходится указывать нужный тип: не правый или левый, а локальный, глобальный, any и т. д. Пользователь, который не знает об этой особенности, рискует получить неконсистентные данные |
||
| Управление ресурсами | Хорошо | Средне |
|
Алгоритм управления ресурсами реализован в Greenplum очень гибко. Можно назначать конкретным группам пользователей конкретные ресурсы, причём они могут даже заимствовать их друг у друга по определённым правилам. Это достигается благодаря новому механизму ресурсных групп (есть ещё старый механизм — ресурсные очереди, которые работают менее стабильно) |
||
| Аварийное восстановление (disaster recovery) | Минимально | Средне |
|
В Greenplum пока нет такой функции. Пока же в этой СУБД write-логи стали совместимы с
логами
PostgreSQL, поэтому можно восстанавливать эти логи на другом кластере в другом ЦОД.
|
||
| Информационная безопасность | Хорошо | Минимально, но* |
|
В Greenplum повторены классические модели PostgreSQL: есть пользователи, группы, разрешения и наследование, есть поддержка шифрования данных и SSL-протокола подключения, можно реализовать roll down security и call down security. В ClickHouse ничего подобного нет, но появилась функция, позволяющая решить задачу авторизации (об этом будет ниже). |
||
| Custom code | Средне | Средне |
|
Под Custom code имеется в виду запуск не стандартного SQL-кода, а длинных
пользовательских
инструкций, написанных на основе SQL.
|
||
Оптимальные use-кейсы для Greenplum и ClickHouse
Суммировав все особенности обеих СУБД, мы выделили оптимальные, на наш взгляд, кейсы для каждого продукта.
Greenplum лучше всего справляется со следующими задачами:
- ETL- и ELT-процессы загрузки данных — классическая трансформация данных, наиболее эффективно показывают себя при in-database обработке.
- DWH-трансформации — любые другие виды трансформации, включая генерацию ключей и т. д.
- Большие JOIN — эффективное соединение больших таблиц, особенно в случаях объединения по заведомо заданному ключу распределения, эта СУБД хорошо объединяет большие таблицы как локально, так и распределённо.
- Ad-hoc deep dive — углублённый анализ по специализированным запросам, когда заранее неизвестно, какие данные понадобятся пользователю, но необходимо организовать к ним доступ и выделить ресурсы для их обработки.
- Аналитические функции на процедурных языках, в том числе и с помощью уже готовых библиотек алгоритмов MADLib.
А скоростной ClickHouse наиболее эффективен для:
- Wide data marts — работы с быстрыми витринами данных. Если витрины, созданные в Greenplum, выгружаются в ClickHouse, куда поступают однотипные предсказуемые запросы пользователей, запросы к быстрым витринам обрабатываются за миллисекунды.
- Wide fact tables — работы с широкими денормализованными таблицами фактов. Когда необходимо сохранить огромные массивы сырых данных, агрегировать их и дальше работать с агрегатами. Позволяет быстро делать сложные агрегации, запросы к таблицам обрабатываются за миллисекунды.
- AD-HOC — работы с несложными специализированными запросами к витринам данных, когда необходимо сохранить огромный массив сырых данных.
- Full-scan операции — работы с full-scan операциями при условии использовании фильтров, а также работы со структурированными логами и событиями.
Tkhemali-коннектор для быстрой доставки данных
Вопрос с доставкой данных из Greenplum в ClickHouse мы решили с помощью дополнительного коннектора,
который
разработали сами. Он позволяет консистентно переносить данные даже в случае отката транзакции. Кстати,
назвали
мы его Tkhemali («Ткемали»), как одноимённый грузинский соус из слив, поскольку Greenplum в
дословном
переводе с
английского означает «зелёная слива».
Это решение позволило нам добиться очень высокой скорости взаимодействия: как показали наши первые тесты
на
типовых SATA-дисках, мы получили до 1 Гб/с на вставку на одну пару серверов Greenplum —
ClickHouse.
Также мы гарантированно увеличили скорость взаимодействия по мере роста кластеров Greenplum и
ClickHouse. При
этом коннектор обеспечивает корректную вставку данных вне зависимости от текущей загрузки ClickHouse.
Благодаря
Tkhemali-коннектору десятки тысяч пользователей одновременно могут быстро получать данные из витрин,
построенных
в основном хранилище в Greenplum, обращаясь к ClickHouse.
В одной из следующих статей подробнее расскажем о Tkhemali-коннекторе, его возможностях, особенностях и
архитектуре.
Greenplum, ClickHouse и продукты Arenadata: в чём отличие?
Несмотря на то, что мы разрабатываем свои продукты на базе проектов с открытым исходным кодом, они
существенно
отличаются от исходных «ванильных» версий.
Во-первых, все продукты Arenadata — это готовые к развёртыванию и использованию дистрибутивы с
оптимальным
набором протестированных и совместимых между собой компонентов стабильных версий. При работе с каждым
открытым
проектом наша команда проводит тщательный анализ исходного кода с целью:
- проверки и последующего исправления ошибок;
- разработки нового и оптимизации существующего функционала (своими наработками мы частично делимся с сообществом проекта);
- проверки на наличие вредоносных «закладок», направленных на разрушение российских информационных систем.
Второе важное отличие — дополнительный функционал, который существенно расширяет возможности исходных
решений
(функционал самого продукта, коннекторы, система мониторинга, дополнительный модуль для управления
политиками
безопасности и др.). Для каждого продукта Arenadata свой набор, однако есть и общее решение — Arenadata Cluster Manager (ADCM).
Все компоненты платформы управляются с помощью универсального оркестратора гибридного ИТ-ландшафта ADCM.
Он
позволяет существенно автоматизировать установку, настройку и обновление сервисов, а также организовать
мониторинг работоспособности кластера. Также с помощью Arenadata Cluster Manager можно легко
разворачивать и
управлять дата-сервисами в гибридной ИТ-инфраструктуре: dev-, test-, prod-среды; bare-metal, clouds,
multi-clouds.
Третье важное отличие состоит в том, что Arenadata — это не просто разработчик программных продуктов, а
экосистема продуктов, проектов и сервисов, в которую кроме самой платформы входят ещё консалтинговые
услуги,
техническая поддержка, курсы для ИТ-специалистов, программы сотрудничества с российскими техническими
вузами и
большая сеть партнёров.
ClickHouse vs Arenadata QuickMarts
Об отличиях Arenadata DB от Greenplum ранее мы уже рассказывали в блоге, поэтому здесь остановимся только на отличиях Arenadata QuickMarts от ClickHouse.
Вклад Arenadata в развитие проекта ClickHouse
Поскольку отдельные разработки мы возвращаем в community исходного проекта, часть нового функционала,
который
Arenadata реализовала для Arenadata QuickMarts, сейчас доступна всему сообществу ClickHouse.
В частности, в релиз ClickHouse 20.8 был включён созданный Arenadata функционал Kerberos-авторизации для
Kafka.
Это позволило настраивать авторизацию в ClickHouse (и Arenadata QuickMarts соответственно):
конфигурационный
файл ClickHouse управляет библиотекой librdkafka, обеспечивающей взаимодействие с Kafka. Основная
сложность этой
разработки была связана с тем, что в ClickHouse изначально было заложено минимальное количество внешних
зависимостей. Стандартный для продукта способ использования библиотек — полная интеграция. Также в этом
релизе
нашей командой были решены некоторые технические проблемы, которые дали возможность community проекта
полноценно
использовать Kerberos в ClickHouse. Потребовалось много усилий для создания окружения из
docker-контейнеров с
Kafka, ZooKeeper и Kerberos KDC для тестирования этого функционала.
В релизе ClickHouse 21.1 вышла реализация Kerberos-авторизации доступа к HDFS, сделанная нашей командой.
А в
ClickHouse 21.11 появилась функция OR operator in ON section for join. Для ClickHouse это был важный шаг
в
направлении полной поддержки стандарта SQL. Для нашей команды эта задача стала своего рода тестом на
возможность
внесения изменений на уровне ядра ClickHouse (обычно такие вещи делает только разработчик исходного
проекта).
Дополнительный функционал в Arenadata QuickMarts
Часть нового функционала остаётся уникальной и доступна нашим заказчикам только в составе
enterprise-версии
Arenadata QuickMarts. В частности, благодаря коннекторам наш продукт нативно совместим с Arenadata DB и
с
Arenadata Hadoop.
Кроме коннекторов, в enterprise-редакции ADQM также реализованы упрощённые установка, настройка и
обновление
сервисов с помощью Arenadata Cluster Manager и система мониторинга и оповещения на базе Graphite и
Grafana. Она
помогает администраторам оставаться в курсе того, что в конкретный момент времени происходит с
кластером.
Система оповещений позволяет предупреждать сбои и ошибки в работе системы.
Как и с остальными проектами, для Arenadata QuickMarts мы проводим дополнительное тестирование и
контроль
качества новых релизов. У наших заказчиков есть возможность влиять на оперативную доработку функционала
и планы
развития продукта.
Техническая поддержка Arenadata QuickMarts оказывается в режиме 24/7 или 8/5 в зависимости от
критичности
системы. Мы строго соблюдаем SLA: в договоре фиксируется время первого ответа на обращение, гарантии по
оперативной диагностике и устранению сбоев, развёрнутые консультации и помощь в установке
обновлений.
Заказчикам enterprise-версии не обязательно самостоятельно заниматься планированием и реализацией
проектов
внедрения. Все эти работы и не только могут выполнить архитекторы, аналитики и инженеры Arenadata в
рамках услуг
«DBA как сервис», «Технический
аккаунт-менеджмент», «Аудит цифрового
ландшафта» и Smart Start.
Как разобраться в Arenadata DB и Arenadata QuickMarts глубже
Для того чтобы специалисты могли хорошо разобраться в наших продуктах, мы разработали авторизованные
курсы,
ориентированные на быстрое применение знаний о продукте на практике. Преподаватели центра — специалисты
с
большим опытом работы с продуктами Arenadata. Они на наглядных примерах объясняют нюансы установки,
настройки,
конфигурирования и обслуживания СУБД, дают необходимые знания по эксплуатации и масштабированию
кластера.
Лабораторные работы проходят на стендах, симулирующих рабочую среду, а каждый курс завершает экзамен с
выдачей
именного сертификата. Программы курсов будут полезны таким специалистам, как Data Engineer, Big Data
Administrator, Software Developer, Data Analyst, DevOps Engineer, Database Administrator, Data
Scientist.
По Greenplum и ClickHouse мы предлагаем учебные программы:
- «Arenadata DB для аналитиков» — программа нацелена на то, чтобы помочь разобраться, как использовать эту СУБД для анализа данных.
- «Arenadata DB для разработчиков» — курс погружает в тонкости разработки для Arenadata DB.
- «Эксплуатация Arenadata DB» — курс даёт все необходимые знания по работе (эксплуатации) этой распределённой СУБД.
- «Эксплуатация Arenadata QuickMarts» — детальный разбор особенностей эксплуатации колоночной СУБД Arenadata QuickMarts.
Описание программ и расписание можно посмотреть в разделе «Курсы». Также наши специалисты всегда готовы проконсультировать по вопросам, связанным с продуктами Arenadata.
