Планирование｜Тина

Недавно команда инженеров Pinterest объявила о плане процесса прекращения поддержки кластеров HBase, сославшись на высокую стоимость строительства и обслуживания инфраструктуры, трудности с поиском специалистов по HBase и недостаточные функции продукта. Поскольку Pinterest также обратился к технологиям баз данных, таким как Druid/StarRocks, Goku, KVStore, TiDB и т. д., технологическое сообщество начало сомневаться в том, что практика запуска нереляционных баз данных поверх Hadoop и HDFS быстро сокращается.

Крупнейшая в мире система развертывания HBase

Уже сбежал из HBase

Когда-то у Pinterest была крупнейшая в мире производственная система развертывания HBase, пиковый объем которой охватывал примерно 50 кластеров, 9000 экземпляров AWS EC2 и вмещал более 6 ПБ данных. Типичное производственное развертывание состоит из основного кластера и резервного кластера, причем оба конца реплицируют друг друга через журналы упреждающей записи (WAL) для достижения более высокой доступности. Онлайн-запросы сначала направляются в основной кластер, а автономные рабочие процессы и ресурсоемкие операции кластера (например, ежедневное резервное копирование) выполняются в резервном кластере. В случае сбоя основного кластера система выполнит аварийное переключение для переключения основного кластера и резервного кластера.

Альберто Ордонес Перейра, старший инженер-программист, и Лянхун Сюй, старший технический менеджер Pinterest, объясняют переход платформы для обмена идеями дизайна от нескольких онлайн-сервисов хранения данных на базе HBase к новой архитектуре с новым хранилищем данных и унифицированными службами хранения.

HBase, запущенный в 2013 году, стал первым решением для хранения данных NoSQL, принятым Pinterest. С ростом популярности NoSQL HBase быстро стал одним из наиболее широко используемых серверов хранения данных в Pinterest. С тех пор он также стал строительным блоком инфраструктуры в стеке технологий Pinterest, поддерживая ряд внутренних систем и систем с открытым исходным кодом, включая графический сервис компании Zen, хранилище с широкими столбцами UMS, хранилище для мониторинга OpenTSDB, отчеты о показателях Pinalytics, базу данных транзакций Omid/ Sparrow, индексное хранилище данных Ixia и т. д. Вместе эти системы поддерживают множество вариантов использования, что позволяет Pinterest значительно масштабировать свой бизнес, продолжать расширять базу пользователей и улучшать качество продуктов за последние 10 лет.

Конкретная сфера воздействия охватывает интеллектуальную обратную связь, сканеры URL-адресов, пользовательские сообщения, уведомления о пиннерах, индексы рекламы, каталоги покупок, мониторинг Statsboard, экспериментальные индикаторы и многое другое.

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

Почему HBase устарел?

Проект HBase возник в 2007 году как подпроект Apache Hadoop и выпустил свою первую независимую версию в феврале 2010 года. С тех пор он продолжал развиваться, при этом стабильность и масштабируемость улучшались с каждой новой версией.

HBase, вдохновленный проектом Google Bigtable и написанный на Java, представляет собой решение для хранения данных с использованием пары «ключ-значение», построенное на HDFS и используемое Apache Hadoop. По словам Перейры и Сюй, HBase было первым решением Pinterest для хранения данных NoSQL и одним из наиболее широко используемых серверов хранения данных для разработчиков приложений для обмена изображениями и социальных сетей.

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

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

Высокие затраты на техническое обслуживание

К моменту оценки обслуживание HBase уже было непомерно дорогим, главным образом, из-за многолетнего технического долга и рисков, связанных с надежностью. По разным историческим причинам версия Pinterest HBase отстает на пять лет от основной версии и не содержит исправлений ключевых ошибок и улучшений. А из-за давних устаревших конвейеров сборки/развертывания/конфигурации и проблем совместимости обновление версий HBase в Pinterest стало медленным и болезненным процессом (последнее обновление с 0.94 до версии 1.2 заняло почти два года). Кроме того, становится все сложнее найти специалистов по HBase, а порог обучения новых инженеров также крайне недружелюбен.

Отсутствует функциональность

HBase делает упор на предоставление относительно простых интерфейсов NoSQL. Хотя он может соответствовать различным вариантам использования в Pinterest, его ограниченная функциональная конфигурация действительно сложна для удовлетворения меняющихся потребностей клиентов с точки зрения строгой согласованности, распределенных транзакций, глобальных вторичных индексов и богатых функций запросов. Например, отсутствие распределенных транзакций в HBase привело к множеству ошибок и неожиданным событиям в Zen, внутреннем графическом сервисе Pinterest, поскольку сбои локальных обновлений могли вызвать противоречивые графические эффекты. Отладка таких проблем зачастую сложна и требует много времени, серьезно влияя на настроение и опыт работы/использования менеджеров по обслуживанию и клиентов.

