4/9/2018 Week 13-A Sangmi Lee Pallickara. CS435 Introduction to Big Data Spring 2018 Colorado State University. FAQs. Architecture of GFS

Save this PDF as:
 WORD  PNG  TXT  JPG

Size: px
Start display at page:

Download "4/9/2018 Week 13-A Sangmi Lee Pallickara. CS435 Introduction to Big Data Spring 2018 Colorado State University. FAQs. Architecture of GFS"

Transcription

1 W13.A.0.0 CS435 Introduction to Big Data W13.A.1 FAQs Programming Assignment 3 has been posted PART 2. LARGE SCALE DATA STORAGE SYSTEMS DISTRIBUTED FILE SYSTEMS Recitations Apache Spark tutorial 1 and 2 3/30, and 4/6 : video clips are available PA3 help session 4/13 Computer Science, Colorado State University W13.A.2 W13.A.3 Today s topics Distributed s Google Part 1. Large scale data analysis using MapReduce Distributed Google (): Master Operations W13.A.4 Architecture of W13.A.5 Master operations... Master Chunk Server Single master Manage system metadata Leasing of chunks Garbage collection of orphaned chunks Chunk migrations 1

2 W13.A.6 Why have a single Master? Vastly simplifies design Easy to use global knowledge to reason about Chunk placements Replication decisions W13.A.7 ALL system metadata is managed by the Master and stored in Main Memory File and chunk namespaces Mapping from files to chunks Location of chunks Logs mutations into a permanent log Disadvantage Single-point-of-error W13.A.8 W13.A.9 Prefix compression use used useful usefully usefulness useless uselessly uselessness 58 characters Data = array( 0 => use, 1 => 0d, 2 => 0ful, 3 => 0fully, 4 => 0fullness, 5 => 0less, 6 => 0lessly, 7 => 0lessness, ); 36 characters 30 characters Data = array( 0 => use, 1 => 0d, 2 => 0ful, 3 => 2ly, 4 => 2ness, 5 => 0less, 6 => 5ly, 7 => 5ness, ); Why keep the entire metadata in memory? Speed Master can scan its state in the background Implement chunk garbage collection Re-replicate if there are failures Chunk migration to balance load and space Add extra memory to increase file system size W13.A.10 Size of the file system with 1 TB of RAM: Assume file sizes are exact multiples of chunk sizes The master maintains less than 64 bytes of metadata for each 64MB chunk Number of entries = 2 40 /2 6 MAXIMUM SIZE of the file system = Number of entries x Chunk size = 2 40 x (2 6 x 2 20 ) 2 6 = 2 60 = 1 EB W13.A.11 Tracking the chunk servers Master does not keep a persistent copy of the location of chunk servers List maintained via heart-beats Allows list to be in sync with reality despite failures Chunk server has final word on chunks it holds 2

3 W13.A.12 W13.A.13 Simple read example Chunk data (chunk handle, byte range) (file name, chunk index within a file) (chunk handle, chunk location) Master Chunk Server Control messages Data message Simple read example in HDFS close() Chunk data read() DFSInputStream (chunk handle, byte range) open() in FileSystem object (file name, chunk index within a file) (sorted chunk handle, chunk location) Master Chunk Server Control messages Data message W13.A.14 Network topology and HDFS [1/2] What does it mean for two nodes in a local network to be close to each other? Bandwidth between nodes? Hadoop s approach The network is represented as a tree The distance between two nodes is the sum of their distances to their closest common ancestor W13.A.15 Network topology and HDFS [2/2] Processes on the same node Different nodes on the same rack Nodes on different racks in the same data center Nodes in different data centers DC1 Rack1 Rack2 Rack3 Node 1Node Proc Proc 1Proc DC2 DC3 distance (/d1/r1/n1, /d1/r1/n1) = 0 (processes on the same node) distance (/d1/r1/n1, /d1/r1/n2) = 2 (processes on the same rack) distance (/d1/r1/n1, /d1/r2/n3) = 4 (processes on the different rack but in the same data center) W13.A.16 W13.A.17 Caching at the client/chunk servers s do not cache file data At client the working set may be too large Simplify client; eliminate cache-coherence problems Chunk servers do not cache file data either Chunks are stored as local files s buffer cache already keeps frequently accessed data in memory Part 1. Large scale data analysis using MapReduce Distributed Google (): Consistency in 3

4 W13.A.18 What is consistency? (1/4) (1) Strong consistency Avoiding all inconsistences W13.A.19 What is consistency? (2/4) (3) Read consistency Update consistency does NOT guarantee that readers of that data store will always get consistent responses (2) Update consistency Write-write conflict Two people updating the same data at the same time Without conflict handling Server will serialize them Decide to apply one then another W13.A.20 What is consistency? (3/4) (4) Replication Consistency Pramod In London Martin In Tokyo In NYC Eventually consistent At any time nodes may have replication inconsistencies -- If there are no more updates, eventually all nodes will be updated to the same value W13.A.21 What is consistency? (4/4) (5) Session Consistency Within a user s session there is read-your-writes consistency Sticky session A session that s tied to one node (session affinity) Version stamps Ensure every interaction with the data store includes the latest version stamp seen by a session Server node must ensure that it has the updates that include that version stamp before responding to the request W13.A.22 Consistency in the ACID properties Relational databases allow user to manipulate any combination of rows from any table in a single transaction ACID transaction is Atomic Consistent Isolated Durable W13.A.23 Relaxed consistency The CAP theorem Eric Brewer, 2000 Seth Gilbert and Nancy Lynch, 2002 Formal proof Given the three properties of Consistency, Availability, and Partition tolerance, you can only get two Consistency Every read receives the most recent write or an error Availability Every request receives a (non-error) response without guarantee that it contains the most recent write Partition tolerance The system continues to operate despite an arbitrary number of messages being dropped (or delayed) by the network between nodes 4

