1. Знакомство с Тезом

Tez — это вычислительная среда с открытым исходным кодом, поддерживающая задания DAG. Она может конвертировать несколько зависимых заданий в одно задание, что значительно повышает производительность заданий DAG.

По своей сути Tez очень прост и состоит всего из двух компонентов:

• Механизм конвейера обработки данных, где механизм может вводить, обрабатывать и выводить реализации для выполнения произвольной обработки данных.
• Хост для приложений обработки данных, который позволяет объединять любые из вышеперечисленных «задач» обработки данных в группу DAG задач для обработки данных по мере необходимости.
• Вообще говоря, задачи MR будут генерировать размещение дисков ввода-вывода на карте и сокращать этапы, но Tez не требует этого шага.
• Tez использует DAG (ориентированный ациклический граф) для организации задач MR. Основная идея: дальнейшее разделение задачи «Карта» и задачи «Сокращение». Задача «Карта» делится на «Ввод-Обработчик-Сортировка-Слияние-Вывод», задача «Сокращение» делится на «Ввод-Перестановка-Сортировка-Слияние-Обработка-вывод», а Tez разделяет. несколько небольших задач в Гибкую реорганизацию для формирования большого задания DAG.

Позволяя таким проектам, как Apache Hive и Apache Pig (без обновлений), выполнять сложные задачи DAG, Tez можно использовать для обработки данных, для которых ранее требовалось, чтобы несколько заданий MR теперь были в одном задании Tez (рисунок ниже). Зеленый кружок представляет собой задание), как показано ниже:

Тестовая среда:

1. Cloudera Runtime 7.1.7 поддерживает Kerberos.

2、Cloudera Manager 7.4.4 

2. Анализ Hive On Tez

2.1. Структурный состав.

Структура вычислительного механизма Tez больше похожа на Spark, но есть и различия.

Компоненты, входящие в состав Tez:

• Направленный ациклический граф (DAG) – определяет общую задачу. Объект DAG соответствует задаче.
• Узел (Vertex) — определяет пользовательскую логику, а также ресурсы и среду, необходимые для выполнения пользовательской логики. Узел соответствует шагу задачи.
• Edge — определяет связь между узлами-производителями и потребителями. Ребрам необходимо назначить атрибуты, необходимые Tez для расширения логического графа во время выполнения в набор физических задач, которые могут выполняться параллельно в кластере.

Tez предоставляет 6 типов программируемых компонентов, введение следующее:

• Входные данные: абстракция источника входных данных. Он анализирует формат входных данных и выдает ключ/значение одно за другим.
• Вывод: абстракция источника выходных данных, который записывает ключ/значение, сгенерированный пользовательской программой, в файловую систему.
• Paritioner: данные раздела, аналогично Partitioner в MR.
• Процессор: абстракция вычислений. Он получает данные от входа, обрабатывает их и выводит через выход.
• Задача: абстракция задач. Каждая задача состоит из входа, выхода и процессора.
• Мастер: управляет зависимостями каждой задачи и выполняет их в соответствии с зависимостями.
• Помимо вышеупомянутых шести компонентов, Tez также предоставляет два оператора, а именно Sort (сортировка) и Shuffle (перемешивание). Для удобства пользователя он также предоставляет различные реализации ввода, вывода, задач и сортировки.

В этой статье не рассматривается представление этих компонентов. Далее при выполнении Hive On Tez их можно разделить следующим образом:

Когда мы используем beeline или JDBC для подключения, сначала будет создан сеанс Hive.

• Hive on Tez Session может включать одно или несколько приложений. Подобно сеансам базы данных, несколько Tez Dags могут выполняться последовательно в одном сеансе Tez. Tez Session позволяет избежать множественных запусков и разрушений AM, а также значительно сокращает время выполнения задач в заданиях Tez (задачи HQL) с несколькими графами DAG.
• В приложении будет одна или несколько групп обеспечения доступности баз данных. Одна группа обеспечения доступности баз данных соответствует идентификатору запроса и SQL.
• В одном SQL может быть сгенерировано несколько исполнений контейнера, а процесс 1Map Vertex или уменьшает вершину может быть выполнен в нескольких контейнерах одновременно, что отличается от задачи в Executor в Spark (Task. Примененный Контейнер можно использовать повторно, поэтому вы можете видеть, что в Контейнере в разные моменты времени будут разные Задачи. Это важный момент для повышения производительности механизма MR по сравнению с механизмом MR.)

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