Сложность системы слишком высока

Чтобы предоставить клиентам более продвинутые функции, Pinterest за последние несколько лет также попыталась создать несколько новых сервисов на базе HBase. Например, Pinterest построил Ixia на основе HBase и Manas Realtime для поддержки глобальных вторичных индексов в HBase. Мы также создали Sparrow на базе Apache Phoenix Omid для поддержки распределенных транзакций поверх HBase. Хотя лучших альтернатив для удовлетворения потребностей бизнеса просто не существовало, сами системы потребовали значительных затрат на разработку и стали новым источником бремени обслуживания.

Завышенные затраты на инфраструктуру

Кластеры HBase производственного уровня обычно полагаются на установку «основной-резервный» с 6 копиями данных для быстрого аварийного восстановления. Но в масштабах бизнеса Pinterest это сопряжено с чрезвычайно высокими затратами на инфраструктуру. Если HBase можно будет перевести на решение для хранения данных с меньшими затратами на копирование данных, очевидно, что это значительно снизит общие эксплуатационные накладные расходы на инфраструктуру. Например, благодаря тщательному проектированию реплик и механизмов развертывания TiDB, Rickstore и MySQL могут обеспечить аварийное восстановление трех копий, не оказывая существенного влияния на соглашение об уровне обслуживания.

Использование в промышленности и сообществе снизилось.

За последние несколько лет Pinterest наблюдал, по-видимому, устойчивое снижение использования HBase и активности сообщества в отрасли, при этом многие коллеги искали лучшие решения для замены своих промышленных реализаций HBase. Эта тенденция, в свою очередь, привела к сокращению количества талантливых специалистов и повышению входных барьеров, из-за чего новые инженеры все чаще неохотно обучаются и развивают свои собственные бизнес-навыки HBase.

Путь к отказу от HBase

В Pinterest полное прекращение поддержки HBase когда-то считалось невыполнимой задачей, поскольку он был настолько глубоко встроен в существующий технологический стек Pinterest. Однако команды Перейры и Сюй были не единственными в Pinterest, которые знали о различных недостатках HBase, когда дело касалось обработки различных типов рабочих нагрузок. Например, команда Перейры и Сюя обнаружила, что HBase работает хуже, чем современные решения для рабочих нагрузок OLAP. Он не может справиться с растущим объемом данных временных рядов, что создает серьезные проблемы с масштабируемостью, производительностью и нагрузками на обслуживание. Он также менее производительен и принципиально менее эффективен, чем KVStore, внутреннее хранилище ключей, созданное на основе RocksDB и Rocksplicator. Поэтому за последние несколько лет команды Перейры и Сюй запустили множество инициатив по замене HBase технологиями, лучше подходящими для этих сценариев использования.

В частности, рабочие нагрузки онлайн-аналитики будут перенесены в Druid/StarRocks, данные временных рядов будут перенесены в Goku (внутреннее хранилище данных временных рядов), а варианты использования «ключ-значение» будут перенесены в KVStore. После серии попыток команда нашла способ полностью отказаться от HBase в Pinterest.

Чтобы удовлетворить оставшиеся варианты использования HBase, им также требовалась новая технология, которая могла бы обеспечить ту же масштабируемость, что и база данных NoSQL, при этом поддерживая те же мощные возможности запросов и семантику ACID, что и традиционная СУБД. Поэтому команда в итоге выбрала TiDB, полностью уйдя от HBase.

HBase умирает?

Новость о том, что Pinterest прекращает поддержку HBase, вызвала бурные дискуссии в сообществе. В статье «Почему Pinterest прекращает поддержку HBase?» В статье «Умирает ли HBase» Шиванг Сараваги подчеркнул, что объем поиска HBase в движке Google неуклонно снижается на протяжении последних пяти лет. В статье упоминалось:

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

В популярном сообщении на сайте Hacker News пользователь dehrmann прокомментировал:

Я работал на предприятии, которое активно внедряло HBase. Они перешли с AWS на GCP только для того, чтобы приблизиться к BigTable... HBase и HDFS очень требовательны к управлению и очень ненадежны, вынуждая каждого в любой момент настраивать отказоустойчивый кластер. Интересно, что во время миграции также произошла деградация ячеек/таблиц, что могло быть одной из причин проблем с надежностью.

Pinterest ранее рассказывал, как они перенесли некоторые из своих рабочих нагрузок с HBase на TiDB без каких-либо простоев. Сараваги добавил: С появлением современных баз данных внимание отрасли постепенно смещается от HBase. Однако нельзя сказать, что эта технология уже устарела.

Справочные ссылки:

https://www.infoq.com/news/2024/06/pinterest-deprecates-hbase/

https://medium.com/pinterest-engineering/online-data-migration-from-hbase-to-tidb-with-zero-downtime-43f0fb474b84