Перенос Hadoop в облако: удвоенная емкость хранения и меньшие затраты на операции

Yimian — ведущий поставщик аналитики данных с использованием искусственного интеллекта, специализирующийся на данных цифровой коммерции. Мы предлагаем реальные временные сведения для стратегии бизнеса, разработки продуктов и операций в области цифровой коммерции. Многие наши клиенты являются лидерами отрасли в сферах личной гигиены, макияжа, продуктов питания и напитков, товаров для животных и автомобильной индустрии, такие как Procter and Gamble, Unilever и Mars.

Изначальная архитектура нашей технологии представляла собой кластер больших данных, построенный с использованием CDH (Cloudera Distributed Hadoop) в собственном центре данных. По мере роста нашего бизнеса объем данных резко увеличился.

Чтобы справиться с такими проблемами, как длительные циклы масштабирования, несоответствие ресурсов вычислений и хранения, а также высокие затраты на обслуживание, мы решили трансформировать нашу архитектуру данных и перенести ее в облако, приняв подход к разделению хранения и вычислений. После тщательной оценки, мы приняли Elastic MapReduce (EMR) от Alibaba Cloud + JuiceFS + Alibaba Cloud Object Storage Service (OSS).

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

В этой статье мы поделимся нашим архитектурным дизайном для миграции Hadoop в облако, почему мы выбрали JuiceFS+EMR+OSS и как мы извлекаем выгоду из новой архитектуры. Наша цель — предложить ценные идеи тем, кто сталкивается с аналогичными проблемами через этот пост.

Наша Старая Архитектура и Проблемы

Чтобы удовлетворить растущие потребности наших приложений, мы собирали данные с сотен крупных веб-сайтов, текущее количество которых превышает 500. Со временем мы накопили значительные объемы исходных, промежуточных и результирующих данных. Поскольку мы продолжали расширять нашу веб-скрапинг и клиентскую базу, объем наших данных быстро увеличивался. Поэтому мы решили масштабировать наше аппаратное обеспечение для удовлетворения растущих потребностей.

Оригинальная Архитектура

На следующем рисунке показана наша предыдущая архитектура, которая включала в себя кластер больших данных на основе CDH, развернутый в дата-центре:

• Ключевыми компонентами были Hive, Spark и HDFS.
• Несколько систем производства данных, включая Kafka, поставляли данные в кластер.
• Мы использовали другие решения для хранения данных, такие как TiDB, HBase и MySQL, наряду с Kafka.

Original architecture at Yimian

Данные поступали от систем верхнего уровня приложений и систем сбора данных, где они записывались в Kafka. Мы использовали кластер Kafka Connect для синхронизации данных в HDFS.

На основе этой архитектуры мы разработали собственную платформу для разработки данных под названием OneWork для управления различными задачами. Эти задачи планировались через Airflow и обрабатывались в очередях задач.

Наши Болезненные Точки

Проблемы, с которыми мы столкнулись, были следующими:

• Быстрый рост данных приложений и длительные циклы масштабирования: Наша CDH-кластера, развернутая в 2016 году, уже обрабатывала петабайты данных к 2021 году. Однако рост данных часто превышал планирование аппаратного обеспечения, что приводило к частым масштабированиям каждые шесть месяцев. Это потребовало значительных ресурсов и времени.
• Сцепление хранения и вычислений, а также сложность планирования емкости: Традиционная архитектура Hadoop имеет тесное сцепление хранения и вычислений, что затрудняет независимое масштабирование и планирование в соответствии с потребностями в хранении или вычислительных ресурсах. Например, расширение хранения также потребовало бы покупки ненужных вычислительных ресурсов. Это привело к неэффективному распределению ресурсов.
• Боязнь обновления из-за старой версии CDH: Наша версия CDH была устаревшей, и мы колебались с обновлением из-за опасений по поводу стабильности и совместимости.
• Высокие операционные затраты: С около 200 сотрудниками у нас был только один штатный сотрудник по операциям. Это создавало большую нагрузку. Чтобы облегчить это, мы искали более стабильную и простую архитектуру.
• Один центр данных как точка отказа: Хранение всех данных в одном центре данных представляло долгосрочный риск. В случае повреждения кабелей или других проблем наличие одного центра данных создает точку отказа.

