О проекте Apache Ignite слышно всё чаще. Но, как ранее заметил на Хабре один из его разработчиков Владимир Озеров, в двух словах описать проект сложно — а в результате у многих остаются вопросы, начиная с самых базовых. Что проект вообще представляет собой? Как соотносятся Apache Ignite и компания GridGain? Как соотносятся понятия «in-memory data grid» и «in-memory data fabric»?

В программу JBreak и JPoint 2017 вошли доклады спикеров из GridGain, а сама компания стала спонсором обеих конференций — и прямо перед JBreak мы задали накопившиеся у многих вопросы. А ответили на них:

  • Владимир devozerov Озеров (архитектор)
  • Алексей Дмитриев (генеральный директор российского отделения / VP of Engineering)
  • Ирина Тищенко (HR-директор)


Владимир Озеров (архитектор)



— Начнём с простого: что проект представляет собой и чем отличается от схожих продуктов?

— Apache Ignite — это универсальная платформа для распределённых in-memory вычислений. Первыми компонентами, появившимися около 10 лет назад, были распределённый кэш (data grid) и map-reduce (compute grid). На тот момент и мы, и наши конкуренты позиционировали свои решения как «distributed cache». Со временем требования бизнеса росли, мы добавляли новые модули. Среди основных: поддержка ANSI SQL'99, потоковая загрузка данных (streaming), развёртывание пользовательских приложений в кластере (service grid), возможность сохранять объекты, не имея их Java-классов на сервере (binary objects), интеграции с большим количеством сторонних интерфейсов и платформ (web sessions, Spring cache, Hibernate L2 cache, Hadoop, Spark, Kafka, JDBC, ODBC, и т.д.).

В какой-то момент устоявшиеся понятия «distributed cache» и «in-memory data grid» перестали отражать суть продукта. Тогда появился термин «in-memory data fabric» — это ПО для распределённых вычислений в памяти, с большим количеством интерфейсов для различных источников данных и их потребителей. Именно это выделяет нас на фоне аналогичных решений, которые не торопятся выходить за рамки термина «in-memory data grid».

— Проект не сразу пришёл к open source — как это произошло?

— Первое время продукт развивался как закрытое коммерческое решение GridGain. Осознав потенциал open source, мы открыли большую часть исходного кода на GitHub, но контроль над разработкой оставался в руках компании. Это распространённая бизнес-модель: смотри, используй, но не вмешивайся. Но мы пошли дальше. В 2015 году открытая часть была передана под контроль Apache Software Foundation. Решение далось нелегко: мы теряли контроль над кодом, и были вынуждены искать новое название. Так появился Apache Ignite. Ставка была сделана на то, что бренд Apache и теперь уже честный open source дадут серьезный импульс проекту, увеличив его популярность. И мы не ошиблись: количество пользователей начало расти экспоненциально.

Что интереснее, люди стали активно вкладывать свои силы в проект: генерировать идеи, исправлять ошибки, улучшать документацию, разрабатывать новые фичи и модули, писать книги и выступать на конференциях. Это просто фантастика! Мы продолжаем прилагать усилия для привлечения новых контрибьюторов. Любой из читающих это интервью может внести свой вклад, получив опыт разработки действительно сложной системы.

— Звучит здорово, но где в этой схеме деньги? Как соотносятся GridGain и Apache Ignite?

— Коммерческие компании редко могут себе позволить работу с чистым open source, особенно в критических бизнес-приложениях. Кто добавит недостающую функциональность, оперативно исправит баг и ответит на вопросы? Всё это доступно в рамках базового коммерческого продукта — GridGain Professional Edition. Это кодовая база Apache Ignite плюс поддержка и хот-фиксы.

Кроме того, бизнес зачастую предъявляет повышенные требования к безопасности, отказоустойчивости и высокой доступности. Эта функциональность реализована в GridGain Enterprise Edition. Он включает в себя Community Edition плюс набор дополнительных фич: аутентификация и авторизация пользователей (security), репликация данных между дата-центрами (data center replication), возможность обновления версии GridGain без остановки кластера (rolling upgrades), а также утилиты для мониторинга состояния системы.

— С продуктами разобрались, давайте поговорим про техническую составляющую. Как вы ведете R&D?

— Технические обсуждения происходят публично, на dev-листе. Мы ставим задачу, собираем мнения, после чего определяем архитектуру, и конкретный план действий. У каждого компонента есть ментор, который хорошо знает соответствующий функционал. В сложных случаях именно он собирает всё в кучу. Для принятия грамотных решений зачастую приходится работать с литературой и научными публикациями. Иногда готовых ответов просто нет, и ты становишься первопроходцем. Это и делает нашу работу увлекательной.

— А как тестируете код?

— Это многоуровневый процесс. Разработчик пишет код, и покрывает его тестами. Причем, это не только unit-тесты, но и интеграционное тестирование. Ты проверяешь код изолированно, потом на одном узле, на нескольких, моделируешь многопоточность и отказы. Тесты бегают на публичном CI-сервере (TeamCity). Далее код проходит обязательный peer review. Второй частью процесса управляет QA-отдел. Они прогоняют функционал через набор своих тест-кейсов, преимущественно автоматических (Python, Java). В комплексе это позволяет нам удерживать качество на необходимом уровне.

