Downloaded 12 times
Uploaded byAnkur Dave
CloudClustering: Toward an Iterative Data Processing Pattern on the Cloud
This document proposes CloudClustering, an iterative data processing pattern for the cloud. It uses K-means clustering as an example application. CloudClustering is designed to be efficient, fault tolerant, and leverage native cloud services. It uses multiple queues to improve data locality during iterative computation. A buddy system provides distributed fault detection and recovery to handle failures in a fault-tolerant manner. Evaluation shows linear speedup with increasing instances and sublinear speedup with increasing instance size due to I/O bandwidth constraints.
CloudClustering: Toward an Iterative Data Processing Pattern on the Cloud
- 1. CloudClusteringToward an IterativeData Processing Pattern on the CloudAnkur Dave*, Wei Lu†, Jared Jackson†, Roger Barga†*UC Berkeley†Microsoft Research
- 2.
- 3. BackgroundMapReduce and itssuccessors reimplement communication and storageBut cloud services like EC2 and Azure natively provide these utilitiesCan we build an efficient distributed application using only the primitives of the cloud?
- 4. Design GoalsEfficient FaulttolerantCloud-native
- 5. OutlineWindows AzureK-Means clusteringalgorithmCloudClustering architectureData localityBuddy systemEvaluationRelated work
- 6. Windows AzureVM instancesBlobstorageQueue storage
- 7. OutlineWindows AzureK-Means clusteringalgorithmCloudClustering architectureData localityBuddy systemEvaluationRelated work
- 8. K-Means algorithmInitializeAssign pointsto centroidsRecalculate centroidsCentroidsPoints moved?Iteratively groups 𝑛 points into 𝑘 clusters
- 9. K-Means algorithmInitializePartition workAssignpoints to centroidsCompute partial sumsRecalculate centroidsPoints moved?
- 10. OutlineWindows AzureK-Means clusteringalgorithmCloudClustering architectureData localityBuddy systemEvaluationRelated work
- 11. ArchitectureInitializePartition workAssign pointsto centroids⋮ Centroids: {𝑐1, …, 𝑐𝑛} Compute partial sumsRecalculate centroidsPoints moved?
- 12. OutlineWindows AzureK-Means clusteringalgorithmCloudClustering architectureData localityBuddy systemEvaluationRelated work
- 13. Data locality⋮ Single-queue patternis naturally fault-tolerantProblem: Not suitable for iterative computationMultiple-queue pattern unlocks data localityTradeoff: Complicates fault tolerance
- 14. OutlineWindows AzureK-Means clusteringalgorithmCloudClustering architectureData localityBuddy systemEvaluationRelated work
- 15. Handling failureInitializePartition workAssignpoints to centroidsCompute partial sumsStall?-> Buddy system Recalculate centroidsPoints moved?
- 16. Buddy systemBuddy systemprovides distributed fault detection and recovery
- 17. Buddy systemFault domain123Spreadingbuddies across Azure fault domains provides increased resilience to simultaneous failure
- 18. Buddy systemvs.…Cascaded failuredetection reduces communication and improves resilience
- 19. OutlineWindows AzureK-Means clusteringalgorithmCloudClustering architectureData localityBuddy systemEvaluationRelated work
- 20. EvaluationLinear speedup withinstance count
- 21. EvaluationSublinear speedup withinstance sizeReason: I/O bandwidth doesn’t scale
- 22. OutlineWindows AzureK-Means clusteringalgorithmCloudClustering architectureData localityBuddy systemEvaluationRelated work
- 23. Related workExisting frameworks(MapReduce, Dryad,Spark,MPI, …)all support K-Means, but reimplementreliable communicationAzureBlast built directly on cloud services, but algorithm is not iterative
- 24. ConclusionsCloudClustering shows thatit's possible to build efficient, resilient applications using only the common cloud servicesMultiple-queue pattern unlocks data localityBuddy system provides fault tolerance
Editor's Notes
- #2 Thanks for the introductionUndergrad at UC BerkeleyPresenting CloudClustering: data-intensive app on cloudQuestions inline
- #3 Joint work with Wei Lu, Jared Jackson, and Roger Barga of MSRGlad to have him in the audience
- #4 MapReduce, Dryad,Twister, HaLoop, Spark:useful abstraction for programming the cloudMapReduce,Dryad:acyclic data flowsSuccessors:iterativeCommunication and storage: sockets, replicationEC2,Azure provide thisCan use only “primitives of the cloud”? -> Simpler
- #5 Fast:data locality and cachingResilient to failureUse only existing cloud services -- reliable building blocks
- #6 What we will do:Used Azure to build CloudClusteringImplements K-MeansCloudClustering architecture: building blocks -> efficient, fault-tolerantBenchmarks of CloudClustering running on AzureRelated work
- #7 Windows/.NET based cloud offeringRun user code on VM instances.Instance fails -> automatically recovered-> Central blob storage, 3x replicated. Limited by network-> Queue storage: small messages
- #8 K-Means: widely used, well-understood
- #9 Iterative clustering algorithmGroups n points into k clusters, n >> k-> Initial set of cluster centers -> centroids-> Points assigned to closest centroids-> Centroids move to average of their points-> Repeats until convergence
- #10 Easy to parallelizeMaster: initial centroids-> Partition points, split across workers-> On workers, same as before for partition-> All returned: averages, move centroids-> Iterate until convergence
- #11 How it’s implemented
- #12 Master supervises pool of workers-> Coordinate using queues->First,master loads input into blob storage-> Generates initial centroids-> Sends command to workers: ptr to partition, list of centroids-> Workers do computation-> Generate partial sums-> All returned: master recalculates centroids-> Next iteration
- #13 2 modifications for efficiency and fault toleranceFirst: data locality
- #14 Conventional: single queueFault tolerance easy. All state in messages. Failure -> throughput reducedNo good for iterative: no data locality-> Multiple queues: unlocks data localityBut complicates fault tolerance
- #15 Efficiency with fault tolerance: buddy system
- #16 Why failure is a problem?-> When worker fails-> Can’t report to master-> Stall-> Buddy system
- #17 Conventional: heartbeat over socketsDesign goals: use cloud servicesInsight: working on task when fail. Queue reliable -> have a recordPeer-to-peer: master assigns into buddy groups-> Each polls queues of others-> When fail-> Tasks in queue for longer than timeout-> Buddies dequeue tasks, complete themSize: tradeoff between fault tolerance and network trafficLarge group -> resilient to simultaneous, but more polling traffic (charge per transaction)
- #18 Fault domains: reduce likelihood of sim.failFault domains: prob. of sim.failAllocation algorithm spreads across fault domains
- #19 Workers -> nodes in graphEdges -> polling queue of another instanceBuddy system: disconnected cliques-> Alternative: cascaded failure detectionTotal ordering of workersEach polls the next, circularLess traffic, better resilienceFuture work
- #20 Performance
- #21 Linear speedup as increase number of instances16 instances and 1 GB data
- #22 Sublinear speedup with faster machinesBecause I/O bandwidth doesn’t always improveUse multiple threads, but I/O is bottleneck
- #23 Related work
- #24 All frameworks support K-MeansMapReduce, Dryad: no iteration, launch from driverImplement communication using socketsAzureBlast: NCBI-BLAST genetic tool on cloud servicesNot iterative -> different challenges
- #25 Can build efficient, resilient with only cloud servicesHelpful patterns: multiple queues, buddy system