Papers We Love BOS: Streaming Queries over Streaming Data

21 April 2016
http://www.meetup.com/Papers-We-Love-Boston-Cambridge/events/229581624/

Transcript

1. Papers We Love BOS: PSoup Peter Bailis @pbailis MIT & Stanford 21 April 2016
2. Who am I? Berkeley PhD ‘15, spent most of this year at MIT T-minus 11 days until tenure-track at Stanford » All about systems for next-gen data applications » Current hotness: MacroBase — automatic, large-scale analytic monitoring for IoT http://bailis.org/ http://futuredata.stanford.edu/
4. Why PSoup? Streams before streams were hot Interesting / cute idea Clean implementation Look to the past to learn for the future
5. Talk Outline History and background Crossing the streams The Trinity Lessons 4 all of us
6. Streaming is so 2016 “Big Data”: Samza / Kafka, Storm, Spark Streaming, Amazon Kinesis, Flink Basic idea: continuously processing dataflow D(A)G
7. DAG DAG DAG
8. Streams: The Big Idea Data warehouse: fixed data, changing queries Streaming: changing data, fixed queries Surprisingly hard to get right: semantics, languages, ordering, fault tolerance, efficient execution, handling multiple queries
9. Streaming is so 2016 “Big Data”: Samza / Kafka, Storm, Spark Streaming, Amazon Kinesis, Flink First approximation: today’s OSS stream processors are kind of like Hadoop in 2009 Low-level API // not much Hive / Spark SQL Not much automated query processing Not always as fast as they could be But they’re trying!
10. Streaming is so 2000 System & Project School Focus STREAM Stanford Semantics TelegraphCQ Berkeley Adaptivity Aurora Brown, Brandeis, MIT Shared execution
11. SELECT dst, COUNT(*), wtime(*) AS c FROM network.tcpdump AS st [RANGE BY '5 seconds' SLIDE BY '1 sec' START AT '2003-06-06'] GROUP BY dst; SELECT R.i, R.j, count(*) FROM R [RANGE BY '1 sec' SLIDE BY '2 sec'], S [RANGE BY '3 sec' SLIDE BY '4 sec'] WHERE R.k = S.k GROUP BY R.i, R.j HAVING R.j > C;
12. Lots to learn… Surprisingly hard to get right: semantics, languages, ordering, fault tolerance, efficient execution, handling multiple queries Literature has answers!!! They may not be right… No huge exits yet: TelegraphCQ -> Truviso -> Cisco (2012) Aurora -> StreamBase -> TIBCO (2013) …but we can learn!
13. Talk Outline History and background Crossing the streams The Trinity Lessons 4 all of us
15. Streams: The Big Idea Data warehouse: fixed data, changing queries Streaming: changing data, fixed queries This paper (PSoup): changing data, changing queries
16. PSoup Motivation » What if users register new queries on demand? May not know in advance, need back-fill » What if we don’t want to pre-compute all query results? May be rare / infrequent » It’s a cool idea… (conceived over beers?) Semantics: SELECT-FROM-WHERE… BEGIN-END
17. Big Idea Treat data and queries symmetrically Join them as needed
20. PSoup Processing Key Ideas: Treat data and queries symmetrically Build predicate index over queries Materialize result structure for rendering actual results Time: system assigned (why can this be problematic?)
21. Fancy terminology, simple ideas: STeM: holds intermediate state (e.g., for a join) Can have Query STeMs, Data STeMs… Eddy: routes tuples between STeMs Works for Joins, too
22. Predicate Indexing Classic technique (e.g., used in concurrency control, multi-query processing, etc.) Cool trick!
23. What about aggregates? Can compute aggregates over SPJ queries, Allow overlapping queries to traverse shared tree…
24. Garbage Collection? PSoup is main-memory only Can be expensive to re-execute arbitrarily in past Solution (not in this paper): punctuations! “All tuples from time T or less have arrived…” PSoup: need to punctuate queries, too…
25. Evaluation PSoup-P: partially materialize PSoup-C: fully materialize NoMat: query on demand
26. Evaluation Continued Trade-off: partial mat slower, but less space required Nitpicks: Workload is not very impressive Do the speedups really matter? (< 1ms)
27. Hot Takes PSoup = Cute, promising idea Symmetric joins = Relatively clean mechanism Paper = Not an exemplar of clarity in writing Paper = I like the idea more than the execution Overall = Interesting thought experiment Worth an after-work discussion over beer…
28. Talk Outline History and background Crossing the streams The Trinity Lessons 4 all of us
29. Processor Queries Data Results Data Warehouse changing fixed fixed Streaming Engine changing fixed fixed PSoup changing changing fixed ¿¿?? changing changing changing Can’t stop won’t stop
30. The Trinity Data Queries Results “If you take the trilogy of queries, data, and answers, then in theory with any two of them you could synthesize the third. So, for example, if I give you a some queries and some answers, you could synthesize a (non-unique) database that would produce those answers given those queries (this would be useful for generating test databases, for example). Likewise, if I give you some data and some answers, you should be able to synthesize a set of queries that would produce those answers on that data (could be useful for generating an optimizer or perhaps for security-related forensics). There may be Turing award in there somewhere.”
31. Talk Outline History and background Crossing the streams The Trinity Lessons 4 all of us
32. Why did 2000s streaming engines fall short? Too early? Wrong API? Story: PoC at major retailer… Veteran @ Brown: temporal queries were more valuable than temporal processing (everyone has WINDOW now); only finance needed latency …and yet: most serious SQL engines now support WINDOW functionality
33. Why does streaming matter today? » Decoupling storage, compute (e.g., HDFS, Kafka)? » Nowcasting / minute-level latency matters? » Poor man’s materialized view / model maintenance ? » Maybe it doesn’t matter!
34. IRL: MacroBase We’re building a new engine for prioritizing attention in data streams: analytic monitoring = anomaly detection plus summarization What can we use from the literature? » Dataflow as computing substrate + fault-tolerance » Semantics for windows, time, out of order execution What needs to be re-done? » Need support for statistical operators (e.g., KDE) » Need support for approximate computation » Need support for new edge capabilities
35. Another (Beerworthy) Idea When you squint, most problems look like joins with historical state: e.g., every web request is a just a fancy join with all other web requests previously seen… Why don’t we build services / infra like this? (Immutable logs as building blocks appx. this)
36. If I were to recommend three papers:
38. Summary PSoup: streaming queries, streaming data One weird trick: join data with queries Streaming: what is old is new again… Lots to learn from the literature! Thanks! @pbailis