apache-spark - examples - apache spark wikipedia

Mind blown: método RDD.zip()

Question

Acabo de discovered el método RDD.zip() y no puedo imaginar cuál podría ser su contract .

Entiendo lo que hace , por supuesto. Sin embargo, siempre he entendido que

• el orden de los elementos en un RDD es un concepto sin sentido
• el número de particiones y sus tamaños es un detalle de implementación solo disponible para el usuario para la optimización del rendimiento

En otras palabras, un RDD es un (multi) conjunto , no una secuencia (y, por supuesto, en, por ejemplo, Python se obtiene AttributeError: ''set'' object has no attribute ''zip'' )

¿Qué está mal con mi comprensión anterior?

¿Cuál fue la razón detrás de este método?

¿Es legal fuera del contexto trivial como a.map(f).zip(a) ?

EDIT 1:

• Otro método loco es zipWithIndex() , así como también las diversas variantes de zipPartitions() .
• Tenga en cuenta que first() y take() no están locos porque son muestras justas (no aleatorias) del RDD.
• collect() también está bien, simplemente convierte un set en una sequence que es perfectamente legítima.

EDIT 2: La reply dice:

cuando calcula un RDD de otro, el orden de los elementos en el nuevo RDD puede no corresponderse con el del anterior.

Esto parece implicar que incluso el trivial a.map(f).zip(a) no se garantiza que sea equivalente a a.map(x => (f(x),x)) . ¿Cuál es la situación cuando los resultados de zip() son reproducibles ?

Answer 1

El modelo mental que uso (y recomiendo) es que los elementos de un RDD están ordenados, pero cuando se computa un RDD de otro, el orden de los elementos en el nuevo RDD puede no corresponderse con el del anterior.

Para aquellos que quieran estar al tanto de las particiones, diría que:

1. Las particiones de un RDD tienen un orden.
2. Los elementos dentro de una partición tienen un orden.
3. Si piensas en "concatenar" las particiones (digamos "ponerlas de punta a punta" en orden) usando el orden de los elementos dentro de ellas, el orden general que termines corresponde al orden de los elementos si ignoras las particiones.

Pero, de nuevo, si calcula un RDD de otro, todas las apuestas sobre las relaciones de orden de los dos RDD están desactivadas.

Varios miembros de la clase RDD (me refiero a la API de Scala) sugieren fuertemente un concepto de orden (como lo hace su documentación) :

collect()
first()
partitions
take()
zipWithIndex()

al igual que Partition.index así como SparkContext.parallelize() y SparkContext.makeRDD() (que ambos toman una Seq[T] ).

En mi experiencia, estas formas de "observar" el orden dan resultados consistentes entre sí, y las que se traducen entre los RDD y las colecciones de Scala ordenadas se comportan como es de esperar: conservan el orden general de los elementos. Es por eso que digo que, en la práctica, los RDD tienen un concepto de orden significativo.

Además, aunque obviamente hay muchas situaciones en las que el cálculo de un RDD de otro debe cambiar el orden, en mi experiencia el orden tiende a conservarse donde sea posible / razonable hacerlo. Las operaciones que no se redistribuyen y no cambian fundamentalmente el conjunto de elementos tienden a preservar el orden.

Pero esto me lleva a su pregunta sobre "contrato", y de hecho la documentación tiene un problema en este sentido. No he visto un solo lugar donde el efecto de una operación sobre el orden de los elementos quede claro. (La clase OrderedRDDFunctions no cuenta, porque se refiere a un orden basado en los datos, que puede diferir del orden en bruto de los elementos dentro del RDD. Del mismo modo que la clase RangePartitioner ). Puedo ver cómo esto podría llevarlo a concluir que no hay ningún concepto de orden de elementos, pero los ejemplos que he dado arriba hacen que ese modelo me resulte insatisfactorio.

Answer 2

No es cierto que los RDD siempre estén desordenados. Un RDD tiene un orden garantizado si es el resultado de una operación de sortBy , por ejemplo. Un RDD no es un conjunto; puede contener duplicados. El particionamiento no es opaco para el que llama, y ​​puede controlarse y consultarse. Muchas operaciones conservan la partición y el orden, como el map . Dicho esto, me resulta un poco fácil violar accidentalmente las suposiciones de las que depende zip , ya que son un poco sutiles, pero ciertamente tienen un propósito.