Organizar conjuntos de datos a lo largo de las canalizaciones de Lakeflow

Utiliza pipelines Lakeflow para procesar desde uno hasta cientos de conjuntos de datos en una sola pipeline. Decide qué conjuntos de datos deben estar juntos según el dominio, la cadencia y las dependencias, y divide el trabajo en pipelines separados cuando la propiedad, latencia o escala difieran.

Overview

Una decisión que nunca surge en un tutorial cobra importancia en despliegues reales: ¿qué tablas deben agruparse en la misma canalización y cuándo debe algo ir en una canalización independiente? Equivocarse en esto es una de las formas más comunes de que los equipos se metan en un callejón sin salida. El modo clásico de fallo consiste en meter todo en una sola canalización gigante y luego enfrentarse a problemas de escalado, concurrencia y radio de explosión que resultan dolorosos de resolver.

No hay una única respuesta correcta, pero sí fuerzas claras que tiran en cada dirección y hay una restricción dura que merece la pena conocer antes de diseñar.

Guidelines

Agrupa los conjuntos de datos por dominio, cadencia compartida y dependencia, y divídelos en los límites de propiedad, capa y latencia. Mantén el número de conjuntos de datos que pueden actualizarse de forma independiente en cada proceso holgadamente por debajo del límite de actualizaciones en paralelo.

Conoce el límite de concurrencia antes de diseñar

Una única actualización desencadenada de una canalización ejecuta un máximo de 16 actualizaciones de conjunto de datos en paralelo. Esta es la sorpresa más común para los equipos que lo ponen todo en un solo flujo de trabajo: una vez que tienes más de aproximadamente 16 conjuntos de datos que, de otro modo, podrían ejecutarse de forma simultánea, los adicionales quedan en cola detrás de los primeros 16 en lugar de ejecutarse en paralelo, por lo que el tiempo total de actualización se alarga aunque haya capacidad de cómputo disponible. Si tienes decenas de conjuntos de datos independientes y te importa el tiempo real de actualización, eso por sí solo es motivo suficiente para no agruparlos todos en una sola canalización.

Qué pertenece a la misma canalización

Mantén los conjuntos de datos juntos cuando compartan estructura o programación:

  • Conjuntos de datos que forman una cadena de dependencias o un dominio lógico, como las tablas de bronce, plata y oro para órdenes. Mantener unido un grafo acíclico dirigido (DAG) conectado permite que el pipeline lo programe, cree puntos de control y lo actualice por completo como una unidad coherente, y hace que el linaje sea más legible. Consulte Cargue y procese datos de forma incremental con flujos de Lakeflow Pipelines.
  • Conjuntos de datos que comparten el mismo requisito de actualización y la misma frecuencia de ejecución, como elementos que deben actualizarse juntos, con el mismo desencadenante y dentro de la misma transacción.
  • Conjuntos de datos lo suficientemente pequeños en conjunto como para que todo el gráfico quede cómodamente bajo el techo de actualización paralela y se actualice en un tiempo aceptable.

¿Qué pertenece a una tubería separada?

Separar conjuntos de datos cuando difieren en propiedad, capa o latencia:

  • Diferentes dominios o equipos. La titularidad independiente normalmente debería significar canalizaciones independientes, para que el cambio o fallo de un equipo no bloquee el de otro.
  • Capas que quieres escalar o programar de forma independiente. Una división ampliamente recomendada consiste en separar la ingestión (bronce) de la transformación (plata y oro) en canalizaciones independientes, para que un proceso de ingestión lento o fallido no ralentice la transformación y cada una pueda dimensionar los recursos de cómputo según sus propias necesidades.
  • Diferentes perfiles de latencia. Una transmisión continua y de baja latencia no debería compartir una canalización con una agregación por lotes diaria. Consulte Desencadenado frente al modo de canalización continua.
  • Conjuntos de datos que te empujan más allá del límite de actualizaciones paralelas y que, de otro modo, harían cola.

Para ejecutar un conjunto de conjuntos de datos de forma aislada, consideremos una tubería independiente. Consulta Oleoductos independientes vs. oleoductos de flujo de lago.

Una regla práctica

No use por defecto una sola canalización monolítica y tampoco fragmente cada tabla en su propia canalización. Agrupe por dominio + cadencia compartida + dependencia, divide por los límites de titularidad, capa y latencia, y mantén el número de conjuntos de datos que pueden actualizarse de forma independiente en cualquier canalización muy por debajo del límite de actualizaciones en paralelo. En caso de duda, es preferible optar por un puñado de canalizaciones de tamaño medio alineadas con los dominios en lugar de una sola canalización gigantesca. Es mucho más fácil fusionar dos pequeñas canalizaciones más tarde que dividir un monolito que ya está en producción.

Limitations

  • Una única actualización desencadenada ejecuta como máximo 16 actualizaciones de conjunto de datos en paralelo. Los conjuntos de datos que superan ese límite hacen cola en lugar de ejecutarse simultáneamente, por lo que una pipeline con decenas de conjuntos de datos independientes puede tardar más en actualizarse incluso cuando hay computación disponible.
  • Dividirlo en varias canalizaciones supone perder parte de la visibilidad de extremo a extremo. Cuando lo divida, apóyese en las tablas del sistema (system.lakeflow.pipelines, system.lakeflow.job_run_timeline) y orqueste las distintas partes con un trabajo de Lakeflow para seguir teniendo una única visión integral de todo el flujo de principio a fin. Consulte Ejecutar canalizaciones en un flujo de trabajo.

Recursos adicionales

  • Se actualizó por última vez el