Presentation is loading. Please wait.

Presentation is loading. Please wait.

Inter-process Communication in Hadoop

Similar presentations

Presentation on theme: "Inter-process Communication in Hadoop"— Presentation transcript:

1 Inter-process Communication in Hadoop

2 Different types of network interactions found in Hadoop (source Cloudera)
1. Hadoop RPC calls – These are performed by clients using the Hadoop API, by MapReduce jobs, and among Hadoop services (JobTracker, TaskTrackers, NameNodes, DataNodes). 2. HDFS data transfer – Done when reading or writing data to HDFS, by clients using Hadoop API, by MapReduce jobs and among Hadoop services. HDFS data transfers are done using TCP/IP sockets directly. 3. MapReduce Shuffle – The shuffle part of a MapReduce job is the process of transferring data from the Map tasks to Reducer tasks. As this transfer is typically between different nodes in the cluster, the shuffle is done using the HTTP protocol. 4. Web UIs – The Hadoop daemons provide Web UIs for users and administrators to monitor jobs and the status of the cluster. The Web UIs use the HTTP protocol. 5. FSImage operations – These are metadata transfers between the NameNode and the Secondary NameNode. They are done using the HTTP protocol. This means that Hadoop uses three different network communication protocols: ---Hadoop RPC, Direct TCP/IP, HTTP

3 IPC in Hadoop Distributed System
IPC: Inter-process communication Based on: Using Hadoop IPC/RPC for distributed applications, by Kelvin Tan Hadoop IPC is the underlying mechanism is used whenever there is a need for out-of-process applications to communicate with one another.

4 Hadoop IPC Hadoop IPC 1. uses binary serialization using and, unlike SOAP or XML-RPC. 2. is a simple low-fuss RPC mechanism. 3. is unicast does not support multi-cast. Why use Hadoop IPC over RMI or RMI: Remote method invocation RPC: Remote Procedure Call

5 Server code Configuration conf = new Configuration(); Server server = RPC.getServer(this, "localhost", 16000, conf); // start a server on localhost:16000 server.start();

6 Client code Configuration conf = new Configuration(); InetSocketAddress addr = new InetSocketAddress("localhost",16000); // the server's inetsocketaddress ClientProtocol client = (ClientProtocol) RPC.waitForProxy(ClientProtocol.class, ClientProtocol.versionID, addr, conf);

7 ClientProtocol Interface
interface ClientProtocol extends org.apache.hadoop.ipc.VersionedProtocol { public static final long versionID = 1L; HeartbeatResponse heartbeat(); } Note: HeartbeatReponse is a class

8 HeartbeatResponse public class HeartbeatResponse implements { String status; public void write(DataOutput out) throws IOException { UTF8.writeString(out, status); } public void readFields(DataInput in) throws IOException { this.status = UTF8.readString(in);

9 Summary 1. A server which implements an interface (which itself extends VersionedProtocol) 2. 1 or more clients which call the interface methods. 3. Any method arguments or objects returned by methods must implement Learn about RPC, RMI, …TCP/IP, .. SOAP, REST… Also see ;)

10 Now to answer Troy’s and Saurab’s questions:
Output of mapper is buffered When the buffer is 80% full it is transferred to “local file system” (spill files) not to HDFS …no need… no need for replication. It is after all local… “The map outputs are copied to the reduce tasktracker’s memory if they are small enough (the buffer’s size is controlled by mapred.job.shuffle.input.buffer.percent, which specifies the proportion of the heap to use for this purpose); otherwise, they are copied to disk. …”, T.White, Hadoop Definitive Guide So the question is: How will you design/decide the size of the input split to the mapper? How many mappers? Memory(RAM) size/heapsize, bandwidth between machines are important

11 There was a question about partitioner
Here is the code: public interface Partitioner<K, V> extends JobConfigurable { int getPartition(K key, V value, int numPartitions); } Return value is the partition # , that is the reducer#

12 #Mapper X #Reducer times
Hadoop Task flow Map Partition Combine Shuffle Reduce Copy #Mapper X #Reducer times Buffer/Cache HDFS HDFS Local Disk What sort could the partiton, shuffle use?

13 Improvements? parameters to tune in are:
io.sort.mb This is the output buffer of a mapper. When this buffer is full the data is sorted and spilled to disk. Ideally you avoid having to many spills. Note that this memory is part of the maptask heap size. This is the heap size of a map task, the higher this is the higher you can put output buffer size. In principle the number of reduce tasks also influences the shuffle speed. The number of reduce rounds is the total number of reduce slots / the number of reduce tasks. Note that the initial shuffle (during the map phase) will only shuffle data to the active reducers. So mapred.reduce.tasks is also relevant. io.sort.factor is the number threads performing the merge sort, both on the map and the reduce side. Compression also has a large impact (it speeds up the transfer from mapper to reducer but the compr/decompr comes at a cost! mapred.job.shuffle.input.buffer.percent is the percentage of the reducer's heap to store map output in memory.

14 More info Increasing the sort buffer memory and the performance gain from that will depend on: a)The size/total Number of the Keys being emitted by the mapper b) The Nature of the Mapper Tasks : (IO intensive, CPU intensive) c) Available Primary Memory, Map/Reduce Slots in the given Node d) Data skewness

Download ppt "Inter-process Communication in Hadoop"

Similar presentations

Ads by Google