Наши требования к новой архитектуре

Чтобы решить наши проблемы и удовлетворить растущие потребности, мы решили внести изменения в архитектуру. Основные аспекты, которые мы рассмотрели для обновления, включают следующее:

• Принятие облачных услуг, эластичная масштабируемость и оперативная гибкость: Привлечение облачных сервисов упрощает операции. Например, использование облачного хранилища позволяет сосредоточиться на приложении, избегая задач по обслуживанию. Кроме того, облачные ресурсы обеспечивают эластичное масштабирование без длительных развертываний аппаратного обеспечения и настройки систем.
• Разделение хранения и вычислений: Наша цель заключалась в разделении хранения и вычислений для достижения большей гибкости и производительности.
• Преимущество открытого исходного кода, избегание зависимости от поставщика: Несмотря на использование облачных услуг, мы стремились минимизировать зависимость от конкретных поставщиков. Используя AWS Redshift для обслуживания клиентов, мы предпочитали открытые компоненты для внутренних операций.
• Совместимость с существующими решениями, контроль затрат и рисков: Наша цель заключалась в обеспечении совместимости с текущими решениями для минимизации затрат на разработку и воздействия на наше приложение.

Почему мы выбрали JuiceFS+EMR+OSS

После оценки различных решений, мы выбрали EMR+JuiceFS+OSS для создания разделенной платформы хранения и вычислений для больших данных и постепенно перенесли наш локальный центр данных в облако.

New architecture at Yimian

В этой конфигурации объектное хранилище заменяет HDFS, а JuiceFS выступает в качестве слоя протоколов благодаря поддержке POSIX и протоколов HDFS. На вершине мы используем полу-управляемое решение Hadoop, EMR. Оно включает Hive, Impala, Spark, Presto/Trino и другие компоненты.

Облако Alibaba против других публичных облаков

После тщательной оценки, мы выбрали Alibaba Cloud вместо AWS и Azure из-за следующих факторов:

• Близость: Доступность зоны Alibaba Cloud в одном городе с нашим дата-центром обеспечивает низкую задержку и снижение затрат на сеть.
• Комплексные открытые компоненты: Alibaba Cloud EMR предлагает широкий спектр открытых компонентов, связанных с Hadoop. Помимо интенсивного использования Hive, Impala, Spark и Hue, он также обеспечивает плавную интеграцию с Presto, Hudi, Iceberg и другими. В ходе нашего исследования мы обнаружили, что только EMR изначально включает Impala, в то время как AWS и Azure либо предлагают более низкие версии, либо требуют ручной установки и развертывания.

JuiceFS vs. JindoFS

Что такое JuiceFS?

JuiceFS — это открытый, ориентированный на облако, распределенный файловый систем с высокой производительностью. Он обеспечивает полную совместимость с POSIX, что позволяет использовать объектное хранилище в качестве массива локальных дисков в разных платформах и регионах.

JuiceFS использует разделенную архитектуру данных и метаданных, что позволяет создать распределенную файловую систему. При использовании JuiceFS для хранения данных сами данные хранятся в объектном хранилище, таком как Amazon S3, в то время как метаданные могут храниться в базах данных, таких как Redis, MySQL, TiKV, SQLite и других.

Помимо POSIX, JuiceFS полностью совместим с SDK HDFS, что позволяет плавно заменить HDFS для разделения хранения и вычислений.

The JuiceFS architecture

Почему мы выбрали JuiceFS вместо JindoFS

Мы предпочли JuiceFS JindoFS на основе следующих соображений:

