Acerca de la búsqueda de linaje multirregional

Cuando administras datos en una organización compleja, comprender su linaje es fundamental para una buena administración de datos y una administración eficaz de los datos en la nube. En esta guía, se explica cómo usar la búsqueda en varias regiones en Knowledge Catalog (anteriormente, Dataplex Universal Catalog) para hacer un seguimiento de tus datos en diferentes límites geográficos.

De forma predeterminada, el linaje de datos en Knowledge Catalog es un servicio regional. Cada vez que tus datos se mueven o transformen, los datos de linaje resultantes, como vínculos, procesos y eventos, se almacenan en la región específica en la que se produjo esa acción.

Sin embargo, las canalizaciones de datos del mundo real suelen abarcar varios Google Cloud proyectos y regiones. Por ejemplo, es posible que tengas una tabla de BigQuery en us-central1 que copie datos a un bucket de almacenamiento en europe-west1. Para rastrear tus activos de datos a través de estos límites y crear gráficos de linaje completos, debes realizar una búsqueda en varias regiones.

Knowledge Catalog te ofrece dos formas de descubrir y conectar estos gráficos de linaje entre regiones:

  • El método de automatización del servidor que usa la API de searchLineageStreaming (versión preliminar): Recomendado
  • El método de fan-out del cliente que usa la API de searchLinks

Para comprender el descubrimiento del linaje en varias regiones, es útil saber cómo el sistema controla el recorrido del gráfico:

  • Criterios raíz: Es el punto de partida de tu búsqueda de linaje, definido por uno o más nombres de recursos (como una tabla de BigQuery o un tema de Pub/Sub) o campos de columnas detallados.

  • Dirección: Es la orientación del recorrido del gráfico en relación con los criterios raíz. Puedes buscar el origen (para ver de dónde provienen tus datos) o el destino (para ver a dónde van).

  • Búsqueda en amplitud: Es el mecanismo arquitectónico que se usa para encontrar nodos conectados. La búsqueda recorre el gráfico de linaje capa por capa y calcula con precisión la profundidad de ejecución de cada recurso conectado en los límites regionales.

¿Cómo se comparan los métodos de búsqueda en varias regiones?

Si bien ambos métodos te permiten armar una vista interregional de tus datos, se encargan del trabajo pesado de manera diferente:

Función Automatización del servidor
API de searchLineageStreaming		 Fan-out del cliente
API de searchLinks
Modelo de ejecución Automatización del servidor: El motor de enrutamiento Google Cloud recorre varias regiones de forma nativa. Orquestación del cliente: La secuencia de comandos de tu aplicación debe realizar un bucle y administrar las solicitudes de forma manual.
Sobrecarga de la solicitud Solicitud a la API única: Una sola llamada POST HTTP inicia la búsqueda en varias regiones. Varias solicitudes a la API: Requiere una llamada HTTP separada para cada región y cada capa de gráfico.
Control de respuestas Transmisión en tiempo real: Los resultados se envían al cliente a medida que se encuentran, lo que evita los tiempos de espera. Cargas útiles estáticas: Los arrays JSON individuales se deben recibir, recopilar y combinar de forma manual.
Gráficos profundos (más de 2 capas) Maneja automáticamente gráficos de linaje anidados y profundos de hasta 100 niveles. Sufre el problema de la consulta N+1 y requiere viajes de ida y vuelta iterativos y lentos desde el cliente.

Elige el método de búsqueda en varias regiones adecuado

Revisa las siguientes situaciones para determinar qué método de búsqueda en varias regiones se adapta mejor a tu carga de trabajo.

Elige el método de la API de transmisión para los siguientes casos de uso:

  • Realizar un seguimiento de gráficos complejos o profundos: Tus datos se mueven a través de varias tablas, buckets o canalizaciones intermedias en diferentes regiones, lo que requiere un recorrido de varios niveles (maxDepth mayor que 2).

  • Hacer un seguimiento del linaje a nivel de columna: Deseas hacer un seguimiento de los campos en todas las regiones o aprovechar las búsquedas con comodines (*) para extraer todas las dependencias de columnas a la vez.

  • Mantener un código ligero: Prefieres realizar una sola llamada a la API y dejar queGoogle Cloud controle el enrutamiento, la deduplicación y el ensamblaje del gráfico.

  • Solicitar metadatos de la canalización: Deseas recuperar de forma opcional detalles estructurales sobre los procesos que ejecutan tus canalizaciones en la misma carga útil de la solicitud.

Elige el método de fan-out del cliente para las siguientes situaciones:

  • Solo realizas un seguimiento del linaje superficial de un solo salto: Tu gráfico de linaje no es complejo y solo necesitas buscar vínculos directos de elementos superiores o secundarios (maxDepth igual a 1) en una pequeña cantidad fija de regiones conocidas.

  • Trabajas en sistemas heredados estrictos: Tienes una aplicación de administración de datos existente que se basa en gran medida en el extremo SearchLinks estándar y deseas mantener la compatibilidad estructural con versiones anteriores sin implementar consumidores de respuestas de transmisión.

¿Qué sigue?