Проблемы при переносе данных из Apache Atlas в ADCP

Чаще всего пользователи обращаются с этой проблемой со следующей формулировкой: "Я добавил(а) новый датасет в Apache Atlas, но он не публикуется"

Возможные причины проблемы

1. Пользователь ввел данные в Apache Atlas и ожидает мгновенной загрузки данных в платформе
2. Пользователь некорректно, не в полной мере, ввел данные в Apache Atlas
3. Воркеры небыли запущены по расписанию
4. Некорректная работа воркеров отвечающих за синхронизацию данных
   1. Воркерам недоступен Blockchain
   2. Воркерам недоступен RabbitMQ
   3. Воркерам недоступна MongoDB

Устранение проблем и поиск причин

Перед началом поиска причин проблем необходимо уточнить:

1. С каким датасетом в Apache Atlas вел работу пользователь, публикацию какого датасета он ожидает
2. Как давно пользователь вносил изменения в Apache Atlas
3. Отображается ли этот датасет в списке неопубликованных датасетов
   1. Какое количество полей отображается у неопубликованного датасета
   2. Есть ли поля у которых нет в интерфейсе привязанных бизнес терминов
4. Использовал ли пользователь только существующие Бизнес термины, которые уже используются в других датасетах, или создавал новые.

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

Пользователь ввел данные в Apache Atlas и ожидает мгновенной загрузки данных в платформе

В этом случае необходимо ожидать до 30 мин, данные перемещаются из Apache Atlas в платформу каждые 30 мин.

note

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

Пользователь некорректно, не в полной мере, ввел данные в Apache Atlas

Пользователь внес изменения в Apache Atlas более 30 мин назад, датасет есть в интерфейсе, у датасета 0 полей.

Это может произойти по двум причинам:

1. Пользователь не привязал таблицу к датасету в Apache Atlas.
2. В ClickHouse у привязанной таблицы нет полей

В случае если у датасета в Apache Atlas нет привязанной не удаленной таблицы необходимо привязать таблицу.

В случае если у таблицы фактически нет полей в ClickHouse, датасет не будет опубликованным, поскольку в нем не может быть данных

note

Промежуток 30 мин указывается по умолчанию, период синхронизации может быть изменен в зависимости от конфигурации вашего инстанса. Проверить периодичность возможно в kubernetes-кластере в списке cron-job. Вас интересует сron-job в неймспейсе вашего инстанса формата: dataservice-*-aesync

Пользователь внес изменения в Apache Atlas более 30 мин назад, датасет есть в интерфейсе, у полей датасета нет бизнес термина.

1. Пользователь не привязал бизнес термины к полю таблицы. Пользователю необходимо привязать Бизнес термины к таблице.

note

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

Пользователь внес изменения в Apache Atlas более 30 мин назад, датасет есть в интерфейсе, у всех полей датасета есть бизнес термин.

Проблема может возникать если:

1. К полям таблицы датасета не привязаны Бизнес термины с минимум 1 атрибутом матчинга и 1 бизнес термин с атрибутом согласия
2. К полям таблицы датасета привязано 2 одинаковых атрибута матчинга или 2 бизнес термина с атрибутом согласия
3. У одного или нескольких бизнес терминов нет классификации или не заполнены все обязательные поля классификации

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

note

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

Воркеры не были запущены по расписанию

В случае если с момента внесения пользователем данных в Apache Atlas прошло более 1 часа и изменения не отображаются в интерфейсе системы В этом случае необходимо понимание того, включены ли cron-job запускающий синхронизацию. Для этого вы можете воспользоваться любым средством визуализации kubernetes (прим.: Lens) или воспользоваться консольными утилитами. Вас интересует Cron-job в неймспейсе вашего инстанса формата: dataservice-*-aesync

caution

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

Именно данная задача отвечает за синхронизацию данных между Apache Atlas и платформой. В случае если эта задача была приостановлена (suspend=true) необходимо её включить, убедившись что она является приостановленной не по ошибке и что сейчас не ведутся технические работы с платформой. В случае если по какой-то причине необходимо оперативно запустить синхронизацию, запустите выполнение этой задачи вручную.

Некорректная работа воркеров отвечающих за синхронизацию данных

В случае если вы уверены, что:

1. Пользователь ввел все данные верно, согласно инструкциям.
2. Задача отработала по расписанию

Но данные в платформе не появились, возможно проблема в исполняемом коде.

Как показано на схеме в разделе "Взаимодействие компонентов", синхронизация данных между Apache Atlas и ADCP осуществляется с помощью ряда воркеров.

Технические проблемы можно разделить на следующие типы:

1. Аварийное состояние ключевых узлов взаимодействия или их недоступность
   1. Массовая недоступность (для всех сервисов)
   2. Точечная (для одного сервиса)
2. Некорректность вводимых или передаваемых данных между узлами

Перед любой проверкой логов или остальных компонентов, необходимо изучить их состояние. Для того чтобы определить состояние воркеров, необходимо изучить дашборд мониторинга Healthcheck. В случае если хотя бы у одного из воркеров отвечающих за синхронизацию есть проблемы (красные пробы readiness и/или liveness) синхронизация данных будет работать некорректно.

Какие-либо проблемы при использовании этих воркеров могут быть при недоступности других ключевых узлов, более подробно какие узлы необходимы для работы воркеров см. в разделе Компоненты ADCP и описании метрик мониторинга Healthcheck.

Массовая недоступность ключевых узлов

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

Точечная недоступность ключевых компонентов

В случае если только 1 воркер по какой-то причине сигнализирует о том что его readiness=0 (красный) необходимо узнать, что именно не так с воркером. Изучить его лог сообщения в Kibana на предмет наличия ошибок с level=50. Сообщения с level=50 означают ошибки. Если по какой-то причине в логах будет зафиксировано сообщение о том что одна из readiness или liveness метрик недоступна. В этом случае вы можете:

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

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

В случае если все healthcheck'и воркеров в норме, необходимо изучить логи воркеров отвечающих за синхронизацию. Вероятнее всего в логе вы найдете сообщения с level=50, что свидетельствует об ошибках при обработке задач воркерами. С вашей стороны необходимо передать информацию о найденном логе разработчику приложения, поскольку такая проблема требует разбирательства в причинах появления невалидного сообщения и внесение правок в кодовую базу или пользовательские инструкции.