Using data to find mushrooms (Tableau vs Omni Version)
📣 If you’re not invested in the tool comparison and just want to find more mushrooms -> click here.
📚 Context
Two things I’m really passionate about are foraging for mushrooms and data. Given that I’ve been doing a fair amount of comparisons between analytics tooling lately, I figured why not have some fun with this one and build a data tool to help people find mushrooms using both Tableau and Omni, then write up some of the differences between the tools.
For context, in order to be successful in finding mushrooms, it’s helpful to know basic habitat features, what the mushroom looks like, what time of year the mushroom you’re looking for grows, where they grow, and if you know somebody else has found the mushroom you’re looking for in the area. With this project I aimed to bring many of those data points into a single tool to inform mushroom hunters, you’ll still need to go outside and start looking in order to be successful though!
👨🏻🍳 Tableau vs Omni Bakeoff results
Even though I really enjoy Omni in a professional context due to its feature set prioritizing the semantic layer, collaboration via integrations with dbt and git, and its cloud native architecture, Tableau was the better tool for the job in this bakeoff. Omni did win the last bakeoff that was focused on embedded analytics, if you’re interested, you can read more on that here.
What ultimately made Tableau the winner? One of the main criteria in this bakeoff was being able to publicly share the end product Tableau Public makes this free and super easy. Another standout item that Tableau has is the ability to configure dashboard actions, which provide a hands on experience to end users and create a fun and interactive experience.
💾 Connecting to data (+1 for Omni)
Once I identified the data that would I help me find more mushrooms, I loaded it into a Snowflake. I did a bit of data processing and modeling in Snowflake to get a usable dataset, the raw outputs from census.gov were usable without converting them into a .geojson, and the exports from iNaturalist had limits and needed to be aggregated so that they could be analyzed together. Man… I gotta say, Snowflakes UI + pick your LLM of choice makes that super easy these days. In order to practice the amazon core value of frugality, I accomplished a lot of this work by using free tier LLMs until I’d hit my rate limits, then I’d switch over to another one and so forth.
Once I had my data in Snowflake in the format that I wanted, I then needed to connect the tools. I was able to get Omni connected to my Snowflake environment within minutes, mostly due to their excellent documentation and cloud native ecosystem.
Tableau took quite a bit longer to get connected given that I needed to download an ODBC driver, it had to be a certain version, and I had to log into my tableau account to get Tableau/Salesforce’s recommended drivers. To be honest, this was quite annoying and felt like a wild goose chase to get something that felt like it should just work natively. I ended up needing to switch to a CSV as a data source to publish to Tableau Public in the end, so jokes on me.
👷🏻♂️ Data Modeling and Semantic layer (+1 for Omni)
Omni models are built out in YAML, which as a language tends to be a bit picky. If I’m being honest, it took me a bit to get comfortable with. That being said, the model IDE is where you do a lot of your heavy lifting for Omni. The way that I generally operate when building content out in Omni is with two windows open on a big monitor, One window open in the model IDE and one window open in the workbook that I’m developing in. This enables me to update logic, set default colors, sorts, filters, user adjustable values etc in the IDE and then save them to the model, push the changes, and then benefit from that in the workbook. The main thing I like about this, is that it’s all in SQL, all version controlled, all in the cloud, and can all be checked in, reviewed, and provide value to more users that may want to derive value from the same data set. In this case, I preferred omni because update your logic directly in the YAML file with full data lineage as to what logic is being applied, and see it all in one place.
On the other hand, Tableau has features that allows the user to do fast exploration via dragging and dropping, and to be honest may cater to users that are more comfortable connecting to flat, cleaned, de-normalized tables. Due to prioritizing this type of user, the features and functionalities around using custom SQL connect in Tableau have not really evolved since the notepad style pop out box was introduced about 10 years ago. While this ended up being okay for my current project at hand as I’d already written up my logic in snowflake, it still felt clunky given that you just take your sql and plop it into your data connection, in a place that users that do not have a creator/developer license will not be able to access. Sure, you can create a Tableau published data source (.tdsx) file with your semantics, and publish it to Tableau Online or Tableau Server, however this does not end up being recyclable for other tools in your data environment as it’s not a standard format, and the more of this that you do just ends up creating a larger and larger vendor switching cost. Perhaps not relevant to this specific bakeoff, but it’s likely the resurgent trauma from all of the times that I’ve been trying to collaborate with other developers on published data sources, and the combination of the semantic layer sometimes being stored locally in an extract, and then sometimes overwriting various versions of a .tdsx file published on Tableau Server or Tableau Online with limited change controls is still fresh with me, and that’s not even mentioning extracts failing and crashing workbooks when trying to publish 🥲.
👨🏻🎨 Visual development (+1 for Tableau)
Tableau still takes the cake on visual development. The thing that I still love about tableau is something that Francois Ajenstat, one of the people I admire most in the industry, used to obsess over - the developer flow. Tableau’s whole product has been designed around the concept that every chart is a combination of the stuff you select on the marks card, and what’s on your columns (X axis) and rows (Y axis). The flow also prioritizes things like dashboard actions that allow the user to click on one chart to filter another chart. I like all of these fun bells and whistles as they provide for a very hands on experience whilst exploring data, particularly if you’re experienced with the product.
Given that Omni has prioritized a more technical developer experience, the tool is still lacking in the department of front end developer flow and data exploration. You can select from a pre-canned library of charts, if you want to go past that your only real option is to use the Vega-Lite chart library which unlocks some cool charts but restricts some functionality including drill downs. To me, the Vega-Lite library feels like something that could be really powerful one day, but still needs a bit more work to make it practical to use for the majority of users on a regular basis. The biggest thing that I wish omni had for this project/demo was the ability to do what Tableau calls dashboard actions, or what Looker would call cross filtering. Currently, Omni does not support the ability to click on one chart to filter another chart on the dashboard, which takes away from the hands-on data exploration experience of the end user. The workaround that I used to provide a similar end user experience to Tableau’s dashboard action feature that enables the user to click on the map and see an image of the mushroom, was to add a table that has the top 10 records based on the filters configured by the user.
🤌 Sharing Content Publicly (+2 for Tableau)
Tableau has Tableau Public, which supports sharing of packaged workbooks (.TWBX files). I absolutely love this about Tableau, given that you can share content with the broader community to get input on how to solve problems, help others solve problems, or just share cool data insights. Tableau Public is such a great way for people to explore, learn, share, experiment, and just have fun with data. Being able to share the end tool publicly was critical to my solution, so I gave it a +2 for this.
Omni does not have a public cloud for sharing content, I’ve got the turned on in my demo environment, however embedding within products is quite a bit different than embedding publicly. When you’re embedding in a product or controlled environment, the experience is almost always gated by user logins that provide user specific experiences with features like permissions, row level security and access filters. If Omni ships a feature update that enable intuitive public sharing of content or helps me get this configured, or helps me bypass the current limitation, I’ll update this blog with the omni content and adjust the score accordingly 😉.
Summary
Both Tableau and Omni are great tools, it’s very clear that they cater to different strengths. Comparing in this context did not feel like an apples to apples experience given that they have such different approaches to providing value with data.
I hope this was helpful, please reach out if you’re interested in discussing further, or if you have any feedback for my mushroom finding tool 😊.
Josh
Link to Tableau Public dashboard.
