Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- TLDR. 15 years ago they avoided SQL and created a language for streaming. Today, the industry decided that SQL materialized views with a “freshness” or time lag promise is the correct mental model.by rawgabbit
- Streaming is expensive, both in terms of machine and human cost, and the benefit is quite marginal for most applications. However, Google engineers need to get promotion somehow, you know?by 7e
- > Splitting
This is one of the things I wished for in the Beam APIs, and I'm glad they included it in the doc. Some (single) elements are bigger than a single function, and can't be processed one at a time. For example. a very large CSV file. They added support for it later (as Splittable DoFn's) but each implementation had varying support for it.
by guglecwoam - I used to be extremely into Dataflow/Apache Beam and literally had the paper printed on my desk AND the book. I agree they got Event time versus processing time and Never rely on completeness right, and I love they go deeper into why that was just a hard thing to accept. My head still hurts thinking about unbounded stream triggers and I'm happy we got around to a table-centric model. I still think taking some ideas from Spanner, databases as message bus or consistency information per row, basically in-database CQRS would have been nice, though. Great paper.by janpeuker
- I've always thought this paper was a bit of an overlooked gem: https://www.vldb.org/conf/2002/S07P01.pdf
It views stream processing as a join between queries and data, where internally everything is just materialized views probing each other.
Interesting that the authors above ended up landing in a similar place conceptually.
- I worked in the streaming area for a decade, doing research and development (see: https://scholar.google.com/citations?user=Rdf5OIYAAAAJ&hl=en). After moving on from streaming specifically and moving into the general problems in large data warehouses, I also concluded: just default to SQL for all analytics and the database lens is the best way to think about streaming for analytics.
I still do think that stream programming models are extremely interesting and powerful. But I used to think they would eventually become more mainstream as a way to elegantly program for high throughput, low latency massively parallel systems. That has not been the case, and I no longer think that it will be. People get by with the existing programming languages and models, that seems to be fine.
by scott_s - > That has not been the case, and I no longer think that it will be. People get by with the existing programming languages and models, that seems to be fine.
.. as long as the processing they do fits in a map().
I still deeply believe that a new class of programs can be unlocked by using reduce() or all_gather() in a massive concurrent stream.
In a stadium, why can't a uuid be embedded as an acoustic chirp emitted by all the smartphones, then triangulation-reduced in a 3D map of all devices, enabling a stadium-wide sound system?
Why don't we have MMORPGs that can deal with 100k users in a single game instance?
by BenoitP - > People get by with the existing programming languages and models, that seems to be fine.
People like what they like, and they have trouble with anything other than imperative structured programming. It’s been a pain over the last decade plus to get people just to try functional programming, and they already know what functions are!
It’s so hard I think it’s a losing battle. No matter how good a paradigm people will always stick to a) what they know and b) what they’re paid to know.
However, I still think there’s a future for paradigms like dataflow because LLMs use random esoteric languages with great ease, and without complaint. They will use the tool for the job, even if they’re unfamiliar with it at first. “Mainstream” doesn’t really matter anymore.
by ModernMech - You paper "A catalog of stream processing optimizations" is great! It seems like a classic in stream processing for me :)
Generally I agree with this comment. Very few niche applications require stream processing and all struggle that had been into research to enable some of the ACID properties for stream processing.
While at it, would you know how kdb+ (mostly used in finance) work? It -- together with q -- seems to achieve very low latency for real time systems.
by zekrioca - I've similarly spent a decade in the streaming space, started a stream processing startup, built three streaming platforms at various large companies... and I basically agree.
Streaming always felt like it was about to happen, and it kept not happening, in a year of the linux desktop sort of way. I (and others, who also optimistically started stream processing startups) thought it was a technology problem but ultimately it's a demand problem: very few companies actually need low latency processing. And continuously running, stateful systems are inherently more complex to operate and evolve compared to batch systems.
Now that relatively low-latency ingest into warehouses and datalakes is easily achieved, it's really hard to make the argument to invest in complicated streaming systems.
That said, it still feels like we've landed in a suboptimal spot. Stream processors (in particular, those following the dataflow model) solve two problems that are hard in batch systems:
1. Determining and signaling completeness for a time period (when have I likely received all of the data for 12:01pm, such that I can now safely process it)
2. Avoiding expensive recomputations for periodic queries
I do think long term we'll see some amount of streaming influence moving back into the batch systems, particularly as object storage gives us the ability to run stateful workloads with less operational headache.
(If anyone else finds these problems interesting, I'm hiring for my stream processing team at Cloudflare. Email in my profile)
by necubi