nimbo VS dbt-spark

You should really mention / give attribution / emphasize more that this is a fork of https://spotty.cloud and you took a lot from https://github.com/nimbo-sh/nimbo as well.

Hey everyone,

I (Miguel) am an ML PhD from the University of Edinburgh and Juozas is a Software Engineer also from Edinburgh.

Together we developed Nimbo, a dead-simple CLI that wraps the AWS CLI, allowing you to run code on AWS as if you were running it locally. You can find the source code here (https://github.com/nimbo-sh/nimbo) and the docs here (https://docs.nimbo.sh).

We decided to build this because we were frustrated with how cumbersome using AWS was, and we just wanted to be able to run jobs on AWS as easily as we run them locally. At the same time, we wanted to make use of the cheap spot instances (on Nimbo, this is a single parameter). All in all, we didn't like the current user experience of working with AWS, and we believed it was possible to vastly improve it.

For this reason, we also provide many useful commands to make it faster and easier to work with AWS, such as launching notebooks on EC2, easily checking prices, logging onto an instance, or syncing data to/from S3 (you can see some useful commands at https://docs.nimbo.sh/useful-commands).

Unlike other similar services, we are solely client-side, meaning that the code runs on your EC2 instances and data is stored in your S3 buckets (we don't have a server; all the infrastructure orchestration happens in the Nimbo package). We are also open contribution, meaning that all the source code is publicly available on our GitHub, and we welcome community contribution.

We have tons of ideas for Nimbo, like adding docker support, and providing instances with preloaded datasets like ImageNet, so that you don't have to download and store it yourself - you simply spin the instance, and the dataset is available at /datasets. We are currently working on adding GCP support, so that you can use AWS or GCP with the same config file.

We are happy to receive any feedback and suggestions you have.

My friend and I just launched Nimbo, a dead-simple CLI that wraps AWS CLI, allowing you to run code on AWS as if you were running it locally. GitHub: https://github.com/nimbo-sh/nimbo. Docs: https://docs.nimbo.sh.

Spark + dbt => https://github.com/dbt-labs/dbt-spark/blob/main/docker-compose.yml

So the idea is you land your data raw in a Delta bronze layer, and then use dbt models to propagate that data forward to silver, gold, do all of your data quality, etc. and all of the actual execution is happening on a Databricks SQL endpoint (or you can use the dbt-spark adapter and run your transfors as Spark on a cluster)

Neat. Congratulations on the launch!

Apart from the fact that it could deploy to both GCP and AWS, what does it do differently than AWS Batch [0]?

When we had a similar problem, we ran jobs on spots with AWS Batch and it worked nicely enough.

Some suggestions (for a later date):

1. Add built-in support for Ray [1] (you'd essentially be then competing with Anyscale, which is a VC funded startup, just to contrast it with another comment on this thread) and dbt [2].

2. Support deploying coin miners (might be good to widen the product's reach; and stand it up against the likes of consensys).

3. Get in front of many cost optimisation consultants out there, like the Duckbill Group.

If I may, where are you building this product from? And how many are on the team?

Thanks.

[0] https://aws.amazon.com/batch/use-cases/

[1] https://ray.io/

[2] https://getdbt.com/

It will be helpful to set the stage, as no two technical stacks are the same and not all data warehouse platforms provide the same functionality. It's for the latter that we really like tools like dbt, and the sample files provided here should provide a good starting point for your specific use case. Our instance leverages the cloud version of dbt and connects to our Snowflake data warehouse, where models output tables in a designated dbt schema.

T: SQL - views and scheduled queries in BigQuery; planning to go hard with dbt as soon as I can find some breathing room)

Since all of the data is often already in the data warehouse, the logical choice is to simply just use it as a CDP. A modern data stack should consist of an end-to-end flow from data acquisition, collection, and transformation. In most cases, the easiest way to enable this goal is by leveraging tools that are purposely designed to handle a single task. Fivetran, Snowflake, and dbt are great examples of this. In fact, this is the core technology stack that every data-driven company is adopting. Fivetran handles the entire data integration aspect providing a simple SaaS solution that helps businesses quickly move data out of their SaaS tools and into their data warehouse. Snowflake provides an easy way for organizations to consolidate their data into one location for analytics purposes. Lastly, dbt provides a simple transformation tool that is SQL-based, enabling users to create data models that can be reused. These three solutions combined create an effective data management platform.

This is the issue: https://github.com/dbt-labs/dbt-spark/issues/161. Too bad they still haven't fixed it!