Slightly off-topic. "Arroyo" is a Spanish word meaning creek, or stream
Correct
I live in a California town called Arroyo Grande ("big creek")
Show HN: Arroyo – Write SQL on streaming data
21–30 of 35 posts
Re: Show HN: Arroyo – Write SQL on streaming data
#22Unbounded streams, but with watermarks (which right now seem fixed length?): https://doc.arroyo.dev/concepts#watermarks Also works based on fixed, pre-built pipelines. This is all very much in the style of most stream processing platforms today but I hope we’ll continue to move closer as an industry to having our cake and eating it: ingest everything in real-time, while serving any query (with joins) over the full da…
In SQL we currently support specifying watermarks based on SQL expressions, so it can be a bit more expressive than just the basic fixed-delay watermark: https://doc.arroyo.dev/sql/ddl#options. For watermark-based systems, I think the ideal is something that allows users to express either max latencies or statistical completeness (like, wait up to 1 minute or until an estimated 99.5% of the data is there).
Beyond that, there are systems that are more integrated end-to-end that can update as late arriving data comes in (like Materialize), and think those have there place. However for many uses of stream processing what's important is taking action once the data is complete enough, and watermarks a useful and pretty straightforward mechanism for that.
Re: Show HN: Arroyo – Write SQL on streaming data
#23In the watermarks documentation it mentions that events arriving after the watermark are dropped. Are there any plans to make this configurable (to disable dropping or trigger exception handling) and/or alertable? I can think of quite a few use cases (particularly in finance) where we'd want late-arrivals to be recorded and possibly incorporated into later or revised results, not silently dropped on the floor.
Yeah, currently late-arriving data is dropped but we will be making this more configurable. We're currently working on what we call "update tables," which means being able to emit incremental changes to state as well as final results. Once that's in we'll be able to give richer semantics around late arriving data.
Re: Show HN: Arroyo – Write SQL on streaming data
#24Would Arroyo be an alternative to Confluent KSQL?
Yes, Arroyo is an alternative to KSQL, although more in the design-space of Flink.
KSQL is pretty simple and easy to run if you already have Kafka, but will be much more expensive and harder to scale due to its reliance on Kafka streams for persistence and shuffling of data in processing DAG.
And with Confluent's embrace of Flink in the past year (https://www.confluent.io/blog/cloud-kafka-meets-cloud-flink-...) it's not clear that KSQL has much of a future.
Re: Show HN: Arroyo – Write SQL on streaming data
#25This looks great, and it’s very cool that it recommends Nomad to run it in production.
I wish more products would support (or at least document how to run on) Nomad.
Re: Show HN: Arroyo – Write SQL on streaming data
#26Re: Show HN: Arroyo – Write SQL on streaming data
#27Very exciting, how is feature parity with tinybird? https://www.tinybird.co/
I am not sure of specifics on features, but I think the fundamental difference is that Arroyo is a stream processing engine i.e., it doesn’t have a database, whereas Tinybird has the statefulness afforded by ClickHouse as its primary data store. Arroyo would be more like Flink, Tinybird would be more like ClickHouse. Disclaimer: I work for Tinybird.
Yes, that's mostly true. Arroyo is a stream processor like Flink. In Arroyo, you pre-register the queries you are interested in, and they will be compiled into streaming dataflow jobs that continuously execute as events come in. This means that we're not storing all of the raw events that come in for later querying.
However, like a database we do have a serving layer (currently only in our cloud version due to its reliance on our distributed state backend: https://doc.arroyo.dev/connectors/state) so it is possible to query the results directly from Arroyo as well.
Generally you would want to use something like Arroyo when your data is too high volume to reasonably store it all in a DB like Clickhouse, or your queries are too expensive to perform on every query, as Arroyo incrementally computes the results of the query as events come in.
There's also opportunities to use these systems together: Arroyo can pre-aggregate the high volume raw data, and then it can be inserted into a Clickhouse-based system for final processing along different dimensions.
Re: Show HN: Arroyo – Write SQL on streaming data
#28This looks great, and it’s very cool that it recommends Nomad to run it in production. I wish more products would support (or at least document how to run on) Nomad.
We're big fans of Nomad! It's what we use for scheduling in our cloud platform, due to its simplicity and scheduling speed. Although we also have great support for Kubernetes as that's what most folks will be running.
Re: Show HN: Arroyo – Write SQL on streaming data
#29Earlier quoted context omitted.
Hi there! We actually already have a built-in Nexmark source. It's pretty useful for developing new capabilities, and available as a source out of the box. Just read through the DBSP docs and it looks like it is working in a similar space. The biggest differences in my mind are around distribution and reliability. Arroyo works across a cluster of machines and has built in fault tolerance, while for DBSP that's still…
Thank you! I'll try to get something set up to compare performance of the two on the same machine.
That'd be great! We have versions of most of the nexmark queries and some internal benchmark vs Flink, we'd love to help if you're interested in benchmarking against more systems. Reach out at micah@arroyo.systems.
Re: Show HN: Arroyo – Write SQL on streaming data
#30Slightly off-topic. "Arroyo" is a Spanish word meaning creek, or stream
Yep! In California where we live, it typically refers to a seasonal desert stream that can range from a trickle to a torrent. We chose it because Arroyo is a stream processor, and it's very good at autoscaling.