| Заказчики: Uber Подрядчики: Uber Продукт: Apache HadoopВторой продукт: Apache Spark Дата проекта: 2014/01 — 2018/09
|
Технология: Средства разработки приложений
|
В октябре 2018 года Uber опубликовала на своем сайте статью, посвященную тому, как устроена ИТ-инфраструктура, позволяющая обрабатывать огромные массивы данных с минимальной задержкой, когда каждый день совершаются миллионы поездок при помощи сервиса.
До 2014 года объем данных, которые хранила Uber, был небольшим (всего несколько терабайт), что позволяло компании использовать небольшое количество традиционных баз данных OLTP. У данных не было глобального предоставления, а доступ к ним осуществлялся достаточно быстро, поскольку каждая база данных получала запросы напрямую (см. иллюстрацию ниже).
С 2014 года Uber работает над решением Big Data, чтобы обеспечить достоверность, масштабируемость и простоту в использовании данных. В 2018-м компания сосредоточилась на повышении скорости и эффективности платформы, которая называется Hadoop Upserts and Incremental (Hudi). Она построена на открытом фреймворке Apache Spark, предназначенном для реализации распределенной обработки неструктурированных и слабоструктурированных данных. Перед созданием BigData-платформа прошла путь развития, который запечатлен на изображениях ниже.
Hudi позволяет пользователям постепенно извлекать только измененные данные, что значительно повышает эффективность запросов. Она масштабируется по горизонтали и может быть использована из любой задачи Spark. Наконец, главное преимущество заключается в том, что Hudi работает только с распределенной файловой системой HDFS, отмечают в Uber.
Почему была создана Hudi?
Uber изучила содержание данных в своей базе, шаблоны доступа к ним и специфические для пользователя требования для выявления проблемных мест. В результате компания пришла к четыре основным ограничениям, которые предстояло преодолеть при помощи Hudi.
Ограниченная масштабируемость в HDFS
Многие компании, которые используют HDFS для масштабирования своей инфраструктуры Big Data, сталкиваются с этой проблемой. Хранение огромного количества небольших файлов может существенно повлиять на производительность, поскольку недостатком HDFS является присутствующий в одном экземпляре узел NameNode, который выполняет роль служб метаданных. Он становится серьезной проблемой, когда размер данных превышает 50-100 Пбайт.
Необходимость быстрой доставки данных в Hadoop
Поскольку Uber работает в режиме реального времени, компании необходимо предоставить услуги с использованием максимально актуальных данных. Сервису было важно сделать доставку данных намного быстрее, поскольку 24-часовая латентность данных (время, необходимое для извлечения и записи пакета данных) была слишком большой для многих случаев использования данных.
Отсутствие прямой поддержки обновлений и удалений существующих данных
Uber использовала моментальные снимки данных, которые предполагали поступление новых копий исходных данных каждые 24 часа. Поскольку сервису необходимо обрабатывать актуальные данные, ему нужно было решение, поддерживающее обновление и удаление уже созданных данных. Однако большие данные компании хранятся в форматах HDFS и Parquet, поэтому реализовать обновление напрямую не предоставлялось возможным.
Быстрые процессы ETL и моделирование
ETL — это один из основных процессов в управлении хранилищами данных, который включает в себя извлечение данных из внешних источников, их трансформацию и очистку, чтобы они соответствовали потребностям бизнес-модели, а также загрузку в хранилище. В системе Uber процессы ETL и моделирование также основывались на моментальных снимках, в результате чего платформа должна была перестраивать производные таблицы при каждом запуске. Быстрые ETL необходимы для постепенного уменьшения задержки данных.
Ниже представлена диаграмма, демонстрирующая принцип работы BigData-платформы Uber третьего поколения после внедрения Hudi. Она, как утверждается, создана в 2017 году с прицелом на долгосрочную работу и обрабатывает около 100 Пбайт данных.
Независимо от того, являются ли обновленные данные новыми записями в недавних подобластях или заменяют самой старые сведения, Hudi позволяет передавать свою последнюю временную метку контрольной точки и получать все записи, которые были обновлены с тех пор. Это извлечение данных происходит без выполнения дорогостоящего запроса, который сканирует всю исходную таблицу.
Используя эту библиотеку, Uber отошла от поглощения данных с использованием моментальных снимков на инкрементальную модель. В результате латентность данных была снижена с 24 часов до менее чем одного часа.
При этом компания продолжает совершенствовать свою систему. В частности, она стремится улучшить качество данных в базе и снизить латентность исходных данных в Hadoop до пяти минут и до 10 минут в случае с моделированными таблицами.
В Hudi планируется добавить дополнительный режим просмотра, который будет включать в себя оптимизированный для чтения обзор данных, а также новое представление, которое отображает данные с задержкой всего в несколько минут. Для этого будут применяться технологии с открытым исходным кодом, которые в компании называют Merge-On-Read или Hudi 2.0.
Uber также отказывается от использования специализированного оборудования для всех своих сервисов и переключается на контейнеризацию сервисов. Все механизмы распределения ресурсов объединяются внутри и вокруг экосистемы Hadoop, чтобы преодолеть разрыв между Hadoop и не связанными с данными сервисами компании.
Следующая версия Hudi позволит Uber генерировать гораздо более крупные файлы Parquet (более 1 Гбайт против 128 Мбайт на октябрь 2018 года) по умолчанию в течение нескольких минут для всех источников данных. Благодаря этому, а также надежной независимой от источника платформы для приема данных Hudi будет расти в соответствии с бизнесом, говорится в сообщении Uber.[1]
Примечания
