Conecta Looker a tu base de datos

Después de proteger y configurar tu base de datos, estarás listo para conectar tu base de datos a Looker.

Crea una conexión de base de datos nueva

Selecciona Conexiones en la sección Base de datos del panel Administrador. En la página Conexiones, haz clic en el botón Agregar conexión. Looker muestra la página Configuración de conexión. Los campos que muestra la página Configuración de conexión dependen de tu configuración de dialecto.

Para obtener más información sobre cómo aplicar atributos de usuario a la configuración de conexión, consulte la sección Conexiones de la página de documentación de Atributos de usuario.

Si desea obtener más información sobre el uso de la columna Anulaciones de PDT a fin de configurar credenciales de acceso separadas para los procesos de PDT, consulte la sección Cómo configurar credenciales de acceso separadas para procesos de PDT.

Por ejemplo, las siguientes opciones están disponibles para la configuración cuando conecta Looker a Amazon Redshift.

Nombre

El nombre de la conexión como deseas referirla. No debes usar el nombre de ninguna carpeta. No es necesario que este valor coincida con ningún elemento de tu base de datos; es solo una etiqueta que asignas. Lo usarás en el parámetro connection de tu modelo de LookML.

Dialecto

El dialecto SQL que coincide con tu conexión. Es importante elegir el valor correcto para que se le presenten las opciones de conexión adecuadas y que Looker pueda traducir correctamente su LookML a SQL.

Servidor SSH

La opción Servidor SSH está disponible si la instancia se implementa en la infraestructura de Kubernetes y solo si se habilitó la capacidad de agregar la información de configuración del servidor SSH a su instancia de Looker. Si esta opción no está habilitada en tu instancia de Looker y deseas habilitarla, comunícate con tu administrador de cuentas de Looker o abre una solicitud de asistencia en el Centro de ayuda de Looker.

El servidor SSH elige automáticamente el puerto localhost por ti y, por el momento, no es posible especificar el puerto localhost. Si necesitas crear una conexión SSH que requiera que especifiques un puerto localhost, comunícate con el administrador de cuentas de Looker o abre una solicitud de asistencia en el Centro de ayuda de Looker.

Para conectarte a tu base de datos con un túnel SSH, activa el interruptor y selecciona una configuración de servidor SSH en la lista desplegable.

Host remoto:Puerto

El nombre de host de tu base de datos y el puerto que Looker debe usar para conectarse al host de la base de datos

Si trabajaste con un analista de Looker para configurar un túnel SSH en tu base de datos, en el campo Host ingresa "localhost" y en el campo Puerto ingresa el número de puerto que redirecciona a tu base de datos, que tu analista de Looker debería haber proporcionado.

Si aplica un atributo de usuario al campo Host, el atributo de usuario no puede tener un nivel de acceso de usuario establecido en Editable.

Si configuraste un túnel SSH para conectarte a tu base de datos, no puedes aplicar un atributo de usuario al campo Host remoto:Puerto.

Base de datos

El nombre de la base de datos en tu host. Por ejemplo, puedes tener un nombre de host de my-instance.us-east-1.redshift.amazonaws.com en el que haya una base de datos llamada sales_info. Ingresaría sales_info en este campo. Si tienes varias bases de datos en el mismo host, es posible que debas crear varias conexiones para usarlas (a excepción de MySQL, en la que la palabra database significa algo un poco diferente a la mayoría de los dialectos de SQL).

Usar OAuth

Para las conexiones Snowflake y Google BigQuery, tienes la opción de usar OAuth. Esto significa que tus usuarios deben acceder a Snowflake o Google, respectivamente, para emitir consultas desde Looker.

Cuando selecciones Usar OAuth, verás los campos ID de cliente de OAuth y Secreto de cliente de OAuth:

Estos valores se generan a partir de la base de datos Snowflake o de Google. Consulta la página de documentación en la que se describe la configuración de OAuth de Snowflake o la configuración de OAuth de Google BigQuery para ver el procedimiento completo.

Nombre de usuario

El nombre de usuario que Looker debe usar para conectarse a tu base de datos. Debes configurar el usuario con anticipación de acuerdo con nuestras instrucciones de configuración de la base de datos.

