#jdbc #hive #azure-databricks
#jdbc #улей #azure-databricks
Вопрос:
Я использую Azure Databricks с Databricks Runtime 5.2 и Spark 2.4.0. Я настроил внешние таблицы Hive двумя различными способами: — дельта-таблица Databricks, где данные хранятся в Azure Data Lake Storage (ADLS) Gen 2, таблица была создана с использованием параметра местоположения, который указывает на подключенный каталог в ADLS Gen 2. — обычный фрейм данных, сохраненный в виде таблицы в ADLS Gen 2, на этот раз не используется монтирование, а вместо этого используется Учетные данные OAuth2 я установил на уровне кластера, используя spark.SparkContext.hadoopConfiguration
Как точка подключения, так и прямой доступ (hadoopConfiguration) были настроены с использованием учетных данных OAuth2 и участника службы Azure AD, который имеет необходимые права доступа к озеру данных.
Обе таблицы корректно отображаются в пользовательском интерфейсе Databricks и могут быть запрошены.
Обе таблицы также видны в инструменте BI (Looker), где я успешно настроил соединение JDBC с моим экземпляром Databricks. После этого начинаются различия:
1) таблица, настроенная с использованием точки монтирования, не позволяет мне выполнить операцию ОПИСАНИЯ в инструменте BI, не говоря уже о запросе. Все завершается ошибкой «com.databricks.backend.daemon.data.common.Исключение InvalidMountException: ошибка при использовании path /mnt/xxx/yyy /zzz для разрешения пути ‘/yyy / zzz’ при монтировании в ‘/mnt/xxx’.»
2) таблица, настроенная с использованием без точки монтирования, позволяет мне выполнить операцию ОПИСАНИЯ, но запрос завершается ошибкой «java.util.concurrent.Исключение ExecutionException: java.io.IOException: Нет основной группы для UGI (базовый токен) (аутентификация: ПРОСТАЯ) «.
Подключение к JDBC и выполнение запросов из инструмента BI к управляемой таблице в Databricks работает нормально.
Насколько я знаю, нет ничего, что я мог бы настроить по-другому при создании внешних таблиц, настройке точки подключения или учетных данных OAuth2. Мне кажется, что при использовании JDBC монтирование вообще не видно, поэтому запрос к базовому источнику данных (ADLS Gen 2) не может быть выполнен успешно. С другой стороны, второй сценарий (номер 2 выше) немного более загадочный и, на мой взгляд, кажется чем-то скрытым, глубоким, и я понятия не имею, что с этим делать.
Одна особенность — это также мое имя пользователя, которое отображается в сценарии 2. Я не знаю, откуда это взялось, поскольку это не задействовано при настройке доступа к ADLS Gen 2 с использованием участника-службы.
Комментарии:
1. вы нашли решение для этого? у меня такая же проблема
2. У меня пока нет решения. Я пытаюсь заставить кого-нибудь из группы продуктов Microsoft поделиться некоторыми соображениями, и я сообщу о любых результатах здесь. Это также очень важно для нашего клиентского проекта. Что я собирался сделать тем временем, так это опробовать последний кластер Databricks (бета-версия 5.3), чтобы увидеть, имеет ли это значение.
3. Я пробовал с новым бета-кластером 5.3, никакой разницы, не работает.
4. Кстати, это работает из HDInsight. При настройке кластера HDInsight можно указать, что его основным хранилищем является ADLS Gen 2. Вы также предоставляете SP (= идентификатор) для подключения к хранилищу. Как только вы это сделаете, любая внешняя таблица с данными в ADLS Gen 2 будет доступна через JDBC. Однако, поскольку HDInsight довольно дорогой, я бы оставил его только в качестве второго варианта.
Ответ №1:
У меня была похожая проблема, и я решил ее, добавив этот параметр в свой кластер Databricks :
запустите.hadoop.hive.server2.включите.Значение doAs false
Смотрите : https://docs.databricks.com/user-guide/faq/access-blobstore-odbc.html
RB
Комментарии:
1. Да, это ответ, который я также получил от нашего сотрудника службы поддержки Microsoft, он сработал и для меня 🙂
2. Интересно, однако, что мне сказали, что ошибка «Нет основной группы …» была бы вызвана какой-либо ошибкой (я бы предположил, что во время выполнения Databricks?), и эта ошибка была бы исправлена в конце прошлого года. Кроме того, параметр сервера Hive «doAs» должен содержать только обходной путь, позволяющий обойти эту ошибку до ее исправления. Однако это был не мой опыт, поскольку мне также пришлось установить для этого параметра значение false, чтобы заставить это работать.