So, all right, there we go.
Hey everybody, thank you very much.
Wow, it's loud.
Free applause.
I like it.
Hey everybody, good.
So, I don't know if anyone recognizes what movie this is from.
So, dog day afternoon, because hostage situation, because the title of the talk.
Bad pun.
I know.
Anyways.
So, in 2017 at VLDB, Honda's Mielsen and Mark Roosevelt gave a talk and had this paper about,
don't hold my data hostage.
Specifically talking about the details and problems with the formats that are used for query,
retrieval.
And this was a big deal when they gave it.
And lots of data systems are adopting what they learned, I'm going to go over.
But it's still need more.
And so, a lot of what the paper is about is that databases have their own client server protocols constantly.
And there's three, there's a few specific points that the day paper makes.
That if you benchmark query result retrieval in the various protocols of major day systems, they're slow.
And in fact, while we focused so much over the years on query execution and planning and optimization,
the actual protocols used for query retrieval for results have kind of stagnated.
And end up being the bottleneck very frequently.
And so, they proposed a novel client protocol that solved the problems they were observing.
And then they benchmark that against a bunch of the major day systems.
And the central observation is that query result retrieval is expensive.
And largely, it's expensive because of the overhead done by serializing and decelerizing those results,
the data.
As you're passing it from the server, the database to whatever client, you're serializing it over there,
decelerizing it in the client, over and over again.
And that overhead becomes the bottleneck and makes it very expensive.
And so, they tested a few different things.
And they examined data in a row oriented formats and calmering to format,
and row oriented serializations cause a number of different inefficiencies.
If you compare row oriented formats to calm formats, like we use calm oriented formats internally of databases,
constantly for vectorization purposes, simply in all the benefits they're in.
But when you're talking about serializing the data over the wire,
everyone still constantly ends up using row oriented serialization formats,
even though they don't compress as well as a calmering to format.
And more importantly, both the source system and the client system are increasingly calmer oriented internally,
which means that because you're using a row oriented transport,
the source system has to transpose all that data into rows to pass across the network.
And then your client, transposes it all back into columns over and over again.
Instead of just leaving it in the column oriented format the whole way through,
because that would make more sense wouldn't it?
And so they look at their novel protocol that was calmer oriented.
And then they also tested it against various bandwidth conditions,
because it's not only about the size of the data payloads.
It's also about how it deals with the various bandwidth conditions.
And what they found was heavyweight compression only gives you a speed-up when the connection between your client server are very slow.
If the connection is actually very fast,
the overhead of performing the compression is more expensive than any slowdown because the payloads large.
Which means that lightweight compressions are much more effective at speeding up a treeval at the network speeds that were common back in 2017,
which have only gotten faster in the almost the decade since,
which means that if your connection is super fast and they tested it on your specific loopback local connection,
your best bet is just don't even bother with the compression.
Because if the network's fast enough, any actual cost of performing the compression and decompression is more expensive than the transport,
transport cost.
So of course their novel protocol made compression optional.
And so when you compare the various timings and the benchmark,
their protocol against the common ones the day.
And then you can see in bold the best performing scenario here,
which was their protocol was the MonetDB because they would go on to make ductDB anyways.
So the novel protocol was faster than any of the existing database protocols that were existing at the time.
Because of all of these benefits that you get from a column oriented client server protocol where compression is optional,
where you enable all of these things on arbitrarily fast connections,
and even that slow connections it's still more efficient to perform this way.
And so they wrap up the paper emphasizing that these row-based protocols,
which were originally designed in a very different era,
are just not suitable for modern data analytic needs,
and they're increasingly a poor decision.
And yet we're still using them nearly a decade later.
So that was in 2017.
In 2016 just before that,
the Pachiaro became a top level project of the Pachian Foundation.
Arrow was brand new.
We don't know if Honness and Mark knew about Arrow at the time they wrote the paper,
but even if they did, Arrow was so new that it was unclear whether or not Arrow actually offered the solutions.
But what they described, their novel protocol,
was for all intents and purposes, Arrow pretty much.
There's a few minor differences here and there,
but for all intents and purposes,
a compression optional batch column oriented format for data transportation,
communication, and for data computation,
that has almost no serialized nation overhead.
The bytes on the wire are the bytes in memory,
small little flap buffer header,
but for the most part, the bytes are as they are,
compression is optional, and so on.
And so in the earliest days, Arrow was most widely used
as that kind of serialization format where you don't need to serialize.
For transporting data between different systems and across networks,
it started low level,
and gradually you went from the format to the CABI
for interoperability,
to flight RPC, a framework for client server query protocols,
to flight SQL for the full protocol for database interactions,
to ADBC, which is more recent,
which is basically OUBC, but better.
You know, similar idea, you have single client API,
and swapable drivers implemented,
but it's all using Arrow as the format for the data,
so you get column oriented data the whole way through.
So when you're talking about dealing with back to databases here,
your client server protocol can keep the data in
the column oriented format, the whole way through,
especially when your source system is column oriented internally.
And then gradually, you know,
now it's much clearer and better known that Arrow is what it is.
I saw several people clap when I saw it in the picture up there
of the Arrow logo, and so on, many people know what it is,
but also many people don't know what Arrow is,
because it's such a low level technology.
Arrow is in almost everything already.
If you're using Polars, Polars is Arrow under the hood.
If you're using pandas, it's basically Arrow under the hood,
especially with the most recent release.
Dr. Bee is, for all intent and purposes,
internal memory is essentially Arrow,
and so on and so on.
And last year, me and my co-founders of Kalmar put out
a blog post explaining and punctuating a lot of what I've said
at the beginning of the talk.
And if you're interested, go read the blog post,
lots of visuals, lots of cool things,
talking about modern day protocols,
specifically talking about Postgres in that article.
So if you're one of more in-depth attacks here,
go ahead and read.
The other part is that when they concluded that the conclusions
that they reached have only gotten more important
as your average network speeds have gone up.
In 2017, the average global network speed for broadband
was about 39 megabits.
In 2023, your average global system was 110,
and it's only gotten bigger.
And so the faster the system, your network speed is,
the more you need a compression optional batched Kalmar-oriented
format to take advantage of that speed.
You're just throwing performance away
by converting everything into JSON and rows and so on.
And so this has been a real triumph for Arrow.
Because Arrow is a format, it's a spec.
It has libraries in pretty much every language under the sun.
If you are using a programming language,
there is probably an Arrow implementation for it.
But because the format is identical,
no matter what language you're using,
everything's all interoperable.
And many systems have adopted it.
You can see here at mean.tv is completely interoperable with Arrow.
Dremio, Google BigQuery, you can get from the Read Storage API
and return Arrow.
Click out Snowflake, all return Arrow, and so on.
In fact, half the time they do that because their clients
are demanding it, because it's immediately interoperable with
all the downstream pollers, pandas,
versus front end visualization systems
like perspective and so on.
But at the same time, there's lots of systems
that aren't adopting it.
That are still oriented there.
Still oriented protocols that are only returning JSON,
even though they're client.
Even though they're column oriented internally and so on.
And so you think about, okay, why?
Is it Stockholm syndrome?
Why?
And what comes down to is it's a really high switching cost?
It's a steep learning curve.
Whether if you're writing a new code,
then you have to reskill and learn how to think about things
in this way.
If you're adding to an existing system,
it requires migrating your system to this new way of doing things.
So it's not an easy thing to convert from
our usual understanding of row oriented stuff
to utilizing arrow and commoying stuff.
If that's not what you're already familiar with.
And kind of like help visualize this.
Anyone familiar with what this keyboard layout is?
It's the Vorac.
You might be more familiar with Quarty.
And then there's also a lovely other format
that is let's known called Colmac.
And so think about it this way.
You're used to Quarty or you're used to the Vorac, whatever.
And so in puts one of the other keyboard layouts in front of you
that are very, very different.
It is not easy to rewire your brain
after spending decades typing on a Quarty keyboard
to suddenly use the Vorac.
And that's kind of the same system we're talking about here
with the difficulty of the conversion
from these row oriented paradigms to column oriented ones.
And also also consider the fact that
the experts on all this stuff always overestimate
the actual understanding of the non-experts.
No matter how much you think that you're accounting for
what a non-expert might know.
If you're an expert in the system, you're probably overestimating
what they're understanding is.
And so one of the things that the arrow community and that
columnar and general are trying to do is we want to
shrink this learning curve.
We want to make this feel much more gentle and make it easier.
And then you think about, you know,
talk about since we're talking about DS systems.
And we talk about, you know,
the problems of ODBC and JDBC that were designed,
you know, 20 years ago, 30 years ago and everybody
hates them and they're awful.
And I mentioned arrow as ADBC for communication of data
stuff that way, of dealing with databases.
And so we have an example here of simplifying this data
transfer with arrow under the hood.
And you can use this little CLI that columnar made open source
and you can just install the driver for the system of your choice
that we have.
We've got about 10, 12, all open source drivers and a couple
of non-open ones.
And then you can just, in this case,
I'm using Python, but we have a driver
managers for go, C++, R, Rust, whatever.
And then you just load the driver and it just works.
And you get arrow data out of it,
no matter what a source system is.
But if that source system can support
out-putting column oriented data,
you get all of the performance benefits.
You get this significantly faster communication,
query result retrieval, interoperability,
connection with your existing tooling.
If you look at, you know, last year, Power BI
from Microsoft had their new snowflake connector.
It's just the ADVC driver.
We can have for two weeks ago,
they announced Power BI using a new database
data bricks connector.
It's just the ADVC driver.
Because arrow is eating the world,
but it's such a low-level technology that
you don't even realize you're using it
if you're not the one building these systems.
But you have to know about it,
tester whatever systems you're using
to add support for it,
so that you can then benefit.
And so, you know,
check out our little CLI for managing drivers.
Check, learn about it.
Learn about, you know, ADVC and arrow.
Lots of documentation.
Reach out to columnar, reach out to me.
Reach out to the arrow community.
You know, whatever level of participation you want to do.
But the important point here is understanding,
let's stop using row-based formats for query retrieval.
Let's stop making everything JSON,
even when it doesn't need to be.
Because yeah, it's human-reable and easy,
but that's what cost.
And that's it.
So, thanks everybody.
I think I've got like two minutes for questions.
So, the question was,
if we're spending things out of the data system,
calm oriented, to dump it into a web app,
is there anything on the web app?
So, the question was,
if we're spending things out of the data system,
calm oriented, to dump it into a web app,
is there anything on the web app side that takes
advantage of the calm oriented system?
And the answer to that is, yeah, arrow.
There is the JavaScript, arrow library.
There are several visualization libraries,
perspective of Falcon,
which exist, which leverage arrow data
for their front end visualizations.
And more on that coming soon,
columnar, the company co-founder of,
we are working on a wasom,
no situation for ADBC directly,
but more on that soon.
I can do, look, am I ahead of time?
I'm out of time.
Thank you very much.