Contraseña

La contraseña que Looker debe usar para conectarse a tu base de datos. Debes configurar la contraseña con anticipación de acuerdo con nuestras instrucciones de configuración de la base de datos.

Schema

El esquema predeterminado que Looker usa cuando no se especifica un esquema. Esto se aplica cuando usas SQL Runner, durante la generación del proyecto de LookML y cuando consultas tablas.

Tablas derivadas persistentes

Marque esta casilla para habilitar las tablas derivadas persistentes. Esto revela campos PDT adicionales y la columna Anulaciones de PDT. Looker muestra esta opción solo si el dialecto de la base de datos admite el uso de PDT.

Ten en cuenta lo siguiente sobre los PDT:

• Los PDT no son compatibles con conexiones de Snowflake que usan OAuth.
• Si inhabilitas los PDT en una conexión, no se inhabilitarán los grupos de datos asociados con tus PDT. Incluso si inhabilitas los PDT, los grupos de datos existentes aún ejecutarán sus consultas sql_trigger en la base de datos. Si desea evitar que un grupo de datos ejecute la consulta sql_trigger en su base de datos, debe borrar o comentar el parámetro datagroup de su proyecto de LookML, o bien puede actualizar la configuración PDT y Programa de mantenimiento de grupos de datos de la conexión para que Looker revise los PDT y los grupos de datos con muy poca frecuencia o nunca.
• Para conexiones copo de nieve, Looker establece el valor del parámetro AUTOCOMMIT en TRUE (valor predeterminado de copo de nieve). AUTOCOMMIT es obligatorio para los comandos de SQL que ejecuta Looker a fin de mantener su sistema de registro de PDT.

Base de datos temporal

Aunque esté etiquetado como Temp Database, ingresará el nombre de la base de datos o el nombre del esquema, según corresponda para su dialecto SQL, que Looker debe usar para crear tablas persistentes derivadas. Debes configurar esta base de datos o esquema con anticipación, con los permisos de escritura adecuados. En la página de documentación Instrucciones de configuración de la base de datos, selecciona el dialecto de tu base de datos para ver sus instrucciones.

Cada conexión debe tener su propia base de datos temporal o esquema; no se puede compartir entre conexiones.

Cantidad máxima de conexiones del compilador PDT

La configuración de Máximo de conexiones del compilador PDT le permite especificar cuántas compilaciones de tablas simultáneas puede iniciar el regenerador de Looker en su conexión de base de datos. La configuración Max PDT Builder Connections se aplica solo a los tipos de tablas para las que el regenerador de Looker inicia recompilaciones:

• Tablas persistentes (tablas derivadas persistentes y tablas agregadas que usan la estrategia de persistencia datagroup_trigger o sql_trigger_value)
• Tablas persistentes que usan la estrategia persist_for, pero solo cuando la tabla persist_for forma parte de una cascada de tablas derivadas en las que depende una tabla que usa la estrategia de persistencia datagroup_trigger o sql_trigger_value En este caso, el regenerador de Looker volverá a compilar una tabla persist_for, ya que la tabla es necesaria para volver a compilar otra en la cascada. De lo contrario, el regenerador no iniciará compilaciones para tablas persist_for.

La configuración predeterminada de Max PDT Builder Connections es 1, pero se puede establecer hasta 10. Sin embargo, el valor no puede ser mayor que el valor establecido en el campo Conexiones máximas o en el per-user-query-limit establecido en las opciones de inicio de Looker.

Establece este valor con cuidado. Si el valor es demasiado alto, puedes sobrecargar tu base de datos. Si el valor es bajo, los PDT de larga duración o las tablas agregadas pueden retrasar la creación de otras tablas persistentes o ralentizar otras consultas en la conexión. Las bases de datos que admiten multiusuarios, como BigQuery, Snowflake y Redshift, pueden tener un mejor rendimiento en el manejo de compilaciones de consultas paralelas.