5 W13.A.24 Two breaks in the communication lines W13.A.25 Eventually consistent Boston London Rome At any time nodes may have replication inconsistencies If there are no more updates (or updates can be ordered), eventually all nodes will be updated to the same value Chicago LA Paris Miami A single machine can t partition So it does not have to worry about partition tolerance There is only one node. If it s up, it s available Sydney W13.A.26 Mutations in Mutation changes the content or metadata of a chunk Write Writes data at an application-specific file offset Append Appends atomically at least once even in the presence of concurrent mutation W13.A.27 In the state of file region after mutation depends on Type of the mutation Success/Failure of the mutation Whether there were concurrent mutations Each mutation is performed at all chunk replicas Append is done based on record (1/4 of a chunk) Offset is specified by W13.A.28 has a relaxed consistency model Consistent: See the same data On all replicas Defined: If it is consistent AND s see mutation writes in its entirety W13.A.29 Inconsistent and undefined Operation A Operation B 5

6 W13.A.30 Consistent but undefined Operation A W13.A.31 Defined Operation A Operation B Operation B W13.A.32 Data mutation W13.A.33 File state region after a mutation Write Data to be written at an application-specified file offset Record appends (in ) Data ( record ) to be appended atomically at least once even in the presence of concurrent mutations chooses the offset No need for a distributed lock manger Serial success Concurrent success Failure Write defined Consistent but undefined Inconsistent Record Append defined interspersed with inconsistent W13.A.34 For the sequence of successful mutations, guarantees the mutated file to be defined and to contain the data written by the last mutation Applying mutations to a chunk in the same order on all its replicas Using chunk version numbers to detect any replica that has become stale If the chunkserver was down W13.A.35 But, clients cache chunk locations What if the chunk location points to a stale replica before that information is refreshed? Cache entry s timeout Next open to the file will purge all chunk information for that file from the cache Most of files are append-only Stale replica usually returns a premature end of chunk rather than outdated data 6

7 W13.A.36 W13.A.37 Implications for applications Rely on appends instead of overwrites Checkpoint Write records that are Self-validating Self-identifying What if many writers concurrently append? Append-at-least-once semantics preserves each writer s output Each record contains extra information like checksums so that its validity can be verified Reader can identify and discard extra padding W13.A.38 W13.A.39 uses leases to maintain consistent mutation order across replicas Part 1. Large scale data analysis using MapReduce Distributed Google (): Handling writes and recordappends to a file Master grants lease to one of the replicas PRIMARY Primary picks serial-order For all mutations to the chunk Other replicas follow this order When applying mutations W13.A.40 Lease mechanism designed to minimize communications with the master W13.A.41 Revocation and transfer of leases Master may revoke a lease before it expires Lease has initial timeout of 60 seconds As long as chunk is being mutated Primary can request and receive extensions Extension requests/grants piggybacked over heart-beat messages If communications lost with primary Master can safely give lease to another replica ONLY AFTER the lease period for old primary elapses 7

8 W13.A.42 How a write is actually performed 1. Chunkserver holding the current lease for the chunk and the location of the other replica 4. Write request MASTER 3*. 2. Identity of the primary and the locations of the other replicas Secondary Replica A W13.A.43 pushes data to all the replicas [1/2] While the data is written, each chunk server stores data in an LRU buffer until Data is used Aged out 7. Final Reply Primary Replica 5. Write request/ 6. Acknowledgement Secondary Replica B 3. pushes the data to all the replicas W13.A.44 pushes data to all the replicas [2/2] When chunk servers acknowledge receipt of data sends a write request to primary Primary assigns consecutive serial numbers to mutations Forwards to replicas W13.A.45 Data flow is decoupled from the control flow to utilize network efficiently Utilize each machine s network bandwidth Avoid network bottlenecks Avoid high-latency links Leverage network topology Estimate distances from IP addresses (in Google s data center) Pipeline the data transfer Once a chunkserver receives some data, it starts forwarding immediately. For transferring B bytes to R replicas ideal elapsed time will be B/T+RL Where, T is the network throughput L is latency to transfer bytes between two machines W13.A.46 Part 1. Large scale data analysis using MapReduce Distributed Google (): Record Append and Inconsistency W13.A.47 The control flow for record appends is similar to that of writes Google s record appends Atomic record appends pushes data to replicas of the last chunk of file Primary replica checks if the record fits in this chunk (64MB) 8

9 W13.A.48 Primary replica checks if the record append will breach the size (64MB) threshold If chunk size would be breached Pad the chunk to maximum size Tell client, that operation should be retried on next chunk If the record fits, the primary Appends data to its replica Notifies secondaries to write at the exact offset W13.A.49 Record sizes and fragmentation Size is restricted to ¼ the chunk size (16MB) Minimizes worst-case fragmentation Internal fragmentation in each chunk W13.A.50 What if the secondary replicas could not finish the write operation? request is considered failed W13.A.51 Inconsistent Regions Data 1 Data 1 Data 1 Data 2 Data 2 Data 2 Modified region is inconsistent No attempt to delete this from the chunk must handle this inconsistency retries the failed mutation Data 3 Data 3 User will re-try to store Data 3 Data 1 Data 1 Data 2 Data 2 Data 1 Data 2 Failed Empty Data 3 Data 3 Data 3 Data 3 Data 3 Data 3 W13.A.52 What if record append fails at one of the replicas must retry the operation Replicas of same chunk may contain Different data Duplicates of the same record In whole or in part Replicas of chunks are not bit-wise identical! In most systems, replicas are identical W13.A.53 only guarantees that the data will be written at least once as an atomic unit For an operation to return success Data must be written at the same offset on all the replicas After the write, all replicas are as long as the end of the record Any future record will be assigned a higher offset or a different chunk 9

