Наряду со способностью обеспечить большую гибкость для приложений с большими данными, контейнеры могут играть важную роль в ИТ-стратегии, которая способствует принятию решений в режиме реального времени.

Контейнерные технологии, впервые разработанные для упрощения развертывания, управления и масштабирования приложений, тем не менее, получили ограниченное применение в системах больших данных из-за более ранних попыток управления состоянием приложений и данными. Но все это начинает меняться, обещая большую гибкость для этих систем.

“Контейнеры можно рассматривать как часть непрерывного упрощения инфраструктуры, расположенного между традиционной монолитной инфраструктурой и безсерверными функциями”, - сказал Джон Грей, технический директор Infiniti Consulting. По сравнению с развертыванием монолитной инфраструктуры, безсерверная инфраструктура может обеспечить большую гибкость и сократить расходы в краткосрочной перспективе, значительно упрощая задачи управления в долгосрочной перспективе.

Но «контейнеры все еще могут делать многие вещи лучше, чем безсерверные функции», добавил Грей. Например, рефакторинг очень больших монолитных приложений все еще лучше подходит для контейнеров. Размещение такого типа приложений в безсерверной производственной среде содержит гораздо больше элементов, чем в старых монолитных приложениях. Контейнеры также предоставляют разработчикам больший контроль над виртуальной средой. По словам Грея, могут пройти годы, прежде чем станет возможным развертывание больших приложений на бессерверных платформах.

«Контейнеры обеспечивают практически немедленное снабжение сложных систем повторяемым и надежным способом», - сказал Монте Цвебен, соучредитель и генеральный директор поставщика платформ данных Splice Machine. С помощью инструментов оркестрации, таких как Kubernetes, контейнеры можно непрерывно контролировать, и они могут активно предпринимать действия по самовосстановлению. Например, если один из узлов в большой распределенной системе данных не отвечает и, таким образом, задерживает вычисления, система может заранее уничтожить поврежденный контейнер и добавить узел, который выбирает то место, где остановился старый.

Помимо конкретных приложений, технологии контейнеров больших данных могут помочь в поддержке ИТ-стратегии, которая обеспечивает интеллектуальную автоматизацию и принятие решений в режиме реального времени, сказал Гордон Ван Хейзен, вице-президент по стратегии платформы в Mendix, создателе платформы для разработки малокодового программного обеспечения. «Он вписывается в более широкий контекст демократизированной науки о данных, итеративного экспериментирования, индивидуальной и командной автономии, а также быстрого масштабирования и является основополагающим компонентом в поддержке этих целей», - сказал он.

Повышение гибкости потоковой передачи данных

“Инструменты, используемые для предоставления приложений больших данных в контейнерах, обычно такие же, как и для других типов приложений, среди которых Docker, Kubernetes, Jenkins и GitLab. Но также важно рассмотреть возможность использования связанных инструментов для потоковой передачи данных”, - отметил Ван Хойзен.

Мало того, что потоковая передача является оптимальным способом выполнения аналитики в реальном времени, она предлагает гораздо более гибкий и свободно сопряженный  подход к более широкому запросу и обработке данных. Например, большие контейнеры данных можно комбинировать с возможностью создавать и управлять конвейерами данных между исходными системами, репозиториями «накопителей данных» и узлами обработки. Соединение контейнеров с технологиями потокового вещания и конвейера с открытым исходным кодом, такими как Apache Kafka, Beam и Airflow, «быстро преобразит способы создания систем, использующих большие данные», - сказал Ван Хуйзен.

По словам Джеффа Берка, старшего вице-президента компании по инженерным разработкам, поставщик инструментов управления данными Collibra использует контейнеры и конвейеры данных в реальном времени, а также потоковые приложения для больших объемов данных, требующих реакции на события в реальном времени. В результате контейнер, содержащий приложения и параметры больших данных в консолидированной среде, может быть распределен быстрее, чем традиционный процесс развертывания этих инструментов на серверах. Все же сложность создания контейнерных сред представляла проблему.

Хотя технологии контейнеров больших данных могут облегчить распределенную обработку, некоторая их ценность теряется, если они зависят от хранилища монолитных данных. Система может показаться модульной, но каждая служба должна записывать в одно и то же общее хранилище.

