Почему компании переносят обработку данных в облако?
Когда компании принимают решение о переносе своей инфраструктуры в публичное или частное облако или о ее расширении за счет публичных мощностей, они зачастую выбирают «легкий путь». Он заключается в перемещении отработанных годами подходов в новую технологическую среду без каких-либо заметных преобразований. Просто, понятно и не требует больших бюджетов на разработку.
Такой сценарий имеет право на жизнь, но часто приводит к тому, что компании не могут в полной мере ощутить преимущества от перехода. Они продолжают использовать те же файловые системы, те же СУБД, те же серверы, объединенные в те же кластеры. И прежние подходы к работе. Прямая трансляция унаследованных монолитных решений в новую среду может дать некоторую выгоду в плане надежности и утилизации. Но все же ее следует рассматривать только как переходный этап по переезду в облако, за которым следует модернизация уже самой архитектуры системы. Современные облака предоставляют принципиально иные и куда более эффективные возможности по организации вычислений и хранения данных.
Традиционный подход предполагает, что клиент разворачивает привычные системы для работы с данными «над» инфраструктурой, используя облако в режиме «инфраструктура-как-услуга» (IaaS). В роли таких систем могут выступать Hadoop, Greenplum, Vertica и другие средства, и после развертывания их требуется постоянно поддерживать, начиная от обновлений и заканчивая патчами для закрытия уязвимостей.
Когда развернуть полноценную работу требуется в сжатые сроки, гораздо целесообразнее приобретать те же самые сервисы, включая Hadoop и Greenplum, у облачного провайдера уже в формате «платформа-как-услуга» (PaaS). Это минимизирует расходы на разработку и время вывода продукта на рынок. В конце концов, облако тем и ценно, что позволяет существенную часть задач, связанных с администрированием и поддержкой, переложить на плечи провайдера. И здесь в облако уходит уже не просто обслуживание серверов, дисков и сетей, то есть уровня инфраструктуры, но обслуживание самих инструментов для работы с данными. Кроме того, самостоятельно разворачивая кластер Hadoop поверх IaaS, мы теряем гибкость, которую облако дает в плане масштабирования нагрузки. Получив Hadoop как готовую услугу, мы можем в любой момент эластично расширить или сжать возможности кластера по хранению и обработке данных, платя за эту нагрузку, только когда она действительно нужна.
Эффективная обработка данных
В традиционных инфраструктурах слои хранения и вычисления объединены. Каждая нода в Hadoop одновременно выполняет и функцию вычисления, и функцию хранения. Такая же ситуация, к примеру, и с нодой Vertica: когда система требует расширения, мы можем добавить только ноду целиком, но не увеличить или уменьшить возможности вычислений и хранения по отдельности.
Современная архитектура требует разделять слои, и облака идеально для этого приспособлены. Их масштабируемость – одно из ключевых свойств, поэтому можно бесконечно наращивать любой из слоев.
Дополнительно оптимизировать расходы на инфраструктуру можно путем частичного переноса данных из кластера Hadoop в более дешевое объектное хранилище S3, тем самым разделив между собой слои хранения и обработки данных. Сам же кластер можно арендовать лишь на время обработки, после чего данные останется лишь разложить по целевым системам, а кластер – остановить.
.jpeg)
Может ли традиционный Hadoop-кластер работать настолько эффективно, что перевод этой вычислительной нагрузки на новые рельсы и разделение данных на слои не оправдывали бы себя? В редких случаях такое возможно. Например, когда рабочие нагрузки предполагают максимальное использование локальности данных (Data locality). Таким образом между нодами пересылаются не данные, а код, что ускоряет обработку и снижает нагрузку на сеть.
Бывает, что перевод такого кластера с уровня инфраструктуры на уровень платформы вызывает падение скорости обработки в несколько раз. Точнее, это происходит при выделении слоев данных и вынесении их в хранилище S3, в результате чего для обработки данных придется сначала выгрузить их из S3. Впрочем, такие ситуации не слишком распространены, а владельцы подобного оптимизированного кластера наверняка отлично знают, что и зачем они делают.
Экономичное хранение данных
Прошли времена, когда любые потребности бизнеса в аналитике покрывались классическими или даже колоночными СУБД. Количество источников информации, ценной для принятия тех или иных решений, выросло на порядки. И, чтобы сохранить возможность сбора и обработки столь огромного потока, облачные платформы обзавелись инструментами для построения «озер данных» (Data lake). Основанные на распределенных файловых системах HDFS, S3 или иных, они позволяют хранить практически безграничные объемы неструктурированных данных, загружаемых как есть, без какой-либо обработки. В озерах формирование схемы данных происходит только при их чтении (Schema-on-read).
К достоинствам озер данных можно отнести простоту загрузки в них информации из множества разнородных источников. Минусы вытекают из этих же плюсов. Простота загрузки часто приводит к тому, что разные специалисты или департаменты вносят туда одни и те же данные по нескольку раз, а подчас еще и в разных форматах, и всегда есть опасность превращения такого озера в болото. Пользуясь инструментами обработки больших данных и каталогами метаданных, любой дата-сайентист всегда сможет не только извлечь необходимое, но и сопоставить его с другими данными, получив на выходе новую ценность для бизнеса. Это помогает справиться с угрозой «заболачивания».
Альтернативой озерам данных может стать организация хранилища по принципу предметно-ориентированных баз данных (Data warehouse). Вне зависимости от технологической основы (это может быть тот же Hadoop), в предметно-ориентированных базах содержатся предварительно обработанные и очищенные данные, готовые к использованию в целях бизнес-аналитики или для других задач. Информация отсюда уже может напрямую применяться бизнес-пользователями без помощи дата-сайентиста. В этом и заключается главный плюс такого подхода. А к его минусам можно отнести сложность внесения и извлечения информации. Сначала она должна быть предварительно обработана и отфильтрована, приведена к единому виду. А позже, по мере использования, извлекать приходится не одну конкретную таблицу, а множество, так как для получения нужного результата потребуется их многократное сопоставление.
Отдельным интересным применением облаков является сбор данных с устройств «Интернета вещей». Огромные сети, порой состоящие из десятков или сотен тысяч датчиков, производят колоссальные объемы информации. При этом периодически необходимо проводить сравнения текущих показателей с историческими, а значит, хранить надо буквально весь собранный объем. Делать это на традиционной инфраструктуре непозволительно дорого.
Облака обладают сразу несколькими преимуществами. Во-первых, систему хранения можно плавно наращивать по мере поступления данных. Следовательно, и платить придется только за использованный объем. Во-вторых, данные в облаке можно разделить на «горячие», «теплые» и «холодные». Последние логично отправить на архивное хранение, что окажется существенно дешевле, чем держать их в непрерывной доступности, когда в этом нет необходимости.
.jpeg)
Самостоятельная работа с данными
Мало собрать данные. Необходимо предоставить к ним удобный доступ для дата-сайентистов, которые будут извлекать из них ценные для компании выводы. Современный бизнес, хорошо понимающий важность этого процесса, все шире внедряет концепцию управления данными (Data governance). Одним из основных ее элементов является самообслуживание (Self service). Если в компании не реализованы подходы самообслуживания, то дата-сайентист или бизнес-пользователь должен обратиться к аналитику, а зачастую еще и в ИТ-сервис только для того, чтобы узнать, где лежат нужные данные.
Делать этого не нужно, когда в распоряжении специалиста есть соответствующие права и инструменты, главный из которых – каталог метаданных. Где бы в облаке ни располагалась необходимая таблица, ее всегда можно отыскать при помощи этого каталога, играющего роль поисковой системы. Классическим примером подобного инструмента является Amundsen. С его помощью можно и найти нужную информацию, и получить к ней доступ.
А теперь ее нужно обработать. В прошлом специалист пошел бы в службу ИТ, заказал сервер соответствующей производительности и неделями ждал, пока его соберут и доставят. Сейчас достаточно воспользоваться графическим интерфейсом, чтобы в несколько кликов «накидать» себе нужное количество процессорных ядер или графических чипов из пула облачного провайдера. Получив в свое распоряжение виртуальную машину (или даже кластер), специалист может за короткое время произвести обработку, после чего сразу остановить и освободить арендованные ресурсы.
В заключение можно с уверенностью сказать, что рано или поздно облачной станет любая инфраструктура для анализа данных. Для этого достаточно экономических причин, не говоря уже о технологических. И в этом процессе в выигрыше окажется тот, кто совершит переход раньше других и сумеет правильно использовать уникальные преимущества облаков.
В сущности, выбор лишь в том, как совершить переезд. И даже если сначала вы выполните простой перенос в виртуальную среду своей локальной архитектуры как она есть, более правильно ставить конечной целью пересборку бизнес-логики с учетом современных архитектурных подходов и использованием платформенных сервисов провайдера. Это потребует запустить рефакторинг приложений под новые платформы и микросервисные архитектуры, разделить слои хранения и вычислений, а также внедрить лучшие практики работы с данными.
Опубликовано 12.11.2021
