В данной статье я бы хотел вкратце рассказать о самых известных подходах к построению хранилиз данных, а именно:
Важно заметить, что я не ставлю целью раскрыть все детали, так как каждая из этих концепций заслуживает отдельной подробной статьи.
Итак, поехали.
Inmon
Начнём с подхода, созданного Биллом Инмоном, он подразумевает рассматривание организации сверху вниз,
когда структура данных известна на всех уровнях, доступна цельная картина того, как данные передаются внутри компании,
а сами данные смоделированы в соответствии с третьей нормальной формой.
Каждая логическая модель содежит все детали, исчерпывающую информацию, связанную с этой конкретной сущностью, дублирование данных сведено к минимуму.
Самый большой минус данного подхода, что он требует досконально знать все структуры данных, это может потребовать слаженной работы
очень талантливых людей, чтобы правильно спроетировать все сущности и соединения между разными компонентами. Особенно сложно
реализовать такой сценарий в больших компаниях.
Kimball
В противоположность предыдущей концепции, данная, созданная Ральфом Кимбаллом, рассмативает организацию снизу вверх.
Ключевые источники данных, такие как операционные системы, известны и задокументированы.
Обычно проще начать с Kimball, разделив данные на витрины данных согласно отделам компании.
Но впоследствии модель будет сложнее масштабировать.
Различные ETL инструменты берут данные из источников и загружают их в промежуточный слой данных.
На следующем этапе формируются витрины данных, различные измерения.
Ключевой момент заключается в том, что данные не нормализованы,
вместо этого они организованы либо в схему “звезда” или “снежинка” (в определённых случаях).
Data Vault
Data Vault (я не буду переводить термины, которые не имеют однозначного перевода на русский) - гибридный подход, сочетающий практики OLAP и схемы “звезда”, который обеспечивает масштабирование с учетом растущих бизнес-требований и служит для устранения сложностей как моделирования, так и ETL.
Основными компонентами являются: хабы (hub, бизнес-сущности), ссылок (link, отношений) и сателлитов (satellit, описательные атрибуты). Подход особенно интересен в случаях, когда требуется поддерживать и хранить исторические изменения данных, так как DV подразумевает хранение всех фактов, без разделения на плохие и хорошие данные, в противоложность другим подходам к DWH, исповедующим подход “единственная версия правды” (single version of truth)
Метод моделирования разработан так, чтобы быть устойчивым к изменениям в бизнес-среде, откуда поступают данные,
путём отделения структурной информации от описательных атрибутов.
DV предназначен для обеспечения максимально возможной параллельной загрузки, поэтому даже очень большие инсталяции
могут масштабироваться без необходимости серьезной модернизации.
Data lake
Довольно популярный подход в настоящее время, так как количество данных быстро растёт и зачастую создаёт трудности в коммуникации
и понимании данных между различными отделами, особенно в больших компаниях.
В отличие от традиционных подходов, Data Lake хранит всю информацию из источников как есть, в сыром виде,
опционально с добавлением служебных колонок created_at, updated_at.
Важно отметить, что сохраняются не только данные, которые используются прямо сейчас, но и те данные, которые могут быть потенциально использованы в будуем, и даже те, которые возможно не будут использованы совсем. (просто потому что может быть когда-нибудь они пригодятся) Таким образом, зачастую используется стандартизированное железо в сочетании с дешёвым хранилищем (Hadoop, S3, и пр.), которые позволяют масштабироваться до терабайтов и петабайтов по вполне разумной цене.
В качестве аналогии можно сравнить этот подход с гигантской ванной из разных Лего-кубиков без чёткого плана, как они сочетаются. а некоторые детали будут нестандартными - тот, кто будет играть с ними, может собирать их так, как считает нужным, лишь бы это работало.
Некоторые Data Lake используют многослойную архитектуру - слой сырых данных, над ним слой минимально очищенных данных, которые были стандартизированы, очищены, возможно применены какие-то оптимизации для ускорения чтения, но в целом структура сырых данных сохраняется и здесь.
Lakehouse
Следующий подход стремится взять лучшее из обоих миров DWH и DL, создавая единую платформу для всех трансформаций данных, бизнес-аналитики и data-science. Вычислительные мощности не привязаны к хранилищу, следуя обычным подходам DWH к управлению данным, при этом используется то же самое дешёвое хранение данных, как и в случае с Data Lake. Некоторые из преимуществ такого подхода:
- Единая точка контроля данных
- Единый формат файлов на всех уровнях
- Упрощённое управление схемой данных
- Поддержка ACID транзакций