Technical Documentation: ArroyoSystems/arroyo

ℹ️ Provenance: Multi-Tier Ingestion · CodeWiki Reference

Overview (`README.md`) Copy Section

[Getting started](https://doc.arroyo.dev/getting-started) | [Docs](https://doc.arroyo.dev) | [Discord](https://discord.gg/cjCr5rVmyR) | [Website](https://www.arroyo.dev)

Arroyo is a distributed stream processing engine written in Rust, designed to efficiently
perform stateful computations on streams of data. Unlike traditional batch processing, streaming engines can operate
on both bounded and unbounded sources, emitting results as soon as they are available.

In short: Arroyo lets you ask complex questions of high-volume real-time data with subsecond results.

Features Copy Chapter

🦀 SQL streaming pipelines

🚀 Scales up to millions of events per second

🪟 Stateful operations including windows and joins

🔥State checkpointing for fault-tolerance and recovery of pipelines

🕒 Time-oriented stream processing via the Dataflow model

🔌 A wide variety of connectors, including Kafka and Iceberg

Use cases Copy Chapter

Some example use cases include:

• Detecting fraud and security incidents
• Real-time product and business analytics
• Real-time ingestion into your data warehouse or data lake
• Real-time ML feature generation

Why Arroyo Copy Chapter

There are already a number of existing streaming engines out there, including Apache Flink,
Spark Streaming, and
Kafka Streams. Why create a new one?

• Serverless operations: Arroyo pipelines are designed to run in modern cloud environments, supporting seamless scaling,
  recovery, and rescheduling
• High performance SQL: SQL is a first-class concern, with consistently excellent performance
• Designed for non-experts: Arroyo cleanly separates the pipeline APIs from its internal implementation. You don't
  need to be a streaming expert to build real-time data pipelines.

Installing Copy Chapter

Arroyo ships as a single binary. You can install it locally on MacOS using Homebrew

brew install arroyosystems/tap/arroyo

or on MacOS or Linux with this script:

curl -LsSf https://arroyo.dev/install.sh | sh

or you can download a binary for your platform from the releases page.

Once you have Arroyo installed, start a cluster with

$ arroyo cluster

You can also run a cluster in Docker, with

docker run -p 5115:5115 \
      ghcr.io/arroyosystems/arroyo:latest

Then, load the Web UI at http://localhost:5115.

For a more in-depth guide, see the getting started guide.

Once you have Arroyo running, follow the tutorial to create your first real-time
pipeline.

Cloudflare Pipelines Copy Chapter

If you don't want to self-host, Arroyo is available as a fully-managed solution on the
Cloudflare Developer Platform: Cloudflare Pipelines,
now available in beta. Currently, stateless pipelines ingesting into R2 are supported, and we'll
be expanding to stateful pipelines in the near future.

Developing Arroyo Copy Chapter

We love contributions from the community! See the developer setup guide
to get started, and reach out to the team on discord or create an issue.

Community Copy Chapter

• Discord — support and project discussion
• GitHub issues — bugs and feature requests
• Arroyo Blog — updates from the Arroyo team

Overview (`k8s/arroyo/README.md`) Copy Section

Arroyo

This is the official Helm chart for deploying Arroyo, a distributed stream
processing engine, on Kubernetes.

Arroyo supports Kubernetes as both a scheduler (for running Arroyo pipeline tasks) and as as a deploy target for the
Arroyo control plane. This is the easiest way to get a production quality Arroyo cluster running.

See the docs for full information on how to use this helm chart.

Each version of the helm chart is associated by default with a particular release of Arroyo. The latest release
is 0.10.3.

Quickstart Copy Chapter

To quickly get up and running with Arroyo on a local kubernetes cluster (e.g. minikube), first create the following
configuration file:

values.yaml

artifactUrl: "/tmp/arroyo/artifacts"
checkpointUrl: "/tmp/arroyo/checkpoints"

volumes:
  - name: data
    hostPath:
      path: /tmp/arroyo 
      type: DirectoryOrCreate

volumeMounts:
  - name: data
    mountPath: /tmp/arroyo

(Note that if running on a distributed kubernetes cluster, you will need some sort of shared storage for checkpoints
and artifacts, for example an object store like S3 or GCS. See the deployment
docs for more details.)

Then you can create the cluster with

$ helm install arroyo arroyo/arroyo -f values.yaml

Once all of the pods start up (which may take a few minutes if you're deploying Postgres) you should be able to access
the Arroyo UI by running

$ open "http://$(kubectl get service/arroyo-api -o jsonpath='{.spec.clusterIP}')"

or if that doesn't work, by proxying the service:

$ kubectl port-forward service/arroyo-api 5115:80

and opening http://localhost:5115.

Configuration Copy Chapter

The Helm chart provides a number of options, which can be inspected by running

$ helm show values arroyo/arroyo

The most important options are:

• postgresql.deploy: Whether to deploy a new Postgres instance. If set to false, the chart will expect a Postgres
  instance to be available with the connection settings determined by postgresql.externalDatabase configurations
  (by default: postgres://arroyo:arroyo@localhost:5432/arroyo).
• prometheus.deploy: Whether to deploy a new Prometheus instance. If set to false, the chart will expect a
  Prometheus instance to be availble at the URL determined by prometheus.endpoint (by default: http://localhost:9090).
  Prometheus is not required for operation of the system, but is needed for the Arroyo UI metrics to function. By
  default Arroyo expects you to have a scrape interval of 5s. If you have a higher scrape interval (for example, the
  default 1m) you will need to update the prometheus.queryRate configuration to at least 4x the scrape interval.
• s3.bucket and s3.region: Configures the s3 bucket and region that will be used for storing artifacts and
  checkpoints. If using s3, the pods will need to have access to the bucket.
• outputDir: Alternatively, you may configure the pods to write artifacts and checkpoints to a local directory when
  running a local Kubernetes cluster. You will additionally need to configure volumes and volumeMounts to make this
  directory available on all of the pods.

The helm chart can be configured either via a values.yaml file or via command line arguments. See the
Helm documentation for more details.

Help Copy Chapter

If you have any questions or need help, please feel free to reach out on our
Discord server.

--- METRICS ---

• Files Extracted: 2
• Estimated Token Budget: ~2194 tokens
• Canonical Reference: https://codewiki.google/github.com/ArroyoSystems/arroyo