Ballista: Distributed compute platform implemented in Rust using Apache Arrow

https://github.com/ballista-compute/ballista

by Kinrany • 6 years ago

223 58 6 years ago

github.com

speps• 6 years ago

using Apache Arrow MEMORY MODEL

Probably got cut because of maximum title length but important nonetheless.

superbcarrot• 6 years ago

It has Rust in the title, that will be enough.

DSingularity• 6 years ago

lol

davesque2• 6 years ago

Not sure what that omitted portion would have clarified. Apache Arrow, at its core, is a memory model spec. Also, it appears that this project is using the official Rust library which is developed in the same repo as all the other language implementations. So the simple statement that they're using Apache Arrow seems adequate.

eb0la2• 6 years ago

Author is the same guy that wrote Arrow Rust library ;-)

habitue3• 6 years ago

It saddens me a little bit that a nascent protocol like arrow flight is using grpc + protobufs behind the scenes with some hacks on top to skip the cost of deserializing protobufs. It seems like a really common belief that protobufs have so much engineering time behind them and are cross-language that it's a no brainer to implement your new protocol on top of them.

In reality, all the engineering and optimization time is behind the implementations for the google internal languages, and even the python protobuf implementation is pretty bad.

Protobuf makes some stunningly bad decisions like using varints, etc that you shouldn't make the immediate assumption "google has tons of great engineers, google uses protobuf for everything internally, therefore, protobuf is a good foundation to build my new thing on top of"

In reality, path dependence and the (amazing) internal tooling ecosystem at google both play a huge part of why they use protobuf so extensively.

(Grpc is a little overly complicated to be a universal recommendation, but I could believe it's a good choice for Arrow Flight. But it seems like they didn't do grpc + arrow or grpc + flatbuffer + arrow in the hopes that "dumb" grpc + protobuf implementations would be able to still benefit. In my opinion, grpc implementations are so coupled, there's no reason to make this unnecessary concession to protobufs)

jfim• 6 years ago

I'm not sure I'd call varints a stunningly bad decision. It seems more like the kind of tradeoff one would make if storage and network transfer costs are considered to be more important than the serialization/deserialization speed.

That being said, the fact that that particular tradeoff was considered to be good for Google doesn't mean it actually is, or that it's applicable to one's application.

xiphias23• 6 years ago

I guess it was good before compression. Nowdays working with protobufs is painful inside Google as well, but at least it's supported by everything.

Most of what the CPUs at Google are doing is just copying fields from one protobuffer to another.

habitue3• 6 years ago

You're right, it's probably fair to say it's a stunningly bad tradeoff for most applications most of the time, given we have fast compression like snappy & brotli available now and cloud costs are heavily weighted towards CPU costing more than storage & network transfer

sitkack3• 6 years ago

What you describe is truly an https://github.com/TimelyDataflow/abomonation

ampdepolymerase2• 6 years ago

What are some production ready alternatives to gRPC that have both a pleasant developer experience and great performance? Apache Avro? Apache Thrift?

habitue3• 6 years ago

I think for this kind of high performance stuff, grpc is a reasonable choice. For ergonomics though, http + json is fine for many/most applications and there is a lot more widely available tooling for it than there is for grpc.

It's very possible that will change over time

(My implicit assumption here is that a project like Arrow Flight wants a cross-language, widely used foundation for their protocol, and there's not a ton of things that fit that bill. But depending on your application's needs, implementing a language-specific rpc system is perfectly acceptable, and may have even better ergonomics. Rust and Python both have a plethora of mono-lingual rpc frameworks)

hilbertseries• 6 years ago

gRPC has a pleasant developer experience? This is news to me.

jeffnappi2• 6 years ago

GraphQL is one.

Here's an article making the argument for it https://blog.spaceuptech.com/posts/why-we-moved-from-grpc-to...

e12e2• 6 years ago

Cap'n'proto?

https://capnproto.org/

lmeyerov2• 6 years ago

We directly stream arrow across devices, skipping grpc indirection / confusion, and have done that since near the beginning of arrow. Others do too, works great :)

Flight is interesting to us bc they're thinking through parallel i/o. I'm guessing grpc overhead there is more tolerable, though yeah, I'd be curious. I had similar initial reservations, esp as we were happy to remove slow google protobuf stack stuff as part of our switch to arrow :)

eb0la2• 6 years ago

Blog post that started the project. Worth reading. https://andygrove.io/2019/07/announcing-ballista/

andygrove3• 6 years ago

There is also a more recent blog post which perhaps led to the project being posted here (I am guessing).

https://andygrove.io/2021/01/ballista-2021/

Kinrany• 6 years ago

I saw the project in github.com/trending

lumost2• 6 years ago

