Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dagster + SQLMesh Metrics: Run sqlmesh python models on trino #2444

Closed
ravenac95 opened this issue Nov 4, 2024 · 2 comments
Closed

Dagster + SQLMesh Metrics: Run sqlmesh python models on trino #2444

ravenac95 opened this issue Nov 4, 2024 · 2 comments
Assignees

Comments

@ravenac95
Copy link
Member

What is it?

The second part of a set of issues for getting Dagster + SQLMesh Metrics running. This is to get sqlmesh running the python models on trino. If, somehow, this is performant enough without any additional work to run the metrics with the special pre-warmed duckdb as a cache + rolling query runner, then we can still accomplish all the metrics work without as much time spent developing a more complex option.

@github-project-automation github-project-automation bot moved this to Backlog in OSO Nov 4, 2024
@ravenac95 ravenac95 self-assigned this Nov 4, 2024
@ravenac95 ravenac95 moved this from Backlog to In Progress in OSO Nov 4, 2024
@ravenac95
Copy link
Member Author

Sadly, after having spent quite a few hours on this (there were some setup things to fix and then bugs in the python models). running this with just the python models as is on trino is still not enough. Some observations when running

  • We can't seem to saturate the requests to trino.
  • Queries for each rolling day take on the order of seconds 1-10s each. So for a 10 year period this would take ~10 hours.
    • This is vastly slower than our duckdb pre-warmed cache implementation
  • Trino has some limitations with query text size. This might cause issues with the dataframe writing.
    • We can adjust settings here to a point so this is less an immediate problem.
  • Still running into periodic errors.
    • I think this is due to the scaling mechanisms. So I may disable those for now until we get prometheus and KEDA setup to be able to scale based on additional dimensions like http requests.

Places we will go from here to explore (still not using duckdb):

  • We should try to see if we can saturate the requests to trino's workers. It would be nice to see if it's possible make the workers actually queue queries. At least then we will know it's functioning at it's limit.
  • We should use an external process to handle this test as adding this directly as part of the sqlmesh python model adds some complication. My current thought is to use an "Arrow Flight Protocol" compliant server that will stream table results to the caller. This is an open protocol used by arrow so it's something we could easily use in other places. We would call the service from the python model and stream the rows in and periodically write the results out.

@ravenac95
Copy link
Member Author

Closing as the work in #2469 started as this but ended up encompassing more

@github-project-automation github-project-automation bot moved this from In Progress to Done in OSO Nov 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Done
Development

No branches or pull requests

1 participant