10 W13.A.54 client code implements the file system API Communications with master and chunk servers done transparently On behalf of apps that read or write data Interact with master for metadata Data-bearing communications directly to chunk servers W13.A.55 Handling failed write in Hadoop HDFS [1/2] Different from 1. Pipeline is closed Any packets in the ack queue are added to the front of the data queue Datanodes that are downstream from the failed node will not miss any packets 2. The current block on the good datanodes is given a new identity Reports to the namenode To detect and delete partial block on the failed datanode later on W13.A.56 Handling failed write in Hadoop HDFS [2/2] 3. Remainder of the block s data is written to the two good datanodes in the pipeline 4. Namenode notices the block is under-replicated It arranges for a further replica to be created on another node Write quorum dfs.replication.min (default to 1) 10

CLOUD-SCALE FILE SYSTEMS

CLOUD-SCALE FILE SYSTEMS Data Management in the Cloud CLOUD-SCALE FILE SYSTEMS 92 Google File System (GFS) Designing a file system for the Cloud design assumptions design choices Architecture GFS Master GFS Chunkservers GFS Clients

More information

! Design constraints. " Component failures are the norm. " Files are huge by traditional standards. ! POSIX-like

! Design constraints.  Component failures are the norm.  Files are huge by traditional standards. ! POSIX-like Cloud background Google File System! Warehouse scale systems " 10K-100K nodes " 50MW (1 MW = 1,000 houses) " Power efficient! Located near cheap power! Passive cooling! Power Usage Effectiveness = Total

More information

GFS: The Google File System. Dr. Yingwu Zhu

GFS: The Google File System. Dr. Yingwu Zhu GFS: The Google File System Dr. Yingwu Zhu Motivating Application: Google Crawl the whole web Store it all on one big disk Process users searches on one big CPU More storage, CPU required than one PC can

More information

Distributed File Systems II

Distributed File Systems II Distributed File Systems II To do q Very-large scale: Google FS, Hadoop FS, BigTable q Next time: Naming things GFS A radically new environment NFS, etc. Independence Small Scale Variety of workloads Cooperation

More information

The Google File System

The Google File System The Google File System By Ghemawat, Gobioff and Leung Outline Overview Assumption Design of GFS System Interactions Master Operations Fault Tolerance Measurements Overview GFS: Scalable distributed file

More information

GFS: The Google File System

GFS: The Google File System GFS: The Google File System Brad Karp UCL Computer Science CS GZ03 / M030 24 th October 2014 Motivating Application: Google Crawl the whole web Store it all on one big disk Process users searches on one

More information

The Google File System

The Google File System October 13, 2010 Based on: S. Ghemawat, H. Gobioff, and S.-T. Leung: The Google file system, in Proceedings ACM SOSP 2003, Lake George, NY, USA, October 2003. 1 Assumptions Interface Architecture Single

More information

Google Disk Farm. Early days

Google Disk Farm. Early days Google Disk Farm Early days today CS 5204 Fall, 2007 2 Design Design factors Failures are common (built from inexpensive commodity components) Files large (multi-gb) mutation principally via appending

More information

Distributed Filesystem

Distributed Filesystem Distributed Filesystem 1 How do we get data to the workers? NAS Compute Nodes SAN 2 Distributing Code! Don t move data to workers move workers to the data! - Store data on the local disks of nodes in the

More information

Google File System. Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung Google fall DIP Heerak lim, Donghun Koo

Google File System. Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung Google fall DIP Heerak lim, Donghun Koo Google File System Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung Google 2017 fall DIP Heerak lim, Donghun Koo 1 Agenda Introduction Design overview Systems interactions Master operation Fault tolerance

More information

18-hdfs-gfs.txt Thu Oct 27 10:05: Notes on Parallel File Systems: HDFS & GFS , Fall 2011 Carnegie Mellon University Randal E.

18-hdfs-gfs.txt Thu Oct 27 10:05: Notes on Parallel File Systems: HDFS & GFS , Fall 2011 Carnegie Mellon University Randal E. 18-hdfs-gfs.txt Thu Oct 27 10:05:07 2011 1 Notes on Parallel File Systems: HDFS & GFS 15-440, Fall 2011 Carnegie Mellon University Randal E. Bryant References: Ghemawat, Gobioff, Leung, "The Google File

More information

Google File System (GFS) and Hadoop Distributed File System (HDFS)

Google File System (GFS) and Hadoop Distributed File System (HDFS) Google File System (GFS) and Hadoop Distributed File System (HDFS) 1 Hadoop: Architectural Design Principles Linear scalability More nodes can do more work within the same time Linear on data size, linear

More information

The Google File System

The Google File System The Google File System Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung Google SOSP 03, October 19 22, 2003, New York, USA Hyeon-Gyu Lee, and Yeong-Jae Woo Memory & Storage Architecture Lab. School

More information

The Google File System (GFS)

The Google File System (GFS) 1 The Google File System (GFS) CS60002: Distributed Systems Antonio Bruto da Costa Ph.D. Student, Formal Methods Lab, Dept. of Computer Sc. & Engg., Indian Institute of Technology Kharagpur 2 Design constraints

More information

MapReduce. U of Toronto, 2014

MapReduce. U of Toronto, 2014 MapReduce U of Toronto, 2014 http://www.google.org/flutrends/ca/ (2012) Average Searches Per Day: 5,134,000,000 2 Motivation Process lots of data Google processed about 24 petabytes of data per day in

More information

The Google File System

The Google File System The Google File System Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung December 2003 ACM symposium on Operating systems principles Publisher: ACM Nov. 26, 2008 OUTLINE INTRODUCTION DESIGN OVERVIEW

More information

The Google File System. Alexandru Costan

The Google File System. Alexandru Costan 1 The Google File System Alexandru Costan Actions on Big Data 2 Storage Analysis Acquisition Handling the data stream Data structured unstructured semi-structured Results Transactions Outline File systems

More information

The Google File System

The Google File System The Google File System Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung Google* 정학수, 최주영 1 Outline Introduction Design Overview System Interactions Master Operation Fault Tolerance and Diagnosis Conclusions

More information

Google File System 2

Google File System 2 Google File System 2 goals monitoring, fault tolerance, auto-recovery (thousands of low-cost machines) focus on multi-gb files handle appends efficiently (no random writes & sequential reads) co-design

More information

