Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support native Row source type, conversions to/from #2262

Open
frankmcsherry opened this issue Mar 10, 2020 · 5 comments
Open

Support native Row source type, conversions to/from #2262

frankmcsherry opened this issue Mar 10, 2020 · 5 comments

Comments

@frankmcsherry
Copy link
Member

@frankmcsherry frankmcsherry commented Mar 10, 2020

While we have a variety of input sources, we don't have a native format yet. For example, we could maintain serialized Row types that are more or less trivial to serialize and deserialize, and thereby remove a substantial amount of work from our dataflows.

It seems reasonable to consider "ingestion" as a task separate from core dataflow processing. We may still want to do it there, but at some point (S3 persistence at least) we'll want to convert the data to something more economical. We could map this out now, and by writing some conversions give folks a better experience when exploring materialized (i.e. when restarting a lot).

Downsides are (at least): 1. this either ossifies Row, or means we support lots of different row formats, or we break internal formats periodically; each seems fine. 2. Rewriting input data; it would be great to leave user data at rest, but if we want to improve deserialization performance we'll want to do this.

One bridge might be to put together a Row format and help folks with materialized source -> sink dataflows that just do the rewrite once and drop the results in our internal format. This might be easier operationally than other converters, and allows them to decide if they want to decouple this from their dataflow processing or not bother.

@rjnn

This comment has been minimized.

Copy link
Member

@rjnn rjnn commented Mar 10, 2020

The bridge option seems elegant from a UX standpoint: it’s just a one off materialize job that makes all future materialize jobs much faster. And like you said, they don’t have to do it.

Sent with GitHawk

@quodlibetor

This comment has been minimized.

Copy link
Member

@quodlibetor quodlibetor commented Mar 10, 2020

This issue seems like it's combining ingestion/a "connector" API, persistence, and our internal format? FWIW I think all of this discussion becomes a lot easier once we have persistence, because then users don't need to store/re-parse much (or ideally anything) and we have a lot of flexibility in looking for performance and ergonomics improvements.

The internal/persistence/row format basically doesn't matter from a UX perspective -- as long as users upgrade only one internal-format version at a time we can handle upgrades, and I (obviously) think that we should be experimenting with this ASAP, and I believe some conversation around this has happened in the dataplane consistency discussions?

The ingestion API seems like what we should be improving with our various conversion dataflows, a clearer API boundary there would, I agree, help us make the functions more generic/possibly possible to export.

One bridge might be to put together a Row format help folks with materialized source -> sink dataflows that just do the rewrite once and drop the results in our internal format.

I'm not sure what architecture you're imagining here? Is it a separate timely cluster that folks can independently scale up, or some sort of bridge library that folks can load and shares memory space with timely, or something that hits a socket/filesystem API?

@benesch

This comment has been minimized.

Copy link
Member

@benesch benesch commented Mar 10, 2020

@frankmcsherry

This comment has been minimized.

Copy link
Member Author

@frankmcsherry frankmcsherry commented Mar 11, 2020

We can ingest Avro at 300MB/s with a bit of legwork:

This is a good improvement and we should do it, but it is still a long ways off of the performance you'd get with serialized Row data. Back in differential days, the cost for using a tuned JSON deserialized (pikkr) was about 30x over just having the binary data ready (which is essentially what a serialized Row would be).

Do you recall if the 300MB/s is measured in terms of output data produced or input data read? Iirc, a fair bit of the Avro data is cruft that we just throw away, right?

I don’t think we need to be designing our own serialization format just yet!

I think we already are, we are just doing it ad-hoc at the moment. With sinks, we do have to write data down. We could write out Debezium-looking streams and use BYO consistency topics, but that is a serialization format. We don't need to do this next week, but it should happen. Prioritization is orthogonal.

@frankmcsherry

This comment has been minimized.

Copy link
Member Author

@frankmcsherry frankmcsherry commented Mar 11, 2020

I'm not sure what architecture you're imagining here? Is it a separate timely cluster that folks can independently scale up, or some sort of bridge library that folks can load and shares memory space with timely, or something that hits a socket/filesystem API?

The intended proposal was just that people can write a source -> sink dataflow, which results in efficiently encoded batches of data, and with that ability they can choose to 1. run that dataflow in their copy of materialized to make subsequent uses of the same inputs faster, or 2. run that dataflow in a different materialized to decouple the scaling needs of the work, or 3. not run it at all if they don't need it. The written sink is meant to be something that can be read in as a source (e.g. perhaps Row data written in to Kafka, in a super-simple version).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.