— К вопросу о «любой может внести свой вклад» — есть ощущение, что всё-таки не любой, поскольку проект нерядовой. Какие требования к разработчикам GridGain, и где вы находите людей?

— Действительно, Apache Ignite — наукоёмкий продукт, поэтому фундаментальные знания важны. Начиная с классических алгоритмов, структур данных и многопоточности, и заканчивая принципами создания распределённых систем и внутренним устройством СУБД. Найти человека с такими багажом — задача сложная. Мы это понимаем, поэтому ищем людей с хорошим фундаментом, а подтягиваем до нужного уровня уже в бою. В этом очень помогает открытость процесса. Любой сотрудник может участвовать в архитектурных обсуждениях на dev-листе. В добавок к этому, у нас достаточно плоская организационная структура, все пишут код, что также способствует адаптации.

Алексей Дмитриев (генеральный директор российского отделения / VP of Engineering)



— При взгляде со стороны кажется, что компания GridGain обогнала своё время: когда она появилась, интерес к in-memory computing был куда ниже нынешнего, а вот теперь приходит её время. Согласны ли вы с этим?

— Скорее я бы сказал, что компания пришла ровно в то время, когда рынок был готов для новой технологии. Основателям компании в своё время удалось правильно уловить технологические тенденции и сделать правильные шаги. Поэтому сейчас, когда эта технология очень востребована, компания имеет возможность приходить к своим клиентам с уже готовым и зрелым продуктом.

— Какими вы видите тенденции рынка — ожидаете и дальнейшего бурного роста?

— Объём данных, который необходимо обработать, растёт, а потребность обработать эти данные быстро актуальна сейчас практически для всех крупных компаний как в финансовой сфере, так и в телекоме и в других областях. Наша технология позволяет масштабировать решение практически неограниченно. В данный момент появляются всё более и более быстрые аппаратные решения как для оперативной памяти, так и для диска. Наш проект архитектурно готов к этим новым решениям и их внедрение, безусловно, раскроет нам новые горизонты. Поэтому, да, я ожидаю дальнейшего бурного роста и активности в области распределённых решений, и в частности, вокруг нашего продукта.

— У вас есть крупные клиенты вроде Сбербанка — а ваше решение и подходит гигантам с большими бюджетами, или небольшим компаниям тоже?

— Это решение подходит всем. У Сбербанка очень много данных, поэтому они задействуют коллосальный аппаратный комплекс, чтобы оперировать с такими данными быстро. У небольших компаний, как правило, данных меньше и затраты существенно скромнее. Кроме того, наш продукт сейчас позволяет дифференцировать данные по частоте обращения к ним и держать в оперативной памяти только те, к которым приложения обращаются наиболее часто. Ну и самое главное: наш продукт работает не только на доргих многопроцессорных серверах, но и на простых дешёвых офисных компьютерах. Вам нужно просто подключить их в одну сеть и поставить на них GridGain. Вам не понадобится никакое сверхдорогое специфическое «железо».

— У GridGain любопытные взаимоотношения с Россией: компания американская, но основатели русскоговорящие, разработка во многом ведётся силами российских программистов, а в 2016-м одним из инвесторов и ключевых клиентов стал Сбербанк. Насколько Россия для вас приоритетна и как рынок для продаж, и как место поиска новых кадров?

— GridGain — далеко не первая известная американская компания с русскими основателями. Если вы хотите сделать разработку нового и сложного продукта очень быстро и качественно, то Россия будет на первом месте среди стран, где можно найти инженеров, способных это сделать, причём дешевле, чем в США или Европе. У нас очень сильная инженерная команда в России, и основная разработка ведётся именно здесь. И это не находится в прямой зависимости от того, что Сбербанк — один из наших крупнейших клиентов, хотя и является тут несомненным плюсом.

Сбербанк, на мой взгляд, один из самых динамично развивающихся в сфере ИТ клиентских банков в мире. Он является примером для подражания для многих компаний как в Европе, так и в России. Многие наши потенциальные клиенты в России внимательно смотрят сейчас на нашу совместную работу со Сбербанком, поэтому я думаю, что с точки зрения продаж этот рынок для нас один из самых важных.

Ирина Тищенко (HR-директор)



— GridGain написан на Java — соответственно, и разработчики у вас джависты, или всё хитрее?

— Конечно, ядро продукта — это сотни тысяч строк Java-кода. Но есть нюансы. Например, модули, обеспечивающие интеграцию нашей платформы с C++ и .NET кодом, написаны, соответственно, на этих языках. Наша красноярская команда разрабатывает консоль управления и мониторинга Apache Ignite / GridGain: это приложение создаётся с использованием различных веб-технологий.
Есть в GridGain и разработчики, одинаково хорошо программирующие на различных языках.

