Автоматизированный, Без кода Стек данных
Научиться Astera Data Stack может упростить и оптимизировать управление данными вашего предприятия.
Загрузка данных в факты и измерения — проще простого?
КимболлМногомерное моделирование в стиле многомерного моделирования было основной архитектурой для большинства разработчиков хранилищ данных в течение последних нескольких десятилетий. Денормализованная природа этих схем в сочетании с оптимизацией для ведения истории делает многомерную модель идеальным инструментом для арсенала хранилищ данных, особенно для составления отчетов посредством бизнес-аналитика (БИ) инструменты.
На первый взгляд идея проста: таблицы фактов содержат транзакционную информацию, а измерения обеспечивают контекст для этих фактов через отношения внешнего ключа. Однако возникают следующие вопросы: Насколько легко загружать и поддерживать данные в таблицах фактов и измерений? И стоит ли оно усилий?
Давайте рассмотрим сценарий, в котором вы настроили архитектуру для своего информационное хранилище — простая звездообразная схема, состоящая из информации о продажах в таблице фактов, окруженной несколькими измерениями, такими как клиенты, поставщики и т. д. Исходные данные, первоначально поступающие из разрозненных систем, загружаются в единый промежуточный уровень.
Цель состоит в том, чтобы настроить процесс загрузки и обслуживания ваших таблиц измерений и фактов. Загрузка данных в таблицы измерений может быть простой, если вы не хотите вести историю. В таком случае вам нужно будет обновить только записи назначения, что можно выполнить через Медленно меняющиеся размеры Тип 1 (SCD1). Вот фрагмент того, как будет выглядеть этот запрос:
Однако маловероятно, что этого будет достаточно в практическом бизнес-сценарии. Важно сохранить хотя бы некоторую историю в хранилище данных, чтобы выявить тенденции и закономерности. Именно здесь в игру вступают другие, более сложные типы SCD, такие как SCD 2, 3 и 6.
Если вы собираетесь использовать SCD 2 или 6 для определенных полей, таблица также должна содержать идентификаторы записей, чтобы распознавать активную строку для каждой записи. Это может быть флаг true/false, эффективный диапазон дат истечения срока действия или просто номер версии для каждой записи, и это лишь несколько примеров.
Если вы хотите использовать SCD 3 или 6, вам понадобится дополнительное поле для хранения предыдущего значения рассматриваемого поля.
Вот как могла бы выглядеть часть запроса, если бы вы использовали SCD 2 или 6 для ведения истории:
Это начинает выглядеть немного сложным? Мы коснулись лишь верхушки айсберга.
Вероятно, вам потребуются разные уровни истории для разных полей. Допустим, например, что у вас есть измерение «Сотрудник», содержащее информацию о зарплате и номер телефона сотрудника. Здесь вы можете отслеживать, как меняется зарплата сотрудника, просто обновляя номер телефона.
В подобных случаях вам следует использовать несколько типов SCD; SCD 1 для полей, которые просто требуют обновления, и SCD 2, 3 или 6 для тех полей, которые требуют сохранения определенного уровня истории. Учитывая столько всего, что нужно принять во внимание, вы можете себе представить, насколько сложным может стать запрос!
До сих пор мы сосредоточились на заполнении и обслуживании таблиц измерений. Эти измерения обеспечивают контекст для информации, хранящейся в таблицах фактов. Таким образом, каждое изменение в таблице измерений также распространяется и на таблицу фактов; обеспечение точности этого распространения может оказаться сложной задачей.
Некоторая информация, которую необходимо загрузить в таблицу фактов, недоступна в источнике. Суррогатные ключи, используемые для установления связей между таблицами измерений и таблицами фактов, отсутствуют на промежуточном уровне — они были созданы как сгенерированные системой ключи в каждом измерении.
Таким образом, вам потребуется разработать механизм, который будет использовать поиск по измерениям, чтобы переносить каждый входящий бизнес-ключ (естественный) с промежуточного уровня в соответствующее измерение и получать активный суррогатный ключ для этой записи. Более того, сложность получения этих суррогатных ключей будет зависеть от типа SCD, используемого для каждого поля, и идентификатора строки, присутствующего в таблице измерений.
Как будто этот процесс недостаточно сложен, вот вам еще одна кривая: что, если в таблице фактов есть некоторые недостающие записи, для которых не требуется самый последний суррогатный ключ? Вы можете использовать ключ даты транзакции для определения активного суррогатного ключа, при условии, что вы использовали идентификатор активной строки, специфичный для метки времени, например диапазон дат фактического истечения срока действия.
Ситуация может быть и наоборот: в таблице фактов могут быть некоторые записи, которые ссылаются на запись измерения, которая еще не добавлена в таблицу измерений. Это распространенная загадка хранилищ данных — поздно поступающие измерения и ранние факты. Чтобы решить эту проблему, вы можете создать фиктивную запись в таблице измерений во время выполнения.
Эта запись в конечном итоге будет заменена соответствующей (отложенной) записью измерения, поступающей из источника. Но это, по крайней мере, позволило бы выполнять поиск измерений в нужное время без каких-либо ненужных сбоев.
В целом загрузка данных в таблицу фактов может оказаться утомительным и подверженным ошибкам процессом. Если вышеперечисленные проблемы не решены. Например, ваши конвейеры могут выйти из строя или ваш склад может содержать неточные данные.
Вот пример запроса, который может загрузить данные в таблицу фактов:
Допустим, у вас все получается. Вы успешно ввели все необходимые запросы, и они идеальны. Ваша работа еще не совсем завершена. Процесс хранения данных никогда не завершается полностью, поскольку поддержание экосистемы так же важно, как и ее проектирование. Чтобы максимизировать производительность, вам необходимо обеспечить инкрементную загрузку данных, что требует реализации механизма отслеживания измененных данных (CDC).
Более того, эти сложные запросы потребуют частого обновления, в зависимости от потребностей бизнеса. Возможно, вам придется добавить или удалить поля, изменить определенные типы данных, изменить тип SCD, примененный к полю, и т. д. Внесение этих изменений в запросы не только отнимает много времени, но и чрезвычайно подвержено ошибкам. Прежде чем вы это заметите, вы, возможно, испортили существующий конвейер, внося незначительное изменение в механизм загрузки.
Несмотря на эти потенциальные проблемы с обслуживанием, вы все равно будете чувствовать, что большая часть тяжелой работы уже сделана. Однако предприятия постоянно стремятся модернизировать и улучшить свои процессы обработки данных. Может наступить день, когда ваша компания решит сменить платформу хранилища данных. Допустим, они решили перейти с локального SQL Server на облачную платформу, например Снежинка or Амазонка Redshift.
Вы понимаете, что для этого потребуется? Во-первых, вы должны создать новую архитектуру на новой платформе. Затем перепишите все запросы, чтобы настроить конвейеры, встроенные в новые целевые таблицы. По сути, вам придется выполнить весь процесс заново — с нуля! Итак, основываясь на всем, что мы выяснили, можно с уверенностью заключить, что загрузка данных в таблицы фактов и измерений НЕ кусок торта. Уровень сложности может стать слишком высоким даже для технических пользователей.
Но что, если я скажу вам, что есть гораздо более простой способ добиться того же результата?
Доступно Astera Строитель хранилищ данных, вы можете построить архитектуру для своего габаритная модель с помощью интуитивно понятного конструктора моделей данных. Кроме того, интерфейс «щелкни и укажи» позволяет назначать полям фактических данных и таблицам измерений роли, такие как типы SCD, идентификаторы активных строк, ключи даты транзакции и т. д.
Самое главное, вы можете использовать информацию в своих моделях в компоненте ETL/ELT инструмента с возможностью перетаскивания, чтобы автоматизировать утомительные и трудоемкие задачи, связанные с загрузкой таблиц фактов и измерений — от ведения SCD в измерениях до выполнения поиск измерений в таблицах фактов. Сложный код, который мы видели ранее, генерируется инструментом автоматически.
Зачем тратить столько времени и усилий на написание огромных запросов, если того же результата можно добиться с помощью простого визуального интерфейса? Несмотря на то, что загрузка данных в факты и измерения обычно не является простой задачей, с Astera Построитель хранилищ данных, это возможно!
Если вы хотите изучить гибкий способ создания своего хранилища данных, свяжитесь с нами по адресу [электронная почта защищена] сегодня или загрузите 14-дневная бесплатная пробная версия.