18-hdfs-gfs.txt Thu Nov 01 09:53: Notes on Parallel File Systems: HDFS & GFS , Fall 2012 Carnegie Mellon University Randal E.

18-hdfs-gfs.txt Thu Nov 01 09:53: Notes on Parallel File Systems: HDFS & GFS , Fall 2012 Carnegie Mellon University Randal E. 18-hdfs-gfs.txt Thu Nov 01 09:53:32 2012 1 Notes on Parallel File Systems: HDFS & GFS 15-440, Fall 2012 Carnegie Mellon University Randal E. Bryant References: Ghemawat, Gobioff, Leung, "The Google File

More information

Google File System. By Dinesh Amatya

Google File System. By Dinesh Amatya Google File System By Dinesh Amatya Google File System (GFS) Sanjay Ghemawat, Howard Gobioff, Shun-Tak Leung designed and implemented to meet rapidly growing demand of Google's data processing need a scalable

More information

GFS Overview. Design goals/priorities Design for big-data workloads Huge files, mostly appends, concurrency, huge bandwidth Design for failures

GFS Overview. Design goals/priorities Design for big-data workloads Huge files, mostly appends, concurrency, huge bandwidth Design for failures GFS Overview Design goals/priorities Design for big-data workloads Huge files, mostly appends, concurrency, huge bandwidth Design for failures Interface: non-posix New op: record appends (atomicity matters,

More information

CA485 Ray Walshe Google File System

CA485 Ray Walshe Google File System Google File System Overview Google File System is scalable, distributed file system on inexpensive commodity hardware that provides: Fault Tolerance File system runs on hundreds or thousands of storage

More information

The Google File System

The Google File System The Google File System Sanjay Ghemawat, Howard Gobioff and Shun Tak Leung Google* Shivesh Kumar Sharma fl4164@wayne.edu Fall 2015 004395771 Overview Google file system is a scalable distributed file system

More information

Distributed Systems. Lec 10: Distributed File Systems GFS. Slide acks: Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung

Distributed Systems. Lec 10: Distributed File Systems GFS. Slide acks: Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung Distributed Systems Lec 10: Distributed File Systems GFS Slide acks: Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung 1 Distributed File Systems NFS AFS GFS Some themes in these classes: Workload-oriented

More information

Google File System, Replication. Amin Vahdat CSE 123b May 23, 2006

Google File System, Replication. Amin Vahdat CSE 123b May 23, 2006 Google File System, Replication Amin Vahdat CSE 123b May 23, 2006 Annoucements Third assignment available today Due date June 9, 5 pm Final exam, June 14, 11:30-2:30 Google File System (thanks to Mahesh

More information

CS 138: Google. CS 138 XVI 1 Copyright 2017 Thomas W. Doeppner. All rights reserved.

CS 138: Google. CS 138 XVI 1 Copyright 2017 Thomas W. Doeppner. All rights reserved. CS 138: Google CS 138 XVI 1 Copyright 2017 Thomas W. Doeppner. All rights reserved. Google Environment Lots (tens of thousands) of computers all more-or-less equal - processor, disk, memory, network interface

More information

The Google File System

The Google File System The Google File System Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung SOSP 2003 presented by Kun Suo Outline GFS Background, Concepts and Key words Example of GFS Operations Some optimizations in

More information

CSE 124: Networked Services Lecture-16

CSE 124: Networked Services Lecture-16 Fall 2010 CSE 124: Networked Services Lecture-16 Instructor: B. S. Manoj, Ph.D http://cseweb.ucsd.edu/classes/fa10/cse124 11/23/2010 CSE 124 Networked Services Fall 2010 1 Updates PlanetLab experiments

More information

Georgia Institute of Technology ECE6102 4/20/2009 David Colvin, Jimmy Vuong

Georgia Institute of Technology ECE6102 4/20/2009 David Colvin, Jimmy Vuong Georgia Institute of Technology ECE6102 4/20/2009 David Colvin, Jimmy Vuong Relatively recent; still applicable today GFS: Google s storage platform for the generation and processing of data used by services

More information

NPTEL Course Jan K. Gopinath Indian Institute of Science

NPTEL Course Jan K. Gopinath Indian Institute of Science Storage Systems NPTEL Course Jan 2012 (Lecture 41) K. Gopinath Indian Institute of Science Lease Mgmt designed to minimize mgmt overhead at master a lease initially times out at 60 secs. primary can request

More information

7680: Distributed Systems

7680: Distributed Systems Cristina Nita-Rotaru 7680: Distributed Systems GFS. HDFS Required Reading } Google File System. S, Ghemawat, H. Gobioff and S.-T. Leung. SOSP 2003. } http://hadoop.apache.org } A Novel Approach to Improving

More information

NPTEL Course Jan K. Gopinath Indian Institute of Science

NPTEL Course Jan K. Gopinath Indian Institute of Science Storage Systems NPTEL Course Jan 2012 (Lecture 39) K. Gopinath Indian Institute of Science Google File System Non-Posix scalable distr file system for large distr dataintensive applications performance,

More information

The Google File System GFS

The Google File System GFS The Google File System GFS Common Goals of GFS and most Distributed File Systems Performance Reliability Scalability Availability Other GFS Concepts Component failures are the norm rather than the exception.

More information

This material is covered in the textbook in Chapter 21.

This material is covered in the textbook in Chapter 21. This material is covered in the textbook in Chapter 21. The Google File System paper, by S Ghemawat, H Gobioff, and S-T Leung, was published in the proceedings of the ACM Symposium on Operating Systems

More information

Lecture XIII: Replication-II

Lecture XIII: Replication-II Lecture XIII: Replication-II CMPT 401 Summer 2007 Dr. Alexandra Fedorova Outline Google File System A real replicated file system Paxos Harp A consensus algorithm used in real systems A replicated research

More information

Distributed Systems. 15. Distributed File Systems. Paul Krzyzanowski. Rutgers University. Fall 2017

