Live data from Hacker News

Apache Arrow 3.0

arrow.apache.org

201–204 of 204 posts

Re: Apache Arrow 3.0

#201
post #64

Would really love to see first class support for Javascript/Typescript for data visualization purposes. The columnar format would naturally lend itself to an Entity-Component style architecture with TypedArrays.

There is a Typescript arrow library that can operate off the IPC format. As an example use case, take a look at the arquero data processing library from the University of Washington (from the same group that created D3). https://github.com/uwdata/arquero

Re: Apache Arrow 3.0

#202
post #111

Earlier quoted context omitted.

Until arrow has proper support for multidimensional arrays [1], its not really appropriate for many use cases. Not having first class support for multidimensional arrays, in a modern framework, really surprised me and my sensor data. [1] https://lists.apache.org/x/thread.html/9b142c1709aa37dc35f1c...

FWIW, you can support tensors etc. natively today by using Arrow's structs, such as `column i_am_packed: {x: int32, y: int32, z: int32, time: datetime64[ns], temp: int32}`. This will be a dense, packed representation for whatever fixed type the column has, including dynamically generated. It ends up being quite nice to have that passed around, esp. vs say protobufs. You wouldn't be sending mixed-length values, and ~a…

[deleted]

Re: Apache Arrow 3.0

#203
post #111

Earlier quoted context omitted.

Until arrow has proper support for multidimensional arrays [1], its not really appropriate for many use cases. Not having first class support for multidimensional arrays, in a modern framework, really surprised me and my sensor data. [1] https://lists.apache.org/x/thread.html/9b142c1709aa37dc35f1c...

What are the use cases where multi-dimensional arrays are important and why?

R&D/manufacturing of consumer facing sensors, in my case.

Re: Apache Arrow 3.0

#204

Earlier quoted context omitted.

The big thing is that it is one of the first standardized, cross language binary data formats. CSV is an OK text format, but parsing it is really slow because of string escaping. The files it produces are also pretty big since it's text. Arrow is really fast to parse (up to 1000x faster than CSV), supports data compression, enough data-types to be useful, and deals with metadata well. The closest competitor is probab…

The worst part about CSV is that it appears to be so simple that many people don't even try to understand how complicated it is and just roll their own broken dialect instead of just using a library. There is also no standardized encoding. Delimiters have to be negotiated out of band and people love getting them wrong.

Mostly agree, but RFC-4180 does specify delimiters. I've used pipe-delimited files for years to ensure explicitly-defined conformity, but recently due to the plethora of libraries have been thinking that CSV may be simpler.
Post reply on HN