Согласно прогнозам IDC, мировой рынок больших данных и бизнес-аналитики вырастет в нынешнем году на 12% и достигнет 189 млрд. долл., а в 2022 г. он выйдет на уровень 274 млрд. долл. Обсуждение таких инновационных технологий, как Big Data и искусственный интеллект (ИИ), вполне логично концентрируется на вопросах их применения для решения практических задач и реализации оригинальных бизнес-моделей. При этом в тени оказываются проблемы построения оптимального ИТ-фундамента, необходимого для достижения желаемого результата, в том числе инфраструктуры хранения и обработки таких данных.
Во многих компаниях есть унаследованная инфраструктура, и им необходимо принимать решения о том, как лучше всего использовать или модернизировать существующие ИТ-активы и что придется создавать с нуля. Сегодня нередко модернизация инфраструктуры по объективным причинам сопровождается распространением ее на распределенную гибридную облачную среду. Для обсуждения всех этих вопросов мы обратились к экспертам из ведущих российских ИТ-компаний.
Какая нужна инфраструктура?
Прежде всего хотелось бы понять, какова специфика ИТ-инфраструктуры для работы с большими данными, для их анализа и использования в решениях на основе ИИ? Какие изменения потребуются корпоративным ЦОДам, уже использующим стандартные инструменты виртуализации и программного конфигурирования ИТ-ресурсов?
«Как известно, под термином Big Data скрывается множество технологий, подходов, задач и методов их решений, — рассуждает руководитель группы перспективных технологий предпроектного консалтинга Oracle в России и СНГ Андрей Пивоваров. — Поэтому рассматривать общие требования к инфраструктуре для абстрактных Big Data не очень правильно. Изначально, когда этот термин только набирал популярность, существовало мнение, что для больших данных в основном подходит Hadoop, полезный для ситуаций, когда данных очень много и при этом требуется большая вычислительная мощность для их обработки».
Он убежден, что требования к инфраструктуре сильно зависят от присущих той или иной задаче узких мест. Например, существуют задачи, которые требуют относительно мало данных, но предъявляют очень высокие требования к оперативной памяти или процессорам. В этом случае нет каких-то особых требований к СХД, но зато появляется, например, необходимость поддержки графических процессоров (GPU) для обучения нейросетей. Бывает так, что периодически нужно обсчитывать и строить какую-то сложную, ресурсоемкую модель, само применение которой требует в десятки и сотни раз меньше ресурсов, и тогда во весь рост встает проблема неравномерного их использования. В этом случае, возможно, не имеет смысла покупать мощное оборудование, а лучше использовать облачные платформы.
Принято считать, что большие данные — это массивы слабоструктурированных или по-разному структурированных данных, в которых количество записей исчисляется сотнями миллионов, а объем данных — петабайтами. По мнению руководителя направления «Инфраструктурное ПО» компании Axoft Сергея Игнатова, в таких случаях использование классических СХД может быть нерациональным, поскольку они имеют пределы масштабирования и характеризуются весьма высокой стоимостью в расчете на терабайт и IOPS. Сейчас все большую популярность приобретают гиперконвергентные инфраструктуры и хранилища, способные использовать имеющиеся серверные ресурсы заказчика. Такие инфраструктуры обладают высокой масштабируемостью и предоставляют гибкие возможности управления производительностью с минимальными затратами и разумной защитой вложений в текущую инфраструктуру. Практически все эти возможности обеспечивает софт, установленный на классические серверы, соединенные между собой через обычные сетевые коммутаторы.
Эксперты компании КРОК напоминают, что специфика ИТ-инфраструктуры для Big Data заключается в потребности недорогого хранения больших объемов данных. Для этого применяются архитектуры распределенного хранения с горизонтальным масштабированием, например на основе HDFS. ЦОДы могут использоваться те же, но для больших данных понадобятся другие серверы с большим объемом локальных дисков, ОЗУ и числом ЦПУ. Специализированные программно-аппаратные комплексы создаются для ИИ. Здесь важны вычислительные мощности, в них используются GPU и требуется быстрый доступ к данным. Программная инфраструктура строится, как правило, на решениях с открытым кодом. Поскольку в таких системах применяются специализированные ускорители на базе графических процессоров, чаще всего они создаются с нуля. При этом они мало затрагивают остальную инфраструктуру корпоративных ЦОДов.
Директор департамента ТЭК компании RedSys Павел Миронов полагает, что в подобных решениях необходимо использовать суперкомпьютерную архитектуру, включающую как традиционные процессоры, так и GPU, или же строить высокопроизводительные вычислительные системы (HPC) на базе графических ускорителей. Иными словами, большинству действующих корпоративных ЦОДов потребуется модернизация аппаратных компонентов. Системы Big Data/ИИ предъявляют также высокие требования к оперативной памяти, поскольку большинство операций происходит именно в ней. Кроме того, для эффективной работы с оперативной памятью необходима модернизация программных инструментов виртуализации и конфигурирования.
Директор по продуктам и сервисам компании PROMT Борис Тихомиров обращает внимание на то, что требования к инфраструктуре постоянно растут, поскольку непрерывно увеличиваются запросы бизнеса к получаемым результатам, скорости работы, объемам данных, способам их анализа, применяемым технологиям. Например, традиционный подход предполагает, что большие массивы данных сначала накапливаются, а потом анализируются, а более продвинутая концепция дает возможность анализа относительно больших объемов в реальном времени, в частности за счет технологий in-memory. Все это делает ИТ-инфраструктуру весьма сложной, затратной и требующей высококвалифицированных специалистов для ее поддержки.
Есть ли отраслевая специфика?
Зависит ли подобная инфраструктура от области применения, отраслевой специфики, масштаба решения, нормативных требований? Каковы особенности такой инфраструктуры в облачных, онпремисных и гибридных конфигурациях?
«Инфраструктура всегда зависит от области применения, — считает Сергей Игнатов. — Но мир идет к максимальной унификации ее компонентов, а специфику все больше задает управляющий софт — ведь мы уже давно вошли в эру программно-определяемых инфраструктур. Унификация инфраструктуры и программная определяемость ее функционала существенно облегчают формирование однородных гибридных решений, когда вы не замечаете разницы в использовании локальной или облачной инфраструктур и управлении ими».
Эксперты компании КРОК подтверждают, что инфраструктура больших данных варьируется в зависимости от отрасли и источников информации и может размещаться как в облаке, так и на предприятии. В публичном облаке важно минимизировать влияние задач разных заказчиков друг на друга. Вполне возможны гибридные сценарии: например, озеро данных, содержащее большой массив исходной информации, может размещаться на площадке заказчика, а хранилище с аналитическими моделями и инструменты анализа — в облаке. Архитектура системы существенно зависит от вида и масштаба задачи, а также от объема обрабатываемых данных. Самая сложная и ресурсоемкая задача — подготовка данных и обучение моделей, а также их обновление. Для этого требуются высокие вычислительные мощности либо в собственном ЦОДе, либо у внешнего провайдера. Дальнейшая работа на обученной модели может осуществляться на «обычных» мощностях в режиме реального времени, в том числе на удаленных площадках, там где данные генерируются и хранятся.
В качестве примера отраслевой специфики Павел Миронов приводит электроэнергетику, где приходится анализировать огромные потоки ограниченного набора показателей (напряжение, сила тока, сопротивление, температура). Нефтегазовая индустрия, напротив, отличается значительным разнообразием данных, высокими требованиями к последовательным и параллельным вычислениям. Медицина требовательна к активному использованию помимо поступающих исходных показателей еще и громадного объема накопленных знаний. Без вовлечения этих знаний анализ исходных данных и построение выводов только на их основе невозможен.
Отсюда следует, что в электроэнергетике лучше использовать онпремисную инфраструктуру, в которой для хранения и быстрого извлечения однотипных мгновенных замеров за большой промежуток времени с целью их обработки и составления прогнозов подойдет Hadoop. В нефтегазовой отрасли, где поток данных значительно меньше, но высока степень разнообразия типов данных и их атрибутов, наиболее предпочтительна гибридная архитектура. В медицине, где применяются совершенно другие инструменты анализа больших данных и ИИ (включая машинное и глубокое обучение) и важно накопление самой разнообразной информации от множества источников, лучше подойдет облачная архитектура, которая соберет под свое крыло множество клиентов с похожими запросами по медицинской аналитике.
СХД и распределенная обработка данных
Работа с большими данными предполагает их распределенную обработку и хранение. Какие варианты распределенных СХД (гибридных, облачных и мультиоблачных, включающих ресурсы провайдеров внешних данных, поддерживающих периферийные вычисления) целесообразно применять для решения тех или иных задач? Предлагают ли вендоры готовые решения? Какова здесь может быть роль системных интеграторов?
По мнению Сергея Игнатова, хранить и обрабатывать большие данные в собственных локальных ЦОДах могут позволить себе очень немногие компании, поэтому здесь не обойтись без облаков. Глобализация облачных инфраструктур, в том числе так называемая мультиоблачность, дает невиданные прежде возможности по извлечению пользы из гигантского количества накопленной человечеством информации. Вся суть сегодняшней индустрии Big Data заключается не в хранении огромных массивов данных, как многие до сих пор думают, а в дата-майнинге и аналитике залежей информации, которая благодаря этому наконец-то стала приносить пользу.
Эксперты компании КРОК обращают внимание на то, что когда речь заходит о больших данных, то имеется ввиду стек конкретных технологий, таких как технологии из экосистемы Hadoop или массивно-параллельные СУБД, подобные Greenplum, Vertica и т. д. Данные технологии для обеспечения максимального горизонтального масштабирования изначально построены в архитектуре shared-nothing. Это в существенной степени подразумевает применение локальных дисков на уровне узлов без единой централизованной СХД. И если посмотреть на практику применения, то в большинстве развертываний используют именно такой подход. Несмотря на то что данные внутри организации могут храниться в различных системах и могут быть распределены, обрабатываться они должны внутри одного программно-аппаратного комплекса: аналитической платформы data warehouse для структурированных данных или Hadoop — для неструктурированных.
Павел Миронов предупреждает, что хотя вендоры и предлагают готовые аппаратные решения, готовых программно-аппаратных комплексов нет. Есть неизменяемые компоненты таких комплексов, как, например, SAP HANA, предлагающая быструю обработку в оперативной памяти, но не предоставляющая самих инструментов анализа. В этой ситуации, когда конечные заказчики пытаются работать с вендорами напрямую, роль системных интеграторов весьма высока. И обусловлена она именно тем, что нет вендоров, предлагающих эффективную законченную ИТ-архитектуру для определенной отрасли. Системные интеграторы должны, исходя из задач заказчика, предоставить собственную экспертизу по анализу и подбору правильной ИТ-архитектуры и выбору эффективных программных средств. Системному интегратору придется становиться своеобразным бизнес-ИТ-интегратором, глубже понимающим конкретную отраслевую задачу. Невозможно подобрать ИТ-архитектуру, основываясь только на глубоком знании информационных технологий.
Андрей Пивоваров утверждает, что изначально популярность технологии Hadoop была связана с ее способностью хранить данные в десятки раз дешевле по сравнению с СУБД. Однако в последние годы в лидеры по дешевизне хранения данных (при этом без потери возможности их обрабатывать в любое время) выходят облачные объектные хранилища. Тем не менее Hadoop все еще является лидером в мире Big Data. Следует помнить, что крупный кластер Hadoop — это огромное количество серверов, которые нужно обслуживать, апгрейдить, патчить, конфигурировать, ремонтировать и т. д. Из-за этого существенно вырастают затраты компании на поддержку инфраструктуры и опенсорсный Hadoop становится не таким уж бесплатным. С учетом данного обстоятельства имеет смысл рассмотреть возможность приобретения специализированного оптимизированного аппаратно-программного комплекса, поскольку в этом случае большую часть работы по поддержке как программной, так и аппаратной инфраструктуры вендор возьмет на себя, а заказчик сэкономит время и ресурсы.
Еще одной проблемой может стать сложность сайзинга оборудования. В зависимости от множества обстоятельств требования к оборудованию могут вырасти во много раз всего за несколько месяцев. А могут и не вырасти. При планировании ресурсов на несколько лет вперед возможна ошибка в любую сторону. Можно закупить слишком мало или слишком много. Это еще один аргумент в пользу облачных инфраструктур, которые позволяют использовать ресурсы по мере необходимости.
Нужна ли специальная интеграция СХД и СУБД?
Наряду с уровнем хранения и первичной обработки больших данных методами MapReduce в системах Big Data специфические требования предъявляются к уровню БД, на котором осуществляется аналитическая обработка тех или иных выборок из общего массива. Каким требованиям должна удовлетворять СХД, поддерживающая оба указанных уровня?
По мнению экспертов компании КРОК, современные системы Big Data предоставляют и уровень обработки, и уровень хранения. Например, если говорить про Hadoop, то в качестве инструментов обработки служат MapReduce или Spark, в случае же с Greenplum сама СУБД выступает и в роли средства хранения, и в роли механизма исполнения запросов. Что касается требований к дисковой подсистеме, то в первую очередь — это большая пропускная способность на уровне узла. Так как указанные системы базируются на принципе локальности вычислений, большую часть обработки они стараются выполнять на том же узле, где расположены данные. При этом основная идея здесь заключается именно в увеличении степени параллельности операций чтения и вычислений.
Следует отметить, что сегодня при проектировании таких систем принято ставить во главу угла либо вычислительную производительность, либо хранение больших объемов данных, либо некий баланс между первым и вторым. При этом подбираются оптимальные соотношения по количеству процессорных ядер, а также числу, размеру и производительности дисков. Нередко проектируются и смешанные решения, где в рамках одной системы имеются сразу несколько областей хранения с разными требованиями по производительности и шаблонам обращений к данным. Павел Миронов обращает внимание на то, что некоторые задачи требуют ухода от традиционных реляционных СУБД к базам данных с поколоночным хранением и к проведению всех операций с данными в оперативной памяти.
Большие данные = большие затраты?
Обязательно ли работа с большими данными требует и больших расходов на инфраструктуру их хранения и обработки? Каковы возможности оптимизации затрат для тех или иных областей применения?
Как считают эксперты компании КРОК, большие расходы вовсе не обязательны. Уменьшить затраты на инфраструктуру позволяет то, что такие решения можно строить горизонтально масштабируемыми на открытых платформах. Однако стоит учитывать, что для сокращения сроков внедрения, уменьшения рисков и снижения затрат на дальнейшую поддержку системы в некоторых случаях экономически более целесообразно использовать готовые оптимизированные решения.
По мнению Павла Миронова, самые большие затраты приходятся на сбор и хранение больших объемов данных с учетом требований их быстрого извлечения для анализа. Отсюда следует, что наиболее затратны отрасли электроэнергетики или телекоммуникаций. Здесь необходимы и СХД на флэш-носителях, и скоростная передача данных, и большие объемы оперативной памяти — все это стоит дорого и наименее подвержено падению стоимости. Нефтегазовой и медицинской отрасли в большей степени нужны вычислительные ресурсы, которые дешевеют значительно быстрее, да и капитальных вложений там в разы меньше.
С его точки зрения, наиболее эффективный инструмент оптимизации затрат — это качественно работающий механизм выделения ресурсов по требованию, который включает быструю обработку заявки на выделение ресурса и быстрое его высвобождение, а также инструменты динамического изменения выделенных ресурсов.
«Все зависит от деталей, — убежден технический директор представительства компании NetApp в России Роман Ройфман. — Традиционно аппаратные решения для работы с большими данными достаточно бюджетные. Зачастую кластеры Hadoop базируются на стандартных недорогих аппаратных компонентах с использованием JBOD на SATA-дисках, установленных непосредственно в DataNode. При этом защита данных переносится на уровень репликации в HDFS. Общепринятая практика — хранение трех копий данных».
Кажется, все прекрасно: железо дешевое, механизмы HDFS стандартны, отмечает эксперт. Однако когда заказчик разворачивает инфраструктуру с общепринятым фактором репликации, равным трем, то для каждого петабайта данных, загруженных в кластер Hadoop, нужно обеспечить копирование по сети еще двух петабайтов. Это отражается на стоимости и, что более важно, сказывается на времени загрузки данных, так как два из трех петабайт копируются только для обеспечения их сохранности. Альтернативные механизмы, например erasure coding, помогают снизить накладные расходы на хранение данных, но вносят дополнительные издержки на сеть и ресурсы процессора.
По словам Романа Ройфмана, в больших инсталляциях Hadoop пользователи иногда идут на риск при загрузке данных с фактором репликации, равным одному, просто потому что это быстрее. В дальнейшем они или оставляют фактор репликации неизменным или снижают риски потери данных, увеличивая указанный фактор. Перенос задач сохранности данных на СХД уровня предприятия позволяет уменьшить число хранимых копий, снизить нагрузку на сеть и повысить производительность кластера. Другой причиной использования промышленных СХД вместе с кластерами Hadoop является возможность применения функционала In-Place Analytics, который позволяет отказаться от создания избыточных копий и мгновенно создавать наборы данных«.
Борис Тихомиров напоминает, что сейчас происходит бум нейросетевых технологий, в том числе в области машинного перевода — одного из направлений искусственного интеллекта. И применяемая технология такого рода непосредственно влияет на инфраструктуру решения. Если используются классические алгоритмы машинного перевода (перевод по правилам), то аппаратные требования минимальны. Решения такого рода переводят фантастически быстро (доли секунд для фрагментов текстов и секунды для больших документов), и все это на весьма скромных мощностях. Но при переходе к нейросетевым технологиям требования возрастают в разы, соответственно решения становятся дороже. Поэтому все определяется тем, какая задача решается и что является приоритетным: скорость перевода, его качество, объемы контента, безопасность или стоимость.
Нужны ли большим данным флэш-СХД?
Мы являемся свидетелями бурного роста популярности СХД, базирующихся на флэш-технологиях. В какой степени высокая цена твердотельных накопителей ограничивает применение флэш-систем для работы с Big Data? В каких случаях их использование дает реальный выигрыш?
По мнению экспертов компании КРОК, для задач оперативной аналитики использование флэш-накопителей оправданно. Например, для быстрого определения профиля клиента или для оперативной аналитики на данных за текущий день. Но поскольку стоимость флэш-технологий весьма высока, строятся смешанные решения, где на флэш-системах хранится только часть данных. Продолжением развития этой идеи является использование систем in-memory, когда все обрабатываемые данные хранятся в оперативной памяти. Цена твердотельных накопителей продолжает уменьшаться, и ожидается, что уже в ближайшие годы произойдет полный переход на флэш для решения front-end-задач. Уже сегодня использование флэш-систем совместно с технологиями сжатия и дедупликации дает значительный выигрыш для работы с большими данными в производительности, а нередко также в стоимости и объеме хранения.
Роман Ройфман, напротив, убежден, что в целом технология Flash для работы с большими данным не является базовой ценностью, поскольку обычно все ограничивается стандартными NL-SAS/SATA-дисками внутри серверов кластера. При этом в последнее время все чаще появляются решения, где массивы All Flash становятся органической частью архитектуры. Как правило, это не механическая замена внутренних дисков, а более глубокая переработка архитектуры с переходом на In-Place Analytics.
«В любой технологии есть свои плюсы и минусы, — рассуждает Павел Миронов. — Плюс флэш-технологии — значительно лучшие показатели на операциях чтения, нежели у традиционных жестких дисков. Поэтому наиболее востребованной флэш-технология будет в таких отраслях, как электроэнергетика и телекоммуникации. В нефтегазовой отрасли ситуация иная, поскольку там ведутся процессы обработки данных и моделирования, в которых постоянно используются операции и чтения, и записи. Например, обработка сейсмических данных порождает практически тот же объем данных, что и у исходного массива. Задачи, связанные с гидродинамическим моделированием, формированием нейронных сетей, порождают объем данных даже больше, чем входной. Поэтому применение флэш-систем там невыгодно. Иными словами, их использование дает реальный выигрыш в случае существенного преобладания запросов на чтение».
Сергей Игнатов напоминает, что большие системы хранения данных всегда были и будут многоуровневыми с разными показателями по скорости доступа и объему хранения на каждом уровне. Флэш-системы становятся все доступнее, но используются по большей части в онлайн-обработке массивов информации с большим количеством записей, но с малым общим объемом (например, баз данных). За ними всегда стоят пулы или целые системы хранения на медленных, но очень емких дисках, на которых хранится вся неоперативная информация (в частности, медиафайлы, ссылки на которые содержатся в БД).
«Стоимость аппаратных конфигураций систем с использованием SSD тем выше, чем больше объем требуемого дискового пространства, — констатирует Борис Тихомиров. — При небольших и средних объемах данных стоимость аренды или владения сервером с использованием флэш-систем примерно в полтора раза выше, чем для конфигураций с обычными HDD. Так, в задачах статистического машинного перевода на этапе выполнения непосредственно перевода, где важна скорость чтения данных, но нет высоких требований к их объему, применение SSD более чем оправданно. Здесь достигается двукратный выигрыш в производительности».
Нужна ли Big Data как услуга?
Общие достоинства облаков хорошо известны. Но в какой степени современные облачные инфраструктуры готовы к предоставлению Big Data как услуги? Готова ли нормативная база? Есть ли реальный спрос на такие сервисы со стороны как крупных компаний, так и СМБ?
По мнению экспертов компании КРОК, особых проблем здесь нет, такие сервисы уже давно существуют и прекрасно развиваются.
У Павла Миронова иная точка зрения: «Нет, к сожалению, не готовы. Провайдеры предоставляют, как правило, обычное облако с основными сервисами виртуализации. Никаких услуг и сервисов Big Data не предлагается. Я говорю, прежде всего, о российских поставщиках услуг. Основные проблемы связаны, как ни странно, не с нормативной базой. Традиционно в России ограничения по использованию внешних облачных решений налагают службы безопасности. Поэтому основное препятствие на пути развития данного сектора услуг — это неадекватная строгость к перемещению данных вовне со стороны служб безопасности. Конечно, проще запретить, чем прилагать усилия к нахождению баланса между безопасностью и потребностями бизнеса. Последнее слово остается за владельцами предприятия. Ввиду того, что финансово стабильным у нас пока является только крупный бизнес, этот фактор, видимо, еще будет долго оказывать заметное влияние на развитие облачных сервисов Big Data».
Сергей Игнатов уточняет, что современные облачные инфраструктуры предоставляют не Big Data, а гипермасштабируемые мощности для хранения и обработки, а также специализированные фреймворки для извлечения и аналитики больших данных. Спрос, несомненно, есть. Например, крупные финансовые и торговые компании, работающие в розничной сфере, значительно улучшают таргетирование своих товаров и услуг на перспективного покупателя, существенно экономя на классических маркетинговых исследованиях и кампаниях. А самое привлекательное в облачной модели — это то, что данная услуга доступна и для компаний уровня СМБ, не требуя от них больших капитальных затрат.
