Я использую блоки данных Azure с Databricks Runtime 5.2 и Spark 2.4.0.Я настроил внешние таблицы Hive двумя различными способами: - Дельта-таблица Databricks, где данные хранятся в хранилище озера данных Azure (ADLS) Gen 2, таблица была создана с использованием параметра местоположения, который указывает на смонтированный каталог в ADLS Gen2. - обычный DataFrame, сохраненный в виде таблицы в ADLS Gen 2, на этот раз не использует монтирование, а вместо этого установил учетные данные OAuth2, которые я установил на уровне кластера с помощью spark.sparkContext.hadoopConfiguration
Как точка монтирования, так и прямой доступ (hadoopConfiguration) были настроены с использованием учетных данных OAuth2 и субъекта службы Azure AD, который обладает необходимыми правами доступа к озеру данных.
Обе таблицы правильно отображаются в блоках данныхПользовательский интерфейс и может быть запрошен.
Обе таблицы также видны в инструменте BI (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: SIMPLE) ".
Соединение JDBC и запросы из инструмента BI в управляемую таблицу в Databricks работают нормально.
НасколькоЯ знаю, что я ничего не могу настроить по-разному при создании внешних таблиц, настройке точки подключения или учетных данных OAuth2.Мне кажется, что при использовании JDBC монтирование вообще не видно, поэтому запрос к базовому источнику данных (ADLS Gen 2) не может быть успешным.С другой стороны, второй сценарий (номер 2 выше) немного более загадочный, и на мой взгляд кажется, что-то где-то под капотом, глубоко, и я понятия не имею, что с этим делать.
Одной из специфических вещей является также мое имя пользователя, которое отображается в сценарии 2. Я не знаю, откуда оно берется, поскольку оно не задействовано при настройке доступа ADLS Gen 2 с использованием принципала службы.