Но главное то, что наши сотрудники — талантливые инженеры, обладающие отличной алгоритмической подготовкой. Одна из основных задач development-команды — это performance. Решение задач оптимизации производительности в распределённой многопоточной системе требует очень серьезных ментальных усилий. Поэтому при выборе сотрудников мы, в первую очередь, ориентируемся на их умение думать, а уже потом на конкретные знания.

— Известно, что ещё в 2006-м основатели GridGain подключили к разработке петербуржцев — а в каких городах сейчас у компании ведётся разработка?

Основной офис разработки GridGain по-прежнему находится в Питере. Но Питером, конечно, российская география нашей компании не ограничивается. Так, веб-консоль управления разрабатывается в Красноярске. Московская и новосибирская команды GridGain, несмотря на то, что их спектр функций намного шире, также участвуют в разработке продукта.

Головной офис GridGain неизменно находится в Silicon Valley. И, в целом, учитывая активнейшее развитие нашей компании, мы совершенно смело можем предположить, что GridGain-у понадобятся разработчики и в Западной Европе, и даже в Азии.

— Вдогонку предыдущему: происходит ли релокация между разными городами?

— Конечно! Как следует из предыдущего ответа, для GridGain нет границ! В нашей команде работают ребята практически со всех уголков России и не только России.
Мы с удовольствием помогаем в релокации, и, как я уже сказала, не скованы в ее направлениях.

— Чего GridGain ждёт от участия в JPoint и JBreak? У GridGain есть упоминавшаяся выше сложность «описать продукт в двух словах проблематично» — а конференции, где тему разбирают куда подробнее двух слов, помогают донести до других разработчиков суть проекта?

ignite.apache.org — вместо тысячи слов! :) А если серьёзно, да, нашим ребятам действительно есть, о чём рассказать. И эти события — хороший повод для нашей встречи с теми, кому интересен и полезен опыт команды GridGain, так сказать, из первых уст.

И в Новосибирск, и в Москву мы едем с докладом о масштабируемости распределённых систем и командой наших сотрудников-разработчиков, которые будут рады диалогу с участниками конференций на стенде GridGain. Посему мы надеемся на шквал вопросов. Мы его не боимся, ведь мы привыкли работать в режиме многопоточности :)




Новосибирцы уже увидели сегодня упомянутый доклад на JBreak (и увлеклись опросом из буклета компании — ответы на него GridGain опубликуют на следующей неделе в своём хабрааккаунте). А посетителям московской JPoint всё это только предстоит — и пока что в ожидании можно вспомнить доклад Владимира Озерова «(Почти) неблокирующая синхронизация» с прошлогоднего JPoint:

Поделиться с друзьями
-->

Комментарии (8)


  1. gltrinix
    05.04.2017 02:26
    +2

    Прошу прощения за, возможно, дилентантский вопрос, но: Apache Ignite может заменить Apache Spark? Или его нужно использовать как Data Source вместо Apache Parquet или Apache Kudu? Или я вообще не понял как им пользоваться?


    1. kuaw26
      05.04.2017 05:34

      В некоторых сценариях — можно заменить Apache Spark.
      В некоторых сценариях — можно использовать совместно с Apache Spark.
      Обычно в Apache Ignite данные закачивают для дальнейшей обработки.


  1. voipp
    06.04.2017 13:03
    +1

    А подскажите, в транзакциях для блокировок у вас используется парадигма Mvcc. Где можно было бы подробнее прочитать о ней?


    1. devozerov
      09.04.2017 21:28
      +1

      Полноценный MVCC появится в ближайшем будущем. В интернете можете найти много статей на эту тему. Если на фундаментальном уровне, то раздел 9 (Transaction Processing, Concurrency Control, and Recovering) отсюда [1]. Только нам это нужно распределенно :-)

      [1] https://www.amazon.ca/Fundamentals-Database-Systems-Ramez-Elmasri/dp/0133970779


  1. p1l1gr1m
    06.04.2017 13:03
    +1

    Но ведь есть Tachyon с которым можно интегрироваться бесшовно, чем IngiteRDD лучше в данном случае для Spark?


    1. p1l1gr1m
      06.04.2017 17:13

      Вдобавок — в целом отличный продукт, великолепная команда, все супер.

      Но очередная статья про Ignite и в конце опять остаётся вопрос — а как это ещё можно использовать, если это не только распределенный кеш?

      Думаю определенно нужна статья с use cases из жизни.


      1. kefirr
        07.04.2017 10:37

        В основе своей Ignite — это база данных, NoSQL+SQL. Соответственно, и использовать можно везде, где нужна база данных.

        Плюс к этому есть compute (map-reduce), передача сообщений, распределённые сервисы (микросервисы, если угодно), всякие интеграции.


      1. gltrinix
        08.04.2017 02:05
        +1

        В дополнении к kefirr: сегодня на JPoint говорили, что в Ignite можно указывать распределение партишенов на кластере, давая разработчику максимальный контроль над данными. Имхо, звучит очень вкусно.