Map (Ввод-Процессор-Сортировка-Объединение-Вывод) и Редукция (Ввод-Перестановка-Сортировка-Слияние-Процесс-вывод) — это всего лишь процесс задачи, выполняемый на одной или нескольких Задачах, и не имеют прямого отношения к Контейнеру. Он отличается от CDH5 Hive, использующего Map Download в движке MR.

Сеанс При создании ссылки на куст создается идентификатор сеанса. Тайм-аут простоя по умолчанию составляет 5 минут. Чтобы просмотреть этот параметр, найдите tez.session.am.dag.submit.timeout.secs.

По умолчанию соответствующие идентификаторы приложений в одном сеансе одинаковы. Как показано ниже, если вы повторно выполните его более чем через 5 минут, в журнале будет выведена информация о том, что сеанс Tez был закрыт. Повторное открытие.

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

Чтобы всем было проще просматривать информацию о выполнении задачи, запустите немного сложный SQL и извлеките ключевую информацию о выполнении задачи. Например:

Вы можете использовать команду cat /tmp/application_1640571570835_309624.log | grep 'taskAttemptId', чтобы отфильтровать другую информацию, чтобы вы могли более интуитивно понять статус выполнения задачи в контейнере.

Как показано ниже:

В контейнереContainer_e14_1640571570835_309624_01_000002 есть две задачи, а именно попытка_1640571570835_309624_1_00_000000_0 и попытка_1640571570835_309624_1_02_000000_0, вы можете видеть, что 02 инициализируется и запускается после завершения 00. Это один и тот же повторно используемый контейнер (Примечание: 01 находится в другом контейнере_e14_1640571570835_309624_01_000006).

2.2 Вычислительные ресурсы и конфигурация

В этом документе основное внимание уделяется распределению и расчету следующих параметров YARN. Для более подробной настройки вы можете просмотреть справочный документ в конце статьи [5].

Ресурсы, используемые задачей Hive on Tez при запуске, рассчитываются следующим образом:

Используемый объем памяти:

Количество контейнеров*hive.tez.container.size + 1*tez.am.resource.memory.mb 

Количество используемых процессоров:

Контейнер количество* hive.tez.cpu.vcores +1*tez.am.resource.cpu.vcores

Параметры кластера следующие: работает Как показано ниже:

tez.am.resource.memory.mb=4096tez.am.resource.cpu.vcores=3hive.tez.Container.size=1024hive.tez.cpu.vcores=2

Когда генерируется только AM:

Контейнер АМ+:

2.2.1 Конфигурация памяти Tez AM и размера ЦП

Размер памяти и количество процессоров Tez AM настраиваются, как показано ниже.

CM > Tez > Конфигурация внутри:

По умолчанию для tez.am.resource.memory.mb этот параметр обычно необходимо корректировать в соответствии с реальной ситуацией, в противном случае может легко произойти переполнение памяти. Вы также можете установить уровень сеанса, установив tez.am.resource.memory. mb=4096; Параметр, размер этого параметра не может превышать размер Yarn.nodemanager.resource.memory-mb, иначе будет невозможно выделить контейнеры, поскольку запрошенный ресурс превышает максимально допустимое выделение при выполнении задачи. Подсказка об исключении.

Значение по умолчанию tez.am.resource.cpu.vcores равно 1. В большинстве случаев его настраивать нет необходимости. Как и выше, значение этого параметра не может превышать размер Yarn.nodemanager.resource.cpu. -vcore, иначе при выполнении задачи возникнет та же проблема, что и выше.

<property><name>tez.am.resource.cpu.vcores</name><value>3</value></property>

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

2.2.2 Tez Container память и процессорразмер Конфигурация

Размер памяти и количество процессоров Tez Container следующие:

CM > Hive on Tez > Конфигурация внутри:

Размер hive.tez.Container.size по умолчанию равен 4G. Этот параметр имеет тот же тип, что и tez.am.resource.memory.mb. Обычно его необходимо настроить в соответствии с реальной ситуацией. В противном случае возможно переполнение памяти. Вы можете использовать set hive.tez.container.size=8096; для установки параметров уровня сеанса. Размер параметра не может превышать размер Yarn.nodemanager.resource.memory-mb, иначе при выполнении Vertex появится TaskResource. задача. За пределами возможности кластерного контейнера. Ошибка.

hive.tez.cpu.vcores отображается в CM как -1. Если для hive.tez.cpu.vcores установлено значение меньше 1, оно будет перезаписано значением mapreduce.map.cpu.vcores. Этот параметр обычно не имеет значения. необходимо отрегулировать. Значение этого параметра не может превышать размер Yarn.nodemanager.resource.cpu-vcore, иначе задача Hive on Tez зависнет при запуске задачи, и в журнале ResouceManager будет видно, что неверный запрос ресурса не может быть выделен! Контейнеры в качестве запрошенного ресурса превышают максимально допустимое выделение. Соответствующая информация об исключении.

