6 ms·
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 dese
by habitue 6y 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 6y agoI'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.
- xiphias2 6y agoI 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.
- cogman10 6y agoI think that's a fair description of pretty much every webapp :D Most of them are doing nothing more than copying data from the database into an http stream.
- ithkuil 6y agoWell, all what CPUs do is copying memory from one memory location to another, perform some arithmetic and do some conditional jumps :-)
- cogman10 6y agopop pop jump jump oh what a crunch it is. (sung to this tune https://www.youtube.com/watch?v=iENQXIQ8wH0 https://www.youtube.com/watch?v=iENQXIQ8wH0 ) Side note: It really is incredible what happened in the early days of computing when memory and computation were limited. How much care was taken in the precise layout of memory or even the timing of a calculation was insane.
- xiphias2 6y agoMost of the arithmetic is checking optional fields if they are empty or not before copying :)
- xiphias2 6y agoSure, but when you are using C++, protobufs are not the best way to store data...but I guess it could be worse.
- munk-a 6y agoDon't forget the validation! Webapps are dumb middleware that pipes data from the database into an http stream - but it needs to determine which database calls to invoke and sanitize all the incoming junk.
- lmeyerov 6y agoWe use arrow to do the validation 'for free': it has a typed columnar schema, so by passing the schema, we get the recordset validation without inspecting values. we still need to do semantic validation, but w/ arrow, now we do that in bulk and on gpus :)
- habitue 6y agoYou'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
- sitkack 6y agoWhat you describe is truly an https://github.com/TimelyDataflow/abomonation https://github.com/TimelyDataflow/abomonation
- ampdepolymerase 6y agoWhat are some production ready alternatives to gRPC that have both a pleasant developer experience and great performance? Apache Avro? Apache Thrift?
- habitue 6y agoI 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 6y agogRPC has a pleasant developer experience? This is news to me.
- riku_iki 6y agoMaybe it is relatively pleasant when compared to alternatives.
- ampdepolymerase 6y agoIt doesn't.
- jeffnappi 6y agoGraphQL is one. Here's an article making the argument for it https://blog.spaceuptech.com/posts/why-we-moved-from-grpc-to-graphql/ https://blog.spaceuptech.com/posts/why-we-moved-from-grpc-to...
- e12e 6y agoI think that if you honestly consider GraphQL a better fit than gRPC, you probably should never have considered gRPC to begin with... And much as we're considering GraphQL for some services as work... I'm not sure I buy it as an RPC framework. I suppose it has about the same appeal as SOAP for that purpose.
- deleted 6y ago[deleted]
- lmeyerov 6y agoWe 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 :)