FugueSQL: SQL-ish for pandas, dask, spark
fugue-tutorials.readthedocs.io
fugue-tutorials.readthedocs.io
I love these SQL layers but they can obfuscate how they implement their transforms. So, they can speed up filter and join creation and coding... til something breaks and then you have to go atomic anyway.
Each of the runtimes, supported by Fugue, can be compared to Ray, but Fugue is a tool of a different kind.
Fugue SQL is one way, and it also has functional API. They both can be translated into the underlying runtime. You can choose based your preference and real need.
Fugue is a higher level abstraction compared to Ray. It provides unified and non-invasive interfaces for people to use Spark, Dask and Pandas. Ray/Modin is also on our roadmap.
It provides both Python interface (not pandas-like) and Fugue SQL (standard SQL + extra features). Users can choose the one they are most comfortable with as the semantic layer for distributed computing, they are equivalent.
With Fugue, most of your logic will be in simple Python/SQL that is framework and scale agnostic. From the mindset to the code, Fugue minimizes your dependency on any specific computing frameworks including Fugue itself.
Please let me know if you want to learn more. our slack is in the README of the fugue repo
Fugue repo: https://github.com/fugue-project/fugue Tutorials: https://fugue-project.github.io/tutorials/
For example, let's assume you use duckdb or mysql or other standard sql for data processing, how do you deal with intermediate tables?
You may have to frequently use CREATE TABLE and INSERT or write gigantic WITH statement to avoid the hassle. I guess many people use both.
In Fugue SQL, you can use simple assignment to do the same thing (Fugue may translate the assignment to CREATE TABLE or do something more efficient)
-------
a = CONNECT duckdb SELECT * FROM table1
b = LOAD "/tmp/src.parquet"
c = SELECT * FROM a LEFT SEMI JOIN b ON a.key = b.key
OUTPUT c USING mysql_dumper(table_name="temp", mode="append")
d = SELECT * FROM b UNION SELECT * FROM c
SAVE d OVERWRITE "/tmp/tmp.parquet"
--------
Look at the above Fugue SQL example, it's self-explaining, but how much extra code you have to write to achieve the same semantic without Fugue SQL?
Fugue SQL can provide a unified and minimal way to express your logic in SQL-ish way, while the real executions are done but those wonderful database solutions you mentioned.
For example, with a python function
```python
# schema: , c:int
def add_new_col(df:pd.DataFrame) -> pd.DataFrame:
df['c'] = 1
return df
fsql(query).run()
# to run on Spark
fsql(query).run(SparkExecutionEngine)
```