Después de proteger y configurar tu base de datos, puedes conectarla a Looker. En esta página, se describe el nuevo flujo de trabajo de conexión de Looker.
- En el caso de las instancias de Looker (original), si el botón de activación heredado Use Legacy Connections Page está habilitado, consulta la página de documentación Cómo conectar Looker a tu base de datos con el flujo de trabajo heredado para obtener información sobre la IU de conexión heredada.
En el caso de las instancias de Looker (Google Cloud Core), el nuevo flujo de trabajo de conexión de bases de datos, que se describe en esta página, es el único flujo de trabajo admitido.
Creas una conexión de base de datos en Looker en la página Conecta tu base de datos a Looker. Existen dos opciones para abrir la página Conecta tu base de datos a Looker:
- Haz clic en el ícono del menú principal y selecciona Administrador y, luego, 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.
- Haz clic en el botón Crear en el menú de navegación principal y, luego, selecciona el elemento de menú Conexión.
En esta página, se describen los campos comunes que Looker muestra en la página Conecta tu base de datos a Looker. Los campos exactos que muestra la página dependen de la configuración de tu dialecto.
Para obtener información sobre cómo aplicar atributos del usuario a la configuración de conexión, consulta la sección Conexiones de la página de documentación Atributos del usuario.
Haz clic aquí para ver los vínculos a las instrucciones específicas del dialecto en la documentación de Looker.
- Actian Avalanche
- AlloyDB para PostgreSQL
- Amazon Aurora PostgreSQL
- Amazon Athena
- Amazon Aurora MySQL
- Amazon RDS para MySQL
- Amazon RDS para PostgreSQL
- Amazon Redshift
- Amazon Redshift 2.1 y versiones posteriores
- Amazon Redshift Serverless 2.1 y versiones posteriores
- Apache Druid
- Apache Hive 2.3 y versiones posteriores, y 3.1.2 y versiones posteriores
- Apache Spark 3 o versiones posteriores
- ClickHouse
- Cloudera Impala 3.1 y versiones posteriores
- Databricks
- DataVirtuality
- Denodo 7, 8 y 9
- Dremio
- Exasol
- Firebolt
- SQL heredado de Google BigQuery
- SQL estándar de Google BigQuery
- Google Cloud SQL para MySQL
- Google Cloud SQL para PostgreSQL
- Google Spanner
- Greenplum
- IBM DB2 en AS400
- IBM DB2 en LUW
- MariaDB
- Microsoft Azure Synapse Analytics
- Microsoft Azure SQL Database
- Microsoft Azure PostgreSQL
- Microsoft SQL Server (MSSQL)
- MongoDB Connector for BI
- MySQL
- Oracle
- Oracle ADWC
- PostgreSQL
- PrestoDB
- SAP HANA
- SingleStore (anteriormente MemSQL)
- Snowflake
- Teradata
- Trino
- Vector
- Vertica
La configuración de conexión de la base de datos incluye las siguientes cuatro secciones:
Configuración general
Nombre
Es el nombre de la conexión que quieres usar para referirte a ella. Necesitas este nombre de conexión de base de datos para usarlo en el parámetro connection
de tu modelo de LookML. El nombre de la conexión de la base de datos también es la forma en que se identifica la conexión en la página Conexiones de Administrador de Looker. No uses el nombre de ninguna carpeta para este parámetro de configuración. Este valor no tiene que coincidir con nada en tu base de datos; Name
es una etiqueta que identifica esta conexión dentro de la IU de Looker.
Dialecto de SQL
Es el dialecto de SQL que coincide con tu conexión. Es importante elegir el valor correcto para que se te presenten las opciones de conexión adecuadas y para que Looker pueda traducir correctamente tu LookML a SQL.
Usa la versión más reciente del controlador
De forma predeterminada, Looker siempre se conecta a tu base de datos con la versión más reciente del controlador JDBC para el dialecto de tu base de datos. Si el dialecto de la base de datos que seleccionaste tiene más de una versión del controlador JDBC compatible con Looker, puedes inhabilitar el botón de activación Usar la versión más reciente del controlador para seleccionar una versión anterior del controlador JDBC para la conexión. Si quieres seleccionar una versión anterior del controlador JDBC, puedes inhabilitar el botón de activación Usar la versión más reciente del controlador para tu conexión y, luego, seleccionar la versión del controlador en el menú desplegable Versión del controlador.
Si seleccionas una versión anterior del controlador JDBC, Looker seguirá usando esa versión anterior mientras sea compatible con Looker.
Looker dejará de admitir una versión del controlador en las siguientes dos situaciones:
- Se quitó la versión del controlador de la compatibilidad con Looker. En este caso, la conexión usará la versión del controlador más antigua que Looker admite para el dialecto.
- La versión del controlador aún no existe debido a una reversión de Looker. En este caso, la conexión usará la versión más reciente del controlador que admite la versión revertida.
Si la versión del controlador que seleccionaste ya no es compatible con Looker, Looker mostrará una alerta en el campo Versión del controlador de la página Edita tu conexión de base de datos para informarte que la versión del controlador seleccionada ya no es compatible. La alerta también te informará qué versión del controlador usa Looker para la conexión. Para borrar esta alerta, selecciona una versión compatible del controlador JDBC en el menú desplegable Versión del controlador o habilita el botón de activación Usar la versión más reciente del controlador para usar la versión más reciente del controlador.
Alcance del proyecto
Selecciona si la conexión se podrá usar con todos los proyectos o solo con uno:
- Todos los proyectos: Todos los proyectos de LookML en la instancia pueden tener acceso a la conexión, por lo que el nombre de la conexión se puede especificar en el parámetro
connection
de los archivos de modelo en ese proyecto. - Proyecto seleccionado: Solo un proyecto de LookML en la instancia puede tener acceso a la conexión. Cuando seleccionas esta opción, en la pantalla de conexión, se muestra un menú desplegable de los proyectos en la instancia. Selecciona el proyecto que puede tener acceso a esta conexión.
Usa esta opción junto con los siguientes permisos para delegar la administración de conexiones y la configuración de modelos:
Detalles del estado
Expande la sección Detalles del estado para probar la configuración de tu conexión.
Configuración de bases de datos
Habilitar el servidor SSH
La opción Servidor SSH solo está disponible si la instancia se implementa en la infraestructura de Kubernetes y si se habilitó la capacidad de agregar información de configuración del servidor SSH a tu instancia de Looker. Si esta opción no está habilitada en tu instancia de Looker y deseas habilitarla, comunícate con un Google Cloud especialista en ventas o abre una solicitud de asistencia. Si activas la opción Habilitar el servidor SSH, Looker mostrará los campos Servidor SSH y Túnel SSH.
Servidor SSH
No puedes especificar el puerto de localhost; el servidor SSH elige automáticamente el puerto de localhost por ti. Si necesitas crear una conexión SSH que requiera que especifiques un puerto localhost, abre una solicitud de asistencia.
Selecciona una configuración del servidor SSH en la lista desplegable. Se requiere un servidor SSH para seleccionar o crear un túnel SSH adecuado. Puedes crear un nuevo servidor SSH en la pestaña Servidores SSH del panel Conexiones.
Túnel SSH
Selecciona un túnel SSH existente en la lista desplegable o haz clic en el ícono Crear túnel nuevo si deseas crear un túnel SSH nuevo con un nombre de host y un puerto o un puerto local.
Nombre de host
Es el nombre de host de la base de datos que debe usar Looker para conectarse al host de tu base de datos.
Si trabajaste con un analista de Looker para configurar un túnel SSH en tu base de datos, ingresa "localhost"
en el campo Host. Si aplicas un atributo del usuario al campo Host, el atributo del usuario no puede tener un nivel de acceso del usuario establecido en Editable. Si configuraste un túnel SSH para conectarte a tu base de datos, no puedes aplicar un atributo del usuario al campo Host remoto:puerto.
Puerto
Es el puerto de la base de datos que debe usar Looker para conectarse al host de tu base de datos.
Si trabajaste con un analista de Looker para configurar un túnel SSH en tu base de datos, en el campo Puerto, ingresa el número de puerto que redirecciona a tu base de datos, que tu analista de Looker debería haberte proporcionado.
Puerto local
De forma predeterminada, Looker selecciona automáticamente un puerto local disponible para el túnel SSH. Para elegir un puerto local de forma manual, selecciona Ingresar valores manualmente y, luego, ingresa un número de puerto en el campo Puerto local personalizado. Asegúrate de que el puerto local esté disponible en tu instancia.
ID del proyecto de facturación (solo para Google BigQuery)
El ID del proyecto de facturación es el Google Cloud ID del proyecto. Para obtener más información, consulta la página de documentación de Google BigQuery.
ID del proyecto de almacenamiento (solo para Google BigQuery)
Es el nombre del ID de tu proyecto de Storage, si separas el procesamiento y el almacenamiento en proyectos diferentes. Puedes consultar conjuntos de datos en un proyecto Google Cloud diferente si tus desarrolladores de LookML especifican nombres de tabla completamente definidos en el parámetro sql_table_name
de tus vistas, Explores o uniones de LookML. Para obtener más información, consulta la página de documentación de Google BigQuery.
Conjunto de datos principal (solo para Google BigQuery)
Es el nombre del conjunto de datos que deseas que Looker use de forma predeterminada cuando consulte tu base de datos. Para obtener más información, consulta la página de documentación de Google BigQuery.
Nombre de la base de datos
El nombre de la base de datos en el host. Por ejemplo, es posible que tengas un nombre de host my-instance.us-east-1.redshift.amazonaws.com
en el que haya una base de datos llamada sales_info
. En este campo, ingresarías sales_info
. Si tienes varias bases de datos en el mismo host, es posible que debas crear varias conexiones para usarlas (con la excepción de MySQL, en el que la palabra base de datos significa algo un poco diferente que en la mayoría de los dialectos de SQL).
Esquema predeterminado
Es el esquema predeterminado que usa Looker cuando no se especifica un esquema. Esto se aplica cuando usas el Ejecutor de SQL, durante la generación del proyecto de LookML y cuando consultas tablas.
Configuración de autenticación
Para las conexiones de Google BigQuery, Snowflake, Trino y Databricks, selecciona el tipo de autenticación que deseas que Looker use para acceder a tu base de datos:
- En el caso de las conexiones de Google BigQuery, tienes la opción de configurar OAuth o una cuenta de servicio para que Looker la use para autenticarse en tu base de datos.
- En el caso de las conexiones de Snowflake, Trino y Databricks, tienes la opción de configurar OAuth o una cuenta de base de datos para que Looker la use para autenticarse en tu base de datos.
Cuando usas OAuth, tus usuarios deben acceder a tu base de datos para emitir consultas desde Looker. Para obtener más información sobre cómo configurar OAuth en una conexión a Looker, consulta los procedimientos de conexión de Google BigQuery, Snowflake, Trino o Databricks.
Nombre de usuario
Es el nombre de usuario de una cuenta de usuario en tu base de datos que Looker puede usar para conectarse a ella.
Contraseña
Es la contraseña de una cuenta de usuario en tu base de datos que Looker puede usar para conectarse a ella.
Expande la sección Detalles del estado para probar la configuración de tu conexión.
Configuración opcional
Cantidad máxima de conexiones por nodo
Aquí puedes establecer la cantidad máxima de conexiones que Looker puede establecer con tu base de datos. En su mayor parte, estableces la cantidad de consultas simultáneas que Looker puede ejecutar en tu base de datos. Looker también reserva hasta tres conexiones para detener 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 sobrecargues la base de datos. Si el valor es demasiado bajo, las consultas deberán compartir una pequeña cantidad de conexiones, lo que podría hacer que muchas consultas parezcan lentas para los usuarios, ya que deben esperar a que se devuelvan otras consultas anteriores.
El valor predeterminado (que varía según el dialecto de 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 per node sea igual o inferior al límite de tu base de datos.
Tiempo de espera del grupo de conexiones
Si tus usuarios solicitan más conexiones de las que se configuraron en el parámetro de configuración Max Connections per node, las solicitudes esperarán a que finalicen otras antes de ejecutarse. Aquí se configura la cantidad máxima de tiempo que esperará una solicitud. El parámetro de configuración predeterminado es de 120 segundos.
Establece este valor con cuidado. Si se establece demasiado bajo, es posible que los usuarios descubran que sus búsquedas se cancelan porque no hay tiempo suficiente para que finalicen las búsquedas de otros usuarios. Si se establece demasiado alto, se pueden acumular grandes cantidades de consultas, lo que provoca que los usuarios esperen durante mucho tiempo. Por lo general, el valor predeterminado es un punto de partida razonable.
Cantidad máx. de consultas simultáneas para esta conexión
Este valor opcional limita la cantidad de consultas simultáneas que enviará Looker a esta conexión de base de datos a la vez. Si llegan más solicitudes simultáneas que solicitan la misma conexión, Looker las pondrá en cola internamente y las procesará en orden. Si estableces este valor, se reemplazará un valor existente de Max connections per node.
Cantidad máx. de consultas simultáneas por usuario para esta conexión
Este valor opcional limita la cantidad de consultas simultáneas de un usuario que Looker enviará a esta conexión de base de datos a la vez. Si llegan más solicitudes simultáneas que solicitan la misma conexión, Looker las pondrá en cola internamente y las procesará en orden.
Parámetros adicionales de JDBC
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 del usuario en un parámetro JDBC, usa la sintaxis de plantillas de Liquid: _user_attributes['name_of_attribute']
. Consulta el siguiente ejemplo:
my_jdbc_param={{ _user_attributes['name_of_attribute'] }}
Programación de mantenimiento
El regenerador de Looker verifica los grupos de datos y las tablas persistentes (tanto las tablas agregadas como las tablas derivadas persistentes) que se basan en sql_trigger_value
. Según estas verificaciones, el regenerador de Looker vuelve a compilar o descarta las tablas persistentes del esquema de borrador de tu base de datos.
El valor de Programa de mantenimiento establece el intervalo cron
para el regenerador de Looker. El regenerador de Looker inicia un ciclo de regeneración para verificar los grupos de datos y las tablas persistentes en el intervalo cron
. Si un ciclo del regenerador de Looker sigue en curso en el siguiente intervalo de cron
, el regenerador de Looker completará el ciclo en curso y, luego, esperará hasta el siguiente intervalo de cron
para comenzar el siguiente ciclo del regenerador.
El parámetro de configuración Programa de mantenimiento acepta una expresión de cron
. El valor predeterminado es */5 * * * *
, lo que significa que el ciclo del regenerador de Looker iniciará un ciclo en el intervalo de cinco minutos si se completó el ciclo anterior del regenerador. Si no se completó el ciclo anterior del regenerador, el regenerador de Looker se iniciará en el siguiente intervalo de cinco minutos después de que se complete su ciclo.
El intervalo predeterminado de cinco minutos también es el intervalo más frecuente que se admite para el Programa de mantenimiento. Looker no aplica un intervalo máximo para el Programa de mantenimiento, lo que significa que puedes extender el intervalo entre los ciclos del regenerador de Looker durante el tiempo que se pueda especificar con una expresión cron
. Ten en cuenta que los ciclos más largos del regenerador de Looker pueden afectar negativamente la actualización de los datos en tu caché y en las tablas persistentes.
Después de que el regenerador de Looker complete todas las verificaciones y las recompilaciones de PDT en un ciclo, esperará el siguiente intervalo de cron
para iniciar el siguiente ciclo. Si tienes compilaciones de PDT de larga duración, es posible que haya períodos prolongados entre los ciclos del regenerador de Looker. Otros factores pueden afectar el tiempo necesario para volver a compilar tus tablas, como se describe en la sección Consideraciones importantes para implementar tablas persistentes de la página Tablas derivadas en Looker.
Si tu base de datos no está disponible las 24 horas, todos los días, es posible que desees limitar las verificaciones a los momentos en que esté disponible. Estas son algunas expresiones cron
adicionales:
Expresión cron |
Definición |
---|---|
*/5 8-17 * * MON-FRI |
Verifica los grupos de datos y los PDT cada 5 minutos durante el horario de atención, de lunes a viernes. |
*/5 8-17 * * * |
Verificar 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 |
Verifica los grupos de datos y los PDT cada hora durante el horario de atención, de lunes a viernes. |
1 3 * * * |
Verifica 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 las expresionescron
. - 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 los PDT, restablece la cadena cron a su valor predeterminado de
*/5 * * * *
.
Estos son algunos recursos que te ayudarán a crear cadenas de cron
:
- https://crontab.guru: Ayuda a editar y probar cadenas de
cron
. - http://www.crontab-generator.org: Selecciona la configuración de tiempo y el generador crea la cadena
cron
correspondiente.
SSL
Elige si deseas usar la encriptación SSL para proteger los datos a medida 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 Cómo habilitar el acceso seguro a la base de datos, se describen otras opciones seguras.
Verificar SSL
Elige si deseas exigir la verificación del certificado SSL que usa la conexión. Si se requiere verificación, la autoridad certificadora (CA) de 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 establecerá la conexión a la base de datos.
Si esta casilla no está seleccionada, se seguirá usando la encriptación SSL en la conexión, pero no se requerirá la verificación de la conexión SSL, por lo que se podrá establecer una conexión cuando la CA no esté en la lista de fuentes de confianza del cliente.
Almacenar previamente en caché tablas y columnas
En el Ejecutor de SQL, toda la información de la tabla se carga previamente en cuanto seleccionas una conexión y un esquema. Esto permite que SQL Runner muestre rápidamente las columnas de la tabla en cuanto haces clic en el nombre de una tabla. Sin embargo, para las conexiones y los esquemas con muchas tablas o con tablas muy grandes, es posible que no desees que el Ejecutor de SQL cargue previamente toda la información.
Si prefieres que el Ejecutor de SQL cargue la información de la tabla solo cuando se selecciona una tabla, puedes anular la selección de la opción Almacenar previamente en caché tablas y columnas para inhabilitar la precarga del Ejecutor de SQL para la conexión.
Recuperar y almacenar en caché el esquema
Para algunas funciones de escritura de SQL, como el reconocimiento de agregaciones, Looker usa el esquema de información de tu base de datos para optimizar la escritura de SQL. Si el esquema de información no se almacena en caché, es posible que Looker deba bloquear ocasionalmente la escritura de SQL en la base de datos para poder recuperar el esquema de información. En el caso de los dialectos que usan el sistema de archivos distribuidos de Hadoop (HDFS), la recuperación del esquema de información puede tardar lo suficiente como para afectar de manera significativa el rendimiento de tus consultas de Looker. Si sabes que tu esquema de información es lento, puedes inhabilitar la opción Fetch and cache schema para tu conexión. Si inhabilitas esta función, se evitará parte de la optimización de SQL de Looker para ciertas funciones, por lo que debes habilitar la opción Fetch and cache schema, a menos que sepas que el esquema de información de tu conexión es particularmente lento.
Estimación de costos
El botón de activación Estimación de costos solo se aplica a las siguientes conexiones de bases de datos:
- Snowflake
- Amazon Redshift
- Amazon Aurora
- PostgreSQL, Google Cloud SQL para PostgreSQL y Microsoft Azure PostgreSQL
El botón de activación Estimación de costos habilita las siguientes funciones en la conexión:
- Estimaciones de costos para las preguntas de Explorar
- Estimaciones de costos para las consultas de SQL Runner
- Estimaciones de ahorro de procesamiento para las consultas con conocimiento agregado
Consulta la página de documentación Explorar datos en Looker para obtener más información.
Agrupación de conexiones de bases de datos
En el caso de los dialectos que admiten el agrupamiento de conexiones de bases de datos, esta función permite que Looker use grupos de conexiones a través del controlador de JDBC. La agrupación de conexiones de bases de datos permite un rendimiento más rápido de las consultas; una consulta nueva no necesita crear una conexión de base de datos nueva, sino que puede usar una conexión existente del grupo de conexiones. La capacidad de agrupación de conexiones garantiza que se limpie una conexión después de la ejecución de una consulta y que esté disponible para su reutilización después de que finalice la ejecución de la consulta. Consulta la página de documentación sobre agrupación de conexiones de bases de datos para obtener más información.
Configuración de tablas derivadas persistentes (PDT)
Si las PDT están habilitadas, aparecerán los siguientes parámetros de configuración.
Habilitar PDT
Activa el botón de activación Habilitar PDT para habilitar las tablas derivadas persistentes. Cuando los PDT están habilitados, la ventana Connection revela campos de PDT adicionales y la sección PDT Overrides. Looker muestra el botón de activación Habilitar PDT solo si el dialecto de la base de datos admite el uso de PDT.
Ten en cuenta lo siguiente sobre los PDT:
- Las PDT no son compatibles con las conexiones de Snowflake que usan OAuth.
- Si inhabilitas las PDT en una conexión, no se inhabilitarán los grupos de datos asociados a tus PDT. Incluso si inhabilitas los PDT, los grupos de datos existentes seguirán ejecutando sus consultas de
sql_trigger
en la base de datos. Si deseas evitar que un grupo de datos ejecute su consultasql_trigger
en tu base de datos, debes borrar o comentar el parámetrodatagroup
de tu proyecto de LookML, o bien puedes actualizar el parámetro de configuración Programa de mantenimiento de la conexión para que Looker verifique las PDT y los grupos de datos con muy poca frecuencia o nunca. - Para las conexiones de Snowflake, Looker establece el valor del parámetro
AUTOCOMMIT
enTRUE
(el valor predeterminado de Snowflake).AUTOCOMMIT
es obligatorio para los comandos de SQL que ejecuta Looker para mantener su sistema de registro de PDT.
Base de datos temporal
Si bien esta base de datos se etiqueta como temporal, debes ingresar el nombre de la base de datos o del esquema (según tu dialecto de SQL) para que Looker lo use a fin de crear tablas derivadas persistentes. 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 las instrucciones correspondientes.
Cada conexión debe tener su propia base de datos temporal o esquema. No se pueden compartir entre conexiones.
Cantidad máxima de conexiones del compilador de PDT
El parámetro de configuración Cantidad máxima de conexiones del compilador de PDT te permite especificar cuántas compilaciones de tablas simultáneas puede iniciar el regenerador de Looker en la conexión de base de datos. El parámetro de configuración Cantidad máxima de conexiones del compilador de PDT solo se aplica a los tipos de tablas para los que el regenerador de Looker inicia recompilaciones:
- Tablas con activador de persistencia (tablas derivadas persistentes y tablas de agregación que usan la estrategia de persistencia
datagroup_trigger
osql_trigger_value
) - Tablas persistentes que usan la estrategia
persist_for
, pero solo cuando la tablapersist_for
forma parte de una cascada de tablas derivadas en la que depende de una tabla que usa la estrategia de persistenciadatagroup_trigger
osql_trigger_value
. En este caso, el regenerador de Looker volverá a compilar una tablapersist_for
, ya que se necesita para volver a compilar otra tabla en cascada. De lo contrario, el regenerador no inicia compilaciones para las tablaspersist_for
.
El parámetro de configuración Cantidad máxima de conexiones del compilador de PDT tiene el valor predeterminado 1, pero se puede establecer en 10. Sin embargo, el valor no puede ser superior al que se establece en el campo Max connections per node o en el parámetro per-user-query-limit
establecido en las opciones de inicio de Looker.
Establece este valor con cuidado. Si el valor es demasiado alto, es posible que sobrecargues la 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 la arquitectura multiusuario, como BigQuery, Snowflake y Redshift, pueden tener un mejor rendimiento en el manejo de compilaciones de consultas paralelas.
Si deseas aumentar el parámetro de configuración Cantidad máxima de conexiones del compilador de PDT, se recomienda aumentarlo de a 1. Si se produce algún comportamiento inesperado, vuelve a establecer el valor predeterminado de 1. De lo contrario, si el rendimiento de las búsquedas no se ve afectado, puedes seguir aumentándolo de forma incremental en 1 y verificar el rendimiento en cada incremento antes de aumentar aún más el parámetro de configuración.
Ten en cuenta lo siguiente sobre el parámetro de configuración Cantidad máxima de conexiones del compilador de PDT:
- El parámetro de configuración Cantidad máxima de conexiones del compilador de PDT solo se aplica a las conexiones necesarias para la recompilación de tablas, no a las conexiones necesarias para las verificaciones de activadores. Una verificación de activación es una consulta que verifica si se activó la estrategia de persistencia de la tabla. Debido a que estas consultas de verificación de activación siempre se ejecutan de forma secuencial, no se aplica el parámetro de configuración Max Number of PDT Builder Connections.
- En una instancia de Looker agrupada en clústeres, el regenerador solo se ejecuta en el nodo principal. El parámetro de configuración Cantidad máxima de conexiones del compilador de PDT solo se aplica al nodo principal y, por lo tanto, establece el límite para todo el clúster.
- El parámetro de configuración Cantidad máxima de conexiones del compilador de PDT no se aplica a los siguientes tipos de tablas. Estos tipos de tablas se compilan de forma consecutiva:
- Tablas que se conservan a través del parámetro
persist_for
(a menos que otras tablas que usan las estrategiasdatagroup_trigger
osql_trigger_value
dependan de ellas) - Tablas en el modo de desarrollo.
- Tablas recompiladas 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 otra de la que depende. Por ejemplo, si
table_B
depende detable_A
,table_A
debe terminar de recompilarse antes de quetable_B
pueda comenzar a recompilarse.
- Tablas que se conservan a través del parámetro
Reintentar compilaciones de PDT con errores
El parámetro de configuración de activación Retry failed PDT builds configura la forma en que el regenerador de Looker intenta volver a compilar las tablas persistentes activadas que fallaron en el ciclo anterior del regenerador. El regenerador de Looker es el proceso que vuelve a compilar las tablas persistentes activadas (PDT y tablas de agregación) según el intervalo configurado en el parámetro de configuración de conexión Programa de mantenimiento. Cuando el botón de activación Retry Failed PDT Builds está habilitado, 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 de activación del PDT. Cuando este parámetro de configuración está inhabilitado, el regenerador de Looker intentará volver a compilar un PDT que falló anteriormente solo cuando se cumpla la condición de activación del PDT. La opción Retry Failed PDT Builds 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.
Control de la API de PDT
El botón de activación Control de la API de PDT determina si se pueden usar las llamadas a la API de start_pdt_build
, check_pdt_build
y stop_pdt_build
para esta conexión. Cuando el botón de activación PDT API Control está inhabilitado, estas llamadas a la API fallarán cuando hagan referencia a PDT en esta conexión. El botón de activación Control de la API de PDT está inhabilitado de forma predeterminada.
Habilitar anulaciones de PDT
Si tu base de datos admite tablas derivadas persistentes y activaste el botón de activación Habilitar PDT en la configuración de la conexión, Looker mostrará el botón de activación Anulaciones de PDT. Habilita el botón de activación PDT Overrides para mostrar la sección PDT Overrides, en la que puedes ingresar parámetros de JDBC separados (host, puerto, base de datos, nombre de usuario, contraseña, esquema, parámetros adicionales y después de las instrucciones de conexión) que sean específicos para los procesos de PDT. Esto puede ser valioso por varios motivos:
- Si creas un usuario de base de datos independiente para los procesos de PDT, puedes usar PDT en tu proyecto de Looker incluso si asignas atributos de usuario a tus credenciales de acceso a la base de datos o usas OAuth para la conexión a la base de datos.
- Los procesos de PDT pueden autenticarse a través de un usuario de base de datos independiente que tenga una prioridad más alta. De esta manera, la base de datos puede priorizar los trabajos de PDT por sobre las consultas de los usuarios menos importantes.
- Se puede revocar el acceso de escritura para la conexión estándar de la base de datos de Looker y otorgarlo solo a un usuario especial que los procesos de PDT usarán para la autenticación. Esta es una mejor estrategia de seguridad para la mayoría de las organizaciones.
- En el caso de bases de datos como Snowflake, los procesos de PDT se pueden enrutar a hardware más potente que no se comparte con el resto de los usuarios de Looker. De esta manera, los PDT se pueden compilar rápidamente sin incurrir en el costo de ejecutar hardware costoso a tiempo completo.
Por ejemplo, en una conexión en la que los campos de nombre de usuario y contraseña se establecen en atributos del usuario, la sección PDT Overrides puede crear un usuario independiente (pdt_user
) con su propia contraseña. Con esta configuración, ocurrirá lo siguiente:
- Cada usuario puede acceder a la base de datos con sus credenciales individuales, según lo asignado por sus atributos de usuario.
- La cuenta de
pdt_user
se usará para todos los procesos de PDT, con niveles de acceso adecuados para la creación y actualización de PDT. - El tráfico de búsquedas de los usuarios y el tráfico de procesos de PDT se pueden diferenciar rápidamente para fines como la supervisión con Actividad del sistema.
zona horaria de la base de datos
Es la zona horaria en la que tu base de datos almacena la información basada en el tiempo. Looker necesita saber esto para poder convertir los valores de tiempo para los usuarios, lo que facilita la comprensión y el uso de los datos basados en el tiempo. Consulta la página de documentación Cómo usar la configuración de zona horaria para obtener más información.
zona horaria de la consulta
La opción Zona horaria de la consulta solo está visible si inhabilitaste Zonas horarias específicas del usuario.
Cuando se inhabilitan las zonas horarias específicas del usuario, la zona horaria de la consulta es la zona horaria que se muestra a los usuarios cuando consultan datos basados en el tiempo, y la zona horaria a la que Looker convertirá los datos basados en el tiempo de la zona horaria de la base de datos.
Consulta la página de documentación Cómo usar la configuración de zona horaria para obtener más información.
Expande la sección Detalles del estado para probar la configuración de tu conexión.
Revisar
Una vez que hayas ingresado todos los parámetros de configuración de la conexión a la base de datos, puedes revisar y probar la conexión para asegurarte de que esté configurada correctamente.
Puedes probar la configuración de tu conexión desde varios lugares de la IU de Looker:
- Selecciona el botón Probar en la sección Detalles del estado en la parte inferior de la página Configuración de conexiones.
- Selecciona el botón Probar junto al listado de la conexión en la página Administrador de conexiones, como se describe en la página de documentación Conexiones.
Si Looker muestra Se puede conectar, presiona Conectar para crear la conexión. Luego, tu conexión de base de datos se agregará a la lista en la página Connections Admin de Looker.
Si estableciste uno o más valores de parámetros de conexión en un atributo del usuario, aparecerá la opción Probar como usuario. Selecciona un usuario y, luego, haz clic en Probar para verificar que la base de datos pueda conectarse y ejecutar consultas como este usuario.
Soluciona problemas
Si tu conexión no pasa una o más pruebas, ten en cuenta lo siguiente:
- Si ejecutas la versión 3.6 o una anterior de Mongo en Atlas y se produce un error en el vínculo de comunicaciones, consulta la página de documentación del conector de Mongo.
- Para recibir mensajes de conexión exitosa sobre el esquema temporal y los PDT, debes permitir 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 la base de datos.
- Las conexiones de bases de datos que usan OAuth, como Snowflake y Google BigQuery, requieren que el usuario acceda a su cuenta. Si no accediste a tu cuenta de usuario de OAuth cuando pruebes una de estas conexiones, Looker mostrará una advertencia con un vínculo para 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.
- En el caso de las instancias de Looker alojadas por el cliente, consulta la página de documentación Prueba la conectividad de la base de datos para las instancias alojadas por el cliente para obtener sugerencias sobre cómo solucionar problemas.
Próximos pasos
Después de conectar tu base de datos a Looker, podrás configurar las opciones de acceso para tus usuarios.