Файл hive.tez.cpu.vcores После того, как значение Конфигурация превысит значение Yarn.nodemanager.resource.cpu-vcore, задача зависает, как показано на рисунке ниже, только с AM. Генерация, невозможно подать заявку на ресурсы контейнера и ResourceManager. бревно Существует исключение, как показано ниже.

2.2.3 Tez Task память и процессор размер Конфигурация（Нет Конфигурация）

Эти два параметра вынесены отдельно, потому что их легко неправильно понять. Они находятся в Hive CDP. on Tez Домашняя работа неэффективна. Хотя в Тезе Среди параметров — tez.task.resource.memory.mb и tez. task.resource.cpu.vcores Два параметра Конфигурация Задача память и процессора, но эти два параметра будут

hive.tez.container.size hive.tez.cpu.vcores Ресурсы hive.tez.cpu.vcores будут основаны на конфигурации Контейнера, поэтому эти два параметра изменять не нужно.

Как показано ниже, hive.tez.container.size=1024.  hive.tez.cpu.vcores=1 ,

tez.task.resource.memory.mb=5120, tez.task.resource.cpu.vcores=2, ресурсы, запрашиваемые во время фактического выполнения, основаны на конфигурации контейнера.

Вы также можете отфильтровать TaskAttemptId, чтобы определить, в каких контейнерах выполняется задача.

2.3 кратко Просмотр и анализ 

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

Пользователи могут вызвать команду «пряжа logs -applicationId {your_app_id}", чтобы перенести приложение Yarn в локальный каталог. Эта команда доступна только в том случае, если включена бревная агрегация YARN. В кластере CDP бревная агрегация включена по умолчанию.,Можно найти вCM>YARN>Конфигурациясерединапоиск yarn.log-aggregation-enable Проверьте, включен ли этот параметр. Если агрегация бревно не включена, бревно необходимо найти на каждом компьютере с менеджером узла. 

После получения заявки на пряжу бревно. Вы можете проверить это сначала Tez AM бревно,Tez AM был в первом yarn app запущен в контейнере, поэтому он находится в Container_{yarn_app_id}_000001 в такой папке. В этой папке вы можете найти следующие файлы.

• syslog Это AM бревно до нормального запуска. 
• syslog_dag_{yarn_app_id}_{dag_id} Этокаждый dag избревно
• syslog_dag_{yarn_app_id}_{dag_id}_post бревно за каждый день после завершения Этодага

Поэтому обычно нужно проверять только последний dag бревночтобы найти ошибку。

Расширения командной строки:

Приложение бревно можно использовать в сочетании со следующими параметрами.

-show_application_log_info 

Отображение идентификаторов ContainerId, принадлежащих конкретному приложению. Это можно комбинировать с --nodeAddress, чтобы получить все ContainerIds контейнера в определенном менеджере узлов.

-show_Container_log_info 

отображать метаданные контейнера, включая имя файла и размер файла. Этот параметр можно использовать вместе с --ContainerId чтобы получить метаданные записи для определенного контейнера или --nodeAddress Получить бревно все контейнеры метаданных на конкретной точке менеджера.

Как показано на рисунке Приложение Tags Это hive_20220104113302_618d4581-9df4-47a5-b1b0-ada072c6d701 Соответствующий — application_1640872724002_0002. Первый генерирует dag Вычисляемый SQL, обратите внимание: некоторые простые SQL не генерируют dag, вкратце. Как показано ниже syslog_dag_1640872724002_0002_1. То есть SQL Все выполнения, такие как сообщение об ошибке выполненного SQL, обычно находятся под контролем выполнения.

3. Краткое описание документа

Tez Производительность исполнения относительно Map Reduce Производительность Hive была значительно улучшена, а управление ресурсами Hive также стало более разумным за счет повторного использования ресурсов и DAG. on Tez Возникает проблема во время выполнения. Проверка сложнее. Я считаю, что анализ, приведенный в этой статье, может помочь каждому устранить неполадки Hive. on Тез помогает, когда задает вопросы.

Ссылки:

[1] https://tez.apache.org/[2] https://cwiki.apache.org/confluence/display/TEZ/How+to+Diagnose+Tez+App[3] https://cwiki.apache.org/confluence/display/Hive/Configuration+Properties[4] https://github.com/apache/tez[5] https://community.cloudera.com/t5/Community-Articles/Demystify-Apache-Tez-Memory-Tuning-Step-by-Step/ta-p/245279