Presentation is loading. Please wait.

Presentation is loading. Please wait. 3 Google GFS Bigtable Mapreduce Yahoo Hadoop.

Similar presentations

Presentation on theme: " 3 Google GFS Bigtable Mapreduce Yahoo Hadoop."— Presentation transcript:



3 3 Google GFS Bigtable Mapreduce Yahoo Hadoop

4 Cloud computing


6 Why we use cloud computing?

7 Case 1: Write a file Save Computer down, file is lost Files are always stored in cloud, never lost

8 Why we use cloud computing? Case 2: Use IE --- download, install, use Use QQ --- download, install, use Use C download, install, use …… Get the serve from the cloud

9 What is cloud and cloud computing? Cloud Demand resources or services over Internet scale and reliability of a data center.

10 What is cloud and cloud computing? Cloud computing is a style of computing in which dynamically scalable and often virtualized resources are provided as a serve over the Internet. Users need not have knowledge of, expertise in, or control over the technology infrastructure in the "cloud" that supports them.

11 Characteristics of cloud computing Virtual. software, databases, Web servers, operating systems, storage and networking as virtual servers. On demand. add and subtract processors, memory, network bandwidth, storage.

12 IaaS Infrastructure as a Service PaaS Platform as a Service SaaS Software as a Service Types of cloud service

13 Software delivery model No hardware or software to manage Service delivered through a browser Customers use the service on demand Instant Scalability SaaS

14 Examples Your current CRM package is not managing the load or you simply dont want to host it in-house. Use a SaaS provider such as Your is hosted on an exchange server in your office and it is very slow. Outsource this using Hosted Exchange. SaaS

15 Platform delivery model Platforms are built upon Infrastructure, which is expensive Estimating demand is not a science! Platform management is not fun! PaaS

16 Examples You need to host a large file (5Mb) on your website and make it available for 35,000 users for only two months duration. Use Cloud Front from Amazon. You want to start storage services on your network for a large number of files and you do not have the storage capacity…use Amazon S3. PaaS

17 Computer infrastructure delivery model A platform virtualization environment Computing resources, such as storing and processing capacity. Virtualization taken a step further IaaS

18 Examples You want to run a batch job but you dont have the infrastructure necessary to run it in a timely manner. Use Amazon EC2. You want to host a website, but only for a few days. Use Flexiscale. IaaS

19 Cloud computing and other computing techniques


21 The 21 st Century Vision Of Computing Leonard Kleinrock, one of the chief scientists of the original Advanced Research Projects Agency Network (ARPANET) project which seeded the Internet, said: As of now, computer networks are still in their infancy, but as they grow up and become sophisticated, we will probably see the spread of computer utilities which, like present electric and telephone utilities, will service individual homes and offices across the country.

22 The 21 st Century Vision Of Computing Sun Microsystems co-founder Bill Joy

23 The 21 st Century Vision Of Computing

24 Definitions Cloud Grid Cluster utility

25 Definitions Cloud Grid Cluster utility Utility computing is the packaging of computing resources, such as computation and storage, as a metered service similar to a traditional public utility

26 Definitions Cloud Grid Cluster utility A computer cluster is a group of linked computers, working together closely so that in many respects they form a single computer.

27 Definitions Cloud Grid Cluster utility Grid computing is the application of several computers to a single problem at the same time usually to a scientific or technical problem that requires a great number of computer processing cycles or access to large amounts of data

28 Definitions Cloud Grid Cluster utility Cloud computing is a style of computing in which dynamically scalable and often virtualized resources are provided as a service over the Internet.

29 Grid Computing & Cloud Computing share a lot commonality intention, architecture and technology Difference programming model, business model, compute model, applications, and Virtualization.

30 Grid Computing & Cloud Computing the problems are mostly the same manage large facilities; define methods by which consumers discover, request and use resources provided by the central facilities; implement the often highly parallel computations that execute on those resources.

31 Grid Computing & Cloud Computing Virtualization Grid do not rely on virtualization as much as Clouds do, each individual organization maintain full control of their resources Cloud an indispensable ingredient for almost every Cloud


33 Any question and any comments ?

34 34 Google GFS Bigtable Mapreduce Yahoo Hadoop

35 Google Cloud computing techniques

36 Cloud Systems BigTable HBase HyperTable Hive HadoopDB GreenPlum CouchDB Voldemort PNUTS SQL Azure MapReduce BigTable-like DBMS-based VLDB09 VLDB08 OSDI06

