Controladores JDBC sin empaquetar

Las instrucciones de esta página se aplican solo a las implementaciones de Looker alojadas por el cliente. En el caso de las implementaciones alojadas en Looker, tu instancia de Looker debería estar preconfigurada. Si ves algún problema, comunícate con tu analista de Looker.

Estas instrucciones están diseñadas para usarse solo con los dialectos que se especifican en la siguiente tabla. No están diseñados para instalarse en Looker para instalar otros controladores de JDBC no compatibles y conectarse a otras bases de datos. Es posible que los intentos de instalar controladores de JDBC distintos de los que se enumeran no funcionen y no sean aptos para recibir asistencia técnica de Looker.

Configura Looker para usar controladores JDBC sin empaquetar

Para algunos de los dialectos compatibles de Looker, el controlador de JDBC no se puede empaquetar en el archivo JAR de Looker por motivos relacionados con las licencias. En estos casos, debes instalar el controlador de JDBC en tu servidor de Looker y, luego, configurar Looker para que registre el controlador sin empaquetar como se describe en esta página.

Todos los dialectos con un valor de "No" en "¿Se admite?" requieren instalaciones de controladores de JDBC sin empaquetar:

Dialecto	¿Es compatible?
Avalancha de Actian	No
Amazon Athena	Sí
Amazon Aurora MySQL	Sí
Amazon Redshift	Sí
Apache Druid	Sí
Apache Druid 0.13 y versiones posteriores	Sí
Apache Druid 0.18 y versiones posteriores	Sí
Apache Hive 2.3 y versiones posteriores	Sí
Apache Hive 3.1.2 y versiones posteriores	Sí
Apache Spark 3 y versiones posteriores	Sí
ClickHouse	Sí
Cloudera Impala 3.1 y versiones posteriores	Sí
Cloudera Impala 3.1 y versiones posteriores con controlador nativo	No
Cloudera Impala con controlador nativo	No
DataVirtuality	No
Databricks	Sí
Denodo 7	Sí
Denodo 8	Sí
Dremio	Sí
Dremio 11 y versiones posteriores	Sí
Exasol	Sí
Bola de fuego	Sí
SQL heredado de Google BigQuery	Sí
SQL estándar de Google BigQuery	Sí
PostgreSQL en Google Cloud	Sí
Google Cloud SQL	Sí
Google Spanner	Sí
Greenplum	Sí
HyperSQL	Sí
IBM Netezza	Sí
MariaDB	Sí
PostgreSQL de Microsoft Azure	Sí
Base de datos de Microsoft Azure SQL	Sí
Microsoft Azure Synapse Analytics	Sí
Microsoft SQL Server 2008 y versiones posteriores	Sí
Microsoft SQL Server 2012 y versiones posteriores	Sí
Microsoft SQL Server 2016	Sí
Microsoft SQL Server 2017 y versiones posteriores	Sí
MongoBI	No
MySQL	Sí
MySQL 8.0.12 y versiones posteriores	Sí
Oracle	Sí
Oracle ADWC	Sí
PostgreSQL 9.5 y versiones posteriores	Sí
PostgreSQL anterior a la versión 9.5	Sí
PrestoDB	Sí
PrestoSQL	Sí
SAP HANA 2 y versiones posteriores	Sí
SingleStore	Sí
SingleStore 7 y versiones posteriores	Sí
Snowflake	Sí
Teradata	No
Trino	Sí
Vector	No
Vertica	Sí

Requisitos previos

Para conectar Looker a una base de datos que requiera un controlador JDBC sin empaquetar, necesitarás lo siguiente:

• Acceso desde la línea de comandos a tu servidor de Looker.
• El controlador de JDBC como un archivo JAR La documentación específica del dialecto puede tener instrucciones sobre dónde descargar este archivo. De lo contrario, se da por sentado que tienes acceso al archivo JAR necesario.
• El símbolo del controlador para tu dialecto. Un símbolo del controlador es un valor de cadena que Looker usa internamente para hacer coincidir el dialecto con el controlador. En los ejemplos de esta página, se usa el valor genérico driver_symbol. Consulta la documentación de Looker sobre cada dialecto para conocer los símbolos que usa Looker para registrar controladores de JDBC en los dialectos.
• La entrada de controlador YAML para tu dialecto que se agregará al archivo de configuración custom_jdbc_config.yml Consulta la sección Entradas del controlador en el archivo de configuración YAML de esta página para obtener más información.

Entradas de controladores en el archivo de configuración YAML

A continuación, se muestra un ejemplo de entrada de controlador en el archivo custom_jdbc_config.yml:

  - name: driver_symbol
    dir_name: driver_symbol
    module_path: com.dialect.jdbc.DialectDriver
    override_jdbc_url_subprotocol: driver_subprotocol  # optional

Cuando escribas la entrada del controlador para tu dialecto, haz lo siguiente:

