Why are you writing tests on the actual provider? IME these types of tests are slow, brittle and don't give you much value. Even if you get a true positive, what can you do about it?
Because those tests are the only ones that prove the connector is working as intended
Our connectors receive a generic query IR from a Datafusion-based engine
Each connector is then responsible for faithfully translating the query IR into the semantically equivalent query for the underlying data source
For a SQL DB this would be a SQL query, for MongoDB a JSON predicate query, for csv/json files it would be an in-memory predicate engine, etc
Running the generated query against the target data source and asserting that this doesn't throw an error and that the records returned are both correct and in the right order is the true test
For cloud databases, in your use case do you care that the queries actually execute or only that they parse? I with every cloud service had their own version of LocalStack/Moto, and while not perfect they've really helped to improve test coverage.
Unfortunately they have to actually execute and have identical semantics to the target source
I recall seeing a project based on DuckDB parser and engine which emulated dialects for one of these but because the sortinh and other behavior is different it wasn't usable
Ducklake works well. So far it is still under active development (post AWS acquisition). There is support for local disk-based and remote S3 based datalakes, so integration tests become really easy. Seems stable and all the bugs I've found have already been patched.
Praying for the poor Ducklake employees at AWS to keep whatever demon works there at bay who insists that every single data product has to be bolted onto AWS Glue (and its various Data Catalog, Data Lake, etc. partners in crime) in the most clumsy way possible. And please keep it away from Athena, possibly the worst major query engine in terms of support for query features and file formats. I don't want to see AWS-era Ducklake become another failure like S3 Table Buckets are (imo at least).
I'm tempted to use this but the rub with Databricks is that there are always a bunch of different restrictions on what features work in what products (for example RT//Lakehouse looks great but runs a more limited regex parser than other warehouses), and so I'm basically forced to rely heavily on integration tests to catch weird behavior. This would need to copy it closely enough to catch those.
The other problem is that Databricks renames everything like every 6 months so keeping up with them is non-trivial. Their DLT product alone has gone on a jazz odyssey of renames.
Wtf is databricks now anyways? Looks like their ceo is hawking cheap chinese models and some silly harness called ominiagent. Anyone use ominiagent?
I thought they were building their own models at somepoint? what happened to that.
Also looks like they did one full round of english alphabet and are on series L second time around. I feel like we might have some a tech theranos on our hands here.
Managed Spark. That is still what they are, all the other nonsense aside.
Spark is such a headache to run that people would rather pay Databricks to do it for them. They also have some secret sauce like Photon (C++ version of the Spark engine) and the new RT Lakehouse warehouses (10x or so speed up on read-only work flows in my experience) as well as good proprietary optimization features like Liquid Clustering that keep your Parquet files nicely sized and indexed. Their AI features are terrible and I can't tell you how many Zoom calls I've joined to rescue people from wild goose chases their model took them on.
Their main competitor is Snowflake, which imo has nicer UI/UX and snappier SQL execution, but the trade off is that Snowflake has a bit more lock-in, whereas Databricks is easier to kind of just build on top of your existing infrastructure. Snowflake's AI features are also much better in my experience.
>I feel like we might have some a tech theranos on our hands here.
Based on what I've seen some customers paying them, they are absolutely making heaps of money. A "small" SQL warehouse cluster is $8.40 an hour (~$73k a year if you leave it on) and the default size of X-Large is $56 an hour or $490k a year. It goes up to 5X-Large at $729 an hour or $6.3M a year. So they do absolutely let people with horribly optimized data just pay their way out of dealing with the problem, which is something I've seen multiple times.
If this actually works, this is such a huge boon. Let me share why:
I work on connectors to various datasources, mostly SQL DB's
The most useful tests are the integration tests, sending actual queries to the source
For most DB's we have a giant Docker Compose which runs a local instance
But things like Snowflake, Databricks, Redshift, Athena suck to test because we need an external hosted instance
I would kill to be able to run test versions of all of these locally
Why are you writing tests on the actual provider? IME these types of tests are slow, brittle and don't give you much value. Even if you get a true positive, what can you do about it?
Because those tests are the only ones that prove the connector is working as intended
Our connectors receive a generic query IR from a Datafusion-based engine
Each connector is then responsible for faithfully translating the query IR into the semantically equivalent query for the underlying data source
For a SQL DB this would be a SQL query, for MongoDB a JSON predicate query, for csv/json files it would be an in-memory predicate engine, etc
Running the generated query against the target data source and asserting that this doesn't throw an error and that the records returned are both correct and in the right order is the true test
When it comes to platforms like Databricks, integration tests are honestly the only useful ones. Grug remains vindicated as always.
I assume integration tests.
For cloud databases, in your use case do you care that the queries actually execute or only that they parse? I with every cloud service had their own version of LocalStack/Moto, and while not perfect they've really helped to improve test coverage.
Unfortunately they have to actually execute and have identical semantics to the target source
I recall seeing a project based on DuckDB parser and engine which emulated dialects for one of these but because the sortinh and other behavior is different it wasn't usable
[dead]
Getting tired of the standard AI design, all websites look the same now
I would say go straight to their GitHub but there again, same thing.
With a list of "Known gaps" and implemented engines listed with status like "Real", and of course the Quick start first, as Claude loves to do.
It's not "wrong", it just shows low effort. But then again it's just something someone needed and shared it for free so let's not complain too much.
All the products and saas launching with obvious AI landing pages, that the authors did not even care to trim down, that's another story.
Before it was all those common template sites.
Want to hijack this someone made experience recently with https://ducklake.select/ ? We need to setup a warehouse soon and this looks enticing.
Ducklake works well. So far it is still under active development (post AWS acquisition). There is support for local disk-based and remote S3 based datalakes, so integration tests become really easy. Seems stable and all the bugs I've found have already been patched.
Praying for the poor Ducklake employees at AWS to keep whatever demon works there at bay who insists that every single data product has to be bolted onto AWS Glue (and its various Data Catalog, Data Lake, etc. partners in crime) in the most clumsy way possible. And please keep it away from Athena, possibly the worst major query engine in terms of support for query features and file formats. I don't want to see AWS-era Ducklake become another failure like S3 Table Buckets are (imo at least).
I'd personally love to try this in earnest as well
You should call it "pond".
Oh wow! This would've been so useful at my previous work place. I'll save this one for later. Looks pretty decent too for homelabs!
I wonder if there is any plans on extending it further? (just a bit)
I'm tempted to use this but the rub with Databricks is that there are always a bunch of different restrictions on what features work in what products (for example RT//Lakehouse looks great but runs a more limited regex parser than other warehouses), and so I'm basically forced to rely heavily on integration tests to catch weird behavior. This would need to copy it closely enough to catch those.
The other problem is that Databricks renames everything like every 6 months so keeping up with them is non-trivial. Their DLT product alone has gone on a jazz odyssey of renames.
Great for CI i guess; or is this meant as a cost savings measure where you can swap out your databricks for self-hosted this?
Wtf is databricks now anyways? Looks like their ceo is hawking cheap chinese models and some silly harness called ominiagent. Anyone use ominiagent? I thought they were building their own models at somepoint? what happened to that.
Also looks like they did one full round of english alphabet and are on series L second time around. I feel like we might have some a tech theranos on our hands here.
Managed Spark. That is still what they are, all the other nonsense aside.
Spark is such a headache to run that people would rather pay Databricks to do it for them. They also have some secret sauce like Photon (C++ version of the Spark engine) and the new RT Lakehouse warehouses (10x or so speed up on read-only work flows in my experience) as well as good proprietary optimization features like Liquid Clustering that keep your Parquet files nicely sized and indexed. Their AI features are terrible and I can't tell you how many Zoom calls I've joined to rescue people from wild goose chases their model took them on.
Their main competitor is Snowflake, which imo has nicer UI/UX and snappier SQL execution, but the trade off is that Snowflake has a bit more lock-in, whereas Databricks is easier to kind of just build on top of your existing infrastructure. Snowflake's AI features are also much better in my experience.
>I feel like we might have some a tech theranos on our hands here.
Based on what I've seen some customers paying them, they are absolutely making heaps of money. A "small" SQL warehouse cluster is $8.40 an hour (~$73k a year if you leave it on) and the default size of X-Large is $56 an hour or $490k a year. It goes up to 5X-Large at $729 an hour or $6.3M a year. So they do absolutely let people with horribly optimized data just pay their way out of dealing with the problem, which is something I've seen multiple times.
Databricks is a furnace. It burns money.
[flagged]
[flagged]
[flagged]
[flagged]