Distributed Systems. 15. Distributed File Systems. Paul Krzyzanowski. Rutgers University. Fall 2017 Distributed Systems 15. Distributed File Systems Paul Krzyzanowski Rutgers University Fall 2017 1 Google Chubby ( Apache Zookeeper) 2 Chubby Distributed lock service + simple fault-tolerant file system

More information

CS /30/17. Paul Krzyzanowski 1. Google Chubby ( Apache Zookeeper) Distributed Systems. Chubby. Chubby Deployment.

CS /30/17. Paul Krzyzanowski 1. Google Chubby ( Apache Zookeeper) Distributed Systems. Chubby. Chubby Deployment. Distributed Systems 15. Distributed File Systems Google ( Apache Zookeeper) Paul Krzyzanowski Rutgers University Fall 2017 1 2 Distributed lock service + simple fault-tolerant file system Deployment Client

More information

Staggeringly Large File Systems. Presented by Haoyan Geng

Staggeringly Large File Systems. Presented by Haoyan Geng Staggeringly Large File Systems Presented by Haoyan Geng Large-scale File Systems How Large? Google s file system in 2009 (Jeff Dean, LADIS 09) - 200+ clusters - Thousands of machines per cluster - Pools

More information

Distributed Systems. 15. Distributed File Systems. Paul Krzyzanowski. Rutgers University. Fall 2016

Distributed Systems. 15. Distributed File Systems. Paul Krzyzanowski. Rutgers University. Fall 2016 Distributed Systems 15. Distributed File Systems Paul Krzyzanowski Rutgers University Fall 2016 1 Google Chubby 2 Chubby Distributed lock service + simple fault-tolerant file system Interfaces File access

More information

CPSC 426/526. Cloud Computing. Ennan Zhai. Computer Science Department Yale University

CPSC 426/526. Cloud Computing. Ennan Zhai. Computer Science Department Yale University CPSC 426/526 Cloud Computing Ennan Zhai Computer Science Department Yale University Recall: Lec-7 In the lec-7, I talked about: - P2P vs Enterprise control - Firewall - NATs - Software defined network

More information

GFS. CS6450: Distributed Systems Lecture 5. Ryan Stutsman

GFS. CS6450: Distributed Systems Lecture 5. Ryan Stutsman GFS CS6450: Distributed Systems Lecture 5 Ryan Stutsman Some material taken/derived from Princeton COS-418 materials created by Michael Freedman and Kyle Jamieson at Princeton University. Licensed for

More information

GFS-python: A Simplified GFS Implementation in Python

GFS-python: A Simplified GFS Implementation in Python GFS-python: A Simplified GFS Implementation in Python Andy Strohman ABSTRACT GFS-python is distributed network filesystem written entirely in python. There are no dependencies other than Python s standard

More information

Performance Gain with Variable Chunk Size in GFS-like File Systems

Performance Gain with Variable Chunk Size in GFS-like File Systems Journal of Computational Information Systems4:3(2008) 1077-1084 Available at http://www.jofci.org Performance Gain with Variable Chunk Size in GFS-like File Systems Zhifeng YANG, Qichen TU, Kai FAN, Lei

More information

Introduction to Cloud Computing

Introduction to Cloud Computing Introduction to Cloud Computing Distributed File Systems 15 319, spring 2010 12 th Lecture, Feb 18 th Majd F. Sakr Lecture Motivation Quick Refresher on Files and File Systems Understand the importance

More information

goals monitoring, fault tolerance, auto-recovery (thousands of low-cost machines) handle appends efficiently (no random writes & sequential reads)

goals monitoring, fault tolerance, auto-recovery (thousands of low-cost machines) handle appends efficiently (no random writes & sequential reads) Google File System goals monitoring, fault tolerance, auto-recovery (thousands of low-cost machines) focus on multi-gb files handle appends efficiently (no random writes & sequential reads) co-design GFS

More information

Distributed File Systems (Chapter 14, M. Satyanarayanan) CS 249 Kamal Singh

Distributed File Systems (Chapter 14, M. Satyanarayanan) CS 249 Kamal Singh Distributed File Systems (Chapter 14, M. Satyanarayanan) CS 249 Kamal Singh Topics Introduction to Distributed File Systems Coda File System overview Communication, Processes, Naming, Synchronization,

More information

Google File System and BigTable. and tiny bits of HDFS (Hadoop File System) and Chubby. Not in textbook; additional information

Google File System and BigTable. and tiny bits of HDFS (Hadoop File System) and Chubby. Not in textbook; additional information Subject 10 Fall 2015 Google File System and BigTable and tiny bits of HDFS (Hadoop File System) and Chubby Not in textbook; additional information Disclaimer: These abbreviated notes DO NOT substitute

More information

DISTRIBUTED FILE SYSTEMS CARSTEN WEINHOLD

DISTRIBUTED FILE SYSTEMS CARSTEN WEINHOLD Department of Computer Science Institute of System Architecture, Operating Systems Group DISTRIBUTED FILE SYSTEMS CARSTEN WEINHOLD OUTLINE Classical distributed file systems NFS: Sun Network File System

More information

DISTRIBUTED FILE SYSTEMS CARSTEN WEINHOLD

DISTRIBUTED FILE SYSTEMS CARSTEN WEINHOLD Department of Computer Science Institute of System Architecture, Operating Systems Group DISTRIBUTED FILE SYSTEMS CARSTEN WEINHOLD OUTLINE Classical distributed file systems NFS: Sun Network File System

More information

Seminar Report On. Google File System. Submitted by SARITHA.S

Seminar Report On. Google File System. Submitted by SARITHA.S Seminar Report On Submitted by SARITHA.S In partial fulfillment of requirements in Degree of Master of Technology (MTech) In Computer & Information Systems DEPARTMENT OF COMPUTER SCIENCE COCHIN UNIVERSITY

More information

GOOGLE FILE SYSTEM: MASTER Sanjay Ghemawat, Howard Gobioff and Shun-Tak Leung

