Обзор книги “Learning Domain-Driven Design” — part IV (Data Mesh)

Эта последняя статья из серии с обзором книги Learning DDD, в которой мы рассмотрим data mesh. Рекомендую перед чтением этой статьи посмотреть предыдущие три части: 1, 2 и 3. Интересно, что про концепции DWH и data mesh я год назад сам рассказывал в лекции про данные из курса Essential Architecture, но тогда я не рассматривал их через призму DDD. В любом случае рисунок из той статьи может неплохо выступить в качестве заглавного в этой:)

Рис.1 “Что не так с DWH и Data Lake”

Данная глава начинается с того, что рассматривается понятия analytical data model и transactional data model. Краткое описание обоих доступно ниже.

Рис.2 “Analytical vs Transactional Data Model”

В описании аналитической модели упоминаются таблицы фактов и dimension tables, где факты представляют из себя информацию о произошедшие факты, а в dimension tables хранится информация о том, как эти факты описываются:) И в таблице фактов ссылаются на dimension table через foreign keys. Вот как это выглядит на рисунке

Рис.3 “Tables in analytical model”

Если суммировать, то отличия аналитической и транзакционной моделей данных сфокусированы вокруг гранулярности данных и предсказуемости запросов, которые над этими данными придется производить в будущем.

Рис.4 “Data Models Properties”

Отдельно стоит рассмотреть стандартные концепции построения стандартных аналитических моделей star и snowflake. Модель звезда приведена ниже.

Рис.5 “Star Schema”

Модель snowflake выглядит интереснее, но основная мысль в том, что dimensions у нас становятся многоуровневыми и поэтому схема становится визуально сложнее.

Рис.6 “Snowflake schema”

Дальше автор переходит к рассмотрению подходов к построению аналитических моделей. По-факту, у нас есть старый добрый DWH подход (data warehouse) и новый data mesh. У обоих есть преимущества и недостатки, но подход DWH концептуально ведет в тупик, так как пытается натянуть одну модель на всю организацию и из-за вездесущих ETL процессов приводит к жесткому coupling данных между transactional и analytical data plane. С этими проблемами борется подход data mesh, который базируется на четырех принципах, но его очень сложно применять на практике, так как уровень зрелости команд разработки должен быть очень высоким.

Рис.7 “DWH and Data Mesh”

Кстати, не только data mesh борется с проблемами в подходе стандартного DWH. Изначально их пытались починить при помощи подхода data lake и даже некоторые явные проблемы были устранены, например, data lake позволил работать с большим количеством аналитических моделей, направленных на разные задачи. Суть в том, что OLTP данные сначала выкачивались и сохранялись as is в data lake и дальше можно было строить на основе их любую модель. Но в результате этого у подхода data lake имелись и дополнительные недостатки.

Рис.8 “Data Lake”

В любом случае, что DWH, что data lake имели следующие проблемы

Рис.9 “Challenges of DWH and Data Lakes”

На этом фоне четыре ключевых принципа data mesh устраняют указанные выше проблемы

Рис.10 “Core principles of Data Mesh”

И data mesh очень неплохо комбинируется с подходами из DDD.

Рис.11 “Combination of Data Mesh and DDD”

На этом книга заканчивается, надеюсь, что вам она понравилась настолько же, насколько она понравилась мне:)