Версия сайта для слабовидящих
Хотя Apache HBase обладает массой достоинств, такими как строгая согласованность на уровне строк при больших объемах запросов, гибкая схема, доступ к данным с малой задержкой и интеграция с Hadoop, эта NoSQL-СУБД имеет ряд недостатков: чрезмерная сложность и дороговизна эксплуатации, отсутствие вторичных индексов и ACID-транзакций. Поэтому инженеры фотохостинга Pinterest приняли решение перейти на NewSQL-базу TiDB. Читайте далее, с какими сложностями они при этом столкнулись, и каким образом решили возникшие проблемы.
Предыстория: зачем Pinterest ушел с Apache HBase и на TiDB
Напомним, Apache HBase – это NoSQL-СУБД с открытым исходным кодом на языке Java категории «семейство столбцов» (wide-column store) и представляет собой колоночно-ориентированное, мультиверсионное хранилище типа «ключ-значение» (key-value). Она работает поверх HDFS и обеспечивает возможности Google’вской BigTable для Hadoop, реализуя отказоустойчивый способ хранения больших объёмов разреженных данных.
В фотохостинге Pinterest именно HBase является важным бэкендом для хранения данных, который обеспечивает работу многих онлайн-сервисов хранения, таких как Zen (графовая база данных), UMS (хранилище данных с широкими столбцами) и Ixia (сервис вторичного индексирования почти в реальном времени). Однако, несмотря на множество достоинств HBase, таких как отказоустойчивость, строгая согласованность на уровне строк при больших объемах запросов, гибкая схема, доступ к данным с малой задержкой и интеграция с Hadoop, она достаточно сложна в обслуживании. Кроме того, в HBase Отсутствует целый ряд полезных функций, таких как вторичные индексы и классические ACID-транзакции.
В качестве замены Apache HBase была выбрана TiDB — NewSQL-СУБД от Pingcap с открытым исходным кодом, которая поддерживает рабочие нагрузки гибридной транзакционной и аналитической обработки (HTAP). Она совместим с MySQL и отличается горизонтальной масштабируемостью, строгой согласованностью и высокой доступностью. TiDB объединяет сценарии OLTP, OLAP и HTAP, поэтому отлично подходит для проектов, требующих высокой доступности и строгой согласованности с крупномасштабными данными. Архитектура TiDB, разделяющая вычислительные ресурсы и хранилище, позволяет отдельно масштабировать вычислительные ресурсы или емкость хранилища в режиме онлайн по мере необходимости.
Высокая доступность гарантируется за счет репликации: реплики данных получают журнал транзакций по протоколу Multi-Raft. Транзакция может быть зафиксирована только после успешной записи данных в большинство реплик, что гарантирует строгую согласованность и доступность при выходе из строя меньшинства реплик. Можно настроить географическое расположение и количество реплик по мере необходимости.
TiDB предоставляет два механизма хранения: TiKV, механизм хранения на основе строк, и TiFlash, механизм хранения столбцов. TiFlash использует протокол Multi-Raft Learner для репликации данных из TiKV в режиме реального времени, обеспечивая согласованность данных между механизмом хранения на основе строк TiKV и механизмом хранения столбцов TiFlash. TiKV и TiFlash могут быть развернуты на разных машинах по мере необходимости для решения проблемы изоляции ресурсов HTAP.
TiDB — это распределенная база данных, разработанная для облака, обеспечивающая гибкую масштабируемость, надежность и безопасность на облачной платформе. Можно эластично масштабировать TiDB в соответствии с требованиями изменяющихся рабочих нагрузок. Каждый фрагмент данных имеет как минимум 3 реплики, которые можно запланировать в разных облачных зонах доступности, чтобы выдержать сбой всего центра обработки данных. Оператор TiDB помогает управлять TiDB в Kubernetes и автоматизирует задачи, связанные с работой кластера TiDB, что упрощает развертывание TiDB в любом облаке, предоставляющем управляемый Kubernetes. TiDB Cloud, полностью управляемая служба TiDB, — это самый простой, экономичный и надежный способ раскрыть всю мощь TiDB в облаке, позволяя развертывать и запускать кластеры TiDB всего несколькими щелчками мыши. TiDB совместим с протоколом MySQL 5.7, общими функциями MySQL и экосистемой MySQL. Для миграции приложений на TiDB не менять много кода. Также TiDB предоставляет ряд инструментов переноса данных, упрощающих перенос данных приложений в TiDB.
Все эти преимущества TiDB делают ее особенно востребованной в финтехе и интеллектуальном анализе больших данных в реальном времени. Кроме того, эта NewSQL-СУБД способна заменить связку ETL+Hadoop. Можно реплицировать данные в TiDB с помощью инструментов ETL или нативных инструментов переноса данных, чтобы генерировать отчеты напрямую в этой СУБД с помощью операторов SQL-запросов.
В отличие от Apache HBase, TiDB поддерживает ODBC и JDBC, ACID-транзакции, вторичные индексы, а также множество языков программирования. Из-за большой разницы между HBase и TiDB миграция с первой на вторую становится крупным сложным проектом длительностью несколько кварталов. Как инженеры Pinterest справились с этим, мы рассмотрим далее.
Трудности перехода
Проект миграции с HBase в TiDB включает не только перенос данных, но и API, а также автономных заданий из экосистемы HBase/Hadoop в TiSpark при сохранении согласованности данных на уровне 99,999%, значений SLA и других требований к решению. В целом упрощенная стратегия миграции данных с нулевым временем простоя обычно состоит из следующих шагов:
- Старт двойной записи данных в две базы;
- импорт дампа заменяемой базы данных в новую с разрешением конфликтов оперативной записи;
- проверка обоих наборов данных;
- остановка записи в заменяемую базу данных.
Однако, на практике все оказалось не так просто. В частности, при выполнение двойной записи в таблицы HBase и TiDB и использовании режима бэкенда TiDB для приема данных. Скорость, предлагаемая серверным режимом TiDB, составляет 50 ГБ/час, что приемлемо только для переноса данных небольших таблиц. Можно сделать дамп моментального снимка таблицы HBase и выполнять потоковую запись в реальном времени из HBase через сбор измененных данных (CDC) в топик Kafka. А затем принять данные из этого дампа, используя локальный режим, позже запустив двойную запись из сервисного слоя и применив все обновления из топика Kafka. Но эту стратегию сложно реализовать из-за разрешения конфликтов при применении обновлений CDC? Поскольку имеющиеся в распоряжении инженеров Pinterest инструменты для захвата измененных данных из HBase хранят только ключ.
Альтернативой является считывание ключей из CDC и сохранение их в другом хранилище данных, чтобы после запуска двойной записи в обе таблицы, считать их последнее значение из HBase записать в TiDB. Эта стратегия чревата риском потери обновлений, если асинхронный путь хранения ключей через CDC имеет проблемы с доступностью. Поэтому был реализован другой подход. Поскольку HBase не содержит схемы, а в TiDB данные имеют строгую схему, то перед началом миграции требовалось разработать схему с типами данных и индексами. При этом схема TiDB была разработана с использованием задания уменьшения сопоставления для анализа всех столбцов в строке Hbase и их максимального размера. Затем запросы были проанализированы для создания правильных индексов.
Чтобы сделать моментальный снимок HBase и сохранить его как дамп CSV в AWS S3, использовался hbasesnapshotmanager. Строки CSV были сохранены в кодировке Base64, чтобы обойти ограничения специальных символов. TiDB был запущен в локальном режиме, чтобы начать прием этого CSV-дампа, выполняя декодирование base64 перед сохранением строки. После завершения приема и подключения таблицы TiDB была запущена асинхронная двойная запись, которая гарантирует, что SLA этой NewSQL-СУБД не снижает общий уровень SLA.
Для выполнение моментальных снимков таблиц HBase и TiDB с помощью задания уменьшения сопоставления строки были преобразованы в общий объект и сохранены как файлы последовательности (Sequence) в AWS S3 с помощью диспетчера, специально разработанного инженерами Pinterest с использованием MR Connector и hbasesnapshotmanager. Задание MapReduce считывает эти файлы последовательности и записывает несопоставленные строки обратно в S3. А последнее значение этих несопоставленных строк из S3 записывается в TiDB.
Чтобы записи выполнялись как в HBase, так и в TiDB, была включена запись с двойной синхронизацией, сравнением четности данных и получением статистики о несоответствии. Механизм двойной синхронной записи не имел отката в случае сбоя HBase. Поэтому задания согласования должны запускаться периодически, чтобы гарантировать отсутствие несогласованности. Далее была включена асинхронную запись в HBase с синхронной записью и чтением в TiDB. Асинхронная запись в HBase обеспечивает согласованность данных на случай повторного отката. Наконец, можно полностью прекратить запись в HBase и отказаться от ее таблиц.
При выполнении этого сценария миграции инженеры Pinterest столкнулись с проблемой несогласованности данных из-за недоступности серверной части своих внутренних сервисов, таких как Ixia и несогласованности данных из-за состояния гонки во время двойной записи. Это решилось путем многократного запуска заданий согласования, поскольку после каждого запуска количество таких несоответствий значительно уменьшается. На практике задание согласования потребовалось запустить только один раз, чтобы достичь согласованности 99,999% между HBase и TiDB для таблицы объемом 4 ТБ, обслуживающей 400 операций записи в секунду. Это было подтверждено повторным получением дампа таблиц HBase и TiDB и сравнением его значений.
Освойте администрирование и эксплуатацию Apache HBase и других NoSQL-решений для аналитики больших данных на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