I think it's telling on the state of rust in 2021 that this project can't compile fully for the latest rust versions. Maintaining these types of frameworks in the early days is an intensive and often thankless job, having your language leave you behind is a near guaranteed way to kill off your project, not too mention introduce the obvious "I tried using library X and hit compilation issue Y type issues".

I'm curious to see how this evolves as there are a number of motivated folks working on similar efforts such as Vega. I for one would welcome a mature rust based distributed compute platform.

andygrove3• 6 years ago

The project uses stable Rust. Which version are you trying to compile with?

frankmcsherry• 6 years ago

I think maybe they were confused by this text (which I agree has nothing to do with Rust itself breaking):

With the release of Apache Arrow 3.0.0 there are many breaking changes in the Rust implementation and as a result it has been necessary to comment out much of the code in this repository and gradually get each Rust module working again with the 3.0.0 release.

jasonpbecker2• 6 years ago

With the release of Apache Arrow 3.0.0 there are many breaking changes in the Rust implementation and as a result it has been necessary to comment out much of the code in this repository and gradually get each Rust module working again with the 3.0.0 release.

This appears to be an issue with Arrows implementation hitting a new major version and the Rust libraries not yet being compatible with the newest versions of Arrow. That's not something specific to the Rust ecosystem. It's not like a new version of Rust broke this project.

But even if it had, maintenance is always hard and the health of a project is better measured by how long it takes to be working with new, major, stable versions after widespread community adoption of those new, major, stable versions.

I don't know if Arrow 3.0 is the most commonly used implementation-- it may not have even reached that milestone.

nevi-me• 6 years ago

Arrow 3.0 will be released likely in the next week. The Rust implementation has a lot of changes because we've had to make public-facing changes, mostly for performance benefits.

georgewfraser2• 6 years ago

This kind of data infrastructure is a great use case for Rust. A lot of data infrastructure is memory-bound, so saving the memory overhead of GC is a huge win.

The use of Arrow to support multiple programming languages is also a great concept. Other distributed computing engines have ended up tied to the JVM (Spark, Presto, Kafka) as a way of avoiding serialization/deserialization costs when you go across a language boundary. Arrow is a really elegant solution, as long as you're willing to batch up operations.

MrPowers• 6 years ago

Databricks recently rebuilt Spark in C++ in a project called "Delta Engine" to overcome the JVM limitations you're pointing out. You're right, Rust is a great way to sidestep the dreaded JVM GC pauses.

sitkack3• 6 years ago

At the same time the JVM is getting better memory tracking analysis and incremental pauseless collectors (C4, ZGZ, Shenandoah, G1 improvements)

https://blogs.oracle.com/javamagazine/understanding-the-jdks...

kenhwang• 6 years ago

Our experience with Delta Engine has been that it's way more resource hungry than the JVM code it replaced. It doesn't handle resource exhaustion well at all; lots of crashing and deadlock when nearing full resource utilization.

I would love to have something more resource efficient than Spark on JVM, but Delta Engine isn't there yet.

lavender1a• 6 years ago

Dremio is a query engine for data lake that uses Apache Arrow heavily for a lot of processing. The application still runs on JVM.

secondcoming3• 6 years ago

Hopefully this is the beginning of the end for JVM use in data-centric applications like this. I'm not particularly bothered if it's Rust or C++

joshlk2• 6 years ago

I still don't understand why lots of new databases and data applications (Neo4J, Cassandra, Hadoop ...) are written in Java when it is well known that Java is not well suited to these types to tasks: GC freezes, bad memory model for large data, not fully compiled as so much slower when compared to C++, C or Rust. Why choose Java for these applications?

pjmlp5• 6 years ago

Productivity, unmatched tooling for cluster monitoring, memory safe by default, value types are coming.

And even without value types, there are off heap allocations, also if "Python" libraries can be actually written in C, so can Java ones, without loosing the plus of the ecosystem.

secondcoming3• 6 years ago

We switched from Cassandra (Java) to Scylla (C++) and saw immediate improvements in both query latency and machine count.

pjmlp5• 6 years ago

Except value types will put an end to the anti-JVM dream.

C++ is never going to be safe by default, unless ISO is willing to do a Python 3.

Rust still needs to improve its usability story against everything that is available on the JVM, and compile times, oh boy.

pjmlp5• 6 years ago

The choice of Rust as the main execution language means that memory usage is deterministic and avoids the overhead of GC pauses.

While such projects are welcomed, when value types finally land, the argumentation would need to be upgraded.

And as someone that has to track down memory issues in C and C++ projects, not having a GC doesn't mean the memory usage is deterministic.

mkevac• 6 years ago

What is a distributed compute platform? It's the one thing they are not explaining :-(

Ballista: Distributed compute platform implemented in Rust using Apache Arrow

Related Stories