Автоматизированный, Без кода Стек данных
Научиться Astera Data Stack может упростить и оптимизировать управление данными вашего предприятия.
Проверка модели данных для повышения качества схемы вашего хранилища данных
Что нужно для обеспечения качества и надежности реализации вашего хранилища данных? Углубленная система проверки модели данных, которая позволяет вам тщательно проверять исходные и целевые модели и помогать исправлять их еще до их развертывания. Потому что, если ваша схема хранилища данных точна, последующие процессы загрузки данных и составления отчетов будут автоматически оптимизированы и безошибочны.
Концептуальные модели данных служат основой любой архитектуры хранилища данных, предназначенной для доставки надежных данных для отчетности и аналитики. Будучи ядром такого невероятного механизма (хранилища данных), имеет смысл только гарантировать, что модели данных при использовании будут работать бесперебойно, без каких-либо ошибок или нарушения процесса разработки.
Изображение Кредиты: Компьютерщик и тыкать
Но построение моделей данных редко бывает простым. Некоторые скажут, что это была бы мечта для разработчиков моделей данных, которые хотят, чтобы их модели работали как часы, когда разработчики впервые используют их для процессов загрузки данных. Так как же вы, как разработчик моделей, можете достичь нирваны полного доверия и уверенности в своих моделях данных и избежать длительных циклов тестирования?
Ответ заключается в выполнении комплексных проверок моделей данных во время разработки и непосредственно перед их развертыванием.
Давайте углубимся в то, что подразумевается под проверкой модели данных и как она может повлиять на общие сроки и качество вашей проект хранилища данных.
Что делает проверку модели данных необходимой для DW
Очень важно выявлять эти ошибки модели данных во время разработки.
При создании схемы хранилища данных разработчики моделей данных должны быть осторожны с множеством мелких деталей, чтобы их модели данных работали бесперебойно в последующих процессах. Чтобы дать вам представление, давайте рассмотрим два основных этапа моделирования системных данных, которые значительно выиграют от надлежащих проверочных проверок.
1. Проверки во время разработки
Модели данных строятся со ссылкой на ваши исходные и целевые базы данных. Вам необходимо убедиться, что ваши модели соответствуют определенным правилам, статистическим тестам и стандартам этих баз данных и не имеют логический ошибки.
Из издания перспектива моделирования исходных данныхРазличные типы проверок включают поиск несоответствий на уровне полей между моделью и исходной базой данных. Они варьируются от различий в типах данных, индексах, псевдонимах, именах столбцов и таблиц, вплоть до длины символов, возможности обнуления столбцов, первичных ключей и отсутствующих полей в базе данных.
По сути, если таблицы базы данных и модель исходных данных не синхронизированы, вы получите ошибки гораздо позже, когда будете использовать модели данных для построения конвейеров данных и сопоставления полей.
Давайте поговорим о построение целевой схемы, которым может быть 3NF, многомерная модель или хранилище данных. Для этого обсуждения мы будем использовать многомерное моделирование (из-за его популярности среди масс). Требуется настроить факты и измерения, определив бизнес- и суррогатные ключи, ключи даты транзакции, Роли SCD, идентификаторы строк, проверки нулевых значений и некоторые другие спецификации.
Возьмем пример Сотрудник измерение. Вы хотите вести историю различных аспектов сотрудников, например, когда они были повышены по службе, изменение зарплаты, дата, когда они были приняты на работу и покинули компанию и т. д. Для этого вам нужно будет использовать SCD типа 2 или типа 6. Кроме того, необходимо убедиться, что бизнес-ключи и суррогатные ключи назначены, связи установлены и определен один идентификатор строки.
Отсутствует ошибка суррогатного ключа в измерении «Сотрудник» с полным контекстом.
Итак, что произойдет, если одна или несколько частей головоломки пропадут? Допустим, суррогатный ключ не определен.
Когда вы запускаете конвейер данных в первый раз, он вставляет данные обычным образом. Чтобы исправить это, разработчикам ETL придется сообщить об этой проблеме команде моделирования данных, которой затем придется найти это конкретное измерение с отсутствующим суррогатным ключом, чтобы исправить его. Опять же, вся эта переделка будет долгим процессом.
2. Проверки для обеспечения соответствия базе данных назначения.
После построения схемы хранилища данных следующим шагом будет копировать это в целевой базе данных. На этом этапе вам необходимо убедиться, что сценарий вашей схемы соответствует поставщику целевой базы данных, которым может быть Snowflake, Oracle, Azure или Teradata.
Чтобы представить это в перспективе, давайте возьмем пример Snowflake и того, как он не использует индексы. Поэтому, если вашей исходной системой является SQL Server, который поддерживает все различные варианты индексирования (первичный ключ, кластеризованный, некластеризованный и т. д.), Snowflake выдаст ошибку о том, что индексирование не поддерживается во время выполнения.
Имея модуль проверки модели данных, вы можете легко проверить модель и протестировать качество и целостность моделей данных перед их развертыванием в целевой базе данных или использованием для заполнения хранилища данных. Это экономит командам много часов разработки, которые в противном случае были бы потрачены на переделку модели данных и перестройку конвейеров данных.
Нужна ли вашей команде по моделированию данных система проверки?
Они, безусловно, делают.
Давайте поговорим о явных преимуществах, которые получают команды, работающие с хранилищами данных, от наличия компетентной системы проверки модели данных.
Определяет, где именно находятся ошибки и предупреждения
Предположим, в вашей базе данных OLTP имеется около 60 таблиц, на основе которых вы создали модель исходных данных. Некоторые таблицы могут иметь более 30 полей. Теперь, когда вы пытаетесь загрузить данные в эти таблицы, ваш поставщик базы данных выдает ошибку о том, что определенные типы данных и длины символов не поддерживаются и их необходимо изменить. Вполне вероятно, что вам и вашим коллегам-разработчикам моделей данных придется часами просматривать модели, проверять каждую сущность и исправлять все эти ошибки.
Некоторые распространенные ошибки в моделях данных
Наличие инструмента проверки модели данных помогает мгновенно идентифицировать все ошибки и предупреждения и предоставляет полный контекст того, где они находятся. Он практически избавляет от догадок при тестировании ваших моделей данных и направляет вас туда, где вам нужно внести исправления в вашу схему с помощью итеративного процесса.
Сейвы от перехода туда и обратно между командами
Изображение Кредиты: Блог Рича Мурнейна
Обычно в проектах по хранению данных участвуют несколько команд, занимающихся различными аспектами хранилища данных. Будут разработчики моделей данных, администраторы баз данных, разработчики ETL, архитекторы данных и некоторые другие.
Команда моделирования данных работает с бизнес-пользователями, чтобы определить их потребности в отчетности, консультируется с администраторами баз данных, чтобы получить спецификации поставщиков, строит и развертывает модели и, наконец, дает зеленый сигнал разработчикам ETL, чтобы они начали создавать конвейеры для загрузки данных.
Теперь, даже при наличии инструмента хранилища данных, это трудоемкий процесс. Но ошибки обычно не проявляются до тех пор, пока вы не дойдете до момента выполнения конвейеров данных для заполнения хранилища данных.
Углубленная система проверки модели данных избавляет пользователей от необходимости возвращаться к исходной строке, вносить изменения в модель данных, передавать ее следующей команде, а затем запускать потоки загрузки данных, чтобы проверить, работает ли она нормально. Внося исправления при разработке моделей данных, вы можете существенно упростить процесс, ускоряя весь цикл разработки на часы, если не на дни или недели.
Обеспечивает соблюдение правил сценариев поставщика базы данных.
Допустим, ваша база данных OLTP находится на SQL Server, а хранилище данных вы создаете в Oracle. При развертывании схемы в базе данных Oracle вы, скорее всего, столкнетесь с проблемами, связанными с ограничениями на типы данных, длину символов и масштаб, поскольку оба поставщика по-разному обрабатывают эти параметры. Аналогично, вы можете получить сообщение об ошибке при наличии кластеризованного индекса в вашей целевой модели, что, опять же, Oracle не поддерживает.
Имея систему проверки модели данных, вы можете легко решить эти проблемы соответствия задолго до развертывания схемы в базе данных Oracle. Это экономит как разработчикам моделей данных, так и разработчикам ETL много часов работы над разработкой, которая в противном случае ушла бы на выявление проблем и их решение в каждом объекте модели данных.
Ускоряет общий процесс хранения данных
«Чувак, если бы только существовала система для тестирования этих моделей данных и сразу же уведомляла меня о своих ошибках, мы бы сэкономили массу часов разработки, потраченных на их исправление снова и снова».
~Анонимный разработчик моделей данных, желающий получить желаемое
Эффективная система проверки модели данных может стать Святым Граалем для команд, занимающихся хранением данных, поскольку она выполняет сотни проверок как во время разработки, так и во время развертывания, чтобы гарантировать стабильность ваших моделей данных. Это позволяет проверять целостность и точность моделей на основе требований к отчетности и гарантирует их соответствие стандартам сценариев соответствующего поставщика базы данных.
Если все будет в порядке до того, как модели данных будут развернуты и переданы следующей команде, организации смогут получить значительную экономию времени, что приведет к сокращению сроков проекта.
Используйте проверку модели данных в один клик с помощью Astera Построитель хранилища данных
Приведенное выше обсуждение показывает, что система проверки модели данных является жизненно важным ядром для процесс моделирования данных и помогает оптимизировать процессы на протяжении всего жизненного цикла хранилища данных.
Astera Построитель хранилища данных — это гибкое решение на основе метаданных, которое позволяет проектировать, развертывать и тестировать модели данных и использовать их для построения конвейеров загрузки данных — и все это на единой платформе. Он поставляется с модулем углубленной проверки модели данных, который следит за моментом развертывания и гарантирует, что ни одна ошибка или предупреждение не останется незамеченным пользователем.
Всего одним щелчком мыши платформа автоматически предоставит вам картину состояния ваших моделей данных. Вы можете рассчитывать на: от проверки отсутствующих бизнес-ключей, аномалий отношений и несовпадающих типов данных до обеспечения соответствия стандартам сценариев целевой базы данных. Astera DW Builder для выявления и сообщения обо всех возможных ошибках и предупреждениях. Это гарантирует стабильность и полноту ваших моделей данных перед переходом к следующему этапу проекта.
Заинтригованы и хотите узнать, как можно проверить модели данных и оптимизировать весь процесс хранения данных? Проверить демо-версия продукта, или возьмите его на прокат и убедитесь сами с помощью Бесплатная пробная версия 14.