37 The Google File System

38 The Google File System (GFS) A scalable distributed file system for large distributed data intensive applications Multiple GFS clusters are currently deployed. The largest ones have: storage nodes 300+ TeraBytes of disk storage heavily accessed by hundreds of clients on distinct machines

39 Introduction Shares many same goals as previous distributed file systems performance, scalability, reliability, etc GFS design has been driven by four key observation of Google application workloads and technological environment

40 Intro: Observations 1 1. Component failures are the norm constant monitoring, error detection, fault tolerance and automatic recovery are integral to the system 2. Huge files (by traditional standards) Multi GB files are common I/O operations and blocks sizes must be revisited

41 Intro: Observations 2 3. Most files are mutated by appending new data This is the focus of performance optimization and atomicity guarantees 4. Co-designing the applications and APIs benefits overall system by increasing flexibility

42 The Design Cluster consists of a single master and multiple chunkservers and is accessed by multiple clients

43 The Master Maintains all file system metadata. names space, access control info, file to chunk mappings, chunk (including replicas) location, etc. Periodically communicates with chunkservers in HeartBeat messages to give instructions and check state

44 The Master Helps make sophisticated chunk placement and replication decision, using global knowledge For reading and writing, client contacts Master to get chunk locations, then deals directly with chunkservers Master is not a bottleneck for reads/writes

45 Chunkservers Files are broken into chunks. Each chunk has a immutable globally unique 64-bit chunk- handle. handle is assigned by the master at chunk creation Chunk size is 64 MB Each chunk is replicated on 3 (default) servers

46 Clients Linked to apps using the file system API. Communicates with master and chunkservers for reading and writing Master interactions only for metadata Chunkserver interactions for data Only caches metadata information Data is too large to cache.

47 Chunk Locations Master does not keep a persistent record of locations of chunks and replicas. Polls chunkservers at startup, and when new chunkservers join/leave for this. Stays up to date by controlling placement of new chunks and through HeartBeat messages (when monitoring chunkservers)

48 Operation Log Record of all critical metadata changes Stored on Master and replicated on other machines Defines order of concurrent operations Also used to recover the file system state

49 System Interactions: Leases and Mutation Order Leases maintain a mutation order across all chunk replicas Master grants a lease to a replica, called the primary The primary choses the serial mutation order, and all replicas follow this order Minimizes management overhead for the Master

50 Atomic Record Append Client specifies the data to write; GFS chooses and returns the offset it writes to and appends the data to each replica at least once Heavily used by Google s Distributed applications. No need for a distributed lock manager GFS choses the offset, not the client

51 Atomic Record Append: How? Follows similar control flow as mutations Primary tells secondary replicas to append at the same offset as the primary If a replica append fails at any replica, it is retried by the client. So replicas of the same chunk may contain different data, including duplicates, whole or in part, of the same record

52 Atomic Record Append: How? GFS does not guarantee that all replicas are bitwise identical. Only guarantees that data is written at least once in an atomic unit. Data must be written at the same offset for all chunk replicas for success to be reported.

53 Detecting Stale Replicas Master has a chunk version number to distinguish up to date and stale replicas Increase version when granting a lease If a replica is not available, its version is not increased master detects stale replicas when a chunkservers report chunks and versions Remove stale replicas during garbage collection

54 Garbage collection When a client deletes a file, master logs it like other changes and changes filename to a hidden file. Master removes files hidden for longer than 3 days when scanning file system name space metadata is also erased During HeartBeat messages, the chunkservers send the master a subset of its chunks, and the master tells it which files have no metadata. Chunkserver removes these files on its own

55 Fault Tolerance: High Availability Fast recovery Master and chunkservers can restart in seconds Chunk Replication Master Replication shadow masters provide read-only access when primary master is down mutations not done until recorded on all master replicas

56 Fault Tolerance: Data Integrity Chunkservers use checksums to detect corrupt data Since replicas are not bitwise identical, chunkservers maintain their own checksums For reads, chunkserver verifies checksum before sending chunk Update checksums during writes

57 Introduction to MapReduce

58 MapReduce: Insight Consider the problem of counting the number of occurrences of each word in a large collection of documents How would you do it in parallel ?

59 MapReduce Programming Model Inspired from map and reduce operations commonly used in functional programming languages like Lisp. Users implement interface of two primary methods: 1. Map: (key1, val1) (key2, val2) 2. Reduce: (key2, [val2]) [val3]