• Проектирование хранилища: JuiceFS использует архитектуру разделения хранения данных и метаданных, что позволяет создать распределенную файловую систему. Данные хранятся в объектном хранилище, а метаданные могут быть сохранены в различных базах данных, таких как Redis, MySQL, TiKV и SQLite, что обеспечивает большую гибкость. В отличие от этого, метаданные JindoFS хранятся на локальном жестком диске кластера EMR, что делает обслуживание, обновления и миграции менее удобными.
• Гибкость хранения: JuiceFS предлагает различные решения по хранению, поддерживая онлайн-миграцию между разными схемами и увеличивая мобильность. JindoFS блочные данные поддерживают только OSS.
• Поддержка открытого сообщества: JuiceFS основан на открытом сообществе, поддерживая все публичные облачные среды. Это облегчает будущее расширение до архитектуры мультиоблака.

Полный дизайн архитектуры

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

A hybrid cloud architecture

На схеме архитектуры:

• В верхней части расположены Airflow и OneWork, которые обе поддерживают распределенное развертывание, поэтому их можно легко масштабировать горизонтально.
• Слева находится ЦОД, который использует традиционную архитектуру CDH и некоторые кластеры Kafka.
• Справа расположен кластер EMR, развернутый в Alibaba Cloud.

ЦОД и кластер EMR соединены высокоскоростной специализированной линией.

Как мы извлекаем выгоду из новой архитектуры

Преимущества разделения хранения и вычислений

При реализации раз decoupling хранение-вычисление, наша общая емкость хранения удвоилась, в то время как вычислительные ресурсы остались стабильными. Иногда мы включаем временные узлы задач по мере необходимости. В нашей ситуации объем данных растет быстро, а потребности в запросах остаются стабильными. С 2021 года объем наших данных удвоился. Мы внесли минимальные изменения в вычислительные ресурсы с самого начала до настоящего времени, за исключением иногда включения эластичных ресурсов и временных узлов задач для удовлетворения конкретных потребностей приложений.

Изменения производительности

Для нашего сценария применения, который в основном включает крупномасштабное пакетное обработку для офлайн-вычислений, на производительность не оказывается значительного влияния. Однако во время фазы PoC мы наблюдали улучшение времени отклика для ad-hoc запросов Impala.

Во время фазы PoC мы провели некоторые простые тесты. Однако точно интерпретировать результаты затруднительно из-за различных влияющих факторов:

• Переход от HDFS к JuiceFS
• Обновление версий компонентов
• Изменения в движке Hive
• Изменения в нагрузке кластера

Все это затрудняет вывод определенных выводов о различиях в производительности по сравнению с нашей предыдущей реализацией CDH на физических серверах.

Удобство использования и стабильность

С JuiceFS мы не столкнулись с проблемами.

При использовании EMR у нас были незначительные проблемы. В целом, CDH воспринимается как более стабильный и удобный в использовании.

Сложность реализации

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

Комплексность определяется многими факторами:

• Сценарии применения (офлайн/реального времени, количество таблиц/задач, вышестоящие приложения)
• Версии компонентов
• Поддерживающие инструменты и резервы

Будущие планы

Наши будущие планы включают:

• Продолжение миграции оставшихся приложений в облако.
• Исследование стратегии хранения холодного/горячего уровня с использованием JuiceFS+OSS. Файлы JuiceFS полностью разбираются на OSS, что затрудняет реализацию сегментации на уровне файлов. Наш текущий подход заключается в переносе холодных данных из JuiceFS в OSS, установке их в качестве архивной памяти и изменении LOCATION таблиц Hive или разделов без влияния на использование.
• Если объем данных увеличится и возникнет давление при использовании Redis, в будущем мы можем рассмотреть возможность перехода на TiKV или другие движки.
• Исследование эластичных вычислительных инстансов EMR для снижения затрат на использование при соблюдении соглашений о уровне обслуживания приложений.