dbt-spark VS damons-data-lake

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!

I use CDK and scheduled Fargate tasks on ECS to do something similar ( https://github.com/dacort/damons-data-lake/blob/main/data_containers/README.md ). But it doesn’t handle the timeouts/retries. For that you would need something like Batch or Step Functions.

I use CDK to deploy it and you can see the code here: https://github.com/dacort/damons-data-lake/tree/main/data_containers

I went a little crazy and built my own set of data extractors that I can deploy with CDK to ECS.

Glad you found it helpful! And yes! I love quantified self type data. I did something similar a few years back where I gathered my inbox unread count, open Chrome and iTerm tab count, and even how many times I copy/pasted in a day and uploaded it all to S3 via Kinesis for a demo. It was a ton of fun - feel free to peek at it! https://github.com/dacort/damons-data-lake