В мае вышла новая версия Apache Ignite — 2.5. В неё внесено множество изменений, с полным списком которых можно ознакомиться в Release Notes. А в этой статье мы рассмотрим ключевые новшества, на которые стоит обратить внимание.
Apache Ignite — горизонтально масштабируемая платформа транзакционного хранения данных, а также распределенных вычислений поверх этих данных в режиме, близком к реальному времени.
Ignite применяют в тех случаях, когда нужна горизонтальная масштабируемость и очень высокая скорость обработки данных. Последнее достигается также за счет оптимизации платформы под хранение данных непосредственно в RAM в качестве первичного хранилища, а не кеша (In-Memory Computing). Отличительными особенностями продукта являются полноценный движок запросов ANSI SQL 1999, дисковое хранилище, расширяющее RAM, большое количество встроенных интеграционных инструментов и Zero-ETL машинное обучение.
Среди компаний, которые используют Apache Ignite такие фирмы, как Veon/Beeline, Сбербанк, Huawei, Barclays, Citi, Microsoft и многие другие.
Одно из главных изменений в версии 2.5 — новый вариант топологии. Ранее в Ignite была лишь топология «кольцо», которая использовалась для обмена событиями внутри кластера и обеспечивала эффективную и быструю масштабируемость, на масштабе до 300 узлов.
Новая топология предназначена для инсталляций из многих сотен и тысяч узлов.
Теперь вы можете выбрать: использовать старую топологию, где вам достаточно только Ignite, или же — для больших кластеров — дополнить большой Ignite маленьким ZooKeeper, через который будет проходить обмен событиями.
Зачем это и каким образом помогает?
У большого «кольца» есть недостаток: с учетом сетевого обмена и обработки уведомление всех узлов о новом событии может достигать секунд. Это само по себе плохо, а если учесть, что вероятность сбоя узла из-за временного отказа сети, оборудования или иных проблем растет с размером кластера, то перестройка топологии становится вполне обыденной задачей, особенно на кластерах, построенных на дешевом (commodity) железе. В большом «кольце» это вносит дополнительных хаос, прерывает обработку потока событий и вынуждает начинать ее сначала, параллельно передавая информацию о новой топологии.
Новая «звезда», где в центре находится кластер ZooKeeper, позволяет не просто сохранить масштабируемость (ZooKeeper тоже может расти горизонтально), но даже значительно повысить ее — масштабируемости — эффективность на больших объемах. Ведь разделяя ответственность за обработку событий и работу с данными, мы можем выделить под обработку событий намного более компактный кластер ZooKeeper, тем самым уменьшая зависимость прохождения событий от размера кластера.
Это никак не влияет на обмен данными между узлами Ignite, например, при ребалансировке, а также на сохранение данных или их извлечение, потому что всё все эти операции шли и идут в обход топологии событий через прямые соединения между узлами кластера.
Также добавление новой топологии никак не влияет на старую — она по прежнему остается рекомендуемой, поскольку намного легче в поддержке и легковеснее, не требует дополнительных элементов.
Но если вы достигли предела масштабирования «кольца» Ignite, можете не заниматься микрооптимизацией и прилаживанием хаков, не применять специфические знания и «костыли». На этот случай у вас есть официально доступное и поддерживаемое решение, которое заметно облегчит внедрение и поддержку столь крупного кластера.
Подробную информацию по новой топологии можно прочитать в документации.
В версии 2.4 была реализована поддержка тонких клиентов за пределами JDBC/ODBC, которые не являются полноценными участниками топологии, намного менее требовательны к ресурсам, но при этом предлагают сокращенную функциональность. Первым тонким клиентом был клиент для .NET.
Начиная с версии 2.5 также доступен тонкий клиент для Java.
Это позволяет без лишних прослоек встраивать Ignite в приложения, чувствительные к ресурсам, например, в приложения на оконечных устройствах. Ранее для такой задачи требовался промежуточный слой, который, например, по REST, принимал запросы и далее использовал внутренний «толстый» клиент для обмена данными с кластером Ignite.
Тонкий клиент можно использовать подключив стандартный «zero-dependency» JAR-файл ignite-core, например, из репозитория maven.
Пример использования тонкого клиента:
Также в версии 2.4 отсутствовала аутентификация для тонких клиентов. Начиная с версии 2.5 она, вместе с поддержкой шифрования при обращении от тонких клиентов, дебютирует в Ignite.
Подробную информацию можно прочитать в документации.
Распределенный ANSI99 SQL-движок исторически является одной из сильных сторон и важных отличительных особенностей Apache Ignite. Он позволяет «единым окном», через Java/.NET/C++-клиент либо через JDBC/ODBC-драйвер, выполнять SQL-запросы поверх всего кластера, как данных как в RAM, так и в Ignite Native Persistence.
В версиях 2.0–2.4 разработчики сосредоточились помимо повышения производительности (которой никогда не бывает мало), также на ускорении первичной и bulk-загрузки данных и более полной поддержке DDL, таких операций как CREATE TABLE, ALTER TABLE, CREATE INDEX и т.д., которые также через «единое окно» могли быть консистентно выполнены на кластере.
В версии 2.5 сделан шаг в сторону дальнейшего развития DDL: добавлена аутентификация для SQL и соответствующие команды CREATE USER, ALTER USER, DROP USER.
Если ранее предполагалось размещать Ignite SQL в стерильном DMZ с контролем доступа на уровне вышележащих сервисов, то теперь можно повысить безопасности с помощью аутентификации, управляемой через SQL.
С точки зрения скорости загрузки больших объемов данных в 2.5 появились 2 новшества.
Первое — новая SQL-команда COPY в JDBC, которая позволяет быстро, в bulk-режиме, перенести содержимое CSV-файла в таблицу.
Второе — режим streaming для JDBC, включаемый через новую команду SET. Он позволяет, загружая данные через стандартные INSERT-операции, прозрачно для пользователя выполнять группировку и оптимизированную загрузку новых записей в кластер Ignite. Передача накопленных операций в кластер происходит при наполнении batch-а или при закрытии JDBC-соединения.
Машинное обучение — одно из стратегических направлений развития Ignite. ML реализует парадигму Zero-ETL, что позволяет обучать непосредственно на тех данных, которые лежат в транзакционном хранилище Ignite. Тем самым достигается значительная экономимя времени и ресурсов на преобразовании данных и сетевой передаче в систему обучения.
В версии 2.5 в набор доступного инструментария добавлены генетические алгоритмы.
Также для оптимизации процесса обучения и минимизации сетевого обмена появилась поддержка ML-вычислений, имеющих информацию о партициях, на которых исполняются, и способных привязывать к этим партициям дополнительную информацию. Учитывая, что партиции атомарны с точки зрения распределенности, и одна партиция не может быть порезана между несколькими узлами, это позволяет оптимизировать процесс обучения, предоставляя больше гарантий алгоритму.
Подробную информацию можно прочитать в документации.
Также в версии 2.5 реализовано:
Apache Ignite — горизонтально масштабируемая платформа транзакционного хранения данных, а также распределенных вычислений поверх этих данных в режиме, близком к реальному времени.
Ignite применяют в тех случаях, когда нужна горизонтальная масштабируемость и очень высокая скорость обработки данных. Последнее достигается также за счет оптимизации платформы под хранение данных непосредственно в RAM в качестве первичного хранилища, а не кеша (In-Memory Computing). Отличительными особенностями продукта являются полноценный движок запросов ANSI SQL 1999, дисковое хранилище, расширяющее RAM, большое количество встроенных интеграционных инструментов и Zero-ETL машинное обучение.
Среди компаний, которые используют Apache Ignite такие фирмы, как Veon/Beeline, Сбербанк, Huawei, Barclays, Citi, Microsoft и многие другие.
Новый вариант топологии: звезда вокруг ZooKeeper
Одно из главных изменений в версии 2.5 — новый вариант топологии. Ранее в Ignite была лишь топология «кольцо», которая использовалась для обмена событиями внутри кластера и обеспечивала эффективную и быструю масштабируемость, на масштабе до 300 узлов.
Новая топология предназначена для инсталляций из многих сотен и тысяч узлов.
Теперь вы можете выбрать: использовать старую топологию, где вам достаточно только Ignite, или же — для больших кластеров — дополнить большой Ignite маленьким ZooKeeper, через который будет проходить обмен событиями.
Зачем это и каким образом помогает?
У большого «кольца» есть недостаток: с учетом сетевого обмена и обработки уведомление всех узлов о новом событии может достигать секунд. Это само по себе плохо, а если учесть, что вероятность сбоя узла из-за временного отказа сети, оборудования или иных проблем растет с размером кластера, то перестройка топологии становится вполне обыденной задачей, особенно на кластерах, построенных на дешевом (commodity) железе. В большом «кольце» это вносит дополнительных хаос, прерывает обработку потока событий и вынуждает начинать ее сначала, параллельно передавая информацию о новой топологии.
Новая «звезда», где в центре находится кластер ZooKeeper, позволяет не просто сохранить масштабируемость (ZooKeeper тоже может расти горизонтально), но даже значительно повысить ее — масштабируемости — эффективность на больших объемах. Ведь разделяя ответственность за обработку событий и работу с данными, мы можем выделить под обработку событий намного более компактный кластер ZooKeeper, тем самым уменьшая зависимость прохождения событий от размера кластера.
Это никак не влияет на обмен данными между узлами Ignite, например, при ребалансировке, а также на сохранение данных или их извлечение, потому что всё все эти операции шли и идут в обход топологии событий через прямые соединения между узлами кластера.
Также добавление новой топологии никак не влияет на старую — она по прежнему остается рекомендуемой, поскольку намного легче в поддержке и легковеснее, не требует дополнительных элементов.
Но если вы достигли предела масштабирования «кольца» Ignite, можете не заниматься микрооптимизацией и прилаживанием хаков, не применять специфические знания и «костыли». На этот случай у вас есть официально доступное и поддерживаемое решение, которое заметно облегчит внедрение и поддержку столь крупного кластера.
Подробную информацию по новой топологии можно прочитать в документации.
Тонкие клиенты: тонкий Java-клиент, аутентификация в тонких клиентах
В версии 2.4 была реализована поддержка тонких клиентов за пределами JDBC/ODBC, которые не являются полноценными участниками топологии, намного менее требовательны к ресурсам, но при этом предлагают сокращенную функциональность. Первым тонким клиентом был клиент для .NET.
Начиная с версии 2.5 также доступен тонкий клиент для Java.
Это позволяет без лишних прослоек встраивать Ignite в приложения, чувствительные к ресурсам, например, в приложения на оконечных устройствах. Ранее для такой задачи требовался промежуточный слой, который, например, по REST, принимал запросы и далее использовал внутренний «толстый» клиент для обмена данными с кластером Ignite.
Тонкий клиент можно использовать подключив стандартный «zero-dependency» JAR-файл ignite-core, например, из репозитория maven.
Пример использования тонкого клиента:
ClientConfiguration cfg = new ClientConfiguration().setAddresses("127.0.0.1:10800");
try (IgniteClient igniteClient = Ignition.startClient(cfg)) {
System.out.println(">>> Пример применения тонкого клиента.");
final String CACHE_NAME = "put-get-example";
ClientCache<Integer, Address> cache = igniteClient.getOrCreateCache(CACHE_NAME);
System.out.format(">>> Создан кеш [%s].\n", CACHE_NAME);
Integer key = 1;
Address val = new Address("Мясницкая, 20", 101000);
cache.put(key, val);
System.out.format(">>> Значение [%s] сохранено в кеш.\n", val);
Address cachedVal = cache.get(key);
System.out.format(">>> Значение [%s] загружено из кеша.\n", cachedVal);
} catch (...) { ... }Также в версии 2.4 отсутствовала аутентификация для тонких клиентов. Начиная с версии 2.5 она, вместе с поддержкой шифрования при обращении от тонких клиентов, дебютирует в Ignite.
ClientConfiguration clientCfg = new ClientConfiguration()
.setAddresses("127.0.0.1:10800");
// включение шифрования
clientCfg
.setSslMode(SslMode.REQUIRED)
.setSslClientCertificateKeyStorePath("client.jks")
.setSslClientCertificateKeyStoreType("JKS")
.setSslClientCertificateKeyStorePassword("123456")
.setSslTrustCertificateKeyStorePath("trust.jks")
.setSslTrustCertificateKeyStoreType("JKS")
.setSslTrustCertificateKeyStorePassword("123456")
.setSslKeyAlgorithm("SunX509")
.setSslTrustAll(false)
.setSslProtocol(SslProtocol.TLS);
// настройка аутентификации
clientCfg
.setUserName("joe")
.setUserPassword("passw0rd!");
try (IgniteClient client = Ignition.startClient(clientCfg)) {
...
}
catch (ClientAuthenticationException e) {
// Handle authentication failure
}Подробную информацию можно прочитать в документации.
SQL: аутентификация и управление пользователями, быстрая bulk-загрузка
Распределенный ANSI99 SQL-движок исторически является одной из сильных сторон и важных отличительных особенностей Apache Ignite. Он позволяет «единым окном», через Java/.NET/C++-клиент либо через JDBC/ODBC-драйвер, выполнять SQL-запросы поверх всего кластера, как данных как в RAM, так и в Ignite Native Persistence.
В версиях 2.0–2.4 разработчики сосредоточились помимо повышения производительности (которой никогда не бывает мало), также на ускорении первичной и bulk-загрузки данных и более полной поддержке DDL, таких операций как CREATE TABLE, ALTER TABLE, CREATE INDEX и т.д., которые также через «единое окно» могли быть консистентно выполнены на кластере.
В версии 2.5 сделан шаг в сторону дальнейшего развития DDL: добавлена аутентификация для SQL и соответствующие команды CREATE USER, ALTER USER, DROP USER.
Если ранее предполагалось размещать Ignite SQL в стерильном DMZ с контролем доступа на уровне вышележащих сервисов, то теперь можно повысить безопасности с помощью аутентификации, управляемой через SQL.
С точки зрения скорости загрузки больших объемов данных в 2.5 появились 2 новшества.
Первое — новая SQL-команда COPY в JDBC, которая позволяет быстро, в bulk-режиме, перенести содержимое CSV-файла в таблицу.
COPY FROM "/path/to/local/file.csv" INTO city (
ID, Name, CountryCode, District, Population) FORMAT CSVВторое — режим streaming для JDBC, включаемый через новую команду SET. Он позволяет, загружая данные через стандартные INSERT-операции, прозрачно для пользователя выполнять группировку и оптимизированную загрузку новых записей в кластер Ignite. Передача накопленных операций в кластер происходит при наполнении batch-а или при закрытии JDBC-соединения.
SET STREAMING ONМашинное обучение: генетические алгоритмы, привязка к партициям
Машинное обучение — одно из стратегических направлений развития Ignite. ML реализует парадигму Zero-ETL, что позволяет обучать непосредственно на тех данных, которые лежат в транзакционном хранилище Ignite. Тем самым достигается значительная экономимя времени и ресурсов на преобразовании данных и сетевой передаче в систему обучения.
В версии 2.5 в набор доступного инструментария добавлены генетические алгоритмы.
Также для оптимизации процесса обучения и минимизации сетевого обмена появилась поддержка ML-вычислений, имеющих информацию о партициях, на которых исполняются, и способных привязывать к этим партициям дополнительную информацию. Учитывая, что партиции атомарны с точки зрения распределенности, и одна партиция не может быть порезана между несколькими узлами, это позволяет оптимизировать процесс обучения, предоставляя больше гарантий алгоритму.
Подробную информацию можно прочитать в документации.
И много другое
Также в версии 2.5 реализовано:
- поддержка выполнения SQL-запросов через Spark DataFrame непосредственно в Ignite без поднятия промежуточных данных в Spark;
- поддержка UPDATE через LINQ в .NET;
- настраиваемая обработка критических ошибок (например, автоматический перезапуск узла при переполнении памяти);
- метки транзакций и дополнительные инструменты отладки длинных транзакций;
- JMX-бины для мониторинга транзакций;
- возможность прерывания длинных транзакций при необходимости перестройки топологии партиций (которая блокируется наличием активных транзакций);
- инструменты по оффлайн-валидации консистентности данных и метаданных;
- дополнительная валидация результатов SQL-запросов;
- ODBC failover;
- новые метрики: количество партиция на узле для кеш-группы, объем RAM для региона данных на узле, суммарный размер WAL на узле, низкоуровневые метрики страниц дискового хранилища;
- DEB-пакеты дополнительно к ранее появившимся RPM.
