Непоследовательный результат уловки фильтра MetaStore - PullRequest
0 голосов
/ 09 мая 2019

Я создал наш пользовательский крючок фильтра метастазов кустов и настроил в hive-site.xml подключаемые модули хранения метастазов Hiveserver2 и Drill Hive.

Плагин хранилища Drill Hive

{
  "type": "hive",
  "enabled": true,
  "configProps": {
    "hive.metastore.uris": "thrift://x.x.x.x:9083",
    "hive.metastore.warehouse.dir": "/user/hive/warehouse",
    "hive.metastore.filter.hook": "com.hive.MyHiveMetaStoreFilterHook",
    "hive.security.authorization.enabled": "true",
    "datanucleus.schema.autoCreateAll": "true"
  }
}

hook работает при выполнении show databases или show schemas из Drill Web UI, hive, beeline и SQLLine.Это фильтры на основе нашей логики, как и ожидалось.Единственное выполнение, которое не работает должным образом, происходит через JDBC/ODBC Клиент, такой как Drill Explorer, SQuirrel или DBeaver

Проблема в том, что когда мы пытаемся подключиться через JDBC/ODBC Client, кажется, что перехват не запущен ион отображал все базы данных.JDBC/ODBC Client работает только после того, как мы выполним команду из Drill Web UI, hive, beeline или SQLLine.Я думаю, это зависит от того, какое выполнение заполнило кеш при первом запуске.Если я запустил Drill WebUI или SQLLine, кэш Drill Metastore заполнится с правильным результатом, поэтому последующий запрос от JDBC/ODBC Client вернет ожидаемый результат.Но если мы сначала запустим JDBC/ODBC Client, он заполнится с неверным результатом в кеше, поэтому, независимо от того, где мы выполняем, он всегда вернет неправильный результат.

Это ошибка в Drill или JDBC / ODBC Client или ожидаемое поведение?
Существует ли простой способ переопределить код DrillHiveMetaStoreClient без необходимости перекомпиляции всего исходного кода Drill?Что-то вроде hive.metastore.client.impl в Улей?

Очень странно, что поведение или результат не согласованы при выполнении через JDBC / ODBC Client по сравнению с пользовательским интерфейсом / CLI Drill Web, таким как hive, beeline или sqlline

...