Data Arrow
Business Model → Data Model → dbt → Lineage → Graph Model
A practical walkthrough of how Data Arrow helps customers transform existing SQL and legacy analytics logic into a modern data foundation by reverse-engineering SQL with Re-SQL, reconstructing dimensional and semantic models, generating structured dbt projects, establishing lineage, and integrating the workflow with Git. Data Arrow helps turn hurdles such as undocumented logic, complex transformations, inconsistent models, and difficult-to-maintain pipelines into measurable value through faster modernization, better transparency, reusable standards, and a clear connection between business requirements and technical implementation.
Explore Data Arrow: Data Arrow — Business Driven Data Modelling
More about it here - https://medium.com/@anurathaakash/from-legacy-sql-to-analytics-how-re-sql-automates-dimensional-modeling-7a7e5a5588a2
Data Arrow was born from the frustration of seeing business logic scattered across SQL, dashboards, dbt models, and undocumented assumptions.
The goal is to help teams convert messy technical structures into clean, understandable, and executable data models.
It is not only about generating code.
It is about helping people understand the data model before they build on top of it.
Because in the end, a data platform is only valuable when both the business and the technical teams can trust the same model.
The Real Motivation
I did not build Data Arrow because the world needs another diagramming tool.
I built it because I felt there is a missing layer between business thinking and data engineering execution.
Many tools are good at execution.
Many tools are good at visualization.
But very few tools help someone understand:
What is the grain?
Is this a fact or a dimension?
Can this SQL be converted into a cleaner model?
How does this dbt lineage map back to business concepts?
Can this business model become executable dbt code?
Can the same model also become a graph model?
That is the gap Data Arrow is trying to solve.
-
1The gap between business modeling and data engineering is the interesting part. Curious where users feel the friction most: understanding the model, translating it into dbt, or keeping the business and technical representations aligned.
-
1
There are several complexities in modern data modelling, and many of them actually start with the fundamentals.
Even with Kimball, one of the biggest challenges is translating business requirements into a clear, consistent model while staying true to dimensional modelling standards.
That is exactly why we created Data Arrow — to help organize the different pieces of a business requirement and systematically translate them into a structured Kimball-based data model.
At the same time, dbt is sometimes mistaken for a data modelling platform. In reality, dbt is primarily a powerful data transformation engine. The business model and modelling decisions still need to come first.
Data Arrow is intended to bridge that gap:
Business Requirement → Dimensional Model → dbt TransformationMore than happy to have a discussion, walk through the approach, or offer access to the public preview free of cost for anyone interested in trying it.
-
1That makes sense. The business requirement → dimensional model → dbt transformation sequence makes the product’s role much clearer.
-
-
Comment