graphic-walker VS parquet-format

[2] https://github.com/Kanaries/graphic-walker/issues/330

GWalkR is an open-source R library that allows you to turn your data frame into a tableau style user interface for data exploration and visualization. It also allows you to analysis your data with natural language questions.

GWalkR is the R binding of graphic-walker: https://github.com/Kanaries/graphic-walker

Big fan of D3.js and now there is Observable Plot! I am building several data visualization software for exploratory data analysis:

RATH, auto exploratory data analysis: https://github.com/Kanaries/Rath

GraphicWalker, embeddable data exploration component: https://github.com/Kanaries/graphic-walker

They are using vega-lite for now. But there is a limit of building more fancy and customized visualizations. It seems Plot has a more flexible layer based visualization system that can support larger design space.

Is Plot stable enough now to migrate from vega-lite based system to Plot based? Are there any large milestone or roadmap of Plot in future?

+ Graphic Walker (https://github.com/Kanaries/graphic-walker): A lite embeddable component for visual analysis.

+ PyGWalker (https://github.com/Kanaries/pygwalker): turning your pandas dataframe into a Tableau-style User Interface for visual exploration.

RATH is a collection of interesting ideas that we think the next generation of data analysis software should be, so there might be many features that not well organized to be a united app. Tell me which feature you prefer and which is not. Looking forward for your ideas and advice.

I know you said you *dont* want a tableau like interface, but in case you do this might be a cool open source project to check out: https://github.com/Kanaries/graphic-walker

> it seems like the heavy lifting is done by the web app here: https://github.com/Kanaries/graphic-walker

FWIW, both are made by the same entity, Kanaries.

You may try to use and modify based on the OpenSource Graphic Walker: https://github.com/Kanaries/graphic-walker

Graphic Walker is designed to be easy to embed in other applications as a React component. Check out the code here: https://github.com/Kanaries/graphic-walker

Right, there's all sorts of metadata and often stats included in any parquet file: https://github.com/apache/parquet-format#file-format

The offsets of said metadata are well-defined (i.e. in the footer) so for S3 / blob storage so long as you can efficiently request a range of bytes you can pull the metadata without having to read all the data.

As i read here https://github.com/apache/parquet-format/blob/master/LogicalTypes.md , they are store in Integer formats and these integers represent the number of days (for Date) or number of milliseconds, microseconds or nanoseconds (for DateTime) since 1970-01-01. This works as expected with the parquet file that written by our ETL tool from internal database --> S3, all Data/DateTime columns are Integers, means that in Glue Job, i have to convert these Integers back to Date/Datetime value to do some transformation on them. But when parquet files are written by Spark, they are Date/DateTime (or TimeStamp to be more concise) format not Integers (i checked by read these files again in other Glue Job) and that make me confused.

Date is confusing with a timezone (UTC or otherwise) and the doco makes no such suggestion.

The Parquet datatypes documentation is pretty clear that there is a flag isAdjustedToUTC to define if the timestamp should be interpreted as having Instant semantics or Local semantics.

https://github.com/apache/parquet-format/blob/master/Logical...

Still no option to include a TZ offset in the data (so the same datum can be interpreted with both Local and Instant semantics) but not bad really.