Dwh что это такое
Что такое DWH?
Многим из нас периодически приходилось слышать три магические буквы DWH. Давайте посмотрим, что это такое и чем отличается DWH от обычных баз данных.
DWH расшифровывается как data warehouse, из чего легко догадаться, что аббревиатура имеет отношение к данным. Однако DWH отличается от простых баз данных. По сути, data warehouse — это склад данных, причем данных, которые нужны и важны для принятия решений в компании. Но, согласитесь, СУБД тоже содержат важные данные о клиентах, складских запасах, покупках и пр. Так где же граница между DWH и обычной БД?
Разница следующая:
Делаем вывод
Говоря простыми словами, DWH представляет собой систему данных, которая отделена от оперативной системы обработки данных в компании. То есть речь идет о корпоративных хранилищах, где хранятся архивные данные в удобном для анализа виде. Как было сказано выше, это могут быть данные из разных, порой даже очень разнородных источников. При этом данные перед сохранением предварительно обрабатываются. Из загрузка осуществляется вследствие ETL-процессов по извлечению, преобразованию и загрузке. Если же сказать совсем упрощенно, то решения ETL и DWH — это единая система, предназначенная для хранения корпоративной информации и работы с ней.
Архитектура хранилищ данных: традиционная и облачная
Привет, Хабр! На тему архитектуры хранилищ данных написано немало, но так лаконично и емко как в статье, на которую я случайно натолкнулся, еще не встречал.
Предлагаю и вам познакомиться с данной статьей в моем переводе. Комментарии и дополнения только приветствуются!
Введение
Итак, архитектура хранилищ данных меняется. В этой статье рассмотрим сравнение традиционных корпоративных хранилищ данных и облачных решений с более низкой первоначальной стоимостью, улучшенной масштабируемостью и производительностью.
Хранилище данных – это система, в которой собраны данные из различных источников внутри компании и эти данные используются для поддержки принятия управленческих решений.
Компании все чаще переходят на облачные хранилища данных вместо традиционных локальных систем. Облачные хранилища данных имеют ряд отличий от традиционных хранилищ:
Традиционная архитектура хранилища данных
Следующие концепции освещают некоторые из устоявшихся идей и принципов проектирования, используемых для создания традиционных хранилищ данных.
Трехуровневая архитектура
Довольно часто традиционная архитектура хранилища данных имеет трехуровневую структуру, состоящую из следующих уровней:
Kimball vs. Inmon
Два пионера хранилищ данных: Билл Инмон и Ральф Кимбалл предлагают разные подходы к проектированию.
Подход Ральфа Кимбалла основывается на важности витрин данных, которые являются хранилищами данных, принадлежащих конкретным направлениям бизнеса. Хранилище данных — это просто сочетание различных витрин данных, которые облегчают отчетность и анализ. Проект хранилища данных по принципу Кимбалла использует подход «снизу вверх».
Подход Билла Инмона основывается на том, что хранилище данных является централизованным хранилищем всех корпоративных данных. При таком подходе организация сначала создает нормализованную модель хранилища данных. Затем создаются витрины размерных данных на основе модели хранилища. Это известно как нисходящий подход к хранилищу данных.
Модели хранилищ данных
В традиционной архитектуре существует три общих модели хранилищ данных: виртуальное хранилище, витрина данных и корпоративное хранилище данных:
Звезда vs. Снежинка
Схемы «звезда» и «снежинка» — это два способа структурировать хранилище данных.
Схема типа «звезда» имеет централизованное хранилище данных, которое хранится в таблице фактов. Схема разбивает таблицу фактов на ряд денормализованных таблиц измерений. Таблица фактов содержит агрегированные данные, которые будут использоваться для составления отчетов, а таблица измерений описывает хранимые данные.
Денормализованные проекты менее сложны, потому что данные сгруппированы. Таблица фактов использует только одну ссылку для присоединения к каждой таблице измерений. Более простая конструкция звездообразной схемы значительно упрощает написание сложных запросов.
Схема типа «снежинка» отличается тем, что использует нормализованные данные. Нормализация означает эффективную организацию данных так, чтобы все зависимости данных были определены, и каждая таблица содержала минимум избыточности. Таким образом, отдельные таблицы измерений разветвляются на отдельные таблицы измерений.
Схема «снежинки» использует меньше дискового пространства и лучше сохраняет целостность данных. Основным недостатком является сложность запросов, необходимых для доступа к данным — каждый запрос должен пройти несколько соединений таблиц, чтобы получить соответствующие данные.
ETL vs. ELT
ETL и ELT — два разных способа загрузки данных в хранилище.
ETL (Extract, Transform, Load) сначала извлекают данные из пула источников данных. Данные хранятся во временной промежуточной базе данных. Затем выполняются операции преобразования, чтобы структурировать и преобразовать данные в подходящую форму для целевой системы хранилища данных. Затем структурированные данные загружаются в хранилище и готовы к анализу.
В случае ELT (Extract, Load, Transform) данные сразу же загружаются после извлечения из исходных пулов данных. Промежуточная база данных отсутствует, что означает, что данные немедленно загружаются в единый централизованный репозиторий.
Данные преобразуются в системе хранилища данных для использования с инструментами бизнес-аналитики и аналитики.
Организационная зрелость
Структура хранилища данных организации также зависит от его текущей ситуации и потребностей.
Базовая структура позволяет конечным пользователям хранилища напрямую получать доступ к сводным данным, полученным из исходных систем, создавать отчеты и анализировать эти данные. Эта структура полезна для случаев, когда источники данных происходят из одних и тех же типов систем баз данных.
Хранилище с промежуточной областью является следующим логическим шагом в организации с разнородными источниками данных с множеством различных типов и форматов данных. Промежуточная область преобразует данные в обобщенный структурированный формат, который проще запрашивать с помощью инструментов анализа и отчетности.
Одной из разновидностей промежуточной структуры является добавление витрин данных в хранилище данных. В витринах данных хранятся сводные данные по конкретной сфере деятельности, что делает эти данные легко доступными для конкретных форм анализа.
Например, добавление витрин данных может позволить финансовому аналитику легче выполнять подробные запросы к данным о продажах, прогнозировать поведение клиентов. Витрины данных облегчают анализ, адаптируя данные специально для удовлетворения потребностей конечного пользователя.
Новые архитектуры хранилищ данных
В последние годы хранилища данных переходят в облако. Новые облачные хранилища данных не придерживаются традиционной архитектуры и каждое из них предлагает свою уникальную архитектуру.
В этом разделе кратко описываются архитектуры, используемые двумя наиболее популярными облачными хранилищами: Amazon Redshift и Google BigQuery.
Amazon Redshift
Amazon Redshift — это облачное представление традиционного хранилища данных.
Redshift требует, чтобы вычислительные ресурсы были подготовлены и настроены в виде кластеров, которые содержат набор из одного или нескольких узлов. Каждый узел имеет свой собственный процессор, память и оперативную память. Leader Node компилирует запросы и передает их вычислительным узлам, которые выполняют запросы.
На каждом узле данные хранятся в блоках, называемых срезами. Redshift использует колоночное хранение, то есть каждый блок данных содержит значения из одного столбца в нескольких строках, а не из одной строки со значениями из нескольких столбцов.
Redshift использует архитектуру MPP (Massively Parallel Processing), разбивая большие наборы данных на куски, которые назначаются слайсам в каждом узле. Запросы выполняются быстрее, потому что вычислительные узлы обрабатывают запросы в каждом слайсе одновременно. Узел Leader Node объединяет результаты и возвращает их клиентскому приложению.
Клиентские приложения, такие как BI и аналитические инструменты, могут напрямую подключаться к Redshift с использованием драйверов PostgreSQL JDBC и ODBC с открытым исходным кодом. Таким образом, аналитики могут выполнять свои задачи непосредственно на данных Redshift.
Redshift может загружать только структурированные данные. Можно загружать данные в Redshift с использованием предварительно интегрированных систем, включая Amazon S3 и DynamoDB, путем передачи данных с любого локального хоста с подключением SSH или путем интеграции других источников данных с помощью API Redshift.
Google BigQuery
Архитектура BigQuery не требует сервера, а это означает, что Google динамически управляет распределением ресурсов компьютера. Поэтому все решения по управлению ресурсами скрыты от пользователя.
BigQuery позволяет клиентам загружать данные из Google Cloud Storage и других читаемых источников данных. Альтернативным вариантом является потоковая передача данных, что позволяет разработчикам добавлять данные в хранилище данных в режиме реального времени, строка за строкой, когда они становятся доступными.
BigQuery использует механизм выполнения запросов под названием Dremel, который может сканировать миллиарды строк данных всего за несколько секунд. Dremel использует массивно параллельные запросы для сканирования данных в базовой системе управления файлами Colossus. Colossus распределяет файлы на куски по 64 мегабайта среди множества вычислительных ресурсов, называемых узлами, которые сгруппированы в кластеры.
Dremel использует колоночную структуру данных, аналогичную Redshift. Древовидная архитектура отправляет запросы тысячам машин за считанные секунды.
Для выполнения запросов к данным используются простые команды SQL.
Panoply
Panoply обеспечивает комплексное управление данными как услуга. Его уникальная самооптимизирующаяся архитектура использует машинное обучение и обработку естественного языка (NLP) для моделирования и рационализации передачи данных от источника к анализу, сокращая время от данных до значения как можно ближе к нулю.
Интеллектуальная инфраструктура данных Panoply включает в себя следующие функции:
По ту сторону облачных хранилищ данных
Облачные хранилища данных — это большой шаг вперед по сравнению с традиционными подходами к архитектуре. Однако пользователи по-прежнему сталкиваются с рядом проблем при их настройке:
Что такое DWH и почему без них данные компании почти бесполезны
Тем, кто работает в крупном бизнесе, периодически приходится слышать три магические буквы — DWH. Узнав расшифровку этой аббревиатуры — data warehouse, можно догадаться, что это имеет отношение к данным. А вот чем DWH отличается от простых баз данных, почему вокруг них снуют рои бизнес-аналитиков и зачем вашей компании иметь такую штуку — это всё еще непонятно. Разбираемся в статье.
DWH — что это и в чем отличие от баз данных
Data warehouse — склад всех нужных и важных для принятия решений данных компании.
Но есть же всякие базы данных внутри фирмы, разве они не DWH? Например, СУБД с клиентами, складскими запасами или покупками. Где разница между обычной базой данных и DWH?
Короче говоря, DWH — это система данных, отдельная от оперативной системы обработки данных. В корпоративных хранилищах в удобном для анализа виде хранятся архивные данные из разных, иногда очень разнородных источников. Эти данные предварительно обрабатываются и загружаются в хранилище в ходе процессов извлечения, преобразования и загрузки, называемых ETL. Решения ETL и DWH — это (упрощенно) одна система для работы с корпоративной информацией и ее хранения.
Что дают DWH-решения для BI и принятия решений в компании
Понятное дело, что просто так тратить деньги и время на консервирование кучи разных записей, которые и так можно накопать в других базах данных, никто не станет. Ответ заключается в том, что DWH необходима для того, чтобы делать BI — business intelligence.
Что такое BI с DWH? Бизнес-аналитика (BI) — это процесс анализа данных и получения информации, помогающей компаниям принимать решения.
Если бы такого аналитического отчета не было — управленцам пришлось бы искать проблему наугад.
Логичный вопрос: казалось бы, зачем держать для этого всего DWH? Аналитики вполне могут ходить в базы данных разных систем и просто выдергивать оттуда то, что им надо.
Ответ: так, конечно, тоже можно делать. Но — не нужно. И вот почему:
Для работы с большими данными используют различные решения, обрабатывающие информацию из DWH. SAS, VK Cloud Solutions (бывш. MCS) и другие компании предлагают различные варианты коробочных и облачных решений под такие задачи.
Пять подходов к построению современной платформы данных
Время + данные = выгода
Любая крупная компания, начинающая работать с данными, которыми обладает, преследует одну первостепенную задачу: получить из них выгоду. При этом ценность данных напрямую зависит от времени, которое требуется на их анализ, обработку. Именно эта зависимость влияет на то, какое архитектурное решение наилучше подойдёт для реализации конкретных задач бизнеса.
Чтобы проследить зависимость ценности данных от времени, рассмотрим абстрактный график (рис. 1). Его левая часть демонстрирует данные, возникающие в режиме реального времени в системах источников. Поскольку это крайне динамичный процесс — речь может идти о миллисекундах и секундах, важно научиться эти данные обрабатывать.
Правая часть графика показывает данные, которые накапливает организация. Именно в ней содержится основная историческая ценность: все паттерны поведения различных клиентов, устройств.
Средняя часть графика представляет наименьший интерес с точки зрения получения выгоды. Данные возникают слишком быстро, и мы не можем реагировать на их обработку оперативно, либо данных недостаточно, и мы не получаем качественную статистическую выборку.
Учитывая зависимость данных от времени, поговорим о пяти подходах к построению платформы данных.
Традиционный подход к построению платформы данных
Как работает. ETL-инструмент извлекает данные систем-источников, в процессе чего обрабатывает их, преобразует и загружает в централизованное хранилище данных. На базе этой информации строятся витрины данных, и конечный пользователь в виде BI-систем, процессов Data Mining, OLAP получает какую-то конкретную выгоду.
Основные ограничения. Наиболее актуальная проблема традиционного подхода к построению платформы данных заключается в том, что с момента возникновения данных во front-end системе до момента получения выгоды проходит значительное количество времени. Несмотря на то что в процессе эволюции этот период сократился с 3-4 дней до 1 дня, на текущий момент это всё ещё «очень долго». А любое изменение на источнике или перемены требований со стороны бизнеса влекут «дорогостоящий» процесс по переработке структуры данных хранилища и необходимости получения истории из источников.
Именно поэтому традиционный подход к построению платформы данных редко используется в самых новых проектах (greenfield-проектах). Но многие компании продолжают его эксплуатировать, несмотря на текущие ограничения.
Вторая проблема традиционного подхода к построению хранилища данных заключается в сложности обеспечения отказоустойчивости в случае потери самого ландшафта или инфраструктуры, которые используются под хранение данных. Восстановление системы может занимать несколько дней. Это происходит потому, что помимо основного контура, где наблюдается отставание систем-источников, приходится использовать резервный контур, который ещё больше отстаёт. Поэтому крайне сложно получить актуальные данные в случае выхода из строя каких-то частей основного ЦОД.
Третье ограничение традиционной платформы данных в том, что она может обрабатывать только структурированные данные. Данные другого типа не используются.
В качестве технологий хранения, как правило, использовались Single-Node Processing (SNP) БД: такие как Oracle, SQL Server и их аналоги. В связи с этим масштабирование платформы и архитектуры предполагало Scale-Up подход, когда при достижении пика производительности необходимо было заменять практически всю инфраструктуру.
Пример использования. Традиционная архитектура использовалась практически во всех компаниях на заре работы с Big Data в середине 2000-х годов, особенно в финтехорганизациях. Наиболее крупные хранилища могли исчисляться десятками терабайтов.
Advanced Architecture
Как работает. В ход пошла ELT-технология: сначала данные извлекаются и загружаются в конечную систему, и лишь после этого происходит их преобразование. Advanced Architecture даёт возможность получить копию исходных данных систем-источника и дальше производить над ними любые манипуляции, не нагружая саму систему источника. Это упрощённый процесс с точки зрения подхода к получению исходных данных: не нужно производить какие-то сложные ETL-процессы преобразования, агрегации. Зато можно хранить сырые данные и получать исторические изменения без необходимости заново получать информацию из источника.
Основным драйвером такого подхода стало появление систем класса MPP — массивно-параллельной обработки и возможность использовать pushdown-оптимизацию (рис. 4). Совмещение этих технологических подходов дало возможность переносить данные из систем-источников в мощное технологическое решение MPP (среди них Teradata, Vertica, Greenplum).
Advanced Architecture реализует концепцию распределённой обработки и возможности горизонтального масштабирования. Такой подход позволяет эффективно преобразовать сырые данные в некие различные слои — как детальные данные, так и витрины, отчёты. При этом таких слоёв может быть несколько. За счёт этого время получения результата сократилось в часы вместо 3-4 дней.
Отставание помог сократить не только ELT-подход, но и CDC (change data capture) — технология, позволяющая воспроизвести изменения систем-источников на удалённом целевом решении, в том числе на уровне MPP-платформ. Здесь существует несколько подходов, но основной из них заключается в том, чтобы использовать так называемые логи или trail-файлы, позволяющие воспроизвести полностью весь цикл изменения исходных данных на системе-источнике и целевой системе.
В результате появляется возможность получить изменение систем-источников, например, в пределах 15 минут. Но это в теории: как правило, процесс занимает чуть больше времени из-за существующей нагрузки на источник. Решить эту проблему помогают механизмы, позволяющие использовать холодные копии исходных данных и воспроизводить именно их. В результате можно сократить отставание до 1-2 часов.
При помощи CDC Advanced Architecture позволила решить проблему и аварийного восстановления (Disaster Recovery). Передача данных обеспечивается различными контурами за счёт воспроизведения изменений на системе-источнике. Это позволяет получить консистентное состояние данных на уровне катастрофоустойчивости с точки зрения отставания в несколько десятков минут.
Основные ограничения. Advanced Architecture не позволяет решать задачи, возникающие в режиме реального времени, потому что оперирует интервалом в десятки минут. Этому препятствует необходимость использовать сторонние инструменты для масштабирования потоков данных, да и сами изменения данных происходят с задержкой.
Modern Data Architecture
Основным драйвером развития Modern Data Architecture стало появление на рынке такого технологического решения, как Apache Hadoop. Оно позволило в значительной степени снизить ТСО (total cost of ownership) системы за счёт того, что Hadoop изначально является открытым проектом (open source) и разрабатывался для работы на любом повсеместно используемом (commodity) оборудовании.
Здесь же появились механизмы, позволяющие как упростить процесс аварийного восстановления самого решения, так и обеспечить Disaster Recovery различных решений с помощью сторонних средств, входящих в экосистему Apache Hadoop.
Использование Apache Hadoop привело к появлению в подходе к построению современного хранилища данных такого термина, как озеро данных (Data Lake). Его автором стал Джеймс Диксон, один из основателей Pentaho. Идея Data Lake заключается в том, чтобы интегрировать Hadoop-решения в существующие у заказчиков legacy-архитектуры. Благодаря этому можно ускорить процесс подготовки данных, решить вопрос, связанный с хранением большого объёма информации, и гибко использовать широкую экосистему инструментов для эффективного анализа данных.
Modern Data Architecture позволила обрабатывать неструктурированные данные, а также разгрузить дорогостоящие как front-end системы, так и различные DWH-системы.
Как работает. Концепция Modern Data Architecture описана на рисунке 5. Существует DWH-архитектура, которая изначально была построена компанией. В ней протекают свои ELT-процессы. Рядом появляется уровень Hadoop, а вместе их можно назвать Data Lake. На себя Hadoop забирает всю нагрузку с точки зрения долговременного хранения детальных данных, агрегаторов, аналитических архивов, включая данные, попадающие из неструктурированных и слабоструктурированных источников (clickstream, логи). DWH и Hadoop интегрированы между собой набором решений — коннекторами, жизненным циклом данных (процессы, определяющие, какие данные являются востребованными, а какие архивными).
Основное достоинство Modern Data Architecture заключается в том, что компания может получать данные другой структуры, а их отставание от источников сокращается за счёт использования более технологичных и распределённых инструментов обработки. Для эффективной передачи потоковых данных появились стриминг-технологии (Apache Flink, Apache NiFi), которые дали возможность перейти к нативной обработке потока данных в его явном виде. Благодаря им компании смогли решать задачи, ранее недоступные им, при помощи микробатч-процессов обработки данных и строить совершенно новые архитектуры платформ данных.
Основные ограничения. У Modern Data Architecture отсутствует чёткий дизайн с точки зрения имплементации тех или иных решений. А концепция реализации во многом зависит от видения главного инженера проекта.
Более того, бизнес-потребности компании со временем эволюционируют, и задачи, изначально возложенные на хранилище данных, могут меняться. Поэтому время построения каких-то статичных отчётов может увеличиваться с нескольких минут до нескольких часов. Одна из причин: быстрый рост пользователей и бизнес-кейсов, решаемых на Modern Data Architecture и в некоторых случаях не подходящих по нагрузке и сценарию использования данных.
Не до конца решена в Modern Data Architecture и проблема аварийного восстановления, несмотря на имеющиеся в Hadoop специфические инструменты отказоустойчивости.
Ещё одна проблема Modern Data Architecture выходит на сцену, когда Data Lake превращается в Data Swamp — болото данных. Это происходит тогда, когда компании в лавинообразном порядке начинают складывать в Hadoop все данные, которые у них есть. В результате теряется смысл данных, пропадают связи между ними. К счастью, сейчас появился ряд проектов, позволяющих структурировать этот подход и решить вопрос, связанный с построением общей таксономии данных, которые есть в системе. Делается это автоматически. Типичным представителем таких проектов является Apache Atlas.
Многие компании сейчас разрабатывают общую спецификацию построения концепций стратегического управления данными и их качеством. Например, этот вопрос один из первостепенных для некоммерческих организаций, развивающих Open Source, например Open Data Platform Initiative (ODPi).
Пример использования. Data Lake является эволюционным шагом в развитии архитектуры обработки данных. Например, одна европейская телеком-компания смогла снизить текущую нагрузку на инфраструктуру и решить задачу по удержанию клиентов за счёт обработки неструктурированных данных — лог-файлов, где хранилась уникальная информация по обрывам связи. Причём данные загружались и обрабатывались именно за счёт внедрения архитектуры Data Lake. А благодаря появлению новых инструментов был реализован ряд механизмов, позволяющих совершать предиктивные действия по отношению к клиенту.
Lambda Architecture
Как работает. Lambda Architecture позволила немного «ослабить» CAP-теорему. Согласно ей ни одна техническая система одновременно не может удовлетворять трём условиям: консистентности, доступности и распределённости. Натан Марц предложил разделить технологические уровни на несколько частей и использовать для них различные технологии, закрывающие со своей стороны два из трёх ограничений CAP-теоремы. Основная идея предполагает существование трёх уровней, позволяющих решать вопросы как real-time обработки (speed layer), где данные появляются в течение миллисекунд, так и исторического слоя (batch layer), когда есть данные, которые нужно хранить в долгосрочной перспективе. Для решения этих задач в платформе хранения данных присутствует федеративный уровень, который может получать оба типа данных и решать задачи разного типа, класса в различных режимах (рис. 7).
Основные ограничения. Поскольку Lambda Architecture достаточно сложная с точки зрения имплементации, возникает проблема внедрения и эксплуатации таких решений в legacy-инфраструктуры. Однако, в отличие от Modern Data Architecture, существует много информации, включая книгу, которую написал Натан Марц, как реализовать ту или иную часть платформы.
Но остаются вопросы, как перейти на Lambda Architecture с legacy-инфраструктуры. На помощь здесь приходит бимодальное ИТ: рядом с существующей legacy-инфраструктурой строится новая инфраструктура, которая работает для новых проектов. В процессе эксплуатации на новую архитектуру переносятся и критичные для бизнеса задачи.
Второй подход — итеративная имплементация различных дополнительных решений. Этот подход актуален, если изначально путь построения архитектуры подразумевал переход к задачам, связанным с real-time. Например, компания начала с реляционной базы данных с DWH, затем появился Hadoop как озеро данных, на уровне которого в текущую инфраструктуру интегрируются новые инструменты для работы с задачами в режиме реального времени. Так, воспользовавшись вторым подходом, крупная компания смогла в режиме реального времени получать данные с датчиков, установленных на дорожной технике. Анализируя поступающую информацию, бизнес смог сократить расходы на ремонты автомобилей, вовремя внедряя результаты предиктивной аналитики.
Пример использования. Lambda Architecture получила распространение в производственных компаниях и автомобильной индустрии. Некоторые добывающие компании реализовали такой подход для решения задач предиктивного обслуживания и выявления угроз на производстве. На базе исторического слоя собиралась статистика по работе узлов и агрегатов, строились паттерны, позволяющие выявлять потенциальные проблемы. Эти модели работали на уровне speed layer и позволяли в режиме реального времени выявлять ранее смоделированные события.
Data Mesh Architecture
Что это такое. Data Mesh Architecture придумала Жамак Дегани. По её мнению, новый подход поможет компаниям разработать платформу данных третьего поколения, учтя ошибки двух предыдущих (проприетарные хранилища данных и использование Data Lake в качестве серебряной пули). Data Mesh Architecture активно использует стриминг-технологии, объединяет пакетную и потоковую обработки данных, а хранит данные в облаке. Благодаря этому у компаний появляется возможность анализировать данные в режиме реального времени, снизив при этом затраты на управление инфраструктурой хранилища.
Как работает. Главное отличие Data Mesh Architecture от предыдущих поколений платформ хранения данных заключается в том, что данные не передаются в Data Lake. Они хранятся и используются командами внутри бизнес-доменов в удобном для них виде. При этом данные в разных доменах могут дублироваться, когда происходит их изменение на удобный конечному пользователю формат.
Основные ограничения. Чтобы перейти на Data Mesh Architecture, любой компании предстоит пройти большой путь, и речь тут даже не об использовании технологий. Чтобы масштабировать новые принципы, необходимо серьёзно подойти к ведению бизнес-процессов.
Пример использования. Data Mesh Architecture наиболее востребована в компаниях с высокой динамикой роста бизнеса и направлений: среди них крупные ритейлеры, которые или уже перешли на эту архитектуру, или начинают процесс перехода. Это позволит им быстро включать в процесс обработки и подготовки данных новые филиалы и направления бизнеса за счёт возможности масштабирования команд, отвечающих за свою часть данных.
Какой из пяти перечисленных подходов к построению платформы выбрать — решает каждая компания для себя. Однако важно подойти к этому вопросу, вооружившись практическими знаниями. Поэтому, чтобы получить эффективно работающие хранилище, желательно найти партнёра, который имеет большой опыт в успешной реализации подобных проектов.