¿Son DataFrames el futuro de Spark?

Conjuntos de datos Será el futuro de Spark.

Debería pensar en Datasets como una extensión de la API DataFrame existente pero con dos cosas adicionales: seguridad de tipo y una interfaz de programación orientada a objetos .

Lo bueno de DataFrames es que están estructurados. Esto viene con muchos beneficios de rendimiento. Dado que las operaciones se expresan en columnas, el optimizador de consultas subyacente comprende cómo encontrar planes más eficientes para generar la misma respuesta. Además, la existencia de un esquema permite a Spark codificar filas en un formato compacto, lo que nos permite mezclar menos datos, omitir algunas serializaciones y disfrutar de una mejor ubicación de caché.

Por el contrario, los RDD expresan transformaciones en términos de código de usuario general, que es un cuadro negro completo para el motor de ejecución subyacente. Esto evita que Spark realice cualquiera de las optimizaciones posibles con DataFrames. Sin embargo, los RDD son estrictamente más potentes en el sentido de que puede expresar sus transformaciones con una programación imperativa, que puede ser más natural en ciertos casos.

Los conjuntos de datos combinan lo mejor de ambos mundos. La representación estructurada de datos le permite a Spark aprovechar todas las optimizaciones de rendimiento ofrecidas a DataFrames. Además, el uso de codificadores nos da seguridad de tipo, lo que a su vez hace posible el imperativo estilo de programación familiar para los usuarios de RDD.

Spark 2.0 (que se lanzará en junio de 2016) unifica estos tres conceptos. Los conjuntos de datos serán los predeterminados, aunque los DataFrames y los RDD seguirán estando disponibles para la compatibilidad con versiones anteriores.

Para obtener más detalles, lea nuestra publicación de blog Presentación de conjuntos de datos de Spark o vea la charla de Michael en Spark Summit East 2016:

Si bien no conozco los planes de DataBricks, solo puedo especular.
En mi opinión, DataFrames tiene ventajas de rendimiento inherentes sobre RDD. Los hace “futuros” independientemente de ML.
Por otro lado, los DataFrames son menos flexibles que RDD, por lo que no los reemplazarán por completo.

Espero que la historia sea entre MapReduce y Hive en cierta medida. MR es una especie de API de bajo nivel y flexible, mientras que Hive es un motor relacional. Por lo general, decidimos entre ellos de la siguiente manera: si podemos resolverlo con Hive, lo hacemos, si no, vamos por MapReduce de vainilla.
Espero que las personas usen DataFrames siempre que sea posible y obtengan conveniencia y velocidad, mientras que aún optarán por RDD cuando se necesite flexibilidad.

A2A

Al igual que David, no tengo ninguna idea especial sobre la dirección de Spark.

Los marcos de datos proporcionan algunas características adicionales muy agradables y hacen que trabajar con datos en los casos de uso habituales de tipo ETL sea significativamente más fácil. La falta de seguridad de tipos en tiempo de ejecución es bastante molesta y dificulta la escritura de código fuera de un entorno REPL. Pues nada es perfecto. También hay gastos generales al realizar operaciones en columnas, ya que necesita definir UDF. Como resultado, es poco probable que DataFrames reemplace los RDD, ya que cada uno es mejor para diferentes tipos de operaciones.

Puedo ver una fusión más cercana de RDD y DataFrames que proporciona una capacidad fácil de transición entre los dos según sea necesario para las operaciones.

Databricks ha estado cambiando continuamente la base de código de spark y, a partir de ahora, han introducido Datasets, que pretende ser el futuro de Spark. Están tratando de proporcionar todas las funcionalidades soportadas por RDD y Dataframes usando Datasets.

Los DataSets serán el futuro de Spark Data. DataFrames será solo un caso especial para DataSet en el futuro.

https://www.linkedin.com/pulse/r