Репликация Hive Metastore с помощью SSM

SSM предоставляет механизм для репликации хранилищ Hive Metastore (HMS), расположенных в разных кластерах ADH. В данной статье описаны основные концепции, принцип работы, а также показан пошаговый пример репликации.

Под капотом HMS хранит все метаданные в реляционной БД. По умолчанию в ADH это база данных, предоставляемая сервисом ADPG. В этой БД хранятся метаданные о различных Hive-сущностях, таких как таблицы, партиции, функции и прочие. SSM поддерживает репликацию следующих сущностей Hive:

  • базы данных;

  • таблицы;

  • партиции;

  • функции;

  • ограничения (constraint) типа PRIMARY KEY, FOREIGN KEY, UNIQUE, NOT NULL, DEFAULT, CHECK.

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

Репликация на основе событий

Механизм репликации в SSM реализован на основе событий Hive (Hive event), которые генерируются при изменении содержимого HMS.

События Hive

Событие Hive — это текстовая запись, которая отражает одну операцию над сущностью Hive, например, создание Hive-таблицы. События Hive генерируются org.apache.hive.hcatalog.listener.DbNotificationListener при каждой операции, приводящей к изменению данных в HMS. События Hive хранятся в таблице NOTIFICATION_LOG базы данных HMS. Примеры событий:

NL_ID|EVENT_ID|EVENT_TIME|EVENT_TYPE               |CAT_NAME|DB_NAME|TBL_NAME |MESSAGE                                                                                                                                                                                                                                                        |MESSAGE_FORMAT|
-----+--------+----------+-------------------------+--------+-------+---------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+--------------+
   12|       8|1771231855|CREATE_TABLE             |hive    |hr     |employees|H4sIAAAAAAAAAL1WbU/bMBD+K1M+l7ROYYV+K23Q2DpATZAmrShymyv1cF7mOLBS9b/vbDejCS6DSUOqYvce3/l8fu7Oa6cAcQ/C6TtyKdhC9tvtO3pA42UM9wddV5QHc0iloJy4LJUgUsr7J53jrtPSmmwOV4Klc5ZTjjZQGs9wXAqcSTrjgH8gyXm2AigqWbjKldz/FvqTi8E4CgenY78CL2c/PhdZivh66pCp08ehkAIn0ydLU2fTmjpeHV0|gzip(json-2.0)|
   13|       9|1771231928|ALTER_TABLE              |hive    |hr     |employees|H4sIAAAAAAAAAO1WbW/aMBD+K1M+00BCO16+UUo1NlYmSKVJY4oMOcCr8zLbKaMV/31nO1lJGmg7adoXJBSbe7HP5+fu8aMlgN8Dt7qWXHO6lN16/Y6ckWAdwP1Z0+bp2QIiyQlzbBpJ4BFh3U6j3bRq2pMu4Aun0YImhOEaKA3mOK45ziSZM8A/ECYs3gKIXOZtEyUffPUGk5veyPd6l6NBrhzPf1zCMubwUcQRWj3OLGdmdXEQkuNk9rTezNr|gzip(json-2.0)|
   14|      10|1771231928|INSERT                   |hive    |hr     |employees|H4sIAAAAAAAAAJ1WbW/aMBD+K1P6NYQktOPlGwWqdWNlglSatFSRIQd4dV7mOO0o4r/vbCctSUO3DqHYPM/d5Xy+F/ZGBvwBuDEwxJbTtRi02/ekRcJtCA+tjsXz1gpiwQlzLBoL4DFhg77d6xim0qQr+MZpvKIpYWgD0XCJ65bjTpAlA/wBUcqSHUBWYt4ulfjkuzeZ3wyngTe8nE5Kcrb8+TlLYuT3vuH4xgCXTHDc+C+WfONg+oZbZbdcw50|gzip(json-2.0)|

Обратите внимание на столбец MESSAGE — в нем хранится сериализованное сообщение с описанием, что именно произошло. В этом сообщении содержится подробная информация о выполненной операции, например:

{
  "eventType": "CREATE_TABLE",
  "server": "thrift://metastore:9083",
  "servicePrincipal": "hive/_HOST@REALM",
  "db": "hr",
  "table": "employees",
  "timestamp": 1771231855,
  "tableObj": {
    "tableName": "employees",
    "sd": {
      "location": "hdfs://warehouse/hr.db/employees",
      "inputFormat": "org.apache.hadoop.mapred.TextInputFormat",
      "cols": [
        {"name":"id","type":"int"},
        {"name":"name","type":"string"}
      ]
    }
  }
}

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

