Pregunta ¿Es Spark zipWithIndex seguro con implementación paralela?


Si tengo un archivo e hice un RDD zipWithIndex por fila,

([row1, id1001, name, address], 0)
([row2, id1001, name, address], 1)
...
([row100000, id1001, name, address], 100000)

¿Podré obtener el mismo orden de índice si recargo el archivo? Dado que se ejecuta en paralelo, otras filas pueden dividirse de manera diferente?


5
2017-08-06 03:16


origen


Respuestas:


RDDs se pueden ordenar, y por lo tanto tienen un pedido. Este orden se utiliza para crear el índice con .zipWithIndex().

Para obtener el mismo pedido, cada vez depende de lo que estén haciendo las llamadas anteriores en su programa. Los doctores mencionan que .groupBy() Puede destruir el orden o generar diferentes ordenamientos. Puede haber otras llamadas que hacen esto también.

Supongo que siempre podrías llamar .sortBy() antes de llamar .zipWithIndex() Si necesita garantizar un pedido específico.

Esto se explica en el .zipWithIndex() scala API docs

public RDD<scala.Tuple2<T,Object>> zipWithIndex() Comprime este RDD con   sus índices de elementos. El orden se basa primero en la partición   índice y luego el orden de los elementos dentro de cada partición. Entonces el   El primer elemento de la primera partición obtiene el índice 0 y el último elemento de   La última partición recibe el índice más grande. Esto es similar a   El zipWithIndex de Scala, pero usa Long en lugar de Int como índice   tipo. Este método debe desencadenar un trabajo de chispa cuando este RDD contiene   más de una partición

Tenga en cuenta que algunos RDD, como los devueltos por groupBy (), no lo hacen   Garantizar el orden de los elementos en una partición. El índice asignado a cada   Por lo tanto, el elemento no está garantizado, e incluso puede cambiar si el RDD es   reevaluado Si se requiere un pedido fijo para garantizar el mismo   asignaciones de índice, debe ordenar el RDD con sortByKey () o guardarlo   a un archivo.


7
2017-08-06 03:24