Cloud Programming Features Overview
Cloud Programming Features Overview
Module 5
Cloud Programming and Software Environments
This section provides a summary of key features found in real-world cloud and grid platforms.
We present this information across four tables, each focusing on a different aspect: capabilities,
traditional features, data-related features, and those relevant to programmers and runtime
systems. These tables serve as a referenced guide for developers aiming to efficiently program
.IN
and utilize cloud infrastructure.
C
Commercial cloud platforms are designed to offer broad capabilities, as summarized in Table
6.1. These capabilities enable cost-effective utility computing with the elasticity to scale
N
resources up or down based on demand. Beyond this core characteristic, commercial clouds
increasingly provide additional services under the umbrella of Platform as a Service (PaaS).
SY
For example, Microsoft Azure includes platform services such as Azure Table, queues, blobs,
SQL Database, and both Web and Worker roles. While Amazon Web Services (AWS) is
traditionally associated with Infrastructure as a Service (IaaS), it has steadily expanded its
U
MapReduce support through Hadoop. Google, although not offering a comprehensive cloud
service like Azure or AWS, provides the Google App Engine (GAE), a robust environment for
developing and hosting web applications.
Table 6.2 outlines various low-level infrastructure features. Table 6.3 presents traditional
programming models and environments used for parallel and distributed systems—capabilities
that are increasingly expected in cloud platforms, either as part of the system or user
environment. Table 6.4 highlights newer features emphasized by commercial cloud providers
and, to a lesser extent, some grid systems. Many of these features have only recently seen wide
adoption and are not yet available in most academic cloud infrastructures such as Eucalyptus,
Nimbus, OpenNebula, or Sector/Sphere (though Sector, a data-parallel file system or DPFS, is
categorized in Table 6.4).
.IN
programming withoutconsideringtediousinfrastructuremanagementissuessuchashandling model
networkfailureorscalingtherunningcodetouseallthecomputingfacilities
providedbytheplatforms.
Workflow and data [Link] query
language theSQLlanguageusedfordatabasesystems,incloudcomputing,providershave
support
C
builtsomeworkflowlanguage aswell asdata querylanguage tosupport better
applicationlogic.
N
Programming Web interfaces or special APIs are required for cloud applications: J2EE, PHP,
interface and service ASP, or Rails. Cloud applications can use Ajax technologies to improve the user
deployment [Link]
SY
provideropensitsprogramminginterfaceforaccessingthedatastoredinmassive storage.
Runtime support [Link]
distributed monitoring services, a distributed task scheduler, as well as distributed
[Link].
U
[Link] Workflow
Data transfer in and out of commercial clouds can be slow and costly.
Uses simple protocols like HTTP.
High-speed links may be introduced for better performance in national infrastructure.
Rashmi M, Asst. Prof., Dept. of CSE, RNSIT Page 2
Module 5- Cloud Programming and Software Environments
Cloud data (e.g., Azure blobs) supports parallel processing.
.IN
[Link] Program Library
Amazon and Azure provide message queues for communication between application
components.
REST interfaces, “deliver-at-least-once” semantics.
Alternatives: ActiveMQ, NaradaBrokering.
Azure uses Worker roles for background tasks and Web roles for web portals.
No need for explicit task scheduling.
.IN
Uses queues for distributed task management.
[Link] MapReduce
C
Processes large data sets in parallel using key-value pairs.
Open-source: Hadoop; Microsoft: Dryad.
N
Cloud-friendly and fault-tolerant.
Supports iterative computing (e.g., Twister).
SY
U
.IN
in ViNe from University of Florida
Environments
C
Cluster management: ROCKS and packages offering a range of tools to make it easy
N
to bring up clusters
Data management: Included meta data support such as RDF triple stores(Semantic web
SY
success and can be built on MapReduce as in SHARD); SQL and NOSQL included in
Grid programming environment: Varies from link-together services as in Open Grid
Services Architecture (OGSA) to GridRPC (Ninf, Grid Solve) and SAGA
U
OpenMP/threading: Can include parallel compilers such as Cilk; roughly shared memory
technologies. Even transactional memory and fine-grained data flow come here
VT
Blob:
o Basic cloud storage (e.g., Azure Blob, Amazon S3).
o Used for storing large unstructured data like images, backups, and videos.
DPFS (Distributed Parallel File Systems):
o Examples: Google File System, HDFS (Hadoop), Cosmos (Dryad).
o Designed with compute-data affinity for efficient large-scale data processing.
SQL:
o Traditional relational database support (e.g., MySQL, Oracle).
o Offered by both Amazon and Azure.
.IN
Table (NoSQL):
o Schema-free data structures like Amazon SimpleDB, Azure Table, Apache
HBase.
C
o Part of the NoSQL movement focused on scalability and flexibility.
N
2. Programming and Execution
SY
MapReduce:
o Programming model for distributed data processing.
o Examples: Hadoop (Linux), Dryad (Windows), Twister.
o Related languages: Sawzall, Pregel, Pig Latin, LINQ.
U
Programming Model:
o Cloud programming built on familiar web/grid paradigms.
VT
Fault Tolerance:
o Key feature in clouds but largely neglected in traditional grids.
o Enables system resilience against node failures.
Monitoring:
o Tools like Inca in grid environments.
.IN
6.2 Parallel and Distributed Programming Paradigms
What is Parallel and Distributed Programming?
C
Parallel and distributed programming means running a program simultaneously on
N
multiple computing systems.
It involves two key concepts:
SY
Benefits
VT
Challenges
Managing these systems is complex due to task coordination, data sharing, and
communication.
1. Partitioning
Computation Partitioning: Break the program into smaller tasks that can run at the
same time.
2. Mapping
Assign the smaller tasks or data pieces to specific computing resources (like assigning
jobs to workers).
3. Synchronization
.IN
4. Communication
When tasks need to share data, they communicate over the network (especially in
distributed systems).
C
N
5. Scheduling
SY
Decides which task runs when, especially when there are more tasks than available
workers.
Managing all of the above manually is hard and slows down development.
VT
Popular Paradigms/Models
The section 6.2.2 from your document elaborates on MapReduce, an important framework for
processing large-scale data in parallel across distributed systems, and introduces its extension
Twister for iterative computations. Here's a summarized and simplified explanation:
What is MapReduce?
.IN
two main user-defined functions:
Key Features:
C
N
Users write Map() and Reduce() functions.
SY
1. Input Files
These are the raw data chunks (e.g., text files, logs) stored in a distributed file system
(like HDFS).
The framework splits the input data and distributes it to multiple Map tasks.
2. Map Function
Each Map task reads a portion of the input data and processes it into intermediate key-
value pairs.
.IN
Example: For a word count task, it might emit pairs like (word, 1) for each word found.
C
The intermediate key-value pairs are shuffled and sorted.
All values associated with the same key are grouped together before being sent to the
N
appropriate Reduce task.
SY
4. Reduce Function
Takes each key and a list of its values (e.g., (word, [1,1,1])) and performs aggregation or
summarization (e.g., total count → (word, 3)).
U
5. Output Files
The final reduced data is written to output files, usually stored again in a distributed file
system.
6. Controller / MapReduceLibrary
7. User Interfaces
.IN
In Simple Terms:
C
Users just define what to do with data (Map/Reduce),
The system handles how and where to do it.
N
SY
U
VT
.IN
This diagram (Figure 6.2) shows the logical data flow in the MapReduce model, broken down
into 5 processing stages involving successive (key, value) pairs. It provides a deeper look into
C
how data is transformed through the MapReduce pipeline.
N
Step-by-Step Explanation
SY
1. Input
Input data is read as lines of text, each associated with a unique key (often byte offset)
and value (content of the line).
U
2. Map Stage
4. Group Stage
5. Reduce Stage
The Reduce function takes each grouped key and list of values.
It applies logic (like summing counts or averaging) to output a single (key, value) pair per
group.
o Example: ("word", 5) if the word appeared 5 times.
Final Output
.IN
Summary of the 5 Stages
Stage Description
Input C
Raw data split into (key, value) pairs.
N
Map Processes input and emits intermediate pairs.
SY
1. Input to Map is a (key, value) pair (e.g., line number and text).
2. Map emits intermediate (key, value) pairs (e.g., (word, 1)).
3. Intermediate pairs are sorted and grouped by key.
.IN
These are grouped and reduced to:
Formal Notation: C
N
Map phase: (key1, val1) → List(key2, val2)
SY
Solving Strategy
U
Key: Unique identifier (e.g., word, word length, sorted letters for anagram)
Value: What you want to count or process (e.g., 1 for occurrences)
.IN
C
This diagram (Figure 6.4) illustrates the partitioning function in the MapReduce model —
N
specifically how MapWorkers assign output to the appropriate ReduceWorkers based on key
values.
SY
Goal of Partitioning:
To distribute the intermediate key-value pairs generated by MapWorkers evenly and correctly to
VT
Components Breakdown
MapWorkers
Each MapWorker processes a chunk of the input data and emits intermediate (key,
value) pairs.
These key-value pairs must be passed to the right ReduceWorker.
Partitioning Function
Example:
o Keys with hash(key) % 3 == 0 go to Reducer 1
o Keys with hash(key) % 3 == 1 go to Reducer 2
o Keys with hash(key) % 3 == 2 go to Reducer 3
All MapWorkers use the same partitioning logic to ensure consistency.
Regions
The diagram uses colored boxes (1, 2, 3) to represent data partitions (or regions).
.IN
Each region is assigned to a specific ReduceWorker.
ReduceWorkers
C
ReduceWorkers are responsible for specific regions (partitions).
All the intermediate pairs for a given region (say region 1) — from all MapWorkers —
N
are sent to the same ReduceWorker.
SY
Summary
Component Role
U
Analogy:
Imagine 4 teachers (MapWorkers) grading exam papers. Based on a student's ID (key), they use
a rule (Partitioning function) to decide which department head (ReduceWorker) the scores
should be sent to. This ensures each head compiles grades only for their assigned group of
students.
.IN
C
N
This diagram (Figure 6.5) illustrates the dataflow implementation in a MapReduce job,
SY
showing detailed internal operations in both Map workers and Reduce workers. It breaks down
the workflow into stages like partitioning, combining, synchronization, communication,
sorting, and reducing.
U
1. Input Splitting
Input data is divided into chunks, and each chunk is processed by a MapWorker.
Each worker receives an Input split.
Each input record (like a line of text) is passed to the Map function.
Output: A set of intermediate key-value pairs — e.g., (K1, V1).
4. Partitioning Function
Intermediate key-value pairs are sent across the network to Reduce workers.
During this Shuffle step:
o Data from all MapWorkers is synchronized.
o Each ReduceWorker receives all values for a given key from all Mappers.
.IN
6. Reduce Worker
Each ReduceWorker:
Summary Table
U
Stage Role
VT
Real-World Analogy:
Imagine multiple teachers (MapWorkers) each grading student assignments (Input splits). After
marking:
Rashmi M, Asst. Prof., Dept. of CSE, RNSIT Page 18
Module 5- Cloud Programming and Software Environments
They summarize scores (Combiner).
Each student's scores go to a specific teacher for final tabulation (Partitioning and
Shuffle).
The receiving teacher calculates the final grade (Reduce), and stores it (Output).
Compute-Data Affinity
MapReduce tries to send computation to the data (on the same node), not the other way
around—this improves efficiency and reduces network use. Google’s GFS stores files in blocks,
aligning well with this strategy.
.IN
Standard MapReduce is not efficient for iterative tasks (like machine learning or graph
processing) because it writes intermediate results to disk.
MapReduce vs MPI
U
δ (delta) flow: Represents the minimal update information exchanged in each iteration.
Full data flow: Transferring all data, even unchanged parts, each time — as done in
MapReduce.
MapReduce's architecture:
.IN
2. Use long-running threads/processes for efficient δ communication (rather than
restarting jobs)
These changes:
Twister (MapReduce++)
Features:
VT
Referenced Figures:
.IN
C
N
Explanation of Figure 6.6: Control Flow in MapReduce
SY
This diagram shows the control flow of a MapReduce job—from starting the user program to
executing map and reduce tasks on distributed worker nodes and finally writing output files.
U
Components Involved
Step-by-Step Breakdown
(1) Start
(2) Fork
(4) Read
Each Map worker reads its assigned input split from the input files.
(5) Map
.IN
Each Map worker executes the Map function on its split, producing intermediate (key,
value) pairs.
(11) Reduce
Reduce workers perform the Reduce function on received grouped data, processing keys
U
(12) Write
Final reduced output is written to output files (e.g., File 1, File 2).
Summary
Stage Function
Userprogram Starts the job and forks workers
Master Coordinates and assigns map/reduce tasks
Workers Read, process (map/reduce), and write data
Communication Shuffle phase moves intermediate data to reducers
.IN
C
N
SY
This figure explains the Twister framework, an enhanced version of MapReduce (often called
VT
1. Configure()
Loads static data (e.g., constants, static matrices) once before the iterative process starts.
2. Map(key, value)
Each iteration begins by applying the Map function to dynamic data (e.g., input
samples).
Generates intermediate (key, value) pairs.
Rashmi M, Asst. Prof., Dept. of CSE, RNSIT Page 23
Module 5- Cloud Programming and Software Environments
3. Reduce(key, list<value>)
The Reduce function receives all values associated with a key, typically to aggregate or
compute a result for that key.
4. Combine(key, list<value>)
5. dfLow (δ-flow)
Twister introduces δ-flow, a small piece of data (delta) communicated between iterations,
instead of full data like in traditional MapReduce. This improves performance.
.IN
6. User Program Iteration
After each Reduce (or Combine), the User Program evaluates results and decides
C
whether to iterate again (loop back to Map).
N
7. Close()
SY
Once convergence or a stopping condition is met, the program finalizes the process and
cleans up.
This part shows how Twister is implemented at runtime with multiple components:
VT
Components:
MR Daemon (D): Long-running processes managing Map and Reduce workers. Unlike
traditional MapReduce, Twister reuses workers between iterations.
M / R: Map and Reduce workers.
MR Driver: Central coordinator responsible for managing iterations, task assignments,
and communications.
User Program: Drives the iterations, convergence checks, and termination.
Pub/Sub Broker Network: Used for efficient communication (publish/subscribe
model) between distributed workers.
Data Splits: Input data is split and fed into the system.
.IN
Worker Lifecycle Short-lived Long-running
Summary C
N
Twister is an efficient iterative MapReduce framework built for tasks that require multiple
SY
Explanation of Figure 6.8: Performance of K-means Clustering for MPI, Twister, Hadoop,
and DryadLINQ
Experiment Overview
.IN
Performance: Consistently the slowest.
Reason:
o Writes intermediate data to disk
C
o Creates and destroys Map and Reduce tasks every iteration
N
o High I/O and setup/teardown overhead
SY
Observations
All systems show some increase in execution time as the data size grows.
However:
o MPI and Twister scale much better than Hadoop and DryadLINQ.
o MPI consistently delivers the fastest results.
o Twister offers a balance between ease-of-use (MapReduce-like) and high
performance.
.IN
Conclusion
For iterative machine learning tasks like K-means, traditional MapReduce frameworks
like Hadoop are inefficient.
C
Twister improves upon this with support for iteration and in-memory computation.
N
MPI remains the most performant but is harder to program and manage.
SY
U
VT
Figure 6.9 presents a comparison of thread and process structures in four parallel
programming paradigms: Hadoop, Dryad, Twister (MapReduce++), and MPI. Here's a
breakdown of what each model represents and how they differ:
1. Yahoo Hadoop
2. Microsoft Dryad
.IN
3. Twister (MapReduce++)
Limitation: Low-level and harder to use than higher-level models like Twister or
Hadoop.
Key Observations:
Interpretation:
Twister performs much faster than Hadoop across all data sizes.
Hadoop suffers from high overhead due to:
.IN
o Writing intermediate data to disk.
o Short-running task management.
Twister:
C
o Uses long-running tasks and in-memory communication (no disk I/O between
iterations).
N
o Excels in iterative applications and large-scale data processing.
SY
Conclusion:
Twister is a highly efficient MapReduce runtime for iterative applications like those in
machine learning or graph analytics. Its performance advantage over Hadoop grows as dataset
U
size increases, making it a better fit for big data processing at scale.
VT
Summary:
Apache Hadoop is an open-source framework developed in Java that allows for distributed
processing of large data sets across clusters of computers using a model called MapReduce. It
was designed as an alternative to Google's proprietary systems and includes its own file storage
layer (HDFS) and computation engine (MapReduce engine).
1. MapReduce Engine:
o This is the processing engine that runs computations on the data stored in HDFS.
o It breaks down tasks into Map and Reduce phases for parallel processing.
2. HDFS (Hadoop Distributed File System):
.IN
o A specialized file system designed for high-throughput access to large files.
o Inspired by Google’s GFS, it is tailored for large-scale data storage and access.
HDFS Architecture
o DataNodes (Slaves): Actually store the file data in blocks and perform read/write
operations.
How Storage Works:
U
1. Fault Tolerance
Block Replication:
o Each block is copied to multiple DataNodes to prevent data loss.
o Default replication factor is 3.
Replica Placement Strategy:
o 1 copy on the same node as the original.
o 1 copy on a different node within the same rack.
o 1 copy on a node in a different rack (for added reliability).
Heartbeat and Blockreport Messages:
o Heartbeats: Sent by DataNodes to let the NameNode know they are working.
2. High Throughput
Reading a File
.IN
1. The user sends a request to the NameNode to open the file.
2. The NameNode returns the list of DataNodes storing the file blocks.
3. The user then connects to the nearest DataNode to read each block one-by-one.
Writing a File
C
N
1. The user sends a “create” request to the NameNode.
SY
4. This process is repeated for each block until the entire file is stored.
VT
Summary
Apache Hadoop, through its components MapReduce and HDFS, enables efficient, reliable
processing and storage of massive data sets across clusters. HDFS, with its fault tolerance and
high throughput capabilities, ensures data is stored safely and accessed quickly, making it ideal
for big data applications.
.IN
C
MapReduce is the topmost layer in the Hadoop framework. It coordinates and manages the
processing of large data sets using parallel, distributed computing.
N
Architecture Overview
SY
o TaskTrackers (Slaves):
Run on individual nodes in the cluster.
Execute the actual map or reduce tasks assigned by the JobTracker.
Task Slots:
o Each TaskTracker has a fixed number of execution slots based on the node’s
CPU capabilities.
o Example: A node with N CPUs, each supporting M threads, will have N × M
slots.
Slot Usage:
o Each slot runs one map or reduce task at a time.
o One map task = One data block → This means there's a 1:1 relationship
between map tasks and data blocks stored in HDFS.
Key Points
This section explains how Hadoop’s MapReduce component works on top of HDFS to process
big data efficiently through distributed execution and parallelism
The diagram in Figure 6.11 illustrates the architecture of Hadoop, specifically showing how
the MapReduce engine and HDFS (Hadoop Distributed File System) interact within a
distributed cluster setup.
.IN
Overview
C
Top Half: Represents the MapReduce engine (for processing data).
N
Bottom Half: Represents HDFS (for storing data).
SY
The cluster is organized into multiple nodes, grouped into racks (Rack 1 and Rack 2).
Key Takeaways
U
Node 1 is the master node with JobTracker (MapReduce master) and NameNode
VT
(HDFS master).
Nodes 2, 3, 4 are worker nodes with both TaskTrackers and DataNodes.
Blocks are stored in DataNodes; Tasks are executed in TaskTrackers.
The architecture supports fault tolerance, parallel processing, and data locality.
When a MapReduce job is run in Hadoop, three main components are involved:
Step-by-Step Process:
1. Job Submission
2. Task Assignment
The JobTracker:
o Creates one map task per input split.
.IN
o Assigns map tasks to TaskTrackers by considering data locality (to reduce data
movement).
o Creates reduce tasks (number is set by the user).
C
o Assigns reduce tasks to TaskTrackers without locality considerations.
N
3. Task Execution
Each TaskTracker:
SY
Each TaskTracker:
o Sends periodic heartbeat messages to the JobTracker.
o Heartbeats indicate that the TaskTracker is alive and whether it’s ready for new
tasks.
.IN
Components in the Diagram
TaskTrackers.
3. NameNode
o Master node of HDFS.
o Knows where data blocks are stored across the cluster.
U
o Used to locate data when JobTracker schedules map tasks (for data locality).
4. TaskTrackers
VT
Process Flow
1. Job Submission
2. Task Assignment
Based on data locality (data block locations known via NameNode), the JobTracker
assigns tasks to the appropriate TaskTrackers.
Map tasks are scheduled closer to where the data blocks reside (shown in the
DataNodes).
Reduce tasks are assigned without considering locality.
.IN
3. Task Execution
Each TaskTracker launches one or more Java Virtual Machines (JVMs) to execute:
o Map tasks (left and middle nodes).
o Reduce task (right node). C
N
JVMs use the code in the submitted JAR to process the task.
SY
4. Heartbeat
Important Notes:
It allows the user to define their own dataflow using a Directed Acyclic Graph (DAG).
.IN
C
N
SY
figure6.13 Dryad framework and its job structure, control and data flow
U
1. Job Definition
2. Execution Components
Job Manager:
o Constructs the DAG from the user-defined program.
o Schedules tasks on available nodes in the cluster.
o Manages execution but does not handle data movement (avoids becoming a
bottleneck).
Name Server:
o Maintains a list of available computing resources (cluster nodes).
3. Deployment
Job manager maps the logical DAG to physical resources using info from the name
server.
A daemon runs on each node:
o Acts as a proxy.
o Receives the program binary.
o Executes the assigned tasks.
o Reports status back to the job manager.
.IN
Data Transfer and Communication
Unlike Hadoop, where all coordination happens via the JobTracker, Dryad allows direct
communication between nodes, making it more scalable.
Fault Tolerance
U
Advanced Features
Summary
Feature Dryad
.IN
Programming model DAG-based (flexible dataflow)
Coordination
C
Job Manager + Name Server
N
Fault tolerance Re-execution of vertices or channels
SY
Why DryadLINQ?
DryadLINQ enables regular .NET developers to write scalable distributed programs using
familiar C# and LINQ syntax, without needing to deal with low-level parallelism or distributed
programming challenges.
Task scheduling
Data partitioning
Fault tolerance
Network communication
.IN
1. Application Starts and Builds Expression
6. Vertex Execution
Each vertex runs its own piece of logic (as compiled earlier).
These are independent and run in parallel where possible.
7. Output Generation
.IN
Job manager terminates.
DryadLINQ returns DryadTable objects encapsulating results.
These can be input to next jobs (i.e., multi-stage pipelines).
Summary Table
Step Description
U
Step Description
Benefits of DryadLINQ
.IN
C
N
SY
U
VT
What is Sawzall?
1. Data Partitioning:
o Input data is split and processed locally using Sawzall scripts.
2. Local Processing:
.IN
o Each node filters and processes its portion of the data using custom scripts.
3. Aggregation:
o Intermediate results are emitted to aggregators (called tables).
C
o Final results are generated by collecting data from these aggregators.
N
Sawzall Scripting Example (Conceptual)
SY
2. Input handling:
3. Runtime Translation:
The Sawzall engine translates scripts into MapReduce jobs that run across multiple machines.
Conclusion
.IN
Like Sawzall and DryadLINQ, Pig Latin provides an abstraction layer over MapReduce,
simplifying the process of writing data processing programs.
Automated Parallelism:
o You focus on how to process individual elements.
o Parallelism is handled automatically by the system.
U
.IN
User-
DefinedFuncti
ons)
ControlStructures
ExecutionModel
Yes
Recordoperation C
No
Sequence of
Yes
DAGs
N
s+ fixed MapReduceopera
aggregations tions
SY
Table6.8PigLatinDataTypes
DataType Description Example
.IN
asetofkeys;thekeysareabag (‘Azure’)
ofatomicdata
‘Redhat’ ‘Linux’
Table6.9PigLatinOperators
VT
Command Description
LOAD Readdatafromthefilesystem.
STORE Writedatatothefilesystem.
FOREACHGENERATE
Applyanexpressiontoeachrecordandoutputoneormorer
ecords.
FILTER
Applyapredicateandremoverecordsthatdonotret
urntrue. GROUP/COGROUP Collect records with the same key from one or
more inputs. JOIN Join two or more inputs based on a key.
CROSS Crossproducttwoormore inputs.
UNION Mergetwoormoredatasets.
SPLIT Splitdataintotwoormoresets,basedonfilterconditions.
ORDER Sortrecordsbased ona key.
DISTINCT Removeduplicatetuples.
STREAM Sendallrecordsthroughauser-providedbinary.
DUMP Writeoutputtostdout.
LIMIT Limitthenumberofrecords.
.IN
Summary
This section explains how different types of applications maps to parallel and distributed
U
systems, based on six distinct application architectures. These helps understand how various
problems can be efficiently executed on different computing models like clusters, grids, and
VT
clouds.
.IN
This sixth category addresses modern big data and data analytics applications that emerged
with MapReduce and its variants. It’s a hybrid of categories 2 and 4 but focused specifically on
data flow.
C
N
Subcategories of MapReduce++
SY
1. Map-Only Applications:
o Similar to Category 4.
o Each task reads data, processes it independently, and outputs results.
o No reduce step involved (e.g., log scanning, data filtering).
U
2. Classic MapReduce:
o File-to-file processing with two phases:
VT
Summary of Differences
This classification helps choose the right programming model and infrastructure for a given type
of application—whether it's for simulations, data analysis, or event-driven systems.
.IN
Table6.11ComparisonofMapReduce++SubcategoriesalongwiththeLooselySynchronousCategoryUsedinMP
I
Map-Only Classic MapReduce IterativeMapReduce LooselySynchronous
input input
C input
jmap()
N
map()
B
SY
map()
reduce() reduce()
output iA Pl
U
output output
VT
.IN
C
Table6.10ApplicationClassificationforParallelandDistributedSystems
Machine
N
Category Class Description Architect
ure
SY
.IN
forexample,theLargeHadronCollideranalysis
for
particlephysics.
5 Metaproblem Thesearecoarse-
s C
grained(asynchronousordataflow)
Gridsof
N
combinationsofcategories1- clusters
[Link]
SY
Alsogrowninimportanceandiswellsupported
by
gridsanddescribedbyworkflowinSection3.5.
U
Google App Engine (GAE) is a cloud platform that allows developers to build and host web
applications on Google's infrastructure. It supports languages like Java and Python, and
provides built-in tools for scalable, secure, and efficient cloud development.
Java Support:
o Eclipse plug-in: Enables local debugging.
o GWT (Google Web Toolkit): Helps develop dynamic web apps in Java.
o Other JVM-based languages like JavaScript, Ruby are also usable via
interpreters.
.IN
Python Support:
o Common frameworks include Django and CherryPy.
o Google provides a lightweight webapp framework for Python.
o Each entity:
Max size: 1 MB.
Identified by key-value properties.
U
o Querying:
Filtered and sorted by property values.
VT
URL Fetch:
o Allows apps to fetch web resources using HTTP/HTTPS.
o Uses Google’s fast internal network for efficient retrieval.
Secure Data Connection (SDC):
o Tunnels through the internet to link an intranet with a GAE app.
Mail Service:
o Enables sending emails from the application.
Google Data API:
o Access services like Maps, YouTube, Docs, Calendar, etc., within your app.
.IN
Google Accounts Integration:
o Users can log in using existing Google accounts (e.g., Gmail).
Images API: C
o Handles authentication and account creation.
N
o Perform basic image operations like resize, crop, flip, rotate, and enhance.
SY
Cron Service:
o Schedule tasks periodically (e.g., hourly, daily).
U
Usage Limits:
o GAE enforces quotas to prevent overuse and ensure fair resource allocation.
o Free tier available with limits on CPU, storage, bandwidth, etc.
o Ensures cost control and performance isolation between apps.
.IN
C
N
SY
Summary
U
Google App Engine simplifies the deployment of scalable web applications using familiar
VT
languages like Java and Python. It offers powerful features such as built-in data storage,
background processing, and access to Google services — all while managing infrastructure,
scaling, and cost control for you.
.IN
GFS was developed by Google to support the massive data needs of its search engine, designed
specifically for storing and processing huge volumes of data on cheap, unreliable hardware.
1. Design Motivations C
N
Traditional file systems could not handle:
SY
o Petabyte-scale data
o Frequent hardware failures
GFS was co-designed with Google’s applications, leading to tight integration (non-
standard, unlike POSIX-compliant systems).
U
2. Key Assumptions
VT
Single Master:
o Manages metadata (file names, block locations, leases).
Shadow Master:
o Mirrors the main master to recover from master failure.
Replication:
.IN
o Each chunk is stored in at least three servers.
o Can tolerate two simultaneous failures.
Checksum Verification:
Fast Recovery: C
o Each 64 KB sub-block has a checksum for data integrity.
N
o Masters and chunk servers restart in seconds.
SY
If errors occur: Client retries steps 3–7 or restarts the entire process.
.IN
6. Special Feature: Record Append
C
Used for concurrent data appending (e.g., by web crawlers).
Ensures:
N
o Data is appended at least once.
o Offset chosen by GFS, not client.
SY
8. Advantages
Summary
GFS is a groundbreaking distributed file system tailored for Google’s massive data needs. It
breaks away from traditional designs to emphasize fault tolerance, high throughput, and
scalability on commodity infrastructure, making it a key foundation for systems like
MapReduce.
.IN
2. Motivations Behind BigTable
Commercial databases can't handle Google's massive scale and performance needs.
Needed a custom-built system for:
o Billions of records (e.g., URLs).
C
N
o High user activity (e.g., thousands of queries/sec).
o Huge data sizes (e.g., >100 TB of geographic data).
SY
U
4. Conceptual View
Thousands of servers.
Terabytes of in-memory data.
Petabytes of data on disk.
Self-managing:
Component Function
GFS (Google File System) Stores persistent data
Scheduler Manages job scheduling for BigTable operations
.IN
Lock Service (Chubby) Handles master node elections and service coordination
MapReduce Used for reading/writing and bulk operations on BigTable
7. Summary
C
N
BigTable is a high-performance, scalable, and fault-tolerant NoSQL system tailored for
Google's unique requirements. Its success lies in tight integration with the underlying Google
SY
infrastructure, and its ability to support billions of rows, flexible schema, and fast access in a
cloud-native way.
BigTable’s data model is simplified yet powerful, designed to handle large-scale, structured
VT
and semi-structured data, such as web pages, user data, and media content.
.IN
C
N
SY
Data mapping:
text
CopyEdit
(row: string, column: string, timestamp: int64) → string (cell value)
3. Key Features
.IN
o Rows are automatically created when data is inserted.
C
Tables are divided into tablets (chunks of rows).
N
Each tablet:
o Stores ~100 MB to 200 MB of data.
SY
BigTable Master:
o Manages metadata and tablet assignments.
o Makes decisions about load balancing.
Tablet Servers:
o Store and serve tablets to clients.
Clients:
o Use a BigTable client library to communicate with master and tablet servers.
Chubby (Distributed Lock Service):
o Handles master election, metadata consistency, and synchronization.
Summary
BigTable’s model supports high scalability, efficient large-scale data access, and fault tolerance.
It uses a simple yet powerful key-value system enhanced with time and column structure,
making it ideal for applications like search indexing, web crawling, user data storage, and
media metadata.
BigTable uses a three-level hierarchy to locate tablets, ensuring fast and reliable access to data.
.IN
1. Root Tablet Location:
o Stored in a file managed by Chubby.
o Root tablet contains metadata about other METADATA tablets.
o This file is never split and guarantees a max of three lookup levels.
2. METADATA Tablets:
o Each entry points to user tablets.
C
N
o Indexed by a row key that encodes the table ID and end row.
o Contains the location of all user data tablets.
SY
3. User Tablets:
o Contain actual user data rows and columns.
U
Key Features:
VT
Key Functions:
.IN
o Elect master servers.
o Manage metadata files and locks.
Primary Use: Google's internal name and configuration service.
Summary C
N
Component Purpose Key Points
SY
.IN
6.4.1 Programming on Amazon EC2
Amazon EC2 (Elastic Compute Cloud) is a key component of Amazon Web Services (AWS)
that allows users to rent virtual machines (VMs) for running applications. It was the first cloud
C
service to offer VM-based application hosting, pioneering the Infrastructure-as-a-Service
(IaaS) model.
N
1. Core Features
SY
Elasticity:
o Create, launch, and terminate VM instances on-demand.
VT
o Pay only for the time the VMs are active (per hour billing).
Class Purpose
1. Standard General-purpose usage.
2. Micro Low-throughput tasks with occasional CPU bursts.
3. High-Memory Suitable for memory-intensive apps like databases.
4. High-CPU Ideal for compute-heavy tasks (e.g., simulations).
5. Cluster HPC and network-intensive workloads using high-speed networking (10
Compute Gbps).
.IN
o 1 ECU ≈ 1.0–1.2 GHz CPU from a 2007 Xeon/Opteron.
4. Cost Considerations
EC2 can be used to power a range of apps, from simple websites to complex enterprise
solutions.
Real-world usage often involves:
o Running databases, web servers, or data processing jobs.
o Scaling up/down based on traffic or computational needs.
Summary
Amazon EC2 offers a flexible, scalable, and cost-efficient platform for hosting applications in
the cloud. It supports a wide range of instance types to suit different workloads and allows users
full control
ImageType AMIDefinition
Private AMI
Imagescreatedbyyou,[Link]
antaccesstoother users to launch your private images.
Public AMI Images created by users and released to the AWS community, so
anyone can launch
[Link]
icimagesat
[Link]
ategoryID=171.
Paid QAMI
Youcancreateimagesprovidingspecificfunctionsthatcanbe
.IN
launchedbyanyone willing to pay you per each hour of usage
on top of Amazon’s charges.
C
N
SY
U
VT
Table6.13InstanceTypesAvailableonAmazonEC2(October6,2010)
ECUorEC2 Virtual Storage
ComputeInstance MemoryG Units Cores GB 32/64Bit
B
Standard:small 1.7 1 1 160 32
Standard:large 7.5 4 2 850 64
Standard:extralarge 15 8 4 1690 64
Micro 0.613 Up to2 OnlyEBS 32or64
High-memory 17.1 6.5 2 420 64
Amazon S3 is a web-based object storage service that allows users to store and retrieve any
amount of data, anytime, from anywhere via web protocols.
.IN
Core Concepts
Object Storage: Each object contains data, metadata, and access control, and is stored in
a bucket.
C
Key-Value Access: Each object is accessed via a unique key.
N
Access Interfaces
SY
Key Features
VT
.IN
6.4.3 – Amazon EBS (Elastic Block Store) C
N
EBS offers block-level storage volumes for use with EC2 instances. It's akin to attaching a
SY
Key Features
U
Persistence: Unlike EC2 instance storage, data is retained after the instance is stopped.
Block Device Interface:
VT
Data Model
Use Case
.IN
$0.14 per SimpleDB machine hour.
First 25 hours/month are free.
Comparison Summary
C
N
Service Type Use Case Interface Pricing (2010)
REST, $0.055–
S3 Object Storage Media, backups, static content
SY
SOAP $0.15/GB/month
Block
EBS Block Storage Persistent storage for EC2 $0.10/GB + I/O costs
Device
U
Azure is Microsoft’s cloud platform offering virtualized compute, storage, and database
services. It supports scalable application hosting through a role-based architecture and
integrates a range of storage models.
Types of Roles
Lifecycle Methods:
Debugging:
.IN
No live debugging on cloud instances.
Use trace logs and performance counters for diagnostics.
2. SQLAzure ([Link])
Blob Storage:
VT
NoSQL key-value store suitable for metadata and scalable structured data.
5. Azure Queues
.IN
C
N
SY
U
VT
Summary Table
.IN
This section introduces open-source and research-oriented cloud platforms and tools
designed to support cloud programming, VM management, storage, and data processing
across diverse infrastructures.
Eucalyptus
for deployment.
Nimbus
Key Features
.IN
C
N
SY
U
VT
OpenNebula
Sector/Sphere
Sector (Storage)
.IN
Wide-area DFS with replica placement based on network topology.
Uses UDP for control, UDT for data.
Integrated with FUSE and provides programming APIs.
Sphere (Processing)
C
N
Works with Sector to process data using user-defined functions (UDFs).
SY
Space: Column-based table storage engine in Sector/Sphere, supporting a limited SQL subset.
VT
OpenStack
Includes:
o Proxy Server: Routes data requests.
o Ring: Maps entity names to physical locations.
o Object, Container, Account Servers.
Supports replication, failure isolation, and heterogeneous storage.
Objects stored as binary files with extended attributes.
.IN
C
N
SY
U
VT
.IN
6.5.3 – Aneka Cloud (Manjrasoft)
Aneka is a cloud platform for developing and running parallel and distributed applications, built
on .NET but supports Linux via Mono. C
N
Key Capabilities
SY
1. Build:
o SDK with APIs for app development.
o Deploy on private, public, or hybrid clouds.
U
2. Accelerate:
o Rapid deployment on multiple runtime environments.
VT
Comparison Snapshot
.IN
Cloud Programming
Aneka Multi-model programming, SLA-aware scaling
Platform
machine and interacts with the operating system through a component called the Platform
Abstraction Layer (PAL). PAL hides the differences between various operating systems and
helps perform system tasks like monitoring performance and ensuring quality of service.
U
Aneka’s architecture is made up of three types of services. First are Fabric Services, which
VT
handle core infrastructure tasks like monitoring hardware, managing nodes, and ensuring system
reliability. Second are Foundation Services, which add useful features like storage management,
accounting, billing, and resource reservation—helping both system administrators and
developers. Lastly, Application Services provide the environment needed to run applications,
using the other services to handle tasks like data transfer and performance tracking. Aneka can
run different types of application models like distributed threads, bag of tasks, and MapReduce.
It supports easy customization and expansion through its SDK and Spring framework, allowing
developers to add new features quickly.
.IN
C
N
SY
U
VT
.IN
C
N
SY
U
VT
Virtual appliances are specially prepared virtual machines (VMs) that contain everything
needed to run an application, including the operating system, libraries, and setup files. These
VMs are designed to run out-of-the-box, meaning they are preconfigured and ready to use
immediately once started. Aneka uses virtual appliances to make application deployment easier,
especially across large, mixed computing environments.
The use of VM technology (like VMware, VirtualBox, or Xen) allows Aneka to create virtual
clusters that are consistent and easy to manage. These virtual appliances reduce software
compatibility issues since the entire software stack is already inside the appliance. Even if the
underlying hardware or operating systems differ, the application runs the same way. This
.IN
C
N
SY
U
VT