Almacenamiento en caché de fragmentos de resultados de Spark - Amazon EMR

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Almacenamiento en caché de fragmentos de resultados de Spark

La versión 6.6.0 y posteriores de Amazon EMR incluyen la característica opcional Almacenamiento en caché de fragmentos de resultados de Spark, que almacena en caché automáticamente los fragmentos de resultados. Estos fragmentos de resultados forman parte de los resultados de subárboles de consultas que se almacenan en el bucket de Amazon S3 que elija. Los fragmentos de resultados de las consultas almacenados se reutilizan en las siguientes ejecuciones de consultas, lo que se traduce en consultas más rápidas.

El Almacenamiento en caché de fragmentos de resultados analiza las consultas de Spark SQL y almacena en caché los fragmentos de resultados aptos en la ubicación de S3 que especifique. En las siguientes ejecuciones de consultas, los fragmentos de resultados de consultas que se pueden utilizar se detectan automáticamente y se recuperan de S3. El Almacenamiento en caché de fragmentos de resultados es diferente del almacenamiento en caché de conjuntos de resultados, en el que las consultas posteriores tienen que coincidir exactamente con la consulta original para obtener resultados de la caché. Cuando se utiliza para consultas que se dirigen repetidamente a un subconjunto estático de los datos, el Almacenamiento en caché de fragmentos de resultados acelera considerablemente el rendimiento.

Considere la siguiente consulta, que cuenta los pedidos hasta el año 2022:

select l_returnflag, l_linestatus, count(*) as count_order from lineitem where l_shipdate <= current_date and year(l_shipdate) == '2022' group by l_returnflag, l_linestatus

A medida que pasa el tiempo, esta consulta debe ejecutarse todos los días para informar sobre las ventas totales del año. Sin el Almacenamiento en caché de fragmentos de resultados, los resultados de todos los días del año deberán volver a calcularse todos los días. La consulta se volverá más lenta con el tiempo y será más lenta al final del año, cuando sea necesario volver a calcular los 365 días de resultados.

Al activar el Almacenamiento en caché de fragmentos de resultados, se utilizan los resultados de todos los días anteriores del año guardados en la caché. Cada día, la característica debe volver a calcular los resultados de un solo día. Una vez que la característica calcula el fragmento de resultados, lo almacena en caché. Como resultado, los tiempos de consultas con la caché habilitada son rápidos y constantes para cada consulta posterior.

Habilitación del Almacenamiento en caché de fragmentos de resultados de Spark

Para habilitar el Almacenamiento en caché de fragmentos de resultados de Spark, lleve a cabo los siguientes pasos:

  1. Cree un bucket de caché en Amazon S3 y autorice el acceso de lectura o escritura a EMRFS. Para obtener más información, consulte Autorización de acceso a los datos de EMRFS en Amazon S3.

  2. Establezca la configuración de Spark de Amazon EMR para habilitar la característica.

    spark.subResultCache.enabled = true spark.subResultCache.fs.root.path = s3://DOC-EXAMPLE-BUCKET/cache_dir/
  3. Habilite la administración del ciclo de vida de S3 para que el bucket limpie automáticamente los archivos de caché.

  4. Si lo desea, configure las maxBufferSize propiedades reductionRationThreshold y para ajustar aún más la función.

    spark.sql.subResultCache.reductionRatioThreshold spark.sql.subResultCache.maxBufferSize

Consideraciones al utilizar el Almacenamiento en caché de fragmentos de resultados

El ahorro de costos al utilizar los resultados ya almacenados en caché en Amazon S3 en lugar de volver a calcularlos aumenta con el número de veces que se pueden utilizar los mismos resultados almacenados en caché. Las consultas con análisis de tablas de gran tamaño seguidas de filtros o agregaciones de hash que reduzcan el tamaño de los resultados en un factor mínimo de 8 (es decir, una proporción de al menos 8:1 entre tamaño de entrada y resultados) son las que más se beneficiarán de esta característica. Cuanto mayor sea la proporción de reducción entre la entrada y los resultados, mayor será la relación entre costos y beneficios. Las consultas con proporciones de reducción más bajas, pero que contengan pasos costosos de computación entre el análisis de la tabla y el filtro o las agregaciones, también se beneficiarán, siempre que el costo de producir los resultados sea mayor que el costo de obtenerlos de Amazon S3. De forma predeterminada, el Almacenamiento en caché de fragmentos de resultados solo se aplica cuando detecta que la proporción de reducción será de al menos 8:1.