60 Map operation Map, a pure function, written by the user, takes an input key/value pair and produces a set of intermediate key/value pairs. e.g. (docid, doc-content) Draw an analogy to SQL, map can be visualized as group-by clause of an aggregate query.

61 Reduce operation On completion of map phase, all the intermediate values for a given output key are combined together into a list and given to a reducer. Can be visualized as aggregate function (e.g., average) that is computed over all the rows with the same group-by attribute.

62 Pseudo-code map(String input_key, String input_value): // input_key: document name // input_value: document contents for each word w in input_value: EmitIntermediate(w, "1"); reduce(String output_key, Iterator intermediate_values): // output_key: a word // output_values: a list of counts int result = 0; for each v in intermediate_values: result += ParseInt(v); Emit(AsString(result));

63 MapReduce: Execution overview

64 MapReduce: Example

65 MapReduce in Parallel: Example

66 MapReduce: Fault Tolerance Handled via re-execution of tasks. Task completion committed through master What happens if Mapper fails ? Re-execute completed + in-progress map tasks What happens if Reducer fails ? Re-execute in progress reduce tasks What happens if Master fails ? Potential trouble !!

67 MapReduce: Walk through of One more Application


69 MapReduce : PageRank PageRank models the behavior of a random surfer. C(t) is the out-degree of t, and (1-d) is a damping factor (random jump) The random surfer keeps clicking on successive links at random not taking content into consideration. Distributes its pages rank equally among all pages it links to. The dampening factor takes the surfer getting bored and typing arbitrary URL.

70 PageRank : Key Insights Effects at each iteration is local. i+1 th iteration depends only on i th iteration At iteration i, PageRank for individual nodes can be computed independently

71 PageRank using MapReduce Use Sparse matrix representation (M) Map each row of M to a list of PageRank credit to assign to out link neighbours. These prestige scores are reduced to a single PageRank value for a page by aggregating over them.

72 PageRank using MapReduce PageRank using MapReduce Map: distribute PageRank credit to link targets Reduce: gather up PageRank credit from multiple sources to compute new PageRank value Iterate until convergence Source of Image: Lin 2008

73 Phase 1: Process HTML Map task takes (URL, page-content) pairs and maps them to (URL, (PR init, list-of-urls)) PR init is the seed PageRank for URL list-of-urls contains all pages pointed to by URL Reduce task is just the identity function

74 Phase 2: PageRank Distribution Reduce task gets (URL, url_list) and many (URL, val) values Sum vals and fix up with d to get new PR Emit (URL, (new_rank, url_list)) Check for convergence using non parallel component

75 MapReduce: Some More Apps Distributed Grep. Count of URL Access Frequency. Clustering (K-means) Graph Algorithms. Indexing Systems MapReduce Programs In Google Source Tree

76 MapReduce: Extensions and similar apps PIG (Yahoo) Hadoop (Apache) DryadLinq (Microsoft)

77 Large Scale Systems Architecture using MapReduce User App MapReduce Distributed File Systems (GFS)

78 BigTable: A Distributed Storage System for Structured Data

79 Introduction BigTable is a distributed storage system for managing structured data. Designed to scale to a very large size Petabytes of data across thousands of servers Used for many Google projects Web indexing, Personalized Search, Google Earth, Google Analytics, Google Finance, … Flexible, high-performance solution for all of Googles products

80 Motivation Lots of (semi-)structured data at Google URLs: Contents, crawl metadata, links, anchors, pagerank, … Per-user data: User preference settings, recent queries/search results, … Geographic locations: Physical entities (shops, restaurants, etc.), roads, satellite image data, user annotations, … Scale is large Billions of URLs, many versions/page (~20K/version) Hundreds of millions of users, thousands or q/sec 100TB+ of satellite image data

81 Why not just use commercial DB? Scale is too large for most commercial databases Even if it werent, cost would be very high Building internally means system can be applied across many projects for low incremental cost Low-level storage optimizations help performance significantly Much harder to do when running on top of a database layer

82 Goals Want asynchronous processes to be continuously updating different pieces of data Want access to most current data at any time Need to support: Very high read/write rates (millions of ops per second) Efficient scans over all or interesting subsets of data Efficient joins of large one-to-one and one-to-many datasets Often want to examine data changes over time E.g. Contents of a web page over multiple crawls

