For me it was this: ”Moreover, there seems to be little justification for adopting a Data Vault model, especially considering the flexibility of the lakehouse architecture.” Pity its about to be published in an O’Reily book. https://learning.oreilly.com/library/view/-/9781098178826/ch02.html

"I'm currently diving deeper into the concepts of Data Mesh and Data Fabric, especially from an organizational and strategic perspective. Does anyone have good resources or reading recommendations on this topic? I'm particularly interested in the organizational aspects but also open to resources that focus more on the architectural approaches. Thanks in advance!

The question arose as to the correct way to model address data. Michael Olschimke explained his point of view and shared his idea on how to proceed in the latest session of Data Vault Friday. You can find the video either here in the classroom or below. How would you model address data? Would you do it differently to Michael?

Of course there are dozen of tips available for Snowflake, but let me share the ones which came into my mind very quickly: 1) Understand how Snowflake stores the data! They are using micro-partitions, organized in a columnar way. Micro Partitions store statistics like distinct values and value-ranges for each column. Your goal should always be to prune as much as possible from both when querying data. For example: Only select columns you really need, and apply filters on columns where the values are mostly not overlapping multiple Micro Partitions. Also think on re-clustering your data if necessary, or creating your own values with a pattern to cluster your data on (usually only necessary for huge amounts of data in one table). 2) When data is spilled to local storage while querying, is a good indicator that a bigger warehouse makes sense. I assume here that the query itself is already optimized and we are just dealing with a lot of data and maybe complex logics. But keep in mind: Increasing the size of the Snowflake Virtual Warehouse by 1 step (i.e. M -> L), doubles the costs or the same runtime! (calculated per cluster). So, when the query time is less than 50%, we achieved a win-win: faster & cheaper result! If the runtime could not be reduced by 50% or more, then you have to decide whether the quicker response is worth the money you now spend. 3) Snowflakes no-copy clones allow you to test features and fixes against your production in a very easy and fast way. It should be part of your deployment pipelines. 4) Insert-only reduces the number of versions Snowflake has to create for the Micro Partitions. Updates and Deletes cause this versioning of already existing Micro Partitions what costs time and additional storage. That also means that Data Vault with its Insert-Only approach meets the scalability factors of Snowflake! 5) The QUALIFY statement improved the code writing a lot. It is using the result of a window-function as filter, means, you don't have to write nested sub-queries with and self-joins.

Are you aware of publicly accessible examples for Data Vault 2.0 implementations? I published a data vault example with oracle for training purposes here: https://danielfritzler.de/data-vault-oracle.html and then there is the willibald implementation with datavault4dbt https://www.linkedin.com/pulse/willibald-data-vault-warehouse-dbt-andreas-haas/ Do you have more?