Si desea aumentar la configuración Máximo de conexiones del compilador PDT, una buena regla general es aumentarla en un incremento de 1. Si se produce algún comportamiento inesperado, vuelve la configuración predeterminada a 1. De lo contrario, si el rendimiento de las consultas no se ve afectado, puedes seguir aumentando este valor de a 1 y, luego, verificar el rendimiento en cada incremento antes de aumentar la configuración.

Ten en cuenta lo siguiente sobre la configuración Máximo de conexiones de compilador PDT:

• La configuración Max PDT Builder Connections se aplica solo a las conexiones necesarias para la recompilación de tablas, no a las conexiones necesarias para las verificaciones de activadores. Una verificación de activador es una consulta que comprueba si se activó la estrategia de persistencia de la tabla. Debido a que estas consultas de verificación de activadores siempre se ejecutan de forma secuencial, no se aplica la configuración Máximo de conexiones del compilador PDT.
• En una instancia de Looker agrupada en clústeres, el regenerador se ejecuta solo en el nodo principal. La configuración Max PDT Builder Connections se aplica solo al nodo principal y, por lo tanto, establece el límite para todo el clúster.
• La configuración Máximo de conexiones del compilador PDT no se aplica a los siguientes tipos de tablas. Estos tipos de tablas se compilan de forma consecutiva:
  • Las tablas se conservaron a través del parámetro persist_for (a menos que las tablas usen las estrategias datagroup_trigger o sql_trigger_value) para basarse en ella.
  • Tablas en modo de desarrollo.
  • Tablas que se volvieron a compilar con la opción Volver a compilar tablas derivadas y ejecutar.
  • Tablas en las que una depende de otra en una cascada de dependencias. Una tabla no se puede compilar al mismo tiempo que una tabla de la que depende. Por ejemplo, si table_B depende de table_A, entonces table_A debe terminar de volver a compilarse antes de que table_B pueda comenzar a hacerlo.

Siempre reintentar las compilaciones PDT con errores

La configuración de Compilaciones con errores de PDT siempre con reintentos configura la forma en que el regenerador de Looker intenta volver a compilar las tablas persistentes del activador que fallaron en el ciclo anterior del regenerador. El regenerador de Looker es el proceso que vuelve a compilar tablas persistentes (PDT y tablas agregadas) según el intervalo configurado en la configuración de conexión PDT y Programa de mantenimiento del grupo de datos. Cuando se habilita la configuración Siempre reintentar las compilaciones de PDT, el regenerador de Looker intentará volver a compilar un PDT que falló en el ciclo anterior del regenerador, incluso si no se cumple la condición del activador de PDT. Si se inhabilita esta configuración, el regenerador de Looker intentará volver a compilar un PDT con errores solo cuando se cumpla la condición del activador de PDT. La opción Siempre volver a realizar compilaciones de PDT fallidas está inhabilitada de forma predeterminada.

Consulta la página de documentación Tablas derivadas en Looker para obtener más información sobre el regenerador de Looker.

Habilitar el control de la API de PDT

La configuración Habilitar control de API de PDT determina si se pueden usar las llamadas a la API start_pdt_build, check_pdt_build y stop_pdt_build para esta conexión. Si se inhabilita esta configuración, las llamadas a la API fallarán cuando hagan referencia a los PDT en esta conexión. Habilitar control de API de PDT está inhabilitado de forma predeterminada.

Parámetros adicionales

Si es necesario, puedes incluir parámetros adicionales de Conectividad a bases de datos de Java (JDBC) para tus consultas.

Para hacer referencia a un atributo de usuario en un parámetro JDBC, use la sintaxis de las plantillas de líquidos _user_attributes['name_of_attribute']. Por ejemplo:

my_jdbc_param={{ _user_attributes['name_of_attribute'] }}

A continuación, te mostramos cómo podría verse en el campo Parámetros adicionales de Looker:

Looker no probó los parámetros adicionales de JDBC, lo que puede causar un comportamiento no deseado.

Programa de mantenimiento de PDT y grupos de datos

Esta configuración acepta una expresión cron que indica cuándo el regenerador de Looker debe verificar los grupos de datos y las tablas persistentes (tanto las tablas agregadas como las tablas derivadas persistentes) que se basan en sql_trigger_value y para ver qué tablas deben regenerarse o descartarse.

