3. What is Big Data?
Datasets that grow so large that they become
awkward to work with using on-hand database
management tools. Difficulties include
capture, storage, search, sharing, analytics,
and visualizing - Wikipedia
High volume of data (storage) + speed of data
(scale) + variety of data (diff types) - Gartner
4. World is ON = Content + Interactions = More Data
(Social and Mobile)
5. Tons of data is generated by each one of us!
(We moved from GB to ZB and from Millions to Zillions)
11. Why Cloud and Big Data?
Cloud has democratized access to large
scale infrastructure for masses!
You can store, process and manage big
data sets without worrying about IT!
**http://wiki.apache.org/hadoop/PoweredBy
21. Hadoop â Getting Started
âą Download latest stable version - http://hadoop.apache.org/common/releases.html
âą Install Java ( > 1.6.0_20 ) and set your JAVA_HOME
âą Install rsync and ssh
âą Follow instructions - http://hadoop.apache.org/common/docs/r0.20.2/quickstart.html
âą Hadoop Modes â Local, Pseudo-distributed and Fully distributed
âą Run in pseudo-distributed mode for your testing and development
âą Assign a decent jvm heapsize through mapred.child.java.opts if you
notice task errors or GC overhead or OOM
âą Play with samples â WordCount, TeraSort etc
âą Good for learning - http://www.cloudera.com/hadoop-training-virtual-machine
22. Why Amazon EMR?
I am interested in using Hadoop
to solve problems and not in
building and managing Hadoop
Infrastructure!
23. Amazon EMR â Setup
âą Install Ruby 1.8.X and use EMR Ruby CLI for managing EMR.
âą Just create credentials.json file in your EMR Ruby CLI installation
directory and provide your accesskey & private key.
âą Bootstrapping is a great way to install required components or
perform custom actions in your EMR cluster.
âą Default bootstrap action is available to control the configuration of
Hadoop and MapReduce.
âą Bootstrap with Ganglia during your development and tuning phase â
provides monitoring metrics across your cluster.
âą Minor bugs in EMR Ruby CLI but pretty cool for your needs.
26. EMR CLI â What you need to know?
âą elastic-mapreduce -j <jobflow id> --describe
âą elastic-mapreduce --list --active
âą elastic-mapreduce -j <jobflow id> --terminate
âą elastic-mapreduce --jobflow <jobflow id> --ssh
âą Look into your logs directory in the S3 if you need any other
information on cluster setup, hadoop logs, Job step logs, Task
attempt logs etc.
27. EMR Map Reduce Jobs
âą Amazon EMR supports â streaming, custom jar, cascading, pig
and hive. So you can write jobs in a you want without worrying
about managing the underlying infrastructure including hadoop.
âą Streaming â Write Map Reduce jobs in any scripting language.
âą Custom Jar â Write using Java and good for speed/control.
âą Cascading, Hive and Pig â Higher level of abstraction.
âą Use a good S3 explorer, FoxyProxy and ElasticFox.
âą Leverage aws emr forum if you need help.
29. Hadoop â Debugging and Profiling
âą Run hadoop in local mode for debugging so mapper and reducer
tasks run in a single JVM instead of separate JVMs.
âą Configure Hadoop_Opts to enable debugging.
(export HADOOP_OPTS="-agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=8008â)
âą Configure fs.default.name value in core-site.xml to file:/// from hdfs://
âą Configure mapred.job.tracker value in mapred-site.xml to local
âą Create debug configuration for Eclipse and set the port to 8008.
âą Run your hadoop job and launch Eclipse with your Java code so you
can start debugging.
âą Use your favorite profiler to understand code level hotspots.
30. EMR â Good, Bad and Ugly
âą Great for bootstrapping large clusters and very cost-effective if
you need once in a while infrastructure to run your Hadoop jobs.
âą Donât need to worry about underlying Hadoop cluster setup and
management. Most patches are applied and Amazon creates new
AMIâs with improvements.
âą Doesnât have a fall back (secondary name node) â only one
master node.
âą Intermittent Network Issues â Sometimes could cause serious
degradation of performance.
âą Network IO is variable and streaming jobs will be much sluggish
on EMR compared to dedicated setup.
âą Disk IO is terrible across instance families and types â Please fix
it.
31. Hadoop â High Level Tuning
Small files problem â avoid too Tune your settings â JVM
many small files and tune your Reuse, Sort Buffer, Sort Factor,
block size. Map/Reduce Tasks, Parallel
Copies, MapRed Output
Compression etc
Good thing is that you can
Know what is limiting you at a
use small cluster and sample
node level â CPU, Memory,
input size for tuning
DISK IO or Network IN/OUT
32. Hadoop â What effects your jobs performance?
âą GC Overhead - memory and reduce the jvm reuse tasks.
âą Increase dfs block size (default 128MB in EMR) for large files.
âą Avoid read contention at S3 â have equal or more files in S3
compared to available mappers.
âą Use mapred output compression to save storage, processing
time and bandwidth costs.
âą Set mapred task timeout to 0 if you have long running jobs (> 10
mins) and can disable speculative execution time.
âą Increase sort buffer and sort factor based on map tasks output.
36. Hadoop and EMR â What I have learned?
âą Code is god â If you have severe performance issues then look at
your code 100 times, understand third party libraries used and
rewrite in Java if required.
âą Streaming jobs are slow compared to Custom Jar jobs â Over
head and scripting is good for adhoc-analysis.
âą Disk IO and Network IO effects your processing time.
âą Be ready to face variable performance in Cloud.
âą Monitor everything once in a while and keep benchmarking with
data points.
âą Default settings are seldom optimal in EMR â unless you run
simple jobs.
âą Focus on optimization as itâs the only way to save Cost and Time.
37. Hadoop and EMR â Performance Tuning Example
âą Streaming : Map reduce jobs were written using Ruby. Input
dataset was 150 GB and output was around 4000 GB. Complex
processing, highly CPU bound and Disk IO.
âą Time taken to complete job processing : 4000 m1.xlarge nodes
and 180 minutes.
âą Rewrote the code in Java â job processing time was reduced to
70 minutes on just 400 m1.xlarge nodes.
âą Tuning EMR configuration has further reduced it to 32 minutes.
âą Focus on code first and then focus on configuration.