.jpg)
Большие Данные открывают новые перспективы как для крупных, так и для малых компаний по выявлению новых возможностей улучшения сервиса для клиентов, повышения эффективности различных процессов, выявления прежде незамеченных типовых шаблонов и т. д. Однако, для того чтобы воспользоваться преимуществами Больших Данных, помимо аналитического программного обеспечения необходима соответствующая инфраструктура для хранения, обработки и передачи данных.
Ввиду огромных объемов данных особое значение приобретает инфраструктура для их хранения и обработки. Немногие компании и организации располагают необходимой для этого емкостью. Но проблема заключается не столько в нехватке дискового пространства, сколько в неадекватности традиционных хранилищ для задач Больших Данных. Вопросы выбора и построения необходимой инфраструктуры рассматривались на отдельной тематической секции «Решения для хранения и обработки данных» в ходе форума BIG DATA 2017, организованного издательством «Открытые системы».
Платформа для хранения Больших Данных должна решать две во многом противоположные задачи. «Те задачи, которые решало классическое хранилище, находятся где-то посредине между онлайн-данными и данными долгосрочного хранения», — отметил Александр Ермаков, ведущий системный архитектор IBS. Ценная информация может содержаться как в данных, которые поступают в реальном времени и на которые надо отреагировать мгновенно, так и в данных, которые накапливаются годами и в которых содержится богатая история. Современные архитектуры хранения эффективно справляются с обеими нагрузками.
Сейчас получила признание идея озер данных, куда можно записывать данные из множества источников в исходном виде и эффективно обрабатывать. Архитектура озера данных значительно эволюционировала. Теперь она предполагает наличие еще одного уровня обработки — уровня памяти, или Speed Layer. Он добавляет новые возможности обработки данных в потоке реального времени. Для распределения потоков данных между различными уровнями хранения и обработки добавлены очереди, потоковая загрузка и т. д.
Память становится все более дешевой и емкой, и поэтому растет популярность систем класса In-Memory Data Grid. «Они содержат в себе только уровень обработки данных в памяти, а все остальные элементы наподобие Hadoop и HDFS будут использоваться как постоянное хранение», — рассказывает Ермаков. Таким образом, архитектура для обработки и хранения Больших Данных постоянно усложняется — она может насчитывать десятки, если не сотни компонентов.
Чтобы упростить развертывание систем обработки Больших Данных, предлагается множество решений. Так, IBS на основе опыта внедрения различных проектов создала аналитическую платформу ArenaData с открытым исходным кодом. В компании ее появление объясняют тем, что заказчикам часто не хватало тех или иных компонентов, имеющихся в одних и отсутствующих в доступных дистрибутивах Hadoop. Платформа содержит все необходимые компоненты для управления данными, доступа к ним, анализа, интеграции, безопасности и администрирования. ArenaData прошла сертификацию ODPI (Open Data Platform Initiative).
Готовую интегрированную систему Data Lake & Analytics Factory для быстрого развертывания Больших Данных предлагает компания Bull. В этом программно-аппаратном комплексе используется ПО Atos и озеро данных на базе сервера Bullion. Как отметил Роман Гоц, директор Bull в России и СНГ, комплекс позволяет запускать озеро данных и аналитические среды на одном аппаратном обеспечении, благодаря чему повышается гибкость работы и снижается совокупная стоимость владения. Серверы Bullion имеют модульную конструкцию и линейно масштабируются от 2 до 16 сокетов.
Масштабирование как по емкости, так и по производительности имеет первостепенное значение для хранения Больших Данных. Именно этот критерий был поставлен на первое место при разработке системы хранения «Полибайт» (международное название — Resilient Cloud Storage) российской компанией RCNTEC. Как отметил в своем выступлении Евгений Лаптев, системный архитектор RCNTEC, возможности наращивания систем хранения с традиционной архитектурой ограниченны, при достижении определенного объема данных приходится переходить на систему более высокого класса.
«Полибайт» имеет горизонтально масштабируемую архитектуру (scale-out). В ней нет централизованных контроллеров, через которые проходит весь трафик, каждый универсальный дисковый модуль оснащен собственным типовым контроллером. Если нужно увеличить емкость или производительность системы, просто устанавливают дополнительные модули. Каждый базовый модуль высотой 1U вмещает до 14 жестких дисков емкостью до 10 Тбайт каждый. Для сохранности данных вместо RAID предусматривается хранение трех копий (реплик данных). По словам Лаптева, такой же принцип обеспечения отказоустойчивости используют Google и Amazon. Благодаря этому достигается доступность данных и необходимая производительность при выходе из строя до двух третей ее компонентов.
Принцип горизонтального масштабирования реализован и в системе EMC Isilon. По словам Михаила Владимирова, технического специалиста компании EMC, Isilon использует уже около сотни российских заказчиков, причем многие — для Hadoop и аналитики. Как и в «Полибайт», в Isilon предусмотрена возможность создавать множественные реплики данных. Однако Михаил Владимиров считает, что при таком подходе неэффективно используется доступное место, к тому же он ведет к дополнительным расходам на электроэнергию и охлаждению. По его мнению, использование кодов Рида-Соломона куда эффективнее с точки зрения хранения. Их использование позволяет обеспечить защиту от отказа до четырех узлов, каждый из которых вмещает до 59 дисков (пока диски 10 Тбайт не поддерживаются, но компания намерена реализовать их поддержку). Однако на практике заказчики ограничиваются резервированием по схеме N+2.
Вместо построения собственной инфраструктуры компания может переложить задачу хранения данных на облачного провайдера или провайдера ЦОД. Но и это нетривиальная задача, показывает опыт латвийского оператора Lattelecom. Как рассказал Сергей Пшеничных, руководитель отдела продаж Lattelecom, при тестовом запуске интернет-магазина для одной российской розничной сети потребовалось решить немало вопросов, при том что для его размещения использовалась современная облачная платформа на базе решений Cisco и HPE.
Заказчик решил разместить магазин в публичном облаке Lattelecom, отказавшись от построения частного. Как оказалось, используемое решение для противодействия DDoS-атакам, построенное на оборудовании Radware, восприняло поток запросов к интернет-магазину как начавшуюся атаку. Надо сказать, что в Латвии самый крупный и посещаемый интернет-магазин, который также размещен в ЦОД Lattelecom, рассчитан на обслуживание порядка 10 тыс. уникальных посетителей. Поэтому 50 тыс. одновременных сеансов система Radware восприняла как аномалию и стала их блокировать.
Клиент Lattelecom перед открытием провел нагрузочное тестирование, эмулировав поток потенциальных покупателей, что позволило устранить проблему до начала эксплуатации магазина. Чтобы сетевая подсистема могла справиться с большими потоками данных, Lattelecom пришлось ее перестроить. В частности, теперь каждому клиенту предоставляется свой виртуальный маршрутизатор. В случае DDoS-атаки на него остальные клиенты ЦОД не будут затронуты.