Where It’s At

Data-Rich Computing: Where It’s AtParticle Physics Large HadronCollider(15PB)Human Genomics (7000PB)1GB / person 200PB+ captured 200% CAGR http://www.intttp://www.intetp://www.intel p://www.intel.://www.intel.c //www.intel.co World Wide Web (~1PB)wiki wiki iki wiki w ki wiki wi i wiki wikWikipedia (10GB)100% CAGR Internet Archive(1PB+)Typical Oil Company(350TB+)Estimated On-line RAM in Google(8PB)Personal DigitalPhotos(1000PB+)100% CAGR200 of London’s Traffic Cams(8TB/day)2004 Walmart Transaction DB(500TB)Annual EmailTraffic, no spam(300PB+)Merck Bio Research DB(1.5TB/qtr)One Day of Instant Messagingin 2002(750GB)Terashake Earthquake Model of LA Basin (1PB)MIT Babytalk Speech Experiment(1.4PB)UPMC Hospitals Imaging Data(500TB/yr)Everyday Sensing & Perception (ESP)15MB today,100s of GB soonCardiac CT4GB per 3D scan,1000s of scans/yearTerashake Sims~1 PB for LA basinObjectRecognitionGB todayTB neededData-Rich Computing Thriving in a World Awash with Data @ Intel ResearchSampling of the projectsGoal: Sample entire region at 10m resolution 6x104x 3x104x 1x104= 18x1012sample points!~1 PB of data uncompressedImage credit: Amit Chourasia, Visualization Services, SDSC100 km deepBuilding groundmodels of Southern California Steve Schlosser , Michael Ryan, Dave O’Hallaron (IRP)Harvard ground modelTime to Build:50 8core blades 8GB memory300GB diskData-Rich Computing: Where It’s At●Important, interesting, exciting research area ●Cluster approach:computing is co-located where the storage is at●Memory hierarchy issues:where the (intermediate) data are at , over the course of the computation●Pervasive multimedia sensing:processing & querying must be pushed out of the data center to where the sensors are atI know where it’s at, man!Focus of this talk:Memory Hierarchy (I):CMP Architecture●Shared H/W ResourcesOn-chip cache Off-chip PINbandwidthMain MemoryP L1P L1P L1(Distributed) Shared L2 Cache InterconnectProcessor ChipLonger latencyLower bandwidthMemoryMemory Hierarchy (II):CMPs, Memories & Disks on a LANSSD (Flash)MagneticDiskand/orMemorySSD (Flash)Magnetic Diskand/orMemory●ClusterOrders ofmagnitude differences in latency &bandwidth among the levelsDiffering accesscharacteristics:●Quirks of disk ●Quirks of flash ●Quirks of cachecoherenceMoreover, can have WAN of such ClustersHierarchy-Savvy Parallel Algorithm Design (HI-SPADE) project●Hierarchy-savvy:Hide what can be hidExpose what must be exposed Sweet-spot between ignorantand fully aware●Support:Develop the compilers, runtime systems,architectural features, etc. to realize the model Important component: fine-grain threadingGoal: Support a hierarchy-savvy model of computation for parallel algorithm designHI-SPADE project: Initial Progress●Effectively Sharing a Cache among Threads[Blelloch & Gibbons, SPAA’04]First thread scheduling policy (PDF) with provably-good shared cache performance for any parallelcomputation●W.r.t. sequential cache performanceHierarchy-savvy:automatically get good shared-cache performance from good sequential cacheperformancePL2 Cache Main MemoryShared L2 CacheP P P PMain Memory WithPDFExample: Parallel Merging in Merge Sort Work Stealing (WS):P=8Parallel Depth First (PDF):●Scheduling Threads for Constructive CacheSharing on CMPs [Chen et al, SPAA’07]Exposes differences between theory result & practiceProvides an automatic tool to select task granularityLU Merge Sort Hash Join Work Stealing (ws) vs. Parallel Depth First (pdf); simulated CMPs●Provably Good Multicore Cache Performance for Divide-and-Conquer Algorithms[Blelloch et al,SODA’08]First model considering both shared & private caches●Competing demands: share vs. don’t shareHierarchy-savvy:Thread scheduling policy achievesprovably-good private-cache & shared-cache performance, for divide-and-conquer algorithmsPL2 Cache Main Memory P P P PShared L2 Cache Main MemoryL1L1L1L1L1●Online Maintenance of Very Large Random Samples on Flash Storage [Nath & Gibbons, submitted]Flash-savvy algorithm (B-File) is 3 orders of magnitude faster & more energy-efficient than previous approaches Well-known that random writes are slow on flash; we show a subclass of “semi -random” writes are fastProgress thus far is only the tip of the iceberg:Still far from our HI-SPADE goal!Springboard for a more general study of flash-savvy algorithms based on semi-random writes (in progress)L e x a r C F c a r dData-Rich Computing: Where It’s At●Important, interesting, exciting research area●Cluster approach:computing is co-located where the storage is at ●Memory hierarchy issues:where the (intermediate) data are at , over the course of the computation●Pervasive multimedia sensing: processing & querying must be pushed out of the data center to where the sensors I know where it’s at, man!Pervasive Multimedia Sensing●Rich collection of (cheap) sensorsCameras, Microphones, RFID readers, vibration sensors, etc●Internet-connected. Potentially Internet-scaleTens to millions of sensor feeds over wide-areaPervasive broadband (wired & wireless)●Goal: Unified system for accessing, filtering, processing, querying, & reacting to sensed dataProgrammed to provide useful sensing servicesConsumer services:●Parking Space Finder●Lost & Found / Lost pet●Watch-my-child / Watch-my-parent●Congestion avoidanceHealth, Security, Commerce, and Science services:•Internet-scale Sensor Observatories•Homeland Security•Asset/Supply Chain Tracking•Low Atmosphere Climate Monitoring•Epidemic Early Warning SystemData & Query Scaling Challenges●Data scalingMillions of sensorsGlobally-dispersedHigh volume feedsHistorical dataNetRad: 100Mb/s ●Query scalingMay want sophisticated data processing on all sensor feedsMay aggregate over large quantities of data,use historical data, run continuouslyWant latest data, NOWIrisNet: Internet-scale Resource-intensive Sensor Network services●General-purpose architecture for wide-areasensor systemsA worldwide sensor web●Key Goal:Ease of service authorshipProvides important functionality for all services●Intel Research Pittsburgh + many CMUcollaboratorsFirst prototype in late 2002In ACM Multimedia, BaseNets, CVPR, DCOSS,Distributed Computing, DSC, FAST, NSDI(2),Pervasive Computing, PODC, SenSys, Sigmod(2),Data & Query Scaling in IrisNet●Store sensor feeds locallyToo much data to collect centrally●Push data processing & filtering to sensor nodesReduce the raw data to derived info, in parallel near source ●Push (distributed) queries to sensor nodesData sampled »Data queriedTied to particular place: Queries often local●Exploit logical hierarchy of sensor dataCompute answers in-networkIrisNet’s Two-Tier ArchitectureSensor Sensor SensorSensornetCreating a New IrisNet ServiceSenselet (program to filter sensor data)Extended code (application-specific aggregation)Hierarchy (XML schema)Front-end SASA OAs Query with standard DB languageImage processing steps FFFFEFF Send to OA Updates DBOnly 500 lines of new code for Parking Space Finder vs. 30K lines of IrisNet codeData-Rich Computing: Where It’s At●Important, interesting, exciting research area●Cluster approach:computing is co-located where the storage is at●Memory hierarchy issues: [HI-SPADE]where the (intermediate) data are at , over the course of the computation●Pervasive multimedia sensing: [IrisNet] processing & querying must be pushed out of the data center to where the sensors are atI know where it’s at, man!Backup SlidesTechniques for Privacy Protection●Cameras raise huge privacy concernsUse to it in London. Chicago protest●Viewed by law enforcement vs. viewed by public•IrisNet Goal:Exploit processing at the sensor node to implement privacy policies•Privileged senselet thatdetects & masks faces•All other senselets onlysee masked versionOnly tip of the icebergData Organized as Logical Hierarchy <State id=“Pennysylvinia”><County id=“Allegheny”><City id=“Pittsburgh”><Neighborhood id=“Oakland”><total-spaces>200</total-spaces><Block id=“1”><GPS>…</GPS><pSpace id=“1”><in-use>no</in-use> <metered>yes</metered></pSpace><pSpace id=“2”>…</pSpace></Block></Neighborhood><Neighborhood id=“Shadyside”>………Example XML Hierarchy IrisNet automatically partitions the hierarchy among the OAsIn-Network Query Processing:Query Evaluate Gather (QEG)/NE/PA/Allegheny/Pittsburgh/(Oakland | Shadyside) / rest of query Pittsburgh OA Q 1. Queries its XML DBDiscovers Shadyside data is cached, but not OaklandDoes DNS lookup to find IP addr for Oakland 2. Evaluate the result 3. Gathers the missing data by sending Q’ to Oakland OA Oakland OA QEG Q’Q’: /NE/PA/Allegheny/Pittsburgh/Oakland/ rest of queryCombines results & returns IrisNet’s approach。