Teradata QueryGrid incluye los siguientes componentes:
Componente | Descripción |
---|---|
Teradata QueryGrid Manager | Software instalado en una máquina física dedicada (TMS o servidor) o VM que permite la definición, administración y supervisión de Teradata QueryGrid. Después de instalar Teradata QueryGrid Manager, configúrelo en Viewpoint y, a continuación, use el portlet QueryGrid para instalar y configurar los demás componentes de Teradata QueryGrid. |
Centro de datos | Nombre lógico que representa la ubicación física o la región de los orígenes de datos (sistemas) y las instancias de Teradata QueryGrid Manager. Si están disponibles, los nodos de origen de datos se comunican con instancias de QueryGrid Manager que comparten el mismo centro de datos. |
Origen de datos | Sistema que contiene uno o más nodos de origen de datos que comparten la misma plataforma de software, como los nodos de sistemas de Teradata, los nodos de un clúster de Hadoop o los nodos de un clúster de Presto. |
Puente | Un sistema que contiene un subconjunto de nodos de origen de datos o nodos de origen sin datos usado para proporcionar conectividad entre sistemas de orígenes de datos que no tienen conectividad de red directa. |
Tejido | Uno o más nodos de origen de datos, que abarcan diferentes sistemas, que ejecutan una versión compatible del software de tejido tdqg de Teradata QueryGrid en el mismo puerto. Solo se admiten los enlaces que incluyen el conector de Teradata. Por ejemplo, los enlaces en los que ni el iniciador ni el conector de destino son un conector de Teradata, como Hive a Oracle, no son compatibles. |
Conector | Software de adaptador para un origen de datos que permite la asignación, conversión y comunicación de tipos de datos con otros conectores en el mismo tejido de Teradata QueryGrid. El conector de inicio es el conector con el que interactúa para iniciar la consulta, y el conector de Destino es el conector que se activa en el lado remoto para realizar la mayor parte del procesamiento de la consulta. Se admiten los siguientes conectores:
|
Enlace | Configuración con nombre que especifica los conectores que pueden comunicarse entre sí y define las reglas de transferencia de datos. |
Teradata QueryGrid Manager
- Administrar y supervisar Teradata QueryGrid
- Instalar, configurar y actualizar Teradata QueryGrid
- Iniciar comprobaciones de diagnóstico de enlaces, conectores o anchos de banda
- Resumir las métricas de rendimiento de las consultas
- Administrar las claves para un acceso seguro a Teradata QueryGrid
- Capturar registros generados a partir de componentes de Teradata QueryGrid
- Especificaciones de hardware de QueryGrid Manager
- Cantidad de nodos de origen de datos en el tejido
- Volumen de consultas de QueryGrid
- Alta disponibilidad (se necesitan dos instancias de QueryGrid Manager como mínimo, consulte Tamaño de QueryGrid Manager)
- Supervisar las consultas de QueryGrid
- Recibir alertas de condiciones problemáticas
- Realizar cambios de configuración
- Crear paquetes de soporte de captura para consultas con errores
- Ejecutar comprobaciones de diagnóstico
Si todas las instancias de QueryGrid Manager están sin conexión, las consultas de QueryGrid pueden seguir ejecutándose siempre que no se reinicie ninguno de los servicios de tejido de QueryGrid de la ruta de acceso de la consulta.
Clúster de QueryGrid Manager
Cuando se instala más de una instancia de Teradata QueryGrid Manager, debe agrupar las instancias de Teradata QueryGrid Manager en un clúster para obtener una alta disponibilidad y escalabilidad. La agrupación en clústeres garantiza que todas las instancias de Teradata QueryGrid Manager tengan la misma configuración y cada instancia puede administrar y supervisar Teradata QueryGrid. Cree varios clústeres de QueryGrid Manager para mantener entornos de producción y prueba separados.
Si existe un clúster, la conmutación por error y la recuperación de una instancia de QueryGrid Manager es automática. Si una instancia se desconecta, las demás instancias del clúster asumen la carga de trabajo de dicha instancia. Cuando la instancia de QueryGrid Manager vuelve a estar en línea, recupera automáticamente las nuevas actualizaciones de configuración realizadas mientras estaba desconectada y reanuda su carga de trabajo tal como estaba antes del error.
Centro de datos
Un centro de datos es una ubicación o región donde residen los sistemas conectados de QueryGrid. Al asociar las instancias de QueryGrid Manager y los sistemas conectados de QueryGrid con centros de datos, QueryGrid puede asegurarse de que los latidos, las actualizaciones de configuración, las métricas de consulta y los registros transferidos entre los nodos y QueryGrid Manager sigan siendo locales en el centro de datos o la región.
Cuando se instala el software Teradata QueryGrid Manager en una máquina física, se crea un centro de datos predeterminado con el nombre de host del TMS, VM o servidor. El nombre del centro de datos predeterminado se muestra en el portlet QueryGrid.
- Cree un centro de datos en el portlet QueryGrid.
- Cree un centro de datos durante la agrupación en clústeres si tiene dos o más instancias de Teradata QueryGrid Manager.
Origen de datos
Los siguientes sistemas de origen de datos se pueden agregar a Teradata QueryGrid. Cada sistema de origen de datos debe tener su propio conector.
Origen de datos | Conector |
---|---|
Analytics Database | Teradata |
Hadoop | Hive, Spark SQL y Presto |
Presto independiente | Presto |
Nodos de controlador de Oracle | Oracle |
Nodos de controlador de BigQuery | BigQuery |
Nodo de controlador Generic JDBC | Generic JDBC |
Durante la configuración de Teradata QueryGrid, el software de nodo y tejido se instala en cada nodo de un sistema (a excepción de Oracle, BigQuery y un origen de datos genérico, donde el software solo se instala en los nodos de controlador de Oracle, BigQuery o genérico). El software de nodo administra los tejidos y conectores del nodo.
Puente
- Un subconjunto de nodos de origen de datos que ejecuten el software de nodo de QueryGrid. Los nodos de origen de datos pueden estar en el sistema de inicio, el sistema de destino o ambos.
- Un conjunto de nodos de origen sin datos que ejecute el software de nodo QueryGrid. Los nodos de origen sin datos no necesitan el software de conector porque no hay datos locales que procesar. Un ejemplo de un nodo de origen sin datos es un nodo perimetral en un sistema Hadoop.
Para cada sistema de puente agregado a un enlace, se requiere una nueva configuración de salto que especifique la red del lado de inicio, la red del lado de destino y la directiva de comunicación que se usará para los datos transferidos en ese salto. Un salto es la transferencia de datos entre dos sistemas de origen de datos o de puente conectados directamente. El número de saltos depende del número de puentes.
Cantidad de puentes | Cantidad de saltos definidos |
---|---|
Sin puente | Un salto (el salto entre el iniciador y el destino) |
Un puente | Dos saltos (el salto entre el iniciador y el puente, y el salto entre el puente y el destino) |
Dos puentes | Tres saltos (el salto entre el iniciador y el primer puente, el salto entre el primer puente y el segundo puente, y el salto entre el segundo puente y el destino). |
Tres puentes | Cuatro saltos (el salto entre el iniciador y el primer puente, el salto entre el primer puente y el segundo puente, el salto entre el segundo puente y el tercer puente y el salto entre el tercer puente y el destino). |
Cuatro puentes | Cinco saltos (el salto entre el iniciador y el primer puente, el salto entre el primer puente y el segundo puente, el salto entre el segundo puente y el tercer puente, el salto entre el tercer puente y el cuarto puente y el salto entre el cuarto puente y el destino). |
Tejido
- Permitir la comunicación entre nodos de origen de datos emparejados del mismo tipo (por ejemplo, entre Teradata y Teradata) o de distintos tipos (por ejemplo, entre Teradata y Presto).
- Permitir a un usuario iniciar una única consulta SQL que una datos de dos o más orígenes de datos en el tejido.
No hay ninguna restricción sobre el tamaño de los datos transportados entre los nodos de origen de datos en un tejido.
- Permitir que los conectores de Teradata QueryGrid realicen lo siguiente:
- Comunicación entre sí en paralelo
- Ejecución, procesamiento y transporte de datos de manera eficiente
- Supervisar el uso de tejido por consulta y generar informes de métricas para Teradata QueryGrid Manager.
Los conectores y los enlaces están asociados con un tejido.
Conectores
- Permitir el procesamiento de consultas entre orígenes de datos (sistemas).
- Traducir el SQL de solicitud de consulta de un formato de consulta de origen a otro.
- Transformar los datos para convertir los datos de un tipo o formato de datos a otro con el objetivo de permitir el intercambio entre diferentes sistemas de orígenes de datos.
- Permitir la participación de orígenes de datos en consultas. Cualquier conector que se una al tejido puede participar en las consultas.
- Permitir que los orígenes de datos inicien consultas.
- Excepto para los conectores de Oracle, BigQuery y Generic JDBC.
- Permitir enviar datos al tejido y recibir datos de él.
- Permitir la comunicación con otros conectores del tejido.
- Controlar la ejecución de consultas en sistemas de destino. Todos los conectores pueden actuar como destino de consultas y controlar las consultas que se ejecutan en un sistema de destino de origen de datos en nombre del sistema de inicio de origen de datos.
- Devuelve resultados de consultas a los sistemas de inicio.
Los conectores son específicos del tipo de sistema (por ejemplo, los sistemas de Teradata, Hive o Hadoop configurado con Presto). Por ejemplo, el sistema de Teradata aloja un conector de Teradata, pero un único sistema Hadoop puede alojar múltiples conectores (como Hive, Spark y Presto).
Las propiedades de conector opcionales permiten refinar la configuración de un tipo de conector o reemplazar las propiedades de conector establecidas durante la configuración.
El software de conector conecta orígenes de datos con el tejido de Teradata QueryGrid. El software se instala en todos los nodos de origen de datos de un sistema. El software de tejido también se instala en todos los nodos de origen de datos de un sistema. El software de tejido incluye un controlador. Un controlador se ejecuta en uno o varios nodos de origen de datos llamados Nodos del controlador. Como parte del procesamiento de consultas, un nodo de controlador recibe solicitudes del conector de iniciador y envía las solicitudes al sistema de destino. El controlador carga el conector, lee los mensajes, invoca los métodos para procesar las solicitudes y envía las respuestas.
- Especifique qué nodos de un origen de datos son nodos de controlador.
En un sistema grande, solo es necesario que haya un subconjunto de nodos como nodos de controlador.
- Seleccione varios nodos de controlador para la redundancia y para compartir la carga de trabajo necesaria para iniciar consultas.
- Limite el número de nodos de controlador para permitir una mejor reutilización de la sesión.
- Reutiliza las conexiones físicas.
- Reduce la sobrecarga de las consultas de QueryGrid.
- Minimiza las sesiones de creación y cierre.
El grupo de conexiones aprovecha la misma conexión JDBC para todas las fases de una misma consulta o para consultas posteriores con la misma sesión y credenciales de usuario. Para obtener información sobre cómo configurar las propiedades de la agrupación de conectores ajustables, consulte la información de propiedades del conector y del enlace en el conector correspondiente.
Enlaces
Tipo de conector | Descripción |
---|---|
De inicio | Punto en el que se origina una consulta de QueryGrid. Por ejemplo, en una consulta de Teradata a Presto, el conector de Teradata inicia la consulta. |
Destino | Punto de destino de una consulta de QueryGrid. Por ejemplo, en una consulta de Teradata a Presto, un conector de Presto es el conector de destino al que accede el conector de inicio para importar o exportar datos. |
Conectores definidos | Resultado |
---|---|
Solo sistemas de Teradata | Solo puede crear enlaces entre sistemas Teradata. |
Teradata, Presto, Hive, Spark, Oracle, BigQuery y Generic JDBC | Puede crear enlaces entre sistemas Teradata con cualquiera de estos tipos de conectores. |
Los enlaces simplifican la configuración de definiciones de servidor externo antes de ejecutar consultas de QueryGrid.
- Un emparejamiento de enlaces de conector de inicio y conector de destino para su uso en las consultas.
- El número de puentes utilizados, si los hay:
Cantidad de puentes Cantidad de saltos definidos Sin puente Un salto (el salto entre el iniciador y el destino) Un puente Dos saltos (el salto entre el iniciador y el puente, y el salto entre el puente y el destino) Dos puentes Tres saltos (el salto entre el iniciador y el primer puente, el salto entre el primer puente y el segundo puente, y el salto entre el segundo puente y el destino). Tres puentes Cuatro saltos (el salto entre el iniciador y el primer puente, el salto entre el primer puente y el segundo puente, el salto entre el segundo puente y el tercer puente y el salto entre el tercer puente y el destino). Cuatro puentes Cinco saltos (el salto entre el iniciador y el primer puente, el salto entre el primer puente y el segundo puente, el salto entre el segundo puente y el tercer puente, el salto entre el tercer puente y el cuarto puente y el salto entre el cuarto puente y el destino). - Las propiedades de los conectores de inicio y de destino.Cuando se crean enlaces y propiedades asociadas, se crean pares nombre-valor (NVP) de configuración. Un NVP:
- Especifica el comportamiento del componente del conector de destino.
- Configura el modo en que se transforman los datos.
- Configura la capa de transporte de datos del enlace subyacente.
- Afecta al funcionamiento del conector de iniciador.
Las propiedades opcionales permiten afinar la configuración del conector de inicio o de destino. Estas propiedades de enlace reemplazan a las propiedades del conector.
- Define las redes de inicio y de destino para los saltos.
- Los Links hacen referencia a las redes para determinar qué interfaces se utilizarán para la transferencia de datos. Una consulta se origina en un servidor o una red determinados y se envía a un servidor o una red de destino. Si no se especifica ninguna red, el tejido prueba todas las direcciones de red de nodo de destino conocidas en paralelo, y usa la primera con la que pueda establecer una conexión.
- Las Networks se definen mediante reglas que asignan interfaces de red física a definiciones de red lógica, ya sea por nombre de la interfaz o notación CIDR (enrutamiento de interdominios sin clases). Las reglas se comprueban en el orden en que aparecen en la lista de reglas coincidentes.
- Una directiva de comunicación que define reglas para la transferencia de datos entre conectores de destino e inicio y puentes (si se usan).
Las directivas de comunicación definen el modo en que los sistemas se comunican mutuamente. Permiten configurar la simultaneidad de transferencias y habilitar o deshabilitar la compresión de datos ZStandard en bloques de datos de fila durante la transferencia de datos.
Teradata QueryGrid está preconfigurado con una directiva de comunicación con compresión habilitada (Compresión) y otra sin compresión habilitada (Sin compresión).
Las directivas de comunicación no son necesariamente específicas de los sistemas involucrados, por lo que puede reutilizarlos.
- Asignaciones de usuarios (opcional).
Las asignaciones de usuarios permiten a un usuario que inició sesión en el sistema de inicio enviar consultas como un usuario específico en el sistema de destino. Es posible asignar varios usuarios del sistema de inicio a un único usuario del sistema de destino, si corresponde, pero no se pueden asignar varios usuarios del sistema de destino a un único usuario del sistema de inicio.
En el portlet QueryGrid, puede asignar nombres de usuario de un origen de datos a nombres de usuario de otro origen de datos.
Cuando se utiliza el conector de destino de Hive, Presto o Spark sin seguridad, normalmente se requiere la asignación de usuarios. Por ejemplo, si el usuario Joe inicia una consulta con un enlace de Teradata a Hive, Teradata cambia automáticamente el nombre de usuario a mayúsculas y envía la consulta como usuario JOE de manera predeterminada al sistema de destino. A continuación, se muestran los resultados posibles para este caso de uso cuando no se utiliza ninguna seguridad con un conector de destino de Hive:Escenario Requisito El usuario "JOE" no existe en el sistema de destino Las consultas deben ejecutarse con un usuario existente en el sistema de destino, como "hive". En este escenario, se requiere la asignación de usuario, donde "JOE" en el sistema de Teradata se asigna al "hive" del usuario en el sistema Hive de destino. Existe en el sistema de destino como joe La asignación de usuarios es necesaria cuando "JOE" en el sistema de Teradata se asigna a "joe" en el sistema de Hive de destino. Existe en el destino como "JOE" En este escenario no es necesaria la asignación de usuarios. Cuando se utiliza una plataforma de seguridad como Kerberos, la asignación de usuario no es necesaria cuando se utiliza un conector de destino de Hive, Presto o Spark.
- Habilitar o deshabilitar las confirmaciones. Las confirmaciones permiten a QueryGrid restablecer las conexiones que se rompen debido a errores de red transitorios. Si las consultas fallan debido a errores de red, esta opción se puede habilitar, si bien generará algo más de sobrecarga de mensajes.