Plumbing metadata

[CJ-Wright]

From the initial blog post:

Annotate elements: we want to pass through event time, processing time, and presumably other metadata

It might be good to have this discussion in the near future (now?) since we are having some discussion on the SHED side about things that are like this/may include this.

Not that this is necessarily the best option: Make a dedicated object for metadata (really just a dict). Every node knows to check if the thing that came down was this object before doing anything. If isinstance (x, MetadataObject) then just pass it on or append something to it or modify it. The sinks know to ignore it for the most part.

@mrocklin @danielballan @jrmlhermitte

[mrocklin]

I will likely need something like this for time-series dataframes as well. I haven't thought very deeply about how to organize this yet. I may not do much thinking on this for the next couple weeks.

[CJ-Wright]

Great (to the need it as well)!

Another option is to include the metadata with the data and scrape the metadata off before doing the transformation and then putting it back on before emitting (but this seems a bit messier although this does offer up the option of combining data and metadata).

[jrmlhermitte]

Sounds good. Sounds like there are two main ideas bounced around (correct me if I'm wrong):

1. Metadata and data are packaged together in stream
2. Data goes through stream, but metadata is kept in a separate place

I personally vote for the first. That's what we currently do with our streamdoc, which is basically a dictionary with args, kwargs and attributes elements (among other things). The parsing is done by a decorator which decorates each mapped function here. The application of this decorator is here (where this decorator is renamed to psdm). I apologize how messy it is but it is working for now. We're not completely settled on this idea.

I think handling all this is extremely messy from my perspective, and would suggest it not to be handled by the baseclass. Perhaps one could imagine making it a Mixin or something? (If possible) Just throwing ideas out there.

[CJ-Wright]

Hmm I didn't think of 2. I was thinking of having metadata-data-metadata-... and then having the streams nodes (potentially including the base class) behave differently for data and metadata.

[jrmlhermitte]

PS: as an alternative to pandas, xarray could also be convenient. See here

[CJ-Wright]

One interesting side effect of this would be that we could potentially use this to manage our exceptions as well. We could:

1. Create a blacklist of types which operators (map, filter, accumulate, etc.) just ignore and include the metadata and exception classes in this list.
2. Upon exception turn the data into metadata (with a whole bunch of info on why/how/when it failed) now all the operators ignore the bad data.

One nasty side effect of this is that we need to make sure that we don't pair data and metadata together in the joining nodes (zip, zip_latest, combine_latest) as the operators would be confused.

[jrmlhermitte]

It sounds like this is trending toward a heterogeneous stream of data. I would argue that this may be out of scope of streamz and may add more complexity that is not well understood yet (not enough use cases). Sounds like shed attempts to answer that. (Schematic here )

One thing I think could be useful here is multichannel streams. Something like data.data would be the regular channel passed on to the stream and data.md or data.anything could be other channels. But one could argue this can be accomplished with a different data type and function handling it properly (like xarray). I would disagree with putting multichannel streams in base class as well.

[CJ-Wright]

I think this has been handled some by #306 adding timestamp metadata could be done by the source. Another potential iteration would be to have metadata functions that return dicts and are passed in whatever data/metadata is applicable into the node, generating new metadata on the way out.