Перенос рабочих нагрузок Hive из Azure HDInsight 3.6 в HDInsight 4.0

  • Статья

HDInsight 4.0 имеет несколько преимуществ по сравнению с HDInsight 3.6. Ниже приведен обзор новых возможностей в HDInsight 4.0.

В этой статье описаны действия по переносу рабочих нагрузок Hive из HDInsight версии 3.6 на версию 4.0, а также приведена информация о выполнении следующих действий:

  • Копирование хранилища метаданных Hive и обновление схемы.
  • Безопасная миграция для обеспечения совместимости с ACID.
  • Сохранение политик безопасности Hive.

Новые и старые кластеры HDInsight должны иметь доступ к одним и тем же учетным записям хранения.

Миграцию таблиц Hive в новую учетную запись хранения необходимо выполнить отдельно. См. статью Миграция Hive между учетными записями хранения.

Изменения в Hive 3 и новые возможности:

Изменения клиента Hive

Hive 3 поддерживает только тонкий клиент Beeline для выполнения запросов и административных команд Hive из командной строки. Beeline использует подключение JDBC к HiveServer для выполнения всех команд. Синтаксический анализ, компиляция и выполнение операций выполняются в HiveServer.

Вы вводите поддерживаемые команды CLI Hive, вызывая Beeline с помощью ключевое слово Hive в качестве пользователя Hive или вызывая beeline с помощьюbeeline -u <JDBC URL>. URL-адрес JDBC можно получить на странице Ambari Hive.

Screenshot showing JDBC URL output.

Использование Beeline (вместо толстых клиентских интерфейсов командной строки Hive, которая больше не поддерживается) имеет несколько преимуществ, в том числе:

  • Вместо поддержания всей базы кода Hive можно поддерживать только клиент JDBC.
  • Затраты на запуск ниже с помощью Beeline, так как вся база кода Hive не участвует.

Вы также можете выполнить скрипт Hive, который находится в каталоге "/usr/bin", который вызывает подключение beeline с помощью URL-адреса JDBC.

Screenshot showing beeline connection output.

Тонкая архитектура клиента упрощает защиту данных в

  • Состояние сеанса, внутренние структуры данных, пароли и т. д. находятся на клиенте вместо сервера.
  • Небольшое количество управляющих программ, необходимых для выполнения запросов, упрощает мониторинг и отладку.

HiveServer применяет параметры списка разрешений и блокировки, которые можно изменить с помощью SET команд. С помощью списков блокировок можно ограничить конфигурацию памяти, чтобы предотвратить нестабильность сервера Hive. Вы можете настроить несколько экземпляров HiveServer с различным списком разрешений и списком блокировок, чтобы установить различные уровни стабильности.

Изменения хранилища метаданных Hive

Hive теперь поддерживает только удаленное хранилище метаданных вместо внедренного хранилища метаданных (в JVM HS2). Хранилище метаданных Hive находится на узле в кластере, управляемом Ambari в составе стека HDInsight. Автономный сервер за пределами кластера не поддерживается. Команды key=value в командной строке больше не задаются для настройки хранилища метаданных Hive. Основываясь на значении, настроенном в файле hive.metastore.uris=' ' ", используемая и установленная служба HMS.

Изменение подсистемы выполнения

Apache Tez заменяет MapReduce в качестве механизма выполнения Hive по умолчанию. MapReduce устарел, начиная с Hive 2.0, ссылается на HIVE-12300. При использовании выражений ациклических графов (DAG) и примитивов передачи данных выполнение запросов Hive в Tez повышает производительность. SQL-запросы, которые вы отправляете в Hive, выполняются следующим образом.

  1. Hive компилирует запрос.
  2. Tez выполняет запрос.
  3. YARN выделяет ресурсы для приложений в кластере и включает авторизацию для заданий Hive в очередях YARN.
  4. Hive обновляет данные в ABFS или WASB.
  5. Hive возвращает результаты запроса по подключению JDBC.

Если устаревший скрипт или приложение указывает MapReduce для выполнения, исключение возникает следующим образом.

Screenshot showing map reducer exception output.

Примечание.

Большинство определяемых пользователем функций (UDFs) не требуют изменения для выполнения в Tez вместо MapReduce.

Изменения в отношении транзакции ACID и CBO:

  • Таблицы ACID — это тип таблицы по умолчанию в HDInsight 4.x без производительности или операционной перегрузки.

  • Упрощенная разработка приложений, операции с более строгими гарантиями транзакций и более простой семантикой для команд SQL

  • Внутренний компонент Hive отвечает за сегментирование таблиц ACID в HDInsight 4.1, что приведет к удалению затрат на обслуживание.

  • Расширенные оптимизации— обновление в CBO

  • Кэш автоматических запросов. Свойство, используемое для включения кэширования hive.query.results.cache.enabledзапросов. Для этого свойства необходимо задать значение true. Hive хранит кэш результатов запроса по /tmp/hive/__resultcache__/. умолчанию, Hive выделяет 2 ГБ для кэша результатов запроса. Этот параметр можно изменить, настроив следующий параметр в байтах hive.query.results.cache.max.size.

    Дополнительные сведения о преимуществах миграции в Azure HDInsight 4.0.

Материализованные перезаписи представлений

Дополнительные сведения о Hive — материализованные представления

Изменения после обновления до Apache Hive 3