El valor predeterminado de */5 * * * * significa"verificar cada 5 minutos", que es la frecuencia máxima de verificaciones. Una expresión cron que indica verificaciones más frecuentes hará que se realicen verificaciones cada 5 minutos.

Mientras se desarrollan los PDT, Looker no realiza verificaciones adicionales de activadores. Una vez que se compilen todos los PDT de la última verificación del activador, Looker reanudará la verificación de los activadores de grupos de datos y PDT en función del programa de mantenimiento de PDT y grupos de datos.

Si tu base de datos no funciona todos los días y a toda hora, es posible que quieras limitar las verificaciones a los horarios en que la base de datos esté activa. Estas son algunas expresiones cron adicionales:

Expresión cron	Definición
*/5 8-17 * * MON-FRI	Revise los grupos de datos y PDT cada 5 minutos, de lunes a viernes, durante el horario de atención
*/5 8-17 * * *	Revise los grupos de datos y los PDT cada 5 minutos durante el horario de atención, todos los días
0 8-17 * * MON-FRI	Consulte los grupos de datos y PDT cada hora durante el horario de atención, de lunes a viernes
1 3 * * *	Revise los grupos de datos y los PDT todos los días a las 3:01 a.m.

Algunos aspectos que debes tener en cuenta cuando creas una expresión cron:

• Looker usa parse-cron v0.1.3, que no admite ? en expresiones cron.
• La expresión cron usa la zona horaria de la aplicación de Looker para determinar cuándo se realizan las verificaciones.
• Si no se compilan PDT, restablece la string cron al valor predeterminado */5 * * * *.

A continuación, se muestran algunos recursos para ayudarte a crear strings cron:

• https://crontab.guru: Ayuda para editar y probar strings de cron.
• http://www.crontab-generator.org: selecciona la configuración de tiempo y el generador crea la string cron correspondiente.

SSL

Elige si quieres usar la encriptación SSL para proteger los datos que pasan entre Looker y tu base de datos. SSL es solo una opción que se puede usar para proteger tus datos. En la página de documentación Habilita el acceso seguro a la base de datos, se describen otras opciones seguras.

Verificar certificado SSL

Elige si deseas solicitar la verificación del certificado SSL que utiliza la conexión. Si se requiere verificación, la autoridad certificadora (CA) SSL que firmó el certificado SSL debe provenir de la lista de fuentes de confianza del cliente. Si la CA no es una fuente de confianza, no se establece la conexión con la base de datos.

Si esta casilla no está seleccionada, se utiliza la encriptación SSL para la conexión, pero no se requiere la verificación de la conexión SSL. Por lo tanto, se puede establecer una conexión cuando la CA no está en la lista de fuentes de confianza del cliente.

Cantidad máxima de conexiones

Aquí puedes configurar la cantidad máxima de conexiones que puede establecer Looker con tu base de datos. En general, debes configurar la cantidad de consultas simultáneas que Looker puede ejecutar en tu base de datos. Looker también reserva hasta tres conexiones para finalizar las consultas. Si el grupo de conexiones es muy pequeño, Looker reservará menos conexiones.

Establece este valor con cuidado. Si el valor es demasiado alto, es posible que abrumes tu base de datos. Si el valor es demasiado bajo, las consultas deben compartir una pequeña cantidad de conexiones. Por lo tanto, muchas consultas pueden parecer lentas para los usuarios, ya que las consultas deben esperar que se muestren otras consultas anteriores.

El valor predeterminado (que varía según tu dialecto SQL) suele ser un punto de partida razonable. La mayoría de las bases de datos también tienen su propia configuración para la cantidad máxima de conexiones que aceptarán. Si la configuración de tu base de datos limita las conexiones, asegúrate de que el valor de Max Connections sea igual o inferior al límite de la base de datos.

Se agotó el tiempo de espera del grupo de conexiones

Si tus usuarios solicitan más conexiones que la configuración de Conexiones máximas, las solicitudes esperarán a que finalicen otras antes de ejecutarse. La cantidad máxima de tiempo que esperará una solicitud se configura aquí. Debes establecer este valor con cuidado. Si es demasiado baja, es posible que los usuarios vean que sus consultas se cancelaron porque no hay tiempo suficiente para que finalicen las consultas de otros usuarios. Si es demasiado alto, es posible que se acumulen muchas consultas, por lo que los usuarios tendrán que esperar demasiado tiempo. Por lo general, el valor predeterminado es un punto de partida razonable.

