REMOTE: Optional, Based in the Netherlands is preferred
VISA: No
DESCRIPTION: Polars is the company founded from the Polars OSS project. The company is building a distributed query engine and managed data platform that can run the full polars API with different scaling strategies. (Almost) Our whole tech stack is in Rust and we are building the platform from scratch.
However, this is not a Polars issue. Using "fork" can leave ANY MUTEX in the system process invalid (a multi-threaded query engine has plenty of mutexes). It is highly unsafe and has the assumption that none of you libraries in your process hold a lock at that time. That's an assumption that's not PyTorch dataloaders to make.
> but quite a bit of pandas code will run as-is with polars
I highly doubt this. Aside from dataframe generation and series assignment, almost everything in the API surface is different.
Strictness is also not something you can transplant easily. It is checking data types at the IR query planning level before you run the query and being able to resolve schema's independent of the data. In pandas schemas do depend on data within operations and therefore it isn't uncommon that data types change if data gets missing values nor can it check if a correct type is passed to an operation without running the compute.
We have full iceberg read support. We have done some preliminary work for iceberg write support. I think we will ship that once we have decided which Catalog we will add. The iceberg write API is intertwined with that.
He means that he wants our Rust library as easy as our Python lib. Which I understand as our focus has been mostly on Python.
It is where most of our userbase is and it is very hard for us to have a stable Rust API as we have a lot of internal moving parts which Rust users typically want access to (as they like to be closer to the metal), but has no stability guarantees from us.
In python, we are able to abstract and provide a stable API.
Not right now. Our current SQLContext locally inspects schema's to convert the SQL to Polars LazyFrames (DSL).
However, this should happend during IR-resolving. E.g. the SQL should translate directly to Polars IR, and not LazyFrames. That way we can inspect/resolve all schema's server-side.
It requires a rewrite of our SQL translation in OSS. This should not be too hard, but it is quite some work. Work we eventually get to.
I am not an expert on Spark RDDs, but AFAIK they are a more low-level data structure that offer resilience and a lower level map-reduce API.
Polars Cloud maps the Polars API/DSL to distributed compute. This is more akin to Spark's high level DataFrame API.
With regard to implementation, we create stages that run parts of Polars IR (internal representation) on our OSS streaming engine. Those stages run on 1 or many workers create data that will be shuffled in between stages. The scheduler is responsible for creating the distributed query plan and work distribution.
Hi, I am the original author and CEO of Polars. We are not focused on SQL at this time and provide a DataFrame native API.
Polars cloud will for the moment only support our DataFrame API. SQL might come later on the roadmap, but since this market is very saturated, we don't feel there is much need there.
Polars is built on the foundation of a vibrant and active open-source community, and we embrace that philosophy in how we run our company. We trust talented people to do their best work without unnecessary constraints. Collaboration is key, but we keep meetings to a minimum to maintain focus. As Polars and Polars Cloud continue to set a new standard in Python data processing, we're looking for like-minded individuals to join us on this journey.
TYPE: full-time
LOCATION: Amsterdam
REMOTE: Optional, Based in the Netherlands is preferred
VISA: No
DESCRIPTION: Polars is the company founded from the Polars OSS project. The company is building a distributed query engine and managed data platform that can run the full polars API with different scaling strategies. (Almost) Our whole tech stack is in Rust and we are building the platform from scratch.
COMPENSATION: Competive salary and Stock option package
CONTACT: [email protected]