Чтобы найти и использовать таблицы Apache Hive 3 после обновления, необходимо понять изменения, которые происходят во время процесса обновления. Изменения в управлении и расположении таблиц, разрешения на каталоги таблиц, типы таблиц и проблемы соответствия ТРЕБОВАНИЯМ ACID.

Управление таблицами Hive

Hive 3 принимает больше управления таблицами, чем Hive 2, и для управляемых таблиц требуется строгое определение. Уровень управления Hive принимает таблицы однородным для традиционных баз данных. Hive самостоятельно учитывает разностные изменения данных; эта платформа управления повышает производительность.

Например, если Hive знает, что разрешение запроса не требует проверки таблиц для новых данных, Hive возвращает результаты из кэша результатов запроса hive. При изменении базовых данных в материализованном представлении Hive необходимо перестроить материализованное представление. Свойства ACID показывают, какие строки изменились, и их необходимо обработать и добавить в материализованное представление.

Изменение свойств ACID в Hive

Hive 2.x и 3.x имеют таблицы транзакционных (управляемых) и нетрансляционных (внешних). Таблицы транзакций имеют атомарные, согласованные, изоляционные и устойчивые (ACID) свойства. В Hive 2.x начальная версия обработки транзакций ACID — ACID версии 1. В Hive 3.x таблицы по умолчанию будут использоваться с ACID версии 2.

Собственные и не собственные форматы хранилища

служба хранилища форматы являются фактором обновления изменений в типах таблиц. Hive 2.x и 3.x поддерживает следующие форматы собственного и не собственного хранилища Hadoop.

Native: таблицы со встроенной поддержкой в Hive в следующих форматах файлов

  • Текст
  • Файл последовательности
  • RC-файл
  • AVRO-файл
  • ORC-файл
  • Файл Parquet

Не собственные: таблицы, использующие обработчик хранилища, например Druid служба хранилища Handler или HBase служба хранилища Handler

Обновление HDInsight 4.x в типах таблиц

В следующей таблице сравниваются типы таблиц Hive и операции ACID перед обновлением с HDInsight 3.x и после обновления до HDInsight 4.x. Владение файлом таблицы Hive является фактором определения типов таблиц и операций ACID после обновления.

Сравнение типов таблиц HDInsight 3.x и HDInsight 4.x

HDInsight 3.x - - - HDInsight 4.x -
Тип таблицы ACID версии 1 Формат Владелец (пользователь) файла таблицы Hive Тип таблицы ACID версии 2
Внешние No Собственный или не собственный Hive или non-Hive Внешние No
Управляемый Да ORC Hive или non-Hive Управляемые, обновляемые Да
Управляемый No ORC Куст Управляемые, обновляемые Да
Управляемый No ORC non-Hive Внешний, с удалением данных Нет
Управляемый No Native (но не ORC) Куст Управляемые, вставка только Да
Управляемый No Native (но не ORC) non-Hive Внешний, с удалением данных No
Управляемый No Не собственный Hive или non-Hive Внешний, с удалением данных No

Олицетворение Hive

Олицетворение Hive по умолчанию было включено в Hive 2 (doAs=true) и отключено по умолчанию в Hive 3. Олицетворение Hive запускает Hive как конечный пользователь или нет.

Другие изменения обновления HDInsight 4.x

  1. Управляемые таблицы ACID, не принадлежащие пользователю Hive, остаются управляемыми таблицами после обновления, но Hive становится владельцем.
  2. После обновления формат таблицы Hive совпадает с форматом перед обновлением. Например, собственные или не собственные таблицы остаются собственными или не собственными, соответственно.

Изменения расположения

После обновления расположение управляемых таблиц или секций не изменяется при одном из следующих условий:

  • Старый каталог таблицы или секции не был в расположении по умолчанию /apps/hive/warehouse перед обновлением.
  • Старая таблица или секция находится в файловой системе, отличной от нового каталога хранилища.
  • Старый каталог таблицы или секции находится в другой зоне шифрования, отличной от нового каталога хранилища.

В противном случае расположение управляемых таблиц или секций изменяется. Процесс обновления перемещает управляемые файлы в /hive/warehouse/managed. По умолчанию Hive помещает новые внешние таблицы, созданные в HDInsight 4.x, в /hive/warehouse/external

Прежнее /apps/hive directoryрасположение хранилища Hive 2.x может существовать в HDInsight 4.x.

Следующие сценарии присутствуют для изменений расположения

Ситуация 1

Если таблица является управляемой таблицей в HDInsight-3.x и если она присутствует в расположении /apps/hive/warehouse и преобразована как внешняя таблица в HDInsight-4.x, то расположение совпадает /apps/hive/warehouse с HDInsight 4.x. Он не изменяет расположение. После этого шага, если вы выполняете команду alter table, чтобы преобразовать ее как управляемую (кислотную) таблицу в то же место /apps/hive/warehouse.

Сценарий 2

Если таблица является управляемой таблицей в HDInsight-3.x, а если она присутствует в расположении /apps/hive/warehouse и преобразована в управляемую (ACID) таблицу в HDInsight 4.x, то это расположение /hive/warehouse/managed.

Сценарий 3 . Если вы создаете внешнюю таблицу, в HDInsight-4.x без указания какого-либо расположения он отображается в расположении /hive/warehouse/external.

Преобразование таблицы

После обновления для преобразования нетрансляционной таблицы в таблицу ACID версии 2 используйте ALTER TABLE команду и задайте свойства таблицы.