83 BigTable Distributed multi-level map Fault-tolerant, persistent Scalable Thousands of servers Terabytes of in-memory data Petabyte of disk-based data Millions of reads/writes per second, efficient scans Self-managing Servers can be added/removed dynamically Servers adjust to load imbalance

84 Building Blocks Building blocks: Google File System (GFS): Raw storage Scheduler: schedules jobs onto machines Lock service: distributed lock manager MapReduce: simplified large-scale data processing BigTable uses of building blocks: GFS: stores persistent data (SSTable file format for storage of data) Scheduler: schedules jobs involved in BigTable serving Lock service: master election, location bootstrapping Map Reduce: often used to read/write BigTable data

85 Basic Data Model A BigTable is a sparse, distributed persistent multi-dimensional sorted map (row, column, timestamp) -> cell contents Good match for most Google applications

86 WebTable Example Want to keep copy of a large collection of web pages and related information Use URLs as row keys Various aspects of web page as column names Store contents of web pages in the contents: column under the timestamps when they were fetched.

87 Rows Name is an arbitrary string Access to data in a row is atomic Row creation is implicit upon storing data Rows ordered lexicographically Rows close together lexicographically usually on one or a small number of machines

88 Rows (cont.) Reads of short row ranges are efficient and typically require communication with a small number of machines. Can exploit this property by selecting row keys so they get good locality for data access. Example:,,, VS edu.gatech.math, edu.gatech.phys, edu.uga.math, edu.uga.phys

89 Columns Columns have two-level name structure: family:optional_qualifier Column family Unit of access control Has associated type information Qualifier gives unbounded columns Additional levels of indexing, if desired

90 Timestamps Used to store different versions of data in a cell New writes default to current time, but timestamps for writes can also be set explicitly by clients Lookup options: Return most recent K values Return all values in timestamp range (or all values) Column families can be marked w/ attributes: Only retain most recent K values in a cell Keep values until they are older than K seconds

91 Implementation – Three Major Components Library linked into every client One master server Responsible for: Assigning tablets to tablet servers Detecting addition and expiration of tablet servers Balancing tablet-server load Garbage collection Many tablet servers Tablet servers handle read and write requests to its table Splits tablets that have grown too large

92 Implementation (cont.) Client data doesnt move through master server. Clients communicate directly with tablet servers for reads and writes. Most clients never communicate with the master server, leaving it lightly loaded in practice.

93 Tablets Large tables broken into tablets at row boundaries Tablet holds contiguous range of rows Clients can often choose row keys to achieve locality Aim for ~100MB to 200MB of data per tablet Serving machine responsible for ~100 tablets Fast recovery: 100 machines each pick up 1 tablet for failed machine Fine-grained load balancing: Migrate tablets away from overloaded machine Master makes load-balancing decisions

94 Tablet Location Since tablets move around from server to server, given a row, how do clients find the right machine? Need to find tablet whose row range covers the target row

95 Tablet Assignment Each tablet is assigned to one tablet server at a time. Master server keeps track of the set of live tablet servers and current assignments of tablets to servers. Also keeps track of unassigned tablets. When a tablet is unassigned, master assigns the tablet to an tablet server with sufficient room.

96 API Metadata operations Create/delete tables, column families, change metadata Writes (atomic) Set(): write cells in a row DeleteCells(): delete cells in a row DeleteRow(): delete all cells in a row Reads Scanner: read arbitrary cells in a bigtable Each row read is atomic Can restrict returned rows to a particular range Can ask for just data from 1 row, all rows, etc. Can ask for all columns, just certain column families, or specific columns

97 Refinements: Compression Many opportunities for compression Similar values in the same row/column at different timestamps Similar values in different columns Similar values across adjacent rows Two-pass custom compressions scheme First pass: compress long common strings across a large window Second pass: look for repetitions in small window Speed emphasized, but good space reduction (10-to-1)

98 Refinements: Bloom Filters Read operation has to read from disk when desired SSTable isnt in memory Reduce number of accesses by specifying a Bloom filter. Allows us ask if an SSTable might contain data for a specified row/column pair. Small amount of memory for Bloom filters drastically reduces the number of disk seeks for read operations Use implies that most lookups for non-existent rows or columns do not need to touch disk

99 Refinements: Bloom Filters Read operation has to read from disk when desired SSTable isnt in memory Reduce number of accesses by specifying a Bloom filter. Allows us ask if an SSTable might contain data for a specified row/column pair. Small amount of memory for Bloom filters drastically reduces the number of disk seeks for read operations Use implies that most lookups for non-existent rows or columns do not need to touch disk

