Размер имеет значение: Spark и Phoenix для больших запросов в Apache HBase

Автор Категория ,
Размер имеет значение: Spark и Phoenix для больших запросов в Apache HBase

Добавляя новые интересные примеры в наши курсы для дата-аналитиков, разработчиков распределенных приложений и администраторов SQL-on-Hadoop, сегодня рассмотрим опыт видеоаналитики в компании Vimeo с использованием Apache Spark. Как быстро запросить множество данных из Apache HDFS через Phoenix и Spark из моментальных снимков HBase с минимальным влиянием на кластер.

Аналитика очень больших данных в Vimeo на Apache HBase и Phoenix

Изначально видеоаналитика в Vimeo поддерживалась кластером HBase из более чем 100 машин на базе Apache Phoenix: сотни терабайт метрик и статистики видео, более 10 миллиардов операций записи и 100 миллиардов запросов в день. Но по мере роста данных с начала 2020 года имеющейся емкости кластера стало недостаточно, а линейного горизонтального или вертикального масштабирования не хватало для поддержки дополнительных сценариев использования. При этом добавление дополнительных ресурсов просто не имеет смысла ни с экономической, ни с прагматической точек зрения. А запросы Phoenix среднего размера могут существенно повлиять на кластер, забирая ресурсы у других пользователей и API из-за частой сборки мусора, а также повышенной загрузки ЦП. Поэтому требуется поддерживать новые варианты использования и большие аналитические запросы, не влияя на существующие запросы к кластеру HBase.

Напомним, Apache Phoenix – это механизм параллельной реляционной базы данных с открытым исходным кодом, который поддерживает транзакционную OLTP-обработку в реальном времени над данными в Hadoop с использованием HBase в качестве резервного хранилища. В отличие от Apache Hive, Phoenix компилирует SQL-запросы в собственные API-интерфейсы NoSQL, не используя MapReduce, позволяя разрабатывать быстрые распределенные приложения для аналитики больших данных, хранящихся в нереляционных хранилищах. Как обратиться к таблицам HBase через SQL-запросы с Phoenix и Hue, читайте в нашей новой статье.

Phoenix подключается к кластеру HBase через JDBC-драйвер, чтобы работать с NoSQL-хранилищем как с реляционной СУБД, позволяя создавать, удалять и изменять таблицы, представления, индексы и последовательности, а также вставлять и удалять строки по отдельности и целыми группами. Phoenix выполняет SQL-запрос, компилируя его в серию параллельных сканирований HBase и запуская их напрямую через API этой системы, достигая производительности порядка миллисекунд для небольших запросов. Также Phoenix сам заботится о добавлении или рандомизации ключа строки с байтом для конкретной таблицы, равномерно распределяя рабочую нагрузку записи и чтения по всем региональным серверам HBase. Подробнее о том, как связаны HBase и Phoenix, а также чем этот механизм отличается от других инструментов класса SQL-on-Hadoop, мы писали здесь.

Хотя вместе Apache Phoenix и HBase являются мощными инструментами для доступа, управления и обработки больших наборов данных, они не обходятся без затрат, поскольку вычисления совмещаются с базовым хранилищем. Отделяя обработку запросов от данных в другом кластере за пределами HBase, необходимо перемещать ресурсоемкие запросы из HBase в кластер для выполнения этих интенсивных операций с высокой загрузкой ЦП и активным потреблением других ресурсов. Поэтому нужен некоторый быстрый вычислительный механизм распределенной обработки для извлечения больших объемов данных, например, Apache Spark. Таким образом, требуется получить доступ к данным на основе Phoenix, не используя клиент HBase/Phoenix и не забирая ресурсы у других. Как это сделала команда Vimeo, мы рассмотрим далее.

Обработка моментальных снимков H-таблиц

Моментальный снимок таблицы HBase содержит метаданные о таблице, в т.ч. где хранятся данные и H-файлы, регионы и соответствующие диапазоны сканирования (начало и конец). Поддержка моментальных снимков HBase позволяет делать снимки таблицы без особого влияния на Region-серверы, поскольку операции создания снимков, клонирования и восстановления не включают копирование данных. Даже экспорт снимка в другой кластер не влияет на RegionServers. До HBase версии 0.94.6 единственным способом резервного копирования или клонирования таблицы было использование служебной программы CopyTable или ExportTable или копирование всех файлов HFiles в HDFS после отключения таблицы. Но методы CopyTable и ExportTable могут снизить производительность RegionServer, а копирование всех файлов HFiles в HDFS требует отключения таблицы, что означает невозможность чтения или записи.

Используя метаданные моментального снимка, можно восстановить ту же логику, которую Phoenix/HBase использует для получения и извлечения данных, обращаясь к HFiles непосредственно из Spark. Это перемещает обработку из кластера HBase в кластер Spark. Но обработанные данные сохраняются в Phoenix, отображаясь в HBase как нечитаемые байтовые значения, закодированные в Phoenix. Поэтому помимо получения данных непосредственно из HFiles, также необходимо декодировать значения из байтовых значений в читаемые форматы, такие как строки и целые числа.

Для этого дата-инженеры Vimeo разработали собственный алгоритм обработки таблицы, определенной ключами строки HBase, основными шагами которого стали следующие:

  • преобразование ключевых столбцов строки в байты – каждый столбец и часть ключа строки преобразуется в массив байтов;
  • объединение преобразованных столбцов массива байтов в ключ строки, включая вызов метода generateRowKey() со значением bucket для строк, в которых добавлено криптографическое хеширование («соль»);
  • запустить сканирование HBase, учитывая последовательность ключевых столбцов строки для начала и конца.

Наконец, остается самая важная и сложная часть: получение данных из HDFS без использования клиента HBase/Phoenix. В Apache Spark для этого можно использовать существующие функции для чтения данных, хранящихся в Hadoop: файлов в HDFS, источников в HBase или S3, и получить RDD для данных Hadoop-файлов через newAPIHadoopRDD. Чтобы запустить сканирования HBase с помощью newAPIHadoopRDD, необходимо сперва создать сканирование и настроить свойства Hadoop. Далее нужно настроить и запустить newAPIHadoopRDD с учетом имени snapshot’а и временного каталога HDFS для дампа метаданных из моментального снимка таблицы. Получив RDD результатов сканирования HBase в формате ключ/значение, их следует преобразовать из байтов в ячейки таблицы на основе ее схемы, получив ключ строки из результата сканирования. Далее для ячейки из строки результата нужно получить имя столбца и значение ячейки. Наконец, после сканирования, декодирования/кодирования и преобразований нужно объединить два последних раздела. В результате получится DataFrame с двумя столбцами: один последовательный с ключевыми столбцами строки, а другой – карта пар ячеек ключ/значение. О том, как другая компания с помощью snaphot’ов Apache HBase организовала миграцию данных в облачный Google BigTable, читайте в нашей новой статье.

Освоить все тонкости работы с Apache HBase для эффективной аналитики больших данных вам помогут специализированные курсы в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:

Источники

  1. https://medium.com/vimeo-engineering-blog/too-big-to-query-how-to-query-hbase-with-minimal-pain-42221f9a8623
  2. https://ru.bmstu.wiki/Apache_Phoenix
  3. https://docs.cloudera.com/HDPDocuments/HDP3/HDP-3.1.5/hbase-data-access/content/hbase-snapshots.html