SSM поддерживает репликацию событий следующих типов.

Объект Реплицируемые события

База данных

CREATE, DROP, ALTER

Таблица

CREATE, DROP, ALTER

Партиция

CREATE, DROP, ALTER

Функция

CREATE, DROP

Ограничения (constraints)

CREATE, DROP

Hive Metastore fetcher

Hive Metastore fetcher — это внутренний процесс SSM, отвечающий за извлечение событий из Hive Metastore. При включенной репликации процесс запускается вместе с SSM, асинхронно извлекает события из исходного HMS и сохраняет их в базе данных. Затем SSM анализирует полученные события и выполняет соответствующие действия на стороне целевого HMS (создает таблицы, переименовывает столбцы и так далее). На следующей схеме представлен высокоуровневый процесс репликации.

Репликация Hive Metastore через SSM
Репликация Hive Metastore
Репликация Hive Metastore через SSM
Репликация Hive Metastore

Основные этапы репликации:

  1. SSM-правило срабатывает и инициирует процесс репликации.

  2. Hive Metastore fetcher извлекает снепшот Hive-событий из исходного HMS. В снепшот попадают все события, доступные в исходном HMS в данный момент времени.

  3. Hive Metastore fetcher переходит в фазу прослушивания (listening phase) и подписывается на события Hive, чтобы получать информацию о событиях, происходящих после формирования снепшота.

  4. SSM анализирует полученные события и для каждого отдельного события выполняет соответствующее действие в целевом HMS (например, создает новую Hive-таблицу).

  5. После того как все события Hive обработаны, SSM продолжает работать в режиме прослушивания, периодически опрашивая исходный HMS на наличие новых событий, пока SSM-правило активно.

Как видно из процесса, SSM использует особый двухэтапный алгоритм для извлечения событий из Hive Metastore, который описан далее.

Получение событий. Фаза снепшота и прослушивания

При выполнении цикла репликации SSM считывает события из исходного HMS в два этапа:

  1. Получение снепшота. В начале процесса репликации SSM извлекает снепшот с событиями Hive. В этот снепшот попадают все события, доступные в данный момент в HMS.

  2. Прослушивание событий. Получив снепшот, SSM переходит в режим прослушивания, периодически опрашивая HMS на наличие новых событий.

ПРИМЕЧАНИЕ
Репликация HMS с помощью SSM предполагает, что база данных целевого HMS пуста, для избежания возможных конфликтов.

Включение репликации

Для включения механизма репликации HMS необходимо установить следующие параметры конфигурации в исходном ADH-кластере (из которого будут реплицироваться данные).

Параметр Значение Локация

Enable SmartFileSystem for Hadoop

true

Clusters → <source_ADH_cluster> → Services → SSM → Primary configuration

smart.hive.event.fetch.enabled

true

Clusters → <source_ADH_cluster> → Services → SSM → Primary configuration → smart-site.xml

hive.metastore.event.listeners

org.apache.hive.hcatalog.listener.DbNotificationListener

Clusters → <source_ADH_cluster> → Services → Hive → Primary configuration → Custom hive-site.xml

hive.metastore.event.db.listener.timetolive

86400s

Clusters → <source_ADH_cluster> → Services → Hive → Primary configuration → Custom hive-site.xml

РЕКОМЕНДАЦИЯ
Дополнительные параметры для настройки процесса репликации доступны в разделе smart-site.xml.

Для запуска процесса репликации используйте правило SSM с объектом hms и действием hms-sync, например:

hms: name matches "test_db.*" | hms-sync -dest thrift://ka-adh-1.ru-central1.internal:9083

Более подробная информация о запуске процесса репликации приведена в примере ниже.

Пример

Следующий пример показывает, как реплицировать содержимое HMS из одного ADH-кластера в другой с помощью SSM. Данный сценарий может быть использован, например, при необходимости иметь резервный HMS, который включается в качестве варианта аварийного восстановления (disaster recovery), если основной HMS выходит из строя.