Estimación de costos

La casilla de verificación Cost Estimate solo se aplica a las siguientes conexiones de base de datos:

• Snowflake
• Amazon Redshift
• Amazon Aurora
• PostgreSQL, Cloud SQL para PostgreSQL y Microsoft Azure PostgreSQL

La casilla de verificación Cost Estimate habilita las siguientes funciones en la conexión:

• Estimaciones de costos de Explorar consultas
• Estimaciones de costos de consultas del ejecutor de SQL
• Estimaciones de ahorro en la computación para consultas de reconocimiento agregadas

Las conexiones de BigQuery y MySQL también son compatibles con la función Estimación de costos. Sin embargo, debido a que la función siempre está habilitada, no hay una casilla de verificación para calcular el costo en las conexiones de BigQuery y MySQL.

Consulta la página de documentación Explora datos en Looker para obtener más información.

Precaché de SQL Runner

En SQL Runner, toda la información de la tabla se precarga en cuanto seleccionas una conexión y un esquema. Esto permite que el ejecutor de SQL muestre las columnas de la tabla con rapidez cuando haces clic en el nombre de una tabla. Sin embargo, para conexiones y esquemas con muchas tablas o con tablas muy grandes, es posible que no desee que SQL Runner realice una carga previa de toda la información.

Si prefieres SQL Runner para cargar información de la tabla solo cuando está seleccionada, puedes desmarcar la opción SQL Runner Precache para inhabilitar la precarga de SQL Runner para la conexión.

Esquema de recuperación de información para escritura de SQL

Para algunas funciones de escritura de SQL, como el reconocimiento total, Looker usa el esquema de información de la base de datos para optimizar la escritura de SQL. Si el esquema de información no está almacenado en caché, es posible que Looker deba bloquear ocasionalmente la escritura de SQL en la base de datos para recuperar el esquema de información. Para los dialectos que usan el sistema de archivos distribuidos de Hadoop (HDFS), recuperar el esquema de información puede tomar el tiempo suficiente para afectar significativamente el rendimiento de tus consultas de Looker. Si sabes que tu esquema de información es lento, puedes inhabilitar la opción Esquema de información de recuperación para la escritura de SQL en tu conexión. Si inhabilitas esta función, se impedirá la optimización de SQL de Looker para ciertas funciones, por lo que deberías habilitar la opción Recuperar información del esquema para la escritura de SQL, a menos que sepas que el esquema de información de tu conexión es particularmente lento.

Inhabilitar el comentario de contexto

La opción Inhabilitar comentario contextual solo se aplica a las conexiones de BigQuery. Los comentarios de contexto en conexiones de Google BigQuery están inhabilitados de forma predeterminada, ya que los comentarios de contexto invalidan la capacidad de Google BigQuery para almacenar en caché y pueden afectar el rendimiento de esta. Puedes habilitar los comentarios contextuales para una conexión de BigQuery si desmarcas la opción Disable Context Comment en la página Connection Settings de la conexión. Consulta la página de documentación de Google BigQuery para obtener más información.

zona horaria de la base de datos

La zona horaria en la que tu base de datos almacena información basada en tiempo. Looker necesita saber esto a fin de poder convertir valores de tiempo para los usuarios, lo que facilita la comprensión y el uso de datos basados en el tiempo. Consulta la página de documentación Usa la configuración de zona horaria para obtener más información.

zona horaria de la consulta

La opción Zona horaria de consulta solo se muestra si inhabilitas las Zonas horarias específicas del usuario.

Cuando las Zonas horarias específicas del usuario están inhabilitadas, la Zona horaria de consulta es la zona horaria que se muestra a los usuarios cuando consultan datos basados en la hora, y la zona horaria en la que Looker convertirá los datos basados en la hora de la Zona horaria de la base de datos.

Consulta la página de documentación Usa la configuración de zona horaria para obtener más información.