100 100 Google GFS Bigtable Mapreduce Yahoo Hadoop

101 Yahoo Cloud computing

102 babycenter epicurious Search Results of the Future LinkedIn webmd Gawker New York Times

103 Whats in the Horizontal Cloud? Common Approaches to QA, Production Engineering, Performance Engineering, Datacenter Management, and Optimization Common Approaches to QA, Production Engineering, Performance Engineering, Datacenter Management, and Optimization ID & Account Management Monitoring & QoS Shared Infrastructure Metering, Billing, Accounting Horizontal Cloud Services Edge Content Services e.g., YCS, YCPI Provisioning & Virtualization e.g., EC2 Batch Storage & Processing e.g., Hadoop & Pig Operational Storage e.g., S3, MObStor, Sherpa Other Services Messaging, Workflow, virtual DBs & Webserving Security Simple Web Service APIs

104 Yahoo! Cloud Stack Provisioning (Self-serve) Horizontal Cloud Services …YCSYCPI Brooklyn EDGE Monitoring/Metering/Security Horizontal Cloud Services …Hadoop BATCH Horizontal Cloud Services …SherpaMOBStor STORAGE Horizontal Cloud Services VM/OS… APP Horizontal Cloud Services VM/OSyApache WEB Data Highway Serving Grid PHPApp Engine

105 Web Data Management Large data analysis (Hadoop) Structured record storage (PNUTS/Sherpa) Blob storage (SAN/NAS) Scan oriented workloads Focus on sequential disk I/O $ per cpu cycle CRUD Point lookups and short scans Index organized table and random I/Os $ per latency Object retrieval and streaming Scalable file storage $ per GB

106 The World Has Changed Web serving applications need: Scalability! Preferably elastic Flexible schemas Geographic distribution High availability Reliable storage Web serving applications can do without: Complicated queries Strong transactions

107 PNUTS / SHERPA To Help You Scale Your Mountains of Data

108 Yahoo! Serving Storage Problem Small records – 100KB or less Structured records – lots of fields, evolving Extreme data scale - Tens of TB Extreme request scale - Tens of thousands of requests/sec Low latency globally datacenters worldwide High Availability - outages cost $millions Variable usage patterns - as applications and users change 108

109 The PNUTS/Sherpa Solution The next generation global-scale record store Record-orientation: Routing, data storage optimized for low-latency record access Scale out: Add machines to scale throughput (while keeping latency low) Asynchrony: Pub-sub replication to far-flung datacenters to mask propagation delay Consistency model: Reduce complexity of asynchrony for the application programmer Cloud deployment model: Hosted, managed service to reduce app time-to-market and enable on demand scale and elasticity 109

110 E C A E B W C W D E F E What is PNUTS/Sherpa? E C A E B W C W D E F E CREATE TABLE Parts ( ID VARCHAR, StockNumber INT, Status VARCHAR … ) CREATE TABLE Parts ( ID VARCHAR, StockNumber INT, Status VARCHAR … ) Parallel database Geographic replication Structured, flexible schema Hosted, managed infrastructure A E B W C W D E E C F E 110

111 What Will It Become? E C A E B W C W D E F E E C A E B W C W D E F E E C A E B W C W D E F E CREATE TABLE Parts ( ID VARCHAR, StockNumber INT, Status VARCHAR … ) CREATE TABLE Parts ( ID VARCHAR, StockNumber INT, Status VARCHAR … ) Parallel database Geographic replication Indexes and views Structured, flexible schema Hosted, managed infrastructure

112 What Will It Become? E C A E B W C W D E F E E C A E B W C W D E F E E C A E B W C W D E F E Indexes and views

113 Scalability Thousands of machines Easy to add capacity Restrict query language to avoid costly queries Geographic replication Asynchronous replication around the globe Low-latency local access High availability and fault tolerance Automatically recover from failures Serve reads and writes despite failures Design Goals 113 Consistency Per-record guarantees Timeline model Option to relax if needed Multiple access paths Hash table, ordered table Primary, secondary access Hosted service Applications plug and play Share operational cost

114 Technology Elements PNUTS Query planning and execution Index maintenance Distributed infrastructure for tabular data Data partitioning Update consistency Replication YDOT FS Ordered tables Applications Tribble Pub/sub messaging YDHT FS Hash tables Zookeeper Consistency service YCA: Authorization PNUTS API Tabular API 114

