Для запуска и эксплуатации высоконагруженных ИТ-решений с петабайтами данных в активе, нужно проработанное решение, позволяющее гибко управлять ресурсами. Одним из критичных аспектов этого решения, является разделение Compute & Storage — разделение ресурсов инфраструктуры под вычисление и хранение соответственно. Если не реализовать такое разделение в крупном проекте, инфраструктура рискует превратиться в «чемодан без ручки» — эффективность использования ресурсов будет низкой, а сложность управления ресурсами и средами будет высока. На примере команды SberData и их корпоративной аналитической платформы я расскажу, когда требуется разделение Compute & Storage и как это реализовать максимально нативно.
Статья подготовлена по мотивам доклада на VK Data Meetup «Как разделить Compute & Storage в Hadoop и не утонуть в лавине миграций».
Погружаемся в контекст: корпоративная аналитическая платформа.
Команда SberData развивает внутреннюю корпоративную аналитическую платформу (КАП), которая покрывает запросы по хранению и аналитике данных для бизнес-блоков и трайбов «Сбера».
Сейчас платформа КАП имеет следующие параметры:
хранит 175 петабайтов данных;
включает 86 различных платформенных сервисов — в том числе централизованные сервисы безопасности (аутентификация, авторизация, аудит), журналирования, мониторинга, а также сервисы хранения, обработки и распространения данных;
поддерживает к актуальном состоянии данные, загружаемые из 780 источников;
загружает до 18 терабайтов данных ежесуточно;
генерирует и доставляет более 1 млн событий в секунду.
По итогам 2023 года, число пользователей аналитической платформы превысило 22 000, а на ее базе реализовано 187 полноценных прикладных аналитических решений, некоторые из которых обрабатывают петабайты данных. Все пользователи исключительно внутренние — 93% трайбов «Сбера» доверяют платформе и на регулярной основе пользуются ею.
В платформе, для реализации прикладных решений, доступен разнообразный технологический стек инструментов, под разные задачи и входящие требования. В части хранения данных в платформе представлены собственные сборки на базе технологических стеков Hadoop, Greenplum, Postgres, ClickHouse. В этом материале остановимся на нашем опыте внедрения Hadoop, набитых шишках и к чему мы в итоге с ним пришли.
Отправная точка: монолитный Hadoop
Начинали мы как все — с монолитной инсталляции Hadoop. Инструмент довольно популярный и неплохо изученный. Мы изначально понимали, что у него есть базовые ограничения:
на узел в кластере (меньше 100 Тб);
на количество блоков NN (400 млн).
В теории это не должно было стать критичным барьером: при размере блока в 256 Мб, на одном кластере Hadoop можно разместить до 95 Пб данных. То есть, в теории, двух кластеров было бы достаточно для размещения всех наших 175 Пб данных. Здесь важна оговорка — все в теории.
Жизнь оказалась несколько прозаичнее, а ограничений — больше. Так, мы столкнулись с тем, что репликация в монолитном Hadoop «съедает» доступный полезный объём в три раза (часть памяти надо выделять под хранение реплик, а erasure coding ещё не был внедрён), и избежать конкуренции за ресурсы не помогает даже продвинутое динамическое управление ресурсными очередями. Кроме этого, огромный кластер на 95 Пб (почти 1500 узлов) сложно поддерживать, а вероятность потери данных увеличивается пропорционально увеличению количества узлов. О равномерности потребления ресурсов в течение дня даже говорить не стоит.
В общем, количество открытых вопросов и недовольство наших потребителей росло, и нам предстояло определить, как мы с учётом этого будем дальше развивать наш продукт. После серии встреч и обсуждения новой архитектуры хранения и обработки данных в Hadoop, решили отказаться от одного большого коммунального кластера Hadoop в пользу отдельных мелких кластеров под нужны разных бизнес-блоков и даже трайбов.
Преимуществ у такой архитектуры сразу несколько:
можно гибко управлять ресурсами, заказывать выделенную инфраструктуру;
снижается конкуренции за ресурсы: кластер покрывает не всю компанию, а, например, только отдельный бизнес‑блок или трайб;
нативно обеспечивается изоляция рабочих сред;
повышается отказоустойчивость и надёжность хранения: данные можно разнести по разным кластерам.
Вместе с тем и такая реализация оказалась не лишена недостатков. На своём опыте мы столкнулись с рядом проблем и ограничений. Так, вместе с децентрализацией мы получили:
дублирование данных;
увеличение количества федераций — оно квадратично количеству кластеров;
повышение стоимости сопровождения;
повышение нагрузки на каналы передачи, вызванное пересылкой данных между кластерами;
увеличение количества стоек с оборудованием;
усиление дисбаланса оборудования;
снижение потребления оборудования;
ухудшение равномерности потребления ресурсов.
На первый взгляд, проблем у распределённой архитектуры больше, чем у монолитной. Но её преимущества во многом перекрывали возникающие трудности. Тем более, мы понимали, как можно решить часть из них.
Промежуточное решение проблем
В процессе реализации децентрализованного хранения стало очевидно, что часть упомянутых проблем концептуально нельзя решить. Но кардинально менять концепцию и отказываться от преимуществ мы не были готовы. Поэтому на первом этапе начали с «промежуточных» мер:
Проблемы дублирования данных и большого числа федераций мы решили, подняв полноценную виртуализацию между кластерами Hadoop.
Внедрение виртуализации позволило потребителям перестать запасать данные «на потом», что привело к снижению нагрузки на каналы в 4 раза.
Высокою стоимость сопровождения мы снизили за счёт частичной автоматизации их деятельности.
Вместе с тем, такая оптимизация не решала проблемы, связанные с дисбалансом оборудования и неэффективным потреблением ресурсов.
Таким образом, нам требовалось решение, которое позволит:
сохранить преимущества децентрализации;
повысить процент утилизации оборудования;
снизить стоимость хранения данных;
расширить интерфейсы доступа к данным;
минимизировать работы в части интеграции в платформу и миграции с Hadoop.
От анализа к выбору итоговой концепции
Имея на руках все карты, мы принялись за изучение современных трендов и существующих технологических решений, способных помочь в нашем случае. В результате мы пришли к выводу, что Compute и Storage нужно разделить — это позволяет закрыть оставшиеся проблемы децентрализации и не требует кардинального переформирования платформы, в том числе в части используемого технологического стека.
Так было найдено новое концептуальное решение, к внедрению которого мы и приступили. Я подробнее остановлюсь только на разделении Compute и Storage в контексте Storage. Однако, если материал получит достаточный отклик, я подробнее расскажу про то, как мы организовывали разделение Compute и Storage в контексте Compute.
С чего начинали
Решение для хранения данных в нашей платформе развивалось довольно динамично, в соответствии с изменяемыми требованиями пользователей.
Так, в 2020 году с приходом первых пользователей появился запрос на более гибкую выдачу ресурсов на кластерах Hadoop. Основная задача состояла в том, чтобы получить возможность заказывать только те ресурсы, которые нужны, и в том объёме, который требуется для конкретной задачи. Внутреннее исследование показало, что относительно безболезненно реализовать это можно с помощью всего двух решений — Ceph и Apache Ozone. При этом Ceph не подошёл из-за сложностей интеграции в существующую платформу, а Apache Ozone оказался на то время просто «сырым». В итоге решили создать свой дистрибутив Hadoop.
К 2021 году корпоративная аналитическая платформа заметно разрослась, данных стало больше. Вместе с этим острее встала проблема дисбаланса в потреблении ресурсов хранения и вычисления. «Тянуть» за собой такой «багаж» было неоправданно, поэтому мы решили повторно рассмотреть замену Hadoop в классической реализации. При этом требования к искомому решению стали жёстче: кроме лёгкой интеграции в экосистему Hadoop и высокой производительности также было важно отсутствие фундаментальных недостатков по масштабированию, присущих Hadoop.
В качестве вариантов рассматривали несколько решений с открытым исходным кодом, в том числе Ceph, Minio и Apache Ozone. Ceph, Minio не подошли из-за слабой поддержки HDFS API. А вот Apache Ozone приятно удивил — к 2021 году он уже получил стабильную полнофункциональную версию, готовую для использования в промышленной среде. В итоге мы провели proof of technology с тестом концепции разделения слоёв хранения и вычисления, и после получения положительных результатов приступили к разработке для интеграции Apache Ozone в существующую корпоративную аналитическую платформу.
В 2022 году пилот решения прошёл успешное испытание в промышленном окружении. В 2023 мы вывели Apache Ozone в промышленную эксплуатацию. В этом же году у нас появились первые потребители, которые начали строить свои продукты данных с Apache Ozone в качестве основного хранилища, и началась миграция данных команд с Hadoop на Apache Ozone.
Почему именно Apache Ozone
Решенные проблемы HDFS
Apache Ozone — объектное хранилище, предназначенное для аналитических платформ, обрабатывающих большие объемы данных. Изначально Apache Ozone зарождался в экосистеме Hadoop и рассматривался как эволюция HDFS. Основным драйвером для начала разработки Ozone были архитектурные ограничения, которые были присущи HDFS, и желание их преодолеть с учётом современных технологических трендов. Это удалось.
Один из основных недостатков HDFS, который мешает создавать большие кластеры, — ограниченная масштабируемость. Так, из-за хранения данных в блоках по 128 Мб, HDFS Hadoop способен вместить около 400 млн объектов. Метаданные хранятся в блоках на NameNode, а размер записи метаданных фиксированный и не зависит от размера блока. Таким образом, в ситуациях, когда размер файла меньше размера блока, Hadoop начинает упираться в проблему масштабируемости.
Разработчики Apache Ozone подошли комплексно к преодолению этой проблемы:
В Ozone данные пишутся в чанки по 4 Мб, которые упаковываются в блоки по 256 Мб. Блоки, в свою очередь, оборачиваются контейнерами по 5 Гб.
Хранение и управление метаданными разнесено на разные сервисы. Так, DataNode хранит данные о чанках и блоках. Storage Container Manager хранит метаданные только о контейнерах, а Ozone Manager управляет пространством имён. То есть, каждый сервис управляет небольшим фрагментом метаданных.
Управляющие сервисы получили возможность эффективно работать с метаданными не только в оперативной памяти, но и на дисках. Такая реализация архитектуры позволяет хранить в Ozone очень много объектов. Например, если под управляющими сервисами — под Ozone Manager и Storage Container Manager — будут диски около 3 Тб, это позволит записать в Ozone около 10 млрд объектов, чего достаточно для создания больших хранилищ и решения проблемы масштабирования.
Второй недостаток HDFS — проблема доступности и отказоустойчивости. На классических Hadoop-кластерах ставится две NameNode: одна — основная, которая обрабатывает все запросы, вторая — дублирующая, которая включается в работу, если основная падает. В случае потери всего двух серверов и, соответственно, двух NameNode, кластер станет недоступным.
В Apache Ozone нет этой проблемы, поскольку управляющие сервисы Storage Container Manager и Ozone Manager поддерживают согласованность состояний между репликами по алгоритму консенсуса Raft Ratis. Это позволяет увеличивать количество реплик каждого из управляющего сервиса до необходимого.
Вместе с тем, при работе с Apache Ozone надо учитывать, что минимально должно быть три мастер-ноды. При увеличении количества реплик сервисов надо увеличивать и количество мастер-нод, но оно всегда должно быть нечётным.
Простая интеграция с экосистемой Hadoop
Нам было важно, чтобы Apache Ozone смог нативно поддерживать инфраструктуру, которая была построена вокруг Hadoop, в том числе централизованные сервисы аутентификации, авторизации, администрирования. С этим не возникло проблем — компетенции в Hadoop и инструментах администрирования, используемых в экосистеме, оказались применимы и для Apache Ozone. Подобная нативная поддержка решений экосистемы Hadoop позволяла органично вписать Apache Ozone в существующий ансамбль инфраструктуры.
В контексте интеграции также было важно, чтобы рассматриваемое решение нативно поддерживало HDFS API — в трайбе SberData написано много прикладных решений по существующей корпоративной аналитической платформе именно под Hadoop, и было важно, чтобы с ними можно было продолжать работу без лишних сложностей миграции прикладных решений в новое хранилище.
В Apache Ozone такая поддержка есть. Более того, если используются стандартные фреймворки, например, Spark, MapReduce, то в коде прикладных продолжений часто практически ничего не надо менять: зачастую всё сводится к минимальным доработкам для включения классов Ozone в общую кодовую базу. В случае с корпоративной аналитической платформой такая совместимость обеспечила нативную поддержку федерации не только экосистемы и инфраструктуры, но и с другими Hadoop-кластерами.
Производительность Apache Ozone
С учётом большого объёма данных и значительной нагрузки на Hadoop, одним из ключевых критериев выбора решения была производительность. В том числе её мы проверяли на этапе proof of technology с разделением слоёв хранения и вычисления. В тестовой среде было выделено несколько десятков узлов промышленной конфигурации, на которых последовательно были развернуты и протестированы:
кластер Hadoop на все узлы с хранением и вычислением на одних и тех же узлах;
кластер Ozone на части узлов, а на остальных Spark над OpenShift;
Сравнивалась производительность чтения разных объёмов данных. В качестве эталона для сравнения был принят существующий кластер Hadoop. Интегральная оценка производительности по сумме всех тестов в разных сценариях показала просадку производительности в случае с децентрализованным Apache Ozone на уровне 5%, что было вполне допустимо.
Профит по итогам перехода на Apache Ozone
Переход на Apache Ozone с разделением Compute и Storage позволил сделать управление ресурсами хранения для аналитической платформы более гибким, с возможностью получения нужных ресурсов в нужном объёме. Одновременно с этим, полученная реализация уже сейчас дала комплексный локальный положительный эффект:
снижение ТСО на хранение, так как появилась возможность использования высокоплотных серверов;
сократилось количество стоек в ЦОДах в 4 раза;
уменьшилось количество кластеров — с более 60 до менее 20;
снизилась стоимость сопровождения решения;
с 40% до 80% повысилась эффективность потребления ресурсов.
Дальнейшая миграция инструментов платформы на Apache Ozone будет лишь усиливать этот эффект.
Послесловие
Разделение Compute и Storage нередко превращается в сложный квест, но при правильной реализации эффект от перехода на такую архитектуру с лихвой оправдывает все трудозатраты и потенциальные трудности.
В большинстве ситуаций, как и в случае с аналитической платформой SberData, необходимость разделения Compute и Storage является эволюционной: с ростом объёма данных, количества источников, сложности и интенсивности вычислений, сохранение монолитного хранилища кратно повышает сложность управления и провоцирует сопутствующие проблемы.
Отдельно стоит отметить, что переход с Hadoop на Apache Ozone в контексте конкретного случая не решил всех проблем — у Ozone в текущей версии (1.3) еще есть нюансы относительно производительности и отказоустойчивости. Но в перспективе их можно доработать как на стороне открытого community-решения (разработчик обещает доработку функциональности уже в версии 1.4), так и на стороне нашей реализации, чтобы получить хранилище, отвечающее даже непрерывно возрастающим запросам больших систем.