Configura credenciales de acceso separadas para procesos PDT

Si su base de datos admite tablas derivadas persistentes y marcó la casilla Tablas derivadas persistentes en la configuración de conexión, Looker mostrará la columna Anulaciones de ADT. En la columna Anulación de PDT, puede ingresar parámetros JDBC (host, puerto, base de datos, nombre de usuario, contraseña, esquema y parámetros adicionales) específicos de los procesos PDT. Esto puede ser valioso por varios motivos:

• Si crea un usuario de base de datos separado para los procesos de PDT, puede usar los PDT en su modelo incluso si asigna atributos de usuario a sus credenciales de acceso a la base de datos.
• Los procesos PDT se pueden autenticar mediante un usuario de la base de datos aparte que tenga una prioridad más alta. De esta manera, la base de datos puede priorizar los trabajos de PDT sobre las consultas de usuarios menos importantes.
• El acceso de escritura se puede revocar para la conexión de base de datos estándar de Looker y solo se otorga a un usuario especial que los procesos PDT usarán para la autenticación. Esta es una mejor estrategia de seguridad para la mayoría de las organizaciones.
• Para bases de datos como Snowflake, los procesos PDT se pueden enrutar a un hardware más potente que no se comparte con el resto de los usuarios de Looker. De esta manera, los PDT pueden compilarse rápidamente sin incurrir en el costo de ejecutar hardware costoso a tiempo completo.

Por ejemplo, la siguiente configuración muestra una conexión en la que los campos de nombre de usuario y contraseña se establecen en los atributos del usuario. De esta manera, cada usuario puede acceder a la base de datos con sus credenciales individuales. La columna Anulación de ADT crea un usuario independiente (pdt_user) con su propia contraseña. La cuenta de pdt_user se usará en todos los procesos de PDT, con niveles de acceso adecuados para la creación y actualización de PDT:

Si bien la columna Anulación de PDT te permite cambiar el usuario de la base de datos y otras propiedades de conexión, una anulación PDT debe leer los mismos datos que la conexión predeterminada y debe escribir datos en el mismo lugar. Looker no puede leer datos de una ubicación y escribirlos en otra.

Prueba la configuración de conexión

Una vez que haya ingresado las credenciales, haga clic en Probar esta configuración para verificar que la información sea correcta y que la base de datos pueda conectarse.

Si tu conexión no pasa una o más pruebas:

• Intenta algunos de los pasos para solucionar problemas en la página de documentación Prueba la conectividad de la base de datos.
• Si ejecutas Mongo 3.6 o una versión anterior en Atlas y recibes un error en el vínculo de comunicaciones, consulta la página de documentación de Mongo Connector.
• Para recibir mensajes de conexión exitosos sobre el esquema temporal y los PDT, debes habilitar esa funcionalidad cuando configures tu base de datos de Looker. Puedes encontrar las instrucciones para hacerlo en la página de documentación Instrucciones de configuración de bases de datos.

Las conexiones a bases de datos que usan OAuth, como Snowflake y Google BigQuery, requieren el acceso del usuario. Si no accediste a tu cuenta de usuario de OAuth cuando pruebas una de estas conexiones, Looker mostrará una advertencia con un vínculo Acceder. Haz clic en el vínculo para ingresar tus credenciales de OAuth o permitir que Looker acceda a la información de tu cuenta de OAuth.

Si aún tienes problemas, comunícate con el equipo de asistencia de Looker para obtener ayuda.

Probar como usuario

Si configuró uno o más valores de parámetros de conexión para un atributo de usuario, aparecerá la opción Probar como usuario encima del botón Probar esta configuración. Selecciona un usuario y, luego, haz clic en Probar esta configuración para verificar que la base de datos pueda conectar y ejecutar consultas como este usuario.

Agrega la conexión de tu base de datos

Una vez que hayas establecido y probado la configuración de conexión de tu base de datos, haz clic en Agregar conexión. Ahora, tu conexión de base de datos se agrega a la lista en la página Conexiones.

Próximos pasos

Una vez que hayas conectado tu base de datos a Looker, estarás listo para configurar las opciones de acceso para tus usuarios.