Рост автономных платформ обработки данных или еще раз про Big Data

Большие данные в «Избавлении от иллюзий»

В результатах исследования компании PricewaterhouseCoopers (PwC) в 2016-м говорится, что «индекс стоимости информации» (Information Value Index), характеризующий возможность большого и малого бизнеса извлекать прибыль из больших данных, в среднем составляет 50,1 из 100 возможных баллов.

Эти явно неудачные рейтинги помещают большие данные в зону «Избавления от иллюзий», куда те или иные технологии попадают после спада раздутого интереса к ним. Фактически, в рейтинге PwC лишь 4% компаний набрали более 90 баллов. Чтобы достичь таких результатов, им пришлось внедрить надёжные фреймворки управления данными, создать сильные культуры принятия решений на основе данных, и обеспечить безопасность доступа к корпоративным данным для тех сотрудников, которым это необходимо.

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

Главная причина неудач — сложность

Технология больших данных сложна. Очень сложна. Тому есть ряд причин. Во-первых, вы пытаетесь решать трудные проблемы с использованием огромных — почти неподъёмных — массивов данных. При этом open source-технологии, используемые для внедрения больших данных, обычно разрабатываются с учётом гибкости применения. Это не коммерческие продукты, у них более низкий уровень поддержки и обслуживания. Они не создаются в качестве готовых решений конкретных проблем. И именно по причине своей гибкости они могут быть трудны и сложны в развёртывании.
Кроме того, при использовании open source-инструментов приходится иметь дело с многочисленными «подвижными частями» (moving parts). Шесть лет назад нам нужно было беспокоиться только о Hadoop. А сегодня у нас park, Presto, Hive, Pig, Kafka и много других инструментов. Все они часто изменяются. У Spark было шесть значимых релизов с начала 2015-го. Hive за последние годы тоже прошёл через несколько итераций основных изменений.

Поэтому для своевременного поддержания инфраструктуры больших данных на уровне последних версий и для исправления багов всех этих open source-продуктов требуется очень много человеко-часов, из-за чего страдает производительность работ.

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

Современные решения проблем, возникающих перед корпоративными инициативами по работе с большими данными

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

Перекомпоновка open source-технологий

Некоторые вендоры перекомпонуют open source-технологии, чтобы уменьшить их сложность для бизнеса. Например, они могут компоновать свои решения с учётом конкретных способов применения. Это уменьшает сложность, потому что предлагаемое решение предназначено для решения конкретной задачи, а не является универсальным средством для работы с большими данными. Но у этого подхода есть обратная сторона: для создания и запуска проекта может понадобиться несколько таких специализированных решений. Например, если вы собираетесь заниматься обработкой данных, а также их преобразованием и анализом, то придётся купить три более мелких перекомпонованных решения. А их суммарная сложность может оказаться ничуть не меньше, чем у одного универсального решения.

Программы для быстрого старта

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

Безкластерные решения

Есть вендоры, пытающиеся скрыть сложность путём отделения основной инфраструктуры от рабочей нагрузки — они исключают само понятие кластеров.
Если вы используете on premise-инфраструктур для работы с большими данными, то обычно используете несколько больших кластеров (например, один для разработки/тестирования, второй для production). Но очень непросто распланировать совместное выполнение нескольких задач в кластере ради максимизации эффективности использования, а следовательно и ROI. С другой стороны, если вы сделали ставку на облако, то можете, к примеру, использовать его адаптивность: сформировать 20-серверный кластер, использовать его четыре часа, а затем расформировать. Так вы сможете гибче управлять расходами и производительностью.

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

В качестве решения данной проблемы многие вендоры сегодня предлагают «безкластерные» решения. Amazon Athena, облачное хранилище данных Snowflake и Cloudera Impala (на данный момент «инкубаторный» проект Apache) — все они отказались от концепции кластеров. Вам достаточно просто указать продукт для ваших данных и начать выполнять запросы.

Безкластерные решения просты в управлении. Однако все они имеют многоклиентскую (multitenant) структуру, то есть всех пользователе обслуживает одна общая инфраструктура. Так что хоть они и замаскировали идею кластера, по сути это всё тот же набор серверов, на которых крутится ПО, которое используют многочисленные пользователи. И большинство из них даже не являются вашими коллегами. Поэтому вендоры безкластерных решений внедряют определённые ограничения, чтобы ваша рабочая нагрузка не помешала выполнению задач многочисленного окружения. Это снижает гибкость применения: приходится ограничивать количество запросов, чтобы они не потребляли слишком много ресурсов. В сущности, сложность скрывается от пользователей, но снижается управляемость с точки зрения IT. Это влияет и на стоимость, и на соглашения об уровне использования (service-level agreements).

Люди

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

В 2015-м было проведено исследование, согласно которому 79% компаний отметили нехватку специалистов большим данным. В 2016-м ситуация ухудшилась. Уже 83% респондентов отметили трудности в поиске необходимых талантов.

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

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

Однако из-за сложности big data придётся нанимать дополнительных сотрудников каждый раз, когда вы будете добавлять новый тип рабочей нагрузки, или вводить новый метод использования технологии. А люди — ресурс не масштабируемый. Добавив в команду одного человека, вы не получите прирост эффективности как от одного человека. Вы получите меньше из-за накладных расходов на коммуникации, сотрудничество, процессы, управление, администрирование и HR.
Сложность — бесшумный убийца больших данных, и причина того, почему в долгосрочной перспективе не получится делать ставку на использование человеческого ресурса.

Рост интеллектуальных, автономных платформ обработки данных

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

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

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

Автономные платформы будут развиваться по трём стадиям. Сначала будут автоматизированы предупреждения, выводы и рекомендации. Затем придёт автоматизация на основе политик. И наконец, мы получим полностью автономные платформы. Да, сегодня это лишь концепция. Но она будет реализована.

Предупреждения, выводы и рекомендации

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

Автоматизация на основе политик

Автоматизация на основе политик — это когда вы даёте инфраструктуре набор руководств или конфигурационных параметров, на основе которого система совершает какие-то действия. То есть вы настраиваете политику, а система действует в соответствии с ней.
Например, можно настраивать политики для «покупки» вычислительных мощностей, чтобы обеспечить оптимальность расходов. В большинстве случаев кластеры формируются на основе какого-то одного типа серверов (по сочетанию процессора, памяти и дискового объёма). Причина в том, что лежащая в основе технология изначально создавалась для on-premise развёртывания, когда IT приобретает для ЦОД идентичные серверы.

В облаках же провайдеры предлагают много конфигураций из разных машин, для каждой из которых есть свои рекомендуемые цены. AWS на «спотовом рынке» продаёт на аукционах неиспользуемые мощности, и вы можете делать свои ставки на ноды. Нередко спрос на AWS бывает так низок (например, посреди ночи), что купить ноды можно за 10% от обычной стоимости. Круто, да? Но есть два «но». Во-первых, если спрос высок, вы можете не найти на спотовом рынке подходящие серверы, потому что наличие может сильно меняться. Во-вторых, AWS может конфисковать у вас спотовые ноды, если другой клиент пожелает заплатить цену «по требованию» (обычную цену). Поэтому спотовый рынок — вещь непредсказуемая, нет гарантий, что вы будете использовать нужные вам ноды в течение необходимого времени.

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

Полностью автономная автоматизация

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

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

Сложность душит большие данные, но будущее представляется светлым

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