2011-12-10 10 views
6

¿Es posible obtener lecturas distribuidas del clúster HDSF utilizando un cliente HDFS en una máquina?Lecturas distribuidas de HDFS sin Map/Reducir

He llevado a cabo un experimento con un clúster que consta de 3 nodos de datos (DN1, DN2, DN3). Luego, ejecuté 10 lecturas simultáneas de 10 archivos independientes de un programa cliente ubicado en DN1, y parecía estar solo leyendo datos de DN1. Otros nodos de datos (DN2, DN3) mostraron actividad cero (a juzgar por los registros de depuración).

He comprobado que todos los bloques de archivos están replicados en los 3 nodos de datos, por lo que si apago DN1, los datos se leerán desde DN2 (solo DN2).

Aumentar la cantidad de datos leídos no ayudó (intenté desde 2 GB a 30 GB).

Dado que tengo la necesidad de leer varios archivos grandes y extraer solo una pequeña cantidad de datos (unos pocos Kb), me gustaría evitar el uso de map/reduce ya que requiere configurar más servicios y también requiere escribir el salida de cada tarea dividida a HDFS. Más bien, sería bueno tener el resultado transmitido directamente a mi programa cliente desde los nodos de datos.

estoy usando SequenceFile para los datos de lectura/escritura, de esta manera (JDK7):

//Run in thread pool on multiple files simultaneously 

List<String> result = new ArrayList<>(); 
LongWritable key = new LongWritable(); 
Text value = new Text(); 
try(SequenceFile.Reader reader = new SequenceFile.Reader(conf, 
            SequenceFile.Reader.file(filePath)){ 
    reader.next(key); 
    if(key.get() == ID_I_AM_LOOKING_FOR){ 
    reader.getCurrentValue(value); 
    result.add(value.toString()); 
    } 
} 

return result; //results from multiple workers are merged later 

Cualquier ayuda apreciada. ¡Gracias!

Respuesta

7

Me temo que el comportamiento que ves es por diseño. De Hadoop document:

Réplica Selección

Para reducir al mínimo el consumo mundial de ancho de banda y latencia de lectura, HDFS intenta para satisfacer una petición de lectura de una réplica que es más cercano al lector . Si existe una réplica en el mismo bastidor que el nodo lector, , se prefiere esa réplica para satisfacer la solicitud de lectura. Si angg/ clúster HDFS abarca varios centros de datos, una réplica que es residente en el centro de datos local es preferible a cualquier réplica remota .

se puede confirmar aún más por los correspondientes Hadoop source code:

LocatedBlocks getBlockLocations(...) { 
    LocatedBlocks blocks = getBlockLocations(src, offset, length, true, true); 
    if (blocks != null) { 
     //sort the blocks 
     DatanodeDescriptor client = host2DataNodeMap.getDatanodeByHost(
      clientMachine); 
     for (LocatedBlock b : blocks.getLocatedBlocks()) { 
     clusterMap.pseudoSortByDistance(client, b.getLocations()); 

     // Move decommissioned datanodes to the bottom 
     Arrays.sort(b.getLocations(), DFSUtil.DECOM_COMPARATOR); 
     } 
    } 
    return blocks; 
    } 

es decir, todas las réplicas disponibles son juzgados, uno tras otro, si uno falla antigua pero la más cercana es siempre la primera.

Por otro lado, si accede a los archivos HDFS a través de HDFS Proxy, selecciona los nodos de datos randomly. Pero no creo que eso es lo que quieres.

+0

Gracias. ¡Eso lo explica! Gracias por el consejo proxy. – rodion

+1

¿Cómo sabe Hadoop qué nodo está en qué rack? Http://hadoop.apache.org/common/docs/current/cluster_setup.html#Hadoop+Rack+Awareness –

+0

¿Qué es "angg"? –

3

Además de lo que dijo Edwardw, tenga en cuenta que su clúster actual es muy pequeño (solo 3 nodos) y en este caso verá los archivos en todos los nodos. Esto sucede porque el factor de replicación predeterminado de Hadoop también es 3. En un clúster más grande, sus archivos no estarán disponibles en cada nodo y, por lo tanto, es probable que el acceso a múltiples archivos vaya a diferentes nodos y distribuya la carga.

Si se trabaja con conjuntos de datos más pequeños es posible que desee ver en HBase, que le permite trabajar con trozos más pequeños y distribuir la carga entre los nodos (por regiones partiendo)

+0

Tienes razón. De hecho, he intentado configurar la replicación en 1 para distribuir bloques de manera uniforme en el clúster, pero acabó escribiéndolos todos en DN1: ((supongo que necesito más datos y bloques antes de que comience a equilibrarlos en diferentes nodos). Gracias por el consejo de HBase, puedo tomar prestadas algunas ideas de allí. – rodion

0

yo le diría que su caso suena bien para MR. Si dejamos de lado el paradigma computacional de MR, podemos decir que hadoop está diseñado para llevar código a los datos, en lugar de opuesto. Mover el código a los datos es esencial para obtener un procesamiento de datos escalable.
Por otro lado, la configuración de MapReduce es más fácil que HDFS, ya que no almacena ningún estado entre trabajos.
Al mismo tiempo, MR framework se preocupará por el procesamiento paralelo para usted, algo que tomará tiempo para hacerlo correctamente.
Otro punto, si los resultados del procesamiento de datos son tan pequeños, no habrá un impacto significativo en el rendimiento si los combina en un reductor.
En otras palabras, sugeriría reconsiderar el uso de MapReduce.

+0

Gracias. Voy a necesitar algunas pruebas de rendimiento allí :) – rodion

+0

Si me das alguna información, trataré de hacerlo con las estimaciones. –

+0

Gracias. Es bastante simple, básicamente una búsqueda similar a grep en archivos grandes de datos de registro. Los datos de registro pueden ser de contenido arbitrario. Tengo dos tipos de búsqueda: 1) coincidencia de subcadenas/expresiones regulares similar al grep en el contenido 2) búsqueda de un registro conocido posición (posiciones/identificadores se almacenan por separado) y simplemente obtener el contenido. Puede suponer que el conjunto de resultados siempre será pequeño: 0 ~ 100 registros. También estoy usando la compresión de bloques (usando la API 'SequenceFile'). – rodion

Cuestiones relacionadas