transaction'='true' and 'EXTERNAL'='false
  • Управляемая таблица, формат ORC, не относящийся к ACID, и принадлежащий пользователю, не являющимся Hive в HDInsight-3.x, будет преобразована во внешнюю, ненужную таблицу в HDInsight-4.x.
  • Если пользователь хочет изменить внешнюю таблицу (не-ACID) на ACID, то она также должна изменить внешнюю таблицу на управляемую и ACID. Так как в HDInsight-4.x все управляемые таблицы являются строго ACID по умолчанию. Нельзя преобразовать внешние таблицы (не-ACID) в таблицу ACID.

Примечание.

Таблица должна быть таблицей ORC.

Чтобы преобразовать внешнюю таблицу (не-ACID) в таблицу Managed (ACID), выполните следующее.

  1. Преобразуйте внешнюю таблицу в управляемые и кислотные значения равным true с помощью следующей команды: 
    alter table <table name> set TBLPROPERTIES ('EXTERNAL'='false', 'transactional'='true');
  2. При попытке выполнить следующую команду для внешней таблицы вы получите следующую ошибку.

Ситуация 1

Рассмотрим таблицу RT— внешнюю таблицу (не-ACID). Если таблица не является таблицей ORC,

alter table rt set TBLPROPERTIES ('transactional'='true');
ERROR : FAILED: Execution Error, return code 1 from org.apache.hadoop.hive.ql.exec.DDLTask. Unable to alter table. The table must be stored using an ACID compliant format (such as ORC): work.rt
The table must be ORC format

Сценарий 2

>>>> alter table rt set TBLPROPERTIES ('transactional'='true'); If the table is ORC table.
ERROR:
Error: Error while processing statement: FAILED: Execution Error, return code 1 from org.apache.hadoop.hive.ql.exec.DDLTask. Unable to alter table. work.rt can't be declared transactional because it's an external table (state=08S01,code=1)

Эта ошибка возникает, так как таблица RT является внешней таблицей, и вы не можете преобразовать внешнюю таблицу в ACID.

Сценарий 3

>>>> alter table rt set TBLPROPERTIES ('EXTERNAL'='false');
ERROR:
Error: Error while processing statement: FAILED: Execution Error, return code 1 from org.apache.hadoop.hive.ql.exec.DDLTask. Unable to alter table. Table work.rt failed strict managed table checks due to the following reason: Table is marked as a managed table but isn't transactional. (state=08S01,code=1)

Здесь мы пытаемся сначала изменить внешнюю таблицу на управляемую. В HDInsight 4.x она должна быть строго управляемой таблицей (это означает, что она должна быть ACID). Итак, здесь вы получаете взаимоблокировку. Единственный способ преобразовать внешнюю таблицу (NON_ACID) в управляемый (ACID) необходимо выполнить команду:

alter table rt set TBLPROPERTIES ('EXTERNAL'='false', 'transactional'='true');

Синтаксис и семантика

  • Создание таблицы для повышения удобства использования и функциональности, создание таблицы Hive 3 изменилось. Hive изменил создание таблицы следующими способами.

    • Создает таблицу, совместимую с ACID, которая используется по умолчанию в HDP
    • Поддерживает простые операции записи и вставки
    • Запись в несколько секций
    • Вставка нескольких обновлений данных в одной инструкции SELECT
    • Устраняет необходимость сегментирования.

    Если у вас есть конвейер ETL, создающий таблицы в Hive, таблицы создаются как ACID. Hive теперь жестко управляет доступом и периодически выполняет сжатие в таблицах

    Перед обновлением в HDInsight 3.x по умолчанию CREATE TABLE создал таблицу без КИСЛОТЫ.

    После обновления по умолчанию CREATE TABLE создает полную транзакционные таблицы ACID в формате ORC.

    Действие, необходимое для доступа к таблицам Hive ACID из Spark, подключение к Hive с помощью хранилища Hive Подключение or (HWC). Чтобы записать таблицы ACID в Hive из Spark, используйте API HWC и HWC

  • Экранирование db.table ссылок

    Необходимо изменить запросы, использующие ссылки db.table, чтобы предотвратить интерпретацию всей строки db.table в качестве имени таблицы Hive. Hive 3.x отклоняет db.table запросы SQL. Точка (.) не допускается в именах таблиц. Имя базы данных и имя таблицы заключены в обратные очки. Найдите таблицу с ссылкой на проблемную таблицу. math.students отображается в инструкции CREATE TABLE. Заключите имя базы данных и имя таблицы в обратные очки.

    TABLE `math`.`students` (name VARCHAR(64), age INT, gpa DECIMAL(3,2));

  • Результаты CASTING TIMESTAMPS приложений, которые приведение числовых меток к меткам времени отличаются от Hive 2 до Hive 3. Apache Hive изменил поведение CAST в соответствии со стандартом SQL, который не связывает часовой пояс с типом TIMESTAMP.

    Перед обновлением значения числового типа в метку времени можно использовать для создания результата, отражающего часовой пояс кластера. Например, 1597217764557 — 2020-08-12 00:36:04 PDT. При выполнении следующего запроса числовое значение приводится к метке времени в PDT: SELECT CAST(1597217764557 AS TIMESTAMP); | 2020-08-12 00:36:04 |

    После обновления значения числового типа в метку времени создается результат, который отражает utc вместо часового пояса кластера. Выполнение запроса приводит числовое значение к метке времени в формате UTC. SELECT CAST(1597217764557 AS TIMESTAMP); | 2020-08-12 07:36:04.557 |

    Приложения обязательных изменений. Не приведение из числа для получения локального часового пояса. Встроенные функции from_utc_timestamp и to_utc_timestamp можно использовать для имитации поведения до обновления.

  • ПРОВЕРКА СОВМЕСТИМОСТИ СТОЛБЦОВ ИЗМЕНЯЕТ конфигурацию по умолчанию, может привести к сбою приложений, изменяющих типы столбцов.

    Перед обновлением в HDInsight 3.x Hive.metastore.disallow.inable.col.type.changes по умолчанию имеет значение false, чтобы разрешить изменения несовместимых типов столбцов. Например, можно изменить столбец STRING на столбец несовместимого типа, например MAP<STRING, STRING>. Ошибка не возникает.

    После обновления hive.metastore.disallow.incompatible.col.type.changes по умолчанию имеет значение true. Hive предотвращает изменения несовместимых типов столбцов. Изменения типа совместимых столбцов, такие как INT, STRING, BIGINT, не блокируются.

    Чтобы предотвратить возможные повреждения данных, приложения обязательных изменений для изменения несовместимого типа столбца.

  • УДАЛЕНИЕ СЕКЦИЙ

    Автономные и NO_DROP ключевое слово в предложении CASCADE для удаления секций вызывают проблемы с производительностью и больше не поддерживаются.

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

    После обновления OFFLINE и NO_DROP не поддерживаются в предложении CASCADE.

    Действия, необходимые для удаления автономных и NO_DROP из предложения CASCADE. Используйте схему авторизации, например Ranger, чтобы предотвратить удаление или чтение секций.

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