GOOGLE FILE SYSTEM: MASTER Sanjay Ghemawat, Howard Gobioff and Shun-Tak Leung ECE7650 Scalable and Secure Internet Services and Architecture ---- A Systems Perspective (Winter 2015) Presentation Report GOOGLE FILE SYSTEM: MASTER Sanjay Ghemawat, Howard Gobioff and Shun-Tak Leung

More information

Abstract. 1. Introduction. 2. Design and Implementation Master Chunkserver

Abstract. 1. Introduction. 2. Design and Implementation Master Chunkserver Abstract GFS from Scratch Ge Bian, Niket Agarwal, Wenli Looi https://github.com/looi/cs244b Dec 2017 GFS from Scratch is our partial re-implementation of GFS, the Google File System. Like GFS, our system

More information

Data Storage in the Cloud

Data Storage in the Cloud Data Storage in the Cloud KHALID ELGAZZAR GOODWIN 531 ELGAZZAR@CS.QUEENSU.CA Outline 1. Distributed File Systems 1.1. Google File System (GFS) 2. NoSQL Data Store 2.1. BigTable Elgazzar - CISC 886 - Fall

More information

Flat Datacenter Storage. Edmund B. Nightingale, Jeremy Elson, et al. 6.S897

Flat Datacenter Storage. Edmund B. Nightingale, Jeremy Elson, et al. 6.S897 Flat Datacenter Storage Edmund B. Nightingale, Jeremy Elson, et al. 6.S897 Motivation Imagine a world with flat data storage Simple, Centralized, and easy to program Unfortunately, datacenter networks

More information

HDFS: Hadoop Distributed File System. Sector: Distributed Storage System

HDFS: Hadoop Distributed File System. Sector: Distributed Storage System GFS: Google File System Google C/C++ HDFS: Hadoop Distributed File System Yahoo Java, Open Source Sector: Distributed Storage System University of Illinois at Chicago C++, Open Source 2 System that permanently

More information

Cloud Computing and Hadoop Distributed File System. UCSB CS170, Spring 2018

Cloud Computing and Hadoop Distributed File System. UCSB CS170, Spring 2018 Cloud Computing and Hadoop Distributed File System UCSB CS70, Spring 08 Cluster Computing Motivations Large-scale data processing on clusters Scan 000 TB on node @ 00 MB/s = days Scan on 000-node cluster

More information

Distributed Data Store

Distributed Data Store Distributed Data Store Large-Scale Distributed le system Q: What if we have too much data to store in a single machine? Q: How can we create one big filesystem over a cluster of machines, whose data is

More information

CS /15/16. Paul Krzyzanowski 1. Question 1. Distributed Systems 2016 Exam 2 Review. Question 3. Question 2. Question 5.

CS /15/16. Paul Krzyzanowski 1. Question 1. Distributed Systems 2016 Exam 2 Review. Question 3. Question 2. Question 5. Question 1 What makes a message unstable? How does an unstable message become stable? Distributed Systems 2016 Exam 2 Review Paul Krzyzanowski Rutgers University Fall 2016 In virtual sychrony, a message

More information

Lecture 3 Google File System Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung, SOSP 2003

Lecture 3 Google File System Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung, SOSP 2003 Lecture 3 Google File System Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung, SOSP 2003 922EU3870 Cloud Computing and Mobile Platforms, Autumn 2009 (2009/9/28) http://labs.google.com/papers/gfs.html

More information

A BigData Tour HDFS, Ceph and MapReduce

A BigData Tour HDFS, Ceph and MapReduce A BigData Tour HDFS, Ceph and MapReduce These slides are possible thanks to these sources Jonathan Drusi - SCInet Toronto Hadoop Tutorial, Amir Payberah - Course in Data Intensive Computing SICS; Yahoo!

More information

CS 537: Introduction to Operating Systems Fall 2015: Midterm Exam #4 Tuesday, December 15 th 11:00 12:15. Advanced Topics: Distributed File Systems

CS 537: Introduction to Operating Systems Fall 2015: Midterm Exam #4 Tuesday, December 15 th 11:00 12:15. Advanced Topics: Distributed File Systems CS 537: Introduction to Operating Systems Fall 2015: Midterm Exam #4 Tuesday, December 15 th 11:00 12:15 Advanced Topics: Distributed File Systems SOLUTIONS This exam is closed book, closed notes. All

More information

SCALABLE CONSISTENCY AND TRANSACTION MODELS

SCALABLE CONSISTENCY AND TRANSACTION MODELS Data Management in the Cloud SCALABLE CONSISTENCY AND TRANSACTION MODELS 69 Brewer s Conjecture Three properties that are desirable and expected from realworld shared-data systems C: data consistency A:

More information

Introduction to Distributed Data Systems

Introduction to Distributed Data Systems Introduction to Distributed Data Systems Serge Abiteboul Ioana Manolescu Philippe Rigaux Marie-Christine Rousset Pierre Senellart Web Data Management and Distribution http://webdam.inria.fr/textbook January

More information

UNIT-IV HDFS. Ms. Selva Mary. G

UNIT-IV HDFS. Ms. Selva Mary. G UNIT-IV HDFS HDFS ARCHITECTURE Dataset partition across a number of separate machines Hadoop Distributed File system The Design of HDFS HDFS is a file system designed for storing very large files with

More information

Hadoop File System S L I D E S M O D I F I E D F R O M P R E S E N T A T I O N B Y B. R A M A M U R T H Y 11/15/2017

Hadoop File System S L I D E S M O D I F I E D F R O M P R E S E N T A T I O N B Y B. R A M A M U R T H Y 11/15/2017 Hadoop File System 1 S L I D E S M O D I F I E D F R O M P R E S E N T A T I O N B Y B. R A M A M U R T H Y Moving Computation is Cheaper than Moving Data Motivation: Big Data! What is BigData? - Google

More information

Exam 2 Review. Fall 2011

Exam 2 Review. Fall 2011 Exam 2 Review Fall 2011 Question 1 What is a drawback of the token ring election algorithm? Bad question! Token ring mutex vs. Ring election! Ring election: multiple concurrent elections message size grows

