Автоматизированный, Без кода Стек данных
Научиться Astera Data Stack может упростить и оптимизировать управление данными вашего предприятия.
Модернизируйте свою архитектуру данных с помощью передового подхода к моделированию размерных данных
Многомерное моделирование данных было основой эффективного проектирования хранилищ данных на протяжении десятилетий. Методология Кимбалла обещает оптимизированную производительность запросов и упрощенную структуру, которая будет легко понятна заинтересованным сторонам на всех уровнях предприятия. Читайте дальше, чтобы узнать, как наш автоматизированный подход поможет вам реализовать эту схему для максимальной эффективности в вашем хранилище данных.
Чтобы создать по-настоящему современную архитектуру аналитики, которая поддерживает передовые методы, такие как машинное обучение, прогнозный анализ, прогнозирование и визуализация данных, вам необходимо реализовать многомерное моделирование данных в своем хранилище данных. Есть несколько галочек, которые должна пройти система BI, прежде чем она сможет пройти квалификацию.
Во-первых, он должен быть способен собирать и обрабатывать большие объемы данных из разрозненных транзакционных источников. Во-вторых, он должен обрабатывать как текущие, так и исторические записи. В-третьих, он должен поддерживать ряд сложных, постоянно меняющихся операций запроса. Наконец, ему необходимо предоставлять актуальные и актуальные данные для ваших конечных пользователей.
Ключ к удовлетворению этих ожиданий лежит на этапе проектирования во время моделирования данных. Решения, которые вы примете здесь, напрямую повлияют на гибкость, производительность и масштабируемость вашего хранилища данных.
Но зачем моделировать размерные данные?
Классическая схема звезды
Допустим, вы выбрали схему 3NF, которая сводит к минимуму избыточность данных за счет нормализации. Количество столов хранения существенно увеличится. Это означает, что любой запрос, выполняемый к схеме 3NF, будет включать в себя множество сложных соединений.
По сравнению, размерное моделирование Методы предлагают упрощенную денормализованную структуру, которая создает гораздо меньше соединений и, таким образом, повышает производительность запросов. Модели размерных данных также поддерживают медленно меняющиеся данные и измерения, привязанные к дате/времени, которые облегчают исторический анализ. Эта схема более понятна конечным пользователям, что позволяет им сотрудничать со своей командой разработчиков, используя общий язык. В результате становится намного проще построить хранилище данных на основе реальных бизнес-процессов и развивать модель данных, чтобы она соответствовала постоянно меняющимся потребностям вашего предприятия.
Давайте рассмотрим некоторые критические факторы, которые сделают ваши многомерные модели ключевым фактором развития вашего хранилища данных.
Обратите внимание на зерно
Очень важно найти подходящее зерно для вашей таблицы фактов (подсказка: пшеница не подойдет).
Очень важно найти подходящее зерно для строки таблицы фактов (подсказка: пшеница не подойдет).
Как правило, вам потребуется построить отдельные многомерные модели для разных областей деятельности вашего предприятия. Каждый из этих процессов будет иметь определенную структуру; это уровень детализации, на котором данные хранятся в таблицах фактов и связанных измерениях. Очень важно поддерживать единообразие в многомерных моделях данных, чтобы обеспечить наилучшую производительность и удобство использования на этапе потребления. В противном случае вы можете получить неправильно рассчитанные отчеты и анализы.
В качестве отличного примера предположим, что вы разрабатываете многомерную модель данных для своего процесса продаж. У вас есть два разных источника, в которых записываются данные: один отслеживает внутренние счета-фактуры по каждой транзакции, а другой отслеживает заказы, генерируемые по всему миру в месяц. Одна таблица гораздо лучше подходит для последующего анализа данных, в то время как вторая, по сути, обеспечивает сводное представление процесса продаж, которое будет полезно только для отчетов высокого уровня и бизнес-аналитики.
В общем, когда данные относятся к различным бизнес-процессам, можно предположить, что потребуется построить несколько моделей. Таким образом, вам необходимо уметь точно проектировать эти схемы на основе связей сущностей, определенных в исходной системе. Таблицы фактов и измерений должны быть правильно назначены на соответствующем уровне детализации.
Перейдя в процесс которое позволяет автоматизировать первоначальное моделирование схемы, вы можете гарантировать, что эти основные концепции правильно применяются к вашей схеме. После этого вы можете работать над тем, чтобы привести его в соответствие с вашими требованиями BI. Что еще более важно, вы можете легко обновить свои модели, чтобы отразить изменения в исходной системе или требованиях конечного пользователя, а затем распространить эти изменения по конвейерам данных без обширной ручной доработки.
Еще одна важная деталь для правильного подхода — это обеспечение того, чтобы ваш подход к многомерному моделированию включал таблицы измерений дат. В этих таблицах представлены различные типы измерений для конкретных дат, такие как ежедневные, ежемесячные, ежегодные, финансовые кварталы или праздничные дни. В конечном итоге это поможет конечным пользователям более эффективно фильтровать и группировать свои данные на этапе потребления.
Автоматически обрабатывайте медленно меняющиеся данные
Эти исторические записи могут пригодиться (https://xkcd.com/2075/).
Бизнес-процессы находятся в постоянной стадии изменений. Сотрудники присоединяются к организации, получают повышение по службе и в конечном итоге выходят на пенсию. Клиенты переезжают на новый адрес или меняют контактные данные. В некоторых случаях целые отделы поглощаются, переименовываются или реструктурируются. Поэтому вы должны убедиться, что ваша многомерная модель может точно отражать эту динамическую среду.
Применяя правильная техника обращения с SCD В своих многомерных моделях данных вы можете учитывать изменения в записях в исходной системе и, при необходимости, сохранять исторические данные для дальнейшего анализа. Теперь в зависимости от ваших требований доступно несколько типов SCD. Методы варьируются от SCD типа 1 для перезаписи прошлых значений до SCD типа 3, который обновляет текущую запись при добавлении нового поля для отображения предыдущего значения атрибута.
Таблица измерений также может содержать дополнительные поля для отражения того, когда конкретное изменение вступило в силу (Дата вступления в силу/Дата истечения срока действия) или валюта конкретной записи (Версия) в случае, если в течение нескольких лет в нее было внесено несколько изменений. У вас может даже быть индикатор активного флажка, указывающий, какая версия записи используется на момент составления отчета.
Единственное предостережение здесь заключается в том, что вручную выполнять эти вставки и обновления во время загрузки хранилища данных затруднительно. В конце концов, мы говорим о реализации процессов для автоматической проверки изменений в записи исходной системы, а затем определения того, следует ли перезаписать или обновить записи. В последнем случае может потребоваться создание нескольких новых суррогатных ключей, не говоря уже о нескольких новых полях. Вам также потребуется создать сопоставление данных для всех этих действий.
Если вы разрабатываете свое хранилище данных с помощью инструмента многомерного моделирования данных, который использует подход, основанный на метаданных, без кода, вы можете просто назначить соответствующие типы SCD атрибутам на логическом уровне. Затем эти сведения будут переданы в механизм ETL, который сможет автоматически обрабатывать последующие вставки/обновления, объединения и сопоставление данных без каких-либо ручных усилий.
Упрощенная загрузка таблицы фактов
Все конвейеры данных ведут к таблицам фактов и измерений.
Загрузка таблицы фактов — еще одна область, требующая большого количества дополнительных ручных усилий при разработке конвейера данных. Этот процесс включает в себя разработку нескольких соединений между таблицами измерений. Учитывая, что таблицы фактов обычно содержат миллионы записей, высокая стоимость выполнения этой операции очевидна.
Каждый раз, когда таблица фактов заполняется, поиск в многомерной модели данных сопоставляет каждый бизнес-ключ с соответствующей таблицей измерений и преобразует его в суррогатный ключ. Предположим, что таблица измерений особенно велика или в исходные записи было внесено несколько изменений (в случае медленно меняющихся измерений). В этом случае поиск может стать особенно трудоемким и ресурсоемким. Конечно, эта задача будет повторяться последовательно, поскольку данные о транзакциях постоянно обновляются.
Во многих случаях вам может потребоваться создать дополнительный промежуточный стол между исходной системой и хранилищем данных, чтобы хранить все эти исторические данные и, таким образом, упростить их дальнейшую обработку во время загрузки.
Вам также может потребоваться выполнить расширенное иерархическое сопоставление данных из исходных систем, чтобы гарантировать, что данные с правильной степенью детализации загружаются в таблицу фактов.
Теперь, если мы вернемся к подход, основанный на метаданных Как было сказано ранее, мы можем найти способ радикально ускорить этот процесс. Если вместо этого вы настраиваете атрибуты фактов в многомерной модели данных, а затем используете эти сущности в конвейере данных, соединения и поиск, необходимые для заполнения хранилища данных, могут выполняться автоматически с помощью базового механизма ETL/ELT.
Внедрите процессы для работы с ранними фактами
Иногда реальность вашей бизнес-среды может не полностью соответствовать требованиям стандартной схемы.
Например, идентификатор сотрудника может быть создан для новобранца до того, как организация получит какую-либо информацию о том, кем он является, или даже о конкретной дате вступления кандидата в должность. Если вы создали многомерную модель данных, отражающую ваш процесс управления персоналом, этот сценарий приведет к записи таблицы фактов без каких-либо связанных размерных атрибутов. По сути, неудачный поиск внешнего ключа.
В этом случае нужно дождаться поступления желаемой информации, поэтому лучший подход — заменить недостающие данные измерением-заполнителем, содержащим значения по умолчанию. Затем, как только сведения о сотруднике будут записаны полностью, атрибуты можно будет обновить в соответствующей таблице. В других случаях вы можете вообще не захотеть обрабатывать запись, и в этом случае вы захотите, чтобы запись была помечена или вообще пропущена во время заполнения хранилища данных.
Независимо от того, как вы справляетесь с такими ситуациями, ваша многомерная модель данных должна допускать динамические конфигурации, отражающие характер вашего бизнеса.
Быстрое создание многомерных моделей данных, обогащенных метаданными, с помощью Astera Построитель хранилища данных
Astera Построитель хранилища данных — это комплексный инструмент моделирования многомерных данных, который позволяет создавать комплексные модели измерений из транзакционной системы за считанные минуты.
Наш интуитивно понятный механизм может автоматически разработать наиболее подходящую схему, назначающую факты и измерения на основе связей сущностей, содержащихся в исходной базе данных. Кроме того, вы можете использовать многофункциональный набор инструментов ADWB для создания собственной многомерной модели с нуля, дополненной таблицами измерений фактов, измерений и дат. Затем просто настройте каждый объект с необходимыми атрибутами, включая типы SCD, суррогатные ключи, бизнес-ключи и другие идентифицирующие метаданные.
Мы также предлагаем различные функции для ускорения процесса загрузки хранилища данных, включая специальные загрузчики фактов и измерений для ускорения передачи данных в пункт назначения. ADWB также предоставляет специальный объект запроса модели данных, который позволяет вам объединять несколько исходных системных таблиц для создания иерархической исходной сущности, которую можно легко сопоставить с соответствующими таблицами хранилища данных.
Чтобы поближе рассмотреть Astera Возможности многомерного моделирования и автоматизации хранилищ данных DW Builder, Связаться с нами сейчас. Или проверять продукт для себя.
