Я использую Azure Databricks с Databricks Runtime 5.2 и Spark 2.4.0. Я настроил внешние таблицы Hive двумя разными способами: - Таблица Databricks Delta, в которой данные хранятся в Azure Data Lake Storage (ADLS) Gen 2, таблица была создана с использованием параметра местоположения, который указывает на подключенный каталог в ADLS Gen 2. - обычный DataFrame, сохраненный в виде таблицы в ADLS Gen 2, на этот раз не использующий монтирование, а вместо этого учетные данные OAuth2, которые я установил на уровне кластера с помощью spark.sparkContext.hadoopConfiguration
И точка подключения, и прямой доступ (hadoopConfiguration) были настроены с использованием учетных данных OAuth2 и субъекта-службы Azure AD, который имеет необходимые права доступа к Data Lake.
Обе таблицы правильно отображаются в пользовательском интерфейсе Databricks и могут быть запрошены.
Обе таблицы также видны в инструменте бизнес-аналитики (Looker), где я успешно настроил соединение JDBC с моим экземпляром Databricks. После этого начинаются отличия:
1) таблица, настроенная с использованием точки монтирования, не позволяет мне запускать операцию DESCRIBE в инструменте BI, не говоря уже о запросе. Все терпит неудачу с ошибкой "com.databricks.backend.daemon.data.common.InvalidMountException: Ошибка при использовании пути / mnt / xxx / yyy / zzz для разрешения пути '/ yyy / zzz' внутри монтирования в '/ mnt / xxx'. "
2) таблица, настроенная с использованием без точки монтирования, позволяет мне запустить операцию DESCRIBE, но запрос завершается с ошибкой «java.util.concurrent.ExecutionException: java.io.IOException: нет основной группы для UGI (базовый токен) (auth :ПРОСТО)".
Соединение JDBC и запросы от инструмента BI к управляемой таблице в Databricks работают нормально.
Насколько мне известно, нет ничего, что я мог бы настроить иначе при создании внешних таблиц, настройке точки подключения или учетных данных OAuth2. Мне кажется, что при использовании JDBC монтирование вообще не видно, поэтому запрос к базовому источнику данных (ADLS Gen 2) не может быть успешным. С другой стороны, второй сценарий (номер 2 выше) немного более загадочен и, на мой взгляд, кажется чем-то где-то под капотом, глубоко, и я понятия не имею, что с этим делать.
Еще одна особенность - это мое имя пользователя, которое отображается в сценарии 2. Я не знаю, откуда оно взялось, поскольку оно не используется при настройке доступа ADLS Gen 2 с использованием субъекта-службы.