More information

Distributed Systems. Lec 9: Distributed File Systems NFS, AFS. Slide acks: Dave Andersen

Distributed Systems. Lec 9: Distributed File Systems NFS, AFS. Slide acks: Dave Andersen Distributed Systems Lec 9: Distributed File Systems NFS, AFS Slide acks: Dave Andersen (http://www.cs.cmu.edu/~dga/15-440/f10/lectures/08-distfs1.pdf) 1 VFS and FUSE Primer Some have asked for some background

More information

TI2736-B Big Data Processing. Claudia Hauff

TI2736-B Big Data Processing. Claudia Hauff TI2736-B Big Data Processing Claudia Hauff ti2736b-ewi@tudelft.nl Intro Streams Streams Map Reduce HDFS Pig Pig Design Pattern Hadoop Mix Graphs Giraph Spark Zoo Keeper Spark But first Partitioner & Combiner

More information

Big Data Technologies

Big Data Technologies Big Data Technologies Big Data Technologies Syllabus 1. Introduction to Big Data 1.1 Big data overview 1.2 Background of data analytics 1.3 Role of distributed system in big data 1.4 Role of data scientist

More information

Big Data Processing Technologies. Chentao Wu Associate Professor Dept. of Computer Science and Engineering

Big Data Processing Technologies. Chentao Wu Associate Professor Dept. of Computer Science and Engineering Big Data Processing Technologies Chentao Wu Associate Professor Dept. of Computer Science and Engineering wuct@cs.sjtu.edu.cn Schedule (1) Storage system part (first eight weeks) lec1: Introduction on

More information

A Distributed Namespace for a Distributed File System

A Distributed Namespace for a Distributed File System A Distributed Namespace for a Distributed File System Wasif Riaz Malik wasif@kth.se Master of Science Thesis Examiner: Dr. Jim Dowling, KTH/SICS Berlin, Aug 7, 2012 TRITA-ICT-EX-2012:173 Abstract Due

More information

Replica Placement. Replica Placement

Replica Placement. Replica Placement Replica Placement Model: We consider objects (and don t worry whether they contain just data or code, or both) Distinguish different processes: A process is capable of hosting a replica of an object or

More information

CS5412: OTHER DATA CENTER SERVICES

CS5412: OTHER DATA CENTER SERVICES 1 CS5412: OTHER DATA CENTER SERVICES Lecture V Ken Birman Tier two and Inner Tiers 2 If tier one faces the user and constructs responses, what lives in tier two? Caching services are very common (many

More information

Performance Enhancement of Data Processing using Multiple Intelligent Cache in Hadoop

Performance Enhancement of Data Processing using Multiple Intelligent Cache in Hadoop Performance Enhancement of Data Processing using Multiple Intelligent Cache in Hadoop K. Senthilkumar PG Scholar Department of Computer Science and Engineering SRM University, Chennai, Tamilnadu, India

More information

CLOUD- SCALE FILE SYSTEMS THANKS TO M. GROSSNIKLAUS

CLOUD- SCALE FILE SYSTEMS THANKS TO M. GROSSNIKLAUS Data Management in the Cloud CLOUD- SCALE FILE SYSTEMS THANKS TO M. GROSSNIKLAUS While produc7on systems are well disciplined and controlled, users some7mes are not Ghemawat, Gobioff & Leung 1 Google File

More information

Bigtable: A Distributed Storage System for Structured Data By Fay Chang, et al. OSDI Presented by Xiang Gao

Bigtable: A Distributed Storage System for Structured Data By Fay Chang, et al. OSDI Presented by Xiang Gao Bigtable: A Distributed Storage System for Structured Data By Fay Chang, et al. OSDI 2006 Presented by Xiang Gao 2014-11-05 Outline Motivation Data Model APIs Building Blocks Implementation Refinement

More information

EsgynDB Enterprise 2.0 Platform Reference Architecture

EsgynDB Enterprise 2.0 Platform Reference Architecture EsgynDB Enterprise 2.0 Platform Reference Architecture This document outlines a Platform Reference Architecture for EsgynDB Enterprise, built on Apache Trafodion (Incubating) implementation with licensed

More information

CS370 Operating Systems

CS370 Operating Systems CS370 Operating Systems Colorado State University Yashwant K Malaiya Spring 2018 Lecture 24 Mass Storage, HDFS/Hadoop Slides based on Text by Silberschatz, Galvin, Gagne Various sources 1 1 FAQ What 2

More information

Architecture of Systems for Processing Massive Amounts of Data

Architecture of Systems for Processing Massive Amounts of Data Architecture of Systems for Processing Massive Amounts of Data Milan Vojnović Microsoft Research April 2011 The Goals of this Lecture Learn about the underlying principles of system design for processing

More information

AN OVERVIEW OF DISTRIBUTED FILE SYSTEM Aditi Khazanchi, Akshay Kanwar, Lovenish Saluja

AN OVERVIEW OF DISTRIBUTED FILE SYSTEM Aditi Khazanchi, Akshay Kanwar, Lovenish Saluja www.ijecs.in International Journal Of Engineering And Computer Science ISSN:2319-7242 Volume 2 Issue 10 October, 2013 Page No. 2958-2965 Abstract AN OVERVIEW OF DISTRIBUTED FILE SYSTEM Aditi Khazanchi,

More information

The CAP theorem. The bad, the good and the ugly. Michael Pfeiffer Advanced Networking Technologies FG Telematik/Rechnernetze TU Ilmenau

The CAP theorem. The bad, the good and the ugly. Michael Pfeiffer Advanced Networking Technologies FG Telematik/Rechnernetze TU Ilmenau The CAP theorem The bad, the good and the ugly Michael Pfeiffer Advanced Networking Technologies FG Telematik/Rechnernetze TU Ilmenau 2017-05-15 1 / 19 1 The bad: The CAP theorem s proof 2 The good: A

More information

Semantics with Failures

Semantics with Failures Semantics with Failures If map and reduce are deterministic, then output identical to non-faulting sequential execution For non-deterministic operators, different reduce tasks might see output of different

More information

Introduction to Hadoop. Owen O Malley Yahoo!, Grid Team

Introduction to Hadoop. Owen O Malley Yahoo!, Grid Team Introduction to Hadoop Owen O Malley Yahoo!, Grid Team owen@yahoo-inc.com Who Am I? Yahoo! Architect on Hadoop Map/Reduce Design, review, and implement features in Hadoop Working on Hadoop full time since

More information

Introduction to MapReduce

Introduction to MapReduce 732A54 Big Data Analytics Introduction to MapReduce Christoph Kessler IDA, Linköping University Towards Parallel Processing of Big-Data Big Data too large to be read+processed in reasonable time by 1 server

More information

Big Data Analytics. Izabela Moise, Evangelos Pournaras, Dirk Helbing

Big Data Analytics. Izabela Moise, Evangelos Pournaras, Dirk Helbing Big Data Analytics Izabela Moise, Evangelos Pournaras, Dirk Helbing Izabela Moise, Evangelos Pournaras, Dirk Helbing 1 Big Data "The world is crazy. But at least it s getting regular analysis." Izabela

More information

Extreme Computing. NoSQL.

Extreme Computing. NoSQL. Extreme Computing NoSQL PREVIOUSLY: BATCH Query most/all data Results Eventually NOW: ON DEMAND Single Data Points Latency Matters One problem, three ideas We want to keep track of mutable state in a scalable

More information

Building Durable Real-time Data Pipeline

Building Durable Real-time Data Pipeline Building Durable Real-time Data Pipeline Apache BookKeeper at Twitter @sijieg Twitter Background Layered Architecture Agenda Design Details Performance Scale @Twitter Q & A Publish-Subscribe Online services

More information

CS 655 Advanced Topics in Distributed Systems

CS 655 Advanced Topics in Distributed Systems Presented by : Walid Budgaga CS 655 Advanced Topics in Distributed Systems Computer Science Department Colorado State University 1 Outline Problem Solution Approaches Comparison Conclusion 2 Problem 3

More information

Exam 2 Review. October 29, Paul Krzyzanowski 1

Exam 2 Review. October 29, Paul Krzyzanowski 1 Exam 2 Review October 29, 2015 2013 Paul Krzyzanowski 1 Question 1 Why did Dropbox add notification servers to their architecture? To avoid the overhead of clients polling the servers periodically to check

More information

Improving Distributed Filesystem Performance by Combining Replica and Network Path Selection

Improving Distributed Filesystem Performance by Combining Replica and Network Path Selection Improving Distributed Filesystem Performance by Combining Replica and Network Path Selection by Xi Li A thesis presented to the University of Waterloo in fulfillment of the thesis requirement for the degree

More information

Cloud Computing. Hwajung Lee. Key Reference: Prof. Jong-Moon Chung s Lecture Notes at Yonsei University

Cloud Computing. Hwajung Lee. Key Reference: Prof. Jong-Moon Chung s Lecture Notes at Yonsei University Cloud Computing Hwajung Lee Key Reference: Prof. Jong-Moon Chung s Lecture Notes at Yonsei University Cloud Computing Cloud Introduction Cloud Service Model Big Data Hadoop MapReduce HDFS (Hadoop Distributed

More information

Hadoop Virtualization Extensions on VMware vsphere 5 T E C H N I C A L W H I T E P A P E R

Hadoop Virtualization Extensions on VMware vsphere 5 T E C H N I C A L W H I T E P A P E R Hadoop Virtualization Extensions on VMware vsphere 5 T E C H N I C A L W H I T E P A P E R Table of Contents Introduction... 3 Topology Awareness in Hadoop... 3 Virtual Hadoop... 4 HVE Solution... 5 Architecture...

More information

Important Lessons. Today's Lecture. Two Views of Distributed Systems

Important Lessons. Today's Lecture. Two Views of Distributed Systems Important Lessons Replication good for performance/ reliability Key challenge keeping replicas up-to-date Wide range of consistency models Will see more next lecture Range of correctness properties L-10

More information

Strata: A Cross Media File System. Youngjin Kwon, Henrique Fingler, Tyler Hunt, Simon Peter, Emmett Witchel, Thomas Anderson

Strata: A Cross Media File System. Youngjin Kwon, Henrique Fingler, Tyler Hunt, Simon Peter, Emmett Witchel, Thomas Anderson A Cross Media File System Youngjin Kwon, Henrique Fingler, Tyler Hunt, Simon Peter, Emmett Witchel, Thomas Anderson 1 Let s build a fast server NoSQL store, Database, File server, Mail server Requirements

More information

Introduction to MapReduce

Introduction to MapReduce Basics of Cloud Computing Lecture 4 Introduction to MapReduce Satish Srirama Some material adapted from slides by Jimmy Lin, Christophe Bisciglia, Aaron Kimball, & Sierra Michels-Slettvet, Google Distributed

More information

Distributed Systems 8L for Part IB

Distributed Systems 8L for Part IB Distributed Systems 8L for Part IB Handout 3 Dr. Steven Hand 1 Distributed Mutual Exclusion In first part of course, saw need to coordinate concurrent processes / threads In particular considered how to

More information

CS 345A Data Mining. MapReduce

CS 345A Data Mining. MapReduce CS 345A Data Mining MapReduce Single-node architecture CPU Machine Learning, Statistics Memory Classical Data Mining Disk Commodity Clusters Web data sets can be very large Tens to hundreds of terabytes

More information

Computing Parable. The Archery Teacher. Courtesy: S. Keshav, U. Waterloo. Computer Science. Lecture 16, page 1

Computing Parable. The Archery Teacher. Courtesy: S. Keshav, U. Waterloo. Computer Science. Lecture 16, page 1 Computing Parable The Archery Teacher Courtesy: S. Keshav, U. Waterloo Lecture 16, page 1 Consistency and Replication Today: Consistency models Data-centric consistency models Client-centric consistency

More information