Ограничения в отношении CBO

  • Мы видим, что выходные данные выбора дают конечный ноль в нескольких столбцах. Например, если у нас есть столбец таблицы с типом данных в виде десятичного (38,4) и если мы вставим данные как 38, то он добавляет конечный нуль и предоставляет результат в виде 38,0000 Как на и https://issues.apache.org/jira/browse/HIVE-12063https://issues.apache.org/jira/browse/HIVE-24389, идея сохраняет масштаб и точность вместо запуска оболочки в десятичных столбцах. Это поведение по умолчанию из Hive 2. Чтобы устранить эту проблему, можно следовать приведенному ниже параметру.

    1. Измените тип данных на исходном уровне, чтобы настроить точность как col1(decimal(38,0)). Это значение предоставляет результат в виде 38 без нулевых значений. Но если вы вставляете данные как 35.0005, это .0005 и предоставляет только значение 38 1.Удалите конечные нули для столбцов с проблемой, а затем приведение к строке.
      1. Выберите TRIM(cast(<column_name> AS STRING)+0 FROM <table_name>;
      2. Используйте regex.

  1. Запрос Hive завершается ошибкой с параметром "Неподдерживаемое выражение subQuery" при использовании UNIX_TIMESTAMP в запросе. Например, при выполнении запроса возникает ошибка "Неподдерживаемое выражение subQuery".

    select * from
(SELECT col_1 from table1 where col_2 >= unix_timestamp('2020-03-07','yyyy-MM-dd'));

    Корневой случай этой проблемы заключается в том, что текущая база кода Hive создает исключение, которое анализирует UNIX_TIMESTAMP, так как для точности HiveTypeSystemImpl.java codeUNIX_TIMESTAMP , в которой Calcite распознает BIGINTкак точность. Но приведенный ниже запрос работает хорошо select * from (SELECT col_1 from table1 where col_2 >= 1);

    Эта команда выполняется успешно, так как col_2 является целым числом. Указанная выше проблема устранена в hdi-3.1.2-4.1.12(4.1 stack) и hdi-3.1.2-5.0.8(5.0 stack)

Действия по обновлению

1. Подготовка данных

  • HDInsight 3.6 по умолчанию не поддерживает таблицы ACID. Однако если имеются таблицы ACID, выполните в них основное сжатие. Дополнительные сведения о сжатии см. на странице руководства по языку Hive.

  • При использовании Azure Data Lake Storage 1-го поколения расположение таблиц Hive, скорее всего, зависит от конфигураций кластера HDFS. Выполните следующий сценарий, чтобы обеспечить перенос этих расположений в другие кластеры. См. статью Запуск сценария в работающем кластере.

    Свойство Значение
    URI bash-скрипта https://hdiconfigactions.blob.core.windows.net/linuxhivemigrationv01/hive-adl-expand-location-v01.sh
    Типы узлов Head
    Параметры

2. Копирование базы данных SQL

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

  • Если кластер использует внешнее хранилище метаданных Hive, создайте его копию. Возможные варианты: экспорт и импорт и восстановление до точки во времени.

3. Обновление схемы хранилища метаданных

На этом этапе для обновления схемы хранилища метаданных используется Hive Schema Tool из HDInsight 4.0.

Предупреждение

Этот шаг не является обратимым. Выполните это действие только для копии хранилища метаданных.

  1. Создайте временный кластер HDInsight 4.0 для доступа к schematool в Hive 4.0. Для выполнения этого действия можно использовать хранилище метаданных Hive по умолчанию.

  2. В кластере HDInsight 4.0 выполните команду schematool, чтобы обновить целевое хранилище метаданных HDInsight 3.6. Измените следующий скрипт оболочки, чтобы добавить имя сервера SQL, имя базы данных, имя пользователя и пароль. Откройте сеанс SSH на головном узле и запустите его.

    SERVER='servername.database.windows.net'  # replace with your SQL Server
DATABASE='database'  # replace with your 3.6 metastore SQL Database
USERNAME='username'  # replace with your 3.6 metastore username
PASSWORD='password'  # replace with your 3.6 metastore password
STACK_VERSION=$(hdp-select status hive-server2 | awk '{ print $3; }')
/usr/hdp/$STACK_VERSION/hive/bin/schematool -upgradeSchema -url "jdbc:sqlserver://$SERVER;databaseName=$DATABASE;trustServerCertificate=false;encrypt=true;hostNameInCertificate=*.database.windows.net;" -userName "$USERNAME" -passWord "$PASSWORD" -dbType "mssql" --verbose

    Примечание.

    Эта служебная программа использует клиент beeline для выполнения сценариев SQL в /usr/hdp/$STACK_VERSION/hive/scripts/metastore/upgrade/mssql/upgrade-*.mssql.sql.

    Синтаксис SQL в этих сценариях не обязательно совместим с другими клиентскими инструментами. Например, в SSMS и Редакторе запросов на портале Azure после каждой команды необходимо указывать ключевое слово GO.

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

  3. Проверьте окончательную версию, выполнив запрос select schema_version from dbo.version.

    Выходные данные должны соответствовать следующей команде Bash из кластера HDInsight 4.0.

    grep . /usr/hdp/$(hdp-select --version)/hive/scripts/metastore/upgrade/mssql/upgrade.order.mssql | tail -n1 | rev | cut -d'-' -f1 | rev

  4. Удалите временный кластер HDInsight 4.0.

4. Развертывание нового кластера HDInsight 4.0

Создайте кластер HDInsight 4.0, выбрав обновленное хранилище метаданных Hive и те же учетные записи хранения.

  • Новому кластеру не нужно иметь ту же файловую систему по умолчанию.

  • Если хранилище метаданных содержит таблицы в нескольких учетных записях хранения, необходимо добавить эти учетные записи хранения в новый кластер, чтобы получить доступ к таблицам. Дополнительные служба хранилища учетные записи см. в HDInsight.

  • Если задания Hive завершаются ошибкой из-за недоступности хранилища, убедитесь, что таблицы расположены в учетной записи хранения, добавленной в кластер.

    Используйте следующую команду Hive, чтобы определить расположение таблицы:

    SHOW CREATE TABLE ([db_name.]table_name|view_name);

5. Преобразование таблиц для обеспечения соответствия с ACID

Управляемые таблицы должны быть совместимыми с ACID в HDInsight 4.0. Выполните команду strictmanagedmigration в HDInsight 4.0, чтобы преобразовать все управляемые таблицы без ACID во внешние таблицы со свойством 'external.table.purge'='true'. Выполните в головном узле следующую команду:

sudo su - hive
STACK_VERSION=$(hdp-select status hive-server2 | awk '{ print $3; }')
/usr/hdp/$STACK_VERSION/hive/bin/hive --config /etc/hive/conf --service strictmanagedmigration --hiveconf hive.strict.managed.tables=true -m automatic --modifyManagedTables

6. Класс не найден с ошибкой MultiDelimitSerDe

Проблема.

В некоторых ситуациях при выполнении запроса Hive может появиться java.lang.ClassNotFoundExceptionorg.apache.hadoop.hive.contrib.serde2.MultiDelimitSerDe сообщение о том, что класс не найден. Эта ошибка возникает при миграции клиента из HDInsight 3.6 в HDInsight 4.0. Класс org.apache.hadoop.hive.contrib.serde2.MultiDelimitSerDeSerDe, который является частью hive-contrib-1.2.1000.2.6.5.3033-1.jar HDInsight 3.6, удаляется, и мы используем org.apache.hadoop.hive.serde2.MultiDelimitSerDe класс, который является частью hive-exec jar HDI-4.0. hive-exec jar по умолчанию загружается в HS2 при запуске службы.

ДЕЙСТВИЯ ПО УСТРАНЕНИЮ НЕПОЛАДОК

  1. Проверьте, должен ли любой JAR-файл в папке (скорее всего, находиться в папке библиотек Hive, которая находится /usr/hdp/current/hive/lib в HDInsight), содержит этот класс или нет.
  2. Проверьте класс org.apache.hadoop.hive.contrib.serde2.MultiDelimitSerDe и org.apache.hadoop.hive.serde2.MultiDelimitSerDe как упоминание в решении.

Решение

  1. Хотя JAR-файл является двоичным файлом, вы по-прежнему можете использовать grep команду с -Hrni переключателями, как показано ниже для поиска определенного имени класса.

    grep -Hrni "org.apache.hadoop.hive.contrib.serde2.MultiDelimitSerDe" /usr/hdp/current/hive/lib

  2. Если не удалось найти класс, он не возвращает выходные данные. Если он находит класс в JAR-файле, он вернет выходные данные.

  3. Ниже приведен пример, полученный из кластера HDInsight 4.x

    sshuser@hn0-alters:~$ grep -Hrni "org.apache.hadoop.hive.serde2.MultiDelimitSerDe" /usr/hdp/4.1.9.7/hive/lib/
Binary file /usr/hdp/4.1.9.7/hive/lib/hive-exec-3.1.0.4.1-SNAPSHOT.jar matches

  4. Из приведенных выше выходных данных мы можем подтвердить, что не содержит jar-файл класса org.apache.hadoop.hive.contrib.serde2.MultiDelimitSerDe и jar hive-exec содержится org.apache.hadoop.hive.serde2.MultiDelimitSerDe.

  5. Попробуйте создать таблицу с форматом строки DerDe как ROW FORMAT SERDE org.apache.hadoop.hive.serde2.MultiDelimitSerDe

  6. Эта команда исправит проблему. Если вы уже создали таблицу, ее можно переименовать с помощью приведенных ниже команд.

    Hive => ALTER TABLE TABLE_NAME SET SERDE 'org.apache.hadoop.hive.serde2.MultiDelimitSerDe'
Backend DB => UPDATE SERDES SET SLIB='org.apache.hadoop.hive.serde2.MultiDelimitSerDe' where SLIB='org.apache.hadoop.hive.contrib.serde2.MultiDelimitSerDe';

Команда обновления — обновить сведения вручную в серверной базе данных, а команда alter используется для изменения таблицы с новым классом SerDe из beeline или Hive.

Сценарий сравнения схемы серверной базы данных Hive

После завершения миграции можно запустить следующий скрипт.

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

Следующий путь содержит файл schemacompare_final.py и test.csv. Скрипт присутствует в файле schemacompare_final.py, а файл test.csv содержит все имя столбца и тип данных для всех таблиц, которые должны присутствовать в серверной базе данных hive.

https://hdiconfigactions2.blob.core.windows.net/hiveschemacompare/schemacompare_final.py

https://hdiconfigactions2.blob.core.windows.net/hiveschemacompare/test.csv

Скачайте эти два файла из ссылки. И скопируйте эти файлы в один из головных узлов, где выполняется служба hive.

Действия по выполнению скрипта:

Создайте каталог с именем schemacompare в каталоге "/tmp".

Поместите файл "schemacompare_final.py" и test.csv в папку "/tmp/schemacompare". Выполните "ls -ltrh /tmp/schemacompare/" и проверьте наличие файлов.

Чтобы выполнить скрипт Python, используйте команду python schemacompare_final.py. Этот скрипт запускает выполнение скрипта и занимает менее пяти минут. Приведенный выше скрипт автоматически подключается к серверной базе данных и получает сведения из каждой таблицы, которая использует Hive и обновляет сведения в новом CSV-файле с именем return.csv. После создания файла return.csv он сравнивает данные с файлом "test.csv" и выводит имя столбца или тип данных, если под именем таблицы отсутствует что-либо.

После выполнения скрипта вы увидите следующие строки, которые указывают на получение сведений для таблиц и выполнение скрипта

KEY_CONSTRAINTS
Details Fetched
DELEGATION_TOKENS
Details Fetched
WRITE_SET
Details Fetched
SERDES
Details Fetched

И вы увидите сведения о разнице в строке "DIFFERENCE DETAILS:". Если есть какая-либо разница, он печатает

PART_COL_STATS;
('difference', ['BIT_VECTOR', 'varbinary'])
The line with semicolon PART_COL_STATS; is the table name. And under the table name you can find the differences as ('difference', ['BIT_VECTOR', 'varbinary']) if there are any difference in column or datatype.

Если в таблице нет различий, выходные данные

BUCKETING_COLS;
('difference', [])
PARTITIONS;
('difference', [])

Из этих выходных данных можно найти имена столбцов, отсутствующие или неверные. Вы можете выполнить следующий запрос в серверной базе данных, чтобы проверить, отсутствует ли столбец.

SELECT * FROM INFORMATION_SCHEMA.columns WHERE TABLE_NAME = 'PART_COL_STATS';

Если в таблице отсутствует любой из столбцов, например при выполнении запросов, таких как вставка или вставка перезаписи, статистика будет вычисляться автоматически, и она пытается обновить таблицу статистики, например PART_COL_STATS и TAB_COL_STATS. Если столбец, например "BIT_VECTOR", отсутствует в таблицах, он завершится ошибкой "Недопустимое имя столбца". Столбец можно добавить как упоминание в следующих командах. В качестве обходного решения можно отключить статистику, задав следующие свойства, которые не могут обновить статистику в серверной базе данных.

hive.stats.autogather=false;
hive.stats.column.autogather=false;
To Fix this issue, run the following two queries on backend SQL server (Hive metastore DB):

ALTER TABLE PART_COL_STATS ADD BIT_VECTOR VARBINARY(MAX);
ALTER TABLE TAB_COL_STATS ADD BIT_VECTOR VARBINARY(MAX);

Этот шаг позволяет избежать сбоев запросов, которые завершаются ошибкой "Недопустимое имя столбца" после миграции.

Обеспечение защиты Hive в версиях HDInsight

HDInsight при необходимости интегрируется с идентификатором Microsoft Entra с помощью пакета безопасности HDInsight Enterprise (ESP). Корпоративный пакет безопасности использует Kerberos и Apache Ranger для управления разрешениями конкретных ресурсов в кластере. Политики Ranger, развернутые для Hive в HDInsight 3.6, можно перенести в HDInsight 4.0, выполнив следующие действия:

  1. Перейдите на панель Service Manager Ranger в кластере HDInsight 3.6.
  2. Перейдите к политике с именем Hive и экспортируйте ее в JSON-файл.
  3. Убедитесь, что все пользователи, на которых ссылаются в экспортированном JSON-файле политики, существуют в новом кластере. Если на пользователя ссылаются в JSON-файле политики, но его не существует в новом кластере, добавьте пользователя в новый кластер или удалите ссылку из политики.
  4. Перейдите на панель Service Manager Ranger в кластере HDInsight 4.0.
  5. Перейдите к политике с именем Hive и импортируйте JSON-файл политики Ranger из шага 2.

Изменения Hive в HDInsight 4.0, которые могут потребовать изменений в приложении

Другие изменения см. в объявлении о HDInsight 4.0.

После миграции

Выполните следующие действия после завершения миграции.

Блюсти таблицы

  1. Повторно создайте таблицы в Hive 3.1 с помощью CTAS или IOW для изменения типа таблицы вместо изменения свойств таблицы.
  2. Сохраняйте doAs как false.
  3. Убедитесь, что управляемое владение таблицами и данными используется пользователем hive.
  4. Используйте управляемые таблицы ACID, если формат таблицы — ORC и управляемый не-ACID для типов, отличных от ORC.
  5. Повторно создайте статистику для повторно созданных таблиц, так как миграция привела бы к неправильной статистике.

Работоспособности кластера

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

Настройте хранилище метаданных, чтобы уменьшить их использование ЦП.

  1. Отключите прослушиватели событий транзакций.

    Примечание.

    Выполните следующие действия, только если компонент hive реплика tion не использовался.

    1. В пользовательском интерфейсе Ambari удалите значение hive.metastore.transactional.event.listeners.
    2. Значение по умолчанию: org.apache.hive.hcatalog.listener.DbNotificationListener
    3. Новое значение: <Empty>

  2. Отключение Hive PrivilegeSynchronizer

    1. В пользовательском интерфейсе Ambari задайте hive.privilege.synchronizer = false.
    2. Значение по умолчанию: true
    3. Новое значение: false

  3. Оптимизация функции восстановления секций

  4. Отключение восстановления секций. Эта функция используется для синхронизации секций таблиц Hive в расположении хранилища с хранилищем метаданных Hive. Эту функцию можно отключить, если после приема данных используется "исправление msck".

  5. Чтобы отключить функцию , добавьте "discover.partitions=false" в свойства таблицы с помощью ALTER TABLE. ИЛИ (если функция не может быть отключена)

  6. Увеличьте частоту восстановления секции.

  7. В пользовательском интерфейсе Ambari увеличьте значение metastore.partition.management.task (в секундах).

    Примечание.

    Это изменение может отложить видимость некоторых секций, которые были приема в хранилище.

    1. Значение по умолчанию: 60
    2. Предлагаемое значение: 3600

  8. Дополнительные оптимизации Перед применением к рабочей среде необходимо протестировать следующие параметры.

    1. Удалите материализованное представление, связанное с прослушивателем, если материализованное представление не используется.
    2. В пользовательском интерфейсе Ambari добавьте настраиваемое свойство (в custom hive-site.xml) и удалите нежелательные фоновые потоки хранилища метаданных.
    3. Имя свойства: metastore.task.threads.remote
    4. Значение по умолчанию: N/A (it uses few class names internally)
    5. Новое значение: org.apache.hadoop.hive.metastore.txn.AcidHouseKeeperService,org.apache.hadoop.hive.metastore.txn.AcidOpenTxnsCounterService,org.apache.hadoop.hive.metastore.txn.AcidCompactionHistoryService,org.apache.hadoop.hive.metastore.txn.AcidWriteSetService,org.apache.hadoop.hive.metastore.PartitionManagementTask

  9. Отключите фоновые потоки, если реплика tion отключен.

    1. В пользовательском интерфейсе Ambari добавьте настраиваемое свойство (в custom hive-site.xml) и удалите нежелательные потоки.
    2. Имя свойства: metastore.task.threads.always
    3. Значение по умолчанию: N/A (it uses few class names internally)
    4. Новое значение: org.apache.hadoop.hive.metastore.RuntimeStatsCleanerTask

Настройка запросов

  1. Сохраните конфигурации Hive по умолчанию, чтобы выполнять запросы при настройке для рабочих нагрузок TPC-DS. Требуется настройка уровня запроса только в том случае, если он завершается сбоем или выполняется медленно.
  2. Убедитесь, что статистика обновлена, чтобы избежать плохих планов или неправильных результатов.
  3. Избегайте смешивания внешних и управляемых таблиц ACID в типах запросов. В таком случае попробуйте преобразовать внешнюю в управляемую таблицу без КИСЛОТЫ через отдых.
  4. В Hive-3 большая часть работы произошла при векторизации, CBO, метке времени с зонами и т. д., которые могут иметь ошибки продукта. Таким образом, если любой запрос дает неправильные результаты, попробуйте отключить векторизацию, CBO, map-join и т. д., чтобы узнать, помогает ли это.

Другие шаги, которые необходимо выполнить, чтобы исправить неправильные результаты и низкую производительность после миграции

  1. Запрос Hive выдает неправильный результат. Даже запрос select count(*) дает неверный результат.

    Причина того, что для свойства hive.compute.query.using.stats задано значение true, по умолчанию. Если задано значение true, он использует статистику, которая хранится в хранилище метаданных для выполнения запроса. Если статистика не обновлена, это приведет к неправильным результатам.

    Разрешение собирает статистику для управляемых таблиц с помощью alter table <table_name> compute statics; команды на уровне таблицы и на уровне столбцов. Ссылка на ссылку — https://cwiki.apache.org/confluence/display/hive/statsdev#StatsDev-TableandPartitionStatistics

  2. Выполнение запросов Hive занимает много времени.

    Причина , если запрос имеет условие соединения, hive создает план, следует ли использовать соединение карты или слияние на основе размера таблицы и условия соединения. Если одна из таблиц содержит небольшой размер, она загружает таблицу в памяти и выполняет операцию соединения. Таким образом выполнение запроса ускоряется по сравнению с соединением слиянием.

    Разрешение обязательно задайте свойство hive.auto.convert.join=true, которое является значением по умолчанию. Если оно задано значение false, использует соединение слияния и может привести к снижению производительности. Hive решает, следует ли использовать соединение карты или нет на основе следующих свойств, заданных в кластере.

    set hive.auto.convert.join=true;
set hive.auto.convert.join.noconditionaltask=true;
set hive.auto.convert.join.noconditionaltask.size=<value>;
set hive.mapjoin.smalltable.filesize = <value>;

    Обычное соединение может автоматически преобразовывать в соединение карты, если hive.auto.convert.join.noconditionaltask=trueпредполагаемый размер небольших таблиц меньше, чем hive.auto.convert.join.noconditionaltask.size(значение по умолчанию равно 10000000 МБ).

    Если возникла любая проблема, связанная с OOM, присвойте свойству hive.auto.convert.join значение true, рекомендуется задать его значение false только для конкретного запроса на уровне сеанса, а не на уровне кластера. Эта проблема может возникнуть, если статистика неправильная, и Hive решает использовать соединение карты на основе статистики.

  • Ошибка запроса Hive дает неправильный результат, если запрос имеет условие соединения, а таблицы, участвующие в ней, имеют значение NULL или пустые значения.

    Иногда может возникнуть проблема, связанная с значениями NULL, если таблицы, участвующие в запросе, имеют много значений NULL. Hive выполняет оптимизацию запроса неправильно со значениями NULL, которые приводят к неправильным результатам.

    Решение Рекомендуется задать свойство set hive.cbo.returnpath.hiveop=true на уровне сеанса, если вы получите неверные результаты. Эта конфигурация содержит не null-фильтрацию по ключам соединения. Если в таблицах имеется много значений NULL, для оптимизации операции соединения между несколькими таблицами мы можем включить эту конфигурацию, чтобы она считала только не значения NULL.

  • Запрос Hive выдает неправильный результат, если запрос имеет несколько условий соединения.

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

    Разрешение может получить неправильные результаты, если задано hive.merge.nway.joins значение false. Попробуйте задать значение true только для запроса, который пострадал. Это помогает выполнять запросы с несколькими соединениями в одном условии, объединение объединяется в один оператор соединения. Этот метод полезен, если крупные соединения перетасовки позволяют избежать перетасовки этапа.

  • Проблема' Существует увеличение времени выполнения запроса на день по сравнению с предыдущими запусками.

    Причина этой проблемы может возникнуть, если количество небольших файлов увеличивается. Поэтому hive занимает время при чтении всех файлов для обработки данных, что приводит к увеличению времени выполнения.

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

    Справочная ссылка: Hive Transactions — Apache Hive — Apache Software Foundation.

  • Запрос Hive выдает неверный результат, если клиент использует условие соединения для управляемой таблицы orc или кислоты и управляемой таблицы, отличной от ACID илиc.

    Причина из HIVE 3 в сторону, она строго запрашивается, чтобы сохранить все управляемые таблицы как кислотную таблицу. И если мы хотим сохранить его как кислотную таблицу, то формат таблицы должен быть orc, и это основной критерий. Но если отключить строгое свойство управляемой таблицы hive.strict.managed.tables, то мы можем создать управляемую таблицу, не относясь к ACID. В некоторых случаях клиент создает внешнюю таблицу ORC или после миграции таблицы, преобразованной во внешнюю таблицу, и отключает строгое свойство управляемой таблицы и преобразует ее в управляемую таблицу. На этом этапе таблица преобразуется в формат управляемых orc, отличных от ACID.

    Оптимизация Решения Hive ошибается, если вы присоединяете таблицу с таблицей ORC, отличной от ACID, с таблицей управляемых кислоты илиc.

    Если вы преобразуете внешнюю таблицу в управляемую таблицу,

    1. Не устанавливайте для свойства hive.strict.managed.tables значение false. Если задано, можно создать неуправляемую таблицу, но она не запрашивается в HIVE-3.
    2. Преобразование внешней таблицы в управляемую таблицу с помощью следующей команды alter вместо alter table <table_name> set TBLPROPERTIES ('EXTERNAL'='false');
    alter table rt set TBLPROPERTIES ('EXTERNAL'='false', 'transactional'='true');

Руководство по устранению неполадок

Руководство по устранению неполадок с HDInsight версий 3.6–4.0 для рабочих нагрузок Hive содержит решения распространенных проблем, с которыми можно столкнуться при переносе рабочих нагрузок Hive из HDInsight 3.6 в HDInsight 4.0.

Дополнительные материалы