Optimización de orígenes

En todos los orígenes, excepto Azure SQL Database, se recomienda mantener Use current partitioning (Usar particiones actuales) como valor seleccionado. Cuando leen desde el resto de los sistemas de origen, los flujos de datos crean automáticamente particiones de los datos en función de su tamaño. Se crea una nueva partición aproximadamente por cada 128 MB de datos. A medida que aumenta el tamaño de los datos, aumenta el número de particiones.

Las particiones personalizadas tienen lugar después de que Spark lee los datos y afectan negativamente al rendimiento del flujo de datos. Puesto que los datos se dividen en particiones uniformes durante la lectura, esta opción no se recomienda.

Nota

Las velocidades de lectura pueden verse limitadas por la capacidad de proceso del sistema de origen.

Orígenes de Azure SQL Database

Azure SQL Database tiene una opción única de creación de particiones denominada creación de particiones "de origen". Si se habilita esta opción, pueden mejorar los tiempos de lectura de Azure SQL DB, ya que se habilitan conexiones paralelas en el sistema de origen. Se especifica el número de particiones y cómo se crean particiones de los datos. Se usa una columna de partición con alta cardinalidad. También se puede escribir una consulta que coincida con el esquema de partición de la tabla de origen.

Sugerencia

En la creación de particiones de origen, la E/S de SQL Server es el cuello de botella. Si se agregan demasiadas particiones, se puede saturar la base de datos de origen. Normalmente, cuando se usa esta opción el número ideal de particiones es de cuatro o cinco.

Source partitioning

Nivel de aislamiento

El nivel de aislamiento de la lectura en un sistema de origen de Azure SQL afecta al rendimiento. La opción "Read uncommitted" (Lectura no confirmada) proporcionará el rendimiento más rápido y evitará bloqueos de base de datos. Para obtener más información acerca de los niveles de aislamiento de SQL, consulte Descripción de los niveles de aislamiento.

Lectura mediante consulta

Puede leer de Azure SQL Database mediante una tabla o una consulta SQL. Si está ejecutando una consulta SQL, esta debe finalizar antes de que se pueda iniciar la transformación. Las consultas SQL pueden resultar útiles para insertar operaciones que pueden ejecutarse más rápido y reducir la cantidad de datos que se leen de una instancia de SQL Server como las instrucciones SELECT, WHERE y JOIN. Cuando se insertan las operaciones, se pierde la capacidad de realizar un seguimiento del linaje y el rendimiento de las transformaciones antes de que los datos lleguen al flujo de datos.

Orígenes de Azure Synapse Analytics

Cuando se usa Azure Synapse Analytics, las opciones de origen incluyen un valor denominado Enable staging (Habilitar almacenamiento provisional). Esto permite que el servicio lea información de Synapse mediante procesos Staging que, a su vez, mejoran considerablemente el rendimiento de lectura mediante el uso de las capacidades de carga masiva con mayor rendimiento, como CETAS y el comando COPY. La habilitación de Staging requiere que especifique una ubicación de almacenamiento provisional de Azure Blob Storage o Azure Data Lake Storage Gen2 en la configuración de la actividad del flujo de datos.

Enable staging

Orígenes basados en archivos

Aunque los flujos de datos admiten una serie de tipos de archivo, se recomienda usar el formato Parquet nativo de Spark para conseguir tiempos óptimos de lectura y escritura.

Si está ejecutando el mismo flujo de datos en un conjunto de archivos, se recomienda leer de una carpeta, usar rutas de acceso con caracteres comodín o leer de una lista de archivos. Una sola ejecución de actividad de flujo de datos puede procesar todos los archivos por lotes. Puede encontrar más información sobre cómo establecer esta configuración en la sección Transformación de origen de la documentación sobre el conector de Azure Blob Storage.

Si es posible, evite usar la actividad For-Eeach para ejecutar flujos de datos en un conjunto de archivos. Esto haría que cada iteración de For-Each activase su propio clúster de Spark, lo que a menudo no suele ser necesario y puede resultar caro.

Pasos siguientes

Vea el resto de artículos sobre Data Flow relacionados con el rendimiento: