kimball book club

dbt was a phase shift for our team at work. When we adopted the tool, we had one data scientist, one data engineer, one data analyst, and a fearless leader shepherding us through the heady waters of quick number pulls. Much of our work was difficult to trace. We’d write SQL queries either embedded in a Python call to our data science database or write the queries in a Redash file and link them in the PR that had the Python notebook with the analysis and visualizations. It was difficult and annoying to trace the full pathway of an analysis project.

When we adopted dbt, we were excited by the version control features, organization of models into neat folders, and lineage of models through the DAG. This, plus the empowerment of me as an analyst to build models without relying on our brilliant data engineer, felt like a leap forward into the future. And it was—our data stack’s maturity shot up with the combined adoption of dbt, Databricks, and Looker1.

As we hired more folks onto our data team, we quickly realized our model proliferation was starting to look like the scary part of a hockey stick graph. It wasn’t the kind of hockey stick graph you want when trying to tame your data stack. This was one of those work problems where I noticed it but certainly did not have a solution. And, as has occurred several times before, I thanked the ancient earthen deities for sending us a terrific systems thinker in our data engineer. He brought up that he’d been reading Kimball’s data warehouse toolkit, as well as several ideas for merging some of Kimball’s practices with data vault principles to tame our data stack before it got completely out of control.

After the idea of a data warehouse remodel started to sink in with me, I roped our data engineer and our (at the time) new senior data analyst into reading the Data Warehouse Toolkit with me in a book club format. We agreed on meeting once a week and reading around half a chapter a week. This way, we’d make significant progress without stressing ourselves out.

Here’s a little captain’s log update on some of what we’ve been learning so far. This does assume some knowledge of Kimball stuff, so please google him if you’re not familiar.

Just because you Ameri-can, doesn’t mean you Ameri-should

Kimball is a snarky man2 who insists upon centralized dimensional models, arranged in a star schema fashion. He is the crusader in the night against models that do similar functions but exist separately in the warehouse. This is something we are guilty of as a data team-myself more than anyone else.

dbt makes it so damn easy to build new models! It is entirely too easy to build a model for one business purpose, stick it in a folder, and then forget what it’s called and accidentally build a similar model for a similar purpose somewhere down the line. This isn’t dbt’s fault3—it’s on you as a data practitioner to have a good sense of what modeling practices make sense for your data. But man, shiny tool syndrome and lack of knowledge around modeling best practices made me build extraneous models that we didn’t need.4

Reading Kimball has made me take a big step back when building any new models, and has even led me to develop a model deprecation strategy to clean house of our one-off, non-reusable models that we built when we were starry-eyed and new to dbt. The last few projects that I’ve worked on have been marked by thinking carefully about whether the new model I need makes sense within a fact/dim structure, what business process it is connected to, and who might want to use it in the future.

It’s early days yet in this process-but my senior data analyst counterpart has already re-used a model that I built for one semi-specialized project into another semi-specialized project. Since we’re both in the book club together, we’re thinking concurrently about how we can build models in what I perceive to be the marriage of both Kimball's and dbt’s spirits. How can we build models aligned with real business processes5 that are composable, recyclable, and version controlled6? That is our guiding light.

Subscribe now

Friends at work help, actually

Kimball book club has also been good for our professional relationships.

A topic for another blog post is going to be my changing relationship with work friendships. When I was in grad school, the friends that I invested the most in were my lab mates. That backfired spectacularly when I quit. I left that experience vowing to never have close work friends again.

Of course, dramatic vows in the wake of a big quit never stick. I took a teaching job in a middle school a few years later and developed a few close friendships that were instrumental in helping me survive the hardest year of my professional life. Those friendships are not part of my life anymore, but it’s for prosaic reasons. We don’t work together anymore, we live in different cities. We drifted apart but on quite good terms.

Heading into a career change and corporate America, I wanted to mingle caution with the understanding that workplace friendships are quite helpful when the going gets tough. Interpersonally, I find it fairly straightforward to make level-one type friends. You have a few common interests, you talk about those, and boom, your workday has a little extra spice in it.

I wanted friends who would push me professionally in my current workplace, and the book club has been a great vehicle for that. When I come up with discussion questions each week for book club, I’ll incorporate bits of my coworkers’ experience that I know they can use to speak to the week’s topic. Getting curious about my colleagues’ past professional experience as it relates to data modeling (and sharing my own) has enriched our professional relationships. We’re making space to actively learn from one another, and it’s a blast.

Learning from your coworkers can also just happen by osmosis, or passively. Nothing wrong with that! But part of why I’ve been enjoying book club is that it’s been a dedicated forum once a week for us to figure out what and how we can learn from each other while learning a new (to us) toolset at the same time. We can do so without worrying whether or not we’re making unreasonable demands on one another’s time. We all agreed to be in a book club once a week, so we know it’s a reasonable ask. \

Captain’s Log, stardate 04302023:

Ask yourself whether you should build a model before you hit go. Also, asking your coworkers about their experiences is a good thing and you should keep doing it. 7

1

Hate all you want! I enjoy this data stack, I’ll say it!

2

I recommend reading the data warehouse toolkit for his snark alone. It’s fantastic.

3

Ya’ll, I’ll die on the hill that shitty modeling practices aren’t your tool’s fault. Your tool is only as good as the users.

4

This is also one of those pernicious things about transitioning careers. My boot camp didn’t spend much time on data modeling principles at all. They were nowhere on my brain when I started modeling with dbt.

5

Kimball’s spirit. But who will think of the BUSINESS?!?!?!?!?!?!?!

6

Version control is the only reason I can sleep at night

7

Subscribe for more groundbreaking career tips. xD