115 Data Manipulation Per-record operations Get Set Delete Multi-record operations Multiget Scan Getrange 115

116 TabletsHash Table Apple Lemon Grape Orange Lime Strawberry Kiwi Avocado Tomato Banana Grapes are good to eat Limes are green Apple is wisdom Strawberry shortcake Arrgh! Dont get scurvy! But at what price? How much did you pay for this lemon? Is this a vegetable? New Zealand The perfect fruit NameDescriptionPrice $12 $9 $1 $900 $2 $3 $1 $14 $2 $8 0x0000 0xFFFF 0x911F 0x2AF3 116

117 TabletsOrdered Table 117 Apple Banana Grape Orange Lime Strawberry Kiwi Avocado Tomato Lemon Grapes are good to eat Limes are green Apple is wisdom Strawberry shortcake Arrgh! Dont get scurvy! But at what price? The perfect fruit Is this a vegetable? How much did you pay for this lemon? New Zealand $1 $3 $2 $12 $8 $1 $9 $2 $900 $14 NameDescriptionPrice A Z Q H

118 Flexible Schema Posted dateListing idItemPrice 6/1/ Couch$570 6/1/ Bike$86 6/3/ Car$1123 6/5/ Lamp$15 Color Red Condition Good Fair

119 Storage units Routers Tablet Controller REST API Clients Local region Remote regions Tribble Detailed Architecture 119

120 Tablet Splitting and Balancing 120 Each storage unit has many tablets (horizontal partitions of the table) Tablets may grow over time Overfull tablets split Storage unit may become a hotspot Shed load by moving tablets to other servers Storage unit Tablet


122 Accessing Data 122 SU 1 Get key k 2 3 Record for key k 4

123 Bulk Read 123 SU Scatter/ gather server SU 1 {k1, k2, … kn} 2 Get k 1 Get k 2 Get k 3

124 Storage unit 1Storage unit 2Storage unit 3 Range Queries in YDOT Clustered, ordered retrieval of records Storage unit 1 Canteloupe Storage unit 3 Lime Storage unit 2 Strawberry Storage unit 1 Router Apple Avocado Banana Blueberry Canteloupe Grape Kiwi Lemon Lime Mango Orange Strawberry Tomato Watermelon Apple Avocado Banana Blueberry Canteloupe Grape Kiwi Lemon Lime Mango Orange Strawberry Tomato Watermelon Grapefruit…Pear? Grapefruit…Lime? Lime…Pear? Storage unit 1 Canteloupe Storage unit 3 Lime Storage unit 2 Strawberry Storage unit 1

125 Updates 1 Write key k 2 7 Sequence # for key k 8 SU 3 Write key k 4 5 SUCCESS 6 Write key k Routers Message brokers 125


127 Asynchronous Replication 127

128 Goal: Make it easier for applications to reason about updates and cope with asynchrony What happens to a record with primary key Alice? Consistency Model 128 Time Record inserted Update Delete Time v. 1 v. 2 v. 3v. 4 v. 5 v. 7 Generation 1 v. 6 v. 8 Update As the record is updated, copies may get out of sync.

129 Example: Social Alice UserStatus AliceBusy West East UserStatus AliceFree UserStatus Alice??? UserStatus Alice??? UserStatus AliceBusy UserStatus Alice___ Busy Free Record Timeline

130 Time v. 1 v. 2 v. 3v. 4 v. 5 v. 7 Generation 1 v. 6 v. 8 Current version Stale version Read Consistency Model 130 In general, reads are served using a local copy

131 Time v. 1 v. 2 v. 3v. 4 v. 5 v. 7 Generation 1 v. 6 v. 8 Read up-to-date Current version Stale version Consistency Model 131 But application can request and get current version

132 Time v. 1 v. 2 v. 3v. 4 v. 5 v. 7 Generation 1 v. 6 v. 8 Read v.6 Current version Stale version Consistency Model 132 Or variations such as read forwardwhile copies may lag the master record, every copy goes through the same sequence of changes

133 Time v. 1 v. 2 v. 3v. 4 v. 5 v. 7 Generation 1 v. 6 v. 8 Write Current version Stale version Consistency Model 133 Achieved via per-record primary copy protocol (To maximize availability, record masterships automaticlly transferred if site fails) Can be selectively weakened to eventual consistency (local writes that are reconciled using version vectors)

134 Time v. 1 v. 2 v. 3v. 4 v. 5 v. 7 Generation 1 v. 6 v. 8 Write if = v.7 ERROR Current version Stale version Consistency Model 134 Test-and-set writes facilitate per-record transactions

