Send the link below via email or IMCopy
Present to your audienceStart remote presentation
- Invited audience members will follow you as you navigate and present
- People invited to a presentation do not need a Prezi account
- This link expires 10 minutes after you close the presentation
- A maximum of 30 users can follow your presentation
- Learn more about this feature in our knowledge base article
Do you really want to delete this prezi?
Neither you, nor the coeditors you shared it with will be able to recover it again.
Make your likes visible on Facebook?
You can change this under Settings & Account at any time.
Democratizing Data-Intensive Computing
Transcript of Democratizing Data-Intensive Computing
Goal: 102 servers for $1M + $200K switches+racks
Two-tier: performance (P) and storage (S)
Large (5PB) + cheap + fast (400+GBps) Computational Turbulence 100s TBs to PB Analyze dynamics on the fly Store few snapshots DNS simulation But what if ? new questions arise need time evolution Then one can..... repeat the simulation keep massive data sets to reload Both require Very large simulations remain out of reach of most.
The problem will not automatically get better--even if wires get faster, size of “top-ranked simulations” growing even faster: i.e. without changing current approach, top-ranked simulations will be accessible only to a shrinking subset of the scientific community.
--Charles Meneveau The resource keeping pace with simulation
size is capacity The JHU Turbulence Database Cluster Complete space/time DNS history of isotropic 16T and MHD 40T turbulence. 1024 timesteps on a 1024 grid. 3 ad hoc inspection
feature extraction (landmark database)
retrospective studies, repeatability, archival
Database "stores" the computational effort separate simulation (solving) from the experiment repeat experiments without repeating computation high-resolution data without HPC observe the simulation New applications and new access patterns iterate back and forth in time track particles back in time examine large temporal spans Spatially-partitioned
scale-out cluster Move the computation to the data (active database, UDFs) Web services interfaces
to R, Fortran, C, Python) Interface Design Too low-level e.g., get velocity at a point
few opportunities for optimization
bulk data transfer
Too high-level e.g., track 1M particles through 1K timestep
scientist cannot customize experiment
no transparency, interactivity Batches of points with server side interpolation, gradients, filters compute/data intensive tasks at server
I/O optimizations possible
client code customizes experiment (e.g., particle mass) Iterate back in time.
Not possible during DNS. 36-nodes, 1200W, <30K$
Zotac Atom/ION motherboards
4GB of memory, N330 dual core Atom, 16 GPU cores
Aggregate disk space 43.6TB
63 x 120GB SSD= 7.7 TB
27x 1TB Samsung F1 = 27.0 TB
18x.5TB Samsung M1= 9.0 TB
I/O Performance: 18GB/s "The only things you have to fear are failure and success."
-- Jim Gray JAWS: Job-Aware Workload Scheduling Distributed and Streaming Evaluation I/O bound (>80% time loading data) 50B queries, 135 users DB scan queries last hours to days Single query can consume
all I/O resources Liferaft: I/O Sharing among Queries Data-driven batch scheduling
Co-schedule sub-queries that share data (by spatial region)
Avoid indefinite starvation
Coordinate cache with scheduler Sequences of turbulence queries (jobs)
defined by nested for loops
not fully declarative With knowledge of jobs??
Evaluate data sharing among all jobs pairwise Greedily assemble a global schedule
that maximizes data sharing Lagrange interpolation the
fundamental operation Batches of points from same
job share data requirements Evaluate points in a single-streaming pass based on a partial sums evaluation of Lagrange polynomials Lesson learned: the utility of data-intensive services depends on I/O performance I/O sharing and data streaming for high-throughput science
Support concurrent users
Scale-up and scale-out for workload is more difficult than for capacity
I/O Challenges for Massive Graphs supercomputing
cloud batch analysis engines
custom hardware (Cray XMT) All require in-memory or semi-external
memory representations of graphs
small and shrinking diameter
no good cuts
bad I/O lower bounds I/O unfriendly (traversal) algorithms Source: https://http://sixdegrees.hu/last.fm/ I/O friendly (sort-like) algorithms
minimum spanning forest
and anything else you really want to know n-body: 1M nodes, 10k snapshots 500M FB users
1B phone calls We reject in-memory graphs as undemocratic! I/O Tricks Don't Work Can we build data-intensive analysis for graphs? What's Hard about Graphs?? Too big for in-memory. Can't do I/O reasonably. Partition and parallelize (no good partitions)
Localize and cache (no locality)
Stream data (no natural orderings) human dmri human brain: 10 vertices, 10 edges 11 15 Current computing paradigms: Brains aren't social networks. spatial properties
locality? Final Thoughts Data-intensive services have revolutionized public access to high-resoluation scientific data Astrophyics (surveys and n-body)
Environmental (observational and models)
Genomics, biology, and bioinformatics Data in graphs and networks represent the next frontier (with fundamental obstacles)