Programming models for data-intensive computing

1. Programming models fordata-intensive computing

2. A multi-dimensional problem • Sophistication of the target user • N(data analysts) > N(computational scientists) • Level of expressivity • High level important for interactive analysis • Volume of data • The complex gigabyte vs. the enormous petabyte • Scale and nature of platform • How important are reliability, failure, etc. • What QoS needs? Where enforced?

3. Separating concerns • What things carry over from conventional HPC? • Parallel file systems, collective I/O, workflow, MPI, OpenMP, PETsc etc., ESMF • What things carry over from conventional data? • Need for abstractions and data-level APIs: R, SPSS, MatLab, SQL, NetCDF, HDF, Kepler, Taverna • Streaming databases, streaming data systems • What is unique to “data HPC”? • New needs at the platform level • New tradeoffs between HL and platform

4. Current models • Data-parallel • A space of data objects • A set of operators on those objects • Streaming • Scripting

5. Conclusions • Current HPC programming models fail to address important data-intensive needs • An urgent need for a careful gap analysis aimed at identifying important things that cannot [easily] be done with current tools • Ask people for their “top 20” questions • Ethnographic studies • A need to revisit the “stack” from the perspective of data-intensive HPC apps

6. Programming models for data-intensive computing • Will flat message-passing model scale for >1M cores? • How does multi-level //ism impact DIC (e.g., GPUs) • MR, Dryad, Swift—what apps do they support? – how suited for PDEs • How will 1K-core PCs change DIC? • Powerful data-centric programming primitives to express HL //ism in a natural way while shielding physical configuration issues—what do we need? • If we design a supercomputer for DIC, what are reqs? • If storage controllers allow application-level control? Permit cross-layer control • New frameworks for reliability and availability (go beyond checkpointing) • How will different models and frameworks interoperate? • How do we support people who want large shared memory?

7. Programming models • Data parallel – MapReduce • Loosely synchronized chunks of work – Dryad, Swift, scripting • Libraries – e.g., Ntropy • Expressive power vs. scale • BigTable (Hbase) • Streaming, online • Dataflow • What operators for data-intensive computing? (>M/R) • Sum, Average, … • Two main models • Data parallel • Streaming • Goal: “use within 30 minutes; still discovering new power in 2 years time” • Integration with programming environments • Working remotely with large datasets

8. Dataset – put in time domain, freq domain, plot the result • Multiple levels of abstraction? All-pairs. • Note that there are many ways to express things at the high level, the challenge is implementing things • “Users don’t want to compile anymore” • Who are we targeting? Specialists or generalist? • Focus on need for rapid decision making • Composable models • Dimensions of problem • Level of expressivity • Volume of data • Scale of platform – reliability, failure, etc. • Gauge the size of the problem you are asking to solve • QoS guarantees • Ability to practice on smaller datasets

9. Types of data + nature of the operators • Select, e.g. on spatial region, temporal operators • Data scrubbing: Data transposition, transforms • Data normalization • Statistical analysis operators • Look at LINQ • Aggregation – combine • Smart segregation to fit on the hardware • Need to deal with distributed data – e.g., column-oriented stores can help with that

10. What things carry over from conventional HPC • Parallel file systems, collective I/O, workflow, MPI, OpenMP, PETsc etc., ESMF • What things carry over from conventional data • Need for abstractions and data-level APIs: R, SPSS, MatLab, SQL, NetCDF, HDF, Kepler, Taverna • What is unique to data HPC

11. Moving forward • Ethnographic studies (e.g., Borgman) • Ask for people’s top 20 questions/scenarios • Astronomers • Environmental science • Chemistry … • … • E.g., see SciDB is reaching out to communities

12. DIC hardware architecture • Different compute-I/O balance • 0.1 B/flop for supercomputer (“all mem to disk in 5 mins” is an unrealizable goal) • Assume that it should be greater: Amdahl • See Alex Szalay paper • GPU-like systems but with more memory per core • Future streaming rates – what are they? • Innovating networking—data routing • Heterogeneous systems perhaps –e.g., M vs Ws • Reliability – where is it implemented? • What about software failures • A special OS? • New ways of combining hardware and software? • Within a system, and/or between systems

13. Modeling • “Query estimation” and status monitoring for DIC applications

14. 1000-core PCs • Increases data management problem • Enables a wider range of users to do DIC • More complex memory hierarchy—200 mems • We’ll have amazing games with realistic physics

15. Infinite bandwidth • Do everything in the cloud

16. MapReduce-related thoughts • MR is library-based. This makes optimization more difficult. Type checking. Annotations. • Are there opportunities for optimization if we incorporate ideas into extensible languages? • Ways to enforce/leverage/enable domain-specific semantics. • Interoperability/portability?

17. Most important ideas • How badly it doesn’t work so well: current HPC practice fails for DIC. Make it easier for the domain scientist, enable new types of science • Gap analysis—articulate what we can do with MPI and MR; what we can’t do with either, and why • Propagating information between layers