135 Consistency Techniques Per-record mastering Each record is assigned a master region May differ between records Updates to the record forwarded to the master region Ensures consistent ordering of updates Tablet-level mastering Each tablet is assigned a master region Inserts and deletes of records forwarded to the master region Master region decides tablet splits These details are hidden from the application Except for the latency impact!

136 136 Mastering A E B W C W D E E C F E A E B W C W D E E C F E A E B W C W D E E C F E Tablet master

137 Bulk Insert/Update/Replace Client Source Data Bulk manager 1.Client feeds records to bulk manager 2.Bulk loader transfers records to SUs in batches Bypass routers and message brokers Efficient import into storage unit

138 Bulk Load in YDOT YDOT bulk inserts can cause performance hotspots Solution: preallocate tablets

139 Index Maintenance How to have lots of interesting indexes and views, without killing performance? Solution: Asynchrony! Indexes/views updated asynchronously when base table updated


141 Types of Record Stores Query expressiveness Simple Feature rich Object retrieval Retrieval from single table of objects/records SQL S3 PNUTS Oracle

142 Types of Record Stores Consistency model Best effort Strong guarantees Eventual consistency Timeline consistency ACID S3 PNUTS Oracle Program centric consistency Object-centric consistency

143 Types of Record Stores Data model Flexibility, Schema evolution Optimized for Fixed schemas CouchDB PNUTS Oracle Consistency spans objects Object-centric consistency

144 Types of Record Stores Elasticity (ability to add resources on demand) Inelastic Elastic Limited (via data distribution) VLSD (Very Large Scale Distribution /Replication) Oracle PNUTS S3

145 Data Stores Comparison User-partitioned SQL stores Microsoft Azure SDS Amazon SimpleDB Multi-tenant application databases Oracle on Demand Mutable object stores Amazon S3 Versus PNUTS More expressive queries Users must control partitioning Limited elasticity Highly optimized for complex workloads Limited flexibility to evolving applications Inherit limitations of underlying data management system Object storage versus record management

146 Application Design Space Records Files Get a few things Scan everything Sherpa MObStor Everest Hadoop YMDB MySQL Filer Oracle BigTable 146

147 Alternatives Matrix Elastic Operability Global low latency Availability Structured access Sherpa Y! UDB MySQL Oracle HDFS BigTable Dynamo Updates Cassandra Consistency model SQL/ACID 147

148 QUESTIONS? 148

149 Hadoop

150 Problem How do you scale up applications? Run jobs processing 100s of terabytes of data Takes 11 days to read on 1 computer Need lots of cheap computers Fixes speed problem (15 minutes on 1000 computers), but… Reliability problems In large clusters, computers fail every day Cluster size is not fixed Need common infrastructure Must be efficient and reliable

151 Solution Open Source Apache Project Hadoop Core includes: Distributed File System - distributes data Map/Reduce - distributes application Written in Java Runs on Linux, Mac OS/X, Windows, and Solaris Commodity hardware

152 Hardware Cluster of Hadoop Typically in 2 level architecture Nodes are commodity PCs 40 nodes/rack Uplink from rack is 8 gigabit Rack-internal is 1 gigabit

153 Distributed File System Single namespace for entire cluster Managed by a single namenode. Files are single-writer and append-only. Optimized for streaming reads of large files. Files are broken in to large blocks. Typically 128 MB Replicated to several datanodes, for reliability Access from Java, C, or command line.

154 Block Placement Default is 3 replicas, but settable Blocks are placed (writes are pipelined): On same node On different rack On the other rack Clients read from closest replica If the replication for a block drops below target, it is automatically re-replicated.

155 How is Yahoo using Hadoop? Started with building better applications Scale up web scale batch applications (search, ads, …) Factor out common code from existing systems, so new applications will be easier to write Manage the many clusters

156 Running Production WebMap Search needs a graph of the known web Invert edges, compute link text, whole graph heuristics Periodic batch job using Map/Reduce Uses a chain of ~100 map/reduce jobs Scale 1 trillion edges in graph Largest shuffle is 450 TB Final output is 300 TB compressed Runs on 10,000 cores Raw disk used 5 PB

