Несмотря на то, что Lakehouse пытается объединить характеристики Data Warehouse и Data Lake, интегрируя функции ACID и CRUD поверх хранилища объектов, приоритет должен отдаваться подходящим методам моделирования данных, которые широко используются в хранилищах данных.
Медальонная архитектура является ключевой концепцией домика у озера, которая включает в себя посадочную зону для необработанных данных в исходном формате, бронзовую зону для необработанных данных, преобразованных в ваш формат хранения (дельта, айсберг и т. д.), серебряную зону для очищенных и отформатированные данные в соответствии с бизнес-стандартами, в основном в формате OBT, и золотая зона для бизнес-агрегатов и моделей данных для BI.
Lakehouse был создан для обработки неструктурированных данных в различных формах, от XLSX до MP4. Большинство систем обработки данных позволяют создавать традиционные таблицы из таких двоичных и неструктурированных данных, используя такие функции, как айсберг и дельта.
Lakehouse — это просто уровень метаданных, созданный поверх озера данных, который предоставляет возможности запросов, подобные хранилищу данных (с поддержкой ACID), в масштабе непосредственно из озера данных.
Вместо того, чтобы проводить ETL и запрашивать данные из хранилища данных, мы немедленно запрашиваем данные из озера данных, каталогизируя данные (подумайте о хранилище метаданных hive).
Вот несколько примеров сопоставимых дизайнов, которые помогут вам понять:
Хранилище метаданных Hive (HQL) -> Озеро данных HDFS
Amazon S3 -> Каталог Amazon Glue (Athena SQL)
DeltaTables (SQL) → Databricks (DBFS/AWS S3/Google Storage/Azure Blob)
Согласно моему исследованию, моделирование в стиле Инмона является лучшей стратегией для домика у озера. В этом случае слои Bronze и Silver будут ориентированы на источник, а в качестве источника будет использоваться нормализованная модель ER. Затем данные Bronze будут вставлены в уровень Silver, который будет отражать уровень хранилища данных Inmon Data Warehouse.
В соответствии с потребностями бизнеса уровень Silver используется для создания или обновления витрин данных на уровне Gold. Для этого я создал схемы звезд в стиле Кимбалла с таблицами фактов и измерений Delta Lake. Эти звездообразные схемы будут уникальными для каждого проекта или варианта использования без стандартного размера. Кроме того, использование Serverless Compute, Power BI или любого другого инструмента BI будет выполнять запросы по этим схемам типа «звезда».
Вам не нужно полностью попадать в ловушку чистого Инмона. Денормализованные модели данных отлично подходят для отчетов, визуализаций, информационных панелей и аналитики, но они не подходят для хранения необработанных данных.
То, что вы храните, существенно влияет на то, как вы это храните. Моделирование Data Vault может быть излишним, если вы управляете только одной коллекцией данных. Если вы хотите стандартизировать данные из многочисленных источников и создать слой для управления и очистки данных без потери чего-либо, рассмотрите Data Vault или некоторые другие шаблоны хранения необработанных данных.
Поскольку слой золота находится ниже слоев бронзы/серебра, витрина данных имеет смысл.
Инмон указал, что хранилище данных является преемником модели ступицы и луча.
Бронза сосредоточена на хранении необработанных данных, чтобы их можно было последовательно обрабатывать. Silver — сопоставимая модель, но она была очищена и стандартизирована с использованием бизнес-правил и логики. Вам не нужна схема «звезда», так как денормализация снижает гибкость для создания вещей за пределами киосков данных. Например, создание графовой модели или обучающего набора данных.
Поскольку вам не нужно переносить в него все из необработанного хранилища, работать с Silver Layer не так сложно. Кроме того, данные можно комбинировать способами, которые имеют смысл для создания вариаций для последующих вариантов использования.
Существует несколько методов использования и преобразования данных для Gold Layer. Звездообразная схема/киоск данных — это только начало.
Компоненты домика у озера:
- Неизменяемая зона приземления, куда попадают необработанные данные. Я предпочитаю поддерживать вещи в удобочитаемом виде. Все имеет точку данных «загружено в» и «имя файла».
- В Подготовительной зоне данные зоны приземления преобразуются в дельту/воду/айсберг. Также может быть версия с дедуплицированными данными, например текущая версия данных в стиле CDC. Обычно здесь добавляется хеш-ключ строки, и на этапе проверки качества данных дубликаты не проверяются.
- Зона трансформации — называйте ее как хотите, но именно здесь проходят этапы моделирования данных. Отдельные исходные системы оцениваются и нормализуются перед связыванием и обновлением с другими. Результатом этого этапа обычно являются основные данные.
- Зоны витрины данных, каждый бизнес-сектор получает свою собственную витрину данных с общей витриной данных для элементов, используемых несколькими витринами, таких как клиенты или даты.
Озеро данных, по сути, создает возможность, подобную хранилищу данных, в масштабе вашего озера данных. В результате данные могут быть сохранены на S3 в виде паркетных файлов, организованных в таблицы Iceberg и каталогизированных с помощью Nessie. Затем, используя механизмы запросов, такие как Dremio Sonar, вы можете запрашивать эти данные в масштабе без необходимости делать копии в хранилище данных или платить за это.
Проблема с домиком на озере заключается в том, что он очень ограничен с точки зрения типов файлов, которые он поддерживает, и на то есть веская причина: если у вас есть тонна CSV, домик на озере не будет работать, так как вам придется либо преобразовать их, либо запрос производительность будет ужасной. Когда вы преобразуете их, вы теряете большую часть очарования домика у озера.
Однако красота домика у озера со столами Iceberg заключается в том, что вы можете использовать оба; вы не привязаны к одному движку для всех операций чтения и записи, как это обычно бывает на складах и в закрытых домиках у озера. Таким образом, вы можете использовать любой инструмент, подходящий для работы, интегрировать хранилище метаданных на основе Nessie и внедрить контроль версий в стиле git непосредственно в SQL.