При масштабировании реляционной базы данных обычной практикой является вертикальное масштабирование путем добавления более крупных устройств хранения и увеличения размера хоста базы данных. Новые базы данных NoSQL, такие как MongoDB, Cassandra и Couchbase Server, построены с горизонтальной масштабируемостью как базовый шаблон для масштабирования без необходимости использования контейнеров. Это позволяет присоединять новые узлы к кластеру базы данных и существующим данным, а также перераспределять запросы между старыми и новыми узлами при увеличении объемов данных.

Кроме того, пояснил Берк, Docker и Kubernetes в сочетании с облачным сервисом, таким как AWS, Google или Azure, могут упростить развертывание кластера базы данных высокой доступности. Такие инструменты, как Presto, Spark и Kafka, по его словам, были созданы с учетом распределенных вычислений большого объема и более дружественны к инструментам на основе Python.

Контроллер YARN, используемый для кластеров Hadoop, ограничивает пользователей инструментами, ориентированными на Java. Используя Kubernetes в качестве уровня оркестровки, можно запускать инструменты анализа данных, такие как Jupyter, TensorFlow, PyTorch или пользовательские контейнеры Docker, в одном кластере.

Проблемы распознавания, содержания и разрешения

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

Другой ключевой вопрос - сохранение данных в контейнере. «Достигнут успех с сохранением данных, но его объединение с большими данными требует осторожности», - сказал Тодд Маттерс, главный архитектор и соучредитель RackWare, поставщика гибридной платформы облачного управления. Он предложил использовать микросервисы в сочетании с большими контейнерами данных. «Архитектура микросервисов может помочь связать процессы больших контейнеров данных и, что более важно, помочь управлять данными как для постоянных данных, так и для данных без сохранения состояния», - пояснил он.

С другой стороны, добавил он, возможность стереть состояние временных метаданных, связанных с обработкой больших данных, может быть полезной. Данные, хранящиеся непосредственно в контейнерах, обычно не являются постоянными, поэтому удобно хранить там временные метаданные. Когда этот процесс завершен, он очищается автоматически.

Кроме того, необходимо решить проблемы управления и инфраструктуры, связанные с технологиями контейнеров больших данных. Вавилапалли сказал, что модели безопасности и сети в системах больших данных отличаются от традиционных веб-приложений. В области больших данных безопасность обычно обеспечивается через Kerberos и краткосрочные токены заданий, в то время как контейнеры используют WebAuth и сертификаты. Точно так же среды больших данных, как правило, проектируются с высокопроизводительным перемещением данных между узлами, стойками и кластерами - что не так уж важно, когда речь идет о контейнерах.

Инструменты управления большими данными также отличаются от технологий управления контейнерами. «Контейнеры - это их новый мир, и для их преодоления потребуется время», - сказал Вавилапалли. «Временные организации должны будут решить, как найти соединяющий эти системы элемент при их совместном использовании до тех пор, пока не появятся правильные и комплексные решения».

Тем временем компаниям придется подумать о написании инструментария для этих систем, который отличается от того, что требуется при обычном развертывании контейнеров на серверах, сказал Цвебен из Splice Machine. С традиционными контейнерами инструментарий может быть таким же простым, как просто проверить контейнер, чтобы убедиться, что он жив. В системах больших данных эти тесты также должны гарантировать, что контейнеры могут выполнять свои функции.

Существуют также проблемы, связанные с изоляцией разных пользователей в мультитенантных средах. «Необходимо убедиться, что арендаторы систем данных достаточно изолированы друг от друга, чтобы один сосед не мешал другому», - пояснил Цвебен.

Проблема заключается в том, что несколько контейнеров могут работать в одной физической системе, и рабочие нагрузки с интенсивным использованием данных могут отрицательно повлиять на использование ЦП, памяти или сети другими контейнерами на одном и том же оборудовании. Хорошей практикой является обеспечение изоляции сети между арендаторами и использование управления ресурсами на основе ролей, чтобы пользователям предоставлялись вычислительные ресурсы, такие как ЦП и память, в соответствии с их ролями.

No Comments