В примере используются два тестовых кластера ADH. В обоих кластерах установлен сервис Hive, а в исходном кластере дополнительно установлен сервис SSM.

  1. В исходном кластере включите механизм репликации HMS. После установки конфигурационных параметров перезапустите сервисы Hive и SSM.

  2. В исходном кластере на хосте с компонентом Hive Client запустите /bin/beeline и создайте тестовую Hive-таблицу:

    CREATE DATABASE test_db;
    CREATE TABLE test_db.t1 (i int);
    INSERT INTO test_db.t1 VALUES (1), (2), (3);

    При выполнении этих операций Hive сгенерирует несколько событий в HMS.

  3. Откройте SSM UI. Актуальный URL доступен в ADCM (Clusters → <source_ADH_cluster> → Services → SSM → Info).

  4. На странице Rules создайте новое правило:

    hms : name matches "test_db.*" | hms-sync -dest thrift://ka-adh2-3.ru-central1.internal:9083 -cascade -nameservice_rename "adh1 adh2"

    где:

    • name matches "test_db.*" — правило для репликации всех сущностей из базы данных Hive test_db.

    • -dest thrift://ka-adh2-3.ru-central1.internal:9083 — адрес целевого HMS. Thrift-адрес HMS можно найти в разделе настроек hive-site.xml сервиса Hive (включите опцию Advanced).

    • -cascade — указывает, следует ли выполнять каскадное удаление родительских сущностей при репликации событий типа DROP.

    • -nameservice_rename "adh1 adh2" — переименовывает значения HDFS nameservice при репликации сущностей (параметр dfs.internal.nameservices сервиса HDFS).

  5. Запустите правило.

  6. Подождите несколько секунд, а затем проверьте страницу Actions. Страница отображает действия, выполненные SSM-агентом для репликации операций CREATE/INSERT над тестовой Hive-таблицей.

    Действия SSM
    Страница Actions
  7. В целевом кластере запустите /bin/beeline и проверьте реплицированную таблицу Hive:

    SHOW DATABASES;
    SHOW TABLES IN test_db;

    Тестовые база данных/таблица успешно реплицированы в целевой HMS:

    SHOW DATABASES;
    +----------------+
    | database_name  |
    +----------------+
    | default        |
    | test_db        |
    +----------------+
    
    SHOW TABLES in test_db;
    +-----------+
    | tab_name  |
    +-----------+
    | t1        |
    +-----------+
  8. В целевом кластере выполните команду DESCRIBE для реплицированной таблицы:

    DESCRIBE EXTENDED test_db.t1;

    Вывод:

    +-----------------------------+----------------------------------------------------+----------+
    |          col_name           |                     data_type                      | comment  |
    +-----------------------------+----------------------------------------------------+----------+
    | i                           | int                                                |          |
    |                             | NULL                                               | NULL     |
    | Detailed Table Information  | Table(tableName:t1, dbName:test_db, owner:hive, createTime:1771568872, lastAccessTime:0, retention:0, sd:StorageDescriptor(cols:[FieldSchema(name:i, type:int, comment:null)], location:hdfs://adh2/apps/hive/warehouse/test_db.db/t1, inputFormat:org.apache.hadoop.mapred.TextInputFormat, outputFormat:org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat, compressed:false, numBuckets:-1, serdeInfo:SerDeInfo(name:null, serializationLib:org.apache.hadoop.hive.serde2.lazy.LazySimpleSerDe, parameters:{serialization.format=1}), bucketCols:[], sortCols:[], parameters:{}, skewedInfo:SkewedInfo(skewedColNames:[], skewedColValues:[], skewedColValueLocationMaps:{}), storedAsSubDirectories:false), partitionKeys:[], parameters:{external.table.purge=TRUE, totalSize=0, numRows=1, rawDataSize=1, EXTERNAL=TRUE, COLUMN_STATS_ACCURATE={\"COLUMN_STATS\":{\"i\":\"true\"}}, numFiles=0, transient_lastDdlTime=1771566711, TRANSLATED_TO_EXTERNAL=TRUE, bucketing_version=2, numFilesErasureCoded=0}, viewOriginalText:null, viewExpandedText:null, tableType:EXTERNAL_TABLE, rewriteEnabled:false, catName:hive, ownerType:USER, writeId:0, accessType:8, id:11) |          |
    +-----------------------------+----------------------------------------------------+----------+

    Обратите внимание на строку location:hdfs://adh2/apps/hive/…​. С помощью параметра -nameservice_rename "adh1 adh2" в SSM-правиле значение nameservice adh1 было переименовано в adh2 при репликации.

  9. Пока SSM-правило активно, SSM постоянно опрашивает исходный HMS на наличие новых событий и реплицирует их, если таковые имеются. В исходном кластере удалите тестовую таблицу:

    DROP TABLE test_db.t1;
  10. В целевом кластере проверьте, что операция DROP TABLE была реплицирована, а соответствующая таблица удалена:

    SHOW TABLES in test_db;

    Вывод:

    +-----------+
    | tab_name  |
    +-----------+
    +-----------+
Нашли ошибку? Выделите текст и нажмите Ctrl+Enter чтобы сообщить о ней