• El archivo custom_jdbc_config.yml se basa en YAML, lo que significa que las sangrías y los espacios son importantes.
• Los atributos name y dir_name deben ser el símbolo del controlador que Looker usa para tu dialecto cuando registra controladores de JDBC.
• Es posible usar el atributo file_name en lugar de dir_name que contiene la ruta de acceso relativa de custom_jdbc_drivers al archivo JAR del controlador JDBC. Se recomienda dir_name porque promueve mantener varios controladores aislados en sus propios directorios y reduce la posibilidad de que entre en conflicto las clases de Java.
• La propiedad module_path dependerá del controlador JDBC específico. Debe ser la ruta de acceso completamente calificada a la clase de controlador de Java. En este ejemplo, se usa un valor genérico, pero para encontrar el module_path específico que usa el controlador, consulta su documentación sobre cómo registrar la clase del controlador.
• override_jdbc_url_subprotocol es un argumento opcional que se usa para anular el subprotocolo que se usa en la cadena de JDBC que Looker envía a la base de datos. Una cadena de JDBC típica se verá de la siguiente manera:

jdbc:mysql://localhost:3306/database_name[?propertyName1][=propertyValue1]

Donde mysql es el subprotocolo de JDBC que se usa.

Si especificas override_jdbc_url_subprotocol: driver_subprotocol, esta cadena de JDBC se convertirá en la siguiente:

jdbc:driver_subprotocol://localhost:3306/database_name[?propertyName1][=propertyValue1]

Esta opción es obligatoria si necesitas usar un controlador JDBC sin empaquetar que requiera un subprotocolo de URL distinto del subprotocolo de URL predeterminado de Looker. En general, esto no es necesario, a menos que la documentación del dialecto lo indique de forma explícita. MongoBI es un ejemplo de un dialecto que requiere esta opción.

Cómo instalar controladores de JDBC sin empaquetar

1. Cambia al directorio base de la aplicación de Looker. En este ejemplo, se usa looker como directorio base.

   cd looker
   

2. Crea un directorio llamado custom_jdbc_drivers. Este es el directorio de nivel superior para todas las instalaciones de controladores de JDBC sin empaquetar. La ruta de acceso a este directorio debe ser looker/custom_jdbc_drivers.

   mkdir custom_jdbc_drivers
   

3. En el directorio custom_jdbc_drivers, crea un subdirectorio con el nombre del símbolo del controlador de tu dialecto. En este ejemplo, se usa el valor genérico driver_symbol. La ruta de acceso resultante al directorio se verá como looker/custom_jdbc_drivers/driver_symbol.

   cd custom_jdbc_drivers
   mkdir driver_symbol
   

4. Coloca los archivos del controlador de JDBC para tu dialecto en este directorio. El método para esto depende de dónde se pueda encontrar el controlador de tu dialecto y subirlo al servidor, pero asegúrate de que los archivos JAR relevantes estén dentro del directorio driver_symbol: looker/custom_jdbc_drivers/driver_symbol/

   Por ejemplo: looker/custom_jdbc_drivers/driver_symbol/DialectDriver.jar

   La forma en que muevas los archivos necesarios al servidor de Looker variará según de dónde obtengas los archivos del controlador y tu preferencia para transferir archivos. Entre los ejemplos de comandos para transferir archivos a este directorio, se incluyen wget, scp y curl.

5. Cambia el directorio al directorio de la aplicación de Looker y crea un archivo de configuración llamado custom_jdbc_config.yml. La ruta de acceso a este archivo debe ser looker/custom_jdbc_config.yml. Este archivo contendrá la información que Looker necesita para ubicar y registrar el controlador de JDBC personalizado.

   cd looker
   vim custom_jdbc_config.yml
   

6. Agrega una entrada nueva para tu dialecto en el archivo de configuración custom_jdbc_config.yml. Consulta la sección Entradas de controladores en el archivo de configuración YAML en esta página para obtener información sobre las entradas de controladores.

   - name: driver_symbol
     dir_name: driver_symbol
     module_path: com.dialect.jdbc.DialectDriver
   

7. Crea o actualiza el archivo lookerstart.cfg para que la aplicación de Looker se inicie con la configuración del controlador JDBC sin empaquetar. La ruta de acceso a este archivo debe ser looker/lookerstart.cfg. Agrega la opción --use-custom-jdbc-config. Si hay otras opciones, agrégalas al final de las opciones de inicio de Looker:

   LOOKERARGS="--use-custom-jdbc-config"
   

   Si tienes LOOKERARGS configurado en otro lugar que no sea lookerstart.cfg, como en una variable de entorno, puedes agregar esta marca de inicio allí. También puedes configurar LOOKERARGS="${LOOKERARGS} --use-custom-jdbc-config" para que los valores existentes se expandan a este archivo.

8. Reinicia la aplicación de Looker. En este comando, usa el nombre de tu secuencia de comandos de inicio de Looker, como ./looker o ./looker.sh

   ./looker restart
   

   o none ./looker stop ./looker start

Varios controladores de JDBC sin empaquetar

Si necesitas configurar más de un dialecto para usar controladores de JDBC sin empaquetar, el proceso descrito en la sección Instala controladores de JDBC sin empaquetar aún se aplica. El directorio custom_jdbc_drivers tendrá varios subdirectorios dialect con sus propios archivos JAR del controlador, y el archivo custom_jdbc_config.yml tendrá varias entradas:

ls looker/custom_jdbc_drivers

driver_symbol_1 driver_symbol_2

ls looker/custom_jdbc_drivers/driver_symbol_1

Dialect1Driver.jar

- name: driver_symbol_1
  dir_name: driver_symbol_1
  module_path: com.dialect.jdbc.Dialect1Driver

- name: driver_symbol_2
  dir_name: driver_symbol_2
  module_path: com.dialect.jdbc.Dialect2Driver