Cuando las consultas reutilizan repetidamente los resultados almacenados en caché, las ventajas de esta característica son mayores. Las consultas en intervalos continuos e incrementales son buenos ejemplos. Por ejemplo, una consulta continua de 30 días que ya se haya ejecutado durante 29 días solo necesitaría extraer una trigésima parte de los datos de destino de su origen de entrada original y utilizaría fragmentos de resultados almacenados en caché de los 29 días anteriores. Una consulta de intervalo incremental se beneficia aún más, ya que el inicio del intervalo permanece fijo: cada vez que se invoca la consulta, un porcentaje menor del procesamiento requerirá la lectura del origen de entrada.

A continuación se indican algunas consideraciones adicionales a la hora de utilizar el Almacenamiento en caché de fragmentos de resultados:

  • Las consultas que no se dirijan a los mismos datos con los mismos fragmentos de consulta tendrán una tasa de aciertos de caché baja, por lo que no se beneficiarán de esta característica.

  • Las consultas con proporciones de reducción bajas que no contengan pasos de computación costosos darán como resultado resultados almacenados en caché que son aproximadamente tan caros de leer como de procesar inicialmente.

  • La primera consulta siempre mostrará una regresión menor debido al costo de escribir en la caché.

  • La característica Almacenamiento en caché de fragmentos de resultados funciona exclusivamente con archivos Parquet. No se admite ningún otro formato de archivo.

  • Los búferes de la característica Almacenamiento en caché de fragmentos de resultados solo intentarán almacenar en caché los análisis con tamaños de división de archivos de 128 MB o más. Con la configuración predeterminada de Spark, el Almacenamiento en caché de fragmentos de resultados se deshabilitará si el tamaño del análisis (el tamaño total de todos los archivos que se analizan) dividido por el número de núcleos ejecutores es inferior a 128 MB. Cuando se establezca alguna de las configuraciones de Spark que se enumeran a continuación, el tamaño de división de archivos será:

    min(maxPartitionBytes, max(openCostInBytes, scan size / minPartitionNum))
    • spark.sql. leafNodeDefaultParalelismo (el valor predeterminado es spark.default.parallelism)

    • spark.sql.files. minPartitionNum (el valor predeterminado es spark.sql. leafNodeDefaultParalelismo)

    • spark.sql.files. openCostInBytes

    • spark.sql.files. maxPartitionBytes

  • La característica Almacenamiento en caché de fragmentos de resultados almacena en caché según la granularidad de la partición de RDD. La proporción de reducción descrita anteriormente, que de forma predeterminada es 8:1, se evalúa por partición de RDD. Las cargas de trabajo con proporciones de reducción por RDD superiores e inferiores a 8:1 pueden obtener menores ventajas de rendimiento que las cargas de trabajo con proporciones de reducción por RDD que son sistemáticamente inferiores a 8:1.

  • La característica Almacenamiento en caché de fragmentos de resultados utiliza un búfer de escritura de 16 MB de forma predeterminada para cada partición de RDD que se almacena en caché. Si se van a almacenar en caché más de 16 MB por partición de RDD, el costo de determinar que no es posible realizar una escritura puede provocar una regresión del rendimiento.

  • Si bien de forma predeterminada el Almacenamiento en caché de fragmentos de resultados no intentará almacenar en caché los resultados de las particiones de RDD con una proporción de reducción inferior a 8:1 y limitará su búfer de escritura a 16 MB, ambos valores se pueden ajustar mediante las siguientes configuraciones:

    spark.sql.subResultCache.reductionRatioThreshold (default: 8.0) spark.sql.subResultCache.maxBufferSize (default: 16MB, max: 64MB)
  • Varios clústeres que utilizan la misma versión de Amazon EMR pueden compartir la misma ubicación de caché. Para garantizar la exactitud de los resultados, el Almacenamiento en caché de fragmentos de resultados no utilizará los resultados almacenados en caché escritos por distintas versiones de Amazon EMR.

  • El almacenamiento en caché de fragmentos de resultados se desactivará automáticamente en los casos de uso de Spark Streaming o cuando se RecordServer utilice Apache Ranger o AWS Lake Formation se utilice.

  • Las lecturas o escrituras del Almacenamiento en caché de fragmentos de resultados utilizan buckets de EMRFS y Amazon S3. Se admite el cifrado CSE, SSE S3 y SSE KMS.