157 Terabyte Sort Benchmark Started by Jim Gray at Microsoft in 1998 Sorting 10 billion 100 byte records Hadoop won the general category in 209 seconds 910 nodes 2 quad-core 2.0Ghz / node 4 SATA disks / node 8 GB ram / node 1 gb ethernet / node 40 nodes / rack 8 gb ethernet uplink / rack Previous records was 297 seconds

158 Hadoop clusters We have ~20,000 machines running Hadoop Our largest clusters are currently 2000 nodes Several petabytes of user data (compressed, unreplicated) We run hundreds of thousands of jobs every month

159 Research Cluster Usage

160 Who Uses Hadoop? Amazon/A9 AOL Facebook Fox interactive media Google / IBM New York Times PowerSet (now Microsoft) Quantcast Rackspace/Mailtrust Veoh Yahoo! More at

161 Q&A For more information: Website: Mailing lists:

162 162 Google GFS Bigtable Mapreduce Yahoo Hadoop

163 Summary of Applications Data Analysis Internet Service Private Cloud Web Applications Some operations that can tolerate relaxed consistency BigTable HBase HyperTable Hive HadoopDB… PNUTS

164 Architecture MapReduce-based BigTable HBase Hypertable Hive scalability fault tolerance ability to run in a heterogeneous environment DBMS-based SQL Azure PNUTS Voldemort easy to support SQL easy to utilize index, optimization method bottleneck of data storage HadoopDB sounds good Performance? Hybrid of MapReduce and DBMS a lot of work to do to support SQL data replication in file system data replication upon DBMS

165 Consistency Two kinds of consistency: strong consistency – ACID(Atomicity Consistency Isolation Durability) weak consistency – BASE(Basically Available Soft-state Eventual consistency ) C P ABigTable,HBase, Hive,Hypertable,HadoopDB C P A PNUTS SQL Azure ?


167 Further Reading Efficient Bulk Insertion into a Distributed Ordered Table (SIGMOD 2008) Adam Silberstein, Brian Cooper, Utkarsh Srivastava, Erik Vee, Ramana Yerneni, Raghu Ramakrishnan PNUTS: Yahoo!'s Hosted Data Serving Platform (VLDB 2008) Brian Cooper, Raghu Ramakrishnan, Utkarsh Srivastava, Adam Silberstein, Phil Bohannon, Hans-Arno Jacobsen, Nick Puz, Daniel Weaver, Ramana Yerneni Asynchronous View Maintenance for VLSD Databases, Parag Agrawal, Adam Silberstein, Brian F. Cooper, Utkarsh Srivastava and Raghu Ramakrishnan SIGMOD 2009 Cloud Storage Design in a PNUTShell Brian F. Cooper, Raghu Ramakrishnan, and Utkarsh Srivastava Beautiful Data, OReilly Media, 2009

168 Further Reading F. Chang et al. Bigtable: A distributed storage system for structured data. In OSDI, J. Dean and S. Ghemawat. MapReduce: Simplified data processing on large clusters. In OSDI, G. DeCandia et al. Dynamo: Amazons highly available key-value store. In SOSP, S. Ghemawat, H. Gobioff, and S.-T. Leung. The Google File System. In Proc. SOSP, D. Kossmann. The state of the art in distributed query processing. ACM Computing Surveys, 32(4):422–469, 2000.

169 2010 6


171 (CORBA) 5.1 CORBA 5.2 CORBA Java IDL Google 7.1 Google 7.2 Bigtable 7.3 Mapreduce 7.4

172 8 Yahoo 8.1 PNUTS: 8.2 Pig: 8.3 ZooKeeper: Aneka 9.1 Aneka Aneka: Greenplum 10.1 GreenPlum 10.2 GreenPlum 10.3 GreenPlum 10.4 GreenPlum Amazon dynamo 11.1 Amazon dynamo 11.2 Amazon dynamo 11.3 Amazon dynamo IBM 12.1 IBM 12.2 IBM 12.3 IBM 12.4 IBM 12.5 IBM Z 12.6 IBM 12.7

173 13 Hadoop 13.1 Hadoop 13.2 Map/Reduce HBase 14.1 HBase 14.2 HBase 14.3 HBase 14.4 HBase 14.5

174 15 Google Apps 15.1 Google App Engine 15.2 Google App Engine 15.3 Google Apps MS Azure 16.1 MS Azure 16.2 WINDOWS AZURE Amazon EC Amazon Elastic Compute Cloud 17.2 AmazonEC2 17.3


Download ppt " 3 Google GFS Bigtable Mapreduce Yahoo Hadoop."

Similar presentations

Ads by Google