TypedTables.jl
ballista
TypedTables.jl | ballista | |
---|---|---|
2 | 20 | |
143 | 2,238 | |
1.4% | - | |
5.2 | 9.3 | |
3 months ago | about 3 years ago | |
Julia | Rust | |
GNU General Public License v3.0 or later | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
TypedTables.jl
-
Pandas vs. Julia – cheat sheet and comparison
Indeed DataFrames.jl isn't and won't be the fastest way to do many things. It makes a lot of trade offs in performance for flexibility. The columns of the dataframe can be any indexable array, so while most examples use 64-bit floating point numbers, strings, and categorical arrays, the nice thing about DataFrames.jl is that using arbitrary precision floats, pointers to binaries, etc. are all fine inside of a DataFrame without any modification. This is compared to things like the Pandas allowed datatypes (https://pbpython.com/pandas_dtypes.html). I'm quite impressed by the DataFrames.jl developers given how they've kept it dynamic yet seem to have achieved pretty good performance. Most of it is smart use of function barriers to avoid the dynamism in the core algorithms. But from that knowledge it's very clear that systems should be able to exist that outperform it even with the same algorithms, in some cases just by tens of nanoseconds but in theory that bump is always there.
In the Julia world the one which optimizes to be fully non-dynamic is TypedTables (https://github.com/JuliaData/TypedTables.jl) where all column types are known at compile time, removing the dynamic dispatch overhead. But in Julia the minor performance gain of using TypedTables vs the major flexibility loss is the reason why you pretty much never hear about it. Probably not even worth mentioning but it's a fun tidbit.
> For what it's worth, data.table is my favourite to use and I believe it has the nicest ergonomics of the three I spoke about.
I would be interested to hear what about the ergonomics of data.table you find useful. if there are some ideas that would be helpful for DataFrames.jl to learn from data.table directly I'd be happy to share it with the devs. Generally when I hear about R people talk about tidyverse. Tidier (https://github.com/TidierOrg/Tidier.jl) is making some big strides in bringing a tidy syntax to Julia and I hear that it has had some rapid adoption and happy users, so there are some ongoing efforts to use the learnings of R API's but I'm not sure if someone is looking directly at the data.table parts.
-
I wrote one of the fastest DataFrame libraries
Not that I am a heavy DataFrame user, but I have felt more at home with the comparatively light-weight TypeTables [1]. My understanding is that the rather complicated DataFrame ecosystem in Julia [2] mostly stems from whether tables should be immutable and/or typed. As far as I am aware there has not been any major push at the compiler level to speed up untyped code yet – although there should be plenty of room for improvements – which I suspect would benefit DataFrames greatly.
[1]: https://github.com/JuliaData/TypedTables.jl
[2]: https://typedtables.juliadata.org/stable/man/table/#datafram...
ballista
- Ballista: Distributed compute platform implemented in Rust using Apache Arrow.
-
Open source contributions for a Data Engineer?
His newer project, Ballista, was also donated to Apache Arrow. I hope to get the Rust skills to collaborate with him on open source work someday too. He's also doing really cool work on spark-rapids FYI.
-
Best format to use for DataFrames in Rust and Python?
https://github.com/ballista-compute/ballista/blob/main/rust/executor/src/flight_service.rs#L193-L228
-
I wrote one of the fastest DataFrame libraries
I'm guessing Polars and Ballista (https://github.com/ballista-compute/ballista) have different goals, but I don't know enough about either to say what those might be. Does anyone know enough about either to explain the differences?
-
Introducing Kamu - World's first global collaborative data pipeline
In your article you mention looking for a faster data engine, have you looked at Ballista https://github.com/ballista-compute/ballista? It’s pretty young but it uses the Apache Arrow memory model and the maintainer did a bunch of work on Apache Spark I believe.
-
Rust for DE?
https://github.com/ballista-compute/ballista is also a cool project worth checking out.
-
Julia: A Post-Mortem
It’s mostly a personal favourite, but once Ballista [1] gets a bit more developed, I expect we’ll tear out our Java/Spark pipelines and replace them with that.
The ML ecosystem in Rust is a bit underdeveloped at the moment, but work is ticking along on packages like Linfa and SmartCore, so maybe it’ll get there? In my field I’m mostly about it’s potential for correct, high-performance data pipelines that are straightforward to write in reasonable time, and hopefully a model-serving framework: I hate that so many of the current tools require annotating and shipping Python when really model-serving shouldn’t really need any Python code.
[1] https://github.com/ballista-compute/ballista
- Ballista 0.4.0
-
Why isn't differential dataflow more popular?
I've looked at this and thought it looked amazing, but also haven't used it for anything. Some thoughts...
Rust is a blessing and curse. I seems like the obvious choice for data pipelines, but everything big currently exists in Java and the small stuff is in Javascript, Python or R. Maybe this will slowly change, but it's a big ship to turn. I'm hopeful that tools like this and Balista [1] will eventually get things moving.
Since the Rust community is relatively small, language bindings would be very helpful. Being able to configure pipelines from Java or Typescript(!) would be great.
Or maybe it's just that this form of computation is too foreign. By the time you need it, the project is so large that it's too late to redesign it to use it. I'm also unclear on how it would handle changing requirements and recomputing new aggregations over old data. Better docs with more convincing examples would be helpful here. The GitHub page showing counting isn't very compelling.
[1] https://github.com/ballista-compute/ballista
- ballista-compute/ballista proof-of-concept distributed compute platform primarily implemented in Rust, using Apache Arrow as the memory model.
What are some alternatives?
vaex - Out-of-Core hybrid Apache Arrow/NumPy DataFrame for Python, ML, visualization and exploration of big tabular data at a billion rows per second 🚀
spark-rapids - Spark RAPIDS plugin - accelerate Apache Spark with GPUs
data.table - R's data.table package extends data.frame:
differential-dataflow - An implementation of differential dataflow using timely dataflow on Rust.
rust-dataframe - A Rust DataFrame implementation, built on Apache Arrow
delta-rs - A native Rust library for Delta Lake, with bindings into Python
Tidier.jl - Meta-package for data analysis in Julia, modeled after the R tidyverse.
dagster - An orchestration platform for the development, production, and observation of data assets.
Prefect - The easiest way to build, run, and monitor data pipelines at scale.
roapi - Create full-fledged APIs for slowly moving datasets without writing a single line of code.
airbyte - The leading data integration platform for ETL / ELT data pipelines from APIs, databases & files to data warehouses, data lakes & data lakehouses. Both self-hosted and Cloud-hosted.
rslint - A (WIP) Extremely fast JavaScript and TypeScript linter and Rust crate