Posted by thingsilearned 12 hours ago
So, are those other pieces going to be part of dbtTran Cloud?
> There’s governance, access controls, interactivity, and connectivity to semantic layers
I'd add to that list as well: KPIs, dropdowns, text boxes, theming, shared data sources.
If you're familiar with Vega-Lite [1], I like to explain dbt Charts as the Vega-Lite but for BI, in that it is a language that specifies all of the components of BI.
> are those other pieces going to be part of dbtTran Cloud?
Certainly there are some features that are more conducive to being offered as a managed service. However, we've built this enterprise BI tool backwards in that we've started less with commercialization in mind, but rather laying the groundwork in the language and OSS project, so that we need not reinvent the wheel over and over again.
I'm hand-waving here about a future that doens't yet exist. But in theory dbt Charts could be extended in the front end to allow for not just SQL or SL metric support, but any query language. Same for the backend, we dbt Charts can render to png and html today, but other formats are also possible!
On the standardized charting language, that would be the dream. All agents giving the same spec when they want to build a chart or dashboard, and then having different renderers of that. That is a steep goal. Such a language would need to be simple but still extremely versatile. I'm not sure that combination exists yet. Our language is simple and fairly versatile, but not as versatile as vega-lite itself, or JavaScript code even. Maybe we can evolve in that direction though
I've been mulling extending dbt Charts to support ggplot, and will likely reach out to the team about this in the next few weeks.
The difference is that Vega-Lite, ggsql, ggplot2 are designed to create a single chart. Yes, you can use facet_wrap() to great a series of charts based on a particular variable, but arguably that's still one chart!
What's missing that is table stakes for a BI dashboard: KPIs, text boxes, dropdowns, data sources, governance, and how the charts are arranged on the page and in relation to one another.
In the next few months we hope to ship a JSON schema that represents a dashboard in the same way that a VegaLite does for a single chart.
Does that make sense?
very disappointed that their domain specific language is just yaml. conditionals and variable binding become insane war crimes when yaml comes to town. you have a friggin llm, do better
and when we computer folks see the word language its implied that its a computing on computers language not a friggin data format.
edit: the yaml to avoid complexity that should live in the sql side can back fire, some folks I was working with last fall were evaluating if a yaml based OLAP tool would work for them, and there were some pretty gnarly gotchas from a yaml based approach. Secondarily, theres a real case to be made that having the data linkages not visible in the charting layer means that groups of related plots with different axes wont have the right data linkage without forcing a lot more ETL for what should be a quick plot if the data already fits in memory.
theres actually a very important reason you want it to be an actual embedded dsl or tiny programming language!
The reason why llms can code at all is the hugeeeee amount of RL based on the loop of 1 "write code", 2 get compile time or runtime errors,3 fix it and iterate. Data file formats dont have that feedback loop so models will fall off the rails faster. Writing code that fits a latent adhoc schema just wont work as well, or will require burning a lot more context.
from that perspective, it could just be an EDSL little library in the host language, or it could be a friggin little custom language with an interpreter and good error messages.
> dct validate <file.yml>
Or any of the other commands that read the file will quickly fail with any syntax or SQL issues. It’s not just an open schema.
That lack of flexibility is actually a feature for one of the bigger problems we're solving: lineage, or knowing where a number came from. If the chart layer can't transform data, the logic stays in SQL, where you can version, test and audit it.
It's also a choice about who this is for. The data community already works in SQL, Jinja and YAML every day, so there's no new language to learn.
Looking forward to the yaml confusion when helm/dbt both see their default "charts/" directory in the same repo, or the dbt chart is set as a config map so it can be updated without rolling a new version of the full app... helm_argo is already a nightmare
rant aside, this does look super useful, and I do have CUE to help with the yamhell, but I may still prefer js/ts options so I can dynamically change the chart (like user clicking a dropdown for a different set of data). Sounds cool until the "dynamic" part of the chart shows it's limitations in crafting your ideal UX
I'll definitely be taking this for a spin, gets at that unbundling and "I need a quick chart" situations